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.

Relationships

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.

Summary

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.

First I must apologize for not posting anything for the last two months. I guess I had writer's block. Then again I know some who would prefer to get more meaningful posts less frequently, so at least I can satisfy the latter part of that preference!

So we have this question about how to expose an existing CIM association as a relationship using the CMDBf metamodel. Take CIM_Dependency for example. It seems that about half of all CIM associations are based on CIM_Dependency so answering this question may be generally useful.

CMDBf would require the MDR to represent a CIM_Dependency association as a relationship between two items, where the relationship has a record of type CIM_Dependency (and maybe other records too). So far, so good (a no-brainer if you have been following my blog or other CMDBf activities).

Now - how do you represent the Antecedent and Dependent properties of this record? The first part of the answer is not too hard - a concatenation of the existing Key properties of each CIM instance will work within a CIM Object Manager. But how do you relate Antecedent and Dependent to CMDBf source and target in the relationship metamodel? That's the tricky part (and very important for an MDR, I might add). In the picture below, can you tell whether Computer System depends on Person (like server depends on administrator) or Person depends on Computer System (like I depend on my laptop)?

If your MDR implementation decides that the Antecedent role maps to the relationship target and my MDR implementation decides that Antecedent maps to source, we won't have interoperability even though we are both using the same data model (!!) In other words, our MDRs may not reconcile or respond to a query with predictable results. A graph traveral from one MDR to the other may get stuck in between.

It would be a lot easier if every Association in CIM had a sense of direction, like "depends on" for example; then it would be grammatically obvious (at least to someone who understands English) - source depends on target. I suspect it's a bit late for that wish to come true.

There may be a couple of ways out of this modeling conundrum. The CMDBf workgroup at DMTF could define how to map these basic CIM association REFs to source and target and ask every MDR implementation that supports CIM to follow these conventions. That's a real possibility and easy to implement if we catch every MDR before they go with their own instincts.

I had another way out, but got lost in the maze. Help! I'm waiting for someone else in the workgroup or in my little blog world to make a better suggestion.