Why Services Not Systems Are the Unit

Services, not systems, are the unit of operational resilience because users experience services. A customer receives a benefit payment, a mortgage decision, or a settlement, not a database or a server, and the loss that matters is the loss of that outcome. Organising resilience around systems can therefore produce reassuring reports while users remain unserved.

Consider a benefit payment service that depends on an eligibility system, a payment engine, a bank file, and a notification channel. Each system might pass its own health check, yet a mismatch between two of them could still stop payments. Only a service view, which follows the payment from request to receipt, would catch that the chain as a whole had failed.

A service, in this sense, is an end to end outcome delivered to an identifiable group of users, with a beginning, a set of steps, and a result that users can recognise. It crosses teams, systems, and suppliers, and it often includes manual steps that a system diagram would omit, such as a check, an approval, or a phone call that unblocks a case.

Naming a service well matters. A name that is too broad, such as payments in general, hides very different harms and dependencies, while a name that is too narrow, such as one application, hides the chain that delivers the outcome. The right level is the level at which a user would notice a stop and describe what they lost.

Mapping a service means walking it from the user backwards, asking at each step what is needed, who provides it, and what happens if it fails. The walk usually surfaces dependencies that architecture documents miss, including a spreadsheet maintained by one person, a supplier that also supports the backup, or a data feed that arrives through an informal route.

The map need not be elaborate to be useful. A clear map that names the channel, the processing steps, the third parties, the data, and the people who decide during a disruption gives a firm something it can test and improve. A detailed map that no one uses during an incident is less valuable than a simpler map that the service owner can actually follow under pressure.

A system view misleads when it treats each component as independent. Recovery can then be reported component by component, with each team able to say its part returned, while no one is responsible for the moment when the parts must work together again for users. The service can remain broken in the gaps between restored components.

System views also encourage investment to follow the loudest technical risk rather than the greatest user harm. A rarely used but technically fragile system may attract attention, while a mundane dependency on which thousands of payments depend remains unexamined because it rarely fails. The service view reorders that priority by harm.

When the unit changes, ownership changes with it. A service owner becomes accountable for the whole outcome, including parts run by other teams and suppliers, rather than each team owning only its component. That accountability does not remove technical ownership, but it adds a person who must answer for the user outcome when components disagree.

Testing changes as well. Instead of testing whether a system restarts, the firm tests whether users can complete the service, and it judges the test by harm and by recovery order. A test that restarts systems in the wrong order, leaving users waiting for a step that comes last, has revealed a service problem even if every system passed.

Choose a service and try to describe it without naming a system. Who uses it, what outcome do they expect, which steps must happen for that outcome, and what would they lose if it stopped? If the description collapses into system names, the service has not yet been defined in user terms.

This guide offers an educational explanation, not a prescription for any firm. Its claim is modest: resilience organised around services keeps attention on the loss users would actually suffer, and that attention is what makes mapping, tolerances, and testing meaningful.