Application Portfolio Rationalization – Prioritize don’t Architect!
by Peter Classon, Posted on August 25th, 2009A common misconception is that application rationalization and optimization will somehow unlock the mysteries of your future IT architecture. Many believe that by analyzing the patterns in your technical architecture, assessing your teams’ skill-sets, and reading the tea leaves of future technology trends you can boldly stand up and say “we will be an SOA shop standardized on Oracle databases, JAVA applications, and portals as our front-end user interfaces”. While I will agree that someone in the enterprise DOES need to plot the future technical architecture of your enterprise, it is NOT the objective of application portfolio management. Put simply, application portfolio management (and the sub-disciplines of continuous rationalization and optimization) is about one thing: Prioritization.
If you go to a surgeon with a bad knee, most likely he will want to operate. If you put architects and application owners in charge of application rationalization/optimization, they will want to “architect”. It is difficult for technologist accustomed to designing and developing applications to resist the urge to build the ultimate technical platform rather than focusing on what needs to be done, why, and in what order. Furthermore, it is important to keep Andy Kyte’s (Gartner Fellow) 1st principle of application rationalization in mind: “Today your organization has exactly the right number of application to run the business the way it runs today.” Taking this to the next logical step, one can see that any application rationalization will have immediate business impacts. Therefore, it is futile for IT to act alone in application rationalization. If you want to spend a lot of time making pretty quadrants, ranking applications, determining future fit to the organization with zero tangible outcomes, by all means run your application rationalization without business involvement.
Since you would rather not waste your time polishing your PPT skills, get business involvement early and identify key individuals that will actually commit to your application rationalization (not just “steering” committee roles but actual hands-on work). Focus your efforts and data gathering on three areas:
1. Financial Data – get as much detailed cost information you can about the applications in your portfolio. Ideally you want to get TCO for every application. Short of TCO data, you need data that can be “defended” if challenged. Plot your cost data over a defined time horizon to show a trend. Most importantly, the future cost graph will help you determine the cost of inactivity (i.e., if we did nothing with X application, it would cost us Y).
2. Application Utilization Data – identify meaningful metrics for each of your applications that can easily be extracted (e.g., for a purchasing application, measure purchase orders). Then, plot these metrics over time to reveal applications with increasing/decreasing usage.
3. Risk Data – analyze the risk of an application using a bottom-up approach. Begin with the technical stack (hardware, operating system, database, etc.). Asses the likelihood of a failure and the impact of a failure. Also consider your staff’s skill-sets and their ability to rapidly address an application outage.
Once you have gathered the data (probably 2/3 of the effort in an application rationalization effort), you are ready to perform the analysis and make prioritization recommendations. It is helpful to classify applications based on disposition statuses such as maintain, reengineer, replace, or retire. A key point here is to define disposition statuses that make sense for your organization (don’t use technical jargon – use plain English!). For example, an application that should be “maintained” will most likely still require technical upgrades and service pack application. However, in some organizations that may be considered “running the business” while others may call that “reengineer” since a maintain application should be completely left alone.
At the end of all this, your goal is to have a prioritized set of application related activities that will lower costs, reduce complexities in your application portfolio, increase customer satisfaction, and align with the direction of your business strategy. If done in lock-step with your business counterparts, none of this should come as a surprise and the business will be willing to make the necessary operational/procedural changes to support the application rationalization recommendations.
Let me know your thoughts and experiences with application rationalization. There is clearly a mix of “art and science” and I’m always interested in hearing what the “artistes” out there are working on!
