Best Practices for loading data into BMC CMDB
When you load data into BMC CMDB, you must clearly identify which objects should go into BMC CMDB and which should be excluded. Determine the information that you want to hold about the CIs. For example, if you load servers into BMC CMDB, you must decide how many server-related details should go into BMC CMDB. BMC recommends that you not add nonconsumed information, which can overload BMC CMDB. Add only the amount of information that is useful to you for making business decisions.
The following best practices will guide you when loading data into BMC CMDB:
- Limit the initial load of data for only the primary use cases identified for your environment. For example, if you have identified your primary use cases to be Incident Management and Change Management, identify objects or data connected to the incident management and change management processes, and start your initial load with those objects or that data.
- Do not start with your data providers; otherwise, you will include all of the data from your environment rather than limiting the data to the business service or to process-critical data.
- Rather than loading everything from your environment, start by populating the data that the business consumes. While loading data into BMC CMDB, always consider the perspective of the consuming application. Identify the data that the consuming application will use and that must be monitored and managed.
- Do not aim for a complete data load; start with a subset that supports the processes you want to manage. For example, assuming your primary use case is Incident Management, you can decide to load the subset of data related to server, software, and desktops, because you need to monitor that data for a successful Incident Management use case. You can choose not to load information related to patches or service packs during the initial load.
- After you have loaded the initial subset of data to BMC CMDB, start adding rules and policies revolving around your primary use cases, such as Incident Management and Change Management. For example, you can set a rule for the payroll system to be up and running at all times on payday.
- After your primary use cases are satisfied and you have added related rules and policies, you can then start populating the remaining objects as you start using BMC CMDB.
After the initial load is complete, BMC recommends that you load only incremental changes. Do not repeatedly reload all data from a source, because doing so triggers re-normalization and re-reconciliation all over again and is time-consuming.
If you are using Atrium Integrator to load data, a checksum value is created. During the incremental data load, if the checksum value matches, the data is not loaded. If the checksum value does not match, the data is treated as new or changed data, and the data is loaded into a dataset. For more information about checksum, see Configuring the checksum value for loading data into BMC CMDB.
If you are using a tool other than Atrium Integrator to load data, it is important that you have a method to identify the delta or incremental change.
When setting up BMC CMDB:
- Do not have a CMDB project as a standalone project. Your project will not be successful.
- Always have a project with CMDB in some context.
- Never use the production dataset to reconcile data.
- Do not rewrite everything to use BMC CMDB immediately
- Use existing repositories as discovery sources for BMC CMDB.
- This includes any pre-existing stores/CMDBs
- Many times these other repositories should remain long term
- Consider migration over time as things allow (if appropriate)
- If there is unique data in the store that does not belong in the CMDB or if there is other value in the other stores, keep them long term and interact with discovery loads and Federated links
- Look at some focused area for initial implementation
- A specific business service
- A specific location
- A specific class of things (servers, desktops, ….)
- Grow into the CMDB don’t rush in too fast