{"id":695,"date":"2022-11-03T11:44:25","date_gmt":"2022-11-03T11:44:25","guid":{"rendered":"https:\/\/infobip.com\/developers\/?p=695"},"modified":"2023-09-11T14:33:16","modified_gmt":"2023-09-11T14:33:16","slug":"evolutionary-architecture-book-review","status":"publish","type":"post","link":"https:\/\/www.infobip.com\/developers\/blog\/evolutionary-architecture-book-review","title":{"rendered":"Evolutionary Architecture\u00a0– book review"},"content":{"rendered":"\n

Intro<\/strong><\/h2>\n\n\n\n

I\u2019m a fan of short practical IT books, packing relevant information into a concise digestible form, without losing readability (Martin Fowler\u2019s UML Distilled<\/a> is one fine example). Having recently purchased a physical copy of Building Evolutionary Architectures<\/a> it was a pleasant surprise to be delivered a slim book, at less than 200 pages. A flight from London to our company HQ offered the ideal opportunity to discover what it had to offer. <\/p>\n\n\n

\n
\"Building<\/figure>\n<\/div>\n\n\n

Building Evolutionary Architectures was published in Oct. 2017 and is the work of three employees (some now ex-employees) of ThoughtWorks; Neal Ford, Rebecca Parsons & Patrick Kua. Despite being a collaborative effort the book remains fairly consistent in tone, albeit with some repetition, with each author contributing their own distinct perspective around a common core set of novel ideas. <\/p>\n\n\n\n

Need<\/h2>\n\n\n\n

Evolutionary Architecture outlines a different approach to software architecture better suited to the Agile era. Rather than impose a design, or simply try to let it emerge, a guided approach is advocated instead. Some useful contextual understanding & history of other approaches are also provided in the book. <\/p>\n\n\n\n

This history contrasts traditional approaches with the recommended evolutionary approach, establishing the underlying need. In addition, it explains why an evolutionary architecture approach was not previously possible.  In the last millennium, prior to the prevalence of open-source options & commodity hardware, software architects & developers were much more constrained by business cost (e.g., of proprietary licensed vendor solutions & expensive specialized hardware driving applications to share precious resources such as proprietary relational databases).<\/p>\n\n\n\n

At one architectural extreme lies the once-traditional approach of BDUF (Big Design Up Front). This takes the architectural metaphor borrowed from the building construction industry most literally,  expecting software architects to create a near-complete initial blueprint that provides an accurate solution prediction for subsequent implementation work to then slavishly follow. <\/p>\n\n\n\n

However, for most software endeavors the need to support ongoing change (e.g. respond to business threats & opportunities), makes this approach highly unreliable. Many of the predictions will simply be wrong since software development is a creative endeavor of design & discovery.  A number of significant challenges & changes simply cannot be reliably envisaged from the outset (and the cost of trying to uncover them is prohibitive or a foolish quest, since they aren\u2019t static).<\/p>\n\n\n\n

BDUF offers a false sense of certainty which often quickly evaporates as reality impinges. Plus, the shortcomings of design choices imposed too early often become apparent late on, when they are difficult, costly, or untimely to reverse or amend. <\/p>\n\n\n\n

At the other extreme lies a complete lack of perceptible architecture, such as from a \u201ccowboy (and\/or cowgirl?) coding\u201d<\/a> approach, that culminates in the BBoM (Big Ball of Mud)<\/a> anti-pattern. Rampant coupling between software units (e.g. classes) & data (e.g. via shared database tables) accumulates over time. Inexorably, this leads to a system that becomes harder to reason about & change. <\/p>\n\n\n\n

Even small changes can have far-reaching ripples of (often unforeseen) impact throughout the system. Developers become reticent to make all but essential alterations as a consequence as fear of change sets in.<\/p>\n\n\n\n

Ultimately, this culminates in a brittle system, where change becomes actively avoided & the softness of software becomes lost. Change becomes too expensive & slow to accommodate efficiently. Rigidity replaces the initial flexibility and the business pays the cost in terms of loss of competitive edge. <\/p>\n\n\n\n

Both these extremes are detrimental to any business fundamentally underpinned by software, plus disheartening to the software teams that must contend with them. <\/p>\n\n\n\n

In between these contrasting approaches, Agile Manifesto\u2019s Principles mention architectural emergence.  Specifically, principle #11 seem to advocate reliance on emergent design: <\/p>\n\n\n\n

\n

The best architectures, requirements, and designs emerge from self-organizing teams. <\/p>\n<\/blockquote>\n\n\n\n

However, as author Neal Ford points out, if you accept the notion of architecture as part of the important & hard to change choices, then you don\u2019t really want to rely purely on emergence as a driver for these.  Delayed choices are pragmatic, due to the cone of uncertainty & unknown unknowns, to reduce the early accumulation of hard-to-reverse choices. However, some choices are practically unavoidable initially (e.g. choice of programming language, frameworks\/libraries). Some skeletal outline from which to start is nearly unavoidable. <\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

In most current software implementation scenarios this book advocates Evolutionary Architecture.  This involves a guided selection of key architectural characteristics (e.g. good design, scalability, reliability), pertinent to the specific system under consideration, distinguishing this approach from the emergent alternative.<\/p>\n\n\n\n

Automated verification of these characteristics ensures their constant consideration & protection during ongoing development, in contrast to imposing specific implementation choices upon development teams & architectural governance from afar (without easy verification). <\/p>\n\n\n\n

Core Idea – Fitness Functions<\/strong> <\/h2>\n\n\n\n

At the heart of the book is the idea of using a suite of quantifiable tests to drive the evolution of a software system in a desirable direction. Furthermore, these tests protect those aspects from deterioration once set in place. The book dubs these fitness functions, in line with the evolutionary theme, borrowing more terminology from Biology.<\/p>\n\n\n\n

However, this is more akin to Artificial Selection \/ Selective Breeding<\/a> (e.g. dog breeding or farming selection of livestock & crops over successive generations) rather than Natural Selection<\/a> (non-human guided e.g. via environmental factors such as changing habitat) with variation (via mutation). <\/p>\n\n\n\n

Architectural fitness functions can be applied systemwide via a variety of approaches, such as automated tests (unit, integration, functional, etc.), software development metrics (e.g. cycle time), contract tests (e.g. Consumer-Driven Contracts for API<\/a>) and experiments running in production (chaos engineering<\/a>). <\/p>\n\n\n\n

Different types of fitness functions are presented, covering four categories, as outlined in the diagram below: <\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Enablers<\/strong><\/h2>\n\n\n\n

Evolutionary architecture is enabled by a set of supporting existing practices: <\/p>\n\n\n\n