Why the CMDBf Matters
A little more than a year ago, a group of IT management software vendors formed the CMDBf (Configuration Management Database Federation) to enable customers to federate and access information from their complex, IT infrastructures.
The group is creating a new interoperability specification that will ultimately enable customers to federate and access information from their complex, multi-vendor IT infrastructures. Using standardized interfaces, a CMDBf standard component will integrate freely with other CMDBf components. Consequently, a product like Unicenter NSM can implement a single CMDBf interface that will work with any CMDBf federated CMDB.
Today, a different interface has to be engineered and implemented for each CMDB product that NSM might want to federate with. Conversely, a CMDB need only implement a single CMDBf standard interface to federate with any data source with a CMDBf data source interface. This drastically reduces the time and effort required for building and maintaining integration.
The CMDBf standard is attacking the right problem, and I believe that problem is critical to CMDB practice.
CMDBs have become a central element of enterprise IT management, so a standards-based approach to this critical functionality is critical. I remember trying to write a CMDB nearly 20 years ago. I was in a network management tools group at an aerospace corporation. Thousands of aeronautical engineers were using high end CAD packages running on networked UNIX workstations and mainframes. The future of the company was bet on this first attempt to design an airliner without a single traditional drawing board.
Keeping all those engineers productive was a challenge.
Distributed environments were relatively new and part of the big bet. The design software would lockup occasionally, and the system configuration was so sketchily recorded that system administrators could not spot the session to drop and restart. They were forced to drop groups of sessions, which dropped groups of engineers. This magnified the effect of each lockup and jeopardized entire production schedules. A tiger team was selected and ordered to eliminate dropping whole groups. Our solution was a CMDB.
Even with resources applied to the problem, our CMDB didn't last.
Over one hundred developers were assigned to building the tiger team design. We built a relational database which stored network resources--now called Configuration Items (CIs). Then, we gave the database a pretty interface and a graphic visualization of all the CIs -- advanced technology for the time. At first, the system was a great success. Engineers were productive and everyone was happy. At one point, we even demonstrated parts of the system to NASA.
Within two years, our CMDB solution was abandoned. It was a manual system. If a workstation was reconfigured, the technician had to enter the changes. As long as management pressured us to maintain the database, it was accurate. But when the airliner went into production and the CAD lockups were fixed, all sense of urgency disappeared. The technicians got sloppy about their updates. Eventually the configuration was no longer accurate. The more inaccurate the CMDB became, the less it was used, and the less it was updated.
With accuracy gone, our CMDB was no more.
The point: a CMDB must be kept accurate. The best way to do that is to automate the process by federating with all the IT management systems at a site. A change to configuration that appears in any system should be accessible from the CMDB. This is typically only partially done because the cost of federation is too great. If the CMDBf can make federation the norm, not the exception, enterprise IT management will take a giant step forward.