The first edition of Building Evolutionary Architectures arrived in 2017 with a great idea — the fitness function — and a book that was too thin to do the idea justice. The second edition, published in 2022, is the book the first edition wanted to be. It is roughly fifty percent longer, it is structurally clearer, and the fitness-function concept gets the treatment it needs to actually be usable in practice.

The premise is straightforward: instead of trying to specify the perfect architecture up front, define a set of fitness functions that continuously evaluate whether the architecture still meets its characteristics. The architecture is then free to evolve, as long as the fitness functions are still satisfied. Architecture becomes a stewarded property of the system rather than a one-time deliverable.

This sounds obvious. It is not obvious in practice, which is why the book is necessary.

What is new in the second edition

Three things stand out.

Fitness functions get worked examples. The first edition introduced the term and gave a handful of toy examples. The second edition gives you concrete fitness functions for performance, security, scalability, data integrity, and deployability, with discussion of how to implement them as automated checks, how to integrate them into CI, and how to distinguish atomic from holistic fitness functions. This is the part of the book I have actually used.

Architectural quanta get the treatment they need. The “quantum” — a deployable unit with high functional cohesion and an independently managed contract surface — is the unit the book uses to talk about microservices without saying “microservices.” The second edition is clearer about when a quantum is and is not a microservice, and the discussion of data quanta is a useful counterweight to the service-only framing most microservices books default to.

The pitfalls and anti-patterns chapter is much longer. The first edition was light on what not to do; the second edition is honest that most “evolutionary architecture” programmes fail in predictable ways, and names them. The honesty is welcome.

What I keep coming back to

The fitness-function framing has done more for my architecture-review practice than almost any other concept. The reason is this: a fitness function is a cheque you can cash. An architectural principle without a fitness function is a wish. An architectural principle with a fitness function is a constraint the system actually has to honour.

Once you have written one fitness function — say, a CI check that fails the build if a new service depends on more than three other services — you start seeing where the rest of your “principles” should also be fitness functions. Most of them, it turns out. The ones that cannot be expressed as fitness functions are usually the ones that were never load-bearing.

What the book gets less right

The treatment of data architecture is better than the first edition’s but still light. Pramod Sadalage’s voice is the right voice for this material, but the data chapters feel constrained by the broader architecture framing. The book occasionally talks about data as if it were just another type of service, which it is not. For the deeper data-system reasoning, you still want Designing Data-Intensive Applications.

The book is also slightly under-developed on how to introduce fitness functions into an existing system. Most readers will not be greenfielding an architecture from scratch. The “start with the most critical characteristic and write one fitness function” guidance is correct but unsatisfyingly brief.

How it pairs with the agentic-AI material

This is the interesting question for 2026. Agentic systems are fundamentally evolutionary architectures whether the architect intends them to be or not — the agents change behaviour as models update, context shifts, and tool definitions evolve. Fitness functions are arguably the only way to keep agentic systems honest over time. You cannot specify their behaviour exhaustively; you can only specify properties their behaviour must continue to satisfy.

The book does not address this directly. But the framing transfers almost without modification, which is the highest compliment I can pay a 2022 book. Read it alongside Agentic Architectural Patterns and the pairing is more useful than either book alone.

Reading note

The book is long (around 450 pages in the second edition) but heavily diagram-driven and easy to read in chunks. The chapter on testing fitness functions deserves a second read with your laptop open; the examples translate fairly directly into the major CI systems with minimal effort.

Who I’d give this to

  • A staff or principal engineer who keeps writing “architectural principles” documents that no one references.
  • A platform team lead who needs to enforce architecture properties without becoming a bottleneck on every PR review.
  • An EA who has been asked to “modernise” a legacy estate and needs a vocabulary for the gradual-replacement approach.
  • Anyone who has read the first edition and felt under-served by it; the second edition is materially better.

I would not give it to an architect who is just looking for a list of microservices patterns. The book is at a higher level of abstraction. For pattern catalogues, look elsewhere.

What it changed for me

It changed what I write when I am asked for an “architecture decision record.” I now try to include, in every ADR, at least one fitness function — even a manual one with an explicit review cadence — that will tell us whether the decision is still correct in six months. The ADRs that have fitness functions attached have outlived the ones that do not, by a substantial margin.

Bottom line

The second edition is the book the first edition should have been. The fitness-function concept is the single most useful architectural vocabulary addition of the last decade. Read it. Then, if you are working on anything agentic, read Agentic Architectural Patterns. The framings rhyme more strongly than either book intends.