Impact Analysis¶

Method — instantiates Dependency Exposure

Traces the blast radius of one specific dependency failing or changing — what breaks first, who is hit, how fast, and what substitutes remain — turning a depends-on relation into a concrete consequence.

Knowing that A depends on B is not the same as knowing what happens when B goes away. Impact Analysis is the method that answers the second question for a specific dependency: pick one — a service, a supplier, a dataset, a person — and trace outward through everything that leans on it, following the chain until the consequences stop spreading. Its distinguishing move is directional propagation from a single point: not a survey of all risks, but a deep, focused walk of one failure's blast radius. It surfaces two things a static map never does — how wide and how fast the damage travels (which reveals when a modest-looking dependency is actually load-bearing), and what fallback, if any, remains standing once it's gone.

Example¶

A city's digital-services team plans to retire an aging single sign-on system and wants to know what it's really holding up. Impact Analysis starts from that one node and traces forward: which applications authenticate through it, then which downstream services those apps feed, then which citizen-facing transactions sit at the end of the chain. The walk reveals the blast radius — 40-plus internal tools, but also, three hops out, the online permit-payment flow and the benefits portal, neither of which anyone associated with "login."

The analysis then asks the second question for each affected path: what happens if SSO is gone, and what's left? Most tools have a local-password fallback; the benefits portal does not — its only authentication path is SSO. That single finding reframes the whole project. The SSO system isn't just old infrastructure; for one critical citizen service it is a single point of failure with no substitute, which means the retirement has to build a fallback there before anything is switched off.

How it works¶

The method's distinctive contribution is depth over one path rather than breadth over all. Starting from a chosen dependency, it walks the depends-on edges outward, recording at each hop what breaks, who notices, how quickly the effect propagates, and — crucially — what alternative remains. Two outputs distinguish it: a blast-radius picture that often surfaces a hidden single point of failure (a node whose reach turns out to be far wider than its reputation), and a substitute inventory that says, for each affected path, whether a fallback exists or the failure is terminal. It is the tool you reach for when you need to understand one dependency deeply, not rank many shallowly.

Tuning parameters¶

Propagation depth — how many hops outward to trace before stopping. Too shallow misses the three-hops-out critical consumer; too deep chases effects into irrelevance.
Trigger scenario — whether you model full failure, partial degradation, delay, or a change in behavior. Each produces a different blast radius; a slow degrade often hurts more paths than a clean outage.
Affected-party resolution — whether you trace to systems, to teams, or all the way to end users. Finer resolution finds the human consequence but costs more tracing.
Substitute scrutiny — how hard you test claimed fallbacks. A fallback assumed to work but never exercised is worse than a known gap.

When it helps, and when it misleads¶

Its strength is converting an abstract dependency into a concrete, believable consequence — the thing that actually moves a decision. By following reach rather than reputation, it routinely finds that an unremarkable component is a hidden single point of failure, and its substitute inventory tells you exactly where a contingency is missing versus merely untested.

Its limits are those of any single-thread analysis. It illuminates the dependency you chose to start from and is blind to the ones you didn't — it answers "what if this fails," never "what should I be worried about," which is FMEA's job. Traced consequences are also only as good as the map underneath; an undocumented consumer simply won't appear in the walk, giving a falsely bounded blast radius. And an untested fallback counted as a real one is how "we have a contingency" becomes the famous last words of an outage. The discipline is to trace one hop deeper than feels necessary, model degradation as well as clean failure, and treat every claimed substitute as unproven until exercised^[1].

How it implements the components¶

failure_path_model — its core output: a hop-by-hop model of what breaks, who notices, and how fast the effect of one dependency's failure propagates.
single_point_of_failure_marker — by measuring blast radius, it exposes when a single dependency's reach is so wide, or a critical path's only support, that its loss is catastrophic.
contingency_or_substitution_path — for each affected path it inventories what fallback remains, distinguishing recoverable failures from terminal ones.

It does not systematically score and rank every dependency at once (FMEA Dependency Table), draw the standing relational map it walks over (Dependency Graph), or keep the owned record of what it finds (Dependency Registry).

Instantiates: Dependency Exposure — Impact Analysis realizes the archetype's consequence-tracing move, turning a depends-on relation into a concrete failure picture.
Consumes: Dependency Graph — where a graph exists, the analysis walks its edges rather than reconstructing the paths by hand.
Sibling mechanisms: FMEA Dependency Table · Dependency Graph · Assumption Log · Architecture Dependency Review · Contract and SLA Review · Critical Dependency Dashboard · Dependency Registry · Dependency Review Workshop · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map

Notes¶

Impact Analysis is deep-and-narrow where FMEA Dependency Table is broad-and-shallow: use impact analysis to understand one dependency you already suspect matters, and FMEA to decide which dependencies deserve that scrutiny in the first place. They compose — FMEA nominates, impact analysis investigates.

References¶

[1] Blast radius — the full set of things affected when one component fails — is the quantity Impact Analysis exists to measure. Its practical value comes almost entirely from tracing it one or two hops further than intuition suggests, because the surprising, decision-changing consumers are usually the distant ones. ↩