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 a definition of Application Rationalization and what are different strategies on 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 build 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. To change an application platform from one into the other is not done overnight. You have to plan it: a migration scenario. One of the hard parts is how to prevent that new versions of software applications are 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. With 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 sometime and then the applications will come back to your place.

Services. Why not start thinking in 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.

Further reading

Are you interested in reading more about this?

Here we have a page about Application Portfolio Management.

An interesting white paper on the matter of Application Rationalization.

In Dragon1 there is an Solution for Application Rationalization.

Our intention is not to provide a complete dictionary on enterprise architecture here, but to provide only the most frequent used words in the field.

If you have a suggestion for us to improve the list or a definition, please contact us via

Blogs on Application Rationalization

Related Terms

Create A Trial Account

Do you want to create Landscapes for Application Rationalization yourself?

Create your Trial Account today.