Section 5.3: Service Modeling and CI Alignment

Service Modeling and CI Alignment

The final stage of CSDM maturity involves connecting operational infrastructure to the business value it delivers. This alignment is managed by the Sell/Consume domain and involves structuring services to map technical capabilities directly to customer-facing business catalogs.

The Sell/Consume Domain and Business Services

The Sell/Consume Domain contains the services and offerings that are published to business users.

The two main classes in this domain are:

1. Business Service (cmdb_ci_service_business): Represents a service delivered to business customers that fulfills a business need (e.g., "Corporate Email" or "Employee Benefits Portal").
2. Business Service Offering (service_offering of type business): A specific tier or catalog option for a Business Service. Offerings define the service-level agreements (SLAs), support hours, and cost metrics visible to the consumer (e.g., "VIP Exchange Email Support" vs. "Standard Webmail Support").

To ensure proper alignment, CSDM enforces a strict hierarchy: every Service Offering must have a parent Business Service. The business service acts as the conceptual container, while the offering is the actual service contract that customers subscribe to.

Service Offerings as the Operational Pivot

CSDM designates the Service Offering as the operational pivot point for service delivery. While a Business Service (e.g., "Enterprise Storage") provides a high-level boundary, all SLA tracking, support groups, and routing rules are defined on the Service Offering (e.g., "Standard Storage" vs. "High-Performance Storage"). When an incident is logged, it is routed based on the offering. This allows IT to support a single service with multiple support tiers, avoiding duplicate service records.

Business Services vs. Technical Services

One of the most common configuration errors in ServiceNow is confusing Business Services with Technical Services. CSDM provides clear distinctions:

Business service offerings are used by the Service Catalog to present choices to end-users, whereas technical service offerings are used internally by the ITSM engine to determine the assignment group for incidents. For instance, an incident raised for a slow application service will route to the support group defined on the associated Technical Service Offering (e.g., "SAN Storage Admins"), while the business user receives updates regarding their Business Service Offering SLA status.

Dynamic CI Groups and Query-Based Services

In massive enterprise environments, mapping infrastructure CIs manually using static relationships is unsustainable. For instance, if an IT team manages 5,000 virtual servers that are dynamically provisioned and decommissioned daily, manually linking them to services in the CMDB is impossible.

CSDM resolves this scalability issue using Dynamic CI Groups (cmdb_ci_query_based_service). A Dynamic CI Group is a special type of service CI that represents a collection of configuration items populated automatically at runtime.

• It inherits from the standard Service table (cmdb_ci_service) but utilizes a saved CMDB Query (created via the CMDB Query Builder) to define its members.
• For example, a query can be defined as "All SQL Server Databases located in the Seattle Datacenter."
• Any time a new SQL database is discovered in Seattle, it automatically joins the Dynamic CI Group without manual intervention.

Dynamic CI Groups are treated as operational services in ServiceNow. They are heavily utilized in Change Management (to apply patches to a group of servers) and Incident Management (to route alerts for an entire cluster of hosts). Unlike standard Discovered Services, which require a strict top-down entry point mapping (e.g., via a URL), Dynamic CI Groups allow grouping of disparate infrastructure based on common attributes.

Real-World Dynamic CI Group Scenario

Consider a patching scenario where an IT administrator needs to update all Linux servers in Seattle. Under CSDM, the administrator:

1. Creates a query in CMDB Query Builder matching all Linux Server CIs in Seattle.
2. Saves the query and creates a Dynamic CI Group named "Seattle Linux Servers" linked to it.
3. Attaches the Dynamic CI Group to a Change Request.
4. The change workflow resolves the query at execution, identifying the exact server CIs to patch.

This automation ensures that newly provisioned servers are automatically included in patch cycles without manual relationship updates.

Top-Down Service Modeling Best Practices

CSDM success requires a phased implementation approach:

• Crawl Phase: Build the Foundation domain. Clean up users, locations, and groups. Map Business Applications in the Design domain.
• Walk Phase: Create operational Application Services. Map them to infrastructure CIs using Discovery, and link them to Business Applications via Realizes relationships.
• Run Phase: Define Technical Services and Technical Service Offerings in the Manage Technical Services domain to establish operational support structures.
• Fly Phase: Define customer-facing Business Services and Business Service Offerings in the Sell/Consume domain, connecting requests in the Service Catalog down to the infrastructure.

By following this sequence, organizations ensure they do not build complex business service maps on top of incomplete infrastructure data, avoiding inaccurate reporting and failed service-aware incident routing.