As this is a recurring discussion it is a good topic to explain via different use cases.
A Dynamic CI Group is a logical grouping of Configuration Items (CIs) that can be automatically populated (via CMDB Groups) and maintained based on rules, conditions, or queries. Beside that it can be manually administrated, which is not preferred.
Instead of explicitly choosing which CIs belong in the group, you define criteria (attributes, relationships, tags, status, ownership, location, etc.). Any CI that matches those criteria is included, and any CI that no longer matches is removed automatically.
Think of it as a living group that constantly updates itself as your environment changes.
Dynamic CI Group as a Service Instance container
A dynamic CI group acting as a service instance represents one running instance of a business or IT service, end-to-end.
It answers the question:
“What CIs together deliver this specific service, right now?”
This group is service-centric.
 |
The Dynamic CI Group as a Service Instance can be created via:
Service Instance base record (cmdb_ci_service_auto). In the wizard-populate step, you can choose the Dynamic CI Group method. When the record is updated the record class is changing from cmdb_ci_service_auto to cmdb_ci_query_based_service . While it was a base Service Instance in the first place, the service_classification = “Application Service”.
 |
Primary use cases:
- Service Instances / Product instances
- Impact analysis
- Change / Risk evaluation
- Blackout windows
- Service Health dashboards
Dynamic CI Group as a Technology Management Offering container
A dynamic CI group acting as a technical container represents a collection of CIs grouped by technical or operational similarity, not by service delivery.
It answers the question:
“Which CIs share the same technical or operational characteristics?”
This group is infrastructure-centric.
It represents the scope of CI’s managed by a team under the same commitments. Example:
Linux Hosting - GOLD
or
Linux Hosting in Datacenter Stockholm - GOLD
 |
The Dynamic CI Group as a Technology Management Container can be created via the menu: Configuration > Dynamic CI Group . This way the the service_classification = “Technical Service”.
An additional function of Dynamic CI Group with service_classification = “Technical Service” is the synchronization of Group data from the related Technology Management Offering via the Dynamic CI Group to all related CI’s. Meaning, the group management happens on the Technology Management Offering.
Define the scope of CI’s related to the Dynamic CI Group
To make it a dynamic group a CMDB Group is used. This CMDB Group can relate CI’s in 3 ways:
- Manual relation of CI’s.
- Dynamic relation of CI’s via encoded queries.
These are based on a specific CI class with a related condition.
- Dynamic Relation of CI’s via saved queries.
These are based on a Query Builder created query that can span multiple
CI classes.
Obviously, option 2 and 3 are preferred, otherwise it is not dynamic. The dynamics means, if a CI is ingested in the CMDB, and the conditions match with a CMDB query, it will be part of a Dynamic CI Group as a result.
 |
Combine Dynamic CI Groups
Supply Chain model
The well-known Service Model is a Service Instance with a vertical mapping of CI’s, where the CI’s itself are horizontal mapped to a Technology Management Offering. This is a supply chain model. Meaning, multiple underpinning offerings are supporting a Service Instance / Business Offering.
|
Patch Management
For infrastructure maintenance Patch Groups Dynamic CI Groups can be defined. Potentially those are related to a specific Technology Management Offering.
In a Change a Dynamic CI Group can be registered in the Configuration Item field, and the individual CI’s will be extracted in the affected CI’s related list.
The patch groups can be defined as Dynamic CI Groups of service_classification = “Technical Service”. Multiple Dynamic CI Groups can be related to the same Technology Management Offering. It is a good practice to define the Maintenance Windows on the Dynamic CI Groups for patching.
 |
When the Patching Service has other characteristics, like:
other support group or other commitments, then it is a good practice to define a separate Technology Management Offering for Patching.
Now there is a little challenge, as when told that a CI can be part of 1 Dynamic CI Group for the reason of inheriting Group data from the related Technology Management Offering, it means in practice: A CI can be part of 1 Dynamic CI Group with a service_classification = “Technical Service”. This scenario might need a specific service_classification for the patching groups. In the below example the CI’s inherit the support group from the Dynamic CI Group with service_classification = “Technical Service”, where for changes we can use the Dynamic CI Groups with service_classification = “Patch Group”. This way the Support Group for Patching can be derived from the Patching Technology Management Offering.
Similar use cases:
- Monitoring
- Security scanning
 |
All in all it takes a good strategy when and how to use Dynamic CI Groups at scale in a fluid CMDB.
