Generic CI Class

zcurtin · ‎05-08-2020

We have been directed to create a handful of generic CIs (i.e., laptop, internet, local printer, etc.) by our organization and are struggling a bit with how to fit that into the CSDM.

If we were to create a new Class to put these what level would that live at? Child of CMDB_CI?

Is it a better solution to add the generic CIs into already existing classes? If so how can we create a new attribute called 'Is Generic?' that can be rolled out across all classes so we can identify them for better metrics/reporting in the future?

DaveHertel · ‎05-08-2020

Hi - I encourage you not to make this common mistake of adding classes, that in reality are not needed. The SN CMDB has been around for 15? years and has matured plenty.. there shouldn't be any need to add classes for the objects like you mentioned. Instead:

Understand what classes already exists and how to leverage it. Example: Laptops. There is already a broad class for computers (cmdb_ci_computers) and within it, the form factor (or other fields) can be used to differentiate. Things like models, categories, etc. are all there waiting to be used, or tweaked if really needed to track laptop/desktop/etc.

Creating new ci classes off ROOT of cmdb_ci should RARELY if EVER be done - and definitely not for the example provided. computers, printers, etc are already well established Ci classes. Use what exists as your 1st option. Only add CI classes after thorough research and then be careful to add to right place in CI hierarchy. Such as the computer class mentioned earlier, it could be subclassed if needed. the subclass inherits the goodness of attributes pertinent to computers... but subclassing off of top of CMDB_CI root would be a considerable mistake to track laptops.

For types of things you mentioned, a generic class should not be needed. Generic should generally be avoided anyway - it sounds like a dumping ground for stuff that will A) eventually become stale B) groups may not 'own' maintaining it and C) stale junk eventually leads to mistrust in the CMDB. When the source is no longer trusted, its just another tool that missed its opportunity to provide real value. my 2 cents.

For optimal reporting and metrics - put the right things in the right classes. don't generalize when you can be specific. don't add to what is already there. Learn about the CMDB CI classes and consider taking the free CMDB course on nowlearning for more info on these fundamentals.

Hope this helps?

View solution in original post

Rahul Priyadars · ‎05-08-2020

Looking at the list of cis you originally posted can easily be accommodated in service now csdm . You may need to add some attributes which may be specific to your organization needs. Service now product is designed with so much broad scope. As it's said adding new class is the very last option when you do not find a place holder . Regards RP

Vivek Andrews · ‎06-19-2024

Hi Dave, I am new to servicenow. We have a similar need to create a generic CI called Servers and another called Desktops. These are intended to be used e.g when a change request is to be raised to patch all windows servers or all desktop machines. We do not want to raise a change request for each CI server thats going to be patched. Looking for for some guidance. thank you.

DaveHertel · ‎06-20-2024

Hi Vivek -- I DEFINITELY would not create a new class for your use cases... just say NO 🙂

Create a couple somewhat generic, general purpose CI's in the existing classes and for your change control to patch "all" servers, then you could point the change ticket to this generic CI. A new class won't help you.. but a general purpose 'catch all' CI might suffice. Example:

1. in Server class (or windows class, or linux class..) create name: All-Servers

2. change ticket can then ref this "all-servers" CI.

consider maybe... having a dynamic(?) relationship between the 1 generic CI and all the server CI's that aren't retired, or meet some specific criteria. Something to enrich the generic CI with more meaningful insights. The generic CI is very.. well... generic... so it doesn't do much to help IT know which specific devices are being patched. OR create a few generic CI's with but with some clear identifiers.. like All-Servers-NY data center. and All-Servers-Paris, etc.

I'm not a fan of this approach... but its food for thought.

you definitely do NOT need to create new CI classes for your described use cases.

Hope this helps?