← Back to principles

Architecture

Design for Change, Not Certainty

Statement

Design for Change, Not Certainty

What this means in practice

Architecture assumes change is inevitable. Systems are designed to be modular, loosely coupled, and adaptable, with clear boundaries that support independent evolution. Short-term trade-offs are made consciously, and technical debt is managed explicitly rather than allowed to accumulate silently.

Why this matters

Designing for change enables systems to evolve safely and deliberately as business needs, technology, and expectations shift. Without this, short-term decisions accumulate hidden risk and long-term cost. Systems become brittle, change feels dangerous, innovation slows, and even small enhancements require large rewrites or risky interventions.

Practices that meet this principle

  • Systems use well-defined interfaces and boundaries between components

  • Coupling between services or modules is minimised and made explicit

  • Technical debt is tracked, prioritised, and addressed as part of regular delivery

  • Architecture supports incremental change and safe experimentation

  • Design decisions consider future adaptability alongside immediate requirements

Validation

A project meets this principle when:

  • System components can be changed or replaced independently without cascading impact

  • Technical debt is explicitly tracked and managed

  • OR:

  • Short-term trade-offs are recorded with plans for resolution

Scoring Guide

  • Score −1 — Disagreement / Rejected: The team acknowledges this principle is applicable but has explicitly decided not to follow it for this product. A rationale and decision record exist explaining why designing for change is not adopted.

  • Score 0 — Not doing: Systems are monolithic or tightly coupled with no explicit boundaries. Technical debt is not tracked. No consideration of future adaptability in design decisions.

  • Score 1 — Planned: The team has committed work to adopt design-for-change practices. An owner and target date exist for introducing modularity, boundary definition, and technical debt tracking. The plan is tracked.

  • Score 2 — Adopted for new work: All new components use well-defined interfaces and boundaries. Technical debt is explicitly tracked and prioritised in the backlog. Short-term trade-offs are recorded with resolution plans. Architecture documentation identifies areas of anticipated change. Any exceptions are explicit and reviewed.

  • Score 3 — Enforced for new work + migration plan: Design for change is systematically enforced for all new work through process or tooling (e.g. architecture reviews, coupling checks). A tracked migration plan exists to decompose legacy monolithic or tightly coupled components and address existing technical debt.

  • Score 4 — Fully adhered: Components across all work (including legacy) can be changed or replaced independently. Technical debt is actively managed with regular reduction. Architecture supports safe experimentation (e.g. feature flags, canary deployments). Design decisions consistently account for future adaptability alongside immediate needs. Remaining gaps are minimal, known, and time-bound.