Being able to perform Root Cause Analysis in ServiceNow is essential. However, it is not always clear what is required to gain the ability to do it for Application Services, since they are not self-evident for many ServiceNow users to begin with.

In this example, I will focus on ensuring that you can perform Root Cause Analysis for Application Services in your ServiceNow instance. For many ServiceNow customers, Application Services are something new, and the first challenge is often understanding what they are. Furthermore, it is not always clear how Application Services differ from Business Applications, Services, or plain Applications.

Often, it is problematic that many of the details that make up an Application Service exist in a mixture of CI Classes and classifications that may have been used long before the existence of the CSDM. Therefore, taking Application Services into use might mean splitting, transforming, and merging existing data into tables defined by the CSDM. At the same time, new concepts need to be introduced to the people maintaining the data.

Ensuring your Application Services are ready for Root Cause Analysis is a quick and easy use case for DCM. You can try it for free in a Free, Guided Trial with us. We will help you set up DCM, provide the Blueprint template discussed below, and run the audits described below together with you.

Let’s take a closer look.

What are Application Services

ServiceNow has done a good job explaining the concepts in the CSDM reference materials and explanation videos like this one. The definition of an Application Service, according to the CSDM white paper, is

“An Application Service is a service type that is a logical representation of a deployed system or application stack” – CSDM White paper v4.0

In practice, Application Services are the glue between Business Applications, Services, and Technology. Different types of Application Services are available for various population methods, such as Top-Down Discovery and Tags (related to ServiceMapping), Dynamic CI Groups, Dynamic Service, and manually connecting underlying IT infrastructure and upstream business relationships to Application Services.

Since, according to the CSDM, Business Applications are not operational records, you need Application Services to represent them in operational service management processes like Incident, Problem, Change, and Request Management.

Application

An Application is any deployed program, module or group of programs, that is designed to provide specific functionality on a compute infrastructure

Application Service

An Application Service is a service type that is logical representation of a deployed system or application stack

Business Application

A Business Application represents all software and infrastructure environments (Dev, Test, Prod) configured to provide business functionality

Root Cause and Business Impact Analysis

This brings us to the question of Root Cause Analysis. If Business Applications should not be directly related to Incidents and Problems, then Application Services are the top-most record in your CMDB hierarchy for this purpose. Users tend to report incidents against what they know and see. This means the applications they are using, even though the issue is probably somewhere underneath.

The opposite is also true when talking about Business Impact Analysis. Automated monitoring systems, for example, report alerts against servers and other infrastructure components. Understanding the impact of a failure or a planned change requires servers to be related to Application Services and, from there, to Business Applications and Services.

So how do you get to the Root Cause if you can’t start from the Application Service and find your way down to infrastructure CIs through valid CI relationships?

What is needed from Application Services?

The quick answer is the relationships themselves. They need to exist, especially regarding Root Cause and Impact Analysis. CSDM guides us here – it defines a different model for Application Services for every implementation phase:

 

  • The Crawl phase requires Application Services to have an upstream relationship to a Business Application and some relationships to the underlying IT Infrastructure.
  • The Walk phase adds Technical Services and Offerings into the picture.
  • The Run phase does the same on the business side.
  • The Fly phase doesn’t add any more details or relationships to Application Services but focuses on the maturity of the related services and could impact how Application Services are related to services and infrastructure.

Turn the Requirements into a Blueprint

When you turn the requirements for the Crawl phase into a DCM Blueprint, it will look like this:

Application Services Crawl Blueprint

The Blueprint above defines the precise requirements that every Application Service should have:

  • A responsible person – an active user in your instance – or a group defined.
  • Upstream relationships to the Business Applications consuming them.
  • Downstream relationships to the IT infrastructure they depend on
  • Some manually maintained attributes like “Environment” that define whether the Application Service represents a Production instance or a non-production instance.

In the above example, we have defined the downstream CI relationships so that Application Services should have either a “Depends on” relationship to an Application CI, or a “Runs on” relationship to a Server.

Related to this, you could run another simple DCM use case to look at things from another perspective – see How to Ensure Server CI Relationships exist. You can run both of these use cases in a Free Trial.

Considering different Population Methods for Application Services, we added the “Service Configuration Item Association” [svc_ci_assoc] relationships to the downstream “IT Infrastructure Relationships” requirements to include relationships discovered by ServiceMapping.

Run an Audit Against the Blueprint

When you run an Audit with DCM against this Blueprint, the results will immediately tell you if your ITSM processes can do Impact and Root Cause Analysis or simply relate incidents, changes, and problems to correct applications on an operational level. Below is an example of the “Blueprint Elements View” for Audit results. It clearly shows which relationships are still missing.

Audit Results

When you drill into each of these, you will get the precise details to know what you need to fix and you can automatically create tasks for responsible people/groups. Then, they can fix the issues in DCM using the built-in Data Content Planner module with a visual tool based on the Blueprint itself.

It really is that simple.

Try it in Your Instance

Running this exercise requires DCM to be installed in your ServiceNow instance. However, we offer a Free Trial that you can run in any non-production ServiceNow instance. Furthermore, we can help you set everything up, including creating the Blueprint with you, so that you can see the results from your instance with minimal effort.

There is no cost or commitment apart from the few hours you would spend with us. As for the results, they are yours to keep. If your non-prod instance has real data to try this with, the results will be real, too. You can use the results as you see fit.

To get started, please book a 1-hour demo session with us. We will show you how Data Content Manager works and iron out the details to get this use case on the way with the Free trial.

More Use Cases for a Free Trial

We have developed several simple Use Cases that are powerful and can have a real impact. You can run them with our assistance using our Free Trial, which is available for 30 days in a non-production ServiceNow instance. 

When you begin a Trial with our assistance, we will help you set DCM up, and will bring along the Blueprints to run any of the Trial Use Cases below.

We will walk you through the Trial so that you can experience the power of DCM without having to invest time into learning all of the features yourself. 

Get in touch with us to get started!

Share This