Skip to content

Architecture Dependency Review

Review procedure — instantiates Dependency Exposure

A gate placed before migrations, launches, and deprecations that forces the technical, data, and operational dependencies a proposed change would touch into the open before the change ships.

The Architecture Dependency Review is not a standing map but an event: a checkpoint that fires whenever a specific class of change is proposed — a migration, a launch, a version bump, a system retirement — and refuses to let it proceed until the dependencies it would disturb are surfaced. Its distinguishing move is that it is change-scoped and change-triggered. It doesn't try to map everything; it bounds the question to "what does this change touch," and it exists precisely to catch the dependencies that only become dangerous at the moment of change — the downstream consumer of a table you're about to drop, the batch job that assumes the old endpoint, the team whose runbook names the server you're decommissioning.

Example

An infrastructure team plans to retire a fifteen-year-old on-premise reporting database, confident that "everyone moved to the warehouse years ago." The Architecture Dependency Review is the gate that stands between the plan and the shutdown. Scoped to just this deprecation, it walks the dependency types deliberately: technical (what still connects to the box), data (what feeds off it), operational (whose scheduled jobs and manual exports touch it), organizational (which teams named it in a contract or SLA).

The walk surfaces three things nobody remembered: a finance month-end macro that still pulls from it, a regulator report generated off one of its views, and a partner feed that was never migrated. None appeared in the migration ticket. The review's verdict isn't "don't retire it" — it's "retire it after these three are cut over," turning a silent outage waiting to happen into a sequenced, safe change.

How it works

What distinguishes the review from a general dependency map is its trigger and its boundary. It is wired to fire on defined change events, so exposure happens at the decision point rather than as a standing effort no one reads. And it is scoped: the review deliberately fences the search to the blast area of the proposed change, walking a checklist of dependency types so that no category (data, operational, human, contractual) is skipped just because it's outside the engineers' usual line of sight. Its output is a go / sequence / hold verdict on the change, grounded in what the walk exposed.

Tuning parameters

  • Trigger scope — which change classes invoke the review (only deprecations, or every launch and version bump). Broader coverage catches more but slows delivery and breeds rubber-stamping.
  • Boundary depth — how far downstream the review traces from the changed component. One hop is fast and misses transitive consumers; deep tracing catches them at the cost of turning every change into an audit.
  • Type checklist — which dependency categories the walk is required to cover. Omitting "operational" or "human" is how the review keeps missing the manual export and the on-call runbook.
  • Blocking authority — whether the review can hold a change or only advise. A hard gate prevents surprises but becomes a bottleneck; an advisory one is easily overridden under deadline.

When it helps, and when it misleads

Its strength is timing: it catches dependencies exactly when they matter — as something is about to change — which is when a hidden reliance turns from harmless to catastrophic. Bound to a change, it is far cheaper and more focused than mapping the whole estate.

Its failure modes are procedural. Under delivery pressure it decays into a rubber stamp — a checkbox cleared without a real walk — and its scoping, its greatest asset, is also its blind spot: anything outside the drawn boundary is invisible by construction, so a too-narrow scope gives false assurance. It is also easily run backwards, convened after the design is frozen to bless it rather than to test it. The discipline is to trigger it early, when the change can still bend to what the review finds; to require the type checklist so no dependency category is silently skipped; and to give it enough teeth to sequence or hold, not merely to comment. It complements a standing Dependency Graph rather than replacing it — the graph is always-on, the review is change-time.

How it implements the components

  • dependency_scope_boundary — it fences the exposure effort to the focal change, defining what's in and out of the blast area so the review stays bounded and reviewable.
  • dependency_type_catalog — its checklist walks the dependency categories (technical, data, operational, human, contractual) so no type is skipped by habit.
  • dependency_change_trigger — it is the gate itself: a defined class of proposed change is what fires the review, tying exposure to the moment of change.

It does not draw the standing relational map (Dependency Graph), quantify what each disturbed dependency's failure would cost (Impact Analysis), or keep owners and status between changes (Dependency Registry).

  • Instantiates: Dependency Exposure — the review operationalizes the archetype at change-time, before migrations, launches, and deprecations.
  • Consumes: Dependency Graph — where a standing graph exists, the review reads it to seed its scoped walk.
  • Sibling mechanisms: Impact Analysis · Dependency Graph · Assumption Log · Contract and SLA Review · Critical Dependency Dashboard · Dependency Registry · Dependency Review Workshop · FMEA Dependency Table · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map