A review of “Building Evolutionary Architectures” by Neal Ford, Rebecca Parsons and Patrick Kua. One section per chapter: the problem it solves, the key ideas, and a diagram.
Each chapter below carries two visuals: a diagram of the idea, and the original slide from the source deck (the deck is in Russian).
Core thesis: three pillars
An evolutionary architecture supports guided incremental change across multiple dimensions. The operative word is guided: the system does not drift, it changes under the control of automated checks.
The three pillars overlap, and they only work together:
| Pillar | What it gives you |
|---|---|
| Incremental change | iterative build and deployment |
| Fitness functions | protection of architectural characteristics |
| Appropriate coupling | architectural quanta and boundaries |
Chapter 1. Guarding against decay through multiple dimensions
The problem. Traditional long-term planning does not work. Systems decay (bit rot) because the ecosystem around them keeps shifting: frameworks, business requirements, scale.
Key ideas:
- evolvability is the new primary architectural characteristic;
- it is a meta-characteristic: a shell that protects every other property of the system;
- architecture must treat time as a first-class element.
Chapter 2. Fitness functions as an immune system
The problem. How do you objectively measure and protect critical characteristics — speed, security, resilience — when hundreds of developers change the code every day?
Key ideas:
- an objective assessment of system integrity; the term comes from evolutionary computing;
- categorised along two axes: atomic vs holistic, triggered vs continuous;
- identify the metric for every -ility up front, not after the fact.
Chapter 3. Engineering incremental change
The problem. Large changes are expensive and carry fatal risk. The result is a business that fears deployment, and release paralysis.
Key ideas:
- Small increments shrink the blast radius of a mistake.
- Hypothesis-driven development.
- Full automation of the routine through Continuous Delivery.
Chapter 4. Anatomy of the architectural quantum
The problem. Accidental coupling — a change in one place breaks the whole system through hidden dependencies.
Key ideas:
- an architectural quantum is the smallest independently deployable unit with high functional cohesion inside;
- a quantum always includes its database: transactional boundaries are the strongest form of coupling.
If the database is shared, it is no longer a quantum.
Chapter 4. Diagnostic matrix of styles
The problem. Picking the wrong architectural template — one that resists change and does not match the pace of the business (Big Ball of Mud, for example).
Key idea. Different styles carry a different built-in quantum size. The smaller the quantum, the faster and cheaper the change — but the higher the cost of running the infrastructure.
| Characteristic | Monolith | SOA | Microservices | Serverless |
|---|---|---|---|---|
| Quantum size | Large | Medium | Small | Micro |
| Coupling level | High | High | Low | Low |
| Incremental change | Hard | Hard | Easy | Easy |
| Fitness functions | Hard | Medium | Easy | Easy |
Chapter 5. Evolving data on a live system
The problem. The illusion that “database schemas live forever”. The database becomes a bottleneck and a point of rigid integration that blocks refactoring of the code.
Key ideas:
- data must evolve in lockstep with code;
- abandon Shared Database Integration;
- use the Expand/Contract pattern to migrate without downtime.
Chapter 6. The mechanics of building evolution
The problem. There is no clear, repeatable algorithm for designing a new system or refactoring a huge legacy codebase.
Key ideas:
- a strict three-step algorithm turns evolutionary architecture from an abstraction into a practice: identify the dimensions → define the fitness functions → automate them in the pipeline;
- isolating the old code is critical to the survival of the new — an anticorruption layer sits between legacy and the new services.
Chapter 6. Guiding principles and routing
The problem. Making “irreversible” architectural decisions that turn into technical debt and block further development.
Key ideas:
- make decisions reversible;
- evolvability > predictability;
- build sacrificial architectures you will not regret throwing away.
Chapter 7. Threat board: antipatterns and traps
The problem. Hidden systemic dysfunctions kill flexibility at the root, even when the team sits on modern frameworks.
Key idea. Recognise and destroy toxic patterns before they take root in the engineering culture.
| Antipattern | What it is |
|---|---|
| Vendor King | total dependency on a proprietary vendor. Fix: introduce an abstraction layer |
| Leaky Abstractions | infrastructure implementation details seep into business logic |
| Resume-Driven Development | hype technology adopted for the architect’s CV, needlessly complicating the quantum |
Chapter 8. The Inverse Conway Maneuver
The problem. Coordination hell. The company structure conflicts with the target architecture, so every release needs sign-off across departments.
Key ideas:
- Conway’s Law: architecture inevitably mirrors the communication structure of the organisation;
- Inverse Conway Maneuver: shape the teams exactly the way you want the target architecture to look.
Chapter 8. The economics of evolution: talking to the business
The problem. How do you justify to management — to the CFO — the money spent on engineering practices, refactoring and fitness functions?
Key ideas:
- a radical reduction in release risk;
- dramatically faster time-to-market;
- an unblocked culture of experimentation (kaizen).
Migration strategies: where to start
The problem. Analysis paralysis when facing a huge, historically tangled legacy monolith.
Key idea. Choosing the right starting point is critical: it must either cut risk quickly or demonstrate maximum value to the business.
| Strategy | What it is |
|---|---|
| Low-Hanging Fruit | quick wins: easy to extract, low value |
| Highest-Value | maximum business benefit: harder, but proves ROI |
| Infrastructure-first | automate the pipelines before anything else |
| Testing-first | cover the legacy with fitness functions before refactoring |
Final synthesis
The problem. Letting go of the “we will build this once, and build it to last” mindset.
Key idea. Evolutionary architecture is not a destination — it is a built-in survival mechanism. Three loops are braided into one: teams (Conway’s Law), architecture (fitness functions and quanta), pipelines (incremental change).
Stop building to last. Start building for change.