What CMDB Implementation Decisions Do You Preserve?

jrbockrath
Kilo Contributor

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.