Architecting for Entropy

I recently read “Building Evolutionary Architectures” by Neal Ford, Rebecca Parsons, and Patrick Kua. The book is nearly a decade old, yet surprisingly little of it feels dated. Rather than introducing a radically new architecture style, it presents a collection of ideas into a philosophy around managing change and presents a set of patterns.

The central premise seems to be that good architecture is less about predicting the future and more about reducing the cost of adapting to it.

That sounds annoyingly obvious.  However, much of enterprise software development still behaves as though requirements are fixed, organizations are stable, and technology stacks are eternal.

Evolutionary vs Reactive

The distinction between adaptable and evolutionary felt unclear to me.  I found myself thinking in terms of tactical versus strategic.  Though, the general meaning is clear to me.  Reactive systems wait for pain or some kind of stimulus before changing. Adaptable systems are intentionally primed for change. Evolutionary systems assume change is constant and optimize around safely accommodating it.

Most systems do not exist in stable environments. APIs change. Organizations reorganize. Vendors disappear. Teams rotate. Databases metastasize. Entire technology categories become obsolete while the Jira ticket is still in grooming. Modern software engineering increasingly feels like a giant distributed systems problem.

Fitness Functions

The most interesting concept in the book is the “fitness function”. The idea appears inspired by evolutionary machine learning algorithms, where organisms survive based on measurable traits. A fitness function is simply an automated verification of some architectural property:

  • Latency thresholds
  • Dependency rules
  • Deployment constraints
  • Security policies
  • Coupling limits
  • Resiliency checks

The important part is not the mechanics. The important part is that architecture stops being merely documentation and becomes executable.

This line from the book made me laugh because it is painfully true:

Developers have a hard time remembering bureaucratic policies in the heat of coding.

Of course they do.  Developers are juggling abstractions, deadlines, outages, meetings, Slack messages, half-working CI pipelines, and existential dread caused by YAML indentation. Nobody is going to remember page 47 subsection 3.2 of the architecture governance PDF.

Automation scales. Human memory does not (at least my memory doesn’t).

Conway’s Law Applies

The book repeatedly reinforces Conway’s Law:

systems mirror organizational communication structures.

Architecture diagrams often pretend teams are rationally partitioned around clean domain boundaries. In reality, systems tend to form around:

  • Budgeting structures
  • Political authority
  • Operational ownership
  • VP’s who can’t or won’t share headcount

One practical insight from the book is that it is difficult to change what you do not own. This seems obvious, but it is frequently ignored in architecture discussions. A perfectly elegant technical solution is irrelevant if the organizational structure cannot support it.  The inverse is also true. A mediocre architecture with strong ownership and healthy communication can evolve surprisingly well.

Coupling: The Real Cause of Entropy

The strongest sections of the book focus on coupling.  Many coupling aspects are discussed:

  • Deployment coupling
  • Temporal coupling
  • Operational coupling
  • Data coupling
  • Organizational coupling (Conway’s Law again)

Modern distributed systems have an amazing ability to recreate distributed monoliths. Platforms end up paying the costs of a distributed system and a monolith while reaping a fraction of the benefits.

Shared databases are especially notorious for this. A shared schema often becomes the “One Ring” that rules enterprise architectures:

  • Impossible to destroy
  • Corrupting everyone who touches it
  • Somehow owned by nobody

The book strongly advocates event-driven architectures as a mechanism for reducing coupling. I found this compelling. Events create separation between producers and consumers and allow systems to evolve more independently. There are certainly ways to create catastrophic event-driven monstrosities too, but the architectural direction generally feels correct.

The book also leans heavily on Domain Driven Design. This makes sense because DDD is fundamentally about defining boundaries and vocabularies. Good boundaries are one of the few reliable defenses against architectural entropy and coupling.

Without boundaries, everything eventually becomes a “misc” folder, a “utilities” package, or a “big ball of mud”.  Which starts to resemble my junk drawer (I have several).

The Hegemony of Database Vendors

One of my favorite phrases in the book was:

the hegemony of database vendors.

There is something darkly funny about how often enterprise architectures become optimized around the limitations and licensing structures of database products. The database quietly becomes the true architecture while the services orbit around it pretending to be independent.

The authors discuss evolutionary database techniques like expand-and-contract migrations which allow schemas to evolve incrementally rather than through terrifying weekend cutovers involving pizza, exhaustion, and rollback plans nobody tested.  In this case, small reversible changes beat dramatic heroics.

Immutable Flexibility

Another interesting idea is that immutability often improves evolvability and flexibility.  At first glance this sounds paradoxical. But immutable infrastructure, immutable deployments, and append-only style thinking reduce uncertainty. Predictability makes systems easier to evolve because fewer hidden side effects accumulate over time.

The book also reinforces the old Mythical Man-Month concept:

plan to throw one away; you will anyway.

This is still difficult for organizations to accept because people become emotionally attached to architecture diagrams and product teams often don’t understand throwing away something that works (engineers struggle with this too). Unfortunately, the first version of almost anything primarily exists as a lesson in what works and what doesn’t. Trying to prematurely engineer the perfect future-proof architecture usually creates a rigid monument to incorrect assumptions and changing requirements.  

Reuse is Not Free

One section critiques excessive code reuse. This was refreshing because enterprise development historically treated reuse as an axiomatic virtue.

In reality, reusable code often becomes:

  • Harder to understand
  • More abstract
  • More coupled
  • Hinders independent development

Sometimes duplication is cheaper than coordination, is a statement that would probably horrify portions of the Java ecosystem. I’m not advocating against reuse, but we shouldn’t have an automatic reflexive aversion to duplication.

Engineers Need Contact With Reality

One section discusses connecting engineers directly with users. This strongly resonated with me.  When I worked in the defense industry, I often had little visibility into how systems were actually used. It made decision-making difficult because feedback loops were weak or nonexistent. Occasionally seeing the software in real operational environments was incredibly valuable.

By contrast, working on a public ecommerce platform is radically different. I can directly experience the product as a user and observe other users discussing frustrations and successes publicly. That feedback dramatically improves intuition around design and prioritization.

It is much easier to evolve systems when you can actually observe the organism interacting with its environment, or better yet, be part of the environment.

Architecture as Trade-offs

One thing I appreciated about the book is that it avoids presenting architecture as a collection of universal truths.

Everything is trade-offs:

  • Reuse vs independence
  • Consistency vs experimentation
  • Standardization vs adaptability
  • Simplicity vs flexibility

There is no final architecture. No ultimate framework. No silver bullet. No YAML file capable of transcending entropy; only choices with consequences.

Final Thoughts

The book occasionally stretches analogies too far. I was not especially fond of the “architecture quantum” terminology. It feels slightly forced and less precise than the underlying idea it tries to describe. Some sections also remain fairly high level and philosophical rather than deeply practical.

Still, the book succeeds because it frames architecture correctly.  Architecture is less about the pursuit of stability and more about the management of change.

Modern systems are incredibly interconnected, organizations too fluid, and technology too transient to optimize primarily for stability. The architectures that survive the longest are rarely the ones built to last forever. They’re the ones built to evolve.