How to Ensure Server CI Relationships Exist

Most ServiceNow customers have Servers in their CMDB. The Servers are often automatically populated by ServiceNow Discovery, through integration from another discovery tool or a vendor CMDB. However, CI relationships are usually not created automatically, and that is problematic.

Keeping track of Server CIs even without upstream relationships can be valuable from an asset and lifecycle management point of view. However, the real value of Server CIs becomes available when they connect to the Applications and Services that depend on them.

These relationships enable Business Impact and Root Cause Analysis as part of, for example,  Incident, Change, and Problem Management processes.

Server CI Relationships According to CSDM

The Common Service Data Model defines how Servers should be related to Business Applications through Application Services. This relationship enables Root Cause Analysis for issues recorded against Applications already in the CSDM Crawl phase.

The addition of Technical Service relationships through Technical Service Offerings in the CSDM Walk phase introduces an operational service aspect to running the Servers. And finally, in the CSDM Run phase, Business Services are related to Servers through Business Service Offerings and Application Services to enable Business Impact Analysis.

A Blueprint drawn with Data Content Manager that contains all of the above-described relationships would look like this:

Ensuring Required CI Relationships are in Place

Unfortunately, integrations populating the Server data usually do not create the required upstream CI relationships. Tools like ServiceMapping can help but do not give you a 100% guarantee. Something else is needed to verify that the required relationships exist.

With Data Content Manager, it’s easy to define what is required. Furthermore, it is also easy to define who is responsible for ensuring those requirements are met.

The above data model diagram is an example of a rather complicated DCM Blueprint that covers the entire CSDM as it is prescribed to Servers. However, to get started, we can narrow it down to the CSDM Crawl phase model and only include details that can be assigned to one person or a group.

The simplified DCM Blueprint below defines a Server’s responsibilities and its relationship to Applications or Application Services.

When this DCM Blueprint is used to run an Audit in Data Content Manager, the Audit will check that every Server has the following:

• An active user and group managing it.
• An upstream CI relationship to either an Application Service or an Application.
• Selected manually maintained attributes in place.

Real Life Scenario

Let us assume that an active integration populates the basic details for a Server. For example, these details could include a Fully Qualified Domain Name, Serial Number, CPU details, Operating System, etc.

We would create one Blueprint that checks that these details exist in the CMDB – in effect, monitoring the quality of the data coming in through the integration. (Read more about Integration Data Quality here.)

Then we would create another Blueprint similar to the one above. That Blueprint would check the user and group managing a server. In addition, this Blueprint would check that the necessary CI relationships exist.

Two Blueprints for Two Points of View

By creating two Blueprints, we can clearly separate and track the automated and manually maintained parts. It is particularly beneficial if the responsibilities lie with different people. For example:

• A vendor provides the basic Server information. The quality of their efforts is tracked and measured by a Blueprint focused on the integration. You can give the vendor clear guidance for addressing deviations.
• Your people should maintain the Managed By details and the CI relationships. The other Blueprint would help them do their job more efficiently since the Audit results would clearly show where gaps exist.

Even if the same people are responsible for the integration and manually maintained data, keeping these blueprints separate is a good idea. It’s also worth noting that when creating these Blueprints, you are documenting your CMDB and integrations at the same time.

As an outcome, responsibilities are clearly defined. Data quality gets managed in real-time, so when deviations are found, it is clear who is responsible for fixing them. All stakeholders get a continuously clear view of data quality in the CMDB, also over time as seen below.

Try This in Your Instance

We offer a guided trial of Data Content Manager where we help you set up the tool and walk you through the basic steps of getting and interpreting results. This way, you do not need to spend time learning the product and can focus on seeing how you can benefit from it.

If you have current data in your non-production environment, running these Blueprints in it will give you one-time tangible results you can already use.

Other than the few hours you will spend with us, there is no cost or commitment. Schedule a meeting with us to get started!