ServiceNow CSDM service modelling that supports operations

Choosing which kind of service a record represents

Teams often use the word service for four different things: a product a customer buys, a capability an internal team provides, a software application a user opens, and a technical platform that runs underneath. When those meanings are mixed in one model, an impact report can list a business service next to a database instance as if they were the same kind of thing. A service model needs a clear answer to which kind of service each record represents, because each kind has a different owner and answers a different operational question.

The three kinds usually form a chain, with business-facing services depending on application services and application services depending on technical services. The chain is only useful when each link has a named owner. Where a technical service has no accountable team, the model will show the dependency but nobody will answer for it.

Sequencing the model so it stays small enough to use

A service model can be built from the top down, starting with the business view, or from the bottom up, starting with applications and platforms. Each route has a characteristic failure. Top-down models can look complete while describing services that do not map to any system. Bottom-up models mirror the infrastructure so closely that no one outside the technical teams can read them. The more practical sequence is to begin with the services that are most often involved in incidents and changes, model those to the depth the decisions need, and extend only when a real question cannot be answered.

1. List the services that generate the most incident, change and request volume, and confirm that each has a named accountable owner.
2. For each, write the boundary in terms users recognize: what is inside, what supports it from outside, and what is explicitly excluded.
3. Decide which kind of service each record represents, and mark the records that belong to a different kind so they are not treated as the same thing.
4. Connect the supporting applications and technical services, with each relationship carrying a source and a reviewer.
5. Test the model against a recent incident or change, and extend it only where that test could not be answered.

The final step is the one that keeps the model honest. A model that has never been tested against a real event is a diagram, and diagrams tend to fall out of date quickly.

Naming services so that duplicates do not accumulate

The same service often appears under three names: the name a customer uses, the name in the project that built it and the name in the support catalog. Each name creates a record unless someone decides otherwise. The practical remedy is a naming rule that gives each service one canonical name, one or more recognized aliases, and a single owner for changes to the name. The alias list matters, because search and incident routing will still use the names people remember.

Renaming a service should be treated as a change with its own review. Relationships, owners and reports refer to the service by its record, not its label, so a careless rename can make a healthy service appear to disappear from a dashboard. The change should confirm which downstream views depend on the old name before it is applied.

Keeping the model in step with delivery change

A service model describes a moving target. New applications are deployed, old ones are merged, and responsibilities move between teams after reorganizations. A model that is reviewed only when a report is requested will lag behind by the time anyone reads it. The stronger pattern is to connect model changes to the delivery events that cause them. A new release that introduces a new integration should prompt a check on the application service it belongs to. A decommissioning should prompt the removal of the service and its relationships in the same piece of work.

Ownership should move with the service. When a team takes over an application, the application service owner should change in the same record update, and the previous owner should confirm the handover. The CMDB ownership model page deals with who decides, who corrects, who approves an exception and who reviews the result.

What a service model cannot answer on its own

A service model can tell a team which services are related and who owns them. It cannot tell the team how the services perform, whether a dependency is healthy, or whether the business outcome is being met. Those answers come from service-level and experience measures, from monitoring and from the operating review. The service level and experience management page covers how a service commitment becomes conditions the platform can measure, and the business service concept explained gives background on how business services are represented in the platform.

Equally, the model does not decide which configuration records are correct. Those records need a definition, a quality rule and an owner. The configuration item definitions page deals with defining classes, attributes, ownership and relationships, and the starting point for business services page deals with starting from service meaning and ownership before a model is expanded.

Models built for one purpose are often reused for another. A service model built for change impact may not suit incident routing or cost allocation without changes to its boundary and relationships. The application service concept explained gives background on how application services are represented, and the service impact analysis page deals with using service relationships, ownership and evidence for change, incident and availability decisions.

Questions organizations ask when they first model services

Should every application be a service?

No. An application becomes a service when a user or a business process depends on it as a distinct capability with its own owner. Many applications are components of a larger service, and modeling each one separately creates records that no one reviews.

Is a technical service the same as an infrastructure record?

Not quite. A technical service describes a capability the platform team provides, such as hosting or a shared authentication function, and it has an owner accountable for that capability. An individual server or virtual machine remains a configuration item that supports the technical service.

How do we decide the depth of the model?

Let the decisions set the depth. If a team needs to know which application is affected by a platform change, the model needs that link and not much more. If nobody has asked a question the model cannot answer, the extra depth is probably not yet needed.

Who should confirm a service boundary?

The accountable service owner, with the technical stewards confirming which items sit inside it. A boundary confirmed only by the technical team tends to reflect the infrastructure rather than the service users receive.

If a service model has several names for one service, or relationships that do not help during an incident, the service that causes the most confusion is a sensible place to begin. Contact OBLYTECH about the service whose boundary is least clear, and bring the current list of service names, the owners you already know and the last incident where the model was consulted.