Raiders of the Lost Service – Part 1
Every IT organisation manages something. The question is whether that something has ever been clearly defined.
Article Series
The Four Articles in the Series
"Raiders of the lost service" is a four-part article series about one of the most quietly expensive problems in IT governance: the fact that most organisations are trying to manage value, risk, cost, and resilience around a concept — "the IT service" — that has never been properly identified, defined, or documented.
1
Why "service" suddenly matters a lot more than you think
The case for urgency. Why the absence of clear service definition has become an expensive problem in the current governance, compliance, and business environment.
2
What a service really is (and why your org chart is lying to you)
The conceptual reset. What a service actually is in practical terms, and why the most common substitutes — teams, applications, and catalogues — are not enough.
3
How to get started without boiling the ocean
The practical path. How to begin service definition work pragmatically, without launching a massive programme that collapses under its own ambition.
4
Where an external advisor can actually help
The honest assessment. When outside facilitation and challenge genuinely change outcomes — and when they do not.
Each article stands on its own. Together they form a complete argument for why service definition is a governance priority, not a documentation project — and how to treat it as one.
Article 1 of 4
Why "service" suddenly matters a lot more than you think
The story so far
Before we dive in — if you have not yet read the series introduction to "Raiders of the lost service", it is worth a two-minute read first. It sets out why this series exists, who it is for, and what the four articles cover together. This first article makes the case for urgency: why the absence of clear service definition has become genuinely expensive in today's IT governance environment. By the end, you should have a clearer picture of what is at stake — and a reason to keep reading.
For years, many IT organisations have managed perfectly well without being especially clear about what a "service" actually is. Not because the issue did not matter, but because it was easy to hide. You could run IT through projects, applications, infrastructure towers, support queues, and cost centres and still create the impression of control. There were systems to monitor, budgets to defend, incidents to resolve, and roadmaps to present. The machinery looked busy, and busy often passes for managed.
That is becoming much harder.
Across both private and public organisations, the pressure on IT is changing. Business leaders want clearer value. Finance wants clearer cost. Security and compliance teams want clearer accountability. Regulators increasingly expect organisations to understand criticality and impact in operational terms, not just technical ones. In that environment, "we have a good application inventory" is no longer enough. You need to be able to explain what business-relevant services exist, who depends on them, how important they are, what they cost, and what happens when they fail.
This is where many organisations discover they have a surprisingly awkward blind spot.
Ask for a list of applications, and someone will send you a spreadsheet before lunch. Ask for the cloud estate, and you might even get a dashboard. Ask for incidents by priority, change success rate, or licence spend, and the numbers usually exist somewhere. But ask a simple question like: "What are our top ten IT services, who are they for, and how do we rate their business impact?" — and the conversation suddenly becomes abstract, political, or strangely emotional.
That reaction tells you something important. It tells you the organisation is likely managing technology components and internal structures more confidently than it is managing services. And that matters because service is the unit where value, risk, and cost actually meet. A business does not care deeply about your server topology in itself. It cares whether employees can work, orders can be processed, patients can be treated, citizens can submit cases, and core operations can continue. Those are service questions.
Regulatory Context
The regulatory pressure is no longer theoretical
NIS2 & ISO 27001
Both push organisations toward understanding business impact, continuity, resilience, and prioritisation in a structured way. A proper Business Impact Analysis under ISO 27001 is not really asking whether a database is elegant. It is asking what matters to the business, how quickly it needs to be restored, what it depends on, and what the consequences are if it is unavailable.
If you have not defined your services properly, you are left trying to answer service-level questions with application-level fragments.
That usually leads to three very familiar problems:
1
Value discussions become vague
2
Risk discussions become distorted
3
Cost discussions become exhausting
Three Familiar Problems — Unpacked
Problem 1: Value discussions become vague
IT reports plenty of activity, but the business still feels unsure what it is actually getting. "We closed 12,000 tickets" is not a value statement. "We maintained secure and reliable digital workplaces for 7,500 staff" is at least heading in the right direction. The difference is not just wording. It is whether IT is presenting itself as a collection of functions or as a provider of outcomes.
Problem 2: Risk discussions become distorted
When risk is attached only to applications or infrastructure components, it often loses the business context needed for sensible prioritisation. A severe incident in one system may have very limited operational impact. A moderate issue in another may quietly block revenue, care delivery, field operations, or public service. Without services as the frame, organisations tend to confuse technical severity with business criticality.
Problem 3: Cost discussions become exhausting
Finance wants transparency. Business leaders want fairness. IT wants reality to be recognised. But if the organisation has no agreed service model, there is no stable unit for cost allocation, showback, or investment discussion. Every cost conversation becomes an argument about assumptions rather than a decision about services.
The Deeper Issue
The strategic issue underneath
What I consistently see in IT organisations is that service is often treated as an output label rather than a management object. Teams say they "deliver services", but they cannot show where those services begin and end, how they are structured, who the real consumers are, or how service changes are governed over time. That is manageable in calm periods. It becomes painful when organisations need to justify spend, respond to audit pressure, build continuity plans, or explain why one issue is more important than another.
There is also a more strategic issue hiding underneath this. If service is unclear, then IT's role in the enterprise becomes easier to reduce to cost and harder to defend as value creation. When business stakeholders cannot see clearly what services exist and what outcomes they support, IT is more likely to be judged as a budget line rather than as an operating capability. That is bad politics, bad governance, and usually bad architecture too.
This is why "service" suddenly matters more than many organisations expected. Not because the word is new. And not because another framework says so. The industry has had enough laminated frameworks to wallpaper a medium-sized municipality. It matters because the environment around IT has become less forgiving of ambiguity.
What Comes Next
What comes next in the series
This first article in the "Raiders of the lost service" series is really about that shift in perspective. Before you can improve service definition, you need to understand why the absence of service definition has become so expensive.
Article 2: What a service really is (and why your org chart is lying to you)
I tackle the deceptively simple question most organisations still dodge: what a service actually is in practical terms, and why teams, systems, and applications are poor substitutes for a proper service definition.
Article 3: How to get started without boiling the ocean
Turns diagnosis into action without the theatrics of a grand catalogue programme.
Article 4: Where an external advisor can actually help
Closes the series with an honest look at when outside support genuinely changes outcomes — and when it simply adds a layer of expensive nodding.
"Raiders of the lost service" is not a nostalgic complaint about terminology. It is a practical argument that many IT organisations are trying to manage value, risk, cost, resilience, and governance without first defining the thing they are supposedly managing.That tends not to end well. And unfortunately, no dashboard can fix a missing concept.
This is Article 1 in the "Raiders of the lost service" series by TransparIT.