Interoperability
Integration Needs
Summary
A service's integration needs are identified before its design is complete.
Reasoning
A design cannot account for interfaces and data exchanges that remain unidentified. Establishing which systems and consumers exchange data or functionality, what they exchange, and in which format makes these integration constraints part of the design.
Implemented By These Standards
Communication Mode Selection
Summary
An integration deliberately chooses synchronous or asynchronous communication according to its coupling, latency, and consistency needs.
Reasoning
Communication mode determines whether a caller waits for an immediate result and how strongly the participants depend on one another's availability. Making the choice during design exposes those consequences before they become an accidental property of the implementation.
Synchronous communication suits an interaction that requires an immediate response. Asynchronous communication reduces temporal coupling where work can proceed independently or the same information must reach several consumers.
Implemented By These Standards
Interface Contracts
Summary
A service exposes shared data and functionality through an explicit, documented, discoverable interface that remains current with its actual behaviour.
Reasoning
An explicit interface contract allows consumers to integrate without depending on undocumented knowledge or the provider's implementation. Keeping the contract current makes its documented behaviour reliable, while discoverability allows prospective consumers to assess and use the interface without direct access to the provider's source code or engineering team.
Implemented By These Standards
Delivery and Ordering Guarantees
Summary
An asynchronous consumer depends only on delivery and ordering guarantees explicitly provided by its channel.
Reasoning
Delivery and ordering behaviour affects whether a consumer can receive duplicates, miss a message, or observe messages in a different sequence. An undocumented assumption about that behaviour can produce incorrect state even while the channel operates as designed.
Explicit guarantees allow consumers to implement the duplicate handling, ordering scope, and retention behaviour their channel requires without relying on stronger behaviour than it provides.
Implemented By These Standards
Open Standards
Summary
Open, widely adopted standards are preferred wherever they meet a service's needs.
Reasoning
Open, widely adopted protocols, data formats, and interface patterns give systems a shared basis for integration. Proprietary or organisation-specific alternatives require each consumer to understand and support separate conventions.
A custom or proprietary option remains appropriate where no suitable open standard exists or where an available standard cannot meet a genuine requirement.
Implemented By These Standards
- API Design
- Health Data Interoperability
- Distributed Tracing
- Observability Platform Integration
- Telemetry Instrumentation
Data Format and Meaning
Summary
The format and meaning of exchanged data remain consistent and reconciled across systems.
Reasoning
Agreed formats, units, and meanings allow a receiving system to interpret data without out-of-band clarification. Reconciling how systems represent the same real-world concept prevents differences in meaning or representation from remaining hidden across an integration.
Implemented By These Standards
Reusable Consumer-Independent Interfaces
Summary
An interface remains independent of any single consumer's implementation and is reusable when multiple systems need the same data or capability.
Reasoning
Coupling an interface to one consumer's internal implementation makes that design a constraint on every later integration. A shared, consumer-independent contract allows additional consumers to integrate without inheriting those details and avoids maintaining separate point-to-point paths for substantially the same exchange.
Implemented By These Standards
Backward Compatibility
Summary
A published interface or data contract preserves compatibility for existing consumers and follows a defined versioning approach when a breaking change is unavoidable.
Reasoning
Existing consumers depend on a published interface's established contract. Preserving compatibility allows providers and consumers to evolve independently, with additive changes avoiding forced version adoption and deliberate versioning and notice providing a transition path when a breaking change is unavoidable.
Implemented By These Standards
- API Design
- Event-Driven Messaging
- Schema Design & Evolution
- Progressive Delivery
- Release Strategy
- Rollback Strategy
Contract & Integration Testing
Summary
Integration points are verified through contract or integration testing.
Reasoning
An integration point can fail even when each participating system works in isolation. Contract and integration testing verify that systems work together and that an implementation conforms to its published interface. Testing a change to a published interface against its actual consumers, or against contract tests representing them, identifies consumer incompatibilities before release.