Most CMDB projects begin with an enthusiastic discovery exercise, a populated database, and a demonstration to leadership showing every server, application and dependency mapped cleanly. Eighteen months later the database describes an estate that no longer exists, because servers were decommissioned without anyone updating the record, and a new application was deployed by a team that had never heard of the CMDB.
The fix is not more discipline, it is automation that removes the need for discipline. Discovery tools that scan the network and reconcile automatically keep infrastructure records honest without asking anyone to remember. What automated discovery cannot capture is business context — which application belongs to which team, what a given service actually does, why a dependency exists — and that layer has to be maintained by people, which means it needs an owner with a reason to keep it current.
The reason that works is tying the CMDB to something people already need. If the change advisory process requires looking up what a change will affect, and that lookup only works if the CMDB is accurate, people keep it accurate because their own change requests depend on it. A CMDB maintained as a side project with no operational dependency decays regardless of the policy written about it.
Scope it narrower than the vendor's demonstration suggested. A CMDB attempting to model every laptop, every SaaS subscription and every network switch in full detail becomes a project nobody finishes. Model the services that matter — the ones with real business impact if they fail — in depth, and everything else as a lighter inventory. A CMDB that is complete for the ten systems that matter is more useful than one that is forty per cent complete for everything.
