How to caregorise Appliances

[Nancy HP]

Hello

I am looking for guidance on how to classify appliances. All of my items are server appliances both physical and virtual, that cant be picked up by discovery.  We are currently using Utah version of ServiceNow and currently we dont see any ootb classes for appliance. Appreciate if you can guide us. TIA

[Jim O_Shea]

@Nancy HP  Did you ever receive an answer to your question? 

I have a similar situation.  We have vendor managed appliances that cannot be discovered - not even with SNMP.  But we also have network segmentation / air gaps that preclude our ability to discover.  My infrastructure teams wish to use the CMDB as their system of record for devices they manage.  Which is great!  They'd like to leverage APIs to add and update CIs in the CMDB.  My question is whether to use one custom appliance data class for tracking everything in this category.  Or, to leverage the appropriate category for each CI type (placing it in the class where it would normally go if it was discoverable) and simply tagging the CI somehow to identify it as an appliance.  This would allow for existing filtering to be leveraged on INC, ITM and CHG for example.  Meanwhile the tag would facilitate using something like data certification to assist with maintaining the accuracy of these manually added CIs. 

This is all hypothetical at this point and would appreciate some confirmation or feedback from someone who is doing something similar and feedback on its' success or issues.

Thanks,
Jim

[cdiorio]

Jim,

There are a whole bunch of additional questions that sprang to mind as I read your scenario, and of course, the quick answer of 'it's ServiceNow, you can do whatever you want!'...plus the fact that this platform always gives you 3-6 different ways to do the same thing.

Anyway...putting the CIs in each of their Class tables....will you have other CIs to also go there at a later point (and will having these devices there already cause any issue with those)? Do you plan to leverage any additional platform functionality for these CIs, such as Service/Catalog Requests, Incident/Problem/Change Management, CMDB Health or other CMDB management? How many of each type of appliance do you have...how many CIs will you wind up with in each table (if you are talking in the dozens, then having them all in one 'bucket' on the CMDB Workspace and Dashboard and reports and such might be easier to deal with than adding Classes to manage that will have such low numbers that your charts get skewed, for example). Point is...when you populate a bunch of tables with a low number of records, it increases the management required (including things like ACLs, etc.), you'll have to look in more places for the data or when adding to Affected CIs in a Change for example (user impact). Another consideration, do you plan to run these CIs through the IRE to make sure you don't have dupes, orphans, etc.

On the other hand, if you put them all in one custom table you will now have to manage THAT, including ACLs and such, starting from scratch....your imports would be simplified as they all go to the same destination table after ETL (well, you said API, so the teams are going to push the data to you? Still, giving all the teams the same destination info will be simpler for everybody)...this would also allow you to segregate these devices from any later devices that would end up in the same Class, and provide a central location for users managing them to look for them. If you ever decide, or are asked, to remove them from the CMDB, they'll all be in one spot so will be easily handled. Oh, and my dev lead's favorite thing...this would cause fewer Skipped Records on upgrades than modifying a whole bunch of tables with a new custom data element to identify 'appliance' CIs.

TL;DR - So, bottom line, the amount of effort is probably going to be about the same no matter which strategy you use, it will just be expended in different ways. My perception is that putting them all in one table will likely be a little easier for your users and your CMDB management team, but would have a bit more upfront development/configuration...putting them in their 'proper' Class tables would be easier on the dev/config front, but more long term management, more user questions, and a bit more management by the CMDB team. I think one big question that might help you decide...you already sort of look at these as their own thing, a specific type of CI in your CMDB...putting them all in one table reinforces that viewpoint.

Chris

P.S. We do not have appliances...as you pointed out they are not discoverable via SNMP or other methods, and the owners would not give us access to their management tools to use Service Graph Connector to import them. But we did talk about how we were going to handle them, so the above is partially based on those conversations (there was a lot more, but I kept getting interrupted, sorry if it is disjointed). We were spared the decision by being told no, but I was a big advocate for them all being in their own table (we were going to leverage an existing one...Network Appliance Hardware) for ease of use.