• Home
  • BVSSH
  • C4E
  • 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

  • Improved delivery flow and clearer architectural separation
  • Reduced risk of cascading failures across teams or services
  • Faster time to market through safe, isolated deployments
  • Higher resilience and testability of services
  • Foundation for scalable, distributed system design

Risks of Not Having This Standard

  • Frequent regressions and delays caused by tight coupling
  • Fragile architectures with high coordination costs
  • Hidden dependencies and difficult-to-debug interactions
  • Reduced confidence in evolving business capabilities
  • Inefficient scaling of teams and domains

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Teams work independently but introduce implicit
dependencies without coordination.
Process & Governance Integrations are informal or undocumented.
Interface changes are rarely communicated.
Technology & Tools Point-to-point APIs or database sharing is common.
There is no boundary enforcement.
Measurement & Metrics Breakages occur regularly but are not tracked
or tied to integration maturity.

Level 2 – Managed

Category Description
People & Culture Teams begin recognising the need for stable
interfaces and communicate changes manually.
Process & Governance Some API documentation exists, and teams coordinate
breaking changes through meetings.
Technology & Tools Shared tools like Postman or Swagger emerge,
but adoption is uneven across domains.
Measurement & Metrics Backward compatibility issues are identified
through incident post-mortems.

Level 3 – Defined

Category Description
People & Culture Domain boundaries are respected, and interface ownership
is clear and documented.
Process & Governance Contract-first design, semantic versioning, and backward
compatibility policies are standard practice.
Technology & Tools API gateways or schema registries enforce
contract expectations across teams.
Measurement & Metrics Metrics around coupling, latency, and breaking
changes are actively reviewed.

Level 4 – Quantitatively Managed

Category Description
People & Culture Engineers proactively analyse usage patterns
and coordinate across domain boundaries.
Process & Governance Governance mechanisms exist to detect risky changes
before they reach production.
Technology & Tools Tooling tracks integration health and triggers alerts
on contract violations or regressions.
Measurement & Metrics Service dependency health is visible, measured,
and reviewed in architectural forums.

Level 5 – Optimising

Category Description
People & Culture Teams adapt interface evolution strategies based
on consumer feedback and change velocity.
Process & Governance Loose coupling is built into system architecture.
Interfaces evolve through versioning and governance boards.
Technology & Tools Runtime contract validation and consumer-driven
testing are integrated into delivery pipelines.
Measurement & Metrics Teams continuously track integration friction,
delivery speed, and change safety.

Key Measures

  • % of APIs or integrations with semantic versioning and published contracts
  • Time to detect and resolve breaking changes
  • Frequency of consumer-impacting integration defects
  • % of services with consumer-driven contract testing coverage
  • Service health metrics traceable to interface stability
Associated Policies
  • Architect for Change
Associated Practices
  • Service Mesh Implementation
  • Domain-Driven Design (DDD)
  • API-first Design
  • Modular Monoliths
  • GraphQL-first APIs
  • CQRS (Command Query Responsibility Segregation)
  • Strangler Fig Pattern
  • Hexagonal (Ports & Adapters) Architecture
  • Event-Driven Architecture (EDA)
  • Microservices Architecture

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

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