Best practice for applying a default Support Group for a CMDB Class

lucaslopesm · 3 weeks ago

Hello guys,

I would like your help to design a good and proper way of populating the "support group" in some classes.

Why I am trying to achieve this:

I want that incidents, alerts etc always have a group when the CI is the main impacted resource.

What I have been studying for this:

TSO - Best option so far, but I found a caveat: If the some items of the class have other support group, I would have to create other TSOs, and since they don't have a "hierarchy", those TSO dynamic CI groups would be constantly maintained to guarantee that they don't overlap.

BR - Not native, but very doable with little effort, wonder if it would be a good practice for maintainability

Default field on the class table - Not native, but very doable with little effort, wonder if it would be a good practice for maintainability

Example1:

I would like to set default group for windows classes to be "MS Windows Support" but I have heavily secured servers (e.g. domain controllers) which also are windows and want to assign "MS Domain Services Support"

Example2:

I have a batch workload software (Control-M) whose jobs are maintained by different teams, and would like to default the group to one of them.

I don't know if I'm overthinking it or just am thinking just too narrowly, so feel free to contribute with options I haven't listed here

Mathew Hillyard · 2 weeks ago

@BharatC @lucaslopesm

This is absolutely a CSDM problem, which is what guides the routing. It's also because assigning support group and other groups to huge numbers of CIs via some form of custom logic is a recipe for disaster. CSDM seeks to make this far simpler by driving it from the (Technology Management) Service Offering.

The whole point of the Foundation domain is to ensure your CMDB data is accurate enough to:

Support build out of Service Instances (Business Application instantiations)
Enable the build out of Technology Management Services and Offerings via Dynamic CI Groups

If you are struggling to avoid overlap with Dynamic CI Groups look again at the foundation data quality, and if that doesn't work, take a long hard look at your support model, as it may well be over-complicated.

I can recall several situations I have encountered where inadequate foundation data has slowed or even completely stalled a CSDM implementation. There's a reason it comes first and it's important to be disciplined about enforcing better data quality.

There are many examples of this kind of dynamic allocation of related objects in the platform so wherever possibly do your best to leverage them.

If after all that, you still cannot get things to work properly without some form of customisation, use custom logic to add CIs to a CMDB Group so your entire TMSO architecture is consistent (all TMSOs are linked to a DCG related to a CMDB Group with related CIs).

I hope this helps!
Mat

View solution in original post

Mathew Hillyard · 2 weeks ago

@vaishali231

Did you use AI to draft your reply?