Using SpiraPlan for Application Decommissioning

September 26th, 2022 by inflectra

We recently demonstrated SpiraPlan to a large, multinational life sciences manufacturing company. During the series of demonstrations and proof concepts, we configured SpiraPlan for a set of different use cases, including demand management, application portfolio management, vendor selection and management, change management, application decommissioning, configuration management, and supplier qualification. In this series of articles, we will be highlighting these different use cases and providing best practices and ideas for how to configure SpiraPlan. In this article we will be covering the topic of application decommissioning.

Application Decommissioning Overview

In the Navy, ships are decommissioned when they are getting old, outdated and too costly to operate compared to more modern and effective alternatives. For example, over time all of the World War II era battleships have now been decommissioned and retired from service, replaced with modern cruiser and destroyer ships.

Interestingly, the same idea can be applied to old and outdated legacy applications in an IT department. Costly to operate and no longer used for production processing, such applications chew up budget that could be better used for something else. If we could decommission them like aging battleships, we could cut out a huge chunk of the IT maintenance budget.

The Application Decommission Process

Application Decommissioning is a strategic approach for systematically retiring outdated and costly legacy applications—without compromising business needs or compliance requirements. It does this in two important ways.

First, it uses a rigorous process to analyze the application portfolio and identify the best candidates for decommissioning. This is based on a combination of their value to the business, the savings that can be achieved, and the cost to retire them. In general, the best candidates have valuable data that needs to be retained for a long time—thus offering longer-term cost savings—while not being overly difficult to deal with technically.

Building a Business Case

The business case for Application Decommissioning involves comparing the cost of maintaining the legacy application to the cost of decommissioning it. This allows us to calculate an ROI for the project over a given period of time, and also to see how fast the project costs can get paid back.

Configuring SpiraPlan for Application Decommissioning

This specific use case - application decommissioning - is an extension from the wider case of application portfolio management that we previously discussed. It assumes that you are already managing your portfolio of software applications and systems in such a way that you are able to obtain a clear idea of the value you derive from them in a quantifiable way. For example, lets consider the following application portfolio being managed by SpiraPlan:

In this scenario we are now looking to plan the decommissioning of specific application based on sorting and filtering the portfolio to find candidates. It assumes that we have already performed the portfolio management tasks and are now ready to begin the decommissioning process.

Typically, application decommissioning can be done by a guided process in terms of timeline, order of completion, mandatory and optional steps, standard operating procedures (SOPs), requirements and electronic signatures for any necessary approvals. We will use the SpiraPlan incident management and incident workflow system to handle this process.

Configuring Incident Workflows

The first thing we need to do is create a new SpiraPlan incident type called "Decommissioning Req" and create a new workflow that we'll use to manage the process:

You will also need to add additional incident statuses and steps for this process, including:

Approved
Rejected
Decommissioned

Once you have the additional statuses added, you can now link them into the new decommissioning workflow. This workflow will typically follow these steps:

New > Open
Open > Assigned
Assigned > Approved or Rejected
Approved > Decommissioned
Decommissioned > Closed

You can of course add additional steps if you need more sign offs in the decommissioning process.

Electronic Signatures

For specific workflow transitions (e.g. Assigned > Approved), you may want to require an electronic signature so that the person making the approval realizes that this is a binding decision. It also means you will have a auditable record of the approval that meets regulatory standards.

Electronic signatures require that the user approving the decommissioning request has to re-authenticate to make the approval and enter in the "meaning" for the signature. The change request record is then cryptographically hashed and stored with the change record inside SpiraPlan to avoid any tampering. This is similar to how the blockchain uses cryptographic hashes to authenticate transactions.

Creating a Decommissioning Request

Now that we have setup the incident type, statuses, and workflows, you can now create a new decommissioning request. In this example, we shall pretend that we're decommissioning Excel 2016 in favor of Excel365.

The incident type can have custom properties defined to capture any fields that are specific to a decommissioning request.

In addition, you will link this new decommissioning request to the requirement containing the application being affected using the Associations tab:

Managing Decommissioning Risks

One of the key aspects of application decommissioning is performing a risk assessment for the decommissioning process. SpiraPlan's built-in risk management functionality makes this very easy. You will simply identify the risks associated with each decommissioning request and associate them with the decommissioning request incident artifact:

In this example we are recording the risk that some reports using macros that have been deprecated in Excel365 and only work in the legacy version.

We are able to use the risk management functionality to document the probability and impact of this risk, as well as outline potential mitigations and action items (tasks). These risk are of course linked back to the source request.

Decommissioning Notifications

One key requirement for the decommissioning process is to ensure that timely notifications are sent to stakeholders:

Customizable notifications to stakeholders about the items or applications to be decommissioned need to be sent
Notifications about status changes of decommissioned items or application can be sent (e.g., for cancelling contracts with suppliers, deactivation projects in financial or relations/interfaces to other remaining systems).

Both of these needs can be fulfilled using the incident workflow notifications:

They provide fine-grained control over the steps in the decommissioning process and ensure that all stakeholders receive appropriate information.

Summary

In this article we have seen how we can extend the existing application portfolio management use case to include the specific needs for application decommissioning. We have seen that the built-in incidents functionality lets us create a custom incident type, workflow and associates statuses to track this process. Finally, SpiraPlan's unique features for electronic signatures, risk management and email notifications can be added into the process as needed.