lessphp fatal error: load error: failed to find /home/effectte/public_html/devii/wp-content/themes/theme52707/bootstrap/less/bootstrap.lesslessphp fatal error: load error: failed to find /home/effectte/public_html/devii/wp-content/themes/theme52707/style.less How does Configuration Management work in a truly federated environment?

How does Configuration Management work in a truly federated environment?

What is Federation?

One of the key idea of Configuration Management is “Federation”. Federation means that data is not stored in one warehouse of information. ITIL recognized 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 CMDBs, which together constitute a federated Configuration Management Database CMDB. The CMS will provide access to data in asset inventories whenever possible rather than duplicating data.

Federation may come in different forms. ITIL, in the same section, points out there are several defined data stores such as the Definitive Media Library, the Capacity Management Information System, the Availability Management Information System, Service Catalog and so that would be separate stores that are accessible by the Configuration Management System. 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 became quickly 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. Finally, 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. Who owns the data and it’s quality gets much fuzzier in a federated data 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 am currently working at a customer who has architected 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 Configuration Management System, IT management wanted to be able to tie Incidents, Problems and Changes to CIs for analytic purposes. So integrations were built to each “System of Record” and the CMDB was populated with applications, servers, databases and network devices. So far so good.

I opened an extensive discussion around this topic on BMC Communities. The link for it can be found here – Reviewing Configuration Management

Here are some key points we came up with in the discussion

  1. 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
  2. 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.

Challenges

Federating the data has challenges. The data quality of my customers “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 agreed to do a better job of cleaning up its data.

Lessons to Learn

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 move to a uniform compliance standard

The CMDB was starting to be the main source of truth. Our work with Systems of Records starting forcing the System owners to better 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.