CMDB vs CSDM — Scope and Purpose Explained

Although often used interchangeably, CMDB and CSDM serve fundamentally different purposes. Confusing the two is one of the main reasons 75% of the CMDB initiatives fail.

What Is the CMDB?

The Configuration Management Database (CMDB) is an operational data store.

CMDB scope

The CMDB contains:

• Deployed configuration items (CIs)

• Runtime instances and their technical relationships

• Discovered and federated infrastructure and platform components

• Service instances and their dependencies

• Operational attributes required for ITSM, ITOM, SecOps, and risk use cases

CMDB characteristics

• Focused on runtime reality

• Populated primarily through automated discovery and integrations

• Continuously changing

• Optimised for operations, impact analysis, incident, change, and risk

• Not authoritative for design-time or portfolio decisions

The CMDB answers: “What is running, where, and what depends on it—right now?”

What Is CSDM?

The Common Service Data Model (CSDM) is a logical reference model.

CSDM scope

CSDM defines:

• Which object types exist (applications, services, offerings, instances, products)

• How those objects relate to each other

• Where ownership, accountability, and commitments belong

• Which artefacts are portfolio-managed versus runtime-discovered

CSDM characteristics

• Stable and opinionated

• Service-centric by design

• Independent of tools and discovery methods

• Focused on governance, consistency, and shared understanding

• Applicable beyond the CMDB (APM, ITSM, IRM, TBM, EA)

CSDM answers: “What should exist, how it fits together, and who is accountable?”

The Key Difference in One Sentence

CSDM defines the structure and rules; the CMDB contains the data that conforms to those rules.

Scope Comparison

Aspect	CMDB	CSDM
Nature	Operational data store	Logical reference model
Purpose	Operational visibility & impact	Structural consistency & governance
Focus	Runtime reality	Service & portfolio structure
Change frequency	High (continuous)	Low (intentional)
Data source	Discovery, integrations	Architecture & design principles
Owns data	No (consumes authoritative sources)	No (defines where ownership belongs)
Audience	Ops, ITSM, SecOps	Architects, governance, platform teams

What Belongs Where (Rule of Thumb)

Belongs in the CMDB

• Service Instances

• Deployed servers, containers, cloud resources

• Runtime dependencies

• Discovered software and infrastructure

• Dynamic CI groups

Defined by CSDM (but instantiated in CMDB)

• Business and Technical Applications

• Business and Technology Services

• Service Offerings

• Service Instance patterns

• Ownership and accountability model

Does not belong in the CMDB

• Design-time artefacts

• CI/CD pipelines

• Source code and build metadata

• Ephemeral runtime events

• DevSecOps tool internals

Why This Distinction Matters

When CMDB and CSDM are conflated:

• CMDBs become bloated and unmaintainable

• Discovery data loses context

• Governance becomes manual and political

• DevOps teams resist integration

• Audit evidence becomes inconsistent

When they are correctly separated:

• Discovery becomes safe and scalable

• Service ownership is clear

• Impact analysis works

• Risk and compliance evidence aligns naturally

• DevSecOps and CMDB coexist without friction

The Modern Operating Model

• CSDM provides the stable, service-centric blueprint

• CMDB provides the dynamic, runtime data

• Discovery and federation keep the two aligned

• Portfolio items are managed; runtime items are observed