In the world of Monitoring, Observability and lately AIOps, the focus in recent years has been primarily on the operational side of the infrastructure and applications. Interest in the services that these capabilities support has been mostly incidental, and either left for the IT Service Management teams to sort out or was tacked on as an afterthought. Some effort was made by large ITSM platforms that also did monitoring to marry these two intrinsically different worlds and allow service owners to gain insights into the service health, but these platforms still had to deal with the purely technical nature of traditional monitoring shops.

Upsetting the applecart

The new kid on the block – OnePane – however seems intent on upsetting the apple cart, as it designed its capability around a Configuration Management System with a CMDB standing central to their solution and natively leveraging off a service-based data model to provide exactly what Service Owners and CIOs have been requesting for more than a decade – a true service-centric operational platform that gives service owners, IT leadership and business a view of the actual state of their services in real-time.

At the heart of OnePane’s ability is a tactical Configuration Management System. The OnePane CMS enables OnePane to understand a Service and all the components and impact relationships captured by the CMS, and because it understands the Service, can concentrate on the relevant data relating to the service when analysing an anomaly in the system. By doing that OnePane is able to better understand root cause and therefore is able to do what it uniquely does – improve the time that it takes to diagnose the Service and pinpoint the areas creating the anomalies

Defining a CMS and a CMDB

So what are Configuration Management systems really about when you leave behind all the jargon and the intricate mumbo-jumbo of the professional CMDB/CSM builder? In essence the CMS is a system that contains a database and supporting systems used to capture and maintain the information that your organization need in order to ensure that all the various processes and systems that depends on such data have it available when needed.

A CMDB itself would relate to the database that contains this information while the CMS would have various technologies and interfaces that allows the people and systems that need to populate, maintain or consume the information contained in the CMDB.

CMDB

An example of this differentiation would be to use a popular ITSM platform like ServiceNow to illustrate the differentiation between the CMDB and the CMS. The ServiceNow CMDB is a hierarchical set of tables that contains CI classes that have attributes that are set according to the type or class of CI. The ServiceNow CMDB makes use of inheritance and any CI class that is in a child table of a higher order CI class will contain the attributes of the parent CI plus the unique attributes of the specific CI class. Any CI that is added to a specific class will have the attributes available for population that is relative to the CI class. An Example would be the Server Class. The Server class acts as the base class for the various types of servers. A Linux Server or Windows Server, would be in subclasses of the server class and inherit all the attributes of the parent class, and then have specific attributes related to a Linux server or a Windows server.

CSM

The Configuration Management System on the other hand would include the CMDB, but then have tooling that will support the CMDB. Examples of this from the ServiceNow world are Discovery and Integrations that populate the CMDB form part of the CMDB. Then the Reconciliation and Normalization engine ensures the quality of the Cis and helps prevent duplicates. A front-end for the CMDB - the CI Class Manager, CMDB portal and CSDM Dashboard allows you to interface with the CMDB for various purposes. These are examples of what your tools are to maintain and manage a CMDB and form part of the CMS.

Tactical use of a CMS

One of the things that has become clear to me over the years is that a CMS and CMDB would not necessarily be configured to implement all capabilities possible for a CMS. A CMS would be implemented to support the functions or processes that consume the CMDB data. Examples of this would be a CMS which is not intended to be consumed by and integrated Incident Management platform or would not be used for Change Management Impact assessment such as the CMS built into ServiceNow. In the period between 2008 and 2014, I worked on several tactical CSMs used to address specific tactical issues such as impact determination for monitoring platforms. The CSM in one of those cases was not even integrated to an ITSM platform from the same vendor.

Does a tactical CMS work with a “classical” ITSM-focused CMS? Yes – most definitely. In the Example of the tactical CMS implementations I mentioned before, the CMS was used to improve Event Management. The Cis were discovered, normalised and populated into the CMS and Services relationships to Services were defined. That provided the possibility of creating events in a different context. Instead of logging an incident for a CI (server, application, network infrastructure) the combination of an understanding of the CI’s context allowed an Incident to be logged in the context of a Service. So you could log an enriched event stating something like “The server ABC has run out of memory impacting on the following services”. This added context to the incident that describes the impact on the services. An integration of the resultant event to the ITSM platform’s Incident Management platform becomes much more meaningful as you are providing context that can be used in the ITSM platform to then do auto-assignment of the incidents.

The synchronization of the CMDB information contained in the tactical CMDB could update

the ITSM platform’s CMDB through an integration which in turn would assist in the mapping of Services to allow Change Management Impact calculation. The added benefit is that such a tactical CSM would be platform agnostic.

Benefit of building a platform-agnostic AIOps platform on a tactical CMS

The benefit of building a separate platform-agnostic CSM for monitoring is pretty clear and in the cases where I was involved in implementing such systems – specifically for IT Operations Management - is quite compelling. Examples of the benefits of using a tactical CMS with a AIOps platform are many, but examples are:

Being able to update the CMS automatically in real time without being limited by the desired, change-approved state. This allows you to monitor the actual state of the services as they are changed and deployed.

It allows for relating changes in the infrastructure to outages even if the change did not go through a formal change process.

It allows for proactive integrations to monitoring tools, cloud platforms to collect log entries, incidents and events for related data even if the monitoring tools are not service-aware.

It allows for concentrating key data related to a service and to an incident that could otherwise be missed that could assist in restoring the service more rapidly

It could relate data that might not be found in a traditional ITSM platform as data can be used from more sources than just the ITSM platform and the CMDB.

It offloads processing of CI data and Events from your ITSM platform improving efficiency and performance of your ITSM solution.

When combining a CMS with modern technologies like AI the value of such a system becomes even more compelling. OnePane is a good illustration of how context of a service relationships in a tactical CMS combined with AI can be leveraged to create a qualified Incident providing the Root Cause.

Look out for my next blog, where I will explain how OnePane leverages off its CMS and uses AI to create a qualified Service incident.