CMDB More Important than Ever in Lean Times
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 isnt a lot of confusion in CMDB land. And the confusion isnt just among IT organizations. Its 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 v2s notion of a CMDB and ITIL v3s 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 cant own up to a Platonically pure, single source for desired state configuration items (CI) youre 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.
ITILs language is as follows regarding the CMS: A set of tools and databases that are used to manage an IT service providers 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 EMAs 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 youll 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 ITILs 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 wont go away. And the commitment to look at your political/cultural/process realities wont 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 wishyou 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 firstname.lastname@example.org.