What is evolutionary architecture?

About this site

This site is a practical introduction to evolutionary architecture for people working in, or moving into, cloud platform and enterprise architecture roles. It summarises and applies ideas from the books and articles listed in the reading list. It’s a learning aid, not a substitute for them, so check the primary sources before relying on a detail. Spotted a mistake? Use the Edit page link at the bottom of any page.

Definition

The term comes from Building Evolutionary Architectures by Neal Ford, Rebecca Parsons, Patrick Kua, and (in the 2nd edition) Pramod Sadalage, all from Thoughtworks at the time. Their definition:

An evolutionary software architecture supports guided, incremental change across multiple dimensions.

Each part of that sentence does work:

Part	What it means	How you see it in practice
Guided	Change is steered toward goals by objective checks, not by an architect’s personal approval.	Fitness functions in pipelines and in production.
Incremental	Change happens in small steps, both in how you build and how you deploy.	Continuous delivery, small batches, feature toggles.
Multiple dimensions	Architecture isn’t just code structure. It includes data, security, operability, cost, and team structure.	Fitness functions per characteristic, evolving data, Conway’s law.

Why it exists

Traditional architecture assumed you could decide the important things up front and that those decisions would stay stable. That breaks down because of what the book calls the dynamic equilibrium of the software ecosystem: languages, frameworks, cloud services, and business needs all keep changing, and they change each other. A decision that was right two years ago can be wrong now without anyone having done anything wrong.

The response is to stop treating architecture as a fixed plan and start treating it as something you protect while it changes:

1. Decide which architectural characteristics (the “-ilities”) actually matter.
2. Express them as objective, preferably automated, checks.
3. Make change small and frequent so you learn quickly and can back out cheaply.
4. Keep coupling appropriate so that one change doesn’t force many others.

Key ideas to keep in mind

• Last responsible moment. Defer decisions until you have the most information, but not so late that you lose options. Cheap change makes deferring safer.
• Evolvability is a characteristic. It sits alongside performance, security, and so on. It has costs, and not every system needs much of it.
• Architecture is hard to change (by definition). The goal is to make more things easy to change, so that fewer decisions carry that weight.
• Conway’s law. Systems mirror the communication structure of the organisations that build them. Team design is an architectural lever (the “inverse Conway manoeuvre”). See Team Topologies and platform teams.
• Sacrificial architecture (Martin Fowler). It’s sometimes right to build something you expect to throw away, as long as you design for its replacement.

Key takeaway

Evolutionary architecture moves the architect’s job from deciding everything up front to defining what “good” means, automating the checks, and making change cheap. For a cloud platform, much of that lives in IaC, pipelines, and policy as code.