Mapping Services Dependencies and Systems

A service map is a trace, not a diagram for its own sake. It starts with one named service, such as customer payments or account access, and follows that service outward to everything it needs to keep running: the people who operate it, the processes that surround it, the systems and integrations that carry it, the data it reads and writes, and the third parties underneath it. When something fails, responders should be able to follow the trace, find the broken link, and know who can fix it. If the map cannot answer those questions under pressure, it is decoration rather than a working tool, however neat it looks on a wall.

Disruption rarely announces itself at the place where the damage is felt. Customers may report that payments are failing while the real fault sits in an authentication service, a data feed, or a supplier platform two layers down. Without a map, each team investigates its own corner, and precious time goes to discovering connections that should already have been recorded. A good map shortens that search. It shows the chain in the order the service actually runs, so responders can work backwards from the symptom to the cause and forwards to the customers affected. It also prevents a fix in one place from quietly breaking something else that depended on the same component.

A useful map names five kinds of dependency for the service in question. People covers the teams and roles that operate, support, and decide about the service, including cover when the usual person is away. Processes covers the steps the service follows in normal operation and the manual workarounds used when a system is unavailable. Systems covers applications, platforms, and the integrations between them. Data covers the flows and stores the service depends on, including where a copy lives if the main store is lost. Third parties covers suppliers, and the suppliers beneath them, where that chain matters to recovery. Anything that is not needed to run or restore the service can stay off the map.

The temptation is to map everything at once and finish with a picture nobody can read. Start narrow instead. Choose one service, name its users, and trace only what that service needs, step by step, from the customer-facing channel down to the deepest dependency that would stop it. Record each link in plain language, with an owner for each part, and note where the evidence for the link came from, such as a system record, a contract, or a workshop discussion. Detail belongs where failure would hurt most. A link that would halt the service deserves a fuller description than a link that would merely slow a back-office report, and the map should make that difference visible.

This cluster exists because of one recurring pitfall: a map drawn once, filed, and never updated. Services change constantly. A supplier is replaced, a system is retired, a team is reorganised, a manual workaround quietly becomes the normal way of working, and none of that reaches the filed map. The next incident then follows a route the map no longer shows, calls an owner who has moved on, or leans on a workaround that no longer works. Keeping a map current is therefore not housekeeping. It is the difference between a record that guides recovery and a record that misleads it. Every change to the service, however small it seems, should prompt the question of whether the map still matches reality.

A map proves itself in rehearsal, not in review. Pick a plausible disruption, such as the loss of a key system or a supplier outage, and walk the map as responders would in a real incident. Can the team find the affected customers, the workaround, and the recovery sequence without hunting through unrelated documents? Does every owner on the map still hold the role the map assigns? Where the walk stalls, the map has a gap, and that gap should be named, owned, and fixed before the next rehearsal. Regime labels matter here too. Under DORA in the EU and under FCA and PRA policy in the UK, expectations are stated separately in the guides, and a firm should be able to show which regime it is evidencing and why.