• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : System design accommodates ongoing adaptation

Purpose and Strategic Importance

This standard ensures systems are intentionally designed to evolve in response to change, learning, and emerging needs. Rather than rigid, one-off architectures, teams build modular, testable, and adaptable systems. This approach enables agility at scale, allowing confident response to shifting priorities, technological evolution, and organisational change.

It supports policies to “Architect for Change” and “Elevate Agility Beyond the Team Level” by embedding adaptability into the technical foundation. Without this focus, systems become brittle, tightly coupled, and costly to modify—slowing delivery and increasing risk as complexity grows.

Strategic Impact

  • Reduces cost and effort needed to change direction
  • Accelerates delivery speed and time-to-value
  • Enables independent evolution of system components
  • Minimises risk of rework or technical failure during change
  • Aligns architecture with product and organisational agility

Risks of Not Having This Standard

  • Systems become difficult and risky to evolve over time
  • Minor changes require large, expensive refactoring efforts
  • Teams are constrained by architectural rigidity and coupling
  • Innovation is stifled by fear of destabilising core systems
  • Technical debt accumulates faster than it can be addressed

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture - Systems built solely for current requirements.
- Change is feared or actively resisted due to fragility.
Process & Governance - Architectural decisions are isolated and untracked.
- No fitness assessments for change readiness.
Technology & Tools - Systems are tightly coupled, monolithic, and hard to test.
Measurement & Metrics - No metrics on changeability, modularity, or flexibility.

Level 2 – Managed

Category Description
People & Culture - Growing awareness of future needs influences design.
- Change is planned but often costly and disruptive.
Process & Governance - Occasional maintainability or adaptability assessments.
- Design reviews consider future growth sporadically.
Technology & Tools - Some modularisation and interface abstraction introduced.
Measurement & Metrics - Informal discussion of change effort or rework post-delivery.

Level 3 – Defined

Category Description
People & Culture - Teams routinely consider impact of change in design discussions.
- Shared culture valuing adaptability.
Process & Governance - Architecture reviews include design-for-change principles.
- Early prototyping/testing of changes.
Technology & Tools - Systems are componentised with clear interfaces and boundaries.
- Automated tests support refactoring.
Measurement & Metrics - Metrics on design churn, modularity, and code ownership are tracked.

Level 4 – Quantitatively Managed

Category Description
People & Culture - Design decisions informed by historical change data.
- Change impact analysed to reduce coupling.
Process & Governance - Change readiness formally assessed prior to architectural sign-off.
- Shared standards reinforce adaptability.
Technology & Tools - Use of architecture fitness functions and change impact simulations.
Measurement & Metrics - Change lead time, modification frequency, and rework trends quantitatively measured.

Level 5 – Optimising

Category Description
People & Culture - System design treated as a living structure evolving continuously.
- Feedback loops actively shape architecture.
Process & Governance - Continuous architectural review and refinement based on delivery signals.
- Systemic retrospectives on design effectiveness.
Technology & Tools - Tooling enables dynamic dependency visualisation and automated refactoring.
Measurement & Metrics - Architecture adaptability, change throughput, and technical debt trends measured and optimised.

Key Measures

  • Average time and effort to implement changes in critical components
  • System modularity and boundary health indicators (e.g., coupling, cohesion)
  • Percentage of changes requiring cross-team coordination
  • Frequency and impact of architectural rework or revalidation
  • Architecture’s support for team autonomy and iterative delivery
Associated Policies
  • Architect for Change

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering