How to Maintain the CMDB Quality and Data Integrity

As with most information, the CMDB is most useful when it is current and correct. When the CMDB was initially loaded, the best data available was used and an ongoing effort was initiated to steadily improve data quality over time. This will require constant monitoring of CIs and defined relationships to ensure they represent the actual configuration as accurately as possible. A major effort in maintaining the quality of the CMDB is to periodically review CIs to make sure they correctly describe the OIT assets they represent. With respect to maintenance of CIs, there are two major types:

• Discoverable CIs are those that can be found using automated scanning processes that maintain current configuration information. This includes classes such as servers, databases, Web servers, Web sites, and many others.
• Nondiscoverable CIs are those that must be maintained manually. This includes business services, application software, and physical items that cannot be queried automatically (equipment racks, data centers, PDUs, etc.).

The discoverable CIs will be updated automatically while the nondiscoverable CIs will require review and updating by the support teams for the CIs. This review must be completed for each individual CI at least once every six months. Review consists of opening a CI record, reviewing the data fields, and making any necessary updates or corrections.

Maintenance of CIs in the CMDB

New CIs

New CIs can get into the CMDB in one of three ways:

• Manual entry using the CI maintenance forms.
• Bulk import using the CI Bulk Import Master template.
• As a result of an asset being identified by the Discovery process.

In all cases, new CIs may only be added by a CMDB Administrator. Once a CI is established in the CMDB, the asset owner or someone from the team supporting the asset can update the attributes.

New CI Review Process

A new CI begins with a Configuration Item Management Form. This form is used to request both an individual CI or a group of CIs using the import template. When requesting a bulk import, the CI request form must include either a link to the CI list or the CI list must be attached to the request form.

The information submitted is reviewed by a CMDB Administrator who will make the following checks:

1. Classification of the CI is checked to make sure it is appropriate for the asset.
2. Name is checked to ensure that the CI is not a duplicate. CI names must be unique across all CI classes and name checking occurs at the base CI level. CI names must follow the naming standard defined for the asset class. (See Configuration Item Life Cycles for details on naming standards.)
3. Mandatory fields are reviewed for completeness.
4. Reference fields (i.e., fields that are references to other tables such as User, Vendor, Support Group, etc.) are checked and if necessary, reformatted to make sure they link to valid records in the reference table.
5. Relationships and Dependencies are reviewed to ensure that the minimum relationships are defined and the definitions are appropriate. (See Configuration Item Life Cycles for information on relationships by asset class.)

If the information provided for the CI fails any of these checks the CI will be returned to the originator with instructions for corrections.

In the case of a bulk import using the import template, all items in the list are reviewed. The list will be returned to the originator if any record fails any check. To further aid in preventing creation of duplicates while doing a bulk import, the imported information provided will be run through an identification engine that performs an identification check of each source record before it is inserted into the CMDB. The identification engine determines if the record is a duplicate of an existing CI, and then:

• If not duplicate: Inserts the record to the CMDB.
• If duplicate: Updates the existing CI in the CMDB with data from the source record.

(For details on this process, see Apply CI Identification and Reconciliation to Import Sets.)

Periodic Review of Nondiscoverable CIs

ServiceNow generates a monthly report showing CIs that have not been manually reviewed at some point during the previous six months. This report (CIs not Reviewed in the Last 6 Months) is distributed via email to the leaders of all teams that support any CIs that need review. If a team's CIs are all up-to-date then none of the team's supported CIs will be listed and no action is necessary. The report will look like the following:

If your name appears in the Manager column then you will see a number in one or more of the CI Class columns to the right. Select any of these numbers to produce a list of CIs in that class that need to be reviewed. You can also select the number in the Count column to review CIs from all classes at once.

You have two options for updating CIs:

• For information on how to do the updates yourself, see Entering Configuration Item Information in ServiceNow
• To have the updates entered by the CMDB Admin Team, submit a Configuration Item Management Form

When reviewing CIs, be sure to reset the Last Reviewed Date to the date you did the review.

Regular Monitoring of CMDB Health

Monitoring and maintaining the health of the CMDB is essential to an effective and continuous use of the CMDB. The overall health of the CMDB is regularly monitored by one or more CMDB Administrator using the CMDB Dashboard in ServiceNow. This dashboard shows the result of nightly automated processes that review the state of the information in the CMDB. Health indicators such as duplicate CIs, required CI fields, and other audits contribute to the calculation of health scorecards at the CI, class, and CMDB level. The health of the CMDB data is reported for the following metrics:

• Completeness: CIs are tested for required and recommended fields that are not populated.
• Correctness: CIs are tested against predefined data integrity rules such as identification rules, orphan CI rules, and stale CI rules.
• Relationships: The health of CI relationships is tested for indicators such as orphan and duplicate relationships. And for compliance with suggested relationships, hosting and containment rules.

After CIs are tested for various health indicators, the results are aggregated at the class level, and eventually at the overall CMDB level. These results are available for review on the CMDB Dashboard. This dashboard provides a summary of the review with the ability to drill down to an individual CI that failed n audit for any reason.