Why is it modeled like that? This question often comes up in CSDM workshops. This series of small articles will dive into some specific modeling practices related to not just CSDM but also Service Mapping.
The conundrum around dynamic CI groups is constantly one of the main topics when engaging in discussions with infrastructure teams. However, they are a great tool to simplify your CSDM structure - to a great degree. In my previous article "WIIMLT - (SaaS) Platform Application Instances" I highlighted, that complexity in CSDM must be use-related. So just to be clear upfront: There may be a niche where you won't need dynamic CI groups. But that niche is closing and likely only comes up if all of your infrastructure is managed by third parties (IaaS).
So let's five into the use of dynamic CI groups!
The model
The model for dynamic CI groups is straight forward:
Whenever some entity in your company is responsible for a horizontal slice, you should use dynamic CI groups. Let me show you an example:
And off we go, done. Note, that only one TSO is related to the dynamic CI groups. The alternative would be to draw these relationships between TSO & CIs directly... But that would be way more effort.
The key principle
Now why do we model it like that? Ownership, support & process integration.
Ownership -> A group is owning these infrastructure CIs (they pay for it) [Note: sometimes ownership is solved based on the upward service relationship!]
Support -> A group is managing these infrastructure CIs (they work on tickets & tasks)
Process Integration -> A change impacting all Windows Servers will only require you to add that one dynamic CI group
And based on these principles we can separate the dynamic CI groups into different ones.
Ownership -> separate ownership (e.g. based on location) -> split it into different groups
Support -> Different teams manage the infrastructure -> split into different groups
Process integration -> want to have different rollout changes for different environments (dev, test, prod) -> split into different groups
And the best part? Through the query system of dynamic CI groups membership for a group is done automatically. Your production servers have a different hostname than the development ones? Awesome! Put that into a query.
In short: Dynamic CI groups allow you to group infrastructure items into different horizontal slices & connect them to their dedicated TSO. Best part? The TSO data on support groups etc. is automatically synchronized to the CIs in a group (also gets automatically updated, if the CI switches to a different dynamic CI group).
Normally this article would end here... but there is a hidden power in dynamic CI groups which you may have never known about...
The hidden power
Alright, let's get to the thing you likely won't find a documentation about.
Dynamic CI groups are "just" services. Yes, strictly speaking they are not - in the best alignment of CSDM. But hey, sue me. This is an edge case which works well. Let's assume you don't need a full vertical map of everything in your infrastructure, but you just want to group together infrastructure under one service. Let's say you don't need a good visualization on this and just want to see the impacted services, whenever a CI is added to the ITSM ticket.
Well, as long as you have a distinguishing factor on your CIs to automatically assign them to your application instance, dynamic CI groups are your friend. This could be anything, from hostnames having the application instance name encoded (e.g. all SAP Production servers begin with SAPRPDXXXXXX). By the best of all definitions, this is a horizontal grouping. Or all your Salesforce runs under the same cloud tenant; you can put that into a query as well.
Please note: More advanced ITOM Health features - mainly impact calculation - won't work well with this model. But everything else likely will.
This won't replace ServiceMapping. And in mature ITOM cases I actively recommend against this. Outside of that, this will be a great starting point to automatically relate your infrastructure to service - semi-automatically.
If you have any CSDM related example where you want insights on "why is it modeled like that?", feel free to drop a reply and I will look to add it to this series.
