When to use federated data
Though a CMDB is intended as the single source of reference about your environment, it should not be the single repository of reference. Consumers should be able to use the CMDB to find all of your configuration data, but it should federate much of that data to other data stores.
In general, you should have more federated data than the data stored in the CMDB. The CMDB should be the card catalog that gives you basic information about what is in your library and tells you where to find the rest. It should not be the library. It is better to start small with the data stored in your CMDB, and federate the rest. You can add data directly to the CMDB later if necessary. For example, you might store computer system configuration items (CIs) in the CMDB, and federate data about computer components.
These are some examples of federated data:
- Maintenance records of a printer.
- Help documentation for computer software.
- Invoices related to an computer.
Best practice
Given this general strategy, we recommend that you consider these factors when deciding which data to federate:
Accessing data — Linking to federated data from the CMDB does not mean that you must go through the CMDB to access that data. You can still access the data directly from its own application when you do not need the context provided by a CI. Use federation for access to real-time or secondary information.
Multiple CMDBs — You might use multiple CMDBs in your company. For example, you might use a different CMDB for each of several geographical regions. Use one CMDB as the single source of truth about your IT environment, and federate the data on your other CMDBs.
Attributes that are permanent or change too fast — Federate attributes that rarely ever change, or that change more than once a day.
The former are not important enough to track in your CMDB, and the latter (such as the current load on a server) are likely to be out of date in a CMDB.
Databases and AR forms — You can federate data that exists on databases and Remedy AR System forms.
Non-essential attributes and data — Federate attributes that will not be used to make business decisions. Federate data such as change requests or incident records that are not CIs but are information about CIs. Federate definitional data such as a Definitive Media Library (DML).
Benefits of federation
These are some of the benefits of federating data:
- Federating avoids rewriting applications to get their data from the CMDB instead of their current data stores.
- Federating avoids extending the CMDB data model.
Comments
Log in or register to comment.