“You cannot have a successful CMDB implementation without discovery tools” could be a quote from several articles describing the success factors for a CMDB initiative.
And sure enough, many companies get all the bells and whistles to populate their CMDB, but how do these technical components relate to more abstract entities such as Business Applications and Services? Or how to take ownership of these data records from an operational point-of-view?
“Discovery finds applications and devices on your network, and then updates the CMDB with the information it finds.”
What is ServiceNow Discovery?
The Common Service Data Model (CSDM), v2.0 published by ServiceNow in late 2019, describes the data model for these more abstract CMDB classes. But as mentioned in the whitepaper, the CSDM is not a product or a solution that would do anything for you. It is just a model, even though it is a very good one.
Some more sophisticated tools can even map application topologies (and call them service maps), but at least for now, there is always one or more parts of the big picture that cannot be modeled and managed without human input.
To sum up the problem:
- You cannot succeed with the CMDB without discovery tools (according to multiple studies)
- 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
- At least the Service Portfolio and other logical elements (like Business Applications) on top tiers and relationships to non-CMDB data (like users and organizations structures) are manually maintained.
- You need to define and manage relationships between discovered and manually maintained data.
Borderline between discovered and manually maintained data
In this blog, I will describe:
- an example of discovery-populated data
- a data model related to Discovery data
- data models connecting discovery data to the Common Service Data Model and non-CMDB data
- how to ensure that agreed models are being followed
Managing the Borderline
One way to manage the borderline between discovered and manually maintained CIs is first to define the links that connect the discovered CIs to the manually maintained CIs. And then start tracking that each record in those borderline classes has the required relationships. This is basically the same as tracking orphan CIs, but with an exact focus on particular use cases.
Let’s imagine that you have a ServiceNow Discovery and/or ServiceMapping products in use. These two can provide a detailed map of your application infrastructure, from Servers and their components to installed applications and their connections.
Example Discovery Data and Data Model
In this example, the Discovery tools have created following data into your CMDB for one of the application entry points.
Example data populated by discovery
These records belong to at least 7 different CI classes and if we simplify and generalize the related data model a bit, it could look like this:
DCM Blueprint example for discovered data
If all this data is maintained by discovery tools, then modeling the relationships between discovered classes may not be that fruitful. What is more important, are the links that pass the borderline i.e. the links between discovered and manually maintained CIs and links between CIs and other data within the ServiceNow platform.
Good examples of other data are Users and Groups responsible for managing the services.
Examples to Connect Discovered Application Data to CSDM
In the real world, the topmost records in the previous example are related to business applications. Few words about them
- Application Service class represents a logical application stack for a particular Business Application.
- Application class often represents e.g., “middleware” or other installed applications on servers.
According to the CSDM, the Business Application class is part of the Design domain and is used mainly for Application Portfolio Management and Enterprise Architecture purposes. In most cases, the data in the Business Application class is manually maintained. Relationships to service portfolio should be done on the Application Service level, according to the CSDM.
Let’s draw another blueprint that defines the links between discovered application data and manually maintained Business Application and Service CIs.
In the following example, we connect the discovered application to manually maintained data. Starting from the Application Service class, we want to ensure it is connected to discovered Application records. More importantly, we ensure that all Application Services, also manually created ones, are related to Business Applications and Business Services.
DCM Blueprint example for connecting discovered application data to CSDM
But what should we do with the rest of the discovered data? Or what is important for all CIs?
Connecting all Discovery Data to Technical Services
To ensure that all CIs are connected to Technical Service Offerings as the CSDM requires, we can create a more abstract data model to define how this should be done. Discovery tools can populate a lot of data into different CI classes. And one thing to consider also is that some CIs are connected to services via other CIs. For example, discs and memory modules should be related to computers that are then connected to services.
Connecting all CIs to technical services
In this example, we can filter the Configuration Item class to select which CI classes should follow this model (or exclude the ones that should not). And for the Service Offering, we can also add a filter saying it should be of type Technical Service.
With these two blueprints above, we can ensure that:
- All discovered applications are connected to business services and business applications.
- All other discovered CIs are connected to Technical Service Offerings responsible for maintaining, supporting, and managing them.
- All CIs have proper responsibilities in place as references to users and groups.
Running continuous audits against these blueprints will make sure that data will remain in good shape and people can focus on the most important parts of the data model to enable the wonderful capabilities provided by discovery, especially when connected to the new Common Service Data Model.
Data Content Manager can help to ensure quality data
With Data Content Manager (DCM), one can draw a blueprint matching the data models shown above and simply run an audit to check how accurate and up-to-date your current data is. Audit results can be shown per audited record (an application service, for example) or Blueprint element (“Depends on::Used by” link between an Application Service and a Service Offering, for example) to see which data to fix.
DCM Audit Dashboard
Additional CSDM Resources
We have written a lot 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 us if you have any questions!
