What is Federation?
One of the key ideas of Configuration Management is “federation”. Federation means that data is not stored in one warehouse of information. ITIL recognizes the key idea of federation (from Service Transition 4.3.4.3 Configuration Management System):
“At the data level, the Configuration Management System (CMS) may take data from several physical Configuration Management Databases (CMDBs), which together constitute a federated CMDB. The CMS will provide access to data in asset inventories whenever possible rather than duplicating data.”
Federation may come in different forms. ITIL points out in the same section that there are several defined data stores such as the Definitive Media Library, Capacity Management Information System, Availability Management Information System, Service Catalog and so on that would be separate stores which are accessible by the CMS. Within the CMDB, there may be multiple data stores that hold different information. The primary CMDB might contain basic references to key CIs but provide links or views to see key attribute information or key components. The CMDB becomes an indexing system and consumers of the information drill into the external sources for details.
Why Federate?
The importance of federation quickly became apparent with early Asset Management and CMDB work. If everything was kept in one location, the database would quickly become unwieldy and too large to efficiently search. Companies also had significant investments in data stores holding information beyond the interests of IT. Moving that information into another database was impractical and losing the information, technology and associated skills was not acceptable. Additionally, information may be formatted in unique ways depending on its nature. IT databases may not be the best tools to manage documents. An asset store focused on networking may not be the best location to manage financial information.
What are the Challenges?
If a federated model is accepted, then Configuration Management still has key challenges. Each source of data will need an interface into the CMDB. Each interface will need to be created and maintained. That means someone with expertise will need to be available to create and maintain those interfaces. Determining who owns the data and maintaining data quality gets much fuzzier in a federated model. Organizations who use data from the CMDB will “blame” the CMDB for inaccuracies when those inaccuracies might originate from the federated data. But configuration managers may not have the authority to correct errors. Finally, as more sources of data are federated, there is bound to be overlap. With overlap of sources there will almost certainly be conflicts in values between these sources.
Extreme Federation Use Case
I was recently working at a customer who has an extremely federated CMDB. The customer is in a highly siloed environment. There is a group that manages and supports applications, another that manages and supports servers, one the manages and supports databases and one that manages and supports network devices. All four have their own Asset Management tools for keeping track of inventory. The company has decided that the each Asset Management tool is considered the “system of record” for its respective infrastructure type. For example, the applications group has the Applications Management System and that is the system of record for applications. Each of these registries is the “authoritative source” for entries infrastructure items.
As the IT Management group built up its integrated CMS, IT management wanted to be able to tie incidents, problems and changes to CIs for analytic purposes. Integrations were built to each “system of record” and the CMDB was populated with applications, servers, databases and network devices.
I opened an extensive discussion around this topic on BMC Communities to get some feedback from others. The link for it can be found here – Reviewing Configuration Management.
Here are some key points we came up with in the discussion:
- Organizations need to recognize that the CMDB is only one tool in the overall Configuration Management process and all tools and their governance need to be considered part of the overall Configuration Management system.
- Frequently, companies bring in more information than they should to the CMDB because they don’t know enough (technically or process-wise) to keep it in its source and link back.
Customer Challenges
Federating the data had challenges. The data quality of my customer’s “sources of record” was poor at times. Much of the data was entered by hand leading to mistyped key pieces of information including indexes. Customers who wanted their records to make it into the CMDB knew how to manipulate data in the “system of record” resulting in defacto duplicate records: two entries with slightly different names.
We had one very long problem investigation dealing with inconsistency on the system of record. We exposed a practice of changing the index value on network items because we would not allow duplicates. Ultimately, the business need for the records overwhelmed our request for the system owner to reform the practice. We changed our indexes and the system owners agreed to do a better job of cleaning up their data.
Lessons Learned
Organizations can implement this extreme form of Federation, but they need some things in place for it to be successful:
- Clear definition of CMDB goals and responsibilities and Configuration Management authority
By defining our goal as “the accurate representation of the system of record”, data quality got pushed back to where the work was done. We did not have the authority to change the system records, but we could alert systems to potential issues.
- Strong governance around “conflict resolution”
This kind of federation diffuses authority and that typically results in conflicts. Customers want their data in the CMDB. We created an “exception process” to deal with those important CIs that were not in systems of record. We regularly reviewed requests for exceptions and approved based on business need and compliance with our governance.
- Federated sources should document their governance and organization to move to a uniform compliance standard
The CMDB was starting to be the main source of truth. Our work with systems of records started forcing the system owners make better documentation. Things were hardly perfect when I left, but they were moving in the right direction.
Summary
This extreme example is probably far more common than most organizations are willing to admit. In reality there are application groups, server groups, network groups and so on. Each group manages their devices in their own fashion. Any configuration management system and plan has to be flexible enough to deal with all these inventory systems.
