Robin John

The CSDM Puzzle: How to Finally Align Your Stakeholders (Part 2)

This is the second post in my series sharing insights and experiences with implementing CSDM. In part 1, I explored the terminology related to the word “Application” in CSDM. In this second installment, I will focus on clarifying the terms that include the word “Service.”

1. The Four Pillars of Service Modeling in CSDM 5.0

CSDM 5.0 defines four critical entities to ensure a clear distinction between what the business consumes and what IT provides.

1.1. Business Service (The “Why”)

The Business Service is housed within the Service Consumption Domain. It represents an entity that defines the strategic business value and facilitates the management of their life cycle. The fundamental role of the Business Service is to identify the why—the value or goal for the organization.

A service is classified as a Business Service if it has an internal or external customer. Architecturally, Business Services should be named after the value they deliver to the business, avoiding technical terminology (e.g., “Digital Signature Services” rather than referencing a specific tool). These services typically implement one or more Business Capabilities and serve as the highest layer for impact reporting during ITSM processes like Incident and Change Management.

1.2. Service Offering (Business Service Offering and Technology Management Service Offering) (The Specific “What”)

The Service Offering is a classification or stratification of either a Business Service or a Technical Service, defining specific strategic value and commitment.

For the business customer, the Business Service Offering is located in the Service Consumption domain. It specifies the concrete deliverables, features, and commitments, such as availability, pricing, and specific Service Level Agreements (SLAs). Service Offerings represent the tangible deliverables or solutions (the what) and are directly tied to the Service Catalog Request Item(s) consumed by the end-user.

The architectural separation between the Business Service and its Offering is vital, as it allows the organization to manage the high-level value stream while providing differentiated tiers of service commitment to various internal or external customers.

1.3. Application Service (Service Instance) (The Deployed “Where”)

In CSDM 5.0, the term Application Service is retained but is categorized as a type within the broader, generalized class known as the Service Instance. This entity is located in the Service Delivery Domain.

A Service Instance represents a specific, deployed, provisioned, and/or configured instance of an application stack or service. Its key function is to link the logical business view (Business Application) down to the physical or virtual infrastructure Configuration Items (CIs). Service Instances are the key relationship entity for ITSM, ITOM, ITBM, and CSM processes. The expansion of Service Instance siblings now accommodates Data, Network, Operational Process, and Facility Service Instances, reflecting CSDM 5.0’s move into expanded service use cases.

1.4. Technology Management Service (Technical Service) (The Underpinning “How”)

In CSDM 5.0, the entity previously known as “Technical Service” has been relabeled to Technology Management Service. It is located in the Service Delivery Domain.

These services are infrastructure-focused, supporting and underpinning the delivery of Business Services or Application Services. They represent the provider’s view and delivery mechanisms needed to realize consumed services. Crucially, Technology Management Services are consumed primarily by IT staff, service owners, or support teams, not the end business customer. Their corresponding Technology Management Service Offerings detail the provision of technical support, defining stratification based on environment, capability, support groups, and technical approval groups.

The architectural design ensures that when an operational failure occurs in an Application Service, the associated Business Service absorbs the impact (measured by the Business Service Offering), while the related Technology Management Service Offering dictates which technical team is responsible for the troubleshooting and repair of the underlying infrastructure components. This clear division between impact and remediation responsibility ensures efficient incident routing and accurate reporting.

2. Prescriptive Relationships and Impact Analysis

CSDM 5.0 provides the prescriptive relationships necessary for robust impact analysis, a primary benefit realized through ITSM and ITOM integration. This connectivity forms the Digital System Model, a layered approach encompassing Business Process, Service (Logical), Functional, and Infrastructure layers.

2.1. Linking Value to Deployment: Business Application to Service Instance

The primary function of the CSDM is to trace business value down to the underlying technology risk. Enterprise architects are required to establish a relationship between Business Capabilities and Business Applications for visualization. Subsequently, a relationship must be established between Business Applications and their corresponding Application Services (Service Instances) to identify technologies that pose risks to those business capabilities.

The recommended architectural relationship between the Business Application and the Service Instance is typically Consumes::Provided by (or a similar dependency relationship). This models the reality that the logical Business Application relies upon the functionality provided by a specific deployed instance (the Service Instance).

2.2. Service Instance Dependencies and Upward Impact Tracing

The Application Service (Service Instance) serves as the central hub for mapping the deployed stack. It is related to all underlying infrastructure Configuration Items (CIs), such as servers, databases, and network components, using the Depends on::Used by relationship. This relationship is fundamental for upward impact analysis; when a low-level infrastructure CI fails, the system traces the dependency chain upward to identify which Service Instances, Business Applications, and ultimately, Business Services, are impacted.

It is essential to maintain a simple hierarchy of Service Instances. Overly complex, multi-layered hierarchies of interconnected Service Instances can complicate troubleshooting and lead to hundreds of impacted services during a Change Request, rendering the approval and management processes unworkable.

2.3. Leveraging Technology Management Service Offerings for Governance

The Technology Management Service Offering provides the crucial link between support teams and the CIs they manage. These offerings must be related to the applications or infrastructure CIs they support.

A central governance mechanism in CSDM is the utilization of a Dynamic CI Group. A Dynamic CI Group identifies a collection of CIs based on common criteria (e.g., “all production servers in the Eastern US region”). The Technology Management Service Offering is linked to this Dynamic CI Group, ensuring that all CIs dynamically grouped inherit configuration values from the offering, such as the designated Support Group, technical approval group, and ownership. This method centralizes configuration data governance, improving data quality and reducing the administrative burden of manually maintaining data veracity on thousands of individual CIs, aligning directly with CSDM’s principle of effective process to manage data integrity.

3. Case Study: Modeling an E-Commerce Platform

This case study models an e-commerce website hosted on a server, utilizing WordPress (Application), MariaDB (Database), and Tomcat (Web Server), applying the CSDM 5.0 service entity distinctions and relationships.

3.1. Layer 1: Service Consumption (The Value Layer)

The organizational value derived from this platform is defined in the Service Consumption domain.

  • Business Service: Online Sales Fulfillment. This is the strategic capability of processing and delivering orders.
  • Business Service Offering: E-Commerce Standard Package (99.9% Availability). This is the specific tier of service, including commitments and SLAs, made available to the business user.

3.2. Layer 2: Functional and Deployment (The Logical and Deployed Layers)

The logical design resides in the Design & Planning domain, and its specific runtime deployment resides in the Service Delivery domain.

  • Business Application (Logical): Online Shopping System. This is the portfolio entity that represents the logical application, regardless of how many instances are deployed.
  • Application Service (Service Instance): E-Comm Prod Web Stack. This is the specific deployed configuration instance running the e-commerce functionality. It represents the deployed stack containing WordPress, Tomcat, and its connection to the MariaDB instance.

The relationship linking these two is critical: Online Shopping System Consumes::Provided by E-Comm Prod Web Stack.

3.3. Layer 3: Infrastructure and CI Mapping

The Application Service/Service Instance serves as the containment mechanism for all dependent physical and virtual CIs that comprise the deployed stack.

  • Infrastructure CIs:
    • Server CI: SRV0123 – Prod Web Host (The physical or virtual machine host).
    • Web Server CI: Tomcat Instance 8.5 (The application server software).
    • Database CI: MariaDB Instance Prod (The specific database software instance).
    • Application CI: WordPress Application vX.2 (The code base/functional capability).

The Service Instance E-Comm Prod Web Stack Depends on::Used by the SRV0123, Tomcat Instance 8.5, and MariaDB Instance Prod CIs. This dependency chain is the foundation of impact analysis.

3.4. Layer 4: Service Delivery (The Underpinning Support Layer)

The underlying infrastructure CIs are supported by Technology Management Services.

  • Technology Management Service: Database Hosting Service. This is the general infrastructure-focused service covering database management practices.
  • Technology Management Service Offering: DB Hosting Gold Tier (24/7). This defines the support coverage and is linked to the responsible support group (e.g., DBA Production Team). This offering is typically linked via a Dynamic CI Group to target the MariaDB Instance Prod CI.

Architecturally, DB Hosting Gold Tier Offering Provides support for::Used by the MariaDB Instance Prod CI (or a similar relationship).

3.5. Impact and Remediation Trace Example

Consider a major incident affects the MariaDB Instance Prod CI:

  1. Impact Determination: The system calculates the upstream impact by following the Depends on::Used by relationship chain: The failure impacts E-Comm Prod Web Stack, which then impacts the Online Shopping System Business Application, leading to a degraded status for the Online Sales FulfillmentBusiness Service. The severity of this impact is measured against the E-Commerce Standard Package (99.9% Availability) SLA defined in the Business Service Offering.
  2. Remediation Routing: The incident ticket is automatically routed for remediation. Because the MariaDB Instance Prod CI is linked to the DB Hosting Gold Tier Technology Management Service Offering, the system assigns the incident directly to the “DBA Production Team” defined in that offering. The Service Owner for the Online Sales Fulfillment Business Service is notified of the business impact, while the technical team is assigned based on service delivery ownership.

E-Commerce Service Architecture Mapping

CSDM EntityExample Instance NameCSDM DomainRelationship to Other EntitiesFocus
Business ServiceOnline Sales FulfillmentService ConsumptionProvides Business Service OfferingStrategic Value
Business Service OfferingE-Commerce Standard Package (99.9% SLA)Service ConsumptionProvided by Business ServiceCustomer Commitments (SLA/Cost)
Business ApplicationOnline Shopping SystemDesign & PlanningConsumes::Provided by Service InstanceLogical Application/Risk Assessment
Application Service (Service Instance)E-Comm Prod Web StackService DeliveryDepends on::Used by Infrastructure CIsDeployed Runtime Stack
Technology Management ServiceDatabase Hosting ServiceService DeliveryUnderpins Application Service/CIsTechnical Practice/Internal Support
Technology Mgmt Service OfferingDB Hosting Gold Tier (24/7)Service DeliveryProvides Support for::Used by MariaDB CISupport Group Assignment/Technical SLA

4. Conclusion and CSDM 5.0 Maturity Roadmap

CSDM 5.0 is the critical enabler for organizations to transition from fragmented IT management to unified digital value orchestration. Its foundational structure, encompassing seven domains, now comprehensively links executive strategy (Ideation & Strategy) to operational monitoring (Service Delivery) and consumer satisfaction (Service Consumption).

The architectural choice to distinguish between Business Services/Offerings (value/impact) and Application Services/Technology Management Services (delivery/repair) ensures that IT operations can achieve optimal efficiency in remediation while simultaneously providing the business with accurate, value-centric impact reporting. Furthermore, the introduction of expanded Service Instances (for Data, Facility, etc.) and specific governance classes for AI and SBOM positions CSDM 5.0 as an indispensable prerequisite for leveraging advanced ServiceNow platform capabilities and managing enterprise-wide IT/OT risk convergence.

For any organization utilizing ServiceNow, full adoption of CSDM 5.0 best practices—progressing through the Foundation, Crawl, Walk, Run, and Fly maturity stages—is essential to maximize platform investment, achieve robust data quality, and secure the necessary architectural alignment for future automated and integrated digital value networks.1 Failure to standardize the CMDB structure according to CSDM 5.0 guidelines will result in governance challenges, inaccurate impact analysis, and an inability to fully capitalize on advanced features like Generative AI.

Sources:

RJ

Leave a Reply

Your email address will not be published. Required fields are marked *