CMDB & CSDM
A CMDB people trust, aligned to the Common Service Data Model.
The CMDB is the most criticised table in most ServiceNow estates — usually because it was populated as a one-off import and never governed. We build CMDB architecture, data quality rules and CSDM alignment that keep it trustworthy as it grows.
The goal is practical: a configuration baseline accurate enough for change risk, incident diagnosis, service mapping and cost reporting, maintained by named ownership rather than goodwill.
Good fit if
- Nobody trusts CMDB data enough to use it for change risk or incident diagnosis
- Duplicate, stale or incomplete CIs undermine reporting
- You cannot connect business services to the infrastructure beneath them
- An audit, merger or platform consolidation needs a defensible configuration baseline
Useful to have first
- Named class owners and an executive agreement on CMDB scope
- Decisions on which data sources are authoritative for which CI classes
- Resources for the initial data cleanup — it is unavoidable and we size it honestly
What the work covers
- CMDB architecture: CI classes in scope, identification and reconciliation rules
- CSDM alignment: application services, business applications and service modelling
- Data quality: completeness, correctness, compliance and staleness rules with remediation
- CI ownership model: class owners, data certification and attestation cycles
- Population strategy: Discovery, Service Mapping, imports and approved manual entry
- CMDB reporting: health scorecards and actionable dashboards
- Relationship design so impact analysis and change risk reflect reality
How we build it
Identification and Reconciliation Engine (IRE) rules are configured per data source with precedence, so Discovery, imports and manual edits coexist without clobbering each other.
Data foundation (CSDM foundation data) is sorted before upstream domains: locations, departments, cost centres and vendors normalised first.
Duplicate detection and staleness rules run on a schedule with remediation workflows, so data quality is measured and acted on rather than audited once.
Business applications and application services are modelled in CSDM terms so service reporting, mapping and cost allocation all key off the same records.
What you receive
- Documented CMDB architecture and CI class scope
- IRE and reconciliation configuration for all data sources
- CSDM-aligned service modelling for the services in scope
- Data quality rules, dashboards and a remediation process
- A CI ownership and attestation model your team can operate
- A health baseline to measure future improvement against
Common questions
What is CSDM and do we need it?
The Common Service Data Model is ServiceNow’s recommended structure for service data — from foundation data through business applications to service portfolios. You need the layers your use cases depend on; we align the CMDB to the layers that earn their keep rather than applying every tier ritually.
Can you fix an existing CMDB without starting again?
Usually yes: deduplication, reconciliation rules, staleness policies and an ownership model recover a neglected CMDB. A full restart is the exception, and we will say so if your data is beyond repair.
How is CMDB quality maintained after you leave?
Through the ownership model we set up: named class owners, scheduled attestation, data quality dashboards and remediation workflows. Governance that survives departure is the deliverable.
How long does CMDB work take?
It depends on CI volume, number of data sources and the state of foundation data. Discovery and reconciliation for a defined scope is a bounded exercise; endless scope is how these projects stall, so we define it carefully.
Let's talk