CSDM
INTERVIEW.

How to answer

• The CMDB is the database — tables, classes, relationships, and the CIs themselves.
• CSDM (Common Service Data Model) is the modeling standard: which classes to use, how to relate them, and which lifecycle stage each belongs to.
• CSDM tells you WHERE in the CMDB a thing lives — e.g. a business service goes in cmdb_ci_service_business, not a custom table.
• Following CSDM means upgrades, Service Mapping, Impact analysis, and vendor integrations work out of the box.

Reference config

// CSDM-aligned classes (out of box)
cmdb_ci_service_business   // Business Service
cmdb_ci_service_technical  // Technical Service
cmdb_ci_service_offering   // Service Offering
cmdb_ci_app_server         // Technical CI (foundation)

// Anti-pattern: custom table for services
u_my_services              // breaks mapping, impact, upgrades

How to answer

• Foundation — the CIs everything stands on: servers, network, apps, databases (cmdb_ci infrastructure classes).
• Design — what you intend to build: business capabilities, application services, planned services.
• Technical — how it's delivered: technical services and their offerings, dynamic CI groups.
• Sell/Consume — what customers see: business services, service offerings, service catalogs, commitments.
• Manage — how you run it: incidents, changes, problems tied to services and offerings.
• A new microservice is a Technical domain CI (application service); its customer-facing offering belongs in Sell/Consume.

Reference config

// Domain placement cheat sheet
Foundation : cmdb_ci_server, cmdb_ci_database
Design     : cmdb_ci_business_capability,
             cmdb_ci_service_auto (planned)
Technical  : cmdb_ci_service_technical,
             cmdb_ci_service_offering (technical)
Sell/Consume: cmdb_ci_service_business,
             cmdb_ci_service_offering (business)
Manage     : incident.service_offering,
             change_request.cmdb_ci

How to answer

• A Business Service is the capability as the business sees it ('Email').
• A Service Offering is a specific way that service is delivered — with its own SLA, price, and commitment set.
• VIP and standard email = ONE business service, TWO service offerings ('Email — VIP', 'Email — Standard').
• Incidents and SLAs attach to the offering, so metrics split cleanly without duplicating the service.

Reference config

// One service, two offerings
svc = new GlideRecord('cmdb_ci_service_business');
svc.name = 'Email'; svc.insert();

off1 = new GlideRecord('cmdb_ci_service_offering');
off1.name = 'Email — VIP';
off1.parent = svc.sys_id;      // business service
off1.sla  = '99.99% / 15min response';

off2 = new GlideRecord('cmdb_ci_service_offering');
off2.name = 'Email — Standard';
off2.parent = svc.sys_id;
off2.sla  = '99.5% / 4h response';

How to answer

• Phase 1 — Foundation first: clean up identification/reconciliation, dedupe, and get infrastructure CIs trustworthy.
• Phase 2 — Crawl: model 3–5 critical business services end-to-end (service → offering → technical service → CIs).
• Phase 3 — Walk: extend to the top 20 services; wire Service Mapping and impact analysis.
• Phase 4 — Run: govern with CSDM lifecycle stages, KPIs on CI health, and a modeling review board.
• Never boil the ocean: CSDM adoption is measured per service, not per CI count.

Reference config

// Health check before migrating
var ga = new GlideAggregate('cmdb_ci');
ga.addAggregate('COUNT');
ga.groupBy('sys_class_name');
ga.query();
// → find classes with dupes, stale CIs,
//   and classes that should be service classes

// CSDM lifecycle per CI
ci.life_cycle_stage = 'Operational';
ci.life_cycle_stage_status = 'In use';