Chances are good that your company is already using some form of a configuration management database (CMDB) -- but you might not know it. A CMDB is a database that contains information about all components in a data center and the relationships between those components.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The technology is designed to help data center pros figure out what equipment they have, where it is, how it's connected and the impact of changing it. CMDB offers control over the data so that it can only be changed by authorized individuals; it ensures that current status of any configuration item (CI) is consistently recorded and kept updated; and it verifies data is accurate.
Getting a handle on CMDB
Dennis Deane, head of program management in Europe for Scottsdale, Ariz.-based delivery company DHL, knows CMDB implementation. He built the CMDB at DHL with Hewlett-Packard Co.'s OpenView Active -- and said laying the foundation is the most important part.
"A CMDB can take any shape a company wants," Deane said. "Chances are pretty good that someone somewhere has all the information that is needed to implement a CMDB on an Excel spreadsheet."
Deane makes it sound easy, but he warns that implementation is actually extremely time consuming and requires meticulous attention to detail.
"A CMDB is comprised of individual configuration items," said Gary Brandt, configuration manager for DHL. "Any and everything a company wants to keep track of can be entered as a CI."
Everything from servers to laptops -- it's all fair game. These CI's are then rounded up and put into the CMDB, which is the most time consuming part of the process.
"In order to really implement a good CMDB, the team has to get granular with the information," Deane says. This translates into working with individual CIs and entering them manually into the database. "Every laptop and registration number has to get into the program somehow."
That means a team is dedicated to working on the CMDB -- entering data piece by piece and laying the foundation that the program will run on.
One option to expedite this process is to federate other databases into the CMDB, according to Richard Ptak, analyst for Ptak and Noel Associates. "If a team enters every CI individually, there is the chance for redundancy. A way to avoid this is to federate databases into the CMDB."
This approach would allow for human resource and IT databases to work in harmony to compose the greater CMDB, for example. "If an employee has a health condition that needs to be kept on file, it will most likely reside in the HR [human resource] database. If that same person is issued a laptop the registration codes will most likely reside in the IT database. By federating those two separate entities into the CMDB, redundancies are eliminated, but all the information is still present," Ptak says.
This results in a transparency that is conducive to building the necessary relationships to ensure that the CMDB works efficiently.
According to Ptak, the primary goal of a good CMDB is to sense and respond to the needs of an organization; to make a business more responsive. But before this desired responsiveness can be achieved, relationships have to be built into the database.
"A CMDB is based on relationships. If something happens to one CI, there will be a knockdown effect on others," Brandt said.
"If a server goes down at a satellite office somewhere, it will register in the database. In a case like this, IT people will be able to track the cause and fix the problem. It's not real-time, automated response, but the problem can be fixed as soon as someone notices it," Deane says.
Rather than suffer the loss of productivity that would come with trouble shooting a problem to identify the solution, a CMDB keeps all the necessary information on hand. For example, what went down, what it was connected to and the programs it was running. Rather than starting blank, this information is immediately available.
Who makes it?
IT analyst firm Forrester Reseearch, Inc. recently evaluated the strengths and weaknesses of vendors that have brought dependency mapping and CMDB tools to market. According to Forrester, all products performed strongly, but it favored products from San Jose, Calif.-based nLayers Inc. and Relicore Inc. [recently purchased by Symantec Corp.]. Forrester also liked BMC Software Inc., Tideway Systems Inc. and Collation [recently purchased by IBM]. Mountain View, Calif.-based Mercury and Cendura were also listed as contenders. CA, Inc. and Hewlett-Packard Co. are relatively new to the market, but Forrester expects them both to be heavyweight entrants.
Who's using it?
Simply put, large companies are making the most out of CMDBs. "The biggest benefit of a CMDB will be realized by mid- to large-sized companies that are expecting to grow. It doesn't make sense economically for a small company to implement one," Ptak says.
Managing one of these databases is no small task. DHL has an entire team dedicated to entering new CIs and updating the database. This is a time consuming tasking that can cost any company a great deal of money. From a purely economical standpoint, large companies will have the proper resources and motivation to best run a CMDB.
"Human costs are never cheap. But in order to effectively run, maintain and update a CMDB, there have to be people manning it full time," Ptak said.
Have any questions? E-mail Brian Kraemer, Assistant Editor.