What does Application Rationalization mean?
Everyone is busy with Applications and talks about Application Rationalization. But who 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 necessary software applications concerning primary business processes.
All software applications that have duplicate functions are phased out or switched off. The objective is to simplify the software application landscape and reduce the average application cost. This creates a more vital, adaptive, and scalable application landscape.
Application. The term "Application" in Application Rationalization refers to a software application. Of course, it can be explained as Hardware and Software, but this is uncommon, too.
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 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 easier 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. Suppose you have different software application products built with various technologies from different vendors that do not communicate as they should. In that case, you may consider basing your application landscape on fewer 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 challenges is how to prevent new versions of software applications from being purchased by your company, while you want to phase them out.
Integration. Suppose you have different software applications for the sales department, and one module lacks data or functionality available in other modules. Instead of buying a new module, you can have the applications communicate via an interface, eliminating the need to purchase a whole new application.
Deduplication. Suppose you have five sales applications because your company has a history of mergers. Why not switch to one of those sales applications with an add-on?
Vendor Lock-in. To prevent vendor lock-in, always standardize on open standards and refrain from building software in-house or 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 large number of software applications installed on client computers, which often require new versions and updates, resulting in significant administrative work. You could consider virtualizing all client applications and have them installed (in memory on a server) only when a user logs in to their workplace. You only have to manage a few virtual clients (stacks of applications).
Outsourcing. By outsourcing the applications to a provider, you may successfully transfer the problem of complexity and slow down the speed of change to that provider, effectively outsourcing your problem. Also, you could simplify the complexity by eliminating the problem and then sourcing it. However, remember that outsourcing sometimes ends, and the applications will return to your location.
Services. Why not start thinking about services instead of applications? If someone requests a new service, ensure a service catalog is available to verify if it is a new service or an existing service with 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 IT services and, thus, on 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. You earn time, money, and quality if you can lower your IT budget by 30% because of rationalization.
Further reading
Are you interested in reading more about this?
In Dragon1, there is a Solution for Application Rationalization.
Here we have a wiki page about Application Portfolio Management.
An interesting White Paper on the matter of Application Rationalization [PDF].
Our intention is not to provide a complete dictionary on enterprise architecture here but to provide only the most frequently used words in the field.
If you have a suggestion for us to improve the list or a definition, please get in touch with us via info@dragon1.com.
Blogs on Application Rationalization
Create A Trial Account
Do you want to create Landscapes for Application Rationalization yourself?
Create your Trial Account today.