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:
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).
|1.10||Any one of four other processes can cause this process to be initiated:
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.
The process kit by Rory Canavan is available from SAMcharter.com