What is Application Rationalization?
Application rationalization is an organizational process that reviews an organization’s application portfolio and identifies applications that should be replaced, redesigned, consolidated, migrated, or retired. Organizations often undertake this process to deal with application sprawl—the use of hundreds or thousands of software solutions, which are not well understood or controlled by the IT organization.
The goal of application rationalization is to streamline an software inventory, aiming to reduce complexity, inefficiencies, risk to information assets, and total cost of ownership (TCO). It often forms part of a wider digital transformation strategy involving modernization goals such as more widespread automation and a move to the cloud.
The key benefits of application rationalization include:
- Reducing IT costs: By eliminating or consolidating redundant applications, companies can save on licensing fees, maintenance costs, support costs, and infrastructure expenses. Application rationalization can also help in avoiding unnecessary upgrades or purchases.
- Minimize IT waste: Often, organizations end up spending on applications that are rarely used or do not add much value to the business. Application rationalization can help identify such applications and eliminate them, thereby preventing wastage of resources.
- Reduce complexity: Application rationalization can significantly reduce complexity within the IT environment. With fewer applications to manage, the IT department can focus more on strategic initiatives rather than getting bogged down with the day-to-day management of numerous applications.
- Improved security: With fewer applications to secure, the IT department can concentrate its security efforts more effectively, thereby reducing the risk of security breaches. Also, older or unmanaged applications typically carry more security risk.
- Improved organization efficiency: Identifying and eliminating redundant applications can improve the efficiency of business processes by reducing confusion, tightening business processes, and improving data consistency. It also simplifies the user experience, as employees no longer have to learn and use a large number of applications, some of which may be overlapping or unnecessary.
4 Key Drivers for Application Rationalization
Here are the primary reasons organizations undertake application rationalization:
1. Cloud Migration
As organizations move their IT operations to the cloud, they often find that they have a large number of applications that are either redundant or not suited for a cloud environment. In such cases, application rationalization can help identify which applications to migrate, which to retire, and which to replace with cloud-native alternatives.
Moreover, application rationalization can optimize cloud migration. By eliminating unnecessary applications before migration, organizations can reduce the cost and complexity of the migration process. Also, by ensuring that the migrated applications align with business objectives, they can maximize the strategic value derived from the cloud.
2. Mergers and Acquisitions
Mergers and acquisitions (M&As) often result in a considerable increase in the size and complexity of an organization’s IT portfolio. With the integration of systems and applications from different companies, there is a high chance of redundancy and inconsistency. Application rationalization can help reduce this complexity and streamline the combined portfolio.
In the context of M&As, application rationalization can provide a systematic framework for assessing the value and fit of each application in the new combined portfolio. This can help decision-makers identify which applications to keep, which to integrate, and which to retire. The result is a more efficient IT landscape that supports the goals of the merged organization.
3. Business Consolidation and Cost Optimization
As organizations seek to streamline their operations and reduce costs, they often find that their IT portfolios contain a lot of unnecessary complexity and redundancy. By rationalizing their applications, they can eliminate this waste and optimize their IT spending.
Moreover, application rationalization can help organizations align their IT investments with their strategic goals. By ensuring that each application in the portfolio delivers tangible value and supports the business objectives, organizations can optimize the return on their IT investments. This can lead to significant cost savings, improved operational efficiency, and better strategic alignment.
4. Shadow IT and Siloed Purchasing
Shadow IT and siloed purchasing are pervasive issues in many organizations. These practices often result in a proliferation of unmanaged and uncoordinated applications, leading to increased IT complexity, security risks, and operational inefficiencies. Application rationalization can help address these issues by providing a systematic approach to identify, assess, and manage all applications within the IT portfolio.
By bringing shadow IT into the light and breaking down siloed purchasing practices, application rationalization can help organizations regain control over their IT landscapes. This can lead to improved IT governance, reduced risk, and greater operational efficiency. Moreover, by ensuring that all applications align with business objectives, application rationalization can help organizations maximize the value derived from their IT investments.
What Are the Challenges of Application Rationalization?
While the benefits of application rationalization are clear, the process is not without its challenges:
Lack of Engagement
One of the biggest challenges is a lack of engagement from key stakeholders. This can occur when those who are most affected by the changes—such as employees who use the applications on a daily basis—are not involved in the decision-making process. When people feel that they are not being heard or that their needs are not being taken into account, they are less likely to support the changes. This can lead to resistance, which can slow down or even halt the rationalization process.
Ensuring that all relevant stakeholders are engaged and involved in the process from the beginning can help to overcome this challenge. This means not just top-level executives, but also middle management and frontline employees. Everyone who has a stake in the outcome should have a voice in the process.
Bloated Application Portfolios
Many organizations have far more applications than they actually need. This can result from a variety of factors, such as acquisitions of other companies (and their applications), departmental purchases of applications without central oversight, or simply a lack of regular review and cleanup of the application portfolio.
The result is a large number of applications, many of which may be redundant, outdated, or underused. This not only increases IT costs, but also makes the application environment more complex and difficult to manage. Rationalizing this bloated portfolio can be a daunting task, but can also provide substantial benefits.
Inefficient Use of Platforms
Just as organizations can end up with too many applications, they can also end up with too many platforms—the underlying systems on which the applications run. This can happen when different departments or business units choose different platforms for their applications, or when new platforms are introduced without retiring the old ones.
This redundancy can create a number of issues, such as increased cost and complexity, as well as potential compatibility issues between different platforms. As with applications, rationalizing platforms involves reviewing them to determine which ones are necessary and which ones can be retired or consolidated.
Under-Utilized Applications
Under-utilized applications are those that are being used, but not to their full potential. This could be because the users are not fully trained on how to use the application, or because the application is not fully integrated with other systems and processes.
Under-utilized applications represent a wasted investment, as the organization is not getting the full value from the application. Identifying and addressing under-utilization is complex, because it requires an in-depth look at application usage and business context, but should be a key part of the rationalization process.
Application Rationalization Roadmap
1. Present the Case for Application Rationalization
Start by getting stakeholders on board by presenting the business case for application rationalization, explaining the value it would bring to the organization.
In addition, prepare and present a simple roadmap, outlining the basics of the rationalization process in terms that are important to senior managers. At this stage, this needs only to include rudimentary information, such as a baseline inventory of applications, which is sufficient to show the IT team has done its homework and has a clear vision of how the project will evolve and deliver ROI.
2. Draw Up an Application Inventory
Next, build up a more detailed picture of the inventory by mapping all applications and their dependencies. In medium and large companies, this is typically done with application dependency mapping (ADM) tools.
ADM tools capture information about application ecosystems across the business and present it in a way that’s easy to understand, providing both a visual representation and downloadable spreadsheet.
These solutions help determine the:
- applications an organization uses
- different dependencies that each application relies upon
The latter will be important in determining the level and complexity of the work that may be involved in the rationalization process—where the larger the ecosystem, the more substantial the project tends to be.
Learn more about Faddom’s Application Dependency Mapping solution
3. Build Up More Detailed Application Knowledge
The next step is to enrich the information gathered from the dependency mapping exercise.
The best way to do this is to send out a questionnaire about each application. This approach ensures that respondents are asked the right questions.
Such a questionnaire would typically ask the following:
- What is the application being used for?
- How easy is it to use?
- Does it provide the functionality users need?
- What information does it store and process?
- Is the application in active usage?
- If so then how often?
- How long has it been in use?
- Is it still eligible for third-party support?
- What are the running costs?
- What value does it bring to the business?
- What technologies does it use?
- What are the licensing details?
- What resources are required to support the application?
- Is it being used properly or to its full potential?
- Are there any known issues?
- Are there any ongoing changes to or planned redevelopments of the application?
- Would users benefit from more automation or integration?
The responses to the questionnaire should be supplemented by other information, such as records of change requests, fault reports, and software updates, as these serve as a guide to the level of maintenance an application requires.
And if the organization has a dedicated IT documentation system then be sure to put it to good use.
4. Review and Analyze Captured Information
The next stage is to compile and analyze all the data gathered so far.
Start by cross-checking the information provided in the questionnaire against any corresponding information collected through the dependency mapping exercise. If there are any discrepancies then investigate further.
Then compare details about different applications with the view to drawing up a provisional shortlist of earmarked applications.
For example:
- Are there any applications that are duplicated elsewhere or perform similar roles?
- Which applications put most demand on technical and customer support?
- Which are the most expensive to run?
- Are some applications less reliable and resilient than others?
- Which applications have a cloud-friendly architecture?
- Where does the customer experience fall short?
Where the review team hasn’t yet done so, it will make sense to talk to development and operations staff in order to gather more technical knowledge about any applications of interest. This should seek to find out:
- the scalability and adaptability of an application
- whether it uses physical or virtualized infrastructure
- information about APIs
- whether it is stateful or stateless
- what application telemetry is available
- security measures in place
- conversion rates of websites
- more about the application architecture
It also pays to get an idea of what technical knowledge is still available to support legacy applications, as it would make sense to rationalize these systems before in-house expertise runs dry.
The review stage is also the opportunity to fine-tune TCO calculations and update senior management accordingly.
5. Set Rationalization Goals
Now draw up a prioritized list of applications that are suitable for rationalization.
One way to go about this is to develop a loosely defined scoring system, taking into account a range of factors based on technical and business considerations. This doesn’t have to be a definitive guide to application selection, but more of a reference point for setting priorities.
The scoring system for each application should include factors such as:
- current application usage and expected usage after rationalization
- projected timescales
- technical complexity of the work
- the amount of potential disruption involved
- the impact of work on other systems
- potential implications for backup, failover, and recovery systems
- TCO and value for money
Give priority to the low-hanging fruit. In other words, quick wins that make a big impact with a relatively low amount of effort.
For example, stateless applications, systems with relatively few dependencies, and those already based on a microservice architecture should be high on the list for cloud migration, as they’re already well suited to cloud deployment.
6. Identify Rationalization Trajectory (Migration Strategy)
As part of the prioritization process, decisions need to be made about the most appropriate course of action for each application. The following rationalization trajectories are the most common options to consider:
- Retain: Leave the application exactly as it is—without any modification to the codebase or migration to a new environment. However, that doesn’t necessarily mean preserving the status quo, as rationalization presents the opportunity to explore new ways of using an application to exploit its full potential.
- Lift and shift: Rehost the application in a new environment with minimum adaptation.
- Refactor: Fully adapt the application to a different type of infrastructure and migrate it to its new environment.
- Replatform: Make modest changes to the application so it can take advantage of key features of the cloud, such as scaling and automation. In other words, a halfway house between refactor and lift and shift that optimizes the application for its new environment—without the commitment to full-scale redevelopment work.
- Rearchitect or replace: Completely rearchitect and rewrite the application or replace it with alternative third-party software.
- Retire or consolidate: Retire the application from service altogether or switch to a system that performs much the same role elsewhere in the application portfolio.
7. Identify Requirements
It’s also important to identify and document the requirements for each application before technical work commences. In many cases, these will concern the functionality of the application. But there are many other requirements to consider, such as:
- compliance with regulations, standards, and licensing requirements
- data security
- performance expectations
- infrastructure and resource requirements
- integration with other systems
- migration preparations
- business continuity and disaster recovery (BCDR)
- monitoring tools
- manpower and staff training
- budgetary requirements
Draw up a plan accordingly, providing a clear roadmap of where the organization is now and where it wants to be.
And if the scope of a project allows it then consider whether an application might benefit from a whole new approach or rethink to its fundamental design.
8. Execute the Plan
Now finally get down to business and start putting the rationalization plans into action.
Assemble an application rationalization team to manage and perform the work then proceed to:
- writing or making changes to code
- implementing security guidelines
- integrating CI/CD pipelines
- logging and monitoring application event data
- testing systems
- retraining users
- creating a revised runbook for day-to-day operations
- scheduling the switchover and planning any necessary downtime
Throughout the process, regularly monitor progress, keeping tabs on cost and projected ROI—both before and after the changes go live.
Application Discovery and Analysis with Faddom
Application rationalization simplifies the IT landscape, helping organizations to reduce complexity, cut costs and take advantage of the latest technologies and industry practices.
But it will be destined to fail without the support of senior management and a roadmap to ensure the application portfolio aligns with strategic objectives.
It is an iterative process, requiring regular progress reviews and continual engagement with stakeholders. It calls for tooling to make tasks as efficient as possible. And it also necessitates an ongoing commitment to efficient application portfolio management—in order to prevent application bloat building up again in the future.
Doing application rationalization first requires a simple, agentless tool that delivers comprehensive, agile, fast, and simple application mapping of your organization’s entire hybrid IT infrastructure in just 60 minutes. To try a free trial of Faddom, just sign up to the right!
