When it comes to application transformation legacy is a relative term. What we associate with the term "current" today is likely to become "legacy" tomorrow. Thus, there is always a need for transformation that entails the introduction of newer applications and the retirement of existing applications. The need to retire applications is one of the constants over time.
So, how do you know the time has come for an application to be retired? Here are 5 tips to help you decide if/when the time is right to get rid of an obsolete app:
Listen to your users. Enterprises need to constantly feel the pulse of its external and internal user communities. Users communicate with the enterprise in multiple ways about their experience with an application that is a likely candidate for retirement. Some do so proactively by venting their frustration with their overall experience with the application. Others do so in a more subtle manner by changing their level of interaction with the application, ultimately switching over to alternative choices.
Align to the business. Enterprises continually need to refine their overall business strategy. New business domains could introduce new business problems requiring new solutions and newer applications. A cloud computing environment needs to have increased focus on managing the As-a-service providers. What used to be a product a few years back is a service today. Therefore, applications that focused on the management of tools and products may qualify to be replaced by applications focused on the management of service providers.
Watch the tech space. Necessity is the mother of invention. Paradigm shifting technologies introduce new areas of research that begets newer technologies. Internet came first followed by YouTube. Remember VCRs? Unbeknownst to the application stakeholders, the technology continues to evolve. Try explaining an audio cassette player to a 10-year old. Technological advances also result in a shift in the demand for human resources in a given domain, which triggers a dramatic change in the available skill sets in the industry. As the enabling technology becomes obsolete, so does the related expertise for the applications enabled by these technologies. Insufficient subject matter expertise is a common trigger for retiring an application.
View the Enterprise. Some signs are not within the context of an application or its underlying technology. They surface at a broader enterprise level. Multiple organizational units land up enabling similar functionality through their own departmental applications. Why should enterprise wide functions like HR, Billing, Supplier Management, IT Services, etc. be implemented through multiple departmental applications? A single enterprise wide instance will do with multiple configurations for various organizational units. So, what happens to the departmental applications? You guessed it. They are retired.
Focus on one Application. Even after standardizing across organizational units within an enterprise, external triggers require us to continually take stock of the enabling set of applications. Mergers and Acquisitions is one such trigger. These result in the sudden emergence of two or more applications that served the same purpose in their respective enterprises. In the new merged enterprise, when there are two, typically one would suffice. The other is a candidate for retirement.
Once applications are identified as candidates for retirement, the process of decommissioning them must be initiated at the right time. But, that is best saved for another post.
If you haven’t yet started the process to retire your duplicate and obsolete applications, check out the HP Application Transformation and Application Rationalization information for additional tips on how to get started. And remember, application portfolio management is not only a journey or destination, it’s an ongoing way of doing business.