Data Foundations (CMDB and CSDM) cheat sheet

A CMDB is a repository of configuration records (CIs) and the relationships among them, supporting impact analysis, incident resolution, and change planning.

A CI is any component that must be managed to deliver a service: hardware, software, facilities, documentation, people, or a service itself.

Core CMDB attributes per CI typically include name, class, owner, environment, location, support group, and operational status.

CMDB class hierarchy: base CI class -> class-specific tables (e.g., server, database, application), with attributes inherited down the hierarchy.

Reconciliation vs. identification: identification discovers/creates records; reconciliation merges or de-duplicates records from multiple sources into one authoritative CI.

The CMDB is the data layer; the Configuration Management System (CMS) is the broader set of tools and processes that produce and consume that data.

A CMDB without defined CI classes, ownership, and relationships degrades into a flat asset list and loses impact-analysis value.

Health metrics for a CMDB include completeness, correctness, compliance, and currency (freshness) of CI records.

Configuration Management (CM) process activities: management planning, CI identification, control, status accounting, verification/audit, and reporting.

CI identification defines selection criteria (which components are CIs), naming conventions, and the level of granularity recorded.

Configuration control ensures changes to CIs go through change management; unauthorized changes are detected via audit.

Status accounting tracks the lifecycle state of each CI (e.g., ordered, installed, in stock, in maintenance, retired).

Verification/audit compares recorded CI data against actual discovered state and reports discrepancies for correction.

The CMS spans multiple data sources (discovery tools, asset management, service catalog, monitoring) and federates them into a consistent view.

A Definitive Media Library (DML) and Definitive Software Library store controlled versions of authorized software/media referenced by CIs.

The Configuration Management Plan documents scope, CI types, roles, and audit cadence for the organization.

CSDM is a prescriptive, standardized data model on the ServiceNow platform that defines how to represent services, products, and their relationships.

Purpose: provide a common language across IT and business so reporting, service mapping, and impact analysis use consistent definitions.

CSDM is layered: Foundation, Crawl, Walk, Run, and Fly - each layer adds maturity and scope.

Foundation layer covers company, business units, locations, users, groups, and the basic CI/asset data model.

Crawl layer introduces business services, service offerings, and technical services - the minimum viable service-aware model.

Walk layer adds application services and service instances; Run layer adds full service-level and product-level modeling.

Fly layer models the full portfolio including product models, service commitments, and business capability alignment.

CSDM is not a product you install; it is a data model and set of implementation guidance applied to the CMDB.

CSDM domains include: Foundation, Design, Sell/Consume, Manage Portfolio, Manage Technology, and Manage Services.

Foundation domain data: Company, Business Unit, Location, User, Group, and the CMDB class hierarchy for hardware/software.

Design domain models business services, service offerings, and their technical underpinnings (application services, technical services).

Sell/Consume domain covers service catalog items, request items, and the offerings presented to consumers.

Manage Portfolio domain covers product models, service commitments, and portfolio-level planning data.

Manage Technology domain covers infrastructure CIs: servers, databases, network devices, and their relationships.

Manage Services domain covers the operational service view used for incident, problem, and change impact.

Each CSDM layer builds on the prior layer; you cannot skip Foundation and expect higher-layer reporting to work.

Data governance defines who owns each CI class, who can edit records, and what the authoritative source is for each attribute.

Authoritative source designation: one system of record per CI class/attribute; other sources are reconciled into it.

CI ownership roles: CI owner (accountable), CI support group (operational), and data steward (quality).

Health dashboards typically measure completeness (% of required fields populated), correctness (matches discovery), and currency (last updated within threshold).

De-duplication and reconciliation rules must be defined before discovery runs at scale, or the CMDB fills with duplicate CIs.

Audit cadence: periodic verification of CI records against discovered state; discrepancies routed to owners for correction.

Retirement process: CIs that no longer exist are marked retired, not deleted, to preserve historical relationships and audit trails.

Governance metrics feed a continuous-improvement loop: identify gaps, assign remediation, re-measure.

Relationship types include depends on, runs on, connects to, hosted on, and member of - each direction (parent/child) must be modeled.

A CI relationship record stores parent CI, child CI, relationship type, and often a port or connection detail.

Service mapping (top-down) discovers application service topology by tracing traffic from entry points to underlying infrastructure.

Discovery (bottom-up) populates infrastructure CIs and their connections from network and agent data.

Impact analysis uses the relationship graph to determine which services and CIs are affected by a change or outage.

Business service -> service offering -> application service -> technical service -> infrastructure CI is the CSDM relationship chain.

Orphan CIs (no relationships) and circular relationships are common modeling defects that degrade impact analysis.

Relationship completeness is measured as the percentage of CIs with at least one modeled relationship.

CMDB value is realized through use cases: incident resolution, change impact, asset optimization, license compliance, and service costing.

Key CMDB KPIs: CI completeness, relationship completeness, duplicate rate, audit discrepancy rate, and discovery coverage.

CSDM maturity reporting maps current state to Foundation/Crawl/Walk/Run/Fly layers to show progression.

Impact-analysis reporting depends on relationship completeness; incomplete graphs produce false negatives in outage scoping.

Service costing and license true-up reports require accurate CI-to-service and CI-to-license relationships.

Trend reporting compares KPI values over time to demonstrate improvement from governance actions.

Dashboards should be role-specific: CI owners see data quality, service owners see service health, executives see value metrics.

Value realization requires tying CMDB metrics to business outcomes (reduced MTTR, fewer unauthorized changes, lower license spend).