Summarize the Content of the Blog
Key takeaways
The most common ITSI failure is modeling services around infrastructure teams instead of business services. It produces technically-correct health scores that answer no question anyone was asking.
A good service maps to something the business would notice if it broke. If nobody outside IT would care that it degraded, it is probably an entity, not a service.
The service tree is where ITSI's value is created. KPIs, thresholds, and dashboards all inherit whatever the model got right or wrong.
Service modeling is a business conversation before it is a technical one. If IT builds the tree alone, it will reflect how IT is organized, not what the business depends on.
Why service modeling decides everything downstream
In Splunk ITSI, a service is the unit everything else hangs off. KPIs measure a service's health. Thresholds define when a service is degraded. Health scores summarize a service. Episodes group problems within a service. Glass tables visualize services.
Which means the service model is upstream of every other decision in ITSI. Get it right and the KPIs, thresholds, and dashboards all have something meaningful to attach to. Get it wrong and you spend months building precise measurements of the wrong things.
This is why service modeling deserves more care than any other part of an ITSI deployment, and why rushing it is the most expensive shortcut available. The implementation mechanics, decomposition, KPI design, entity association, are covered phase by phase in The Complete Guide to Splunk ITSI Implementation. This piece is about the judgment behind the model.
The mistake: modeling your org chart
Here is the failure that recurs across ITSI deployments.
IT builds the service tree, and IT builds it the way IT is organized. There is a "Network" service, a "Database" service, a "Storage" service, a "Compute" service. Each is technically valid. Each has KPIs and thresholds and a health score. And collectively they answer a question nobody in the business is asking, because the business does not experience "the database." It experiences "I cannot check out" or "trades are not settling" or "the patient record will not load."
When the checkout page breaks, this model lights up "Database: degraded" and "Network: healthy" and leaves someone to manually work out that those roll up to a checkout problem. That is exactly the manual work ITSI was bought to remove. The org-chart model recreates the problem it was supposed to solve, dressed as a solution.
The tell is simple: if your top-level services have the same names as your IT teams, you have modeled your org chart, not your business.
What a business-aligned service looks like
A business-aligned service is named after something the business would notice if it failed. Checkout. Trading. Claims processing. Patient records. Order fulfillment. Then the infrastructure, the databases, load balancers, and network segments, become entities that support those services, not services in their own right.
The difference in operator experience is stark. When checkout degrades, a business-aligned model shows "Checkout: degraded, health score 40, driven by database latency." One glance gives the what and the why. The infrastructure detail is still there, but it is positioned as the cause of a business problem, not as a standalone status nobody asked about.
The test for whether something is a service: would anyone outside IT care if it degraded? If yes, it is probably a service. If only IT would notice, it is probably an entity supporting a service. Storage filling up is not a service. The order system it supports is.
How to find your real services
Service modeling is a business conversation before a technical one, and the conversation is more important than the tooling.
Start with the business, not the infrastructure. Ask the people who own outcomes what they depend on. What would trigger a call to the CIO if it broke? Those are your top-level services. They are rarely the same as your monitoring categories.
Work down, not up. Define the business service first, then decompose it into what it depends on. Checkout depends on the payment gateway, which depends on specific databases and network paths. That top-down decomposition is what lets a component problem roll up into a business impact.
Limit the first pass. Model your handful of most critical services well before modeling everything badly. A tree with five well-modeled services beats a tree with fifty half-modeled ones, because trust in ITSI is set by the services people look at first.
Involve the people who feel the outage. If IT models alone, the tree reflects IT. If the business helps, it reflects the business. The best service trees come from a room with both.
Where this connects to the rest of ITSI
Once the service model is right, the rest of ITSI has something real to attach to. KPIs measure services that mean something. Adaptive thresholds, which use machine learning to adjust to historical patterns and recalculate nightly [1], learn the behavior of a service the business recognizes. Episodes group problems within a service someone cares about. And glass tables, covered in Design Splunk ITSI Glass Tables Executives Use, visualize health that maps to business reality.
The full buyer's view of ITSI, including whether your organization is ready to model services at all, is in Splunk ITSI and IT Operations Analytics: A Buyer's Guide.
bitsIO, a four-time Splunk Partner of the Year and Splunk Elite Partner, builds business-aligned service models as part of its Splunk ITSI practice. The reason to bring in help here is not the tooling, which is learnable, but the pattern recognition from having modeled services across many businesses, which is what keeps a first ITSI deployment from becoming an org-chart dashboard. See a real outcome in this Splunk ITSI case study.
Frequently Asked Questions
