⌘ The Architecture Reference

Fnd evolution · Foundations · Intermediate

Evolutionary Architecture

Architecture that supports guided, incremental change across multiple dimensions — and why evolvability is the meta-characteristic that protects all the others.

Fnd evolution Intermediate ⏱ 4 min read Complete

🚲 Analogy

Picture a unicyclist constantly rebalancing while you keep tossing boxes onto their load. That’s the software ecosystem — tools, frameworks, and practices in constant dynamic equilibrium. A fixed five-year architectural plan assumes the rider will hold still. An evolutionary architecture assumes they won’t, and builds in the ability to rebalance.

The definition

Building Evolutionary Architectures defines an evolutionary architecture as one that supports guided, incremental change across multiple dimensions. Each word carries weight:

graph TD
E["Evolutionary architecture"] --> G["Guided change<br/>(fitness functions steer it)"]
E --> I["Incremental change<br/>(small build + small deploy)"]
E --> M["Multiple dimensions<br/>(technical · data · security · operational)"]
  • Guided — fitness functions, borrowed from evolutionary computing, steer the architecture toward chosen characteristics and prevent their degradation.
  • Incremental — software is built in small increments and deployed incrementally (a new service version runs alongside the old; others migrate at their leisure; the unused version is garbage-collected).
graph LR
C["Consumers"] --> R["Router"]
R -->|"most traffic"| V1["Service v1"]
R -->|"canary"| V2["Service v2"]
V1 -. "drained, then GC'd" .-> X["retired"]
V2 -->|"becomes default"| D["v2 only"]
  • Multiple dimensions — evolution must consider not just technical architecture but data, security, and operational dimensions too. “There are no separate systems” (Donella Meadows).

Why “evolutionary”?

The term beats the alternatives. Adaptable implies jury-rigged patches that accrete complexity (a service bus that keeps adding parallel layers). Emergent is rejected outright: agility means no useless architecture, not no architecture — you can throw together a dog house with no design, but not a 50-storey building. “Evolutionary” captures both the incremental and the guided nature of genuine, fit-for-purpose change.

Evolvability is a meta-characteristic

The old definition of architecture as “the parts that are hard to change later” is a self-fulfilling prophecy you can escape — by building changeability into the architecture. Treat evolvability as a meta-characteristic: an architectural wrapper that protects all the other characteristics as the system evolves.

The book unifies two previously separate disciplines to achieve this: the engineering practices of Continuous Delivery (deployment pipelines, automation) and the structural design decisions that control coupling, cohesion, and reuse.

Structure determines evolvability

No architectural style inherently controls evolvability — the coupling characteristics a design supports do. The goal is appropriate coupling: restrict implementation coupling to the tightest scope to avoid brittleness (see connascence and the architecture quantum). Microservices partition along the domain dimension, so a domain concept like Checkout doesn’t smear across layers — giving each bounded context real evolvability.

Two recurring questions answered

How is long-term planning possible when everything changes? — Build changeability in, so the architecture can absorb shifts. How do I stop an architecture from degrading? — Protect it with fitness functions. Together these turn “hard to change” from a fate into a choice.

⚠️ When NOT to evolve

You can’t easily evolve a Big Ball of Mud (rework may exceed a rewrite — the neglected “-ility” here is feasibility). Skip evolutionary investment when another characteristic dominates, you intend a sacrificial architecture, or you’re planning to close the business soon.

💡 Key insight

“All architectures become iterative because of unknown unknowns; agile just recognises this sooner.” Prefer evolvable over predictable — you cannot design for what you can’t yet foresee, so build the system to absorb the surprise.

See also

When to use it — and when not

✅ Reach for it when

  • When business needs and the technology ecosystem will keep shifting under the system
  • When you want to escape the definition of architecture as 'the parts that are hard to change'
  • When planning for unknown unknowns rather than a fixed five-year design

⛔ Think twice when

  • When the system is a Big Ball of Mud — rework may exceed a rewrite
  • When another characteristic dominates, you intend a sacrificial design, or the business is closing soon
fnd-evolutionFitness Functions

Objective, automatable integrity checks for architecture characteristics — the categories they fall into, and how they turn governance from aspiration into enforcement.

fnd-evolutionIncremental Change and Data

How deployment pipelines, feature toggles, and database evolution patterns let an architecture change in small, safe, reversible steps — including the hardest dimension, data.

fnd-componentsConnascence

A precise vocabulary for HOW two components are coupled — static vs dynamic connascence — and the three properties that guide refactoring toward weaker forms.

Check your understanding

Score: 0 / 4

1. How do the authors define an evolutionary architecture?

The definition is precise: guided (fitness functions) + incremental (small build and deploy) + multiple dimensions (technical, data, security, operational).

2. What makes change 'guided' rather than just frequent?

Guided change uses fitness functions, borrowed from evolutionary computing, to keep the system fit for its characteristics as it changes.

3. Why do the authors reject 'emergent architecture'?

You can throw together a dog house with no architecture, but not a 50-storey building; agility removes useless architecture, not architecture itself.

4. Evolvability is best described as…

Treating evolvability as a meta-characteristic lets the architecture protect every other characteristic over time.

Comments

Sign in with GitHub to join the discussion.