This documentation supports the 9.1 to 9.1 Service Pack 3 version and its patches of BMC Atrium Core. The documentation for version 9.1.04 and its patches is available here.

To view the latest version, select the version from the Product version menu.

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 you do 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. Given this general strategy, here are a few more considerations and recommendations when deciding which data to federate:

  • 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.
  • Federating avoids rewriting applications to get their data from the CMDB instead of their current data stores.
  • Federating avoids extending the CMDB data model.
  • You can federate data that exists on databases, CMDBf-compliant CMDBs, and BMC Remedy AR System forms.
  • 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.
  • 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.
  • 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).
Was this page helpful? Yes No Submitting... Thank you

Comments