CMDB More Important than Ever in Lean Times

By Dennis Drogseth

(Back to article)

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.


This pluralist vision is messier, but it is much closer to EMA’s idea that the CMDB phenomenon is driven by two parents: ITIL from a process perspective and the need to integrate existing management investments in a way that finally works. This last admittedly somewhat less “legitimate” parent, is nonetheless worth noting; as the need has existed for decades and answering it portends huge values in terms of IT efficiencies from both a capex and opex perspective.

There are tremendous pragmatic benefits in grasping and executing on this bigger picture (albeit through baby steps rather than as a single, life-changing experience). And most likely you’ll have time on your side. Within the CMS realm, I predict that 2009 will re-establish biodiversity in the CMDB-related ecosystem. For instance, in 2006 the industry witnessed a large number of innovators with differing approaches to CMDB capabilities. But by 2007, many of these innovators were scared away from their CMDB initiatives as the industry moved towards more monolithic definitions with associated negative analyst reviews. This resulted in a platform-centric packaging for CMDBs that played to ITIL’s service-desk roots. It was destructive to the many innovators who would have brought more creative and differentiated approaches to enabling a cohesive fabric for management integration versus laborious one-on-one adapters.

The value of this more complex ecology is more options in how and where to begin, and how and where you choose to evolve, with faster time to value. You will be able to choose CMDBs with a more human (and cost/benefit-defined) face. However, the core requirements to define “trusted sources” and the need to commit to a consistent schema for representing CIs and CI attributes won’t go away. And the commitment to look at your political/cultural/process realities won’t go away either. Still and all, you should feel liberated from the notion that committing to a CMDB deployment is akin to building a monster in the basement. You will be able to start more fluidly, adapt more fluidly. Call it the "Scottish Database” or anything you wish—you are at free at last to chart your own, benefits-oriented course.

Dennis Drogseth is vice president of Boulder, Colo.-based Enterprise Management Associates (www.enterprisemanagement.com), an industry research firm focused on IT management. Dennis can reached at ddrogseth@enterprisemanagement.com.