Here are some reasons why a federation of MDRs implementing the CMDBf specification still needs a “Single Source of Truth” and how to implement it…
For many years, BMC has been promoting a federated CMDB approach that features a centralized repository of configuration information, providing federated access to extended information from management data repositories (MDRs). I would like to refer to this centralized repository as a “configuration directory” since this more clearly identifies its purpose.
Standards are emerging that enable multiple MDRs to form a CMS (Configuration Management System, a collection of MDRs with discovery, data management and human interfaces). I have worked on one such effort, the CMDB Federation specification that is now being finalized by the CMDBf workgroup in the DMTF.
The question must be asked – is a configuration directory still necessary once these standards have reached viability? There are some very good arguments to be made for NOT maintaining a centralized repository such as a recent blog by Glenn O’Donnell (http://blogs.forrester.com/it_infrastructure/2009/04/is-a-cmdb-even-possible.html), but I have some practical concerns with a purely federated approach. There are also good reasons to consider certain MDRs as “master” for the classes of information they provide, so I think Glenn makes some very good points that are consistent with our approach.
I believe that for the foreseeable future, a CMS still requires a configuration directory for a few important reasons.
Even though MDRs may maintain more accurate, complete, and up-to-date information about certain configuration items, the information about relationships to other configuration items may not be available in the same MDR. Maintaining these relationships across MDRs without a configuration directory will present problems for scalability and data integrity. Every relationship must have two endpoints, and the identity of these endpoints must be persistent and unique. This CAN be accomplished without a configuration directory, but is logistically difficult to maintain potentially many cross-repository references.
Normalization and Reconciliation
Multiple MDRs may have information about the same class of configuration items. Normalization and reconciliation of this information requires careful planning and in some cases, human intervention. Perhaps this process can be embedded into rules to enable normalization and reconciliation on-the-fly, but this makes many risky assumptions about accuracy and scalability that are un-proven in a large scale implementation.
Registration and Query
Without a configuration directory, configuration information must be gathered in real time by either a sequence of queries to each MDR, or by querying a federating MDR that delegates the query and aggregates the result. In practical terms, any large implementation would probably cache the results of these queries and attempt to minimize large cross-repository queries. Thus, whether the synchronization of information from multiple repositories is maintained by a caching mechanism or by registration and periodic synchronization, the end result is effectively the same. This is one reason why the CMDB Federation specification defines a Registration service – not to register MDRs (which would more likely be done in a web service registry), but to register the persistent identity of “items” that form the core configuration directory.
Authorization and Change Management
Probably the most important reason to maintain a configuration directory is to provide a consistent and reliable source of information for the change and release management processes. While discovery of the actual configuration items may provide the most accurate and up-to-date information, that does not mean that it represents the authorized configuration. There may be an error in the configuration that is revealed by discovery. Without a configuration directory, each MDR would be responsible to maintain the authorized configuration, and provide consistent ways to detect and report differences between the authorized and actual configuration records.
To summarize, the use of federated MDRs to report detailed, up-to-date information about configuration items and associated records is a key feature of a Configuration Management System. The ability to access and exploit this information will be enhanced by the CMDB Federation standard, and hopefully by some standardization of data model mappings in the future. But the practical implementation of a CMS still requires a federating CMDB that provides persistency, rationalization, and uniform authorized access to a Single Source of Truth about the core configuration items.
It is still a recommended best-practice to minimize the scope and level of detail in the configuration directory to those items (and the properties of those items) that are required to support the configuration and change management processes of ITIL. The CMDB Federation standard (when finalized) will support and enhance this approach.
The postings in this blog are my own and don't necessarily represent BMC's opinion or position.