Welcome to the third lesson in our module on Modern Architectural Thinking. In our previous discussions, we established the architect's new role as an enabler and introduced the "one-way vs. two-way door" framework for deciding which decisions to centralize and which to delegate. A key insight was that a strategic architect's goal is to make more decisions reversible—to turn one-way doors into two-way doors.
This naturally leads to our current topic. If we want to make decisions continuously and delegate them to teams, how does that work in practice? This lesson directly addresses the learning outcome: explaining architecture as a continuous activity embedded in the development process rather than an upfront design phase. We'll explore the concepts of Continuous and Evolutionary Architecture, moving from the "what" and "who" of decision-making to the "how" and "when."
The End of "Big Upfront Architecture"
For decades, software architecture was often treated like building architecture: a detailed blueprint was created upfront, and the development team's job was to implement it faithfully. This "Big Upfront Design" (BUFD) model is too slow and rigid for the modern world, where business needs and technology landscapes change at an incredible pace.
To adapt, the discipline has evolved. Let's start by reading a brief overview of this shift.
Continuous Architecture: A decade of designing for change
This article from ContinuousArchitecture.com explains the "why" behind this evolution.
Please read the first two sections, starting with "Sustainable, continuous delivery of value" and continuing through "Architecture's role today." Pay attention to the idea of architecture as a "continuous flow of decisions" and how this model responds to the demands of agility and DevOps.
As the article highlights, architecture has become a continuous activity performed by more people in smaller increments. This isn't chaos; it's a structured approach to managing change. The central idea is to stop trying to predict the future and instead build systems that can adapt to the future, whatever it may bring. This philosophy is most clearly articulated in the concept of "Evolutionary Architecture."
Evolutionary Architecture: Building for Change
Evolutionary Architecture is an approach that supports guided, incremental change across multiple dimensions of a system. To understand this mindset shift, let's hear from the authors who coined the term.
Building Evolutionary Architectures • Rebecca Parsons, Neal Ford & James Lewis • GOTO 2023
This clip from a GOTO Conferences panel features Rebecca Parsons, Neal Ford, and James Lewis, authors of "Building Evolutionary Architectures."
First, watch Rebecca Parsons define the concept from her initial explanation. Note the three key parts: guided, incremental change, and multiple dimensions. Next, listen to the discussion about the mindset shift required. People once saw architecture as a fixed foundation, but in a rapidly changing technology landscape, that's no longer a practical view.
The key takeaway is that we must accept that architecture will change. The question then becomes: how do we guide that change to ensure the system doesn't degrade over time? The answer lies in the "guided" part of the definition and introduces a powerful mechanism: architectural fitness functions.
Fitness Functions: Making Architecture Testable
A fitness function is a mechanism that provides an objective assessment of some architectural characteristic. Think of it as a unit test, but for an architectural concern like performance, security, or modularity.
This concept is the bridge between high-level architectural goals and the day-to-day reality of software development. It addresses the natural tension between development teams, who are incentivized to deliver features quickly (short-term), and architects, who are responsible for the system's long-term health (long-term).
Building Evolutionary Architectures • Rebecca Parsons, Neal Ford & James Lewis • GOTO 2023
Let's continue with the same panel discussion to understand how fitness functions resolve this conflict.
Watch the segment from "making these objectives" where the speakers explain how fitness functions force objective conversations about trade-offs. Instead of using vague words like "scalable," you define what scalability means in a measurable way.
By making architectural goals objective and automated, you embed them directly into the development lifecycle. This is the core of making architecture a continuous, living part of the system.
From Theory to Practice: How to Implement Fitness Functions
The idea of a "fitness function" might still seem abstract, but the implementation is very concrete and leverages tools and practices you are likely familiar with. Let's dive into a detailed presentation by Neal Ford that provides numerous practical examples.
Building Evolutionary Architectures • Neal Ford • YOW! 2018
This talk, "Building Evolutionary Architectures" by Neal Ford, is a masterclass in the practical application of these ideas.
First, watch the section that formally introduces architectural fitness functions. He draws the analogy from evolutionary computing and defines it as a mechanism for objective integrity assessment. Next, watch the segment on categories and examples. This is the heart of the talk. He provides concrete examples for different types of fitness functions: Triggered Atomic: Checking for cyclic dependencies between components or enforcing rules about how packages can interact. Consumer-Driven Contracts: A technique to ensure integration points between services don't break. Holistic Continuous: The famous Chaos Monkey from Netflix, which continuously tests the resilience of the entire architecture. Finally, focus on the section about automating governance with tools like ArchUnit. This is a powerful demonstration of how to turn an architectural principle, like "the presentation layer cannot talk directly to the data layer," into a test that runs with every build.
These examples show how you can codify your architectural intentions. Instead of documenting a rule in a wiki where it will be forgotten, you write a test that enforces it automatically. This gives your architecture "teeth" and ensures it doesn't decay over time as new features are added or developers join the team.
Techniques for Continuous Architectural Evolution
Fitness functions are the verification mechanism, but they are most effective when combined with development practices that enable safe, incremental change. Let's look at a few key techniques described in the "Agile Software Architecture" article.
Agile Software Architecture: Clean and Evolutionary - Wind4Change
This article from Wind4Change provides a great summary of the principles and techniques that support an evolutionary approach.
First, quickly review the section on "Emergent Design and Intentional Architecture." This describes the balance we're seeking: a high-level "Intentional Architecture" (the vision) guides the "Emergent Design" (the incremental changes made by developers). Next, read through the list of principles. Pay special attention to "Last responsible moment" and "Architect for testability." These are fundamental to embedding architecture in the development flow. Finally, review the section on "Evolutionary Architecture technics," focusing on Continuous Delivery and DB refactoring.
The technique of database refactoring is a perfect example of turning a "one-way door" into a series of "two-way doors." Traditionally, a major database schema change is a high-risk, all-or-nothing event. By breaking it into a series of small, version-controlled, and automated scripts that combine schema, data, and code changes, it becomes a manageable, continuous process.
The diagram below illustrates how such a process integrates seamlessly into a CI/CD pipeline, just like any other code change.
This is the essence of continuous architecture: making even the "hard parts" of the system subject to safe, incremental, and automated evolution.
Conclusion
In this lesson, we have fundamentally redefined architecture from a static blueprint to a dynamic, continuous process woven into the fabric of software delivery.
Key Takeaways:
- Modern software delivery demands that architecture be a continuous activity, not an upfront phase, to cope with the rapid pace of change.
- Evolutionary Architecture provides a framework for this, supporting guided, incremental change.
- The core mechanism is the architectural fitness function: an objective, often automated, way to verify that the system adheres to key architectural characteristics (e.g., performance, security, modularity).
- By codifying architectural rules as fitness functions (e.g., using tools like ArchUnit), you create "living" guardrails that prevent architectural decay and automate governance.
- This approach combines a high-level Intentional Architecture with the day-to-day Emergent Design, allowing for both strategic guidance and team autonomy.
Preview of the Next Lesson:
We now have a framework for continuously verifying our architectural choices. But how do we make those significant, "one-way door" decisions in the first place? In our next lesson, we will tackle this by learning how to apply a structured trade-off analysis framework to systematically evaluate and choose between competing architectural approaches.