CSDM Domains, Layers, and Foundational Data
Structure of the model
CSDM is organized into domains that group related data by purpose, and layers that describe progressive maturity of adoption. Candidates should be able to place a given record in the right domain and layer, because questions frequently present a scenario and ask where the data belongs.
Domains to know
- Foundation: the shared base - companies, locations, users, groups - that everything else references.
- Design: the intended state - business services, service offerings, and their design.
- Build: how services are constructed and delivered - application services, technical services, and the CIs beneath them.
- Manage: operational data used to run services - incidents, changes, requests tied to services.
Layers and maturity
Layers express how completely the model is adopted, from crawl to walk to run. Early layers establish foundational records and a few services; later layers add offerings, technical and application services, and full relationship coverage. A trap is assuming a later layer invalidates earlier data - layers build on each other.
Foundational data traps
Foundational records (company, location, user, group) are prerequisites: services, CIs, and ownership all point at them. Questions often test that foundational data must be cleaned and deduplicated before service modeling, because duplicated locations or groups corrupt every downstream report.
Worked example
A payroll application runs in a data center owned by a subsidiary. The company and location are foundation; the payroll business service and its offering are design; the application service and hosting CIs are build; the incident raised against it is manage. Getting this mapping right is what makes cross-domain reporting possible.