After a short hiatus from blogging, I'd like to ease back into it with a short series on CMDB federation. I will start with the problem itself.
The CMDB federation problem is highlighted in ITIL v3 where the Service Asset Configuration Management (SACM) and the Configuration Management System (CMS) both describe a number of databases working together in a federation to provide configuration management. IT system management architects knew long before ITIL v3 that effective configuration management hinges on bringing together data from many contributing sources and keeping the consolidated data current and accurate. This is one of the challenges at the foundation of enterprise IT management.
The driver behind this desire to combine configuration data sources stems from the heterogeneity of typical IT environments. They are usually a mixture of products from many vendors and usually include a few custom applications that are unique to the site. Good configuration management requires collecting information from all these sources into a single CMDB. Efforts to implement a single database as the CMDB have proved to be more difficult than expected and requirements have shifted toward federation.
The CMDBf spec addresses the difficulty in implementing effective federation between CMDBs and other subsidiary data sources (MDRs). This includes CMDB to CMDB federation. There is a lot of legitimate discussion of the meaning of federation. In the CMDBf context, federation means giving one application access to data from another application. Many people put additional requirements on federation, distinguishing between ETL (Extract, Transfer, and Load) technologies that literally copy data from one application to another and federation technologies that avoid copying data. These are good distinctions to make, but CMDB federation can involve both ETL and strict "non-copying" federation.
Whether there is copying of data or not, the essential characteristics of CMDB federation are related to the content of the data transferred and the way the data is used. A CMDB data consists of CIs (Configuration Items) which represent the physical and logical components of an IT system and relationships, which represent the physical and logical connections between CIs. A CMDB is used to control and understand the IT system. In many ways, the content of a federated CMDB is analogous to the blueprint of an IT system.
Next up: What is wrong with federation without a standard?