Building Evolutionary Architectures — Episode 1

The hosts recall that the club has met since roughly 2021 and is on its sixth or seventh book: they go chapter by chapter, discuss the key ideas and swap stories from their own work, and recommend Alexander's Telegram channel of short book reviews. Sergey Baranov was expected on air but a force majeure intervened, so they wish him well and promise him next episode. They are reading the second edition: in the first one, as one host remembers, Pramod was not among the authors, and chapters about data were probably added in the second, since he turns up precisely in such editions. The subtitle changed too: instead of support constant change the authors bring in the word automatic. Between the editions they seem to have realised that their evolutionary story overlaps with governance, a function that existed in IT before and was also about steering how systems develop, only it sounded less fashionable.

The first edition had noticeably fewer examples, and over the six years since, much of it has come to look obvious. The book has nine chapters: it used to be a flat list, and now there are three parts, mechanics, structure and impact. The first collects the key properties and practices, the second the architectural decisions that help sustain evolvability, the third the influence of the surroundings, because nothing happens in isolation. The club has split the book into six episodes and starts with mechanics. The participants note the authors' fondness for terminology: architectural quanta came, as one host recalls it, from Fundamentals of Software Architecture by the same Ford, while connascence is not their invention, and the authors point back to a book from around 1993. One host recalls hunting for a long time in 2019 for where the term came from: it is so rare that this counts as a renaissance of the term. They will unpack it next time.

Chapter one starts from the obvious: building an architecture that will live beautifully from day one, cause no trouble and age gracefully is impossible or very hard, so it has to be renewed constantly. The participants like that the authors explain how systems develop through business: before the 2000s everything ran into the resources of a single machine, then Linux and open source won business over by being cheaper, and containerisation followed, with small pieces later reborn as microservices. Turn up in, say, 1999 proposing to slice the system into microservices and asking for a hundred machines with a hundred licences, and the business sends you away: one machine is cheaper and simpler. One host recalls that the club covered evolution in the same detail in the New Year episode on the Amazon manifesto: how the company moved off Sun onto ordinary servers at the turn of the century, and how a separate business model grew out of it.

Another participant brings up articles about Amazon rewriting some services back into more monolithic applications and raising utilisation by some ninety percent; he is told the story there is more about tools: Step Functions, Lambda and S3 became a hammer that drives nails even where a screw is needed, so the nails went in fast, then people thought again, pulled them out and screwed something else in. The authors' definition: an evolutionary architecture supports guided incremental change across multiple dimensions. They deliberately refuse to reduce architectural characteristics to non-functional requirements or quality attributes, because the old names, in their view, do not cover everything. The examples give four dimensions: technical choices and frameworks, data, security and operations. In the book's diagram the domain requirements sit in the middle with unit, integration and functional tests, and performance, auditability, legal and data around them. The list is not closed: whatever matters for your own product can go in there too. One participant recalls an interview with the authors: when the idea of evolutionary architecture was first presented, the answer was that they understood nothing, because architecture is what never changes.

A fitness function shows how close the current design is to the stated goal: it catches accidental changes and also lets you change the architecture deliberately, by adjusting the function and watching how the system fits the updated requirements. The name comes from evolutionary computation, which one of the authors worked on, where a fitness function decides whether a mutated instance is kept or discarded. The metaphor works: the architecture has to be healthy enough that the system never goes into a second or third full rewrite. The tools listed are very different: monitoring, where the value is not the metric but a signal taken through to an alert; static analysers counting code complexity; chaos engineering that switches off a piece of a data centre, sometimes easier to run by hand; analysers that spot a vulnerable library among the dependencies. For architectural checks, one participant guesses, the authors hint at ArchUnit or JDepend. The categories of fitness functions went down badly with the participants: beyond illustration there is little use in them.

What is worth keeping is that functions can be triggered, run continuously or run by hand, and that piling everything into one framework is a bad idea. One participant supplies the practice: around 2019 a colleague of his responsible for several teams wrote a small framework with a DSL for describing rules. A vulnerability turns up, you add a rule with a one-week deadline, the pipeline spends the week issuing warnings and then refuses to let you release until the dependencies are bumped. But an automated check, he stresses, needs a link that explains the reasoning and real communication with people. The chapter on incremental change rests on a single example, a rating service that gets dissected almost three times over. The authors suggest automatically taking a service with no traffic out of production; the participants are sceptical, because without deadlines the old service stays on as a zombie, and if there are not two consumers as in the picture but two thousand, nobody knows how long it takes. The deployment pipeline goes by quickly: atomic fitness functions after the functional tests, holistic ones closer to production, feature flags, and scepticism about Pact, which sounds great and fades fast in real life. Chapter four comes next time.