Practice · 02

CMDB, and the graveyard problem.

Most CMDBs are dead on arrival. Not technically — the records exist, Discovery runs nightly, the dashboards populate. But the operations team doesn't trust the data, so they keep their own spreadsheet. And once there's a parallel source of truth, the CMDB stops being a product and becomes a side project nobody updates.

What I notice

Forty different ways to represent a server, none of them agreeing. Discovery turned on but the data quietly ignored. "What does this service depend on?" being a multi-hour archaeology project. CSDM mentioned in meetings without anyone having actually read the spec.

The deeper pattern: CMDBs fail because they're delivered, not maintained. The implementation team builds it for the demo, the operations team inherits it without context, and three months in, the trust gap becomes self-reinforcing. By the time someone asks "should we rebuild this?" the answer is usually yes — but the lesson rarely sticks.

What I've learned

The hardest CMDB work isn't class hierarchy or identification rules — it's the governance discipline that makes those things hold over time. A clean class model that nobody enforces becomes a dirty class model within two quarters. The real product isn't the CMDB; it's the small, fast, focused governance habit around it.

Service mapping is where the patterns get interesting. Top-down mapping forces conversations between teams that haven't talked in years. Done right, the value isn't the map — it's the alignment the mapping process produces along the way.