---
name: multidimensional-coupling-assessment
description: Invoke when someone says "we use messaging, so we're loosely coupled", when choosing REST vs message queue vs Pub-Sub, integrating with a system you don't control, or when a "decoupled" architecture keeps causing cascading failures. Assesses coupling across several dimensions.
---
# Multidimensional Coupling Assessment

## Multidimensional Coupling Assessment

**Source:** Enterprise Integration Patterns addendum, Gregor Hohpe (2022) — "The Many Facets of Coupling"

______________________________________________________________________

### R — Reading (Original Source)

> "Coupling describes the independent variability of connected systems, i.e., whether a change in System A affects System B. If it does, A and B are coupled with respect to this change... The appropriate level of coupling depends on the level of control that you have over the endpoints."
>
> "I have long resented the idea of coupling being regarded as some form of bit that's either set or not, meaning something is coupled or magically decoupled. [...] So, the objective can't be to make everything loosely coupled but rather to understand the nuance of coupling and the design trade-offs that are involved."
>
> "Serverless integration services appear to be topology decoupled thanks to logical resource identifiers like ARNs on AWS. But it turns out that message formats are dependent on the source. Therefore, inserting a message queue or changing the data source in a serverless, event-driven application changes the message and forces downstream consumers to change — topology coupling! Such applications look recomposable at the surface but are topology-coupled via the data format."
>
> "At Google we used Protocol Buffers to describe the contract between services... To make data formats backward compatible, new fields were routinely tagged as `optional` even though they were required by the receiver. The result was that coupling shifted from the IDL to the endpoint implementation."

______________________________________________________________________

### I — Interpretation

The most common architectural mistake in integration design is treating coupling as a single dial — "loosely coupled" or "tightly coupled" — and believing that turning the dial down to loose solves the problem. This is the binary/on-off fallacy. It is architecturally meaningless because coupling is not one thing.

Coupling is the answer to a specific question: "If System A changes in way X, must System B change?" The answer depends entirely on what X is. A system can be temporally decoupled (async messaging; sender does not block on receiver) while being data-format coupled (both sides must agree on field names and types). Adding an SQS queue between an S3 event source and a Lambda consumer achieves temporal decoupling but changes the message schema — the queue's envelope wraps the S3 event — which forces the Lambda to change. Topology was decoupled; data format was not. The result is that inserting the queue caused a downstream code change: hidden coupling.

The eight dimensions make this precise:

1. **Technology Dependency** — same runtime, language, or library? (Java RMI vs. protobuf over HTTP)
2. **Location Dependency** — hardcoded IP or hostname vs. logical channel name or topic?
3. **Topology Dependency** — can an intermediary be inserted without changing sender or receiver?
4. **Data Format & Type Dependency** — does a field rename, type change, or schema evolution break either side?
5. **Semantic Dependency** — do both sides agree on what field values mean (units, enumerations, business definitions)?
6. **Conversation Dependency** — do both sides assume a specific retry contract, message order, or idempotency guarantee?
7. **Order Dependency** — does downstream logic break if messages arrive out of sequence?
8. **Temporal Dependency** — does the sender block waiting for the receiver's response?

**The theorem:** The appropriate level of coupling on any dimension depends on the degree of control you have over both endpoints. This is the calibrating principle that prevents the assessment from degenerating into "make everything loose." When you own and can refactor both sides, tighter coupling is often correct — an IDE can rename a method across every call site with zero risk. When you do not control the other side — a third-party SaaS, a partner organization, an AWS-managed service — you must minimize coupling on dimensions where that endpoint changes unpredictably.

**The hidden coupling trap:** The most dangerous coupling is the kind that appears absent. Components look topology-decoupled (logical addresses, no hardcoded endpoints) but are data-format coupled to their event source. The architecture review passes; the coupling is invisible until the source changes and every consumer breaks.

______________________________________________________________________

### A1 — Past Application (Author's Cases)

**Google Protocol Buffers — coupling shifted, not eliminated (c07):** At Google, Protocol Buffers used an IDL to define service contracts. To maintain backward compatibility, new required fields were tagged `optional` in the IDL. The IDL now said the field was optional; the endpoint implementation assumed it was always present. The coupling had not been reduced — it had been moved from an explicit, auditable IDL specification into implicit, undocumented endpoint behavior. The architecture looked decoupled on the schema dimension; it was tightly coupled on the semantic and conversation dimensions.

**AWS ARN topology coupling via data format (c08):** Serverless applications on AWS use logical ARNs as resource identifiers, which appears to provide topology decoupling — you can reroute event sources without hardcoding addresses. But the message format emitted by S3 events is structurally different from the message format emitted by DynamoDB streams or wrapped in an SQS envelope. Inserting a queue between an S3 trigger and a Lambda consumer changes the message the Lambda receives. The application looked topology-decoupled at the surface; it was topology-coupled via data format through the back door. Hohpe labels this "hidden coupling" — more dangerous than visible coupling because it creates false confidence.

**Silicon Valley race condition discovery (c14):** A developer migrated a brittle Shared Database integration to message-based integration. During the migration, he discovered a race condition in the original system — a hidden order dependency. When he asked the users what the correct behavior should be when messages arrived out of sequence, no one knew. The database's serialized access had been masking the order coupling entirely. Switching to explicit message-based integration made the coupling visible and forced a decision. The moral: coupling you cannot see is not coupling you do not have.

**EDA marketed as loosely coupled (x10):** The addendum specifically addresses the vendor and conference-talk claim that "event-driven architectures are loosely coupled." Running EDA through the 8-dimension assessment reveals: temporal coupling — loose (async); location coupling — loose; topology coupling for adding recipients — loose only if using true Pub-Sub, not Recipient Lists; data format coupling — tight (identical to RPC); semantic coupling — tight; conversation coupling — tight; order coupling — varies; technology coupling — varies. The blanket EDA claim is marketing for two of the eight dimensions and misleading for the other six.

______________________________________________________________________

### A2 — Future Trigger ★

Invoke this skill when:

- **Someone says "we use messaging, so we're loosely coupled."** This is the binary fallacy. Ask: loosely coupled on which dimension? Data format coupling and semantic coupling remain regardless of the messaging style.
- **Evaluating whether to use REST vs. a message queue vs. Pub-Sub.** Each style provides a different coupling profile across the 8 dimensions. The right choice depends on which dimensions matter for this integration point.
- **Designing an integration with a system you do not control** — a third-party SaaS, an AWS-managed service, a partner API. Apply the theorem: low control over the endpoint means you need low coupling on every dimension that endpoint changes unpredictably.
- **Auditing a "decoupled" architecture that keeps causing cascading failures.** Hidden coupling is the likely diagnosis. Evaluate topology and data format coupling explicitly — they are the most common hidden dimensions.
- **Reviewing an event-driven architecture proposal that claims decoupling benefits.** Run it through the 8 dimensions to verify which specific benefits are real and which are folklore.
- **Deciding whether to add a message queue between two components.** The queue adds temporal and topology decoupling; it does not decouple data format or semantics. If those dimensions are the real constraint, a queue does not help.
- **Assessing the risk of changing an integration interface.** Map the change to the specific dimension affected (field rename = data format; behavior change = semantic; timing change = temporal) and check whether you control the downstream endpoint.
- **Designing for a system where some endpoints are owned by other teams or organizations.** The control-level theorem determines how much you can accept coupling on dimensions that team controls.

______________________________________________________________________

### E — Execution (Steps)

1. **Name the integration point.** Identify System A and System B. Define the direction: which system can change and potentially force the other to change?

2. **Assess each of the 8 dimensions independently.** For each dimension, answer the diagnostic question and assign a rating: Tight, Sliding-scale, or Loose.

   | Dimension          | Diagnostic Question                                                          |
   | ------------------ | ---------------------------------------------------------------------------- |
   | Technology         | Do both systems depend on the same runtime, language, or library?            |
   | Location           | Does the sender hardcode the recipient's address (IP, URL, hostname)?        |
   | Topology           | Can an intermediary be inserted between them without changing either?        |
   | Data Format & Type | Does a field rename, type change, or schema evolution break either side?     |
   | Semantic           | Do both sides agree on the meaning of field values, units, and enumerations? |
   | Conversation       | Do both sides assume a specific retry contract or idempotency guarantee?     |
   | Order              | Does downstream logic break if messages arrive out of sequence?              |
   | Temporal           | Does the sender block waiting for the receiver's response?                   |

3. **Assess control level for each endpoint.** For each dimension rated Tight or Sliding-scale, ask: do we control that endpoint? Three cases:

   - Both endpoints under control → tight coupling on this dimension may be acceptable
   - One endpoint not under control → coupling on this dimension is a risk proportional to how often that endpoint changes
   - Neither endpoint under control → minimize coupling on this dimension

4. **Identify hidden coupling.** Look specifically for combinations where one dimension appears loose but another dimension makes it effectively tight. The canonical pattern: topology appears loose (logical channel names, ARNs) but data format is tightly bound to the source — inserting a topological intermediary changes the message schema.

5. **Focus decoupling effort on high-risk dimensions.** The criteria for prioritizing a decoupling investment:

   - The dimension is currently Tight or Sliding-scale
   - The endpoint changes frequently (format changes, semantic drift, availability volatility)
   - You do NOT control that endpoint

6. **State the coupling profile explicitly in design documentation.** Do not write "this integration is loosely coupled." Write which dimensions are loose, which are tight, and why each tight dimension is acceptable given the current level of control.

______________________________________________________________________

### B — Boundary (When Not to Apply)

**The assessment does not tell you the target coupling level.** The 8-dimension model is diagnostic, not prescriptive. It reveals what is coupled and why. The "appropriate level depends on control" theorem provides calibration, but converting that into a specific decision ("accept this tight coupling or invest in decoupling it") requires domain knowledge, team priorities, and change frequency estimates that the model does not supply.

**Semantic coupling cannot be fixed by technical tooling.** Data format coupling can be addressed with schema evolution tools, tagged formats (JSON/XML), optional fields, and Canonical Data Models. Semantic coupling — whether "account" means the same thing on both sides, whether the unit is meters or feet, whether "active" means the same status — requires business-level agreement. No amount of messaging infrastructure resolves a semantic mismatch. The model correctly identifies it as a separate dimension; the fix is human, not architectural.

**The model describes pairwise coupling.** When more than two systems are involved (fan-out from one source to many consumers), the coupling analysis must be repeated for each pair. A source that is data-format loosely coupled to one consumer may be tightly coupled to another. The model does not aggregate across a topology automatically.

**The 8 dimensions are not exhaustive for all integration contexts.** The model was developed for enterprise messaging integration. In streaming architectures, event sourcing, and CQRS, additional coupling dimensions may matter: offset coupling (consumer's position in an event log), schema registry coupling, and exactly-once semantics coupling. Treat the 8 dimensions as the minimum set, not the complete set.

**Decoupling has costs.** Every dimension you decouple adds indirection, operational complexity, or transformation overhead. Temporal decoupling (async messaging) means the developer cannot follow a synchronous call stack during debugging. Topology decoupling means the message routing path is no longer obvious from reading the code. The model helps identify where decoupling is most valuable; it does not rationalize decoupling everywhere.

______________________________________________________________________

## Related Skills

- depends-on: `integration-style-selection` — Style selection identifies which integration approach to use; coupling assessment deepens that decision by quantifying exactly which coupling dimensions each style introduces.
- composes-with: `eda-coupling-diagnosis` — EDA coupling diagnosis applies the 8-dimension model specifically to event-driven patterns, focusing on the asymmetric topology coupling that Pub-Sub creates; the two skills apply the same vocabulary to overlapping scenarios.
- **canonical-data-model-decision** — *enables* → Identifying tight data-format coupling across N applications through coupling assessment is the precise diagnosis that motivates adopting a Canonical Data Model.
- **Competing Consumers vs. Dispatcher** — *enables* → Coupling assessment can reveal conversation and order-dependency coupling that determines whether a Competing Consumers approach (which destroys order) is safe.

______________________________________________________________________

## Provenance

- **Source:** Enterprise Integration Patterns addendum, Gregor Hohpe (2022)