Good foundations - the CMDB challenge
The importance of knowing what you know
Configuration Management Databases (CMDBs) have been a foundational piece of IT service management tooling since the early 2000s. A successful CMDB implementation, it’s said, will allow you to understand the state of IT across your enterprise and track the configuration of all your infrastructure assets. It will provide the bedrock for your core IT service processes, including change and incident management, and support delivery of high-quality services to your business end-users.
We’re all doomed!
Many organisations have found that there’s a significant reality gap between the nirvana of an all-encompassing configuration database and what they are able to achieve. For companies that have grown through acquisition, it is often the case that merging the IT inventory information of different entities has never made it to the top of the IT projects priority list, leaving them with multiple sources of data and no easy way to pull together a holistic view.
Other enterprises are living with failed CMDB implementations, sometimes after multiple attempts. Gartner have reported on multiple occasions a success rate of less than 20% for CMDB projects, with the trend getting worse.
So, is your best bet to give up on your CMDB and to take your chances with whatever data sources you can cobble together? In a world of ever-increasing IT complexity, with IT equipment moving from on-premises data centres and defined office locations to a highly distributed model of public cloud and home working, staying on top of your IT has never been more important. The variety and quantity of cyber risks seem to be growing at an exponential rate, posing yet more threats to IT service integrity and availability.
Why things go wrong
The case for a modern CMDB seems clear then, so how can you successfully crack the configuration management challenge? Perhaps a good place to start is to look at why so many CMDB implementations fail.
A common cause of problems is over-ambition. It may take years to get an approved business case and funding for a configuration management project, and when the time comes, there is an understandable desire to do it all. Implementation of the CMDB can quickly deteriorate into an endless exercise of data gathering, questionnaires and Excel-based data reconciliation, with the aim of logging every bit of infrastructure, and their configuration to the nth degree.
Discovery tooling can exacerbate the issue, adding hundreds or even thousands of configuration records without enough information to effectively tag them for use and ownership.
In practice, many of these records and pieces of information will never be used, and it is easy for the CMDB project to sink under the weight of unclassified data.
Another familiar issue is business-case drift; it can be hard to link the delivery of a CMDB to quantifiable business benefits. As implementation timelines expand because of data issues or unforeseen complexities in the IT environment, business sponsors can become impatient, resulting in pressure to focus on projects that more obviously align to their objectives.
Less is more – a service-centric approach
Before starting on a new CMDB project or embarking on a refresh or rescue of an existing capability, it is vital that you decide on your minimum-viable taxonomy – what type of infrastructure assets do you need to keep track of, and what information do you know that you need. Note, this is not the same as thinking of all of the information data points that you might ever need!
Taking a service-centric approach to developing your CMDB will help you to attack the problem in bite-sized chunks and can also assist in aligning the business-case with identifiable and quantifiable benefits. For example, building a case around preserving the integrity and availability of one of the businesses critical applications will enable you to look at the cost to the business of loss of that service, while newer network discovery tools can be used to build out an application-centric view of the infrastructure used to deliver it.
Data centre or cloud migration projects, and other infrastructure refresh initiatives may provide opportunities to increase the coverage of your CMDB at relatively small additional cost and each should be assessed on its own merits.
A moving target
Of course, setting up your CMDB is only the first part of the challenge. Without robust processes to keep the CMDB updated as elements are introduced, updated, or retired, all the hard work in getting it set up will soon be wasted. Change processes must consider internal and outsourced resources, including those in public cloud. Additionally, third parties working across your IT estate should view, and if necessary update, this same common database, either directly, or via integration with their own service management systems.
But if you can get both the build and the maintenance processes right, the CMDB will prove to be an invaluable asset and still offers one of the key paths to enabling the delivery of high-quality and secure IT services to your business.