The rapid pace of technological change is continually driving organizations to expand their application portfolios—with new and more advanced solutions to help streamline workflows, improve customer service, increase business agility and bolster data security.
Not only that, but other factors, such as business growth, expansion into new markets, and mergers and acquisitions, also increase the size of their application inventories.
But this comes with the burden of managing sprawling application portfolios, which can potentially run into hundreds of different software solutions. This ramps up complexity, introduces cost inefficiencies and holds back innovation.
The only way to address the problem is to reduce unnecessary bloat through application rationalization.
However, an application rationalization initiative will be doomed to failure without careful planning and preparation to ensure it delivers return on investment (ROI) and aligns to the company’s wider objectives.
This post helps organizations avoid the pitfalls of application rationalization by discussing the challenges of such an undertaking and providing a step-by-step roadmap to success.
What is Application Rationalization?
Application rationalization is a strategic business endeavor that sets out to streamline the software inventory with the view to reducing complexity, inefficiencies, risk to information assets, and total cost of ownership (TCO).
This is achieved by identifying applications that are a good fit for replacement, redesign, consolidation, migration, or retirement.
It often forms part of a wider digital transformation strategy involving modernization goals such as more widespread automation and a move to the cloud.
What Are the Benefits?
In addition to reducing complexity, application rationalization can help to pay back technical debt, standardize technology across the organization, improve security and reliability and break down information silos.
In terms of cost efficiencies, it presents the opportunity to reduce wastage through measures such as:
- data storage optimization
- retiring applications that see only minimal use or provide little value
- eliminating duplication and other redundancies that bump up maintenance, licensing, and support costs
It’s also the ideal opportunity to optimize application functionality and performance. This, in turn, can help an organization improve its service-level agreements (SLAs) and customer service accordingly.
And, finally, as part of the modernization process, application rationalization can help towards reducing reliance on legacy technologies that often hold an organization back.
What Are the Challenges?
Visibility into the application inventory is the first hurdle to overcome in any rationalization undertaking. This is down to the sheer scale and complexity of the modern IT operation, making it difficult to see the application portfolio in its entirety and get the insights needed to make informed rationalization decisions.
For example, it can be easy to overlook duplicated, zombie, and shadow IT applications, which are typically prime candidates for rationalization. Furthermore, determining the best rationalization journey for each individual application can be a complex decision-making process as it is. But, without sufficient insight, it can be all the more challenging.
The next major challenge is simply knowing where to begin. In other words, how to go about deciding which applications are in need of rationalization, how they should be rationalized and what applications should take priority.
Not only that, but the actual work on the applications themselves may be highly complex—especially in the case of legacy systems or where there are a large number of interdependencies. Besides, it can be difficult to assess the full extent of any work until that work actually begins. So it’s important to be aware that a project, which initially appears straightforward, may turn out to be more involved than first anticipated.
And, finally, the main objective of application rationalization is to reduce TCO. But this is hard to calculate, as it has to take so many factors into account—from manpower, licensing, and infrastructure to maintenance and support, retraining, and downtime costs. Nonetheless, it’s absolutely essential to present a TOC figure in order to get buy-in from senior management.
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.
Although this is possible by means of a manual spreadsheet, this is unsuitable for any mapping exercise at scale. So, in the case of medium and large companies, this calls for a specialist application dependency mapping (ADM) tool.
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.
To realize the full benefit of application rationalization, mapping should cover the entire organization and shouldn’t be isolated to a single office or global region.
And also bear in mind that, with good tagging and documentation, ADM can help identify the right point of contact for each application. This will make it far easier to gather further information in subsequent stages of the rationalization process.
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.
Rationalization Trajectory
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.
6. 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.
7. 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.
8. Lather, Rinse and Repeat
As the team gradually works through the list of earmarked applications, it should continually capture feedback and document any issues they encounter. That way, they’ll learn and improve the way they tackle each project as they go along.
This will be particularly valuable in cases where the work is an intermediate step to a longer modernization journey, meaning they’ll return to the same application further down the line.
Meet 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!
