The engineering problem
Architecture must preserve important system qualities while requirements, teams, and technologies change. Fowler contrasts the older assumption that architecture should be completed before implementation with an evolutionary view in which architecture remains active work. The difficult part is retaining direction without pretending the future is knowable.
The approach
The source emphasizes small changes and feedback loops. That pairing matters: small changes reduce the cost of being wrong, while feedback reveals whether the system is moving toward or away from its intended qualities. An evolutionary architecture therefore needs observable constraints—tests, dependency rules, performance budgets, operability standards, or other fitness functions—not just flexible code.
Tradeoffs
Evolution lowers the cost of uncertainty but can increase local inconsistency when teams lack shared constraints. Strong up-front design remains appropriate for irreversible boundaries, regulatory obligations, safety properties, and expensive data contracts. The tradeoff is not design versus no design; it is where to commit early and where to preserve options.
What generalizes
Design decisions should state what they protect, how that property will be measured, and what evidence would justify changing direction. Architecture reviews become more useful when they produce a feedback mechanism rather than a static diagram.
What is context-dependent
The pace and safety of evolution depend on test coverage, deployment automation, observability, ownership, and reversibility. A team without those capabilities cannot copy the technique by vocabulary alone.
Architecture review questions
- Which decisions are difficult to reverse, and which can remain provisional?
- What automated signal tells us an architectural quality is degrading?
- How small can the next architectural change be?
- Who owns responding when a fitness signal fails?
The source provides the framing; the implications and review questions above are my synthesis.