In response to a recent article about configuration management databases (CMDB) , Bill Taylor, senior architect with BellSouth Corp., posed a question: How realistic is it to implement a CMDB in a large company?
"I can identify with the labor intensive aspect of a CMDB. We believe these efforts ultimately collapse under the intensive manual effort required."
Taylor is referring to the process of setting up and actually implementing a functioning management database. Typically, a full team is required to begin mapping each configuration item (CI) into the database and federating other databases – such as one used by human resources – into one mega CMDB. In a large company orchestrating cooperation between departments and tracking down individual items can seem like a herculean task.
But Taylor also recognizes that technology matures and wonders if the cavalry is on the way and suggests a possible solution. "Our hope for CMDBs hinges on the possibilities that can come from autodiscovery -- that the technology can discover nodes on the network, software on those nodes and of the inspection of the network traffic. That type of method seems preferable to manual entry. Are we just dreaming or do the vendors of CMDB think this autodiscovery method has promise?"
Brian Emerson, marketing manager at Houston-based BMC Software Inc., believes that autodiscovery is not only possible in the future, but that it can happen now.
Making it happen
"Autodiscovery is the easiest way to populate the topology of a CMDB in large companies. It's just a matter of figuring out where to begin. I recommend 'pain points,' " Emerson said.
Pain points are critical aspects of a business that would benefit by being incorporated into a CMDB but will be difficult to manage. For example, getting all of human resources' (HR) employee files and information could be a long difficult process.
Some kind of check usually will be instituted to make sure that autodiscovery is working properly. What kind of check will depend on the company's philosophy, explains Richard Ptak, analyst with Ptak Noel & Associates.
"A company will either decide that the CMDB is always right, or the real world is always right. If the database is always correct, then when something in the real world is different from what is entered, a report will be run. On the other hand, if a CI exists in the real world but not in the CMDB, then the users will be alerted. It just depends on the corporate philosophy."
Once verified and checked, topology mapping begins to take care of itself.
"All new CIs can be linked to an individual employee in tandem with their HR files. That will help populate the CMDB topology more effectively and become a useful business resource," Emerson said.
Topology mapping will still require a team in charge of priming the database and entering some CIs manually. However, once the pain points have been eliminated, the CMDB's autodiscovery will take over the majority of the work.
"Each CI is linked to an application, autodiscovery will assume that each new item is similar and begin to populate the CMBD as new CIs are added," Emerson said.
Federating databases into one CMDB will help the process go even more smoothly.
"A CMDB is a lot like a card catalogue. Once information has been plugged in it will point the user in the right direction. It's a single point of reference that can be counted on to reliably find whatever information is needed," Emerson adds.
But in order for a card catalogue to work, it has to be written in a common language.
"It's easy to enter information to a CMDB -- the real challenge lies in getting all of these disparate databases to speak a common language. HR has one way of entering data, IT has another, and other groups will undoubtedly be different from either of those," Emerson said.
But ensuring that disparate databases speak the same language isn't as difficult as it may seem, Ptak said.
"The normalization -- or creating a common language -- is usually something that will be embedded in a CMDB right from the beginning. Whoever is designing the database will decide on a standard format and all information that is entered will be forced to match that outline," Ptak explained.
For example, if the architect decides that all entries will include a Social Security number, laptop ID number and date of birth, then when human resources' and IT's databases are federated, that information will be plucked from both and entered into the CMDB.
The trick, Emerson said, is to tackle the project in bit-sized chunks. By getting two or three separate databases speaking a common language through a CMDB, a project manager can turn to upper management and present quantifiable results, which, in turn, can lead to more funding to support a larger team.
The next step
Real-time management solution is a term that companies like to toss around in relation to CMDBs. But Emerson says that just isn't realistic -- yet.
"The technology hasn't matured to the point where the database can virtually sense a problem and then tweak it for a fix. That's probably the next step of maturation though. A real- time CMDB will be able to spot a change in the network that wasn't supposed to happen and ask why."
That could reduce downtime on servers and mainframes and fix problems that arise in individual CIs before they become critical.
"It's all about the relationships that are built between one CI and another. A CMDB can spot one change and see how it affects the rest of the data base. That can be a very powerful business tool in the future," Emerson said.
For people like Bill Taylor and companies like BellSouth that are just beginning to realize the advantages of configuration management databases but are put off by the process of implementation, help is certainly on the way.
Dig deeper on Configuration and change management tools