CMDB Federation Part 2

Troy DuMoulin, VP Research & Development | November 10, 2006 | 2 comments

Application 1: CMDB Federation Is The Exception Not The Rule
This approach starts with a belief in four core truths.

- The CMDB is the central repository of record for all IT Assets.
- The CMDB is the trusted source of data and is used by all IT Management disciplines
- Federation to other databases applies only when the child data is residing in an IT tool or application database that has unique functionality and the source can be trusted as accurate and under control.
- A best practice of data management is that you only store and manage it once if at all possible.

The outcome of these four truths or principles implies that there is an overall goal to consolidate all of the like IT data management sources (regardless of who manages them) into one master source when those sources have the same basic functionality. (i.e. store data about CIs) Note: The number of attributes stored in a source database being evaluated for centralization does not qualify as a basis for unique functionality. A decision on how many attributes should be managed in the CMDB should represent the balanced interest of all stakeholders interested in the data. This includes the owners of the original source database as well as the other groups and processes that require it. The final decision about what attributes will be managed at a controlled or un-controlled level is a deliverable of the CMDB data modeling step of the project. All of these like-data sources, be they spreadsheets or enterprise database solutions, are candidates for consolidation into one source, the central CMDB. And yes, by consolidation, I mean elimination of the original database in favor of the central one. Remember the principle of managing data only once. However, there are many sources of data that have unique functionality. For example; data stored in Active Directory which is used for rights management, a systems management tool used for discovery or event correlation, or a financial management application use for costing and billing. Good Examples of Federation include:

- When I look at a CI record and examine the financial attributes I am actually looking at data stored in the Enterprise Resource Planning application.
- When I look at the hardware attributes, these are sourced from a discovery tool where we have selected only 12 attributes out of a possible number of hundreds that are discoverable from the existing source.
- Or the people data is coming from active directory, the HR tool or the email global address list.

Each of these examples represent a source of data with a unique functionality which is above and beyond the goal of managing data about CIs and represents an excellent candidate for federation rather than consolidation. While it is a goal only to manage data once it is not always possible to avoid data replication. If for some technical or security reason it is not possible to provide a real time view into the child data source then it is very important to have the capability to perform a regular reconciliation of the two sources through an automated means. Troy

Like this article? 0 likes