Important Services Shared Across the Firm

A shared function counts as important when its failure would harm users across several services at once, even if no customer ever sees the function directly. Authentication, customer data, core account records, messaging, and contact centre capability are classic examples: each supports many customer facing services, so a single failure can block access, payments, claims, and support simultaneously. The harm test is applied to the shared function in the same outward way as to any service, by asking what users lose when it fails, not by asking how central it looks on an architecture diagram. In some firms, the shared function is best treated as a component mapped inside each service it supports. In others, its breadth of impact justifies treating it as an important service in its own right, with its own owner, map, and tolerance. What matters is that the choice is explicit and consistently applied.

Harm spreads through shared functions in two ways. The first is simultaneous blocking: one authentication failure locks customers out of accounts, payments, and policy services at the same time, so the customer cannot work around the problem by switching services. The second is hidden dependence: a service that appears healthy may rely on shared data, a shared ledger, or a shared messaging route that has failed, so its output is wrong, delayed, or incomplete without any obvious error at the front end. Shared functions also concentrate recovery risk, because restoring one shared component may be a precondition for restoring many services, and a mistake in that restoration can prolong harm across the firm. Mapping shared functions therefore means tracing dependence in both directions: from each service down to the functions it needs, and from each function up to the services that would be affected if it failed.

A shared function earns service status when its failure profile is distinct from any single service it supports. That is likely when it serves many important services, when its users include customers directly as well as internal services, when it has its own recovery path, or when its tolerance needs to be stricter than the tolerances of the services that depend on it, because it must recover first. A customer data store that must be restored before payments can be reconciled is an example: its recovery priority is set by the needs of others, not by its own user journey alone. By contrast, a narrow utility that fails safely, is retried automatically, and never directly affects a user outcome may be better treated as a component.

Shared functions are vulnerable to ownership gaps, because every service team may assume another team owns the shared part. A named owner for the shared function, distinct from the owners of the services that use it, prevents that drift. The owner needs authority over the functions resilience, including its dependencies, its testing, and its recovery sequence, and needs a clear relationship with service owners, so that a change to the shared function is assessed for its effect on every dependent service. Change is where shared ownership is most tested: an upgrade, migration, or supplier change to a shared platform can introduce risk across the firm at once, and that risk should be reviewed service by service before the change proceeds, not discovered service by service afterwards.

The most common mistake is to omit shared functions from service maps altogether, because they are not customer facing, leaving each service map incomplete at exactly the point where a common failure would strike. The opposite mistake is to list every shared utility as an important service, which recreates the everything is important problem and dilutes focus. A subtler mistake is to map a shared function inconsistently, treating it as a service for one dependent service, a component for another, and an assumption for a third, so that no one can tell what would actually happen if it failed. Another is to set a tolerance for a shared function without checking whether it can recover in time for the services that depend on it, creating tolerances that cannot all be met together.

Check a shared function decision by failing it in a rehearsal and watching the spread. List every service that would be affected, describe the user harm for each, and ask whether the recovery order is workable: which services recover first, what the shared function must deliver before they can, and how customers are kept informed in the meantime. If the rehearsal shows that several tolerances would breach together, the shared function deserves service status and a tolerance of its own. If the rehearsal shows contained, easily worked around effects, component treatment is sufficient. This guide is educational only and does not advise any particular firm.