Best Practice for Dynamic CI Group

[KennyWong]

Hello Community, 

We are looking into using Dynamic CI groups and wants to know what is the best practices for the queries that can be used for Server/Network Devices/Middleware identifications. 

Currently, Servers are only using IP Subnets to separate our in our environment - NA, Asia, etc. Internal facing/external facing/DMZ are also separated by the IP Subnets. 

We would like to know what would be a better way that we can leverage to create those dynamic CI groups? We do have location fields but they are manually populated and maintained by the Server team. 

What other meaningful attributes we can use to help creating the dynamic CI groups? The name are always generic numbers and sequence are based on ascending - Prod/DEV/test/etc are all just in sequence. So using the server name would not be helpful. 

Hopefully to hear from what other organizations are doing to help with setting up dynamic CI groups. 

Thanks!

[Mathew Hillyard]

Hi @KennyWong 

Foundation data is a key subject in CSDM because if it is not in shape, it makes several elements hard to achieve (or even possible). Dynamic CI Groups are an important part of that - Location, Product Model, Operating System etc. are common ways of building queries on the Server table.

As you've already discovered, it's not advisable to create queries based on text fields as they are unreliable (any data can be entered). Pick reference or choice fields for data integrity.

The answer to your question should be guided by how these Servers are supported - ultimately the Dynamic CI Group will be connected to a Technology Management Service Offering, so you need to establish the support model before building out the groups.

I hope this helps!
Mat

[Tyson Elder]

My general rules are:
DCIG - Setup a naming convention for your CMDB Groups. Sounds obvious - but it'l help your sanity.
Queries, I boil it down to two rules:
- Never text based
- Must be controlled/discovered attribute
-- Human Discovery = CMDB Data Manager policies/checks/enforceability
-- Technical Discovery = SCCM/Azure etc. etc. 

If I don't have a reliable technical attribute, then, via the CCB we identify an attribute and lock in cmdb data manager governance and control. 

....I coined the term 'Human Discovery'....many folks dislike this term. 🙂

[Its_Azar]

Hi there @KennyWong 

I would avoid relying only on IP subnets since those can become hard to maintain over time. In most cases, it’s better to use attributes that are automatically populated through Discovery or integrations.

Things like environment (Prod/Dev/Test), support group, business service, OS type, cloud account, location, or ownership fields usually work better for Dynamic CI Groups.

The main thing is to use fields that are consistent and not manually updated too much. That makes the groups more reliable in the long run.