One of the more persistent misunderstandings in service management is the idea that a Technical Service Catalogue lists different services from a Business Service Catalogue. It’s a seductive but flawed notion, and it’s time we retired it for good. A service catalogue, no matter the audience or internal view, should only ever define one thing, the services delivered to the customer.
This isn’t just semantics. Misunderstanding the role of the catalogue leads to confusion, duplicated effort, and most critically a lack of focus on what really matters, value delivered to the customer. When teams start adding internal services to their catalogues, they’re documenting components, not services. They might call them services, but that doesn’t make them so.
Understanding the Catalogue Boundary
A catalogue is not a list of everything IT touches. It is a boundary document that defines what a business unit delivers externally. It should never try to capture the inner workings or technical composition of how services are delivered.
Yes, internal teams like server or backup groups might wish to maintain their own operational inventories, but these are not catalogues. They are views, artifacts, or documentation, not the list of services a customer consumes. And unless a business unit is genuinely delivering something independently to an external audience (with all that entails, accountability, SLAs, funding), it’s not a service in catalogue terms.
One Set of Services, Many Views
There’s often debate over whether a Technical Catalogue and a Business Catalogue are distinct. In reality, they are simply different views of the same catalogue. The Business view is aimed at consumers, clean, consumable, value-focused. The Technical view is inward-facing, helping IT manage complexity and understand relationships. But the underlying list of services should be identical.
This distinction is often blurred when internal processes, systems, or tools are labelled as services. Just because something can be named and described doesn’t mean it qualifies. Services are outputs. They’re what the business unit offers externally and not what’s buried within.
What Gets Documented – And What Doesn’t
There’s absolutely value in capturing the supporting elements of a service, from infrastructure to underpinning contracts, but these should be embedded in service descriptions or architecture views, not added to the catalogue as standalone entries.
A backup system, for example, is not a service unless it is directly offered and managed as one. It may be critical to service delivery, but that doesn’t elevate it to customer-facing status. The more we conflate supporting components with actual services, the harder it becomes to focus effort on service outcomes.
Get the Catalogue Right, Get the Rest Right
A well-constructed service catalogue brings clarity to everything that follows, reporting, accountability, SLAs, service design, and even budgeting. Misuse it, and those same disciplines become muddled.
There is only one set of services that should appear in a catalogue, that’s those delivered by the business unit to its customers. Everything else is either a supporting element or another unit’s responsibility. Keep it clean. Keep it focused. And most importantly, keep the customer in view.
🔗 Further Information.