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

[Rob50]

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

[Rick25]

Hi Rob,

We are trying to define Technical Services (as dynamic ci groups) tied to tech service offerings to use in conjunction with an Incident. I think it's in a manner as described by Barry Kant. Although he used some terms and acronyms that I don't understand. I did also struggle to see how the other Technical Service played in. What I did was make the Technical Service Offering and defined a "contains" relationship to the Technical Service (as dynamic ci group).

I should also mention that we are driving the ticket creation from an Alert out of Event Management.

We're still trying to understand how all of this works. And we still don't fully understand it.

Regards,

Rick

[Stefan K_]

I have a related question:

I am trying to make the link to incident process, especially how to find a good service offering for the incident and consequently populate the assignment group based on the service offering.

Using the Dynamic CI Groups, the relationship trail ends at the technical CI since CSDM 3.0 asks only a "related list" connection rather than a relationship. Below is an example what you get, not seeing which technical service offerings and services lie behind the windows server "serv123":

How does the agent working on incident know which Service Offering to select on their incident if they suspect something might be off in the Windows server? They have no visibility beyond the server CI and what is managing it. 

What you would expect is to get FULL view, like this:

From such a view, I would know to select "Windows Management" as a service offering and populate the assignment group of the incident directly using its "Support Group" attribute.

Am I missing something? Is there some advanced reference qualifier where selecting the serv123 as a CI, it finds the service offerings by first "swimming up" a Dynamic CI Group?

PS. Is there a way to ask the dependency map to populate the value on your incident form (e.g. right click on Service Offering and select "Populate service offering on incident")?

[Rick25]

Hi Stefan and all,

We have a similar use case we are trying to handle. We are using Event Management. So, in my mind, the selection is driven by the particular event/alert. For example, using your relationship diagram, suppose the alert is for C:\ drive nearly full on serv123. In this case, we would want Windows Management. But suppose instead the alert is for a H:\ drive that is associated with SAP application. In that case we would want maybe Inventory Management.

Do you see it the same way?

Regards,

Rick

[Stefan K_]

Hi Rick,

Actually I don't see it the same way. In your example you have a hardware issue and the hardware itself (server) is under responsibility of the Windows Management. 

The Configuration item on the incident would nevertheless be the serv123. Everything "above" it (the application, application service, service offerings and service) would just appear under "Impacted Services/CI" related list. 

For me, the "Inventory Management" could be used as the initial service offering when user calls and says "I'm trying to do inventory management in SAP and it isn't working right...". The support group to attach to this offering would be a first level group, e.g. a functional support desk.

[Rick25]

Hi Stefan,

Just to clarify my example. Not a hardware issue but a space capacity issue. The way we handle this operationally depends on the use of the specific drive. When the capacity alert is for an "application" drive, the application team is responsible for taking action but for a system drive, it is a different team (i.e. windows management).

I agree on your other description. Let me ask, if someone were to call in and report "Inventory Management" problem. And later, someone works the problem and finds out the root cause was related to something in windows config - would you expect them to change the incident service to "Windows Management"?

Regards,

Rick