Application portfolio rationalization

In large enterprises over the period applications are built in silos as each department is large enough as company size. Also, there are chances that these departments may not be collaborating on IT

The rationalization of application is one of the important activities of large enterprises. It involves careful consideration of applications review with relevant stakeholders. It must be carried out on a periodic basis to fully reap its benefits as possible.

Why do we need rationalization of application portfolio?

Typically, in large enterprises over the period applications are built in silos as each department is large enough as company size. Also, there are chances that these departments may not be collaborating on IT matters regularly or might be having department specific IT functions. So, over the period this would lead to -

· Duplication of solutions for the very similar purpose

· Duplicate of data and associated cost and its maintenance

· Also, there might be unused applications, or newer solutions are built / purchased, so old solutions are no longer relevant and are being used by active user communities

So, it does make sense to review those applications which are no longer useful, thus leading to reduced cost of application maintenance.

What are the steps?

Once we receive the application list from each department, prepare a high-level catalogue that will contain details like application purpose, owner, active user base, its geographical spread, average annual cost etc. In my experience, the following are typical steps to be followed as part of the rationalization process:

1. Check for the application usage from users – by going through application monitoring tools / logs

2. Logically group the applications for similar purposes

3. Categorize the applications as Custom/COTS solutions

4. Also, label them as Cloud, On-premises etc.

5. Mark the applications which have not been in use for more than 6 months

6. Also, review and propose revised solutions to merge similar solutions with extensive consultations from application owners

7. Come up the implementation plan for revised solutions and budget / timelines

8. Also, define decommission strategy for the applications which are marked for sunset

9. In my experience, there are couple of approaches for decommissioning

a. Make application read-only.

b. Or else, shutdown application and backup the DB with restoration steps. Any data reference request from application owners in future, we should be able to query the DB for relevant information. But it does not contain application interfaces.

10. It is important that, IT team should get a approval sign-of from business teams for decommissioning or merger of the solutions

11. Get implementation plan approved to kick start the rationalization process

Implementation strategy

Usually, more effort would be required for the merger of similar solutions. If we are working on COTS / vs Custom solution merger, perform the cost-benefit analysis and take a call. Always it is better to go ahead with COTS with standard features. But at times, custom solutions are built over time, and users are reluctant to accept COTS solutions with few gaps / limitations around features. This is challenge, the IT team must navigate and make all the stakeholders understand the plan / baseline the decisions. The decommissioning would be straightforward, choose either of the approach as I mentioned above and act accordingly.

Conclusion

The periodic rationalization exercise would bring TCO down and each application owner would be made accountable for its ROI. In the long run, the application portfolio would look tidy and many redundant apps are removed and maintenance costs shall be better utilized for strategic goals.