CMDB: model what you will actually maintain

A configuration management database records the components of an IT estate — servers, applications, databases, network devices, services — and, crucially, the relationships between them. Its purpose is answering questions that no single system can: what does this application depend on, what breaks if this host is rebooted, who owns the thing that just failed.

It is also the most reliably disappointing project in IT operations. The pattern is consistent: an elaborate model is designed, an initial load looks impressive, and then reality diverges from it faster than anyone updates it. Within a year or two the data is wrong often enough that people stop consulting it, at which point maintaining it is pure cost.

Scope a CMDB by the questions it must answer

• Start from the decisions the data must support — impact of a change, ownership during an incident, licence position, end-of-life exposure — and model only what those need.
• Prefer fewer configuration item types with accurate data over a comprehensive model with stale data.
• Relationships are the point. A list of servers is an inventory; the dependency between an application and its database is what makes it a CMDB.
• Every configuration item needs a named owner, or it will not be maintained.
• Record the source of each attribute — discovered automatically, imported from a system of record, or entered by hand — because the last category is where decay begins.

Automate discovery, reconcile deliberately

Anything that can be discovered automatically should be, because manual maintenance loses to reality. What discovery cannot supply is the human context: business service, criticality, owner, environment classification. The design question is therefore reconciliation — which source wins for which attribute, and what happens when discovery and the manual record disagree. Teams that leave this undefined end up with two versions of the truth in one database, which is worse than either alone.

Measure freshness, not completeness. A count of configuration items says nothing; the proportion of records verified or discovered within the last period says everything about whether anyone should rely on it. Publish that number, and treat a decline as an incident in its own right.

Make it useful during incidents

The fastest way to earn trust in a CMDB is to make it answer a question people ask under pressure: what depends on this, and who do I call. If the data is good enough for that, engineers will notice when it is wrong and correct it, which is the only sustainable maintenance model. A CMDB that exists to satisfy an audit will be maintained to the standard an audit requires, which is once a year.

Where the records sit

Ettex Records holds the configuration and ownership records with the last-verified date visible, Ettex Sheets carries the dependency view for the services that matter most, and the wider inventory it overlaps with is covered in it asset management. What it is consulted for during a failure is covered in incident postmortem.

Being direct: this is a records approach, not a discovery or ITSM platform. Automated discovery and reconciliation are what dedicated products do, and past a modest estate they are necessary; what this covers is deciding what to model and how to keep it honest.