Drivers for CMDB

Last month I wrote about some research EMA is putting together entitled “ITIL’s CMDB Adoption in the Real World – Just how Real World is it?” Now that the research is underway (no, I don’t have the results yet and won’t for a number of weeks) I thought I’d revisit the subject from a personal perspective.

Last month, I wrote about some research EMA is putting together entitled “ITIL’s CMDB Adoption in the Real World – Just how Real World is it?” Now that the research is underway (no, I don’t have the results yet and won’t for a number of weeks) I thought I’d revisit the subject from a personal perspective.

By personal, I don’t mean installing a configuration management database at home but my own individual perception of why the CMDB won’t go away, why they’re far more than fads, and why they herald a sea of change in the entire IT management marketplace. This is in part driven by some of the correspondence from the last column, and in part from the initial stage experiences in crafting and designing a meaningful set of questions for the research.

For readers who are new to this column, or who may not remember what a CMDB, or IT Infrastructure Library is about, here’s the “headline news” snapshot (other readers can skip this and the next paragraph if they like). The ITIL is a best practices organization targeted at supporting IT Service Management (ITSM), in which IT organizations perform more like service providers within the businesses they serve – i.e., with a focus on business alignment and relevance, accountability, and quality.

To do this ITIL stresses fluid processes (albeit sometimes somewhat rigidly defined) that cut across multiple silos of IT skills to manage the full infrastructure in support of business services. ITIL provides a common lexicon for specialists in applications and networks and systems, for instance, to communicate and work together. And within this lexicon, ITIL’s CMDB posits a central, dynamic and trusted source of information about the infrastructure and its services that spans just about everything from configuration information to topologies, to inventory and potentially asset information, to state conditions (i.e. performance), to customer-related information, to contracts, to IT-to-service mapping, to IT owners, etc. In the perfect world, the CMDB would enable huge gains by providing a common, consistent and scalable resource to support almost any management-related decision or action relevant to ITSM and even beyond.

Now, having said all that, I’m going to cut to the chase. Let’s take ITIL out of the picture for a moment. Let’s just pretend it never existed. To some of you, no doubt, this would be a monstrous assault on the future of IT. To others, judging from some recent e-mails, it would be a heaven-sent blessing, or at least an early spring wind at the edge of winter.

So if you take ITIL out of the picture, the whole CMDB phenomenon goes away – right? In my view the answer is “no,” the phenomenon would still be occurring albeit most likely with a different name and in a primarily architectural vs. primarily a process-centric context. In my opinion, the single most important reason behind the rise of the CMDB is the need for more effective data integration. The new technologies and design points evolving to meet this need are based on an architectural evolution of the IT management marketplace that is still in its infancy, but which in itself will have an even more stunning impact on the future of IT management than the advent of SNMP. In other words – the CMDB is about integrating management investments in a way that finally works.

Just look at the design criteria: effective data integration, data reconciliation, discovery, access control, policy-based automation (whatever that is – another open debate), service to IT infrastructure mapping, and the flexibility and versatility to do things in meaningful bite-sized pieces that work vs. platonically complete ideas that, well, don’t. The standards discussions – many around Web services and service-oriented architectures (SOA) – are being accelerated by attention to CMDBs. Given all this I would argue that CMDBs are first and foremost really about consolidating management investments in data gathering, topology building, configuration, and inventory to support advanced analytics and superior schemas for visualizing, automating and aligning IT and business processes.

These requirements aren’t new – they’re as old as the IT management marketplace. But thinking like this in bold, cross-domain building blocks is, in sum, new. It is a new way of building solutions and enabling platforms, a new way of designing best-of-class solutions to interrelate more effectively within a total management strategy, and ultimately a new way of deploying and planning IT management investments. Oh, and indeed – the linkage between technology and process is real and critical. It’s one of the core drivers behind this vision. But even there, it’s the linkage rather than a process-only approach that will allow CMDBs to actually work.

There you have it. Like all good researchers, I’ve written my conclusion before the data is in. And like all good researchers – I’m prepared to eat my hat (it’s getting old anyway) if I’m proven wrong.

Want to weigh in? Write me.

Click here to find out more about the report.