You cannot have a successful CMDB implementation without discovery tools. That could be a quote from several articles or studies describing the success factors for CMDB initiatives. And sure enough, many companies get all the bells and whistles to populate their CMDB automatically.
Automatic discovery, however, is not enough to succeed. The problem lies in the very definition of discovery itself. What is ServiceNow Discovery?
“Discovery finds applications and devices on your network and then updates the CMDB with the information it finds.”
That’s great, it truly is, but what about the information it misses? For example,
- How do technical components relate to business?
- How do you establish ownership of these technical configuration items from an operational point of view?
- How do you set priorities or service levels for these records?
We wrote a practical step-by-step guide that helps organizations align with CSDM, communicate progress clearly, define required resources, and explain the business value to leadership with confidence. Read more about it here.
The Common Service Data Model (CSDM)
The Common Service Data Model (CSDM) describes the data model for the more abstract CMDB classes, like Business Applications and Services. They connect technical infrastructure to the business. However, as we know, CSDM is not a product or a solution that would do the work for you. It is just a data model.
Add ServiceMapping to the equation for more sophisticated application topologies or Service Maps. Great, but even with all these tools, parts of the big picture cannot be modeled and managed without human input.
So What’s the Problem?
To sum it up:
- You cannot succeed with the CMDB without discovery tools
- Discovery tools cannot manage all data within the CMDB.
- The Common Service Data Model provides a model but not the means to link discovered data into the abstract data classes.
- You must manually maintain at least the Service Portfolio and other logical elements (like Business Applications) on top tiers and relationships to non-CMDB data (like users and organizational structures)
- You must define and manage relationships between discovered and manually maintained data.
The borderline between discovered and manually maintained data
How to Connect Discovery and CSDM
To help understand how to approach this problem, I will describe:
- An example of discovery-populated data.
- A data model related to discovered data.
- A data model connecting discovery data to the Common Service Data Model and non-CMDB data.
- A way to ensure that the agreed data models are followed and enforced.
Managing the Borderline
One way to manage the borderline between CIs that are discovered and CIs that are manually maintained is first to define the links that connect the discovered CIs to the manually maintained CIs.
After the links have been defined, you can analyze if each record in these borderline classes has the necessary relationships in place. This is somewhat similar to tracking orphan Cis.
Suppose you have ServiceNow Discovery running horizontally over a certain IP range. Then, you have ServiceMapping to traverse relationships from top to bottom. These two can provide a comprehensive map of your application infrastructure: from servers and their components to installed applications and their connections to Application Services.
In a perfect world, this would mean that you only need to care about manually maintaining the relationships upstream from Application Services.
The rest of this article relies on this assumption.
Horizontal Discovery and top-down mapping by ServiceMapping. Image from ServiceNow.
Example Discovery Data and Data Model
This example shows how discovery tools, especially ServiceMapping, have added the following data to your CMDB for one of the application entry points:
Example data populated by discovery tools
Based on this, I’ve created a DCM Blueprint to simplify and generalize the data model so that I can run audits on my data. I’ll assume Discovery automatically takes care of the bottom part – the Discovered data. It could look like this:
While I can also audit the lower part with this Blueprint, it may not be worth it. Since we decided to rely on Discovery (and ServiceMapping) we’ll just assume the bottom part is taken care of.
As you can see, this assumption makes the Application Service class the “borderline class” when it comes to connecting discovered data to the business. With that established, we can now focus our efforts on Application Services and the upstream relationships from there.
In a similar fashion we can analyze other links that pass the borderline. These could be Business Applications and Services, and links between CIs and other data in ServiceNow, such as Users and Groups in Foundation Data, who are responsible for managing the applications and services. It is simply a matter of drawing your Blueprint to address what you want to analyze.
Examples of Connecting Discovered Data to CSDM
The borderline records in the previous example were Application Services. That is where automation usually ends. Tag-based ServiceMapping can provide a few more relationships, but even that will not cover the entire CMDB.
Nevertheless, according to CSDM, you must connect your Application Services with Business Applications and Services, which does not happen automatically. You usually maintain this data manually in the Business Application class. Also, Service Offerings, either technical or business, are manually maintained.
Finally, all these records should be owned and managed by someone. We need to assign, maintain, and validate responsibilities manually, too.
So, as we can see, even with automation in place, there is plenty of data that still needs to be managed manually.
In practice, Discovery can populate and maintain what it can find, and Data Content Manager then complements it and manages the data that Discovery can’t find.
Data Model for Business Application and Service Connections
Let’s draw another blueprint that defines the links between Application Services, manually maintained Business Applications, and Service CIs.
In the following example, I’ll use the CSDM Walk phase model for Application Services as a starting point and focus on upstream relationships and responsibilities.
Already in the CSDM Crawl phase, we want to ensure that every operational Application Service is related to a Business Application, directly or through an SDLC Component.
When “walking,” all Application Services should also relate to a Technical Service Offering, which should refer to a parent Technical Service. The data model below illustrates the above. Like all of the examples in this article, it has been drawn with the DCM Blueprint Designer, so it is an actionable DCM Blueprint you can use to audit your data.
We always emphasize the criticality of responsibilities and ownership, so we should add references to Users and Groups in the Application Service class (or for the related Technical Service Offering). Our amended Blueprint would look like this:
It’s beginning to look pretty complete, and running an audit against this Blueprint will be very powerful. With the results you can find exactly what is missing and fill the gaps.
Audit your Blueprints with Data Content Manager
When your Blueprints are ready, you can run Audits on your data. You will get very detailed results that you can use to fix any gaps or deviations.
Check out this video to see how auditing data works.
Running audits continuously on a schedule and fixing the issues it finds will ensure that data will remain in good shape and people can focus on the most important parts of your data models. After all, your data quality needs to be pretty good to use any of the more advanced capabilities provided by ServiceNow.
The CSDM defines what you should aim for, and Data Content Manager provides you with the means to get there.
Automate the Manual Parts
The best part of this method is that when you define your data quality requirements into Blueprints with Data Content Manager and schedule audits to run regularly, you’re effectively automating data quality checks for the manually maintained parts of your CMDB.
DCM will find gaps and deviations in your data, and you will know when new gaps appear. For example, new responsibilities must be assigned when people come and go.
You can automatically identify new Configuration Items (CIs) or Application Services added to your CMDB that don’t have the necessary connections and ownership details. DCM can then automatically assign tasks to the relevant people or teams to add the necessary information.
Updating and fixing gaps is much simpler (and less expensive!) than trying to correct these errors for thousands of records months later or when the gaps have already caused expensive issues.
Additional CSDM Resources
In this article, we chose to trust Discovery and ServiceMapping and only focused on CSDM and other requirements from the Application Service CIs upwards. However, in reality, we know that we cannot always rely on discovery tools to do their job perfectly and that we often have applications that are outside ServiceMapping’s scope.
So, to make this a bit more concrete, let’s look at an example: Connecting Orphan Servers to CSDM.
How to Connect Orphan Servers to CSDM
We have written extensively on aligning with the Common Service Data Model and how Data Content Manager can help ease the journey.
Here are some excellent places to start:
Please reach out to learn more!
