• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Systems are architected to minimise the cost of change

Purpose and Strategic Importance

This standard ensures systems are architected with modularity and adaptability in mind, enabling teams to make changes safely, quickly, and with minimal disruption. It promotes long-term agility and reduces the hidden cost of architectural debt.

Aligned to our "Architect for Change" policy, this standard supports scalable design, faster iteration, and technical resilience. Without it, change becomes costly, fragile, and a blocker to innovation.

Strategic Impact

Clearly defined impacts of meeting this standard include improved delivery flow, reduced risk, higher system resilience, and better alignment to business needs. Over time, teams will see reduced rework, faster time to value, and stronger system integrity.

Risks of Not Having This Standard

  • Reduced ability to respond to change or failure
  • Accumulation of technical debt or friction
  • Poor developer experience and morale
  • Decreased confidence in releases and features
  • Misalignment between technical implementation and business priorities

CMMI Maturity Model

  • Level 1 – Initial: Design choices are ad hoc; architecture frequently impedes change.

  • Level 2 – Managed: Some architecture practices reduce change cost, but consistency is limited.

  • Level 3 – Defined: Modular architecture principles are documented and adopted across teams.

  • Level 4 – Quantitatively Managed: Architectural decisions are driven by impact on change lead time and effort.

  • Level 5 – Optimising: Architecture is continuously evolved and informed by feedback loops and change data.


Key Measures

  • Adoption metrics relevant to the standard (to be defined)
  • Quality, throughput, and system health metrics aligned to capability
  • Maturity scores based on structured assessment
Associated Policies
  • Architect for Change
Associated Practices
  • CQRS (Command Query Responsibility Segregation)
  • Event-Driven Architecture (EDA)
  • GraphQL-first APIs
  • Hexagonal (Ports & Adapters) Architecture
  • Microservices Architecture
  • Modular Monoliths
  • Refactoring
  • Strangler Fig Pattern
  • API-first Design
  • Domain-Driven Design (DDD)
  • Strategy & Outcome Mapping
  • Value Stream Mapping
Associated Measures
  • Cycle Time
  • Technical Debt Ratio
  • Infrastructure as Code (IaC) Coverage

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

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