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

What are you looking for?

Standard : Domains are integrated through stable, loosely coupled interfaces

Purpose and Strategic Importance

This standard ensures systems are integrated through stable, loosely coupled interfaces-enabling teams to evolve domains independently without breaking changes. It supports resilience, modularity, and flexibility at scale.

Aligned to our "Architect for Change" policy, this standard reduces integration risk, improves maintainability, and strengthens autonomy. Without it, changes ripple unpredictably across domains, slowing delivery and increasing system fragility.

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: Integrations are informal, with frequent breaking changes.

  • Level 2 – Managed: Interfaces are documented and stable, but coupling remains high.

  • Level 3 – Defined: Teams adopt standards (e.g. versioning, contracts) for reliable integration.

  • Level 4 – Quantitatively Managed: Integration stability and coupling metrics are tracked.

  • Level 5 – Optimising: Interfaces evolve through intentional governance and runtime insights.


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
  • Strangler Fig Pattern
  • Service Mesh Implementation
  • API-first Design
  • Domain-Driven Design (DDD)

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

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