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:
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.
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.
Book a Demo With Us to Get Started!
Get a Free Guided Trial
To see how Data Content Manager works in your own environment, please request a Guided Trial from us. A Guided Trial allows you to experience the power of Data Content Manager in your own ServiceNow instance, with your own data. We will guide you through installation, creating Blueprints, running Audits, and interpreting results.
The results are yours to keep.
There’s no cost or commitment since we know this is the easiest way for you to experience the power of Data Content Manager.
