Evolutionary Architecture: Because Change is the Only Guarantee

Bjarte Bogsnes, former CFO of Statoil, talked about the beauty of a perfectly balanced budget. But the feeling would only last for a fleeting amount of time because inevitably real world changes would mess up the perfect balance in the budget. The same is true of software architecture.

Architects design nice and neat architectures, but then expose them to the messy real world of product development. Developers slowly erode the architecture's integrity - they bypass carefully designed layers by making direct database calls from the UI, create circular dependencies between modules that should be independent, scatter business logic across UI components, and turn innocent "util" classes into massive dumping grounds of unrelated code.

Before long, what was once a clean, maintainable design becomes a tangled web of tight coupling, technical debt, and architectural violations that make the system increasingly difficult to maintain and evolve.

Some companies implement architectural reviews to prevent these problems, but they often become bureaucratic exercises that slow down development and fail to prevent the most serious issues that occur on a more day-to-day basis. Others use code reviews, but again, they rely on the diligence of people who are often time-constrained and under pressure to meet deadlines.

Embracing, Rather than Fighting, Change

There is another way of solving this problem. Neal Ford, Rebecca Parsons, and Patrick Kua wrote the book Building Evolutionary Architectures which advocates for designing architecture with change in mind. Software architecture should be treated as a living entity that evolves to meet shifting requirements, technologies, and business goals.

To achieve this, the authors introduce four key concepts: Fitness Functions, Incremental Change, Architectural Coupling, and Evolutionary Data.

1. Fitness Functions

Fitness functions are tests used to validate and measure how well a system meets its architectural goals and non-functional requirements (NFRs). These ‘invisible’ requirements, such as performance, scalability, security, reliability, and maintainability, are often forgotten as new features are added.

By embedding tests in the CI/CD pipeline, architects can be confident that the system will continue to meet its NFRs as it evolves.

2. Incremental Change

The architecture should encourage small, frequent, and safe changes rather than large, risky overhauls. This can be achieved by implementing automated tests, continuous delivery pipelines and production monitoring.

While outside of the remit of architecture, architects (and developers) should advocate for practices like Test Driven Design (TDD), which enable teams to refactor confidently and avoid big rewrites.

3. Architectural Coupling

Architectural coupling refers to dependencies between components of a system that affect their ability to change independently.

The approach to coupling depends on the core architecture of the system. In monolith architectures, layered or modular architectures enable separation of concerns. In event-driven architectures, brokers and mediators are more appropriate. And in service-oriented architectures, opt for service-based architectures rather than single Enterprise System Bus architectures that have a massive “architectural quantum” (the system bus) because this makes evolutionary changes difficult.

4. Evolutionary Data

Traditional data architecture often becomes a bottleneck for change due to its rigid, monolithic nature. Schema changes are difficult because the data is shared acorss the code base which makes the ‘blast radius’ large and, more challenging, uncertain. People avoid changes out of fear of breaking something.

Architects should consider patterns that maintain database independence while still allowing necessary data sharing through expand/contract patterns, service-based architectures with clear data boundaries, or messaging patterns rather than direct database sharing.

Final Thoughts:

Building Evolutionary Architectures challenges traditional notions by embracing change and uncertainty as constants. It provides actionable frameworks, tools, and case studies to help architects, developers, and organisations build systems that are future-proof, resilient, and aligned with modern development methodologies.

By focusing on fitness functions, incremental delivery, loose coupling and evolutionary data practices, this book provides a roadmap for creating systems that evolve in tandem with business and technological landscapes.