IT organisations are stuck between a rock and a hard place. The “rock” is the bloated application portfolio – large, complex, expensive applications that have an insatiable appetite for money and are difficult and expensive to adapt to changing business needs. The “hard place” is the escalating demand for application capability – more features, more functionality, more integration, more mobility, more analytics, more everything.

Faced with these twin challenges, IT management teams must slim down the bloated application portfolio, removing low-value duplications and embracing cloud-based delivery models to replace aging and expensive on-premises solutions. Modern solutions and architectures are out there, but grasping them and their manifest advantages will involve a “bonfire of the legacy” campaign to sweep away the old and expensive, and free up resources that can focus on innovation and modern, efficient delivery models. That bonfire will create significant demand for application decommissioning work that will require dedicated policies, procedures and services.

Gartner expects that between 2016 and 2020, IT departments will decommission more than three times the number of applications they have decommissioned since 2000.

Unfortunately, too often the ‘replacement’ project successfully implements the new application but fails to eliminate the old one.

The traditional approach to decommissioning, where the project delivering the replacement application is also responsible for decommissioning the old application, has rarely been effective, because project focus and resources have always been overwhelmingly biased toward the replacement system. CIOs and application leaders need to rethink the process of decommissioning applications.

Enter the ‘Application Undertaker’

Decommissioning an application generally involves two distinct activities:

1. Implementing a new application or service to replace the functionality of the old one; and
2. Removing all traces of the old application while implementing access mechanism for any data that must be retained for regulatory or legal purposes

This traditional approach occasionally works well, but a more common outcome sees the new application go live while the old one remans in use. Often, the cost and complexity of implementing the new application is underestimated, leading to a reduction in functionality to attempt to cut costs and delivery time, and so the old application cannot be decommissioned, since it has to be retained to fill the gaps.

There are, of course, many variants of this scenario. Since the traditional approach doesn’t work, CIOs must consider alternative models.

Before an application can be properly decommissioned, it needs to have no live use. It should be, for all intents and purposes, “dead”. The project manager who is responsible for eliminating the need for an application by implementing an effective alternative is the ‘Application Assassin’. The assassin’s job is to kill all need for the application to be used for live data processing purposes.

Is it dead yet?

There are three primary patterns for application decommissioning:

• A single application is replaced by another application. In this situation, the application assassin can hand over the application for decommissioning on completion of the live process migration.
• A single application is replaced by many applications. In this situation, there may be many different assassins, but it is only on completion of the final process migration that the application can be handed over for decommissioning.
• Many applications are replaced by one or more applications implemented together. In this situation, there will be a number of handovers to the decommissioning process as each of the old applications achieves full redundancy.

After the application is dead, there may still be some activities that need to be undertaken to ensure that the last traces of the application are removed from the estate and that the historic data finds a home that ensures compliance with regulatory requirements. This is the role of the application undertaker.

The application undertaker is not expected to run all of the decommissioning projects. Rather, the undertaker’s responsibility is to define the policies, procedures and services that relate to decommissioning activities, and then to provide advice, guidance and audit services to the people who are actually running the decommissioning activities. These policies, procedures and services can then be used by any project manager who is assigned the task of decommissioning a specific application.

By separating the role of application undertaker from the role of application assassin, CIOs can focus their attention, and measure and manage application decommissioning activities using appropriate metrics, rather than trying to manage several major application replacement projects with the hope that decommissioning might happen.

ABOUT ANDY KYTE//

Andy Kyte is vice president and Gartner Fellow in Gartner’s application strategy research group. He helps organisations manage large, complex application portfolios. Andy is presenting a keynote on why IT leaders should “Stop Aiming for Successful Projects and Start Aiming for Successful Applications” at the Gartner Application Architecture, Development and Integration Summit in Sydney, 25-26 July.