Dependency map
What stops when one thing stops, and which handoffs are held together by a person rather than a system?
Enter each piece once, say what it feeds, and mark the handoffs you would not want to explain to an auditor. The map below redraws as you type.
Sources
- CRM
- Stripe
Ingest
- nightly-etl
Store
- warehouse
Services
- billing-api
Consumers
- exec-reports
What feeds what
- CRM feeds nightly-etl — fragile handoff: Manual CSV export, one person knows the steps
- Stripe feeds nightly-etl
- nightly-etl feeds warehouse
- warehouse feeds billing-api
- billing-api feeds exec-reports — fragile handoff: Figures re-keyed by hand into the board deck each month
The map is laid out from the edges you enter: a node's column is its distance from a source, so a long chain is long on the page. Nothing is positioned by hand, which means two people entering the same dependencies get the same map.
How the layout is derived
A node’s column is its longest distance from a node nothing feeds. Sources sit left, consumers right, and a cycle is reported rather than drawn — a dependency graph with a loop in it is a finding, not a rendering problem.
What it assumes
That you can name every piece. The value of the exercise is mostly in discovering that you cannot: the map people draw from memory is reliably missing one vendor and one spreadsheet.
That “fragile” is a judgement you are willing to write down. Marking a handoff dashes its line and lists it in prose beneath the map, so the claim carries a reason and not just a colour.
What it does not model
Latency, volume, cost, redundancy or failure probability. It answers one question — what is downstream of this — and a map that tried to answer the others would answer none of them legibly.