Implementing a self-healing ServiceNow CMDB with high-quality data

6 minutes

Recently, I was at a ServiceNow convention where the speaker on stage asked the audience a simple question: “If you have a high-quality CMDB, please raise your hand?“ Out of the >200 attendees, only 2 people raised their hands! The other >198 people looked at them in disbelief. The conclusion: in large enterprises today, high-quality CMDBs are a very rare phenomenon.

A high-quality CMDB is worth pursuing

The situation described above could lead you to say that having a high-quality CMDB is simply not something worth pursuing. But the complete opposite is true! Simply put, if you don’t know what you have, you will not be able to manage it. A high-quality CMDB enables CIOs, IT Operations and other leaders to meet their objectives. The obvious benefits lie in the area of improving security, costs, performance, risk, stability, end-user happiness, etc.

Build a solid CMDB business case focused on waste

What is often overlooked is the measurable waste related to not having a high-quality CMDB, like time wasted when you have to:

  • …send out emails to the whole organization requesting information (“Who is impacted by this change?”).
  • …manually extract and reconciliate data from multiple sources.
  • …manually keep multiple data sources up to date.

My advice: if you want to convince your leadership to invest, then build a solid business case based on the time that will be saved when having a high-quality CMDB.

Webinar invite: How to establish a self-healing CMDB using CSDM - Register now

Staying away from pitfalls

Why is it so hard to implement a CMDB with high-quality data? During my conversations with senior IT leaders, my conclusion is that we (also at Plat4mation) have been stumbling into the same pitfalls over and over again:

  • Trying to centrally solve the problem
    A common strategy is to assign a central CMDB Manager and make that person accountable/responsible to deliver a high-quality CMDB. The problem is that CMDB managers don’t have the mandate to enforce others to deliver high-quality data, which makes their task a mission impossible.

 

  • Too much focus on the data
    We’re too focused on the CMDB data model, which does not help in filling it with high-quality data.

 

  • Approaching it as a technical problem
    Once the data model is defined, we then shift our focus to finding the sources to populate the model. We spend a lot of time setting up Discovery technology and building integrations to obtain the data. The problem here is that extracting CMDB data from other sources means that your CMDB will never show the real-time status. An even bigger problem is that you will never really know if your CMDB contains all your organization’s CIs. After all, “you don’t know, what you don’t know”!

A self-healing CMDB, how is that possible?

A self-healing CMDB capability is built up from several components that are all needed to create the self-healing effect. But, it all starts with a solid foundation:

  • Governance
    Setting up a proper CMDB governance and operating model is a crucial first step. A key success factor is to get Executive sponsorship in place and to make sure that CMDB data quality is embedded into existing governance routines.

 

  • Ownership
    The ownership for CMDB data quality should be assigned to the right people in the organization. The right people are those managers of the departments/teams that actually deliver the digital services that result in changes in the CMDB (not the CMDB Manager!).

 

  • Definitions
    Document your data model:
    • Document ownership
    • Document properties (attributes)
    • Document acceptable property values
    • Document data quality controls
    • Document data sources
    • Document CRUD processes and agreements
    • Document discovery / IRE configuration
    • Document relationships

 

  • Lifecycle workflows
    CIs don’t suddenly start to exist because they appear in a discovery run. They start to exist, change and become obsolete as a result of lifecycle workflows like changes, standard changes and service requests. Make sure your lifecycle workflows are designed in way that CMDB changes are immediately visible. This will prevent the situation of “You don’t know, what you don’t know”. Also, make sure to implement audit and repair workflows that make sure data owners take the steps needed to act on quality deviations.The road to a self-healing CMDB

 

 

This was the first blog in a series, in which I share Plat4mation’s best practices to implement a high-quality CMDB. Stay tuned for more detailed stories where I zoom in on the various elements mentioned in this blog.

Elmer in handwriting font

Contact person

Elmer de Valk
Chief Executive Officer (CEO)
+31 (0)30 76 02 670

Get in touch