Service Boundaries and Sub-Services

A service boundary states, in user terms, where a service starts, where it ends, and what belongs inside it. The boundary should follow the outcome the user experiences, not the internal division of teams, systems, or suppliers. If customers experience one outcome, such as paying a bill from an account, splitting that outcome into many fragments for mapping purposes will make tolerances and tests hard to interpret. If customers experience two distinct outcomes, such as accessing an account and separately obtaining a lending decision, merging them into one service will hide the fact that one can fail while the other works. Sub-services arise when a part of a service has its own users, its own harm profile, or its own recovery path, and therefore needs to be understood separately even though it contributes to a larger service.

Begin with the user outcome and work backward. Name the point at which the user starts, the point at which the outcome is delivered, and the steps in between that the firm controls or depends on. Everything needed to deliver that outcome, including channels, processing, data, and third parties, sits inside the boundary for mapping purposes, even if different teams run different parts. Everything that is merely related, such as marketing, product development, or general management reporting, sits outside, unless its failure would directly prevent the outcome. Write the boundary in a sentence a customer could recognise, then test it: if the service fails, does the sentence describe what the customer loses? If the sentence describes an internal system rather than a customer outcome, the boundary has been drawn around the wrong thing.

A boundary drawn too broadly gathers unrelated outcomes under one label, so a tolerance set for the whole cannot reflect the harm of any part. A failure in one corner then appears to breach, or not breach, a tolerance that was never designed for it, and recovery priorities become unclear. A boundary drawn too narrowly fragments a single user outcome into dozens of pieces, each with its own owner and tolerance, and no one can say whether the customer outcome as a whole is resilient. Fragmentation also multiplies testing effort without improving understanding. The useful middle ground is a service that matches how users think about it, with sub-services identified only where a part genuinely behaves differently, for example where it serves a different user group, depends on a different supplier, or recovers on a different path.

A part becomes a sub-service worth naming separately when treating it as part of the whole would mislead a decision. That happens when the part has distinct users, distinct harm, a distinct dependency that could fail independently, or a distinct recovery sequence. Identity verification illustrates the point: it may be a step inside several services, but if its failure blocks all of them, understanding it as a shared component matters. Conversely, a routine internal check that fails safely, is retried automatically, and never reaches the user does not need sub-service status. The decision should be recorded with reasons, including what would change if the part were treated the other way, so that a later reviewer can challenge the choice rather than merely inherit it.

Shared functions test boundary discipline, because they appear inside many services at once. A login function, a customer data store, or a contact centre may support several important services without being a customer facing service itself. One approach is to treat the shared function as a component of each service it supports, mapping it repeatedly so that each service map is complete. Another is to treat it as a service in its own right, with its own tolerance, when its failure would harm users across several services. Either approach can work, but mixing them without explanation creates confusion, with the same function mapped in one place, assumed in another, and owned nowhere. Whichever approach is chosen, name an owner for the shared function and make clear how its failure is reflected in the tolerances of the services that depend on it.

Check a boundary by walking a disruption through it. If a failure inside the boundary does not affect the stated user outcome, something has been included that does not belong. If a failure outside the boundary prevents the outcome, something essential has been left out. Check also that two different teams, given the same boundary description, would map the same service: if they would draw different maps, the boundary is not yet clear enough. Finally, check that the boundary survives a change of supplier or system, since a boundary tied to a particular technology will need redrawing at every migration. This guide is educational only.