Outbound Dependency Census

Ask any team to list the external systems their product depends on and you get six. Pull the accounts-payable ledger and the forward-proxy log for the same product and you get somewhere between twenty and sixty. The gap is not carelessness: it is that the list people recall is the list of things they chose, and most dependencies were supplied by a platform team, inherited with a framework, or added by someone who has since left.

A census closes the gap by refusing to ask anyone. It reconciles four registers that exist for other reasons, and treats the differences between them as findings rather than noise.

Why it matters

Three artefacts are wrong when the dependency list is wrong, and all three are wrong in the same direction. The incident checklist omits systems that can stop the product. The vendor concentration view misses the case where three critical dependencies resolve to the same underlying provider, which is a correlated failure nobody has priced. And the exit-cost conversation is answered with the recalled number, so a migration is scoped against six integrations and discovers twenty-five.

The census also produces the one input a context diagram needs and rarely has: a defensible reason for what was left off. A diagram whose omissions are deliberate can be defended in a review; one whose omissions are accidental cannot.

Implementation patterns

• The accounts-payable ledger first, because no commercial dependency exists without an invoice. It is the most complete single register in the company and almost no architect reads it.
• The egress allow-list or forward-proxy log, grouped by second-level domain over the last 30 days. This catches free tiers, trials and anything added without procurement.
• The credential and identity store: API keys, OAuth clients and service accounts issued to or for third parties. This catches integrations that call in rather than out.
• DNS resolver logs as the backstop for traffic that bypasses the proxy.
• Reconcile, then classify by one question: if this is unavailable for an hour, does user-visible behaviour change? Typically 5 to 8 of 25 answer yes.
• Only the yes set goes on the context diagram, with call direction and failure behaviour on the line. The rest goes in a register that procurement, security and on-call all read.
• Re-run it quarterly, or on a trigger: a new environment, an acquisition, a platform migration.

Industry example

The pattern is visible in reverse in public incident reports from 2017 onwards, where an organisation discovers during an outage that a component it did not consider part of its system was in the critical path. A concrete archetype: a payments gateway serving two regulated markets drew seven external systems on its context diagram and found 34 in reconciliation, including a third-party font service in the checkout page and a log shipper terminating in a third region. The font service was on nobody's list because it arrived with a design system, and it was the only dependency capable of blocking checkout rendering.

Failure scenarios

• The census is run once, published as a slide, and never re-run. Within two quarters it is fiction, and its existence discourages anyone from doing the work again.
• Every discovered dependency is added to the diagram, which grows to 30 boxes and stops being read, costing you the six that mattered.
• The ledger is treated as authoritative on its own, so free and trial services are missed entirely — and those are the ones with no contract, no support commitment and no security review.
• Classification is done by the team that owns each dependency, and every owner rates their own as critical.
• The register is built and never wired to anything, so it is a document rather than a control.

Trade-offs

The census also surfaces uncomfortable things: spend on unused vendors, traffic to services nobody approved, and data leaving through paths the architecture diagram denies. That is the value and it is also why the exercise stalls, because somebody now owns a list of problems.

When not to use it

A four-engineer, single-service product should skip it. The team can name its dependencies correctly from memory, and reconciliation costs a day to confirm what everyone knew. The practice starts paying at roughly two teams, when no single person has seen the whole egress path, and it becomes necessary when a regulator, an auditor or an acquirer will ask the question for you.

Interview question

Q: Your team's context diagram lists six external systems. You believe the real number is several times that. How would you find out, in what order, and what would you do with the answer?

What a strong answer covers: deriving rather than asking; naming at least two independent registers and why each catches what the others miss; the reconciliation differences as findings; and the discipline of not putting all of them on the diagram, with a stated rule for what earns a box.

Quick check

Quiz: Which single register is most complete for external dependencies, and why? The accounts-payable ledger, because no commercial dependency exists without an invoice; it misses only free and trial services, which the proxy log catches.

Flashcard: Six on the diagram, 25 in the ledger — what is the difference? Six is the list someone could recall in a meeting; 25 is the list that can take the product down. Put the 5 to 8 whose failure changes user-visible behaviour on the diagram and the rest in a register.