Configuration Measurement Database: From Monolith, to Management, to Measurement, and beyond...
As we know the M in the abbreviation CMDB is an abbreviation for Management. In reality, in a lot of cases we'd argue the M is actually an abbreviation for Monolith, rather than Management. We'd additionally argue that in order for a business to gain true value and insight out of it's CMDB, M should be an abbreviation for Measurement.
Without regular measurement there cannot be improvement. Without improvement there cannot be increases in customer satisfaction. Without increases in customer satisfaction there cannot be increases in revenue.
Firstly lets get started by discussing what do we mean when we refer to the M in CMDB as being an abbreviation Monolith.
In a lot of traditional ITIL implementations of CMDB we see the CMDB referred to as the authoritative source of information, yet there is no easy mechanism for updating this data. If there is no easy mechanism for updating this data then there is only one time it will ever be correct, that is when it is being entered. Five seconds after entering that data it is out of date. It can be argued having no data is better than having incorrect data. Incorrect data leads to incorrect assumptions. Incorrect assumption lead to poor planning and poor budgeting.
It doesn't matter how good your Configuration Management process is, if it isn't automated, then invariably it's going to be skipped, or fail at some point. Whether it's due to human error, or insufficient time, the data in the CMDB is going to be out of date. As the number of items you are managing scales up, the impact of this can be catastrophic to the business, especially where security is concerned.
For example, lets take the recent OpenSSL Heartbleed vulnerability into account. While this was a very well communicated issue by software supplier, in many cases the communication about the level of exposure by organisations using the software to their customers wasn't. If your CMDB isn't up to date how do you have any chance of ascertaining your level of exposure?
More importantly how do you determine the impact to your customers? If your CMDB isn't kept up to date you don't have the capability to respond in this manner. You additionally don't have the capability of assessing the cost and impact to the organisation. Therefore, if the CMDB updates are not automated, it becomes a monolith, or monolithic in nature. It rarely, if ever gets updated as the process to do so is to onerous.
Here's a few questions to ask yourself:
- Can you quickly/automatically report on your license exposure for a specific product?
- Can you quickly/automatically report on the versions of software you have deployed?
- Can you quickly/automatically report on the firmware versions you have deployed?
These are common questions that come up again and again in relation to IT management, especially around budgeting or auditing time. If the answer to any of these questions is no, then you don't know the true cost of delivery of your infrastructure. In an era of increasing competition and dwindling margins, not knowing this kind of information can have a large impact to an organisations profitability.
Secondly, lets conclude this discussion by examining what we think the M in CMDB should actually be an abbreviation for Measurement, rather than Management. Maybe you've got beyond the monolith stage and your updates are automated. The next question to ask yourself is what are you doing with this data? Are you just managing it? Or are you measuring it?
If your CMDB reporting isn't automated, then you are not doing regular measurement of your configuration management. You are only doing adhoc baselining. So what do we mean by measurement? Here are a few simple questions to ask yourself to determine whether you are using your CMDB for measurement rather than management.
Ask yourself:
- Can you report on the number of configuration changes that happened to a system outside of a change window?
- Can you report how long it takes for a configuration change to be rolled out to a set of systems?
- Can you report how many configuration changes needed to be rolled back?
- Can you report on the number of configuration that were successfully or unsuccessfully applied?
- Can you report on the number of systems deployed that met the baseline configuration?
If the answer to any of these is no, then you are not measuring. These common questions relate to common task which consume time, and if not resolved lead to outages. If you are not measuring these then you don't really know the true cost of delivering your service. You similarly can't quantify the impact they are having on your organisation in order to develop and correctly cost a plan to resolve them.
Would you like to the M in your CMDB to be an abbreviation for Measurement?
Contact us to discuss how we can help you leverage your CMDB to allow your organisation to be innovative, and increase your agility, flexibility, and profitability.