Looking into the future

In preparation for my next talk I am researching Sci-Fi movies - since months. Just today I found a really nice article on "Cloud Atlas" on io9. Here they quote the makers of the film:

»but with the Wachowskis, they talk about the history of skyscrapers and how building materials have dictated the shifts in architectural language. From stone towers to metal and glass we pondered the next leap in architectural vocabulary- nano built structures, organic skins with solar cells etc.«

Architecture is always evolutionary as it is always based on a common understanding or a "shared hallucination" (via Ruth). Shaped by our use of materials and our society, architecture always represents a common vision of the future. That future neither has to be true for Sci-Fi movies nor for Architecture, but by deciding to implement this common vision, it allows us to agree on a model. And this model in turn can be questioned by anyone who would have not understood the details. This is why Sci-Fi movies are such a great example, they represent a pre-made iteration-1 prototype.

Sometimes, Architecture brings several disciplines together. As in Calatrava's case. That's why I like Martin Fowler's new Crossplatform framework of the same name. It allows an evolutionary approach, leveraging the power of Mixed-Model apps. Coming back to the materials, it allows us to take the fabric, the logic of an activity and make it truly technology independent - by actively choosing which technology is appropriate in which context.

Eventual Consistency is a usability concept

When Google introduced Spanner, the big news was NewSQL: the availability of general purpose transactions. In last years we have seen movement in a different direction: Basically, that transactions are not needed in many cases and developers should handle them on a highler layer. Often, the main argument used was a concept coined Eventual Consistency. In short, this concept was said to be that consistency is sufficiently reached if (in a distributed environment) all data is consistent at some point in time. The actual point could depend highly on the implementation of the storage subsystem (the database).

In his original post on Eventual Consistency, Werner Vogels already had in mind a much broader notion:

Many times the application is capable of handling the eventual consistency guarantees [...] user-perceived consistency. In this scenario the inconsistency window needs to be smaller than the time expected for the customer to return for the next page load. 

Greg Young put this into context when he showed the relativly small impact of server-side consistency in comparison to stale data along other transport layers to the client. Hence, I believe the point in Werner Vogels' paper never was that consistency is irrelevant, or a database does not have to be consistent, rather the point was that, across system boundaries, consistency needs to be in sync with the user expectation.

Eventual Consistency is a usability concept.

Take a look at CQRS for instance, the translation of the concept into a broader architectural context. You need Eventual Consistency in order to satisfy the CAP theorem, yet this does not mean in any way that your database cannot be transaction-safe. On the other hand, you can build an eventually consistent system and UI on top of a perfectly transaction-safe database like Spanner. Responsive design often means asynchronous design, regardless of the services or storage you use. Consistency is not a requirement database engineers have to solve, it's a user experience requirement.

Map vs. the Landscape

Architects think in maps. Unlike real-world building architects, though, most IT architects cannot just walk to the construction site and get a feeling of the environment. Plus, the time is shorter to cover the spatial dimension of the system. In a time, where high speed links become standard and our perception of the state of a system is like "a star that burned out 50.000 years ago" IT architects need to fly high to cover the distance, even quite literally if they need to coordinate worldwide distributed systems, development teams and clients.

The maps we currently have of systems are not capable of showing the right dimensions. We might even say that UML only covers the obvious parts, the IDE-supported parts, the fine-granular building blueprint instead of the actual, visionary architecture. Mapping functional, parallel, non-structured elements in UML is possible but loses any visually helpful information in the process.  If we look at the interesting systems, the large systems, the old proverb  "The most alluring part of a map is that which is unmappable" becomes true again.

20 years ago the Agile Manifest was the spearhead of a movement that banned documentation as chronically outdated. 20 years later, with emergent, fault-tolerant architectures we need to be able to look at the runtime state of a system, judging its functional and technical change over time, it's clients and connected systems, rather than arranging the building blocks upfront. Process Mining, Architecture Integrity Control (and adapt) and Continuous Refactoring become crucial. Evaluation becomes the key step of an architecture, not design. The architect becomes an explorer with an idea, rather than a supervisor with a plan.

How could we map this changing landscape?

And I expected it to be wonderful - it was.
I expected the world to be sad - and it was.
I just didn't expect it to be so big.
XKCD/1110 

Hoping to bring order and structure to the Bazaar

The Design of Design is one of my favorite books. In "A Generation Lost in the Bazaar" Poul-Henning Kamp is stating "It is a sad irony, indeed, that those who most need to read it may find The Design of Design entirely incomprehensible", where "those" refers to programmers who have "never seen a cathedral" (as in a beautiful architecture). His example of a cathedral is (the original idea of) Unix, whereas BSD is the bazaar.

Needless to say I don't fully agree with the idea of the perfect upfront design for systems of a certain size. But that's not important. Funnily I might be considered one of "those" - yet I like The Design of Design specificly because it talks about building a house and thinking about it iteratively. Furthermore, I am not a big fan of the building architecture metaphor. I don't think a black and white thinking is helpful, most cathedrals might turn out as a tower of Babel and others, like Unix, might be a pretty small shrine with 4200 LoC.

Poul-Henning claims "quality happens only if somebody has the responsibility for it" which is apparently based on a quote from the book "the boldest design decisions, whoever made them, have accounted for much of the goodness of the outcome". The question whether democracy/crowd/agile is better suited for certain problems than aristocracy/delphi-method/waterfall will never be solved, there is no true or false in this question. I guess I can agree with Poul-Henning on the responsibility as much as I can agree with Brooks on iterative design and still consider cathedrals harmful. The discussion always reminds me of the "first follower" meme - the key is not to have a central instance sanctioning "old festering hacks" (one comment to the post stated Linux as an example for that - very well done), the key is to avoid these hacks before they happen by allowing communication and embracing change.

My point is: Who said someone needs to be responsible for the whole system? With modern programming techniques programmers can be responsible for smaller parts and bring beauty to them. With modern collaboration techniques we can share thoughts about others' architectures and avoid a mix of, say, Perl and Python. In fact, almost all cathedrals of the middle ages were built iteratively (and even some modern ones). Sometimes visionary architects come up with something like Sydney Opera House and someone else finishes it. Ideas make leaders, not prohibition.

On civil engineering

Jonathan pointed me to Nick's excellent post why the analogy between civil enginneering and enterprise architecture is flawed.

It's just that I don't agree with his conclusion that "civil engineering, in practice, has not made the leap to layered cities", which implies that layered cities are desirable. The metabolists had them, Archigram experimented with them (The Plugin City), most imporantly Yona Friedman. They were not implemented because of cost (see Dubai) or because they were to complicated (see Beijing), they were not implemented because they would require either a common agreement on planning and design, or alternatively a single building pattern. Both are almost impossible to reach in a free world, where the market decides and risk control is a central element of planning. Betch Andres-Beck (another Theater student, quoted by Kent Beck) points out "It's extremely difficual to reverse progress in the construction world [...] asymetry of costs shapes the activities". In a cost-driven world, risk is key. In civil engineering this means decisions are literally fixed as the risk is on CAPEX - in software enginneering this means adaptability as the risk is on OPEX.

Geoff says it better than I could in his take on Archigram:

Architecture can reshape how we inhabit continents, the planet, and the solar system at large. Whether or not you even want inflatable attics, flying carpets, and underwater eel farms, the overwhelming impulse here is that if you don't like the world you've been dropped into, then you should build the one you want.