Extend a CMDB table or add a type field?

[Bradley Ross]

As we are designing our CMDB and adding custom tables, we are trying to debate the relative merits of extending a table versus adding a type field on a table.

For example, there is a "Virtual Machine" table with extended tables "KVM", "Parallels", "VMware", and "Zones". If I don't intend to track any unique fields in the child tables, I could just add these four options to a "Type" field on the "Virtual Machine" table instead of having a bunch of extended tables. Keeping the table structure flat appeals to my desire to have fewer CI types (or I guess we'd call them "classes" in the ServiceNow lingo).

We are debating our security camera CI type. We have cameras for security purposes that are tied to one system, Genetec. We have cameras for observation rooms that are part of a different system, PDS. They will have unique discovery procedures from the different systems. But they could be the exact same hardware used in each case. We could make a parent CI table called "Camera" with child tables "Security Camera" and "Observation Camera". Or I could add a "type" field to the "Camera" table.

ServiceNow seems to have opted for the hierarchical approach with their out-of-the-box tables. Can you think of pros and cons for the two approaches if I don't need unique fields on the potential child tables?

[jake_mckenna]

Common debate and discussion that has come up on almost every deployment I have done around CMDB. Mostly when we are looking to consider new tables vs. added attributes we also take into consideration the security we would need. If a devices differ not only by an attribute, but also by who manages them we would also consider two table instead of one. For your example if the security cameras are only supposed to be seen by and controlled by Security and Observation have a different group then two extended tables would make sense here. Otherwise a general attribute to ID them as a functional use into a common camera table should be enough.

This logic might not always work, and depends on how an organization is setup. Just something to consider when thinking of who can CRUD a table in the CMDB and how granular you might get.

[Bradley Ross]

Security considerations is a great idea. In my case, the same group would install and maintain the cameras themselves, even though the cameras are part of systems maintained by separate groups on the server side.

[mechamberlain · Accepted solution]

Unfortunately, there's not an easy (or even "right") answer.  

CI Classes are used for (and drive) other things in ServiceNow which you should consider as part of your decision.   For example, a couple (of the many) things to think about:

• Model Categories in ServiceNow associate CI Classes with corresponding Asset Classes. So in your example, if you wished to create Asset records for "Security Cameras" but not for "Observation Cameras", you might want seperate CI Classes to keep things simple.
• CI Classes are the basis for "Suggested Relationships".   So CI's of different Classes can have different suggested relationships in the CMDB.

Keep things like this in mind.   Good luck!

Marty

[Bradley Ross]

Thinking about when other processes will be triggered by the Class is valuable. We have set up a series of recurring preventative maintenance tasks that can be automatically triggered for each new CI of a given type. If they aren't separate classes, then we'd have to make that logic that generates the maintenance tasks more complex.

I don't understand model categories yet, not the categories field on the cmdb_ci table. That is one of the items on my list to research.