What CMDB Implementation Decisions Do You Preserve?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
9 hours ago
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.