Dependency Graph¶

Model — instantiates Dependency Exposure

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.

The Dependency Graph is the archetype's most direct instrument: it renders the depends-on relations themselves as a structure — nodes for the things (services, roles, datasets, suppliers) and directed edges for "relies on." Its distinguishing power is topological: once the relations are a graph, you can see what a list never shows — that eleven services all funnel through one auth component, that a chain runs six hops deep, that a single dataset feeds every model. The graph makes concentration and reach legible in a way a spreadsheet of pairs cannot. It is deliberately just the structural map; it says nothing yet about how bad a failure would be or who owns the fix — that is what the archetype's other mechanisms add on top of it.

Example¶

A payments team believes their platform is well-isolated — each service in its own repo, its own on-call. Drawing the Dependency Graph tells a different story. Nodes for every service, directed edges for each runtime call and shared datastore, and one node lights up with a fan-in of fourteen: a small internal "account-lookup" service that everything, including the fraud checks and the ledger, quietly calls on the hot path. Nobody had designed it to be central; it just accreted edges.

Coloring the edges by type — synchronous call, shared database, shared library — sharpens it further: account-lookup isn't just widely used, it's on the synchronous path of the two most critical flows. The graph flags it as a single point of failure that no org chart or service list had surfaced, which is exactly the input the team needs to decide whether to replicate it, cache around it, or add a fallback.

How it works¶

What distinguishes the graph from a plain inventory is that relations are edges, so structure becomes queryable. Fan-in reveals over-relied-upon nodes; long directed chains reveal fragile transitive dependencies (you depend on things you never named); cycles reveal tangles that resist safe change. Typing the edges — is this a hard runtime call or a soft, cache-tolerant read? — turns the same picture into a fragility map rather than a mere wiring diagram. The graph is a lens, not a ledger: its job is to make shape visible, then hand the criticality, ownership, and response work to other mechanisms.

Tuning parameters¶

Node granularity — teams, services, functions, or datasets. Too coarse and the real chokepoint hides inside a box; too fine and the graph becomes an unreadable hairball.
Edge typing — whether edges are plain "depends-on" or classified (sync/async, hard/soft, data/control). Typing costs effort but is what separates a fatal edge from a tolerable one.
Direction and depth — how many transitive hops to trace outward from the focal system before stopping. Deeper reveals hidden fourth-order reliance but explodes the picture.
Layout emphasis — whether the rendering highlights fan-in (concentration) or path length (chains); the same graph tells different stories depending on what you draw to the eye.

When it helps, and when it misleads¶

Its strength is spatial: humans see a hub or a six-deep chain instantly in a picture and never in a table. It is the fastest way to surface concentration and transitive reach, and it is the substrate the rest of the archetype decorates with criticality and owners.

Its danger is that a graph feels complete and authoritative while being neither. A clean diagram silently omits the edges nobody drew — the manual workaround, the tacit knowledge, the undocumented cron job — and false confidence in an incomplete graph is worse than an honest list. A second failure: reading topological centrality as importance, when a high-fan-in node may be trivially replaceable and a peripheral one irreplaceable. The graph shows structure, not stakes. The discipline is to treat it as a hypothesis to be pressure-tested against people and incidents, and to pair every visually alarming hub with an explicit criticality judgment^[1] before acting on it.

How it implements the components¶

dependency_map — the graph is the map: the recorded depends-on relations, rendered as nodes and directed edges.
dependency_type_catalog — edge typing (sync/async, data/control, hard/soft) distinguishes the kinds of dependency the graph carries, since each kind breaks differently.
single_point_of_failure_marker — fan-in and chokepoint analysis surfaces the concentration nodes whose failure takes many things down at once.

It does not judge how bad each failure would be or rank it (Criticality Classification, via FMEA Dependency Table), assign owners (Dependency Registry), or watch the edges for drift over time (Critical Dependency Dashboard).

Instantiates: Dependency Exposure — the Dependency Graph is the archetype's core structural view, the map the other mechanisms enrich.
Sibling mechanisms: Impact Analysis · Dependency Registry · Assumption Log · Architecture Dependency Review · Contract and SLA Review · Critical Dependency Dashboard · Dependency Review Workshop · FMEA Dependency Table · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map

Notes¶

A graph alone is not the archetype — it becomes governance only when its nodes carry criticality, evidence, ownership, and a response. On its own it is a striking picture that can lull a team into thinking the exposure work is done when it has only just started.

References¶

[1] A single point of failure is a node whose loss halts the whole system because nothing can take over for it. The graph is good at nominating candidates by structure; confirming that a candidate truly has no substitute is a separate, non-topological judgment. ↩