Evolutionary architecture is defined as supporting guided, incremental change across multiple dimensions. Which concrete practices let a team change architecture incrementally while keeping confidence that nothing broke?

## The problem 'Evolutionary architecture supports **guided**, **incremental** change across **multiple dimensions**.' *Guided* = fitness functions steer the direction. *Incremental* = change lands in small deployable steps. *Multiple dimensions* = not just code — data, infrastructure, security, operations, and team structure all evolve. The practical question is how to change a running architecture without a freeze, a rewrite, or a nine-month migration project. ## 1. The deployment pipeline as the enforcement engine Continuous delivery is a prerequisite, not an optional companion. Each commit flows through stages: fast atomic checks (compile, unit, dependency/structure rules, secret and vulnerability scans), then integration and contract tests, then slower holistic ones (load with security enabled, resilience scenarios), then deploy. Because the whole fitness-function suite re-runs automatically, **incremental change becomes cheap to verify** — the cost of one more small step approaches zero, which is exactly what makes small steps viable. Rule of thumb: put fitness functions where their cost is justified. If a load test takes 40 minutes, it runs nightly or pre-release, not per commit; a dependency test taking two seconds runs everywhere. ## 2. Small, reversible steps Big-bang rewrites fail because feedback arrives only at the end. Incremental change means: - Each step is **independently deployable** and leaves the system working. - Each step is **revertible** — ideally by a flag flip or a redeploy of the previous artifact, not a data restore. - Steps are sequenced so value or risk reduction lands early. ## 3. Expand/contract (parallel change) for contracts and data The core technique for changing anything with consumers — an API, an event schema, a database table: 1. **Expand** — add the new form alongside the old (new column/field/endpoint/topic). Nothing breaks; old readers are untouched. 2. **Migrate** — write to both forms; backfill existing data; move readers one at a time, each in its own deployment. 3. **Contract** — once no consumer uses the old form (verified by telemetry, not by hope), delete it. This removes lock-step deployment: producer and consumers deploy on their own schedules. Its costs are a period of duplicated state, extra code to maintain both paths, and the very real risk of never reaching step 3 — so schedule the contraction explicitly. For databases specifically: **versioned, forward-only migrations** stored with the code, applied by the pipeline, each backward compatible with the previous application version so a rollback of code does not require a rollback of schema. ## 4. Consumer-driven contract tests Each consumer publishes the subset of the provider's interface it actually relies on; the provider's build verifies every published expectation. A breaking change fails the *provider's* pipeline before deployment, without needing all services in one environment. This is what makes independent evolution of distributed components safe, and it is itself an atomic triggered fitness function. ## 5. Separating deployment from release - **Feature flags**: deploy dormant code, enable it for a cohort, disable instantly on trouble. Flags are inventory — give each one an owner and an expiry, or the flag graph becomes its own architecture problem. - **Canary / progressive delivery**: route 1%, then 10%, then 100%, with automated rollback driven by error-rate and latency fitness functions. - **Dark launching / shadow traffic**: send real traffic to the new implementation without using its response, comparing outputs and latency. - **Strangler fig**: put a façade in front of the legacy system, route one capability at a time to the new implementation, and retire the old path when nothing routes to it. The system is never in a 'half-rewritten, unusable' state. - **Branch by abstraction**: introduce an abstraction over the component being replaced, add the new implementation behind it, switch, then remove the abstraction — enabling large internal replacement without long-lived branches. ## 6. Structural prerequisites - **Appropriate coupling.** Incremental change is only possible if a part can change alone. Fitness functions that enforce module boundaries are what keep that property alive. - **Architectural quantum thinking.** An independently deployable unit with high functional cohesion and its own data defines the true unit of change; if two 'services' share a database, they are one quantum and cannot evolve independently. - **Observability.** Metrics, logs, traces, and SLOs are how continuous fitness functions detect a bad step in production. - **Last responsible moment.** Defer decisions until the cost of deferring exceeds the cost of deciding; incremental change plus reversibility is what makes deferral affordable. ## Common failure modes - Fitness functions exist but the pipeline is slow, so people batch changes — killing incrementality. - Expand/contract stops after 'migrate', leaving permanent duplicate state. - Flags never removed; behaviour depends on an unauditable combination. - Data is treated as out of scope, so schema becomes the thing nobody dares change. - Reversibility assumed but never rehearsed — the first real rollback discovers migrations are irreversible.