Common Service Data Model (CSDM) Overview and Purpose
Why a common model
Without a shared model, every team invents its own CI classes and relationship types, and reporting breaks down. The Common Service Data Model (CSDM) is a prescriptive, shared data model for representing services, their components, and the domains around them. Its purpose is to give a common vocabulary so that impact analysis, service-level reporting, and portfolio decisions work consistently across the platform.
Concepts to name
- Prescriptive model: CSDM defines recommended tables, classes, and relationships rather than leaving them to local taste.
- Domains and layers: CSDM organizes data into domains (e.g., foundation, design, build, manage) and layers of increasing maturity.
- Service types: business service, technical service, and application service, each with a distinct meaning.
- Service instances: a service offering consumed by a specific audience, distinct from the service definition.
- Foundational data: the base records (companies, locations, users, groups) that all other data depends on.
Traps
The most common trap is treating CSDM as a product you install. It is a model and set of leading practices implemented through configuration. Another is confusing the service definition with the service instance, or assuming full adoption is required on day one - CSDM is designed for incremental maturity.
Worked example
A team wants "Email" in reports. Under CSDM, the business service Email is supported by technical services (mail transport, directory), which run on application services and CIs. The offering consumed by staff is the service instance. Reporting on the business service rolls up from the underlying layers rather than from a manually maintained spreadsheet.
Rule of thumb
Model services top-down from the business service, and let the technical and application layers explain how it is delivered.