IT Service Operations · CMDB & SAF
Know What You Run.
Every stage of the operations loop asks the same three questions: what is this, what does it depend on, and who answers for it. The CMDB is where those answers live. Or fail to.
The configuration management database is not a stage of the loop. It is the ground the loop stands on: the shared map of services, applications, instances and infrastructure that detection watches, observability traverses, AIOps reasons over and service management routes by.
Get it right and every stage moves faster. Get it wrong and every stage guesses. Most estates are guessing.
The Problem
A Map Nobody Trusts.
You have heard the story, or lived it. The programme launched with a big scope and a bigger licence. Discovery was pointed at the estate and filled the database with everything it could see, which is not the same as everything that matters. And nobody was named to keep any of it true.
Then came the night it was needed. Someone pulled up the record mid-incident and it was wrong: the owner had left, the dependency was stale, the server was decommissioned a year ago. One wrong answer at three in the morning is all it takes. Trust dies, spreadsheets bloom, and the map rots quietly while everyone routes around it.
Every enterprise has a CMDB, almost none of them trusts it. That is why the industry's most important database is also its most abandoned.
“A database of everything is a map of nothing.”
A CMDB fails socially before it fails technically. Too much data, too little ownership, no connection to the processes that should keep it honest. A database of everything is a map of nothing.
What It Actually Is
The Heartbeat Of Service Operations.
The distinction is everything. A list of configuration items is stock-taking. A CMDB earns its keep through relationships: this service consumes that application, which runs on these instances, which live on that infrastructure, and every layer carries a name against it.
Two models make that real. A service data model that puts services at the centre and maps everything else in relation to them. And an operating model that wires named owners and accountable teams to every service, inherited down the stack, so a record is never just data. It is data somebody answers for.
An asset register tells you what you bought. A CMDB tells you what you run: how it connects, what it serves, and who answers for it.
The test is simple. Pick any service that matters and ask: what does it depend on, who owns it, what breaks if it changes. If the answer lives in the estate, you have a CMDB. If it lives in someone's head, you have a rumour.
Why Service Operations Needs It
Every Stage Asks.
The Service Operations loop runs on context, and every stage draws it from the same place. Starve the map and you starve the loop.
Observability asks: what does this depend on?
The cause is rarely where the symptom shows, and following a request across an estate takes a map of the estate. Service topology is what turns telemetry into cause.
AIOps asks: do these alerts belong together?
Correlation is only as good as the context beneath it: which signals share a service, which service just changed, who owns the decision. Feed the engine a true map and it stops guessing.
Service management asks: who owns this, and what happens if we touch it?
Routing, escalation, change risk, major-incident blast radius: every one of them is a CMDB query wearing a process costume.
The toolchain asks: do we all mean the same thing?
Monitoring, observability, AIOps and ITSM can only run as one system if they share one definition of a service. The CMDB is that shared language, and the reason a signal raised in one tool lands as context in the next.
Feed the loop from one map and every stage sharpens. Feed it from five spreadsheets and every answer arrives late, twice, and different.
The OOTB Framework
SAF Out Of The Box.
SAF gives an estate two things on day one. A five-tier service structure, business service to IT service to application to instance to infrastructure, so technology maps to logical groupings rather than floating free. And a target operating model that puts named owners and accountable teams against every service, inherited down the stack.
That pairing is what makes automation fire. Incidents route to the right team without a human deciding. Escalation follows a chain somebody actually defined. Change approvals find their approvers, impact analysis traverses real relationships, and certification puts a cadence on keeping it all true. The manual decisions that eat operations time simply stop being manual.
It is a strong baseline, and honesty about baselines is the point of this page. At enterprise scale a linear model starts to creak: the IT service layer becomes the drawer everything gets shoved into, business consumption blurs with technical delivery, and the model has no language for strategy, tiers or the customer's actual experience. That is not a reason to skip SAF. It is the reason we extended it.
You do not have to invent the model. SAF, HaloITSM's Service Automation Framework, ships a proven starting point: a service-centred data model and an ownership model, ready to run.
Halo's out of the box SAF model
Business Service
A service tailored for business sponsors that supports customer interactions or internal business processes. It aligns with recognised business capabilities understood by both business and IT departments.
IT Service
A technological facility or process supporting one or more business services. It is an abstract layer managed by IT to provide specific technology outcomes.
Application
The logical representation of end-user software designed to facilitate specific business capabilities. This is the overarching application entity rather than a specific installed version.
Instance
The physical deployment of a business application encompassing its specific environment, geography, or business line.
Infrastructure
The physical and logical configuration items serving as the foundation for business application instances.
The dotslash Models
From Stack To Strategy.
The dotslash Extended Models take the framework the rest of the way: from a map of the technology to a map of what the technology is for.
The standard model.
The standard extension builds a clean bridge between what the business consumes and what IT operates. It connects the commercial reality of your services directly to the technical reality of your stack. Above it, two new layers: Business Capability at the apex, so technology investment maps to strategy, and Business Offering beneath it, so the same service can carry different tiers, packages and support levels with real commercial control. Below the line, the congested IT service layer is retired. Technical Services move adjacent to the stack, supporting applications and infrastructure without ever cluttering the catalogue the business sees.
The advanced model.
For estates where the user's experience is the business, the advanced tier adds two more layers: the User Journey and its Steps. Now the model knows not just that an application failed, but what the user was doing when it did. A database outage stops reading as "backend degraded" and starts reading as "customers cannot complete payment inside placing an order". Major incidents get prioritised on actual business disruption, and the gap between a technical alert and a customer's experience finally closes.
Get your copy of our CMDB Whitepaper.
Engagement
Start Where You Are.
A dotslash engagement starts with the same blunt test we would give any estate. Pick three services that matter and ask: what do they depend on, who owns them, what changed on them this week. If the answers take a meeting, we have found the work.
A CMDB is not a project with an end date. It is an operating discipline, and we build it to the maturity you actually have, not the maturity a slide deck assumes.
Then we make it real, in stages. The model stood up service-first. Scope governed by value: the critical few in, the trivial many out, every class earning its place with a business justification. Ownership federated to the people who actually run things, certification on a cadence so truth has a heartbeat, and the step up to standard or advanced when the estate earns it, not before.
One Map, One Loop.
Detection, understanding, decisions, action, learning: five stages, one question underneath them all. Does the estate know itself?