Evolutionary architecture becomes real not on slides, but when the product grows, teams split, and the cost of change starts slowing the business down. This chapter focuses on that exact transition from an attractive idea to an everyday engineering necessity.
Its practical value comes from linking customer growth, integrations, and organizational complexity to concrete choices: step size, change boundaries, coupling, fitness functions, and the signals that show when the current structure is no longer holding.
In architecture walkthroughs, it gives you pragmatic language for evolution: why not everything should change at once, how to choose a safe migration sequence, and why deferring a change can sometimes be as important as making it.
Practical value of this chapter
Adoption in practice
Shows how evolutionary approaches are applied in real product teams and delivery processes.
Change boundaries
Helps choose safe architecture step size and migration sequence.
Progress metrics
Teaches measurable signals for whether architecture change is improving the system.
Interview pragmatism
Provides practical language for what to change now, defer later, and why.
Source
Evolutionary architecture in practice
Analysis of Alexander Polomodov's talk: incrementality, fitness functions and coupling.
Evolutionary architecture is a practical way to manage the inevitable changes as the product grows, the team scales, and architectural decisions begin to impact the speed and quality of delivery.
Context: why the topic arises
Drivers of change
- Growth in customers and product lines increases the cost of change.
- More integrations between products → more dependencies and organizational complexity.
- Teams are divided into stream-aligned, the architecture follows the organizational structure (Conway's law).
Key Idea
Architecture should help change, and not turn into a stopping factor. Evolutionary architecture is about quality management in conditions of constant change.
What is architecture in this topic
Architecture as a set of important decisions
Decisions that are difficult and expensive to change, so they need to be made consciously.
Architecture as boundaries and trajectory
Determines not only the current device, but also the direction of development of the system.
What does "evolutionary" mean?
Video
Report: Evolutionary architecture in practice
Tinkoff Agile Conference 2021, Alexander Polomodov.
Incrementality
Small steps are easier to build, test and roll out.
Controllability
Changes must remain within specified quality boundaries.
Incrementality gives profit
- Build: Small changes are easier to implement and test.
- Deploy: Smaller deliveries are safer and roll out faster.
- Product: it’s easier to map business features onto architecture.
Three blocks of evolutionary architecture
Book
Building Evolutionary Architectures
Fitness functions, architectural quantum and the practice of architecture evolution.
Incremental Changes
We build the system so that changes are made small and frequent.
Fitness functions
Automated checks that keep your architecture in line.
Appropriate coupling
The connectivity between components allows them to evolve independently.
Visual evolution map
Flow of changes
Incremental Changes
Small changes are easier to make, test and roll out.
Fitness functions
Checks that maintain quality and limits.
Appropriate coupling
The components change independently, without a domino effect.
Formula
Incrementality + controllability
Without controllability, increments turn into spaghetti.
Guardrails
Incremental changes: yes, but...
Uncontrolled iterations turn the system into “spaghetti” - both at the code level and at the level of integrations between services. This is acceptable for a prototype, but the combat system requires frameworks.
Fitness functions and architectural characteristics
What is it
Architectural fitness function is a measurable test that confirms that the system remains suitable for changes within specified limits.
Characteristics
How to build frames
- Define architectural characteristics (…ility).
- Assign priorities and acceptable budgets.
- Translate budgets into tests, metrics, inspections.
- Automate and run in CI (each PR).
Tools from the report
- ArchUnit - architectural rules through unit tests (Java)
- Danger - automation of code review checks in CI
- Fitv / Fitness Validator - an internal tool for monitoring rules and technical debt
Coupling: how components “evolve”
Book
Clean Architecture
Principles of stability and abstraction for the evolution of components.
Stable Dependencies Principle (SDP)
Dependencies are directed towards more stable components.
Stable Abstraction Principle (SAP)
A component must be as abstract as it is stable.
Stability metrics
Ce - outgoing dependencies, Ca - incoming dependencies.
Main Sequence
Zone of Pain
Stable but specific components are painful to expand.
The Main Sequence
The balance of stability and abstraction is a healthy zone.
Zone of Uselessness
Unstable abstractions that no one uses.
When is it time to evolve?
Too much software for one team
The team does not keep the entire context - the number of manual agreements increases.
Delivery speed problems
Lead time increases, the share of blocking between teams increases.
Excessive cognitive complexity
Systems and processes require too much context to operate.
Architectural changes and team changes are connected: according to Conway's law, systems reflect the communications and structure of the organization.
What's next
- First, fix architectural characteristics and budgets.
- Add fitness functions to CI and team culture.
- Regularly review coupling and monitor Main Sequence.
- To go deeper: "Building Evolutionary Architectures" and "Clean Architecture".Read review
Related chapters
- What is software architecture and why is it in System Design? - sets the core architecture frame where evolution is treated as a continuous process rather than a one-time refactoring event.
- Building Evolutionary Architectures (short summary) - provides the systemic baseline on incremental change, fitness functions, and coupling that this talk applies in day-to-day engineering.
- Architecture at scale: how we make architecture decisions - shows how to operationalize architecture evolution through RFC/ADR, decision logs, and lightweight governance.
- Continuous Architecture in Practice (short summary) - extends the continuous-decision perspective and connects fitness functions to an everyday delivery loop.
- Clean Architecture (short summary) - complements the topic with stability and abstraction principles that support controlled component evolution.