Can / are technical services be supported by infrastructure CIs?

[Max Nowak]

Hi,

I'm a little confused about technical services, maybe someone can help me clear this up.

Let's say I have a technical service called "Database Services", with offerings like "Oracle Prod DB Mgmt", "Oracle Dev Mgmt", and so on. Someone could order one of these offerings as a "building block" for an application service (or something else), at least that's how I understood it.

Now, as far as I understand / imagine it, these offerings would offer you the provision and support of an Oracle DB instance. Now, a colleague came along and said "and the technical service would then depend on the underlying infrastructure that hosts the database instances". So in his mind, this is what this example would look like:

Initially, I disagreed, because this isn't a relationship mentioned in CSDM, but he reminded me that if the underlying infrastructure would fail, I wouldn't be able to provide the database service, so there must be a dependency there.

What do you think? Is this "correct" modeling according to CSDM, or am I (or my colleague) misunderstanding something here? I feel like the dependency is already modeled by the "hosted on" relationship of the database instances and could then be rolled up all the way to the service, but I'm not sure.

[SteveMac1 · Accepted solution]

Your original understanding of the CSDM structure in this case is the correct one. While there is an inherent dependency between the Technical Service and the Infrastructure, it is not modeled or managed as part of the CSDM. 

The inherent dependency runs like this:
Note: Added the infrastructure TS & TSO

'Database Services' Technical Service

is Referenced by 'Oracle Prod DB Mgmt' Technical Service Offering

Contains 'Prod Oracle DB Instances' Dynamic CI Group 

(Contains) 'Prod Oracle 1' DB Instance

Runs on 'Virtual Server 1' Server

(Contained by) 'Prod Linux Servers' Dynamic CI Group 

Contained by 'Prod Linux Server Mgmt' Technical Service Offering

References 'Server Mgmt' Technical Service

[AustinN]

Max, the way we are starting to build this out is to not relate the support infrastructure to the Technical Service directly but to treat the Offerings almost as a Business App in that they also have their own Application Services with a Contains relationship type. Then these App Services have their own relationships to the Support Infrastructure just like the Business Apps/App Services that depend on the Database Instances the Technical Service is providing. This way we comply with the CSDM Relationship types and model.

[Mark Bodman]

This deep dive discussion about Technical Service may help to better understand the 2 types (3 really) that we define in CSDM.  There are some subtle differences that are important to understand, and also you can mix and match them based on the granularity of the CI's that are being managed, and how they are provided to consumers.

https://youtu.be/xmwdrwY15rA 

[Jim Zeigler1]

Hi Mark,

I take issue with the way that CSDM documentation and videos mix together the ITOM operational CIs with the SPM Services and Services offerings that describe the service catalog. You cannot infer or obtain information about operational Application Services or Infrastructure CIs by looking at the SPM services that define the catalog. When a user selects an offering and the service request is provisioned, you may end up creating new Infrastructure CI's but those should only be associated with the request, not the SPM catalog services and service offerings.

Operational services (ITOM Application Services) that contain different classes of infrastructure CIs have an operational status and severity that is derived from the status of the Infrastructure CIs and sub-services that make up the service(defined as Service CI Associations created during Service Mapping). I usually refer to these as "Infrastructure Services" because they are managed and supported by the Infrastructure Support teams within IT. These used to be called "Technical Services" before CSDM relabeled them as Dynamic CI Groups and redefined the term "Technical Service" to model offerings in the Service Catalog.

Query based mapping is the easiest and most commonly used approach for defining Infrastructure Services because the group of infrastructure CIs that are of interest to the Service Owner are usually in the same class or group of similar classes(e.g., Windows Servers, Oracle Databases, Apache Web Servers, WebSphere Servers,...). When Infrastructure Services are grouped together so you can see the collective status of multiple Services, an Application Service Group is used to represent the group. If the DB support team wants to see the health of all Databases, you might have to pull together all the operational CIs created by discovery for all the different types of Databases.

It is also very commonplace for customers to want to see the status of an Application stack (e.g., a collection of Web, App, and Database Servers that host deployed Business Applications). In this case, the CIs in the Infrastructure Service could be discovered using pattern-based mapping, but there are no OOTB patterns for the Application Stacks. The patterns would have to ignore the deployed applications and focus on how the infrastructure CIs of the stack are interconnected and dependent on each other. Again, Query based mapping is the best way to define these Services.

I would like to propose the next version of CSDM focus more on operational services and only show Application Services and Service groups in the Gold quadrant that some CSDM documentation calls the "ITOM" quadrant.  I refer to it as the "Run" Quadrant because it holds only ITOM configuration items that are execute and have an operational state. I have attached my version of the CSDM 4.0 Quadrant diagram that I find is easier to explain to customers who want to know how ITOM fits into the CSDM model. In my diagram, I've included the Technical Service to Application Service relationship even though I feel it should not exist in the CSDM model(see Suggested Relationships).

I feel that SPM Services all belong in the sell/consume Quadrant because the CMDB model for SPM Technical and Business services are all identical, but are very all different from the model for ITOM services. It is unfortunate that SPM and ITOM services are derived from the same Service base class. This confuses many users because they are led to believe that SPM technical services are operational CIs and should have infrastructure CIs related to them. I've recommended to ServiceNow that the SPM only attributes relating to the Service Portfolio and Service Catalog Services and offerings be moved to a new "Catalog Services" superclass for the SPM subclasses of Service. Ideally, the "Catalog Service" superclass should be outside the cmcb_ci class hierarchy that contains only operational CIs.

Jim Zeigler