Process of the Month – Software Removal Process

Best practice

Process of the Month – Software Removal Process

28 October 2014

6 minute read

Software removal best practice – software is a company asset and should be lent out on a piece of elastic – pinged back to the company if not in use.

I had some fun deciding on whether to call this a software retirement process, or whether it should be what I settled on (above). However, the decision to Retire software is taken in a different process (Maintain a Supported Software Catalogue), and so it felt more appropriate to refer to this process as I have done.

Clearly software removal is quite pivotal to SAM, and this can be highlighted perhaps by the number of processes that can instigate it (Four is the highest number of processes that has been modelled to kick-start another process). The removal of software provides many benefits, but the three main ones are:

It aids your Help Desk in not having to support every release, version and edition of software your company might have used in the past.
By staying on trend with product releases your company is better placed to avail of the improvements built-in to such products, rather than having your staff work in outmoded ways simply because prior versions don’t have function A, B or C….
Removing software that is no longer of commercial benefit can offer a residual value through re-sale (See ITAM Review: “Recycling Hardware opens the door to recycling software”)

Although I would draw a distinction between removal and recycling at this point, as Recycling implies that the software may be deployed for re-use at a later stage (See the first process in this book).

Software Removal Process

Primary Objective

To execute the removal of “Red” software

Secondary Objective

To advise HR on any training requirements on software replacing those titles that have been removed

Assumptions

: Screenshot A

: Screenshot B

: Screenshot C

Function Step Overview

1.10	Any one of four other processes can cause this process to be initiated: The Software Rationalisation Process which compares software titles by classification/activity The Hardware Disposal Process which although not modelled in this e-book, takes its lead from the next process, Platform Identity Process – which looks to assess whether servers are required or to be disposed of: i.e. if hardware platforms are to be disposed of, then it makes sense to wipe software from them prior to disposal. Maintain a Supported Software Catalogue – this is the primary process which ear-marks software for retirement, as opposed to mere removal. At this point, if multiple processes have coincided on calls for software to be removed, then perhaps a degree of scheduling might be required by the SAM Manager to coordinate these calls.
1.20	At 1.20, the SAM Manager is required to inform stakeholders (including end users) of the impending removal of any red titles. The product champions and service owners should already know, in that they were involved in the decision making processes prior to this function step, but it bodes well to keep them in the loop as most likely end users could see them as a first port of call for information on how the removal might affect them.
1.30	At function step 1.30, the SAM Manager is required to compare the red SSC titles to the Green SSC titles, so that alternative titles to those about to be deleted can be passed on to HR to aid them with any training guidance a company may want to offer.
1.40	At 1.40 the comparison that has taken place in the previous function step is summarised around the training requirements of typical end users and the potential business benefit of conducting such training and/or the consequences of not undertaking training.
1.50	Here we see the Apps Packaging Team come into their own and remove the red titles the SAM Manager has passed to them at 1.20 in accordance with the removal schedule
1.60	Next the Apps Packaging Team conducts an inventory sweep to ensure that all red titles have been removed.
1.70	This step requires The Apps Packaging Team to make that comparison between the red title list and the inventory data they captured at 1.60 – if instances of red titles still appear on the IT estate then the Apps Packaging Team are required to re-visit 1.50 to remove those instances.
1.80	Subject to the successful removal of all instances of those red titles, the Configuration Manager is required to update any build schemas so that they too do not refer to any red titles.
1.90	Finally the Configuration Manager is also required to archive red title Proof of Entitlement, so that it does not get in the way of any audit and reconciliation activity. Best practice would dictate that such material is archived rather than destroyed, but it should be provided with adequate security controls to prevent future re-deployment/misuse.

As highlighted in the previous processes that call on this process, do consider the consequences of removing software in light of the business impact – do those software titles form part of a wider service offering/stack that the business still uses? Could there be some regulatory or legal requirement to offer access to data that has been stored in a format only read by seemingly non-used software? If so, you will have two option here: either retain a live instance of the software for accessing that data; or port/convert the data into a more readable/modern format.