Evolutionary Architecture in Practice

Incremental development helps teams test business hypotheses quickly and reduces the size of individual changes. Yet a sequence of small changes can gradually entangle code and service interactions. That may be acceptable for a disposable prototype, provided it is actually discarded. A maintained system needs checks that rapid iterations are not undermining the properties required for future development.

The author connects architecture not only with expensive-to-change decisions but also with the boundaries of a system's possible trajectory. Availability, maintainability, auditability, and other quality characteristics therefore matter alongside functionality. A new capability is useful only when it operates at the required quality level. Calling these requirements non-functional does not make them optional.

Fitness functions establish verifiable boundaries for architectural characteristics. They can combine tests, metrics, production monitoring, and alerts. Teams first identify the properties that matter and their acceptable values, then automate checks as frequently as practical, ideally for every change. Passing one test does not establish the suitability of the whole architecture; a coherent set of checks is needed.

Examples include ArchUnit for Java architecture checks, Danger for recurring change-review checks, and the internal Fitv tool. Fitv emerged while a monolith was being divided into dozens of services, so architectural compliance would not depend entirely on technical leads noticing violations. Such tools embed known constraints into everyday delivery, but the rules themselves must still reflect the needs of the particular system.

The discussion of modularity distinguishes cohesion within components from coupling between them. The Stable Dependencies Principle directs dependencies toward more stable components, while the Stable Abstractions Principle relates stability to abstraction. Two problematic extremes are highlighted: a stable component tied to concrete implementations and abstractions nobody uses. These models support architectural discussion beyond simply counting services.

Reasons to revisit architecture include software that is too large for one team, deteriorating delivery, and unnecessary complexity in the surrounding environment. Conway's law connects this work with how people collaborate. Architectural change may therefore require different team boundaries and platform support. Learning the approach involves both studying the principles and solving real system-evolution problems; familiarity with checking tools alone is insufficient.