Integration, interoperability, and coupling decisions

Applications can exchange information in many ways, but not all of those ways create the same enterprise consequences. Integration style shapes how tightly systems depend on one another, how failures spread, how quickly information becomes visible, and how difficult future change becomes.

C220 Part 3 (ADM Techniques) positions integration as an architecture concern because the cumulative effect of individual integration decisions shapes the enterprise's overall changeability, resilience, and cost of ownership. A single badly chosen integration pattern may be harmless. Seventy-two badly chosen patterns create a fragile web that makes every change programme expensive.

TOGAF defines four levels of interoperability that the architecture should consider for each integration. Each level addresses a different aspect of the exchange.

1. Operational interoperability. Can the systems physically connect and exchange data? This is the most basic level, covering network connectivity, protocol compatibility, and transport mechanisms. Most modern systems meet this level, but it is not sufficient on its own.
2. Semantic interoperability. Do both systems understand the exchanged information in the same way? This level addresses shared data definitions, units, formats, and business meaning. Semantic interoperability is where most enterprise integration problems actually lie. Two systems can exchange data successfully at the operational level while interpreting it differently at the semantic level.
3. Syntactic interoperability. Are the data structures and formats compatible? This level covers message formats, schema alignment, and encoding rules. CIM alignment (Module 30) supports syntactic interoperability for power-systems data.
4. Organisational interoperability. Do the participating organisations or teams share enough governance, process, and policy alignment to act consistently on the exchanged information? This is the highest level and often the hardest to achieve. It requires not just technical alignment but also agreement on governance, timing, and accountability.

The architecture should specify which level of interoperability each integration requires and justify why. Not every integration needs organisational interoperability. Some need only operational connectivity. The decision should be explicit and recorded.

Coupling describes how tightly two systems depend on each other's structures, timings, or failure modes. The coupling decision is an architecture choice with enterprise consequences.

Tight coupling means a change or failure in one system directly affects the other. Synchronous point-to-point calls are the most common form. Tight coupling is simpler to implement but creates dependency: if the receiver is unavailable, the sender is blocked. The telemetry pipeline in the opening story used tight coupling and lost data when the receiver went down.

Loose coupling means the systems can operate independently of each other's timing and availability. Asynchronous messaging, event-driven patterns, and buffered exchanges are common forms. Loose coupling absorbs more change and failure but may introduce latency, complexity, and ordering challenges.

The right coupling choice depends on the enterprise context, not on technical preference. Four factors should inform the decision:

• Failure consequence. What happens if the connection fails? If data loss is acceptable, tight coupling may be fine. If data loss has safety or regulatory consequences, loose coupling with buffering is usually necessary.
• Change frequency. How often will the participating systems change? If one system changes frequently, loose coupling reduces the impact on the other.
• Latency requirement. How quickly must information move? Some flows need sub-second delivery. Others are perfectly served by nightly batches.
• Governance accountability. Who owns the interface and who is responsible when the exchange fails or produces inconsistent results?

An integration decision record that supports governance and future review should capture five elements.

1. The business or operational purpose of the connection. Why does this integration exist? Which decision or process depends on it?
2. The interoperability level required. Which of the four C220 Part 3 levels does this integration need, and why?
3. The information authority and semantic assumptions that travel across it. Which system is authoritative for the information being exchanged? What authority rules from Module 28 apply?
4. The chosen integration pattern and the main alternatives considered. The record should show deliberate evaluation, not just the first pattern that worked. The coupling choice (tight or loose) should be stated with rationale.
5. The consequences for latency, failure handling, coupling, and governance. What happens if the connection fails? Who is accountable? How does this integration contribute to or mitigate the enterprise's overall dependency risk?

An integration decision record that explains the mechanism but not the enterprise consequence is still incomplete. The point of the record is to make the trade-offs visible enough to govern.

The London case needs planning, operations, telemetry, publication, and governance flows to interact without letting one application boundary dominate the whole enterprise story. Each flow has different interoperability and coupling needs.

• Telemetry flows need loose coupling with buffering because data loss during operational events has safety and regulatory consequences. The interoperability level is at least semantic (both sides must agree on what the readings mean).
• Planning-to-publication flows need semantic and organisational interoperability because the published output must be interpretable by external consumers. CIM alignment supports syntactic interoperability at this boundary.
• Governance reporting flows can tolerate batch latency but need strong semantic consistency to prevent different reports from contradicting each other.
• Authority, latency, and coupling should all be visible in the London integration map within the Phase C pack.
• A technically possible interface can still be an architecturally weak choice if it creates unacceptable failure propagation, coupling, or governance gaps.