Dynamic CI group and CMDB Group

[Jason Stuart]

Dont know if this is the correct place to ask, but - Dynamic CI Group - it seems like a rabbit hole.  

You need to create a Dynamic CI Group

Then you need to choose a CMDB Group

Than you need to define your CI's that belong to the group.  So the question I have is - why go through all this work when you can just use a CMDB Group?  It seems like a layer that is not necessary.

[cassieb_ · Accepted solution]

Dynamic CI Groups are used with Technical Service Offerings. There is also a scheduled script that will push attributes from the Technical Service Offering to the CI members defined by the Dynamic CI group. This functionality is part of the CSDM

[cassieb_ · Accepted solution]

Dynamic CI Groups are used with Technical Service Offerings. There is also a scheduled script that will push attributes from the Technical Service Offering to the CI members defined by the Dynamic CI group. This functionality is part of the CSDM

[Jason Stuart]

That makes sense, it just seems like you are duplicating efforts though.

[cassieb_]

It may seem like that, but CMDB groups are also used to designate CIs from a health perspective. So two different purposes using the same underlying grouping capability.

[CMDB Whisperer · Accepted solution]

Like many things it's really just a result of the history of how these things developed.  CMDB Group was introduced before Dynamic CI Groups.  CMDB Group was designed as a way to group CIs without actually being a CI itself (note the difference between this and cmdb_ci_group which didn't do much either, even though it was a CI).  When it was first released, it didn't actually have much practical use.  There was the Health Group use case within the CMDB Health dashboard, and in theory there was a way to use CMDB Groups to do Mass Change Requests, but it was mostly one of those things ServiceNow expected customers to run with and implement independently.  Separately, in the Event Management application, they had introduced a CI class, which at the time they called Technical Service (i.e. query based service) and this had some similar dynamic filtering capabilities that CMDB Group had (though not as robust) but allowed Events to have a landing place on something that could be treated as a Service, which helped tie ITOM and ITSM capabilities together.  But in order to use it you had to own Event Management, so it really limited the utility of this class. 

Then CSDM comes in and provides an "a-ha moment" and acknowledges that the absence of this class in the core platform is a significant gap in representing a logical representation of IT operations.  And of course, when you have existing customers you can't (or shouldn't) just take away existing functionality, so they had to bring this into the platform and made the wise decision of leveraging the existing, more robust, grouping capabilities of CMDB Group to do the dynamic filtering, instead of the grouping capabilities already present in the Technical Service class, and then they renamed the Technical Service as Dynamic CI Group to make way for something that was a more appropriate high-level service class, since not every Technical Service involves dynamic grouping of CIs.  What they ended up with is a sound, rational design that, although confusing on the surface, does have a logical structure.  Think of CMDB Group as just a Filtering container, and Dynamic CI Group as the CI that wraps around the filtering container.  Honestly it's not much different in that sense from what you'll find in Certification Templates in Data Certification, or what you will find in Entity Types in GRC, where the filtering component is a separate object from that which is doing the collecting of the filter results.