Skip to content

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.

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.