Generic CI Class

[zcurtin]

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 · Accepted solution]

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?

[guythatusesserv]

Totally agree with your philosophy Dave. 

One small note, cmdb_ci_computer now has a child class of cmdb_ci_pc_hardware where we store our laptops.  We use the Model record to keep track that the CI is specifically a laptop.

[zcurtin]

Can you elaborate on the risks associated with creating a class off of cmdb_ci?

[guythatusesserv]

One example is Asset Management. If you hypothetically extend a u_laptop class off the top level table cmdb_ci, it won't work with the Asset Management application.

Asset Management is designed to work with the cmdb_ci_hardware table and all the tables extended from there (servers, personal computers, network gear, etc.).  If you were to create a new class for laptops (I personally don't think you should, I think you should use the personal computer class), but if you were to, the location of the table should be as a child of the Personal Computers class.

This is one example, but the entire ServiceNow ecosystem relies on the various specific parts of the CMDB.  ITSM, ITOM, ITBM, HR, etc. 

If you create and store CIs outside of the structure designed by ServiceNow, you lose the power of the CSDM (Common Service Data Model) that ServiceNow is creating.  Means you risk losing a lot of OOTB functionality in various apps.