Application Rationalization Definition

What does Application Rationalization mean?

Everyone is busy with Applications and talks about Application Rationalization. But who actually performs IT? What is the definition of Application Rationalization and what are the different strategies for it? Read on if you are interested!

Application Rationalization is an organization's strategic process of coming to the lean set of the most vital and necessary software applications with respect to primary business processes.

All software applications that have duplicate functions are as possible phased-out or switched off. The objective is to lower the complexity of the software application landscape and to average application cost. This creates are more vital, adaptive and scalable application landscape.

Application. The word Application in Application Rationalization refers to the software application. Of course, it can be explained as Hardware and Software, but this is uncommon to do.

Application Rationalization means this: Coming from 3000 software applications (including excel sheets used as financial applications), on 300 software platforms, with 30 software technologies from 30 software vendors, to 2000 software applications (with no excel sheet used as financial application anymore), on 100 software platforms, with 10 software technologies from 5 software vendors.

Benefits of Application Rationalization

Application Rationalization is a topic that wanders around in every organization. If it is done correctly it has mainly two benefits:

1) Decrease Complexity - The application landscape becomes less complex, thus becoming more flexible and more easy to increase, ensuring business continuity.

2) Lower Costs - The application landscape becomes less costly, thus leaving room for more application renewal and other IT projects.

How to cash the benefits of Application Rationalization?

The road to Application Rationalization reduction of costs and complexity is one of standardization, migration, integration and deduplication.

Standardization. If you have different software applications products built in different technologies, from different vendors and they communicate not as they should, one could consider basing your application landscape on fewer different technologies, products and vendors.

Migration. Changing an application platform from one to the other is not done overnight. You have to plan it: a migration scenario. One of the hard parts is how to prevent new versions of software applications from being purchased by your company whilst you want to phase them out.

Integration. Suppose you have different software applications for the sales department and one module does not have data or functionality that is available in other modules, maybe instead of buying a new module, you can have the applications communicate via an interface, so you do not have to buy a whole new application.

Deduplication. Suppose you have five sales applications because you have a past of mergers in your company, why not switch over to one of those sales applications with some add-on?

Vendor Lock-in. If you want to prevent a vendor lock-in always standardize open standards and do not build software yourself or together with vendors!

Application Rationalization Strategies

Cloud. Maybe you have a lot of applications and computing power that you hardly use. By putting all the applications into the cloud and making them accessible, location and time-independent, you may be able to deduplicate applications and only pay for the computing time and resources you use.

Virtualization. Suppose you have a lot of software installed on the client computers, and that software comes with new versions and updates very often, causing a lot of work for administrators. You could consider virtualizing all the client applications and have them only installed (in memory on a server) when a user logs in to his workplace. Now you only have to manage a few virtual clients (stacks of applications).

Outsourcing. By outsourcing the applications to a provider you might successfully move the problem of complexity slowing down the speed of change to that provider (outsourcing your problem). Or you could first lower the complexity (getting rid of the problem) and then source it out. But remember: outsourcing always ends sometimes and then the applications will come back to your place.

Services. Why not start thinking about services instead of applications? If some want to have a new service, be sure there is a service catalog available to check if a new service is requested or it is an existing service with only a new name.

Misunderstandings about Application Rationalization

1. Application Rationalization is not of significant impact. No. It has a big positive impact on the continuity of the IT services and thus on the business continuity.

2. Application Rationalization is hard to do. No. You should already have for management & financial sake a correct list of business processes with the supporting software applications and their aspects in your organizations. With that list, you can start to rationalize.

3. Application Rationalization is expensive. No. If you can lower your IT budget by 30% because of rationalization, you are earning time, money and quality.