How long has the configuration management database (CMDB) been the subject of IT service management (ITSM) debate? I know it was a hot topic when I first became an industry analyst back in 2008, with the CMDB held up as the must-have thing for organizations wishing to improve their ITSM maturity (and with it their operations and outcomes). But there were also horror stories told of the investments that large companies, in particular, had made in CMDB initiatives that failed.
I was recently reminded of the common CMDB issues in a conversion with Kaustubh Jhunjhunwala (KJ), 1E’s Product Manager for the ITSM Service Delivery solution within Tachyon. He confirmed that organizations still struggle with CMDBs and that “The completeness and correctness of the data within a typical CMDB implementation would reach agreed-on levels but then, over time, these typically nosedive because there’s a lot to maintain.”
To help your CMDB thinking, and success, this article offers up three ways in which to rethink your organization’s use of its CMDB(s).
To help your #CMDB thinking, and success, this article by @StephenMann offers up three ways in which to rethink your organization’s use of its CMDB(s). #ITSM Click To TweetCMDB best practices under the microscope
If you look at the more recent bodies of ITSM best practice guidance, such as ITIL 4, then you’ll see that much of the thinking around the CMDB and what’s now called the service configuration management practice is similar to back then.
There’s the CMDB or configuration management system (CMS) – “A set of tools, data, and information that is used to support the service configuration management practice.” (Source: AXELOS, Service Configuration Management ITIL 4 Practice Guide, 2020) – in place to hold accurate and reliable information about the configuration of services and the configuration items (CIs) that support them. This information, in the form of service configuration models, can then be employed in ITSM tasks such as:
- “Impact analysis
- Cause and effect analysis
- Risk analysis
- Cost allocation
- Availability analysis and planning.”
Source: AXELOS, Service Configuration Management ITIL 4 Practice Guide, 2020
However, a key change to the older ITIL best practice – and in line with the ITIL 4 Guiding Principle of “optimize and automate” – is that the service configuration management practice should be highly automated. Gathering data from multiple sources using technology, rather than manually, whenever possible. It sounds great, using technology to pull vast amounts of infrastructure and service-related data into the CMDB or CMS, but then there’s also the concept of “infrastructure as code”…
Rethink #1 – taking an “infrastructure as code” approach
There’s a lot of guidance in the Service Configuration Management ITIL 4 Practice Guide plus the other ITIL 4 books. For example, the High-velocity IT Managing Professional publication includes what has been termed “infrastructure as code” – the practice of using the CMDB or CMS to drive change.
This states that: “If changes are needed, the source is edited, not the target. Tools such as Vagrant, Ansible, Puppet, and Docker support the whole process.” Such that infrastructure reflects the CMDB (or CMS) rather than the reverse (which had traditionally been the case). Importantly, when there’s a difference between the system of record and real-world infrastructure, the CMDB/CMS prevails.
While not contained in the service configuration management practice PDF, this is an important change in CMDB thinking – and real-world practices – that might be beneficial to your organization.
Is it time that your #CMDB efforts focused on what’s really important – the key data that improves both business operations and outcomes? Check out this article from @StephenMann. Click To TweetRethink #2 – pulling CI data as and when it’s needed
Going back to the conversations of 2008, one of the key issues was the accuracy of CMDB data – with the joke (that wasn’t really funny) that CMDBs were like elephant graveyards in that they were the place where CI, or IT asset, data went to die. Automation capabilities have helped significantly with this issue, but it still doesn’t mean that an ITSM practitioner on the IT service desk, or elsewhere, seeking the latest data about a CI actually gets it. Instead, they get the last recorded version of that data (or attribute).
It’s not a new challenge or even a new solution. The concept of a federated CMDB or CMS is even older than the conversations I called out at the start of this article. Here’s a 2006 blog by Troy Dumoulin that describes a federated CMDB as where “a master database (aka the CMDB) references an external database for a subset of information.”
It made sense in terms of CMDB accuracy – with the CMDB able to access the most up-to-date data relative to CIs rather than needing to hold every little detail itself. It certainly made the maintenance of a CMDB easier, although one did have to appreciate that it still might not be real-time or “bang up-to-date” data as we say in the UK.
Extending this thinking, what if your CMDB offered up real-time CI data but only as and when it is needed? Where the CMDB CI record is instantaneously updated on request, with real-time data, directly from the CI.
This is the solution 1E offers to customers, with KJ continuing that “We took the approach by answering the question ‘What if there’s less data to maintain? Can that help sustain a reliable information system of records?’. We designed a solution that captures needed data in real-time. This then eliminates storing essentially historical data in the CMDB by pulling data from the ultimate source of truth, the CI itself.”
Of course, the CMDB can still be populated periodically via scanning or monitoring tools, but how beneficial would that real-time CI data – for either individual CIs or groups of CIs – be to people in service desk, problem, change, or other ITSM roles?
Accurate data and information fuels better decisions and the approach also reminds me of the old adages of “quality over quantity” and that “sometimes less is more.” Plus, the concept of “pull” over “push” is well aligned with modern thinking around optimizing workflows.
“But we don’t use our CMDB”
Over a decade ago, Rob England to speak of “the 5% club.” This was an “elite group of the (less than) 5% of organizations who actually succeed in justifying and implementing a CMDB.” This percentage was also backed up by EMA research data.
Thankfully, things had moved on, although it wasn’t an “apples to apples” industry-wide comparison, when I blogged in late-2013 on ITSM tool usage using aggregated customer “module” adoption stats:
“The real ITSM standout is the 82% CMDB usage. Now, this doesn’t necessarily mean that four out of every five ServiceNow customers are “doing” configuration management – what it does mean is that they are leveraging the CMDB and the information it holds to support other ITSM processes such as incident, change, asset, and capacity management.”
This leads us to the third potential rethink for your CMDB…
CMDB rethink – it’s not really about service configuration management, says @StephenMann #ITSM Click To TweetRethink #3 – that it’s not really about service configuration management
Hopefully, the above statistic has you wondering. It seemed very high at the time, over seven years ago, and it still seems high now. But it does take us back to the earlier ITIL 4 quote, that configuration data can be employed in ITSM tasks such as “impact analysis, cause and effect analysis, risk analysis, cost allocation, and availability analysis and planning.”
So, if you’re not doing so already, especially if you feel that overly data-focused thinking has prevented the success of – or even killed – your CMDB, look at the collection of CI data as the means to multiple ends, not the end itself. Make the CMDB a view of the data that’s important to operations and outcomes rather than the details of everything that’s out there.
Of course, there’s an argument that says, “But what about when you need data or information that you haven’t included in the CMDB?” To which my response would be “Would you prefer that we hold potentially inaccurate information, caused by the added complexity and cost, just in case we need something extra in the future?” Here, the adverse impact of a “belts and braces” approach to CMDB data population is likely to cause more inaccuracy issues than the just-in-case benefits it brings.
So, is it time that your CMDB efforts focused on what’s really important – the key data that improves both business operations and outcomes? Also, recognize the importance of CMDB accuracy to better decision-making and outcomes.
Hopefully, the above three opportunities to rethink the use of your organization’s CMDB, or the introduction of one, are helpful. What else would you add? Please let me know in the comments.
Transparency statement – this article was sponsored by 1E following a demo of its CMDB Connect solution. Its content is the opinion of the author and has been written from an impartial standpoint.
Stephen Mann
Principal Analyst and Content Director at the ITSM-focused industry analyst firm ITSM.tools. Also an independent IT and IT service management marketing content creator, and a frequent blogger, writer, and presenter on the challenges and opportunities for IT service management professionals.
Previously held positions in IT research and analysis (at IT industry analyst firms Ovum and Forrester and the UK Post Office), IT service management consultancy, enterprise IT service desk and IT service management, IT asset management, innovation and creativity facilitation, project management, finance consultancy, internal audit, and product marketing for a SaaS IT service management technology vendor.
