Fear can come in many forms. Sometimes it comes from a loud noise, or else from a scary image – I just heard about a pharmaceutical company trying to get college students to respond to the picture of a spider with fear by giving them electric shocks (they wanted to test medication that could help to soften the memory). And these days it can come from just reading a newspaper, or turning on the TV, or going online for the latest financial news.
But sometimes fear comes from something as simple as a name. Earlier this year, for instance, I heard about a CMDB deployment in a financial institution in Scotland. Even before deployment, the IT executives there had decided not to use the term “CMDB” – as if it might tempt the vexing powers of fate that all too often plague strategic IT initiatives. And so instead they called in the “Scottish Database”, and proceeded with renewed peace of mind.
Clearly, 2009 is placing some level of anxiety over any IT initiative that seems more philosophical than tangible. And in some environments, CMDB deployments are getting cut, with dollars deferred to other projects, or just cut across the board. This is particularly true where CMDB systems were never well understood to begin with, or where vague expectations about changing the known universe overnight ran aground.
Still, based on some mid-February, while 45% of IT mid-tier and enterprise budgets are on the decline versus 17% on the uptake, only 25% of CMDB budgets are on the decline with 19% on the rise, which is pretty close to being flat. In other words, CMDB deployments are getting a bigger share of IT dollars than they were in the past. In my opinion, for good reason. Cost benefits from the same just-in data indicates that “improved operational efficiencies” are the No.1 area where CMDB deployments are showing monetary value, followed by reducing application downtime, and reduced asset costs in software license management and redundant hardware. The list continues, and roughly a third of these deployments claim to have saved more than $500,000 in 2008 alone.
This is not to say there still isn’t a lot of confusion in CMDB land. And the confusion isn’t just among IT organizations. It’s pervasive across the vendor and the analyst communities, as well. In part, this is because the CMDB marketplace is going through another bend in the river that requires more navigation than just staring straight ahead and paddling. It is related to, but not entirely circumscribed by, the difference between ITIL v2’s notion of a “CMDB” and ITIL v3’s notion of a Configuration Management System (CMS). The latter is made up of multiple technologies and, at least potentially, multiple CMDBs.
I was told by one of my vendor clients that some analysts are preaching that anyone who backs away from a single, monolithic CMDB is wimping out. The notion here is if you can’t own up to a Platonically pure, single source for desired state configuration items (CI) you’re falling down on the commitment to consolidate, centralize and get unanimity across IT. I suspect this also comes from the need to create discrete market categories that can be quantified, “owned”, and reported on neatly and definitively. But what this approach misses, and I think what ITIL v3 largely “gets”, is CMDB-related deployments are not really single technologies, but a series of related and enabling technologies.
ITIL’s language is as follows regarding the CMS: ‘’A set of tools and databases that are used to manage an IT service provider’s configuration data. The CMS also includes information about incidents, problems, known errors, changes and releases; and may contain data about employees, suppliers, locations, business units, customers, and users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all configuration items and their relationships.” In this vision, then, the CMS can include multiple CMDBs.