Managing a configuration management database (CMDB) well takes a mix of skills that rarely sit in one person: discovery engineering, identification and reconciliation design, data modelling, integration work, data quality operations and a working knowledge of every process that uses the data. Whether you staff that in-house, hand it to a lower-cost team, or use a managed service, the decision should rest on those skills and on the cost of losing them. The most expensive option is usually the one that treats configuration management as data entry.
Key Takeaways
- Running a CMDB well takes skills that rarely sit in one person. They include discovery engineering, identification and reconciliation design, data modelling, integration work, data quality operations and knowledge of every process that uses the data.
- Only data quality operations resembles routine administration. The rest is specialist work, and most of it is only noticed when it stops.
- At one broadcaster, replacing a highly skilled internal team with a lower-cost, lower-skill offshore team led to a sharp fall in data quality, multiple major incidents and advertisers moving spend to rival channels.
- Each staffing model suits different work. An in-house team brings deep knowledge of your estate, a lower-cost team suits data quality operations run to clear procedures, and a managed service brings breadth and continuity if you keep enough knowledge in-house to hold the provider to account.
- Whichever model you choose, keep process ownership, data ownership, scope and risk decisions and the measures in-house.
- Before any staffing change, document the design decisions, put the dangerous settings behind change management, measure CMDB health before and after, and run the outgoing and incoming teams in parallel.
What a CMDB team actually does
| Capability | What it involves | What fails without it |
|---|---|---|
| Discovery engineering | Ranges, credentials, servers, patterns, scan tuning | Coverage gaps, and scans that disrupt fragile equipment |
| Identification and reconciliation | Identifier entries, source precedence, de-duplication | Duplicates and conflicting attribute values |
| Data model | Classes, Common Service Data Model alignment, service mapping | Maps and classes nobody can use |
| Integration | Service Graph Connectors and third-party sources | Parallel copies of the estate |
| Data quality operations | Health rules, certification, task queues | Slow decay that nobody notices |
| Process integration | What change, incident, problem and security need | A CMDB that's accurate and useless |
Only the fifth row resembles routine administration. The rest is specialist work, and most of it is only noticed when it stops.
When the specialist team is replaced with a cheaper one
At one broadcaster, configuration management was seen as similar to managing a large spreadsheet, needing no particularly deep knowledge. On that basis it was judged ideal for offshoring.
The highly skilled internal team was made redundant and replaced by a lower-cost, lower-skill offshore team. CMDB data quality fell sharply.
Multiple service-affecting major incidents followed. Invalid data undermined change impact analysis. Discovery scans ran at inappropriate times, with every probe sent to every address at once, and delicate broadcast equipment failed. Channels suffered outages, and several advertisers moved their spend to rival channels.
We were brought in to rebuild scanning around very customised, light-touch horizontal discovery, using pattern extensions we wrote for the equipment, followed by top-down, pattern-based scanning.
Three staffing models, honestly compared
In-house specialist team. Deep knowledge of your estate and your politics. Hard to recruit, and vulnerable when one or two key people leave. Works well when the organisation will fund and retain senior configuration management skills.
Lower-cost operational team. Suitable for the data quality operations row, working to clear procedures. Risky when it's also expected to own discovery engineering, identification design or the data model, because those need judgement the procedures can't supply.
Managed service. A specialist provider runs some or all of the capabilities, under agreed measures. You gain breadth of experience and continuity. You must keep enough knowledge in-house to hold the provider to account.
Many organisations end up with a blend: specialist design and engineering from a senior team or provider, with routine operations handled by a lower-cost team working to its procedures.
What to keep in-house whichever model you choose
- Process ownership. Someone inside the organisation stays accountable for whether the CMDB serves its consumers.
- Data ownership. Service and platform owners remain accountable for their records.
- Scope and risk decisions. What's in scope, and who accepts the gaps.
- The measures. You define the key performance indicators (KPIs), and you review them.
Record those in the RACI (responsible, accountable, consulted, informed) for configuration management before any transition starts.
Making a staffing change without losing the estate
Document before anyone leaves. Identification design decisions, source precedence, scan exclusions and the reasons behind them. Much of this sits only in people's heads.
Protect the dangerous settings. Scan schedules, probe settings, exclusions and identifier entries go behind change management with named approvers.
Measure before and after. Baseline CMDB health, data-caused failed changes and scan-related incidents before the change, then track them monthly after it. A fall in quality shows up in these figures well before it shows up as a major incident.
Run in parallel. Keep outgoing and incoming teams overlapping long enough to hand over judgement as well as procedures.
For what poor configuration management costs when it goes wrong, see the financial impact of poor configuration management. For the difference between process and data ownership, see CI data owner vs process owner.
How Apex helps
Before a staffing change, our two-week CMDB health baseline gives you a scored view of which configuration items (CIs) are trustworthy and which are guesses. It's the reference point you'll need to tell whether quality holds afterwards, and a report you can take to your change advisory board.
Our data quality assessment then sets weighted critical success factors, key performance indicators and metrics that any team, internal or external, can be measured against. We scope it with you at an initial consultation.
Book a CMDB diagnostic call or arrange a meeting with a consultant.
Frequently asked questions
How many people does a CMDB need?
It depends on estate size, source count and how much discovery and mapping is in scope. Start from the capabilities in the table above, then size each.
Can configuration management be offshored safely?
Routine operations can, with clear procedures and measures. Design and engineering decisions need senior specialist judgement wherever the team sits.
What should a managed service contract measure?
CMDB health, alongside outcomes in the processes that use it, such as data-caused failed changes and incidents without a CI.
What's the biggest risk in a staffing transition?
Losing undocumented design decisions, particularly around discovery scope and identification.
Written by Kinga Staniszewska, Apex Configuration Group.
Book a free call to discuss how Apex can help you on your journey to a better CMDB
