There are many difficulties involved in CMDB federation that the CMDBf specification helps address.
When you set out to integrate a CMDB product with another data source, such as another CMDB or a specialized device monitor, there are several steps that you must take and with each step there are choices to make.
Perhaps the most important architectural choice is the level on which to federate. You can choose to federate on a database to database level. That involves a detailed knowledge of the schema of both the target and the source system, and the federation is likely to break if the schema of either system changes. Because the schema is intimately tied to the internal operation of the applications, schema changes occur frequently when either the data source or target changes. Often, schemas are not designed with federation in mind and so data that is not relevant to federation may appear as columns in the same tables as federation data. This can complicate transactions and cause the federation to break when an unrelated feature in the federation source changes. In addition, exchanging schema information can become a thorny intellectual property problem, especially when the source and target are from rival vendors.
Due to the difficulties of database to database integration, APIs are often used instead. Using this strategy two products communicate by each calling the published APIs instead of reading or updating a database. These APIs are usually designed and published to support integration. Consequently, they do not require intimate knowledge of the products that support them and they tend to change less often than database schemas that often change to support new features and efficiencies. And finally, APIs are better documented than schemas.
API to API integrations are a distinct improvement, but they still have problems. For example, they still are subject to breaking if either party changes their API with a product change. Sometimes, good engineering rules are followed and the APIs are backward compatible so that existing integrations do not break, but this is not guaranteed. In addition, as new features are incorporated into products, new APIs are often added and integrations must change in order to take advantage of new capabilities. There is often little incentive to vendors to roll new features into existing APIs, which is often much more difficult than inventing a new API. This means that new releases always threaten the federation and adds an element of unreliability. Not only is there danger of downtime and recoding costs, remediation for the unreliability also incurs more cost in the form of extended testing and more elaborate transition plans with new releases.
Most seriously, the APIs for every MDR and federating CMDB are all different. That means each integration project has to be designed and engineered individually. Not only is development of this form of federation expensive, each integration must be supported individually by engineers specially trained on the specific federation, which eliminates economies of scale in support.
In a word, API to API federation is expensive to the supplier of the federation and inconvenient to the user of the federation.
The CMDBf is a public specification for API to API integration and addresses two of the substantial problems involved with that type of federation. First, it puts everyone on the same API. Second, by placing changes to the specification in the hands of an organization like the DMTF, the change process is stabilized and the specification undergoes industry-wide scrutiny before it changes. Like code reviews in software development, this scrutiny can eliminate a large share of the problems with federation breakage.
When the specification becomes widely accepted, basically the same integration can be repeated and supported over and over again. The process of building a federation between an MDR and a CMDB requires a thorough understanding of the APIs of both the MDR and the CMDB. Typically, the developer is only familiar with one of the two and has to fight a learning curve to master the unknown API. Then the federation must be designed, implemented and tested at considerable expense. If standard APIs are used, which apply to both MDRs and federating CMDBs, the expense and risk is not eliminated, but they are both reduced. The learning curve is diminished because the developer is experienced in the standard API, and much of the code will be identical to that used in previous CMDBf-based projects. Although specialized data may be unfamiliar and require some special processing, that is a small part of the entire undertaking. The bulk of the work and risk is eliminated by using the standard interface.
It is hard to over-estimate the importance of these basic improvements that come from standardization. There are other improvements that can be made to CMDB integration, but they all depend upon a well-defined and standardized API.
This is not the whole CMDBf story, but it is an important part. I'll be blogging more on this.