Extend a class versus adding a type field in classes

[mmgauvin]

I have a question concerning the Best Practices to adopt when we are starting to get some requirements around classifying assets on a 2nd level. (Under model categories)...

For example, we have communication devices like Polycom or Desk Phone that we want to classify for reporting purposes.   Should we extend 2 additional subclasses under the communication devices class or should we use the "type" attribute to differentiate these types of phones?

We have the same kind of requirements to identify ceiling mounted vs portable projectors. We created a subclass under "cmdb_ci" called "Video Conferencing Equipement" to record these projectors.   Now we would like to identify the ceiling mounted ones from the portables one.   Again, should we extend subclasses under the custom class. What is the best practice?

We have these kind of requirements where we're starting to experiment that 1 level of classification (model categories) might not be enough for classifying assets.   We are thinking of adding a "Sub Category" under the primary Model Category definition to be able to classify assets with 2 levels instead of only 1.

Has anybody experience these requirements and have you done something like that?   Is it a good thing to do or should we go along with extending classes?

Thanks,

Martin.

[Michael Fry1]

Not sure if there is a right or wrong answer here but we've run across the same issues. In some cases, full tables, but in others where the device count is low, or ever changing, we use a Device Type drop down field. Our class is called IP Devices, then Device Type drop down.

[Community Alums · Accepted solution]

Hi Martin,

I would approach this through Models. Here is my reasoning and how I would approach it based on the information you provided.

If there is no reason to extend a CI class, then don't. Reasons to do this would be that you have specific information to track about a particular type of item that is different or more specific than an existing class. This should be operational information that can change from CI to CI and isn't particular to a specific model. Another reason would be if you have different information to display on a form for the particular item.

From your description, I would say phones are phones and projectors are projectors. Using a Form factor field on the Model, you can identify not only different computer form factors, but phone and projector form factors. A polycom is a polycom. A desk phone is a desk phone. A portable projector is a portable projector. An Espon PowerLite is a portable projector, and it always will be. The Form factor field should be a choice list to keep the options fixed. You can then report on this.

Here is the difference where you might want to have a field on the CI record: mounting. A large projector (or even "portable" projectors) might be mounted to the ceiling or they could just be set up on a desk or even a portable cart. There is already a Location field, but this could help to identify how static the device is.

No categories or sub categories needed.

I hope this helps.

Ben

[mmgauvin]

Thanks Ben, yes it helps!   And I totally agree with the approach through the models.   I thought about the form factor example as well.