Is the CMDB Promise Achievable?
Let’s face it. The configuration management database is really the Holy Grail of IT Service Management. Business services are defined that support one or more business processes. These business services connect to various software and hardware elements (or infrastructure services) that represent connectivity, processing and storage capabilities used to support the business service. Ideally through an extension of the CMDB referred to as the Coniguration Management System (CMS) you might also connect supplier contracts (underpinning contracts), OLA’s, and SLA’s. Additionally you would include links to incidents, problems and changes. The end goal would be to have optimal visibility to see what services you are supporting along with all of the past, present and future activity regarding these services. It is the IT data warehouse that transforms data from multiple IT management operational data store so that key IT management decisions can be made.
The vision for a CMDB/CMS strategy is spot on as a critical underpinning for holistic service management. The execution piece is very tricky. And, in the case of the CMDB, this is a consummate example of the importance of ITIL’s guidance on breaking vision down into manageable, achievable interim goals.
For organizations that have substantial infrastructure and have no current tracking mechanism, be realistic about the results you hope to achieve. Auto discovery tools can be helpful but are also very complex and require you to access all points in the network to give you comprehensive results. A structured, slow but reliable approach to getting your arms around the relationship models is to target a handful of services to begin with and do one service at a time. Once each service is validated in the CMDB assuring that you are managing it under your change management process is key.
Identifying business critical services and prioritizing them within this strategy will allow you gain better control and visibility to the areas that are most important to your enterprise as the first phase of this process. Once you’ve got these critical services captured, you can tackle others. In a large organization, this discover & control method will be a multi-year process, but the approach makes the CMDB promise achievable.
January 28th, 2010 at 1:04 pm
Your point about identifying business critical services and prioritizing them, and approaching CMDB slowly and progressively, is spot on.
Two points though:
autodiscovery is of no use to a CMDB if you are doing proper change control: everything in the CMDB should be under control so you should know about all changes as part of the change process and the data should be updated as part of the implementation of the change. More here http://www.itskeptic.org/more-discussion-cmdb-not-best-use-funds
You are spot on again that what defines CMDB is teh definition of services and most of all the linking of services to supporting CIs. Most things called a CMDB are actually just an asset database. But the difference with CMS is not extra types of CI. the difference is that a CMS is supposed to be a federation of CMDBs, something that ITIL touts but that doesn’t even exist anywhere http://www.itskeptic.org/cmdb-and-cms-industry-created-myth
January 28th, 2010 at 5:22 pm
Agree, Rob, with your comment about auto discovery. I see its main value as helping you to rustle up the inventory of items that you have, and, if your discovery tool is capable, help to formulate relationships. But once you have this and are actively managing this service universe through a proper Change process, the residual value of discovery is it to assist in auditing the change process. Discrepencies between discovered elements and those in the CMDB being actively managed may indicate circumvention of the change process.
Regarding your interpretation of the CMS being a federated CMDB, the ITIL definition (from the ITIL glossary) is “(Service Transition) 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.” The inclusion of federation seems to be inherent in this definition, but I seems a bit broader than that to me.
However your argument that there is no such thing as a CMS (federated CMDB) considering that there is no vendor that provides this type of cross repository integration to day has to be extended, I believe, to the CMDB itself. As there is really no vendor that I know of that can actually provide the capability to automagically capture and map every configuration item to a service. Most of this, as you indicated in your comment, must be done manually. So, too, today, must any “federated” CMDB be developed and integrated manually. Vendors love to talk about their ability to deliver the “Holy Grail”. Seems to me that despite claims otherwise, the search continues…
January 29th, 2011 at 12:33 am
For auto-discovery, most CMDB technologies are able to manage your current approved “Gold Copy” CI data and relationships apart from your to-be (discovered, not yet approved) state. These states exist regardless of the data source (e.g. federated versus native discovery).
In the BMC CMDB, the terms are “Current State or Reconciled” versus “Anticipated or Sandbox”.
In the HP uCMDB, the terms are “Managed” versus “Actual” state.
Regardless, a reconciliation activity is required within both systems and should be executed around a sound process and continual improvement plans.
Cheers!
-Jay