Dependency Heatmap¶
Visualization tool — instantiates Specialization Boundary and Reintegration Design
Renders every specialty's dependencies on one colour-graded grid so single-source chokepoints and lock-in glow before they fail.
When you divide work into specialties you also spin a web of who-depends-on-what, and most of that web is invisible until something in it snaps. Dependency Heatmap makes the web legible in one view: it plots critical functions against the specialties, suppliers, data sources, and platforms they rely on, then colour-grades each cell by how much rides on a single source. Its whole distinctive job is visibility of concentration — turning a diffuse "we're probably over-exposed somewhere" into a wall of red cells that rank themselves. It is a detector, not a fixer, and unlike the people-focused reviews among its siblings it puts every kind of dependency on one scale, so a single-vendor API and a single-engineer toolchain glow side by side.
Example¶
A small drone maker depends, without ever having drawn it out, on a flight-controller chip from one supplier (≈20-week replacement lead time), a firmware toolchain only one engineer can operate, and a telemetry feed from a single vendor's API. A dependency heatmap lays functions down the rows and their sources across the columns, shading each cell red where exactly one source exists, amber where two, green where many. Three cells burn red. The map doesn't argue; it simply shows that the reddest, longest-lead-time cell is the chip — so that is where dual-sourcing starts, followed by documenting the toolchain. Six months earlier the same exposures existed; nobody could see them all at once.
How it works¶
- Choose the axes — critical functions or deliverables against the sources they depend on (people, suppliers, data, platforms).
- Score each cell for concentration — how many independent sources exist, how long a substitute takes to stand up, how wide the blast radius if it fails.
- Colour-grade so hotspots pop — one comparable scale across unlike dependency types, so the eye triages automatically.
- Rank and route the red cells — hand the worst chokepoints to the mechanisms that actually build redundancy or renegotiate the dependency.
The distinguishing move is putting people-, supplier-, and platform-dependencies on the same grid; it maps concentration but deliberately fixes nothing.
Tuning parameters¶
- Grid granularity — coarse (team-to-team) or fine (function-to-single-API). Finer surfaces more chokepoints but multiplies upkeep and can bury the signal.
- Concentration scoring rule — count of independent sources, weighted by replacement lead time, or by blast radius. Each rule lights up a different set of cells.
- Dependency scope — people only, or suppliers, data feeds, platforms, and market access too. Wider scope catches external lock-in but dilutes focus.
- "Red" threshold — where the alarm colour begins. Set it low and everything glows (alarm fatigue); set it high and real chokepoints stay hidden.
- Refresh cadence — a one-shot snapshot or a live dashboard. Live catches drift as the org changes; snapshots are cheaper and less noisy.
When it helps, and when it misleads¶
Its strength is that it makes concentration comparable and rankable on a single page and forces triage onto the reddest, highest-blast-radius cell first. Its central limitation is that a heatmap shows structure, not likelihood: a red single-source cell may be perfectly stable for years, while a bank of green cells can hide a correlated failure that takes them all at once — the map colours where you could be hurt, not where you will be. The classic misuse is running it to justify a reorg or vendor switch already chosen, by picking axes and a scoring rule that make the disfavoured team glow red. It also invites "watermelon" cells — squares too coarse to show that they are green outside and red within. The discipline that keeps it honest is to keep each colour tied to its underlying numbers (lead time, blast radius, source count), and to remember that it only points: the reddest cell earns its risk only once a sibling acts on it. This is concentration risk[n1] made visible, not managed.
How it implements the components¶
dependency_and_bottleneck_map— the heatmap is this map: every dependency and bottleneck across the specialized system, rendered visually and scored by concentration.
It stops at detection. Building the redundancy those red cells demand (overlap_and_redundancy_buffer) belongs to Bus Factor Review and Rotation & Cross-Training Schedule; pricing the coordination the dependencies create (local_metric_alignment_check) is Coordination Cost Accounting; and deciding when a hotspot should actually trigger a redesign (rebalancing_trigger) is Role Recomposition Trigger Review.
Related¶
- Instantiates: Specialization Boundary and Reintegration Design — the heatmap supplies the dependency-and-bottleneck map the rest of the design reads.
- Sibling mechanisms: Bus Factor Review · Coordination Cost Accounting · Handoff Contract Template · Integrator Role Assignment · Over-Specialization Audit · Role/Niche Charter · Role Recomposition Trigger Review · Rotation & Cross-Training Schedule · Specialist–Generalist Portfolio Review · Specialization Boundary Workshop
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: Dependency Heatmap operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it renders every specialty's dependencies on one colour-graded grid so single-source chokepoints and lock-in glow before they fail.
Independent corroboration: The frozen evidence defines Dependency Heatmap as 'Renders every specialty's dependencies on one colour-graded grid so single-source chokepoints and lock-in glow before they fail', so its operative form is Interface, Display & Cue.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Enterprise risk and operational-resilience practice cohered mapping critical functions to internal and external dependencies so concentration chokepoints can be ranked before disruption.
Related originating lineages:
- Data Science & Analytics — Heatmap visualization supplied the common grid and colour encoding used to compare unlike dependency concentrations.
- Economics & Finance — Financial concentration and operational-resilience practice supplied exposure, criticality, and substitutability analysis.
- Logistics & Supply Chain Management — Supply-chain risk management supplied supplier mapping, single-source exposure, and replacement-lead-time measures.
Review resolution: Basel operational-resilience guidance makes mapping critical operations and their interdependencies an enterprise governance method, while NIST supply-chain guidance supplies supplier-dependency and concentration analysis. The single cross-specialty heatmap is therefore organizational risk management primary with financial, logistics, and visualization lineages retained.
Attribution caveat: The all-dependency heatmap synthesizes enterprise, financial, supply-chain, and visual-analytics traditions rather than reproducing one canonical named artifact.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
- Basel Committee: Principles for Operational Resilience
- NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
Notes¶
The heatmap is an input: its value collapses if no mechanism consumes the red cells. It also sits beside two other diagnostic siblings and is easily confused with them — but it maps where concentration is (a static risk picture), where Coordination Cost Accounting prices the ongoing tax of the seams and Bus Factor Review narrows to people and drives the fix.
[n1] Concentration risk — the risk-management term for over-reliance on a single source, supplier, counterparty, or component, such that one failure has outsized effect. A dependency heatmap is essentially a concentration-risk picture drawn across all of a specialized system's dependency types at once. ↩