_
_
.png)
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).
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.”
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.
