Best practices for working with discovery data sources
Consider these suggestions when working with discovery sources:
- Do not load every discovered CI into the on every transfer. Transfer only new CIs and CIs that have been modified since the previous transfer.
- You do not have to populate each possible class with every one of your data providers. Bring into the CMDBonly the data that is used by a data consumer to make key business decisions. If no application is consuming the data, there is no value in maintaining and managing it in the CMDB.
- If you are using more than one discovery source to populate an attribute and those sources format the attribute's value differently (for example, one uses capital letters and the other does not), then you should not rely on those values being formatted consistently in your production dataset. Though one discovery dataset will take precedence over the other in reconciliation, there will be cases where the production dataset receives its value from the lower-precedence dataset. For example, a CI might not yet have been imported into the higher-precedence dataset or might have a NULL value for the attribute in that dataset.
Therefore, you should normalize the values of such attributes between datasets before reconciliation. You can use the Normalization Engine to do this for certain attributes. For others you would need to normalize before importing to BMC CMDB.
- When deciding how often to transfer data to the CMDB, ask yourself how often the data changes and how important it is that you pick up those changes. You might want to split your transfers into longer intervals for stable things like facilities data and shorter intervals for volatile things like network data.
- Network discovery applications are not the only type of discovery source that you can use to update the CMDB. LDAP systems, Human Resources systems, Facilities systems, third-party Asset Management databases, and others can serve as discovery sources.