Building a CMDB a small agency IT team can actually maintain

Reference article · 6 min read

Most configuration management database projects in small agency IT shops fail the same way. The team turns on a CMDB module, spends a few months loading everything it can find, and produces a large and impressively detailed set of records. A year later those records describe a network that no longer exists. Staff stop trusting the data, go back to spreadsheets and memory, and the CMDB becomes something that gets cleaned up before an audit and ignored the rest of the time.

The cause is usually scope, not discipline. A CMDB sized for a large enterprise needs more feeding than a team of a few people can provide. A CMDB scoped to the questions the agency actually has to answer, and tied to processes that were going to happen anyway, can stay current on modest effort. The design work is mostly subtraction: fewer item types, fewer required fields, one clear owner for each fact.

Start from the questions, not the inventory

Write down what the CMDB must answer before defining a single record type. For most small agency teams the list is short:

• What breaks if this goes down? The service impact question, asked during an outage and again during change review.
• What is running here, and is it still supported? Operating system, firmware, and major application versions, with end of support dates where the vendor publishes them.
• Who owns it and who pays for it? Owning department, funding source, contract or renewal date.
• Where is it, physically and logically? Site, room or rack, network segment, or cloud account.
• Is it in scope for a control? Whether the item stores or processes regulated data such as criminal justice, health, tax, or cardholder information, so assessments start from a defensible list rather than a fresh hunt.

Anything the CMDB records that answers none of these is cost without benefit. Cut it from the design before it becomes a field somebody has to maintain.

Decide which items earn a record

A configuration item should earn its record by being something you manage as a unit, restore as a unit, or answer for during an audit. For a small agency that usually means servers and virtual machines, network and security appliances, business applications and the services they support, databases, cloud tenants and subscriptions, telephony and radio infrastructure, and building or plant control systems that IT touches.

Several things usually do not deserve their own hand maintained CI record. End user laptops, phones, and tablets are better left in the endpoint management or mobile device management tool, with the CMDB referencing that system rather than duplicating it. Cables, monitors, adapters, and consumables belong in a stockroom list. Individual user licenses belong in the license or identity system. Duplicating any of these creates two records that will disagree within a quarter.

Keep the mandatory field list short

Every mandatory field is a small tax paid on every record forever. A workable minimum is a unique identifier and name, CI type, lifecycle status such as ordered, in stock, in service, or retired, the owning group rather than a named individual, environment, location or hosting platform, the source system the record came from, and the date the record was last confirmed. Everything else can be optional and populated where it happens to be known.

The test is simple: if staff cannot fill in a required field at the moment the record is created, they will invent a value to get past the form. One fabricated field undermines confidence in the whole record.

Name one system of record for each attribute

The service desk, the finance asset list, and the network scanner will disagree, and arguing case by case burns the time the CMDB was supposed to save. Decide precedence once, in writing, by attribute rather than by system:

• Finance and asset management. Purchase date, cost, funding source, tag number, warranty, contract and renewal.
• Discovery and scanning tools. IP addresses, operating system and firmware versions, installed software, last seen date.
• Service desk and CMDB. Business owner, supported service, criticality, lifecycle status, relationships.
• Identity and HR systems. People, groups, and reporting relationships referenced by the CMDB rather than stored in it.

Where a field has no clear owner, the CMDB should show both values and flag the conflict rather than silently picking one. A short list of these disagreements is a useful weekly work queue.

Let discovery populate, but not decide

Automated discovery is the only realistic way a small team keeps technical attributes current, so use it aggressively for the facts it is good at. Point it at a staging area rather than directly at live records. New devices arrive as candidates, and a person confirms type, owner, and criticality before they become CIs. Anything discovery finds that nobody claims becomes a ticket, which is often where unmanaged equipment and forgotten cloud accounts surface.

Be honest about coverage gaps. Isolated control system segments, contractor managed platforms, and software as a service subscriptions are frequently invisible to network discovery, so those records need a human update trigger tied to contract renewal.

Maintain through change and procurement, not a yearly cleanup

The difference between a living CMDB and an abandoned one is where updates come from. Attach them to work that already happens:

• Change management. A change request names the affected CIs, and the change cannot be closed until the record reflects what was done.
• Procurement. The requisition or purchase order creates the record at order time with status ordered, and receiving flips it to in stock. This also gives finance and IT the same identifier from day one.
• Disposal and surplus. The surplus or media sanitization step retires the record, so decommissioned equipment leaves the active list by process rather than by discovery.
• Application onboarding and offboarding. New systems get a service record at security review, not after go live.
• Light reconciliation. A short recurring review of conflicts and stale records, measured as the share of each CI type confirmed recently, rather than one annual project.

How to start, and what to ask vendors

Start with one important service, model it end to end, and use it in the next real outage or change review. That single vertical slice teaches more about the field list than months of planning. Expand one service at a time.

When evaluating tooling, ask how records are reconciled when sources conflict and whether those rules are configurable by staff. Ask whether full export of all CIs, relationships, and history is available in an open format, and require that export right in the contract along with clear language that the agency owns its data. Ask how discovery is licensed, since per device or per CI pricing can quietly penalize completeness. Ask for a sandbox and an API, and confirm what happens to the data at contract termination, including format and timeline.

HQT works with state and local agencies on enterprise IT and systems engineering, including service management and configuration data practices.

Frequently asked questions