How to tie Application Services to Tech Services and Offerings when Dynamic CI Group is being used?

[AustinN]

Hello,

Currently we have App Services built out for all of our 600+ Business Applications. We are in the process of Service Mapping and building out Technical Services, TS Offerings and Dynamic CI Groups.

We have built out for example a Technical Service for Middleware Messaging, have Offerings for the different Models of IBM MQ (7.5, 8.0, 9.1) and then have the Dynamic CI Groups to query each of those groups of CI's by Model ID. 

1. We now want to understand how to determine which Application Services are using the Middleware Messaging Technical Service. For example, if someone entered a CHG or INC ticket on the Technical Service, how could we identify which Applications Services will be impacted?

2. Also, how could we see on the Application Service record what Offering and Tech Services they are consuming?

3. Also, how do we see on the CI level (and IBM MQ 8.0 device) what Technical Service/Offering it falls under? 

Another example would be OpenShift Clusters (Kubernetes) If we created Tech Services and Offerings for these, how would we know what application services are using them in the CSDM?

There doesn't seem to be a good answer in the white papers.

[CMDB Whisperer]

I get it conceptually and agree with that view.  However, I also know from experience that the more specific and accurate you can create these relationships, the better off you are, generally speaking.  And that there are multiple methods of answering questions by querying different relationships and tables.  For example, if I define the dependency from the Application Service to the specific MQ CIs, and I want to know "what applications are affected by MQ devices" then I can simply query the Service Association table for Application Services with CIs meeting that criteria.  That gives me a list of Application Services without having to create a generic dependency.  I mean if I have a Server as part of an Application Service, then don't I also depend on Server Management to run and support that Server effectively?  But that doesn't mean I should create a dependency between my Application Service and the Server Management technical service.  The problem with such high level dependencies is that they create too many impacted services.  If everything affects everything, then impacted services and other impact indicators cease to be useful in practice.

[AustinN]

But if something is changing with the Server Management Service ci's, and every server under that tech service is going to be impacted, then every App Service depending on one of those ci's will also be impacted. I am not saying an app service would be directly related to the tech service but it is dependent on the tech service as a whole being up and running or impacted by a change. In the model they touch each other through a series of relationships of different tables (below).

Also, I am a little lost on a scenario where we would use the recommended Tech Service Offering --Contains--> Application Service but that may be a completely different conversation.  

[Barry Kant]

Good day,

reading this thread the closest you are expecting here is done in SPM. It is a part that is not described in CSDM as such, but the concept is a Service breakdown. 

A Business Service Offering has underpinning Technical Service Offerings. Meaning as a Business Service Manager if I onboard new Service Offerings I need to ensure that my agreements towards the consumers can be supported by the Technical Service Offering (agreements).

it makes sense to do this on the Business Service Offering and not on the Application Service layer as how you offer it, and how you support it is on the offering level.

Technically those are cmdb_rel_ci records between:

• parent : business service offering
• child.   : technical service offering
• rel type: depends on

1 - In incident or change the impact analysis starts with Configuration Item as input. The output is all upstream records that are within the cmdb_ci_service table (and it extends) with some class exceptions. You wouldn't like it with a Technical Service Offering as input as that will result in most of your applications if your Technical Service Offering is eg Windows hosting and you include 5000 windows servers it shows way to much as output. Also if you start an incident or change with a Technical Service Offering I guess the impacted Configuration Item is already known.

2 - if you open your application service via:
CSDM > Manage Technical Services > application service then it is using a differnt UI ($csdm_app_service.do)

These are cmdb_rel_ci relations visualized and manageable in listbuilders.

3 - You cannot see directly which Technical Service Offering is related to a CI. Directly it includes the Support Group but a Support Group can support multiple Technical Service Offerings. It would be possible to add the Technical Service Offering name in the sync logic, but that requires a new attribute in the cmdb_ci table. 
The svc_ci_assoc table includes the Dynamic CI Group as Server ID. Then still you need to search in the cmdb_rel_ci table for a parent Technical Service Offering for this Dynamic CI Group. 

Cheers,

Barry