Building Evolutionary Architectures: Support Constant Change is a book published in 2017 by Neal Ford, Rebecca Parsons, and Patrick Kua — all of ThoughtWorks — which proposed that software architecture should not be decided on day one and defended until death, but should evolve continuously in response to actual requirements, guided by automated fitness functions that verify the architecture remains fit for purpose as it changes.
This is, stated plainly, Gall’s Law applied to architecture, Refactoring applied to structure, and common sense applied to an industry that had spent twenty years treating architecture diagrams as sacred texts — laminated, signed off by committee, and defended with the fervor of a medieval theologian protecting scripture from translation.
The book said: your architecture will change. Plan for that. Not by predicting the future, but by building systems that can become what the future requires. The enterprise architects heard this and felt the specific chill of a profession being told that its primary artifact — the finalized architecture diagram — was not merely impermanent but should be impermanent.
The Core Idea
The book’s thesis is deceptively simple: an evolutionary architecture supports guided, incremental change across multiple dimensions.
Three words do the heavy lifting:
Guided — not random change, not “move fast and break things,” but change directed by fitness functions that define what “good” means for this system. Does the response time stay below 200ms? Does the coupling between modules stay below threshold? Does the deployment take less than fifteen minutes? These are fitness functions. They are automated. They run continuously. They tell you whether the architecture is still fit after you changed it.
Incremental — not Big Bang rewrites. Not the five-year technology roadmap. Small changes, verified by fitness functions, deployed continuously. The architecture evolves the way a city evolves — one building at a time, one street at a time, with zoning laws (fitness functions) ensuring the city remains livable as it changes.
Multiple dimensions — architecture is not one thing. It is performance. It is security. It is scalability. It is maintainability. It is operability. It is data integrity. Each dimension has its own fitness function. The architecture that optimizes for one dimension while ignoring the others is not evolutionary — it is collapsed.
Fitness Functions
The fitness function is the book’s central invention, and the concept that separates evolutionary architecture from “we’ll refactor later” (which means “we won’t refactor ever”).
A fitness function is an objective, automated measure of how well the architecture serves a specific quality attribute. Examples:
- Performance: average API response time < 200ms (measured by load tests in CI)
- Coupling: no circular dependencies between modules (measured by static analysis)
- Deployability: time from commit to production < 15 minutes (measured by the pipeline itself)
- Security: no known CVEs in dependencies (measured by dependency scanning)
- Data integrity: all database migrations are reversible (measured by migration tests)
The fitness function is not a dashboard that someone checks quarterly. It is an automated test that runs on every commit, in the same pipeline as unit tests and integration tests. If the architecture degrades — if coupling increases, if response time creeps up, if the deployment gets slower — the fitness function fails. The build goes red. The architect does not need to schedule a review meeting. The meeting is automated. The meeting runs in CI. The meeting takes thirty seconds.
This is the insight that makes evolutionary architecture practical rather than aspirational: you can evolve the architecture only if you can verify the architecture. Without fitness functions, “evolutionary architecture” is just “architecture that drifts.” With fitness functions, it is architecture that changes under supervision — guided evolution rather than random mutation.
The ThoughtWorks Connection
The three authors are all ThoughtWorks alumni, which places the book in a specific lineage: Martin Fowler’s Refactoring, the ThoughtWorks Technology Radar, the Continuous Delivery movement, and the general ThoughtWorks philosophy that the correct time to improve something is now, not Q3.
This lineage matters because it explains the book’s tone: practical, empirical, suspicious of grand theories. The book does not propose a new architecture. It proposes a way of thinking about architecture that makes the specific architecture less important — because if the architecture can evolve, the initial choice is a starting point, not a commitment. You do not need to get it right on day one. You need to get it evolvable on day one.
This is ThoughtWorks’s consistent message across thirty years: the code will change, the architecture will change, the requirements will change, the business will change. The question is not whether change will happen. The question is whether your system can absorb it without a rewrite.
“A complex system that works is invariably found to have evolved from a simple system that worked.”
— Gall’s Law, which Ford, Parsons, and Kua operationalized with fitness functions
The Enterprise Architect Problem
The book is, under its measured tone, a devastating critique of a specific role: the enterprise architect.
The enterprise architect, as practiced in large organizations, is a person who draws diagrams. The diagrams are comprehensive. The diagrams are laminated. The diagrams are presented in a 47-slide deck to a steering committee. The steering committee approves the diagrams. The diagrams become The Architecture. The Architecture is finalized. The Architecture is defended.
Then requirements change. The market shifts. A regulation is introduced. A competitor launches something unexpected. A technology that didn’t exist when the diagrams were drawn becomes essential.
The Architecture cannot accommodate this, because The Architecture was designed to be correct, not evolvable. The enterprise architect’s response is not to evolve the architecture. It is to schedule a review. The review produces new diagrams. The new diagrams are laminated. The cycle repeats. The architecture is always one laminated diagram behind reality.
Ford, Parsons, and Kua did not say “enterprise architects are unnecessary.” They said something worse: enterprise architects are structurally incentivized to resist the very change their systems must accommodate. The enterprise architect’s artifact is the diagram. The diagram’s value comes from being finalized. Evolutionary architecture’s value comes from never being finalized. The two are incompatible.
The book proposed an alternative: instead of a person who draws the final architecture, have fitness functions that verify the current architecture. Instead of a laminated diagram, have an automated suite. Instead of a steering committee that approves changes, have a CI pipeline that validates them. The architecture is documented not in slides but in tests. The tests run on every commit. The slides gather dust.
The enterprise architects read the book. Some of them evolved. Some of them laminated their response.
Conway’s Law, Operationalized
The book’s treatment of Conway’s Law is perhaps its most practical chapter. Conway’s Law states that organizations design systems that mirror their communication structures. Ford, Parsons, and Kua take this further: if you want to evolve the architecture, you may need to evolve the organization.
This is uncomfortable. Architects can change code. Architects cannot change org charts. The org chart is defended by people whose titles depend on the org chart staying the way it is. Proposing that the team structure should change to enable the architecture to evolve is, in most organizations, a career-limiting move.
The book acknowledges this with the restraint of ThoughtWorks consultants who have seen many org charts and survived: you cannot evolve the architecture independently of the organization. If the architecture needs a new module boundary, and the org chart has a team boundary in a different place, the org chart will win. Conway’s Law always wins. The question is whether you fight it or use it.
Evolutionary architecture uses it: align the teams with the architectural boundaries. Give each team ownership of a module with a clear fitness function. Let the teams evolve their modules independently, as long as the fitness functions pass. The architecture evolves because the teams evolve. The teams evolve because they own something small enough to change.
This is, in practice, what Amazon calls “two-pizza teams” and what Brooks called “surgical teams” fifty years earlier. The label changes. The principle doesn’t: small teams, clear boundaries, local ownership, global verification.
The Evolvability Spectrum
The book introduces a useful heuristic: architectures exist on a spectrum from static (designed once, changed never) to evolutionary (designed to change, verified continuously).
Most enterprise architectures sit at the static end — not because they were designed to be static, but because they lack the fitness functions that would make evolution safe. Without automated verification, every architectural change is a risk. Risks require meetings. Meetings require approval. Approval requires committees. Committees require slides. By the time the slides are laminated, the market has moved, and the architecture needs a different change.
The evolutionary end of the spectrum is not chaos. It is more disciplined than the static end — it requires fitness functions, continuous integration, automated deployment, clear module boundaries, and the organizational maturity to let teams change things without a committee. The paradox of evolutionary architecture is that it requires more engineering rigor than static architecture, while appearing to require less planning. The planning is not absent. It is embedded in the fitness functions. The planning runs on every commit.
What It Doesn’t Say
The book’s greatest virtue is restraint. It does not say “microservices.” It does not say “Kubernetes.” It does not say “event-driven architecture” or “serverless” or any other specific architectural style. It says: whatever architecture you choose, make it evolvable. If your monolith has fitness functions and can be incrementally changed, your monolith is evolutionary. If your microservices have no fitness functions and cannot be changed without a steering committee, your microservices are static.
This is the distinction the industry consistently misses: evolutionary architecture is not an architecture. It is a property of an architecture. A property that must be built, verified, and maintained — the same way performance is not an architecture but a property that must be measured and protected.
The best architecture is not the one on the laminated diagram. The best architecture is the one that can become the next architecture — guided by fitness functions, evolved by small teams, verified on every commit, and never, ever finalized.
