Are you supporting obsolete Applications?
When a new application is implemented, what happens to the application that was replaced? The obvious answer should be … the obsolete application is retired. Unfortunately, it is quite common for IT organizations to keep both the old and new applications operational. In some cases, even the replacement system has been replaced so there are three systems with redundant capabilities.
Why does this occur? Here is a list of some of the most common reasons why systems are not retired:
- The old system is kept operational as a temporary contingency in case there are problems but there is no plan for retiring the application
- Application is kept operational to access historical data where data retention is mandatory because historical data was not migrated
- There is no ownership assigned for retiring the application
- Business users continue to use the old application as long as it is available because they have a greater comfort level with the old system.
- There is no business owner who is accountable for the costs and the existence of redundant applications.
- Lack of business priority
- Lack of an accurate Application Inventory
- Lack of process for retiring applications
What would be the expected benefits if businesses rationalized their applications and authorized the retirement of obsolete applications?
- Reduce support and operations costs
- Reduce duplication of data and functions and the resulting need for reconciliation
- Eliminate the risk from operating and supporting obsolete technology
Retiring an application is not a trivial endeavor. The following items must be addressed:
- Who is using the obsolete application and why?
- Do the business users have access to an alternate capability and do they know how to use it?
- What is the best time to retire the application (e.g. Year End) to minimize disruption?
- What will happen to the historical data?
- Should the application be de-commissioned and removed from production or be rendered inaccessible?
- What will happen to the supporting infrastructure?
The other factor that will make it easier to retire applications is to assign ownership to the team who is implementing the replacement application. This will provide incentive for the implementation team to make decisions that facilitate instead of inhibiting application retirement.
Hi Nick,
This is an excellent post and very true in many organizations due to the risks associated with the big bang approach of replacing business applications. This leads us to the questions of whether enterprise application portfolio rationalization is a one time exercise or is it something that needs to be a living and continuous process everytime an application is considered necessary to be built for business to operate or evolve.
I personally would suggest to any organization that is interested in keeping the operating costs congruent to real necessities, to maintain multiple matrices that map business capabilities to various applications to the various stake holders to the business user groups. This kind of cross dependency references could very easily be misconstrued to be process heavy and so not agile. But seeding such an activity and keeping it alive by efficiently allocating and aligning Enterprise Architecture group and Business Architecture group to the various lines of businesses would render itself to a very agile ongoing evolution and innovation. It will hold the stake holders responsible for truly phasing out the applications that are being replaced by a modernized application (which would become a legacy application itself over 10+ years of its existence).
best regards,
Dheeraj
Dheeraj, I agree. Application Rationalization should occur at a minimum of once per year. Secondly, any application in production can be considered a “lagacy” application. All applications should be rationalized regardless of their age to make sure they still support business objectives. Thanks for your comment.
An other reason of not retiring old apps can be the complexity level and the significant overall cost of decommissining, when for instance the app to be retired involves links with many other apps … this multiplies the number of stakeholders, who do not necessarily are of the same governance committees, and may have orientations not well aligned !
A tip to help in decommissioning : not cross the opportunity milestone of a build project without having the steerco validate explicitly the old apps to be replaced and then decommisionned, and not cross the end of project milestone without having checked the old apps previously defined have been effectively decommissioned ! or you’ll find always some users having (good) reasons the keep the old ones … Decommissioning old apps is nothing but a military operation !
Philippe, I agree with your comments. Complexity and lack of understanding of the older applications is an impediment to retiring the applications. Ironically, the complexity and lack of understanding are the very reason why these applications should be retired. I also like your point about treating it as a military operation. It is less complex to retire an old application than it is to build a new one. A big part of the problem is a lack of priority.