Back to Blog

Populating the Technical Platform/App Services Layer of the CSDM

Part II in our CSDM blog series - identify Application Services, relate them to Business Apps and Technical Service Offerings
min read
Caleb Cordes
April 30, 2024

Last time, we organized the CSDM into logical layers and then discussed the definition of “Technical Infrastructure Services.” If you need a refresher, please see part I of our blog series, A Layered Approach to Populating the CSDM, for a detailed explanation.

The next layer to go after is the “Technical Platform/App Services'' layer. This layer contains Technical Services and Service Offerings that support the Platform/Application Services that are built using the “building blocks” produced by the previous “Technical Infrastructure Services” layer. Expect the Technical Service Offerings of the “Technical Platform/App Services' layer to be related to one or more Application Services (the CSDM element representing the stack of Infrastructure CIs specifically built to deliver the Service Offering’s product). 

Technical Platform Services Layer

There’s usually a lot of debate about what qualifies to go in this layer, especially concerning applications that support the ecosystem (e.g., Exchange, CyberArk, SAN, VMware, IaC) versus those that support a business function. ServiceNow decided that the CSDM’s role is not to split hairs but to logically organize CMDB data to be functionally maintained by data owners and easily leveraged for other ServiceNow modules. That way, the CSDM behaves like a Rosetta Stone.  Here’s a graphic that explains how several ServiceNow modules leverage the same data.

Now that the business/infrastructure debate is moot use the following questions to help identify what gets an Application Service. Remember, an Application Service is “a logical representation of a deployed application stack.”

  • Does the service ride on a stack of CIs organized by feature, environment, location, and version? If yes, then use an Application Service to represent each stack. 
  • Does the service provide its functionality via deployed software or agents? If yes, then use an Application Service to represent what the clients talk to (e.g. the management console) and a Dynamic CI Group to associate the Technical Service Offering to the agent software installed on the clients.

It’s best practice that every Application Service be related to a Business Application. If SDLC Components are in play, then the relationship would go like this: Business Application > SDLC Component > Application Service. This is to handle the DevOps use cases for both Infrastructure-as-Code and Applications (essentially anything with a DevOps Pipeline).

Great news. The “Technical Platform/App Services” layer also includes Technical Service Offerings, which makes it very simple to manage the technical escalation and ownership structure for multiple Application Services. Let’s just say that by default, Application Services are decomposed by Environment, and you also wanted to have tickets go to different teams based on which Application Service is affected.  The model may look similar to this Endpoint Security model. 

Let’s just say that by default Application Services are decomposed by Environment and Location because the support group is different for each location. The model may look similar to this SAN model.

The number of CSDM objects to create should be kept to as few as FUNCTIONALLY necessary for whichever ServiceNow module the CSDM is going to be leveraged for. It is NOT recommended to allow data owners to create a CSDM model that matches their architectural diagram. Instead, it needs to represent the operational functionality of their service regarding whichever model is in use (e.g., Incident or Change). Suppose you can relate all of the Application Services to one Technical Service Offering, then GREAT. Data Owners will appreciate how little effort it takes to complete an attestation! To drive this point home, look at the Incident use case. When Event Management cuts an incident, the incident’s Configuration Item field is populated with an Infrastructure CI. The “Service” and “Service Offering” fields will be filtered to show the upstream Application Service(s) and then set by either automation or the person triaging the ticket. By default (OOTB), the Incident will be assigned to the Support Group of the selected Configuration Item. If that Support Group field is blank, the ticket will automatically be assigned to the Support Group of the Service Offering.

That’s all for now. The next post will focus on the “Technical Delivery Services” layer, which covers the ecosystem's unsung heroes.

Written by
Caleb Cordes
A ServiceNow Architect living to make the world a better place through automation and meaningful design. Geeks out to any conversation about ITOM, CSDM and operationalizing ServiceNow as a Service Offering. Lives to be a super dad to his kids and inspired by his wife. When time allows, he is a woodworker, cyclist, and outdoorsman.
you might also like
back to blog