Dependency Map¶
Artifact — instantiates Relation Mapping
Maps reliance links — this needs that — across tasks, resources, and vendors, so a change or failure can be followed outward to everything downstream it would disturb.
A Dependency Map represents relies-on relations — this task cannot start until that one finishes, this scene needs that permit, this deliverable assumes that vendor holds — and its defining purpose is to make the blast radius of a change or failure visible before it happens. Its edges are directional by nature (A depends on B is emphatically not B depends on A), and each is annotated with what happens downstream if the thing it leans on slips. Unlike a causal map, it makes no claim about why B affects A; it only records that A's fate is hostage to B's, and follows that hostage-taking outward through the chain.
Example¶
The line producer on an independent film builds a dependency map for the shoot. Nodes are shooting days, locations, cast, equipment, and permits; edges are "depends on." The rooftop-chase day depends on the drone rental, the drone depends on an FAA flight waiver, the waiver depends on the location permit, and three other days depend on the lead actor whose contract ends on the 20th. Reading outward from a single fragile node — the waiver, still marked "pending" — the map shows a cascade: no waiver → no drone → no rooftop day → a re-shoot that collides with the lead actor's contract end → four further days at risk. That traced consequence, not the flat call sheet, is what tells the producer to expedite the waiver now or reorder the schedule before the collision is unavoidable. The fragility was invisible in a list of tasks; the map made the one-to-many fan-out legible.
How it works¶
- Record each reliance as a directed edge A → B, reading "A depends on B," and hold the direction convention rigidly.
- Encode cardinality. Fan-in (how many things depend on B) marks B's criticality; fan-out marks how far a change in one node reaches.
- Annotate the consequence of B's failure or delay on A — blocking or merely degrading — and propagate it transitively down the chain.
- Trace outward from fragile or high-fan-in nodes to compute the blast radius before, rather than after, the failure.
What distinguishes it: it is about the propagation of trouble, not the semantics of causation, and not the standing maintenance of a register.[n1]
Tuning parameters¶
- Direction convention — "depends-on" versus "is-required-by." Pick one and never mix them; silently reversing the arrow is the single commonest dependency-map error.
- Transitivity depth — how many hops of downstream consequence to trace and display before the picture becomes noise.
- Criticality surfacing — whether to highlight high-fan-in nodes as single points of failure.
- Entity breadth — tasks only, or tasks plus resources, vendors, and assumptions; broader maps catch more fragility but grow harder to read.
- Hard vs. soft edges — blocking dependencies ("cannot proceed") versus degrading ones ("proceeds worse"); conflating them overstates the blast radius.
When it helps, and when it misleads¶
Its strength is turning "what could go wrong" into a chain you can actually follow, and exposing the single points of failure that a flat plan hides.
Its failure mode is that a tidy graph implies a complete one: real dependencies are partly unknown, informal, or emergent, so the reliance nobody drew stays invisible and the map turns falsely reassuring. The classic misuse is reading the absence of an edge as the absence of a dependency. It is also easy to mistake a dependency for a cause — that A needs B does not mean B makes A behave. The guarding discipline is to mark assumed edges apart from confirmed ones and to re-trace as the plan shifts, while leaving the standing, owned upkeep of that record to its register sibling.
How it implements the components¶
relation_instance_link— each "A depends on B" is one atomic, inspectable reliance record, the unit the map is built from.directionality_and_cardinality— direction distinguishes the dependant from what it depends on, and fan-in/fan-out cardinality is precisely what reveals critical nodes and reachable scope.consequence_annotation— every edge, and every traced chain, carries what fails downstream — the blast radius that is the map's payoff.
A dependency map records and propagates reliance; it does not defend those edges as causal or bound them to a regime — the evidence_and_source_basis and temporal_validity_window discipline of a proven cause belongs to Causal Map, its nearest twin (a dependency needs no causal proof, only that the reliance holds). Nor is it the standing roster: the owned, kept-current register of ownership_annotation and validation_and_update_loop is Service Dependency Inventory.
Related¶
- Instantiates: Relation Mapping — the reliance variant, focused on tracing downstream impact.
- Consumes: Service Dependency Inventory can supply the raw service-and-dependency list this map renders and traces outward.
- Sibling mechanisms: Causal Map · Service Dependency Inventory · Relationship Graph · Ownership Map · Stakeholder Map · Adjacency Matrix · Knowledge Graph · Data Lineage Map · RACI Matrix
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Dependency Map operates as a non-executable information artifact that externalizes static or prospective structure because it maps reliance links — this needs that — across tasks, resources, and vendors, so a change or failure can be followed outward to everything downstream it would disturb.
Independent corroboration: The frozen evidence defines Dependency Map as 'Maps reliance links — this needs that — across tasks, resources, and vendors, so a change or failure can be followed outward to everything downstream it would disturb', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Project-network methods cohered directed prerequisite maps for tracing schedule consequences and critical dependencies; engineering design and computer science developed parallel dependency representations for complex artifacts and software.
Related originating lineages:
- Computer Science & Software Engineering — Build systems, package managers, and service graphs independently operationalized directed dependency maps and transitive blast-radius tracing.
- Engineering & Design — Design-structure matrices established directed component and task dependencies for managing complex engineered systems.
Review resolution: The 1959 PERT project-network method predates the later design-structure matrix and modern software dependency graphs as a recognizable directed prerequisite map. Operations research is therefore primary, with engineering design and computer science retained as convergent lineages; generic organizational use is applicability rather than a separate origin.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- Malcolm et al. (1959): Application of a Technique for Research and Development Program Evaluation
- Steward (1981): The Design Structure System
Notes¶
[n1] "Blast radius" is the operational term for the set of things disrupted when one component fails; the larger a node's fan-in, the larger its blast radius. Dependency maps exist largely to make that radius visible before, rather than after, the failure. ↩