“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 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 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 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 to relationships 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 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 have the required relationships. This is basically the same as tracking “orphan CIs”, but with 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.
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:
If all this data is maintained by discovery tools, then modelling the relationships between discovered classes may not be that fruitful. What is more important, are the links which 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. a “middleware” or other installed applications on servers.
According to the CSDM, the Business Application class is part of the “Design” domain and 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 make sure it’s connected to discovered Application records. And more importantly we ensure that all Application Services, also manually created ones, are related to Business Applications and Business Services.
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
In order to ensure that all CIs are connected to Technical Service Offerings as required by the CSDM, 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 another CIs. For example discs and memory modules should be related to computers that are then connected to services.
In this example we can use a filter on 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 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 with 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.
Thanks for reading! To find out more about Data Content Manager, please get in touch with us or book a demo!
Get Started with Data Content Manager!
We are confident that after the Free Trial you will want to continue with DCM. However, if, for whatever reason, you are not convinced DCM will by far bring more value than it costs, you simply stop using it when the Free Trial ends. There are no strings attached!