The Configuration Management Database business case… elusive, intangible. How do you define it?
Part of the CMDB challenge is what data to manage. How do we think more systematically about this?
First, we need to understand why we want to assemble this data in a ready-to-query repository. There are two major reasons why we store data:
- There are no other sources for it. If we don’t establish a system of record, the data will go unmanaged. We won’t know what servers we have or what applications we are running.
- There may be other sources for the data, even systems of record. But, we need an operational data store to bring the various data sources together in a way that makes them more efficient to query.
For either kind of data, you need to have an economic understanding of why you want it. Suppose you need to find out what servers an application is running on, because an auditor has expressed interest in its controls. You could invest a few days’ research into the question, costing perhaps $750 worth of yours and others’ time, and answer the auditor without trouble.
With enough time, we can research the environment. But, what happens when there are multiple applications of concern? And, you also are doing the same research when incidents and changes occur? What if you don’t have a “few days” but rather are trying to resolve an incident that is costing you thousands of dollars an hour? What happens when the same engineers and managers are asked for the same data over and over again, because there is no repository to maintain this organizational memory?
The challenge is, when does it make economic sense to pre-aggregate the data? The following economic graph may help:
The graph may be familiar to those of you who studied economics. On the left, you have the assumption of no CMDB and on the right you have a comprehensive CMDB.
With a less comprehensive CMDB, you are paying some cost in research and outage impacts. You also are incurring more risk, which can be quantified.
On the other hand, with a comprehensive CMDB, you incur more costs in maintaining it. You need processes that have direct cost to operate, as well as imposing indirect costs such as cost of delay (e.g. if updating the CMDB slows down the release schedule).
But, in the middle is a sweet spot, where you have “just enough” CMDB data. This optimal CMDB scope represents the real savings you might realize from instituting the CMDB and the necessary processes to sustain it.
This is not a complete business case, of course. Your projected savings must be offset against the costs of acquisition and operations, and the remaining “benefit” needs to exceed your organization’s hurdle rate for investments. A simple example:
Let’s say that you have identified a set of use cases indicating $300,000 maximum savings from an accurate and optimally scoped CMDB. The CDMB implementation is projected to cost $250,000 over 3 years. This means that you have an ROI of 20% ($50k/$250k). You can’t get 20% return on investment in the capital markets, so this exceeds your hurdle rate.
On the other hand, if you only are projecting $20k benefits for an ROI of 8%, the CFO may well say, “I can do better with other projects, or by leaving our money in the stock market.”
Of course, estimating benefits such as redundant research and outage risk reduction are not simple. The book “How to Measure Anything” by Doug Hubbard is a very useful resource for these kinds of problems. You may need to consider using techniques such as Monte Carlo Analysis for business benefits that are more probabilistic. But, you do not need to throw up your hands and say that it’s all just “intangible”. Successfully making challenging business cases of this nature is possible. Many organizations have done just this in building the case for their CMDB, and you can too.