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 cliched 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 per cent to 90 per cent 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.