Dependency Exposure¶
Reveal hidden dependencies so risks, obligations, failure paths, and coordination needs become visible before they cause failure.
The Diagnostic Story¶
Symptom: A failure in one place cascades into systems that were thought to be unrelated. A rollout or migration keeps hitting blockers that nobody saw in the planning documents. A key process stops the moment one person, vendor, or dataset becomes unavailable. Postmortems repeatedly conclude that 'an assumption turned out to be wrong,' but the assumption was never written down.
Pivot: Surface the dependency relations that were previously implicit or hidden, classify each by criticality and the evidence that supports it, assign accountable ownership, and connect the exposed dependencies to monitoring, contingency planning, or redesign rather than leaving them as entries in a static inventory.
Resolution: Critical dependencies are named, typed, and owned; failure paths are connected to decisions rather than buried in postmortems. Change impact assessment becomes more reliable because planners can see what they are relying on, and sensitive exposure is governed rather than left implicit.
Reach for this when you hear…¶
[platform engineering] “We didn't know our auth service depended on that third-party lookup until it went down and took login with it.”
[supply chain] “We thought we had two suppliers for that component but they both source from the same factory.”
[public health] “The whole reporting pipeline breaks if the lab coordinator is out sick because nobody else has her credentials.”
Mechanisms / Implementations¶
- Architecture Dependency Review: A gate placed before migrations, launches, and deprecations that forces the technical, data, and operational dependencies a proposed change would touch into the open before the change ships.
- Assumption Log: Makes the unstated premises a plan silently rests on into an explicit, revisable list — each with its confidence and a trigger to revisit it when reality drifts.
- Contract and SLA Review: Reads the contracts and service-level agreements behind external providers to expose what is actually guaranteed, what happens on breach, and how little recourse the fine print really leaves.
- Critical Dependency Dashboard: A live board that watches the handful of highest-criticality dependencies and lights up the moment one degrades, drifts stale, or nears a deadline — turning a one-time map into continuing observability.
- Dependency Graph: Draws the system's depends-on relations as nodes and directed edges so concentration, chains, and single points of failure become visible at a glance.
- Dependency Registry: The durable system of record for dependencies — one governed entry per dependency carrying its owner, its criticality, and its next review date, so nothing important stays unowned or unrevisited.
- Dependency Review Workshop: Puts maintainers, users, and domain experts in one room to surface the dependencies that live only in people's heads — the tacit handoffs and workarounds no document records — and to claim owners for them on the spot.
- FMEA Dependency Table: Adapts failure mode and effects analysis to dependencies — scoring each one's failure by severity, likelihood, and detectability to produce a ranked, mitigation-prioritized list rather than a flat inventory.
- Impact Analysis: Traces the blast radius of one specific dependency failing or changing — what breaks first, who is hit, how fast, and what substitutes remain — turning a depends-on relation into a concrete consequence.
- Software Bill of Materials: A machine-generated, itemized inventory of every software component and version inside a build — direct and transitive — so a vulnerability, license, or end-of-life question can be answered from a record instead of a scramble.
- Supply Chain Mapping: Traces physical dependencies upstream through multiple supplier tiers — parts, materials, facilities, transport routes, geographies — to reveal the hidden convergence that a direct-vendor view can never see.
- Vendor Risk Map: Connects each external provider to the services, data, and outcomes riding on it, rates the consequence of its failure, and names an owner and a fallback — turning a vendor list into a governed risk picture.
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)
- Coupling: Interdependence among subsystems.
- Observability: Infer internal state externally.
- Relation: Describes associations or dependencies.
Also references 11 related abstractions
- Accountability: Responsibility for actions.
- Fault Tolerance: Continue operating under failure.
- Network: Models interactions between components.
- Redundancy: Duplicate critical components.
- Resilience: Absorb shocks and adapt.
- Resource Management: Allocation of finite assets.
- Robustness: Maintain functionality under stress.
- Systemic Fragmentation: Siloed subsystems.
- Task Interdependence: Tasks rely on each other.
- Transparency: Open processes.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Supply-Chain Dependency Exposure · domain variant · recognized
Expose suppliers, logistics paths, facilities, materials, geopolitical exposures, and contractual dependencies that can disrupt delivery or production.
Software Dependency Exposure · domain variant · recognized
Expose libraries, services, APIs, infrastructure, data feeds, versions, licenses, maintainers, and security dependencies that software relies on.
Assumption Dependency Exposure · risk or failure variant · recognized
Expose plans, models, forecasts, policies, or designs that depend on untested assumptions rather than visible resources or actors.
Human Role Dependency Exposure · domain variant · recognized
Expose dependency on particular people, tacit knowledge, role coverage, informal workarounds, approvals, or relational labor.
Data Dependency Exposure · domain variant · recognized
Expose datasets, data quality assumptions, upstream transformations, model inputs, freshness constraints, and downstream uses that decisions or systems depend on.