Section 5.2: CSDM Design, Build, and Manage Technical Services Domains

CSDM Design, Build, and Manage Technical Services Domains

The transition of a digital capability from architectural planning to active operations is governed by three primary CSDM domains: Design, Build, and Manage Technical Services. Understanding the boundary lines between these domains and the specific roles of their Configuration Items (CIs) is critical for passing the CIS-DF exam.

The Design Domain and Business Applications

The Design Domain is used to define the conceptual architecture of applications. The central CI class in this domain is the Business Application (cmdb_ci_business_app).

It is vital to understand that a Business Application is a conceptual, non-operational CI. This means:

• It does not have an IP address.
• It is not discovered by network sweeps.
• IT agents should never log standard operational incidents, problems, or changes directly against a Business Application CI.
• Instead, it is used by Application Portfolio Management (APM) to track software portfolios, business criticality, roadmaps, and software lifecycle costs.

For example, an organization might have a Business Application named "Global Oracle ERP." This record tracks the strategic value and ownership of the ERP capability. Underneath it, the Design domain also models Information Objects (cmdb_ci_information_object), which represent the logical data types (such as "Employee PII" or "Corporate Financial Data") that the Business Application processes. This provides context for data privacy compliance without requiring connection to specific databases.

Information Objects and Data Privacy

Within the Design domain, CSDM 4.0 incorporates the Information Object (cmdb_ci_information_object) to address compliance and risk management. An Information Object represents a logical collection of data elements, such as "Credit Card Numbers (PCI-DSS)" or "Protected Health Information (PHI)."

• Information Objects are linked to Business Applications via the Logical Content relationship.
• Unlike database schemas or tables, Information Objects are high-level descriptors that allow risk management teams to identify which applications process sensitive data without needing to examine individual database CIs.
• This creates a clean layer of abstraction for GRC (Governance, Risk, and Compliance) reporting, mapping logical regulatory scope directly to application portfolios.

The Build Domain and SDLC Components

The Build Domain serves as the bridge between software development pipelines and active operations. As organizations adopt DevOps and Agile methodologies, they need a way to link code repositories and build artifacts to the logical applications they realize.

The central CI class in the Build domain is the SDLC Component (cmdb_ci_sdlc_component). This CI represents a unit of software code (like a microservice, repository, or build package) that is developed and compiled. When software is compiled through a CI/CD pipeline, the build results are tracked in the Build domain. By linking SDLC Components back to their parent Business Applications and forward to the operational Application Services, ServiceNow provides full traceability from the initial code commit in a Git repository to the running containers in a production Kubernetes cluster.

The Manage Technical Services Domain

The Manage Technical Services Domain represents the operational phase of the CSDM lifecycle. This is where development assets turn into running systems that must be supported and monitored.

The critical bridge between Design and Operations is the Application Service (cmdb_ci_service_discovered). An Application Service represents a logical deployment of a Business Application in a specific environment. For example:

• "Global Oracle ERP - Production"
• "Global Oracle ERP - Test"
• "Global Oracle ERP - Dev - US East"

Unlike Business Applications, Application Services are operational CIs. They serve as the entry points for Service Mapping, are populated with relationships to hosts, databases, and network switches, and are the primary targets for operational incidents, changes, and Event Management alerts.

This domain also houses Technical Services (cmdb_ci_service_technical) and Technical Service Offerings (service_offering of type technical).

• A Technical Service represents an internal service capability published by an IT provider (e.g., "Database Hosting" or "Network Administration").
• A Technical Service Offering represents a specific tier of that service with defined SLA, OLA, support hours, and an operational Support Group (e.g., "Oracle Database Support - Gold 24x7").

When a database fails, the incident is logged against the Database CI. Through relationship routing, the system identifies that this database supports the "Global Oracle ERP - Production" Application Service, which in turn maps to the "Database Hosting - Gold" Technical Service Offering, triggering alert notifications to the appropriate DBA support group.

CSDM 4.0 Digital Product Models

CSDM 4.0 introduces the Digital Product Model as a unified concept that spans the Design, Build, and Manage domains. Instead of viewing applications, software builds, and deployed infrastructure as siloed elements, the Digital Product Model treats them as a single continuous product. This model tracks the product from its initial conceptual design, through the pipeline build stages (using SDLC Components), to its live operational status (using Application Services), and finally to its business portfolio definition. This unified view enables organizations to manage the total cost of ownership (TCO) and measure the value of digital products end-to-end.

Distinguishing CSDM Operational and Non-Operational Elements

To succeed on the CIS-DF exam, candidates must be able to contrast conceptual architectural design records with deployed, discoverable operational configuration items: