Relation Mapping¶
Make important associations or dependencies explicit so they can be reasoned about, governed, repaired, or redesigned.
The Diagnostic Story¶
Symptom: A local change ripples downstream in ways no one anticipated because the dependencies connecting it to other parts of the system were never made explicit. Different teams hold incompatible mental maps of who depends on whom, and after a failure the ownership and influence paths are contested rather than clear. A diagram exists, but nobody agrees what the lines mean.
Pivot: Create and maintain an explicit representation of the consequential associations among entities — including relation types, directionality, strength or criticality, and the decisions the map is meant to support. The map is not a picture; it is a governed artifact with defined semantics and a traceability obligation.
Resolution: Hidden dependencies become visible before they become failures. Change-impact reviews can trace the ripple path rather than discovering it after the fact. Accountability for ownership, influence, and obligation can be established from the map rather than reconstructed from memory after a problem.
Reach for this when you hear…¶
[software architecture] “We thought we were changing one service, but we had no idea three other teams had taken a silent dependency on its internal API.”
[organizational design] “After the restructure, nobody could tell who owned the handoff between product and legal — the org chart showed boxes, not the actual obligation lines.”
[supply chain risk] “We mapped our tier-one suppliers but had no visibility into tier two, so when a single factory went down we didn't know we had six products depending on it.”
Mechanisms / Implementations¶
- Adjacency Matrix
- Causal Map
- Data Lineage Map
- Dependency Map
- Knowledge Graph: A machine-queryable web of typed entities and relations you can traverse — following links from one concept to another to discover connecting paths a flat list would hide.
- Ownership Map
- RACI Matrix
- Relationship Graph
- Service Dependency Inventory
- Stakeholder Map
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Network: Models interactions between components.
- Observability: Infer internal state externally.
- Relation: Describes associations or dependencies.
Also references 9 related abstractions
- Accountability: Responsibility for actions.
- Boundary: Defines system limits.
- Constraint: Limits possibilities to guide outcomes.
- Coupling: Interdependence among subsystems.
- Data Integrity: Accuracy and consistency preserved.
- Network: Models interactions between components.
- Stakeholder Analysis: Identify involved parties.
- Topology: Studies properties preserved under deformation.
- Transparency: Open processes.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Dependency Mapping · subtype · recognized
Maps which entities rely on which other entities, resources, assumptions, or services.
Stakeholder Relation Mapping · domain variant · recognized
Maps actors and their interests, influence, dependencies, obligations, conflicts, or communication relations.
Data Lineage Mapping · domain variant · recognized
Maps how data elements move, transform, and depend on upstream sources across systems or processes.
Ownership Relation Mapping · governance variant · recognized
Maps responsibility, authority, custody, or ownership relations so accountability paths become explicit.
Causal Relation Mapping · other · candidate
Maps hypothesized causal relations among variables, events, actors, or system states.