Architecture rarely decays because teams stop caring. It decays because change starts accumulating faster than the system can absorb it. This chapter shows how to make evolution deliberate instead of hoping one good diagram will survive production forever.
The strongest part is the way it ties incremental change, fitness functions, connascence, architectural quantum, and database evolution into one operating model. That helps teams decide which constraints should be executable, where coupling has become too expensive, and how to change the system without losing delivery cadence.
In reviews and interviews, the chapter helps you discuss more than the target architecture. It gives you a way to explain how the design stays healthy after launch: which rules must be enforced, how degradation gets noticed, and why good architecture needs ongoing discipline.
Practical value of this chapter
Fitness functions
Shows how to convert architecture principles into measurable automated checks.
Controlled change
Helps roll out architecture changes incrementally without breaking delivery cadence.
Coupling visibility
Makes dependency hotspots visible before they become expensive change bottlenecks.
Interview differentiation
Strengthens interview answers with a practical strategy for keeping architecture evolvable.
Source
CoA Book Club
This chapter draws on the Code of Architecture book club recap of the book.
Building Evolutionary Architectures, 2nd Edition
Authors: Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
Publisher: O'Reilly Media, Inc.
Length: 262 pages
Fitness functions, connascence, architectural quanta, and database evolution as a practical framework for controlled architecture change.
Here, evolutionary architecture means the ability to keep changing a system without losing control over its quality, boundaries, and delivery pace. The book ties incremental change, fitness functions, coupling, connascence, architectural quanta, and database evolution into one practical operating model.
That makes the material useful far beyond the target diagram. It helps explain which constraints should become executable checks, where change cost is already too high, and how to move a system safely from one state to the next.
Related book
Fundamentals of Software Architecture
Baseline architecture framing around characteristics, styles, and decision-making.
What evolutionary architecture is
Evolutionary architecture = incremental change + fitness functions + appropriate coupling
Incremental change
The architecture should support small, frequent changes instead of rare, high-risk leaps.
Fitness functions
Important constraints are turned into checks that can actually be run, not just described.
Appropriate coupling
Components stay connected only to the degree that helps the system evolve rather than slowing change down.
Related book
Continuous Architecture in Practice
A practical continuation of the same idea: constant feedback and architecture as an ongoing process.
Fitness functions
A fitness function is an objective way to tell whether the architecture still stays within acceptable boundaries. The term comes from genetic algorithms, but here it simply means a repeatable check that guards an important architectural property as the system evolves.
Types of checks
- Atomic — validate a single constraint, such as a dependency rule or one measurable budget.
- Holistic — evaluate several properties together when the combination matters.
- Triggered — run on a commit, build, deploy, or another delivery event.
- Continuous — stay active through monitoring and operational feedback.
Implementation examples
- Performance — load testing in CI/CD and latency budgets.
- Security — SAST/DAST scanning, dependency audit, and banned configurations.
- Modularity — layer rules, dependency checks, and tools like ArchUnit.
- Resilience — chaos experiments and recurring failure-mode validation.
Key idea
Once these checks are embedded in delivery and operations, architecture guidance stops being aspirational. It becomes an executable specification that can catch degradation automatically.
Related book
Software Architecture: The Hard Parts
A deeper treatment of coupling, connascence, and architectural quanta in distributed systems.
Coupling and connascence
The book refines the usual discussion of coupling with the idea of connascence. That gives teams a more precise way to talk not just about the existence of a dependency, but about the strength of the requirement to change together.
Static connascence (weaker)
- Name — the same names must stay aligned across components.
- Type — the same contracts and types must be preserved.
- Meaning — constants and values must mean the same thing.
- Position — parameter order matters and must remain aligned.
- Algorithm — multiple parts depend on the same computational logic.
Dynamic connascence (stronger)
- Execution — behavior depends on step ordering.
- Timing — behavior depends on precise timing relationships.
- Values — several parts depend on coordinated values.
- Identity — components share the same object or state.
Rule: keep weak connascence between modules and allow strong connascence only inside them. The stronger the requirement to change together, the closer those elements should sit.
Architectural quantum
An architectural quantum is the smallest independently deployable part of a system with strong functional cohesion. It includes everything required to operate: code, data, and infrastructure dependencies.
Monolith
One quantum covers the whole system.
Modular monolith
Still one quantum, but with explicit logical boundaries inside.
Microservices
Multiple quanta, each evolving more independently.
More quanta give teams more change autonomy, but they also raise operational complexity, observability cost, and coordination overhead.
Related book
Database Internals
A deeper look at DBMS design, replication, and distributed transactions.
Database evolution
Schema evolution is one of the hardest parts of evolutionary architecture. The book makes it easier to reason about ACID, BASE, and NewSQL trade-offs without defaulting to big-bang database rewrites.
The recommended approach is incremental migration: evolve the schema in small, compatible steps so multiple versions of the system can coexist safely while data is being moved.
ACID (RDBMS)
PostgreSQL, MySQL, Oracle
Strong consistency with an explicitly managed schema.
BASE (NoSQL)
MongoDB, Cassandra, DynamoDB
Eventual consistency and more flexible schema evolution.
NewSQL
Spanner, CockroachDB, YDB
ACID guarantees combined with horizontal scaling.
Expand-Contract pattern
The safe sequence is simple: expand the schema first, migrate data second, and only then contract the old structure. That keeps different application versions compatible during rollout and avoids downtime-heavy migrations.
Organizational aspects
Architecture is inseparable from organizational design. Conway's Law is a useful reminder that service boundaries, communication paths, and team boundaries eventually start to mirror one another.
The book also connects architecture change to DORA metrics. That shift is practical: it lets teams see whether their system is genuinely becoming easier to change, recover, and ship safely.
DORA metrics
- Deployment frequency — how often the team can ship safely.
- Lead time for changes — how long it takes to move from commit to production.
- Mean time to recovery — how quickly the team restores the system after failure.
- Change failure rate — how often deployments lead to incidents or rollback.
Decision types
- Irreversible decisions — language, database, and cloud choices. These deserve slower and more careful analysis.
- Reversible decisions — module structure, APIs, and interaction patterns. These are good candidates for experiments and staged change.
How to use the book in a system design interview
What to use
- Fitness functions help explain how the team will keep SLOs intact and notice degradation in latency, errors, and other quality budgets.
- Architectural quanta give you a concrete way to reason about service boundaries and the choice between a monolith, a modular monolith, and microservices.
- Expand-Contract gives you a safe strategy for schema migration without downtime.
- Connascence helps explain which parts truly need to change together and which should be separated.
Common mistakes
- Designing as if today's solution must remain untouched forever.
- Ignoring the future cost of change and focusing only on the current diagram.
- Forgetting organizational constraints and team boundaries.
- Choosing microservices without understanding their operational price.
Example answer
“For this case I would start with a modular monolith. That keeps the system at one architectural quantum and avoids unnecessary operational overhead. I would align module boundaries with bounded contexts so the team could later extract them into separate services without reshaping the domain. For performance, I would add a load test in CI/CD with a p99 < 200 ms threshold as a fitness function.”
Verdict
Strengths
- A practical frame for deliberate architectural evolution.
- Fitness functions can be adopted incrementally and measured clearly.
- The book connects technical choices to organizational consequences.
- It works especially well alongside the authors' related architecture books.
Limitations
- It offers fewer detailed implementation case studies than conceptual frames.
- Connascence can feel abstract on first read.
- The material becomes strongest when combined with the rest of the series.
Recommendation: this book is especially useful after “Fundamentals of Software Architecture” and “Software Architecture: The Hard Parts”. Together they provide a common language for architecture characteristics, boundaries, change cost, and managed evolution.
Sources
Related chapters
- What Software Architecture Is and Why It Matters in System Design - provides the broader architecture frame where evolution is treated as continuous engineering work rather than a one-off refactor.
- Fundamentals of Software Architecture (short summary) - builds the baseline on architecture characteristics and styles that fitness functions and controlled change rely on.
- Software Architecture: The Hard Parts (short summary) - extends the topic into decomposition, data boundaries, distributed trade-offs, and the cost of coupling.
- Continuous Architecture in Practice (short summary) - shows how to embed architecture checks and decisions into a continuous delivery flow.
- Evolutionary architecture in practice - adds a practical lens on change step size, degradation signals, and safe migration sequencing.
- Architecture at Scale: How We Make Architectural Decisions - translates the book into organizational routines with RFCs, decision records, decision logs, and lightweight governance.