What CMDB Implementation Decisions Do You Preserve?

[jrbockrath]

Question for the CMDB community.

One thing I've noticed across CMDB implementations is that we spend a lot of time discussing how to model services, configure Discovery, tune IRE, and implement CSDM.

What I'm curious about is something a little different.

What implementation decisions do you intentionally preserve?

Not the configuration itself—but the reasoning behind it.

For example:

• Why was one discovery source chosen as authoritative over another?

• Why was a CI intentionally classified into a particular class?

• Why was a specific normalization rule introduced?

• Why does a transform behave the way it does?

• Why was an exception made to the standard model?

A year later, those decisions often seem just as important as the configuration itself.

Do your teams have a formal way of preserving that operational knowledge, or is it mostly captured in project documentation, meeting notes, and consultant experience?

I'd be interested to hear how different organizations approach this.

[pr8172510 · Accepted solution]

Hi @jrbockrath,

try to preserve not only the configuration, but also the rationale behind key CMDB implementation decisions.

Examples include

• Why a particular Discovery Source is considered authoritative.

• Why a CI is classified into a specific CMDB class.

• Why an IRE Identification Rule or Reconciliation Rule was implemented.

• Why a transform map or normalization rule was introduced.

• Why an exception to the standard CSDM model was approved.

While ServiceNow provides capabilities for CMDB, Discovery, IRE, and CSDM, the rationale for implementation decisions is typically maintained in solution design documentation, architecture decision records (ADRs), or other governance documentation rather than within the platform itself.

Keeping this information alongside the implementation helps future administrators understand the original design decisions during upgrades, audits, and troubleshooting.

[Sam Webb]

There are two things which I find useful:

1. A CMDB Data Dictionary -> attribute level description of what, why etc.

2. Knowledge articles -> Higher level documentation regarding CSDM, overall specifications, integrations and so on.

Thanks,
Sam