Use and relationships with Dynamic CI Groups for CSDM v3.0

Rob50
Tera Contributor

In CSDM v3.0 the "Dynamic CI Group" entity was introduced which allowed you to leverage queries to group CI's together. 

We have groups of servers in our monitoring solution representing services, and identified the Dynamic CI Group as a logical fit for this mapping in ServiceNow. I don't believe mapping these servers directly to an Application Service, as it would not provide much value and doesn't align with how the application service is intended to be used.

In the latest version of the CSDM Dynamic CI Groups DON'T have a direct relationship with Application or Technical Services.

Has anybody used the "Dynamic CI group in anger and if so, in what context have you used it? Additionally, is it wrong to directly relate a dynamic CI group to and application/technical service in the CMDB?

@scott.lemm I'd appreciate your thoughts on this use case?

Thanks in advance,

R

12 REPLIES 12

Ok, indeed you select the service offering that is responsible for the topic. If you have application teams managing drives then that should selected (it could be one of the existing offerings on the previous image or modeled separately).

For your second question: Yes that is what I would expect, the more you narrow down the root of the issue you change the CI/service offering accordingly. 

As mentioned before, the application itself should appear in the impacted services related list so the information is not lost.  

Paul Wike _FlyF
Giga Contributor

Hi Stefan,

 

Could you associate the Application Service SAP PROD with the Technical Service Offering 'Windows Management' ?  This would give you the link to the TSO that you need,  but I too think this could be drawn better on the map.

 

Paul.

Barry Kant
ServiceNow Employee
ServiceNow Employee

Hi all,

 

one option, that is proposed in the SPM Advanced view of Service Offerings, is to create Service Offering - Service Offering relations. It results in:

This Business Service Offering is depending on those Technical Service Offerings. 

You can extract the Support Groups that way in a to be made reference qualifier. This is more beneficial for Incident Agents if:

  • the incident is initiated from the business side and the CI level is not clear yet. 
  • the service model is not at a mature level

For event/technical initiated Incident you register on the Technical Service Offering and the CI level is know. While using Dynamic CI Groups you need to search for CI associations for the related Dynamic CI Group and from there the CI Relations to search the Related Parent Technical Service Offering. 

An alternative of Dynamic CI Groups might be to explore the Health Compliance rules and on fail to create a CI Relation to the Technical Offering that is expected.