Dependency Registry¶
Register — instantiates Dependency Exposure
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.
A graph shows dependencies as shape and a dashboard shows them as live status; the Dependency Registry is where they become governed records. Its distinguishing purpose is accountability-over-time: every dependency gets a durable entry with three things a diagram never carries — a named owner answerable for its state, a criticality rating that sets how much attention it earns, and a review date that forces the entry to be re-confirmed before it goes stale. The registry is the archetype's system of record. It is deliberately unglamorous: not a snapshot or a picture, but the standing ledger that lets an organization govern many dependencies across many teams without any of them quietly slipping back into invisibility.
Example¶
A regional transit authority runs fare gates, real-time arrival signs, a scheduling engine, and a mobile app — each leaning on dependencies scattered across teams and years. After a fare-gate outage traced to a certificate no one owned, they stand up a Dependency Registry. Each dependency becomes a row: the arrival-signs feed, its owner (the data-services lead), criticality (high — public-facing), evidence (an incident and a config file), status, and a review date six months out.
The registry's payoff is mundane and decisive. When the scheduling engine's vendor is acquired, there's a named owner to notify. When an auditor asks "who's accountable for the payment integration?" there's a row, not a shrug. And when review dates come due, the high-criticality entries surface for re-confirmation on a cadence — so the next unowned certificate is caught by a scheduled review, not by an outage.
How it works¶
The registry's distinctive contribution is structure and stewardship, not discovery. It assumes dependencies have been surfaced (by a graph, a workshop, a review) and gives each a canonical, queryable record. Two disciplines make it more than a spreadsheet: every entry must have an owner — an unowned row is treated as an open defect, because an unowned dependency is operationally invisible no matter how well documented — and every entry carries a review date keyed to its criticality, so high-stakes dependencies are re-validated often and trivial ones rarely. It is the join point the other mechanisms write to and read from.
Tuning parameters¶
- Entry granularity — one row per system or per specific reliance. Coarse rows are cheap but hide the actual failure point; fine rows are precise but multiply maintenance.
- Criticality scheme — the scale and factors (consequence, substitutability, lead time) used to rate entries, which in turn sets review frequency and who must own them.
- Review cadence binding — how tightly review dates track criticality. Tight binding keeps critical entries fresh but demands real reviewing capacity; loose binding lets the registry drift toward fiction.
- Ownership enforcement — whether an unowned entry blocks, warns, or is tolerated. Hard enforcement guarantees accountability but can stall onboarding of legacy dependencies.
- Field discipline — how many attributes each entry must carry. More fields make richer governance but raise the odds the registry rots from maintenance burden.
When it helps, and when it misleads¶
Its strength is durable accountability at scale: it is the mechanism that keeps hundreds of dependencies governed across teams and years, and the only one that reliably answers "who owns this and when was it last checked?" It is what stops exposure from being a one-off exercise that decays the week after the workshop ends.
Its central failure mode is rot: a registry is only as true as its last update, and a stale registry is worse than none because it lends false authority to outdated entries. It also tempts organizations to mistake having a record for managing the risk — a well-filled row with a red criticality and no contingency is documentation of a problem, not a solution to it. And its review dates are inert unless someone actually works them. The discipline is to bind review cadence to criticality and enforce it, to treat unowned and overdue entries as live defects rather than cosmetic gaps, and to keep the schema lean enough that keeping it current is realistic.
How it implements the components¶
owner_assignment— its defining field: every dependency carries a named, accountable owner, and an unowned entry is treated as a defect rather than a blank.criticality_classification— each entry holds a criticality rating that governs how much attention, how tight a review cadence, and what level of ownership it requires.freshness_review_cadence— review dates keyed to criticality force each entry to be re-confirmed on a schedule, keeping the record from silently rotting into fiction.
It does not visualize the relations (Dependency Graph), watch entries change in real time (Critical Dependency Dashboard), or produce the criticality scores it stores — those come from assessment mechanisms such as FMEA Dependency Table.
Related¶
- Instantiates: Dependency Exposure — the registry is the archetype's standing system of record, holding owners, criticality, and review dates over time.
- Consumes: FMEA Dependency Table supplies criticality ratings; Dependency Review Workshop supplies newly surfaced entries and their owners.
- Sibling mechanisms: Critical Dependency Dashboard · Dependency Review Workshop · Assumption Log · Architecture Dependency Review · Contract and SLA Review · Dependency Graph · FMEA Dependency Table · Impact Analysis · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Dependency Registry operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it 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.
Independent corroboration: The frozen evidence defines Dependency Registry as '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', so its operative form is Record, Log & Register.
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: Governance and risk management cohered standing registers that assign each dependency an owner, criticality rating, and review date.
Related originating lineages:
- Computer Science & Software Engineering — Configuration-management registries supplied durable identity and system-of-record discipline for technical dependencies.
Review resolution: Governance and risk management cohered standing registers that assign each dependency an owner, criticality rating, and review date. The retained alternate lineages materially shaped the mechanism's form.
Attribution caveat: The governed-record form combines enterprise risk registers with technical configuration registries.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
The registry is the hub the other mechanisms orbit: workshops and reviews write entries into it, FMEA writes criticality, and the dashboard reads owners and ratings out of it to decide what to watch. On its own it governs but does not detect — pair it with the dashboard for drift and with impact analysis for consequences.