How do you handle Deprecated List values?

Brad_McKenna

We all know that it is a big no no, no delete a list value that is used somewhere. You can of course rename it, however that does not prevent someone from continuing to use the value.

In our place, we are fortunate to be exclusively using the portal, except users whom have the Outlook Add-in. However aside from doing some scripting to hide specific list values when they get deprecated, such as a Support Group, we have been holding out users just do not use them. Obviously, this is unreliable and someone always uses a value that is in a list.

We are fortunate in the sense that we keep all data in OpsDB. Bad I know in the overall sense, but nice as it gives us the mobility to rebuild the DW when something goes awry or we decide to make a big update.

We'll be completing changing our classification model, do I will be leveraging the opportunity to deprecate an it item or two. But next time this occurs I won't have this luxury.

So how do you handle Deprecated List values?

Adam_Dzyacky

Hrmm...not a consistent data warehouse. That certainly throws a wrench in this. Because in lieu of that, I've gone through this exercise myself several times but it's always been with a single DW which not only simplifies but I think aids tremendously in what you're trying to accomplish. I'm still trying to think through the best way to achieve this in your scenario, but at the very least want to share my thought process with a consistent DW to at the very least provoke some further discussion/ideas.

• Introduce a new enum value called "Retired" or something to that effect then export this unsealed MP

• With your exported MP, find the enum GUID for the "Retired" value you just created. Save this off/keep it handy

• Next find all of the enum values you're looking to retire, and change their Parent Enum to the recently created Retired Enum.

• Increment the version of the MP and re-import

Round 1 is now complete. Analysts for the most part don't notice this difference and integrations for SCO specific things, templates, etc. continue to work without issue. You let a few weeks go by continually checking in to see who/what is still setting Retired values. I recommend approaching this through a SQL report against the DW, but you could certainly PowerShell this too. All in all, this is part staff training opportunity part double checking you don't have processes calling templates that reference these old values. Everybody wins.

Some time has gone by. You're absolutely clear SCSM/SCO/some processes aren't still leveraging these retired values. The only thing that's left is people are still using them. Assuming you've addressed the needs of new/replacement enums for the ones you're retiring, begin deleting enum values. Here's the potentially tricky part, you're only going to be able to delete values that are not in use in the current live OpsDB. This is where some PowerShell may come into play, find all of the active things in the system and flip their values to something else so you can get on with deleting the enum values. Round 2 is now complete.

With the enum values deleted, they will eventually become retired in their own right within the data warehouse. Reporting against these missing values will require an extra join or two, but you will still be able to grab their plain text display string as the DW has a record of all of these enums. By having a consistent DW you preserve the enum in the long run but still allow yourself to continually alter/improve your OpsDB.

Brad_McKenna

First of all, THANK YOU @Adam_Dzyacky for the feedback and advice...greatly appreciated!

It sounds as though containing all of our data in our OpsDB is truly a 'bad thing' in this instance as we do not have the luxury of removing/deleting enum values without renaming them to a different GUID. Thus forcing us to treat all our 'retired' items as your Round 2 items.

I like your approach with essentially renaming the GUID of the value(s) to Retired instead of the actual value themselves. Allowing ease for users to understand these are not to be used, and aiding in users most likely not using these values.

I do have a follow-up question though for you, for the quote below...my assumption was that by the word active things, you meant any items that fit the criteria that is still in OpsDB. aka. status is not the dimiliter, it is the fact the object is contained in the OpsDB

This is where some PowerShell may come into play, find all of the active things in the system and flip their values to something else so you can get on with deleting the enum values. 

Conner_Wood

Brad_McKenna said:

We are fortunate in the sense that we keep all data in OpsDB.

I don't blame you at all for keeping everything in the Live ServiceManager Database, however you may want to do some much needed preventative maintenance:
SCSM Data Warehouse: Fact Groom Retention - Prevent Relationships Getting Marked As Deleted
SCSM: Perfect the SSAS Cubes

I've found this has kept the DW cube jobs finishing and kept the data accurate for reporting purposes....

Due to SCSM design, it's better to be using business services with generic classifications, so if you have 50+ classifications and not using services, you may want to consider using the following tool to help change that:
SCSM Incident - Service Adder and Reclassification Tools

Adam_Dzyacky

Always glad to help and collaborate @brad_mckenna! By "active things" I'm referring to enums that are in use currently in your OpsDB. For example, if you have a Support Group value that you are looking to delete but even if a single Incident that has that value set - you will be unable to delete this enum until the Incident is purged out or you flip the value to something else.

I mention PowerShell here because it will be easy to discover what those values are and if necessary change them to some other value so you can get on with deleting the enum.