BMC and CA have both been aggressive in the practical implementation and application of CMDB's in production environments. Each was willing to share their view of the Top 5 requirements to keep in mind when evaluating an enterprise CMDB
Just so everyone knows: A configuration item (CI) is defined as an instance of an entity that is a part of your environment and has configurable attributes specific to that instance. How a vendor's CMDB approaches configuration items largely defines differences among available vendor partners.
BMC touts CMDB maturity, service
BMC was the first to deliver a CMDB to the market. As a result, they have an extensive customer list experienced at using their product in production environments. They use five criteria to evaluate a CMDB.
- Ability to support service models within the CMDB structure - In other words, how easy or difficult is it to define services and build relationships to the underlying technology? Recall that the fundamental task of the CMDB is to allow easy access to data that accurately describes the operating environment. In ITIL terms, this means the CMDB enables your business to model, discover and populate not just technology-based services, but also the next level of services. This includes both business process services and people-implemented processes.
- Support for multiple datasets: pre-production, production, sandbox (future), archive, reporting, etc. - What support is available to create, integrate and accurately manage and maintain multiple datasets inside the CMDB? For example, pre-production datasets collect and store data about the changes taking place in the real-world environment prior to accepting them for updating the production dataset, which contains the "true snapshot" of the environment.
A sandbox dataset holds "what if" changes to configurations used to see the impact of changes to the environment. Archive and reporting datasets provide snapshots that record that state of the environment immediately prior to change and to create reports for audits, record-keeping, etc.
- Ability to manage and maintain reconciliation across vendor and non-vendor tools with built-in workflows - A CMDB exists in isolation. A significant amount of the values comes from its ability to leverage and utilize existing datasets (pre-production, etc.). There must be a robust ability to reconcile the inevitable contradictions that result when dealing with multiple datasets. Rules need to be set for which datasets or pieces of the various datasets will take precedence to define the production dataset considered to be the true description of the environment.
- Support and understanding of the vendor approach to federation - The CMDB is typically implemented as a virtual datastore that discovers and stores customer identified core information about a configuration item. It provides pointers to all the remaining information of interest needed as part of the datastore.
Federation is the process that allows integration of all the other or "related" extended CMDB data. The major vendors (BMC, CA, HP, IBM) and other interested parties (EMC, Symantec, etc) have a working group to standardize federation across the various vendors.
- Visualization of CI data and relationships available to vendor and non-vendor tools - The concern is the ability to create and maintain a graphical model of the CI and its configuration, as well as upstream and downstream dependencies. This visual representation should have an open interface accessible to third party tools.
CA CMDB emphasizes practical product ability
CA's product introduction came later but their focus on practical application and direct aids in implementation led to a list of satisfied customers. Their list of items focuses on the speed of implementation and automation. Let's look at their criteria.
- Easy and quick implementation to maximize speed-to-value - In today's highly competitive environment time-to value is critical. Extended periods for implementation and the resultant delay in payback cannot be tolerated. The solution should be operational and fully capable of delivering useable results as quickly as possible.
- Automated relationship discovery built into the product - This addresses and resolves some of the traditional inhibitors to effective, comprehensive infrastructure configuration management: the difficulties associated with accurately collecting and maintaining manually entered data; describing the dependencies and relationships between infrastructure and environmental element configurations.
The solution must be able to automatically discover and record upstream and downstream dependencies and changes to the configuration as they happen. How it handles this data is part of the reconciliation process.
- Extensive out-of-the-box content that can be easily enhanced to match the customer requirements - This is an extension of the first point above. IT and the enterprise want solutions that start to work out-of-the-box and immediately begin resolving problems. Additionally, they want CMDBs with built-in functionality and flexibility that can be extended to address the unique challenges that exist in their environments.
- Easily federate with a the customers existing IT applications - Both vendors agree that dataset federation is key. Understanding what and how this is implemented is critical to avoid conflicts and implementation problems.
- Powerful automated reconciliation to the need for manual reconciliation - Given the state of today's technology and the operating environment in most enterprises, totally automated reconciliation remains more of an ambition than a reality. But the more automated the process the more accurate and efficient the solution.
It seems everyone, from database vendors to every software solution vendor, touts their own CMDB today. This discussion should help to steer you toward a robust CMDB solution with a partner able to meet your needs. Keep in mind that this is a starting point for evaluation of a CMDB vendor. Let me know about your experiences.
I'd like to thank both BMC and CA for their cooperation. Please feel free to send over your comments and point of view about this column, or to raise any issues you'd like discussed. I can be reached at firstname.lastname@example.org.
ABOUT THE AUTHOR: Richard Ptak is an analyst with Visit the Ptak, Noel & Associates LLC . He has over 30 years experience in systems product management. This was first published in April 2007
This was first published in April 2007