Raiders of the Lost Service – Part 2
What a service really is (and why your org chart is lying to you)
The story so far
Where we left off
In Article 1 of the "Raiders of the Lost Service" series, I made the case that missing service definitions are no longer a theoretical problem — they show up in value conversations that go nowhere, risk assessments built on the wrong unit, and cost discussions that exhaust everyone without producing clarity.
This second article moves from why it matters to what it actually is. That sounds like a small step. In practice, it is where most service definition efforts quietly fall apart — because everyone in the room turns out to have a completely different picture of what a service is.
The core problem
One of the most persistent problems in service management is that almost everybody uses the word "service", while surprisingly few organisations define it in a way that stands up under pressure. In normal conversation, that does not seem like a major issue. People nod along. The term sounds familiar, even comforting. But as soon as you try to use "service" to govern value, risk, cost, reporting, accountability, or resilience, the fuzziness becomes expensive.
That is because many organisations do not actually have a service model. They have a vocabulary problem disguised as a structure problem.
The four substitutes most organisations use instead
In practice, I usually see one of four substitutes for a real service definition. Each of them is understandable. None of them is enough.
1
The Org Chart Substitute
"Our services are basically what our teams do." This is the most common pattern, and the most misleading. Teams are organisational constructs. They reflect authority, reporting lines, headcount, budget ownership, and the occasional reshuffle designed to make a slide deck look decisive. Services are supposed to be far less dramatic than that. They should exist to support a business capability, not to audition for survival every time leadership changes, a budget cycle lands, or someone decides the org needs to be "simplified".
That instability is the real problem. If the service definition moves whenever the reporting line moves, then the service is not anchored in business need at all. It is anchored in internal convenience. And internal convenience is a terrible design principle for anything the business depends on. Today's tidy team boundary becomes tomorrow's reorg casualty, and suddenly the "service" has been renamed, split, merged, or quietly disappeared — not because the need changed, but because the org chart did.
It also makes accountability wonderfully vague, in the way that only bad models can. When the service is the team, it becomes very hard to separate what we deliver from who we are. That sounds harmless until performance questions appear. Then every issue becomes personal, every gap becomes a territorial dispute, and every honest conversation has to tiptoe around identity, ego, and departmental pride. The result is a governance model where nobody is quite sure whether they are discussing outcomes, operations, or feelings — which is a lot to ask of a service review.
From the consumer's point of view, the whole arrangement is even less impressive. The business does not care which team owns what. It does not wake up asking for a neat alignment to your function structure. It cares whether the capability it depends on is available, reliable, supportable, and recoverable when something inevitably goes sideways. The team is an implementation detail. A useful one, sometimes. But still an implementation detail.
That is why these portfolios are such a giveaway. When the service portfolio mirrors the IT org chart almost perfectly, that is not evidence of good alignment. It is evidence that someone mapped the internal structure and called it strategy. At that point you are not describing services in the business sense. You are cataloguing departments and hoping the business will admire the symmetry.
So yes, teams matter. But teams are not services. A service should outlive the reorg, outlast the budget round, and survive the next leadership clean-up. If it cannot do that, then it was never a service — just a team with a nameplate, a budget, and an overinflated sense of purpose.
2
The Application Substitute
"Our services are our systems." This is understandable, especially in application-centric IT environments, but it remains fundamentally incomplete. Applications are often a central part of a service, but they are not the same thing as the service being consumed. A payroll application is not the same as a payroll service. The software may calculate wages beautifully, but the service also includes payroll runs, exception handling, approvals, tax compliance, support, continuity, and the somewhat overlooked expectation that people get paid on time. A collaboration platform is not identical to a workplace collaboration service either. The platform may provide chat, meetings, file sharing, and document co-authoring, but the service is what enables people to work together reliably, securely, and without needing a small act of faith each morning.
The mistake looks tidy in a catalogue. It even feels efficient. A system gets added to the CMDB or asset register, someone finds a field called service, and — with the confidence that only a dropdown can inspire — the system is declared to be one. Problem solved. Except nothing has actually been defined. The application is just the nearest available object. It is what you can point at, not what the business actually depends on.
And that distinction matters. When IT equates services with systems, governance becomes fragile in exactly the wrong places. If the application is replaced, retired, consolidated, or re-platformed, the so-called service vanishes with it — even when the business need is still very much alive. The payroll need does not disappear because the payroll app is decommissioned. Yet if the "service" was only ever the application, then change management, portfolio management, and reporting all inherit a neat little illusion: the object moved, so the service must have moved too. Convenient. Wrong. Expensive.
That is the deeper problem. This framing quietly turns IT into a department for managing objects instead of delivering outcomes. Once that happens, attention drifts from what the business is trying to achieve to what technology assets happen to exist. The conversation becomes about inventories, dependencies, names, and records — all useful in moderation, all insufficient on their own. IT stops asking, "What outcome are we enabling?" and starts asking, "What do we call this thing in the tool?"
So yes, systems matter. But they are components, not definitions. A service is bigger than the application that happens to carry it. Otherwise you are not managing a service at all. You are just curating a list of expensive nouns and hoping one of them does the job.
3
The Catalogue Substitute
"If it is in the tool, it is a service." This is where things become theatrical. A team spends months building a service catalogue or configuring a data model, and suddenly the stage is set: dozens of "services" appear because the platform has a field called service, and someone was determined to populate it. It looks complete. It sounds mature. It is mostly just a very tidy illusion.
That is the governance theatre in all its glory. Stakeholders see entries, owners, groups, dependencies, and a few reassuring arrows, then assume the hard thinking is done because the admin work is done.
But a polished catalogue does not answer the real questions: What is the service?
Who consumes it?
What outcome does it support?
Why does it exist?
But a polished catalogue does not answer the real questions: What is the service?
Who consumes it?
What outcome does it support?
Why does it exist?
This is where Service Catalog and Request Catalog get tangled. A Request Catalog is a menu of things people can order: laptops, access, licences, onboarding tasks, passwords. Useful. Transactional. A Service Catalog should describe what the service provider actually delivers and why it matters. One is a shopping list. The other is a service model. They are not the same thing.
So no, being in the tool does not make something a service. It may only make it searchable. And if your entire service model fits on a request form, then congratulations — you have built a very efficient way to order things you still do not understand.
4
The Contract Substitute
"If we have an SLA, then we must have a service." Not necessarily. An SLA is a wrapper, not the contents. It can describe the packaging with impressive precision, support hours, contact routes, maintenance windows, escalation paths, response targets, while telling you almost nothing about what the service is actually for, who it is meant to serve, or why anyone should care in the first place. You can formalise the envelope without ever defining the letter.
And SLAs often measure the wrong things with great confidence. Response times. Uptime percentages. Resolution times. All useful, in their place. All completely capable of missing the point. A service can meet every target in the agreement and still fail the consumer in the only way that matters: it does not help them get work done, manage risk, or create value. The numbers look tidy while the experience remains unknow or lost.
That is the dangerous part. An SLA can create false confidence. It looks like governance, it feels like accountability, and it generates reassuring reports with just enough traffic-light colour to suggest seriousness. But often it is measuring the performance of something that was never properly defined. It is a highly organised way of being uncertain.
It is a bit like putting a warranty on a box and never checking whether anything useful is inside. Very professional. Very expensive. Still empty.
An SLA does not prove you have a service. It may only prove you have paperwork for the thing you failed to define.
A working definition that actually holds
So what is a better answer? A practical one comes from Unified Service Management, where a service is defined as a facility made available to a customer by a provider, with support for its use. In plain English: a service is a supported facility. That definition matters because it combines two things many organisations keep artificially separate.
The Facility
The goods and actions that allow a customer or user to do something. This might include applications, devices, access rights, workflows, data, automation, cloud components, physical assets, or operational activities. The facility is the "what" — what is actually being made available for the consumer to use.
The Support
The help, assurance, communication, and agreed handling that make the facility usable in practice. This includes contact routes, support channels, response times, standard requests, issue handling, and ongoing service interactions. Support is the "how we stand behind it" — the commitment that turns a capability into something a business can rely on.
Neither half is optional. A facility without support is a capability that has been installed but not delivered. Support without a clearly defined facility is a helpdesk attached to an undefined promise. A service requires both, and it requires them to be described together from the consumer's perspective.
That "from the consumer's perspective" point is worth dwelling on, because it is where most internal service definitions go wrong. Providers naturally describe services in terms of what they manage, maintain, and monitor. Consumers naturally describe services in terms of what they need to get done, what they rely on, and what happens when things go wrong. Those two perspectives often produce very different service shapes, and neither one alone gives you a complete picture.
The questions a good service definition must answer
A good service definition therefore needs to answer a few basic questions clearly:
1
Who is the customer or main consumer group?
2
What are they actually trying to achieve?
3
What facility is being made available to help them achieve it?
4
What support comes with it?
5
How do we know whether the service is functioning and useful?
6
What is the impact if it is disrupted?
These are not rocket science questions. They are the minimum needed to manage a service responsibly. And yet, for a surprising number of IT services in most organisations, you cannot answer all six without a lengthy internal debate. The real test will then be if the customer agrees with the answers?
That is a reliable diagnostic sign that the service is lost in the sense this series is about.
Where the org chart starts lying
This is also where the org chart quietly starts producing fiction like the whole thing is a movie 😉.
Take a typical "Digital Workplace" service. From the consumer's perspective, this is probably one thing: the ability to work digitally, access the right applications and data, collaborate with colleagues, stay secure, and get help when something breaks. From the provider's perspective, that experience is assembled from end-user computing, identity and access management, collaboration tooling, networking, endpoint security, device management, and first- and second-line support, each of which may sit in a different team, under a different manager, with a different budget.
The Fragmentation Problem
If you let the org chart define the service, you fragment what the consumer experiences as one coherent capability. You end up with five "services" that each manage their own piece without anyone owning the whole, until a security incident exposes the fragmentation.
The Reverse Problem
Teams often badge themselves as "service owners" over things that are really internal capabilities, technical components, or shared infrastructure. That does not make those things unimportant. Many are critical. It simply means they are not the right unit for every governance conversation. A load balancer team is not a service provider in the same sense as a team delivering a secure remote access service to field engineers. Both matter. But only one of them maps directly to a business outcome.
A service definition anchored in customer need and supported facility is far more durable than one that mirrors the org chart, because it is attached to a purpose rather than a management line. Reorganise the teams and the "service map" changes — even though the business still has the same needs the morning after the restructuring announcement.
Thinking from the outside in: Using the Value Proposition Canvas
This is where the Value Proposition Canvas (Value Proposition Canvas) earns its place on the table. Instead of starting from our organisation chart or system list, it forces us to start from a specific customer segment and map three things clearly: the jobs they are trying to get done, the pains that make those jobs hard or risky, and the gains they are actually looking for.
Jobs to Be Done
Jobs can be functional ("approve and pay suppliers on time"), social ("look competent as a manager"), or emotional ("feel confident our case handling is under control"), and each job has concrete pains and desired gains attached to it.
Pain Relievers & Gain Creators
On the other side of the canvas, we describe how our products and services act as pain relievers and gain creators for that segment, rather than just listing features. Nobody wakes up wanting "better CMDB data" — they wake up wanting employees to be productive anywhere, field workers to access systems securely, citizens to complete cases without friction, or clinicians to reach critical information reliably.
The USM Service Model Canvas
The USM Service Model Canvas structures the conversation around the right elements: the service itself, the parties involved, the facilities provided, the support model, the experience expected, the reporting required, and the governance rhythm. Notice what is not at the centre of that structure: your internal hierarchy. The canvas forces a provider-consumer framing rather than a team-management framing. That shift alone often produces better service definitions in a two-hour workshop than a month of internal catalogue work.
In later articles in this series, I will show how a short workshop that combines the Value Proposition Canvas with the Service Model Canvas gives you a service definition that starts from customer reality, not from platform fields, and can then be translated into specifications, agreements, and catalogues without losing the plot.
A practical test for whether your service model is healthy
A few practical warning signs are worth knowing.
Jargon-heavy service names
If your service names are hard to explain to someone outside IT without internal jargon, they are probably not defined from the consumer's perspective. Names like "Messaging Infrastructure Shared Services", "Identity Platform Level 2 Capability", or "Productivity Management Operations" may be internally meaningful, but they rarely reflect a coherent service experience for a real consumer group.
Service list changes with every restructure
If your service list changes significantly every time the organisation restructures, you are probably cataloguing teams rather than services.
No meaningful business involvement
If your CMDB or service catalogue entries were created primarily by IT staff without meaningful business involvement, there is a high chance they reflect provider logic rather than consumer reality.
Nobody outside IT references the service model
And if nobody outside IT ever references the service model in a governance conversation, it is not functioning as a management tool — whatever it may look like on a platform dashboard.
The most useful moment in service definition work
One of the most consistently valuable moments in service definition work is when a room realises that the things it has been calling services are actually a mixture of teams, systems, support groups, platforms, contracts, and intentions. That realisation feels uncomfortable at first. But it is the beginning of real clarity.
Once that mixture is visible, the organisation can start separating provider structure from service structure — and begin building a service model that is actually usable.
In my experience as a consultant, that moment rarely happens through a tool project. It happens in a structured conversation, with the right people, working through honest questions about purpose, consumers, facilities, support, and impact.
In the next article "How to get started without boiling the ocean" I will move from understanding what a service is to actually defining one. Because the next trap, after conceptual confusion, is overreaction: launching a massive service definition programme that creates hundreds of entries and very little shared understanding.
We can do better than that. And thankfully, we do not need a cathedral project to prove it.
We can do better than that. And thankfully, we do not need a cathedral project to prove it.
This Article
Article 2 in the "Raiders of the Lost Service" series by TransparIT.
Read Article 1: "Why service suddenly matters a lot more than you think."
Article 3 →
Next in the series → Article 3: How to get started without boiling the ocean.