Integrations are the formal contracts that connect applications, domains and capabilities. They define how data moves, how events are triggered, how dependencies are managed and how failure is handled.
They include:
An integration is not merely a technical connector. It is an expression of organisational agreement.
If one system sends a “customer” record to another, integration defines what “customer” means, when it is created, who owns it and how changes are governed.
When these contracts are explicit and stable, integration simplifies over time. When they are implicit or reactive, maintenance expands and fragility increases.
Integrations are not:
Installing an integration platform does not create integration maturity. It provides tooling.
Integration maturity arises from disciplined boundary design, version control, ownership clarity and explicit contracts between domains.
Treating integration as purely technical underestimates its structural significance.
A £55m services organisation operates separate CRM, billing and project delivery systems. Revenue recognition errors begin to appear in quarterly reports. Investigation reveals that billing status updates are sometimes delayed in synchronisation between systems. Manual corrections are common.
Leadership attributes the issue to a “sync problem.”
A deeper review shows that integration contracts were never formally defined. The CRM assumes project activation triggers billing eligibility. Finance assumes billing eligibility is validated post-delivery. The integration logic translates fields but does not reconcile intent.
The issue is not the API. It is misaligned domain assumptions.
By redesigning integration contracts deliberately — clarifying event triggers, defining ownership and formalising error handling — the organisation reduces reconciliation effort and restores reporting confidence.
The economic benefit includes reduced finance overhead and improved audit posture.
Integration complexity often increases in SMEs due to:
Symptoms typically include:
These patterns create integration debt — a structural liability that compounds quietly.
Poorly governed integration produces measurable cost:
Strategically, integration fragility reduces optionality. Platform replacement becomes high-risk because downstream impact is unclear. Vendor renewal decisions are influenced by switching cost anxiety rather than structural fit.
Integration discipline therefore directly affects both cost and agility.
Integrations sit at the intersection of structural domains.
Capabilities determine which domains must exchange information. Without clear capability boundaries, integration scope expands unpredictably.
Processes define when and how data should move. Poor process clarity produces ambiguous event triggers.
Data defines payload meaning. If definitions diverge, integration logic becomes translation-heavy.
Applications provide implementation endpoints. Application choices influence integration patterns and coupling depth.
Automation depends on reliable integration events. Fragile contracts destabilise orchestration.
Controls require traceability and auditability across integration boundaries.
Integration is therefore not a separate layer. It is the structural seam between domains.
If seams are weak, pressure reveals them.
Integration discipline becomes visible during Design and Execution but is rooted in earlier clarity.
Sensemaking
Current-state integration mapping reveals coupling depth, undocumented dependencies and translation complexity.
Design
Target integration architecture defines domain boundaries, event contracts and versioning standards before delivery begins.
Execution
APIs, event flows and authentication models are implemented deliberately, with monitoring and error handling embedded.
Institutionalisation
Integration ownership and lifecycle management are formalised. Change control processes include dependency review.
Stewardship
Periodic contract reviews prevent drift as new systems or automation initiatives introduce pressure.
When integration design is postponed until after system selection, structural coupling increases.
For structural context across all domains, see:
Applications are closely coupled with:
Controls → /frameworks/seven-pillars/controls/
Stabilising application architecture without coordinating these domains increases coupling rather than reducing it.