Harris KhanApplication rationalization is the radical reshuffling of an application portfolio as part of an application strategy, a plan that implements changes to applications to achieve a business outcome. It’s a combination of things:
- Application feasibility
- Technical risks
- Defining application boundaries
- Business benefits
An application portfolio is used to select a list of applications to be considered for rationalization. The application portfolio is broken up into two parts: applications that are suitable for rationalization and applications that are not to be considered for rationalization. The rationale for rationalization is to consolidate and reduce the number of applications in the portfolio and improve business value and performance. Rationalization processes can produce a positive flow on effect on a company’s application portfolio. Applications that have low business value can be removed from the portfolio, allowing extra resources to be allocated to other applications.
Rationalization is performed to achieve business benefits, and applications that address business needs with limited technical risk can be selected for rationalization. Applications that have low business value and highly risky technical factors are excluded from the rationalization process. An application rationalization strategy will be centered on the most strategic applications in a company’s enterprise. An example would be human resources. Reducing business value in this area would notably impact a company’s ability to employ and retain staff.
Numerous applications may be subject to rationalization, and a rationalization strategy should first involve defining the boundaries of each application. An application can be represented by a fixed set of functionality. If a company owns two different applications that address the same set of functions then they can be ‘cojoined’. The rationalization strategy should provide for the simplification of application boundaries.
Application rationalization should be carefully assessed for cost, time, and functionality. It will directly address the business needs of a company, and the business and technical risk factors should be assessed in the process. Business factors need to be defined, and achieving business processes through one application is preferred. A company can identify areas where rationalization can provide cost savings for other applications. For example, if human resources existing applications for payroll, time and wage management, sick leave management, and annual leave management are all merged into one, then there will be significant cost savings to apply in other areas of human resources.
Rationalization of applications is a very important process. I think that the missing part in CIO’s repertoire for application based areas are risk analysis and the full analysis of the application portfolio in the organisation to try and rationalize as many applications as possible. Application rationalization is a cost and time saver and above all, it’s disruptive and ‘risky’ to your organisation. But this is where the CIO really earns his or her creds… because they got their hands dirty. They face the wrath of the CEO, and they do it for all the right reasons.
App based areas are ignored by most CEOs until the problem is typically too big to ignore. This can grow into a huge problem, potentially crippling the organisation. This is because systems are normally pushed to their limits from day 1 without the knowledge of the real requirements.
Application rationalization is a very hard skill to teach. But what makes things harder is that human resources is typically a very disparate and decentralised area of operations. It requires a lot of time and effort to optimize the consolidated portfolio and even more time and effort to rationalize inefficient or redundant applications.
For the CIO, I think it’s something that needs to be done in the interest of the company, the employees, and the shareholders.
It’s worth investing time and effort now to avoid future problems.
