ServiceNow ITOM, observability and resilience with useful context

Monitoring, observability and ITOM answer different questions

Three terms are used loosely in operations conversations, and the looseness causes real planning errors. Monitoring tells a team that a measured value crossed a line. Observability is the ability to work out why a system behaves as it does, using the signals it produces. ITOM, in the sense used here, is the operating layer that connects those signals to configuration, to services and to the people who must act. A team can have a great deal of monitoring and very little ITOM, and it can have a well-designed ITOM model fed by weak signals. Teams that run most of their checks against public cloud platforms may find the cloud observability and service health page closer to their situation, since it starts from services rather than cloud objects. The two problems need different fixes.

This section is written for the head of operations who has to decide which problem to tackle first, because budget and attention rarely allow both at once. It describes how to diagnose the starting point, the order in which the decisions usually fall, and what a degraded service should look like in the records once the work is done.

The table is a diagnostic rather than a product comparison. A team that cannot answer the first question reliably should not begin with automated response. A team that answers the first question well but cannot say who owns the affected service has an ITOM gap, which no additional metric will close.

Deciding which problem to fix first

The sequencing decision is easier when it is made from the symptoms the organization actually experiences. A few questions usually reveal the starting point, and they can be answered in a short workshop with operations, service owners and the team that runs the monitoring tools. The ITOM section describes what the product area covers, from discovery and service mapping to event management, and may help the team that will run the workshop.

1. When a service degrades, does the team know within a reasonable time which service is affected? If not, the gap is in service context, and ITOM relationships come first.
2. When the team knows the service, can it find the signal that explains the degradation? If not, the gap is in observability, and the signal design comes first.
3. When the signal is found, does a named owner act on it without a search through several chat channels? If not, the gap is in ownership and response rules.
4. After an event, does the team learn which context was missing? If not, the review process is the gap, and it is cheap to start even while the other fixes are underway.

Many teams find that the first question has the weakest answer, because service context was never built out beyond a small set of critical services. Starting with the context gives the other fixes a target. Starting with more signals when the context is missing tends to produce a larger pile of alerts about components that nobody can place in a service.

What a degraded service looks like in the records

A degraded service should be visible in the records as a change of state, linked to the components that are affected and to the owner who must respond. That sounds obvious, but many estates record degradation only in the monitoring tool, while the service record continues to show the service as healthy. When the service desk takes a call, it has to check two systems and reconcile them by hand.

The aim is a record that says, in plain terms, which service is degraded, which supporting components are implicated, what evidence supports that view and who owns the response. Where the evidence is partial, the record should say so. An inferred link between a component and a service is useful for triage, but it should be labeled as inferred rather than presented as established fact, because the next decision may depend on that distinction.

Owning the correction as well as the detection

Detection is the part of ITOM that gets funded. Correction is the part that gets neglected. A signal that identifies a fault has done its job only if someone is responsible for the fix, for the change to the monitoring that prevents a repeat, and for the record that was wrong. Without that ownership, the same fault returns after every release, and each recurrence is treated as new.

The useful distinction is between three kinds of ownership: the owner of the signal, who keeps the check accurate; the owner of the service context, who keeps the relationships current; and the owner of the response, who decides what happens when the signal fires. These can be the same team in a small organization, but they should be named separately in any design, so that a gap in one of them is visible.

Testing resilience without waiting for an outage

Resilience work tends to be judged by the outage it prevents, and that is a poor test because outages are rare and unpredictable. A better approach is to test the operating model against conditions that are predictable: a noisy signal, a missing relationship, a degraded dependency and a service whose owner is unavailable. Each test shows whether the model produces a clear next action, and each failure points to a specific gap.

• A noisy condition, to check whether repeated signals are grouped without losing the first one.
• A missing-context condition, to check whether the signal still reaches a team that can add the context.
• A degraded-dependency condition, to check whether the affected services are identified and their owners notified.
• An unavailable-owner condition, to check whether the escalation route works without a person who is absent.

These tests can be run on a planning workshop or a tabletop exercise, using recent real events as the starting material. The output is a list of gaps with owners, which is more useful than a score.

Where ITOM work stops

An ITOM program does not make a fragile application dependable, does not remove the need for capacity planning, and does not replace the engineering work that fixes causes. It makes the operating response faster and more accountable, and it makes the next decision about investment better informed. Those are worthwhile outcomes, but they should be described as such. A buyer who is told that ITOM will prevent outages should ask what evidence supports the claim and which part of the estate the claim covers. Other services that sit alongside this one are listed in the ServiceNow solutions overview.

Service level measurement is a closely related concern. Where the organization already reports against service levels, the ITOM model should feed those reports rather than run a separate version. The service level and experience management page covers how a service commitment is translated into conditions the platform can measure.

Questions a head of operations should ask

Should observability tooling be replaced before ITOM is designed

Not usually. Replacing tooling before the context model exists tends to move the same gaps into a new product. The design question should come first, and the tooling decision should follow from the requirements it produces.

How much service context is enough to start

Enough to answer the first question for the services that matter most: which service is affected, who owns it and which components it depends on. A complete model of every service is not a starting requirement, and waiting for one usually delays the work indefinitely.

How is impact analysis related to ITOM

Impact analysis uses the same relationships to answer a planning question before a change. The service impact analysis page covers the use of service relationships, ownership and evidence for change, incident and availability decisions, and ITOM depends on the same relationships to answer an operational question during a fault.

What should a provider show before describing an ITOM route

A provider should be able to show the decision it starts from, the context it will check, the ownership model it proposes and the tests it will run.

Next step for an ITOM and observability review

You can discuss your ITOM and resilience priority with OBLYTECH. The four questions earlier on this page indicate whether the next investment belongs in service context, signal design, ownership or review.