FMEA Dependency Table¶

Structured assessment — instantiates Dependency Exposure

Adapts failure mode and effects analysis to dependencies — scoring each one's failure by severity, likelihood, and detectability to produce a ranked, mitigation-prioritized list rather than a flat inventory.

A list of dependencies tells you what you rely on; the FMEA Dependency Table tells you which failures to worry about first. Borrowing the discipline of failure mode and effects analysis from reliability engineering, it takes each dependency, enumerates how it could fail, and scores that failure along three axes — how bad the effect is (severity), how likely it is (occurrence), and how likely you'd catch it in time (detectability). Its distinguishing move is that third axis and the multiplication: a dependency that fails silently and catastrophically ranks far above one that fails loudly and harmlessly, even at equal likelihood. The output is a priority order for where to spend scarce mitigation effort — the systematic, comprehensive complement to a targeted impact analysis.

Example¶

A satellite operator runs an FMEA over its ground-segment dependencies. Each row is a dependency and a way it could fail: the primary downlink station (weather outage), the GPS timing source the scheduler trusts (spoofing or drift), the commercial power feed, the orbit-prediction data vendor. For each, the team scores severity, occurrence, and detectability on a 1–10 scale and multiplies them into a risk priority number.

The ranking is the payoff, and it's counterintuitive. The power feed scores high on severity but low overall — it fails loudly and a UPS covers it, so detectability and mitigation are strong. The timing-source drift, by contrast, scores modest severity but terrible detectability: a slow drift wouldn't trip any alarm and would silently corrupt scheduling before anyone noticed. Its risk priority number lands at the top — not because it's the most dramatic failure, but because it's the one they'd catch last. That's the row that gets a monitoring check and a cross-validation source added first.

How it works¶

The table's distinctive contribution is comparability through scoring. Where other mechanisms surface or map dependencies, FMEA forces each failure mode onto a common scale so that heterogeneous risks — a vendor outage, a data corruption, a staffing gap — can be ranked against one another by a single number. The detectability axis is what sets it apart from a plain consequence-times-likelihood risk score: it explicitly rewards failures you'd notice and punishes the ones that hide, which is exactly the silent-failure blind spot the archetype cares about. High-scoring rows then carry a mitigation column — the contingency or substitution that would bring the score down — so the table doubles as a prioritized action plan.

Tuning parameters¶

Scoring scale — the range and anchors for severity, occurrence, and detectability. Well-anchored scales make scores comparable across raters; vague ones make the numbers theater.
Axis weighting — whether the three axes multiply equally or detectability (or severity) is emphasized. Weighting shifts what floats to the top — a safety context leans on severity, a silent-corruption context on detectability.
Failure-mode granularity — one failure mode per dependency or several. Finer modes catch distinct failure paths but multiply rows and effort.
Action threshold — the risk priority number above which a mitigation is mandatory. A low threshold forces action broadly; a high one focuses effort but tolerates more residual risk.

When it helps, and when it misleads¶

Its strength is disciplined prioritization: it stops a team from treating all dependencies as equally worrying, and its detectability axis specifically elevates the silent, slow, hard-to-notice failures that flat lists and even impact analyses tend to under-weight. It is the natural mechanism when there are more dependency risks than mitigation budget and the question is what to fix first.

Its danger is false precision. Multiplying three subjective 1–10 guesses yields a crisp-looking number that can lend spurious authority to what is really an opinion, and risk priority numbers are notoriously gameable — nudge one axis and a row moves off the action list, which makes the table easy to run backwards to justify not fixing something^[1]. It also assumes the failure modes were enumerated; a dependency failure nobody thought to score simply isn't on the table. The discipline is to anchor the scales concretely, treat scores as a conversation-starter for the top rows rather than a verdict, and revisit the enumeration itself, not just the numbers.

How it implements the components¶

failure_path_model — each row models a specific way a dependency fails and the effect that follows, which is the raw material the scoring operates on.
criticality_classification — the severity × occurrence × detectability score is a criticality ranking, ordering dependencies by prioritized risk rather than leaving a flat list.
contingency_or_substitution_path — high-scoring rows carry the mitigation or substitution that would lower the score, making the table a prioritized action plan.

It does not draw the relational structure (Dependency Graph), trace the blast radius of one specific change end to end (Impact Analysis), or hold the durable owned record of each dependency (Dependency Registry).

Instantiates: Dependency Exposure — the table is the archetype's systematic risk-ranking mechanism, turning a dependency inventory into a mitigation priority order.
Consumes: Impact Analysis or a Dependency Graph supplies the failure paths the table scores.
Sibling mechanisms: Impact Analysis · Dependency Registry · Assumption Log · Architecture Dependency Review · Contract and SLA Review · Critical Dependency Dashboard · Dependency Graph · Dependency Review Workshop · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map

Notes¶

FMEA scores known failure modes; it is silent on the ones nobody listed. Its comprehensiveness is real but bounded by the enumeration step, so it pairs best with a discovery mechanism (a workshop or graph) that widens the set of dependencies before they are scored.

References¶

[1] The risk priority number (RPN = severity × occurrence × detection) is the classic FMEA output. Its known weakness — that very different risk profiles can yield the same RPN, and that the score is sensitive to subjective ratings — is why modern practice (e.g. the AIAG-VDA handbook) supplements it with action-priority logic rather than trusting the number alone. ↩