That for which we have no language, we must pass over in silence. – Ludwig Wittgenstein
Creating the CMDB Language
One of the greatest difficulties for IT executives is communicating why we do what we do to the rest of the organization. This is no small matter. When this communication fails, the organization can only view IT as a cost center, and cost centers are only targeted for reduction. In many organizations, this mentality has firmly taken hold, and the reductions are quite visible in outsourced operations, even outsourced management. It appears that this has even become the majority view, though certainly not the unanimous one.
It may not be overstating the case to say that IT’s status as a cost center is the dividing line between the old and the new economy. On one side, IT talent is viewed as a commodity where one body can be swapped for another. On the other, companies viciously compete for IT talent with recruiting programs, benefits packages, and salaries that astonish the other side. There is little question about which side of the line is the more profitable, which has more rapid growth, or which will comprise the majority of the Fortune 500 in the next decade.
We do ourselves and our organizations a disservice when we do not take the opportunity to make our case in the language of the business. IT is the business of creating magic! We should be proud to tell this story. Which of your major projects in the past 5 years was not fundamentally an IT project? How much of what you did in your position was even imaginable ten years ago? IT enabled everyone to do their job in their pajamas for a year and most of them did it better because they weren’t sitting in their co-workers’ cube arguing about whether it was Pacino or De Niro in Heat.
It is incumbent upon us all to translate the value of our work into the language of the business. That begins with understanding that value ourselves. What capability did we create? What risk did we eliminate? Most of the time, we do, or we did understand the initial reason for a project or task. However, this can get lost over time, repetition, and transition until the reason becomes, “we do this because we do this.” It is necessary to surface the value statement for a project early and often.
Just as often, tasks and projects are nested several layers deep in dependencies, and the value is not as immediately obvious. The CMDB tends to fall into this category. We spoke a bit about this in our previous article, but let us state for the record that populated properly, the CMDB can be a foundation for:
- Disaster Recovery
- Cloud Transformation and Cost Management
- Cost Allocation to Line of Business
- Change Management Risk Reduction
- Vulnerability Management
- Inventory Management
These are all operational goals for management, and this is certainly not exhaustive. Nearly every project of organizational significance has a critical IT component, and nearly every one of those IT components has deployments that can be accelerated or roadblocks that can be removed by utilizing a properly populated CMDB. It is critical to tie the population effort to the projects that they enable.
Regardless of whether we have or have not stopped believing, the CMDB is not a magical bird descending upon us to grant wishes. It is a painstakingly built repository of data gathered manually and through automated discovery for express purposes. If your project or use case is new, the CMDB likely does not contain all the data required to achieve your goal. This is not a cause for cursing, and it is also not the time to look upwards for magical birds with the phrase, “The CMDB should already have that.” As stated before, the CMDB should not have anything that is not already recognized as valuable to the organization (caveat, if it’s free, it might not hurt). This is a time to turn to the infrastructure owners to see what is possible.
You get what you measure
Let’s assume you get a “yes,” or a “yes, but it’s going to cost something” from the infrastructure owners. Let us also assume that you know the value of the capabilities your project will produce or the risks it will mitigate, and that value considerably exceeds that of the cost of gathering the data. May I also assume that somebody is writing this part down?
Given that the CMDB enhancements are now greenlighted, the key to success is tracking and verification. Ostensibly, your request has consisted of: “I need these {a} attributes and these {r} relationships.” If you want to measure whether or not you’re getting what you pay for, you’ll need metrics and a way to observe them. The blood and guts way of measuring this is to create a flag for each attribute {a1 – an} and each relationship {r1 – rn}. One should. This will enable the infrastructure owners to identify problem areas and identify individual CIs that require action.
However, this will not get you where you need to go. Look at all that notation up there. Subscripts, CIs!? The disengagement you’re feeling is the same emotion everyone in Line of Business feels when they talk to us. Clearly, this needs to be done, but where’s the headline? What capability is being produced? What risk is being mitigated? Where is the value?
Give the business a headline. This consists of two things. The first is the headline metric, and it reads something like:
Percentage of Infrastructure Meeting Disaster Recovery Requirements
Catches the eye, no? The headline metric consolidates all of the sub-metrics into one topline number that the organization can respond to. It is also fundamentally Agile. For a piece of infrastructure, nothing is done until everything is done. This approach gives no credit for Work in Progress. It attributes value to results rather than work. We know with certainty that the organization is better off when the number goes up.
This brings up the second requirement. In order to know whether the organization is improving, it is necessary to have the ability to track the headline metric over time. This actually goes beyond knowledge of improvement. It is very difficult to know whether the current number associated with the headline metric is good or bad out of context. Suppose the Percentage of Infrastructure Meeting DR Requirements is 61%. There are no industry benchmarks for numbers like these. You might even be one of the pioneers in your industry in this regard. However, you can be sure that 61% is a good number if it was 49% last week.
Suppose now that we have all the measurements that we have proposed. We can tell the executives that our company is more resilient to unexpected events due to the effort and money expended over the past few weeks. As a project owner can see that my project is moving toward success in a measurable and significant way. I can also see who is doing great work and who needs coaching. The infrastructure owners are also able to more quickly identify what items require action and see directly how their efforts are accruing to the benefit of the organization. Not bad, why doesn’t everyone do this?
Roadblocks
Creating the headline metric shouldn’t be too bad. If the requirements for the project are clear, the headline metric merely needs to be able to evaluate that each of the requirements is satisfied. That formula may contain 30+ elements, but a competent analyst should be able to pull that off. As complexity increases, so does the level of testing that is advisable before making the metric visible to critical eyes.
You can never step in the same river twice
The real roadblock is in trending CMDB data. The CMDB is the picture of the infrastructure of an organization at the current moment. The accounting metaphor for the CMDB is the balance sheet. The balance sheet is taken at a point in time, and a past balance sheet can be created with a current one and an income statement.
If only we could do the same for the CMDB. The problem with the accounting metaphor is that there is an enormous level of formalism in financial accounting that is neither followed nor desirable in the IT space. Creating a view of the past from the current CMDB and the logs of changes is theoretically possible, but prohibitively expensive in terms of time and expense.
The amount of data contained within a CMDB is also huge. Relational databases struggle with processing standard organization-wide reports out of the repository. Lights dim, and nobody can make coffee. What is required is the ability to take periodic snapshots of at least the headline metrics, preferably the detail metrics, and even more preferably, the full state of the CMDB. Even if that were to occur, it would be necessary to report off a source that would be many multiples of the size of the CMDB itself. This is typically the stumbling block. Even some of the best companies resort to keeping copies of spreadsheets around archived with highly suspect naming conventions.
But what if you could do it the right way?