I've decided to go back to square one and discuss EMA's (and my own) evolving perception of what a CMDB System is or at least should be in a little more detail - and then look at how the meaning of 'CMDB' has itself changed, both within ITIL and within the industry.
This third and last (I promise) in my series on CMDBs in the NOC probably should have been written first. Based on some feedback, I've decided to go back to square one and discuss EMA's (and my own) evolving perception of what a CMDB System is or at least should be in a little more detail - and then look at how the meaning of "CMDB" has itself changed, both within ITIL and within the industry.
My goal is to emphasize the value of phasing in a CMDB System without getting caught up in the many misconceptions and sometimes unnecessary complexities that are evident in many deployments.
I like to say that the “Configuration Management Database” is the “Holy Roman Empire” of high technology. As the popular, now almost clichéd saying goes, the Holy Roman Empire wasn’t holy, it wasn’t Roman and it wasn’t an Empire (although this last point could be disputed). Similarly, a CMDB System is neither a database, nor is it about “configuration management” except as ITIL defines it.
In other words, it’s a vision of services and their infrastructure interdependencies, including configuration information within the devices but in no way limited to that, as well as more logical associations for services and infrastructure components, such as customers, operational owners, suppliers, and so forth. And yes, it includes databases, but it is really much more a system of sources reconciled by policy and by appropriate technology to provide a cohesive window on “what’s true.”
ITIL in fact made a fairly radical shift in its v3 focus on service lifecycle management and evolved the original idea of the “CMDB” to what it now calls the “Configuration Management System” or “CMS.”
ITIL characterizes the CMS as: “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. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes. “
Notice already that this presents a clear federated vision – “a set of tools and databases” -- versus the notion of a single mammoth repository. Notice also that it includes information about “incidents” and “problems” which in ITIL can translate into service availability and performance data as relevant to changes made to the infrastructure or to applications, and vice versa. In other words the CMS can show how changes may affect performance and how performance issues may be understood in the context of changes made from within IT – which constitute 60% to 90% of the causes for service failures.
I would suggest that many network operations groups already have “tools” and “data sources” that are the beginnings of an effective CMS – most notably including Layer 2 and Layer 3 topologies. Information about service availability/performance as affected by a specific device or WAN link is also relevant to the notion in the CMS about linking service to infrastructure to support the resolution of “incidents” and “problems.” And of course device configuration information for network devices is also directly relevant. The problem often isn’t that there are no sources or “tools and databases,” but that there are too many, redundant and conflicting sources used by different individuals and groups spread geographically and organizationally across IT and quite often within the NOC itself.
And this brings me to a term that I would hardly try to evangelize outside of this column, but that seems useful here -- and that’s the “CCS” or “Contextually Cohesive System.”
The CMS should be a contextually cohesive system to support all IT service management processes. The politics and process issues categorically outweigh the technology issues in establishing such a system. This was reinforced in a note from one of my column respondents who rightly complained, "You may have the best intentions when designing a CMDB, but if the processes and buy-in from the users aren't agreed upon, then you'll just be spinning your wheels."
In this case the NOC became the “red-headed stepchild” of an initiative that seemed to have spun out of control in terms of the review process (too much formality, too little appreciation for domain expertise) and a disassociation of those who bear the burden of maintaining and updating the system from those who profit from its value.
Along the “red-headed stepchild” front, in two briefings this week I challenged two vendors - one a large platform vendor and the other a smaller, service-desk centric company - about the lack of out-of-the-box capabilities to support network devices in terms of core CMDB models, or fields, or classes. One explained that it had dedicated partners for telecommunications requirements in particular. The other responded with a classic - “Don’t they have their own tools for this?” - meaning, not the CMDB.
But they got it instantly, as soon as I suggested that was exactly the problem in many environments, a CMS growing in the service desk or data center, while the NOC is left literally to its own devices, with redundant and often conflicting views of “truth.”
The beginning of the CMS is not a technology purchase – it is, not to sound too Zen, a state of mind. Just by beginning the journey to establish a cohesive fabric of sources to view changes and conditions across the infrastructure as they affect business services – you are by definition embarking on a CMDB System (or CMS) initiative.
ITIL can and should provide good process guidelines, but they, too, are only a place to start. The goal is to facilitate collaboration, eliminate redundancy and inconsistent sources, and use common sense. Whatever you happen to buy along the way to further this progression towards a more effectively integrated system is still just an enabler, not an end in itself.