Sunday, 19 March 2017

On the other side of Certainty

"We have to create the preconditions under which
Exaptation can happen naturally...
which actually means introducing inefficiency into systems"

"The question is no longer how systems behave ...
but how to ask for the probability distribution
of the properties that change the system"


Moving from project- into product world last year, I wanted to experience the real long-term view, because only strategy can tackle complexity. And our software grows more complex, though arguably less complicated, every year. But I also wanted to understand uncertainty, the dark matter of complexity, better. After some time in, I understand it's probably more important for an architect* to have strong operations knowledge than very strong algorithmic skills.

Resilience is sometimes mistaken as being adaptive, or agile. It just means expecting uncertainty and disruption, but also working properly under normal conditions. Just calling everything disruptive, and reacting in an agile way to every random demand, is not resilient. For instance, "The datacenter as a computer"** came to us, rather unexpected, from a relatively "boring" infrastructure level, rather than from new frameworks and startups, but also not from consortium standards and language ecosystems. Similarly, in true grassroots manner, polyglot programming and JavaScript on top of Unix principles catapulted us into the 21st century and will eventually enable domain logic to exist, as Adrian Cockcroft calls it, in functions, unaware of most technological constraints. In order to understand resilience, you need to care about your product, and want to improve it, have a real goal, a story you want to tell. Ironically, you have to be a little bit un-adaptive, inefficient and un-agile in order not to overfit, but to really improve.

We are still waiting for the 4th paradigm of programming. My guess is it's going to be more than just goal-oriented, it will be probabilistic, in the sense of an abstract goal corridor. While engineers will live inside the goal corridor, making sure its workings are predictable, specializing in certainty, architects live on the outside, in the long tail of the probability distribution, the Multiverses where the Dragon Kings live, outside predictive models, specializing in uncertainty. That’s what makes a system resilient. It implies engineers have a fairly static/discrete/fitted view of a system, the perfect snapshot, the position, whereas architects have a time-smeared continuum perspective, the story, the momentum. It's the whole story, not only the goal, that differentiates between emergence and evolution. But it's also important to understand that both of those roles are equally creative and forward-looking, none is a "higher level", they are two sides of the same coin.

Helga Nowotny's distinction between risk and uncertainty fits nicely here - risk can be computed, uncertainty not. Risk a relation between snapshots, uncertainty is the continuum in between. A weather forecast has risk, the climate is uncertainty. In that sense, a risk-driven architecture involves everyone, but uncertainty needs a different perspective. The future leaves to the architect (the systems-of-systems-carer, archeological gardener, forensic librarian, ontological cartographer or whatever you like to call her) the role of the curator, and maybe narrator, of the uncomputable. Paraphrasing what Akka Architects say: Architects don't design system interactions, they curate the context for a discourse about system interactions.

"It is not a question of establishing limits with walls,
but by other means"

Why is all of this important, why should we get used to speak in terms of probabilities, but, most importantly, tackle certainty and uncertainty differently, but with the same importance?

In my last job I learned the importance of maintainability and traceability. In every single one of my projects the first thing I introduced was proper monitoring, alerting and analytics - Robustness was core, as was accountability, to be able to become lean and agile. With new infrastructure, whether in the cloud or not, this has become the default. The battle for certainty, traceability, and robustness is won.

While we were busy fighting this battle, uncertainty has come back, as Ms. Nowotny would put it, "systemic risk", as risk deeply embedded in the complex relationships of our services: "Uncertainty switches gestalt". A cloud service going down is a risk that can be predicted - the dashboard not showing it, because it is hosted on the same cloud service is systemic risk, the type of Dragon King uncertainty which we don't expect. Soon it will be mainstream that coders will pair with AI, and operations and product teams will regularly train models rather than manually define metrics. The relationships between components will become so complex that, more often than not, it will take a long time to even recognize errors, or feature usage, let alone find the root cause or customer need.

Despite all the data we accumulate, Observability does still not mean Explainability (sometimes as beautifully visualized as our old architecture diagrams) or Introspection, the ability to rationalize the inscrutability of AI.

Most of our architecture diagrams are nothing more than Thomassons, useless depictions of a fictional state which we only keep because it took us so long to create them. But similar to code, it's actually more productive to delete them. What we need is a visualization of the statistical complexity of actual state. In my book, a good friend of mine wrote a story how we made network traffic audible in order to hear inconsistencies - that's what we need to understand the architecture of a system. A real-time explanation of what's going on, mapped to the architecturally relevant components, such as interfaces, deployment units (like functions) and, last but not least, rules inside machine learning systems.

I am looking forward to new, real-time programming and data toolkits, think Eve, Jupyter and Glitch, especially because they enable a different kind of coder to build software. And with serverless and deep learning we will be able to scale those apps and the data required quicker than ever before. But it will require architects to understand them, if something is wrong, if a use case needs to be developed or a feature is behaving unexpectedly - i.e. in operations and product development. These architects won't be able to look at diagrams anymore, they won't be certain about documentation (not that they ever were), and they won't even be able to observe the system in its entirety. Architects will indeed become archeological gardeners or forensic librarians. Most importantly, they will become like anthropologists or biologists in the early days, trying to understand evolution, with the help of experimentation and collection. We'll finally see architects developing models instead of diagrams. And with that, we will see very different people in this role too. Which is very exciting.

*) separating this from a Tech Lead here, sometimes it can make sense to combine the two roles, though
**) e.g. serverless computing platforms such as Lambda and globally distributed databases such as Spanner, with them a different approach to time, where evergreen becomes an axiom, but also a comeback of Spreadsheets through functional programming and k/v stores

Saturday, 26 November 2016

Letter to my future self

This is a variation on a letter to my future self, just a public one. A reminder what I thought, written on the last day in my old job - exactly 6 months ago. I would write it differently now, so I’ve added many current links. Don’t read it as a manifesto, read it as a snapshot.

When I quit my first full-time employment in a start-up, after my own one, it was because I felt start-ups disguised the struggles for power under a hood of coolness and artificial problems.

I joined consulting to be outside of power structures, and tackle real problems (as real as it gets in corporations). Accenture Digital was inspiring, and t-shaped/widened my horizons - more than once. It allowed me to thrive in technology, strategy, product prototyping, Agile, design thinking and to trust liberal arts. I will always remember the learnings in those years: All the opportunities I had to meet great, diverse, truly interesting people across the globe, to learn about dozens of domains, to build digital-first, mobile-first, offline-first products, omni-chanel SPA, Microservices with vertical slices, API management and EAI, or CQRS systems. In short I am grateful to have been inspired and had the chance to inspire others.

Really building stuff around existing problems is what makes technology consulting so amazing. Seeing what you’ve built in the wild, changing the way an industry runs. Building a team around a problem, changing their perspective, and mine. Unlearning is just as important a skill as learning. We are constantly developing, iterating, behaviours, patterns and principles of good systems, including its human actors. These principles always come with a drawback, outweigh by the advantages. Microservices might manifest team separation and can lead to incoherent style in end-user product experience. Event systems enforce eventual consistency, and not every organization is ready for probabilistic thinking. Containers can degrade security (and with it privacy) to a part of commerical opt-in dependency-hell rather than reliable infrastructure; Design Thinking either glosses over faster horses or fakes ownership because agencies just rebrand; Patterns sometimes promote solutions that only look good on paper; CI, Lean and Feedback prefer simplistic, biased, measurable KPI’s over long term goals. OSS, Agile and DevOps can establish a status-quo burn-out treadmill of minor, over-hyped, pseudo-improvements, and holocracy could build a cast system; Opinionated often just means tribal or elitist (for lack of a better word); competing API, AI and Cloud standards with unexplainable, magic automation and integration can cement vendor lock-in; Cross-vendor services are still not solved, maybe due to academic REST and DDD being inherently anti-evolution with their focus on a Xanadu-ideal, fixed state. And simplicity does never illustrate success, while complexity does. Not everyone wants to hear those drawbacks, and few openly make the tradeoffs. Most want to hear the innovative, the disruptive, which sometimes simply excludes the best option for the largest group.

In addition, the problem with the typical project organization is that it takes a lot of effort to not disguise debt with another layer but actually change the underlying problem (a post on this is coming up). I always enjoyed this challenge, and I had the pleasure of being on many projects which achieved this, and turned into real, strong products. But kickstarting this "digital transformation" every so often started to nag on my belief in actual progress.

An unfortunate side effect of the project and OSSpublishing” treadmill seems communal wisdom is often discouraged in favour of new marketing slang. Or, like Maciej puts it:
"This is not the first time an enthusiastic group of nerds has decided to treat the rest of the world as a science experiment. Earlier attempts to create a rationalist Utopia failed for interesting reasons, and since we bought those lessons at a great price, it would be a shame not to learn them"

Sometimes it feels through lean and measurability the Peter Principle and pop-culture power struggles in the form of Deutungshoheit have eventually arrived in what used to be an idealistic geek world of IT, pushing practitioners from actual consulting into meta- and consult-speak. If software indeed eats the world, it seems to prefer junk food. To avoid this trap I took a step back on conference talks and wrote an obscure book. But I am interested in historical patterns, across disciplines, which is hard to communicate. The nagging feeling stayed.

So I decided it’s time to move away from a project into a product organization. I wanted to feel out of my comfort zone again, but still contribute to technology. A few of my considerations which company to join, in no specific order, were:
  • It should be first class in building delightful products with end-user impact, where good design is a strategic asset. Not just gadgets. I see technology simply as a tool to materialize curiosity. 
  • Many traditional enterprises consider themselves digital companies now and like to use “disruptive” technologies, but I haven’t seen many who actually care. Mostly it's a hedging strategy. I want to work in a real digital enterprise, maybe on intelligent and intuitive products (e.g. what I often miss in AI and technology as a whole is the capacity to trace the intentwhy did you do that”?) 
  • It should be first class in technology. I am more of an operational excellence person, so I don't care if it's boring technology, as long as there is a clear rationale and it makes a real impact. In short: An engineering mindset. 
  • It should see information and technology as a narrative. Over the years I’ve got more and more interested in systems of systems, the polytechnic, involving people, and believe the role of an Architect is to enable strategic, uncertain, but fair, critique and decisions within the team. 
  • It should have a strong and clear vision, not only building products but aligning those products to a long term goal. However, I would prefer that goal to be ethical, not to wipe out the middle class, centralize means of production and distribution, or make everyone dumber (Note: This was written before the US election, there would be much more to say on this in hindsight). 
  • While I believe my strength is to be a good tech lead and manager, and I enjoy building teams, I’d prefer less hierarchical organization (ever wondered that squad is a military term?), rather a swarm - what I liked about consulting. I’d prefer a strongly influencing, not necessarily managing position and a slightly slower, maybe even less visionary, but more humane company. 
  • It should be global, distributed and diverse. Living in many places, working with people from all kinds of backgrounds has enriched my life more than anything else. I have enough startup experience to not believe fast-moving (hierarchical) unicorns necessarily make better corporate citizens. Hence I prefer truly multinational, larger organizations. I like foxes, not hedgehogs
  • And finally, for now I want to stay in Asia, with its multiplicity an ideal model for the ever more complex and uncertain systems in his world, the opposite of the power structures I encountered in the past. Someday I might want to leave corporate world, and work on the grass roots. Asia is the best place to keep this door open. 

Google’s 10 things always resonated with me. They maintain a hive-mind culture based on research while at least sometimes trying to improve the world (yes, I know Silicon Valley). I am continuously impressed which brilliant people work there, and the degree of freedom they have. Let’s see if I can meet a few and learn.

Sunday, 5 June 2016

Towards a progressive REST API model

"Although REST interaction is two-way, the large-grain data flows of hypermedia interaction can each be processed like a data-flow network, with filter components selectively applied to the data stream in order to transform the content as it passes"
Roy Fielding's dissertation

This is the last post of my 5-piece API story "You don't manage the API, the API manages you". In my first real full-time job in a startup, founded around 2004, I had the role of both CIO and CMO. Back then, outsiders were not only laughing at this combination, but investors directly took is an example why the organization would be immature and not able to survive. It did, though, and prospered for a long time. Fast forward 10 years later and McKinseyDeloitteAccenture and Adobe are promoting the CIO/CMO model and more, design thinking as culture and blueprint. And CMO/CFO get closer with programmatic content and advertising. From my own experience in startups, but also consulting and service design, I know this model is not only about making the company customer-centric, and product-centric, but focusing the culture on most value [outcomes] instead of cost savings. It's about having a common goal, and allowing fast feedback for the product or service of the organization. This fast feedback requires fast, agile changes, a lean cycle, a risk culture and a real collaborative service, or product, design - I don't like singularity but it seems that cybernetics has won.

What does that mean for our API's? Can we really still revolve around a relatively static* hyperlink model that does not embody this feedback?


*) I am aware of solutions to that, like Gateway API's, Content Negotiation and Redirects but the core issue of no common ontology still exists and DDD alone cannot solve this

Thursday, 2 June 2016

Caching means Retention and other Web API quirks

"Fun here becomes related to formal logic and repetition, to the question of where software starts and ends, to mental states, to what operations it can carry out on the world, to the cultures and usages of software, to its building upon itself, to its aesthetics"
Olga Goriunova
For everyone who the other 3 posts in this series were to philosophical, relax, this is a technical one.

Thanks Daniel for suggesting Vinay Sahni's "Best Practices for Designing a Pragmatic RESTful API"; I like that he also emphasizes on documentation, what works in the real world and still believes in some principles like links. Also, Pedro's "List of HTTP API Specs", thanks to Mike for this tweet. And of course the ubiquitous REST Cookbook and the always good Apigee guides (I would reference CA Layer 7 here as well but they hide their guides behind a spamwall), the pragmatic API blog and Steve's rant.

As the 2nd last piece in this series, let's have a look into some technical quirks of Web API's.


Wednesday, 1 June 2016

The API and the Stream

As Alexander mentions in pattern No. 110:
“The position of main entrances controls the layout of the building. It controls movement to and from the building, and all the other decisions about layout flow from this decision. […] the first step in placing the entrances is to consider the mainlines of approach to the site”
In my last post I have written about API's as portals into your systems, a kind of grey box that gives enough semantics away to understand your system, but abstracts it for the target user group. While there is a lot material about patterns within API's and when to use API's (in messages/services), about the good and the bad, I still miss a holistic picture of systems-of-systems architecture that focuses on the API as the service itself. A behaviour that goes beyond a contract. I hope this will soon evolve in an interesting discussion, given that a few really clever people have literally picked it up: