The numbers are in on configuration management database adoption and they're soon to be available in EMA's report "CMDB adoption in the real world: Just how real is it?" When I first embarked on the research, I wrote a column about the project and suggested that in my view, the CMDB had a life of its own, beyond that of its "creator," the IT Infrastructure Library, or ITIL. And the numbers are back to prove me right, or wrong.
ITIL is, as most of you know by now, a resource for IT organizations seeking to define and evolve their processes from a best practice perspective in support of what ITIL calls IT Service Management or ITSM. ITIL provides libraries that can help IT organizations collaborate more efficiently across silos, address customer requirements more effectively, align more closely with the businesses that IT supports, and proactively take control of change.
Just as ITIL is itself a resource for IT organizations - ITIL posits a CMDB as a resource that's critical for enabling best practices for not only configuration management, but also a wide range of other disciplines and processes. At core, the CMDB is a trusted and dynamic repository of information relevant to such things as infrastructure configuration and topology as they map to the delivery of IT services. ITIL also extends the CMDB to include "the relationships between all systems components including incidents, problems, known errors, changes and releases..." as well as "corporate data about employees, suppliers, locations and business units." ITIL suggests that the CMDB "is likely to be based upon database technology that provides flexible and powerful interrogation facilities."
In parallel, EMA has been tracking an architectural evolution within the IT management marketplace - a phenomenon all in itself quite apart from ITIL. This evolution has to do with a shift away from siloed design points towards architecture that favors more modular building blocks. The still largely unspoken goal of this architectural evolution is to enable management applications to share data more efficiently, streamlining data collection and enabling more effective analytics in support of faster and more accurate diagnostics, configuration management, service-level management, etc.
Architecturally, this evolutionary trend moves towards what I would call the CD and CD player model, in which next generation platforms become enablers for intelligent integration across multiple brands. From an IT adopter perspective, this would be the best of all possible worlds, while forcing vendors to own up to "ecosystem" vs. "isolated" requirements in how they model and position their products. In other words, vendors would have to design their management tools to work together vs. simply compete in imperialistic fashion for real or imagined turf.
In its next-generation architecture analysis from the second quarter of 2004, EMA predicted: "federated data stores in support of cooperative analytic engines." At that time, EMA viewed this as a future trend, one that would unfold over the course of 10-20 years. This was before the public visibility of the CMDB became a marquis affair - virtually within the last 18 months. As this began to occur, EMA couldn't help but notice the linkages between the two visions - architecture and process - and saw what we felt might just be "the perfect storm."
Well, I've probably spent more time than a sane man should looking at the current state of CMDB adoptions - including about 20 in-depth studies combined with the quantitative data. I've learned quite a few lessons of my own in the process - which of course will be included in the coming report. But, as far as the initial question - does the CMDB have a life outside of ITIL - the answer is "yes." At least it's "yes" in the eyes of the popular imagination. In fact, awareness of the term "CMDB" outranked awareness of the term "ITIL" by a significant percentage within the U.S. IT population. (Awareness of ITIL has been traditionally higher in Europe in particular.)
Logically, from an ITIL perspective, of course this makes no sense. ITIL created the term "CMDB." But the greatest driver for CMDB adoptions - based on this latest research - is not ITIL compliance, but data integration. The CMDB is, in fact, a concept neither greater nor smaller than its parent - ITIL - but in the "real world" represents an overlapping circle, where architectural evolution and best practices come together.
One might expect me to have gloated on being correct in my initial assumptions when the data came in. And I have to admit to having had at least one smiling moment. However, pretty soon, I was also having second thoughts. In all my research - and in dialog with IT clients - the importance of process has become more and more apparent. In almost all the "successful" CMDB implementations that I've personally assessed, there has been a strong commitment to process and to change management processes in particular. In most but not all instances, this attention has been ITIL-driven, while in some it's more a mix of ITIL and other best practice initiatives (and in one instance ITIL was thrown out and the CMDB was kept).
My concern is that the convergence of architecture and process - and frankly often inflated vendor marketing - that now seems to be driving CMDB interest is complex and confusing. And CMDB technologies and standards are also very "early in the game." I am concerned that too many IT expectations are moving towards the notion of the CMDB as something that IT can simply buy to fix its woes. And this, of course, is both dangerous and false. While I am a big CMDB believer, I view it, like ITIL, as an enabler for more efficiency, improved compliance, better governance, etc. But it is not really a "thing." It is the beginning of a journey in which politics, organizational structures, process and cultural dynamics must all, ultimately, evolve together.