Right Positioning of Application Portfolio Rationalization and R-Lane in the Cloud Era

gowebing 2024-12-02

decision

Take a look at these decision-making methods for cloud migration

During discussions with many of my colleagues, I realized the need for (a) clear demarcation between Application Portfolio Rationalization (APR) and R-Lane, (b) the association of R-Lane with APR, (c) right positioning of APR and R-Lane and (d) role of modernization in APR and R-Lane.

While all these topics spinning around rationalization, they differ only in when and where rationalization is taking place. Let us consider the following three scenarios to better understand these trending terminologies.

Scenario 1: A telecom organization has 1,000+ applications to support its business and its IT branch recently acquired another telecom organization with 500+ applications. 50% of the applications were developed in-house and become legacy. Acquisition resulted in duplicate applications and cost overhead in managing these applications. The organization decided to rationalize applications to optimize cost.

Scenario 2: A retail organization has 1,000+ applications running in on-premises datacenter. Customer-facing applications are experiencing increased traffic and are not able to scale dynamically to meet increasing customer requests. 100+ applications are rarely used and some are not used by anyone in the organization. Additionally, there is a need to move out of current data center as the contract is coming to an end. The leadership team decides to rationalize applications and migrate them to public cloud.
Scenario 3: A bank has around 100+ applications supporting the business. One of the core business-critical banking applications has become legacy and is failing to adopt changes. It is unable to scale for increasing customer requests. Additionally, the bank has observed performance issues with this application.

You may also enjoy: Top 3 Considerations for Building A Cloud Native Foundation in Your Enterprise

Application Portfolio Rationalization (APR)

APR refers to an exercise of rationalizing applications. Rationalization can take place in applications running in on-premises environments or in the cloud. In Scenario 1, assume that there are two CRM applications running on-premises. While it originally had only one CRM, the second one was introduced when it acquired another organization with a similar CRM application. This incurs duplicate effort and cost in managing these two applications. Similarly, this set of applications becomes legacy over time, creating a need to rationalize applications. An APR exercise is carried out in such scenarios to achieve the following:

To eliminate duplicate applications and functionalities
To retire applications that are just running and not used by anyone
To replace applications that incur high operational and management costs
To rewrite or re-engineer applications that have become legacy and are unable to scale

Organizations willing to run an APR exercise need to adopt the right APR approach and methodology that defines different phases of APR and activities in each phase. A high-level view of the APR approach and methodology is given below.

Fig 1.0: APR Methodology

Fig 1.0: APR Methodology

In the Discovery Phase, applications are discovered, and applications' attributes are collected to gain a 360-degree view of the applications. In the Analysis Phase, applications are analyzed against the data collected. In the Recommendation phase, a high-level rationalization strategy or technique option is chosen for each of the applications.

In scenario 1, two CRM applications are rationalized into one by choosing the “Retire” option for one of the CRM applications and choosing the “Retain” option for the other one. In this case, customer data of the retiring application is migrated to the CRM application that is recommended to be “Retained.” An application that is not able to scale is “Refactored” by rewriting the code. Applications that are legacy and no code is available for them are “Replaced” with COTS products wherever applicable. Legacy platforms of applications are “Re-platformed” to the latest. In APR, most of the actions on application start with “R.” However, there is no standard term defining these Rs in detail during traditional APR time.

Let us now understand what R-Lane is and its association with APR.

R-Lane

In Scenario 3, while cloud migration is the main goal of an organization, moving all applications as-is is not going to help the organization as they will continue to face challenges with application scalability and issues with legacy. Additionally, applications that are not being used by any user at on-premises will be hosted on the cloud and will not be used at all. This will add to cloud costs unnecessarily.

APR exercise is carried out for these applications. APR always results in treating applications in any one of the several techniques seen in the above section. APR in the context of cloud migration introduces a set of R actions clearly defined for application treatment. Gartner defined five R strategies (Rehost, Re-platform, Re-factor, Re-Architect, Replace) to follow while migrating application workloads to the cloud. These strategies have evolved over time. A new framework defining different migration strategies that organizations can apply on applications before migrating them to cloud is called R-Lane. A high-level view of R-Lane in cloud migration is given below.

Fig 2.0 : R-Lane in Cloud Migration

Fig 2.0: R-Lane in Cloud Migration

Six migration strategies or techniques of R-Lane to treat applications are described in detail below. These strategies are also called the 6vRs of cloud migration and are applicable only in a cloud migration scenario.

Re-host

Re-host is also known as “Lift and Shift." The application is redeployed to a new virtual hardware environment in cloud with minimal effort. Application data is migrated as-is to the cloud without conversion so the application works seamlessly.

A legacy application that was developed in-house with few people using it is the best candidate to move to cloud in this category.

Retain

Applications that are not ready to move to the cloud are retained. These applications will be revisited later and get migrated to the target cloud environment when appropriate. Scenarios in which an application might be best retained include:

Applications that are not justifiable to move to cloud, like one whose OS is not supported by the cloud service provider.
When regulatory requirements demand that the app run on-premises and not in the cloud.
COTS applications that are not supported by cloud service provider

Retire

Applications with redundant functionalities are retired. For example, during merger and acquisition, there could be a “Salesforce” CRM application exists in both merging entities. Only one CRM is retained and the rest is retired once the data is consolidated. Applications that are not used by any users and are non-critical are retired and following decommissioning.

Re-platform

An application's platform can be replaced with alternatives to achieve some tangible benefits. The WebSphere application server is re-platformed to Apache Tomcat open-source server, thereby reducing the licensing cost. The core architecture of application is not changed while choosing this option.

Re-factor

While it is difficult to make improvements in the current environment to cater to the need of improved availability and scalability, application binary code is refactored. A scenario where an application’s existing environment is failing to meet the performance requirements would be a candidate for refactoring.

Replace

Replace, also called Re-purchasing, is a move towards SaaS adoption, like replacing an on-premise CRM application with Salesforce in an SaaS model.

Modernization

Modernization is not associated with APR; it is an independent activity. Since the scope in Scenario 3 is to deal with only one application, there is no scope for APR. The application can be modernized in many ways. Rewriting the code, replacing some of the services by developing a service layer over this application are the best examples for application modernization. In scenario 3, the application is modernized by rewriting the code.

Modernization in the context of APR is an action or decision recommended for an application. Re-factoring and re-platforming, two of the recommended options that we have already seen in APR and R-Lane, are two examples for modernization. Modernization is applicable in both APR and R-Lane exercises. Enterprises may request for a vendor to modernize a complex legacy application to accelerate digital transformation. Modernization opportunities for vendors need not be always as part of APR and cloud engagements. Modernization in the context of APR and R-Lane is described below.

Fig 3.0 : Modernization in APR and R-Lane

Fig 3.0: Modernization in APR and R-Lane

Summary

APR is an act of rationalizing applications running in either on-premises or on cloud. An APR exercise is mostly done on applications running on-premises, while it is rarely done in the cloud, with the objective of optimizing cost. An APR exercise can also be carried out while applications are being migrated to the cloud. While the approach and steps are the same for all these scenarios, the only difference is in the decision recommended for application treatment.

Gartner defined 5R migration strategies while moving workloads to the cloud. This was later enhanced. The new framework defining 6 R’s (Re-host, Re-Platform, Replace, Retain, Retire, and Refactor) for treating applications while migrating them to cloud is called R-Lane. APR is applicable in all scenarios, whereas R-Lane is applicable only in cloud migration. Modernizing an application can either be a totally independent exercise or can be the result of an APR exercise. Modernization in APR context is about re-factoring the code or re-platforming the existing one.