Application Modernization: A Rapid Assessment Approach

The intent of the Rapid Assessment is to define a set of high-level criteria that can quickly be applied to the application portfolio in order to rapidly disposition all the applications to a cloud journey. This is a preliminary assessment, with the intent of developing an initial point of view on the application estate. The intent is to be within plus or minus 10-20% of the dispositions that would be derived from a more exhaustive analysis. 

Developing a point of view on the disposition of the entire application estate is needed to do the following:

• Drive the overall business case for the hybrid cloud transformation.
• Develop estimates for modernizing and migrating the application portfolio to the cloud.
• Demonstrate a standardized modernization approach that maximizes the overall business value.
• Show the ability to quickly develop an understanding of the application portfolio and identify the attributes that drive complexity, time to market, performance and scalability.

In defining the Rapid Assessment approach, it is helpful to look at the Distributed and Mainframe workloads separately. These platforms typically have different modernization drivers, SLAs and supporting technologies, driving a varying set of criteria for evaluating the portfolio. Although many distributed applications have mainframe backends — or “systems of record” — a distributed workload, in this case, is defined as one that has its primary execution thread running on a distributed platform.

A typical high-level distribution of distributed application dispositions and their definitions is as follows:

• Refactor/modernize to cloud native: 5-15% consisting of highly valued, mission/business-critical applications. These applications are refactored or rewritten as cloud-native/12-Factor applications. This disposition provides the highest business value, as the application becomes more agile, scalable and highly available, but at a high cost. Consequently, these applications should be chosen judiciously, as they represent strategic investments that are typically millions of dollars per application. 
• Containerize: 50-60% consisting of most Java applications and some Windows applications. These applications are containerized to run in a Kubernetes container, ideally on Red Hat OpenShift. Containerized applications provide the optimal ROI based on the cost to containerize vs. the overall benefit realized.
• Migrate: 30-40% consisting of COTS, some Windows and other “Exotics” running on bare metal or virtual machines. These applications follow a “lift-and-shift” pattern with little to no code changes to move them to the cloud. The most common migrate patterns are physical to virtual and virtual to virtual.
• Leave as-is: <10% consisting of desktop applications, mobile applications (not including the backend) and applications already in the cloud (especially SaaS, although some applications in the cloud could be moved to a more preferred cloud).

Note these dispositions differ from other applications categorization rubrics, such as the Gartner 7 Rs, but provide a much simpler and straightforward way of classifying the portfolio while identifying the applications that will help drive the most transformation value — the applications that will be refactored and containerized:

A minimal set of data attributes is needed to execute the Rapid Assessment for distributed applications. Let’s look at each criterion in more detail.

Commercial-off-the-shelf (COTS) applications

Since the source code for Commercial-off-the-shelf (COTS) applications is typically not distributed to the purchaser, these applications will have to be migrated to the cloud. During a more detailed assessment (typically a 30-day sprint), additional investigation can be done to determine if the COTS vendor has plans to move the application to containers or develop a cloud-native version.

Some COTS custom adapters developed by the client may be candidates for refactoring or containerizing. This component-level disposition would be determined during a more detailed assessment.

SaaS applications or applications already moved to the cloud

Applications already running in the cloud typically stay “as-is” if the end goal is to accelerate the overall movement to the cloud. The applications could potentially move to another cloud if the goal is to move all workloads to a specific cloud provider, but the safest thing is to assume that these applications will remain where they currently reside.

Mission-critical/business-critical applications

Mission-critical or business-critical applications should be considered for refactoring or modernizing to cloud-native/12-factor applications, as they stand to benefit the most from the high cost of refactoring. 

From this set of applications, determine the applications that:

• Have a high degree of change activity or a large backlog and would benefit from being more agile, or
• Do not currently meet business needs and would benefit from being reimagined to reflect a modernized business process or improved user experience.

This category typically represents no more than 5-15% of the entire portfolio. For a portfolio of 500 applications, that translates to rewriting 25–75 applications in three to five years — which is a sizable number representing a huge development effort and cost!

Java applications

Java applications are prime candidates for containerization. Any application that runs in a JavaEE application server (WAS, WebLogic, Jboss, Tomcat, etc.) should be able to be containerized with a relatively small amount of effort. A key assumption is that the “bare minimum” will be done to containerize the app — middleware upgrades or movements (e.g., move relational database to a cloud-native database, move from MQ to Kafka) are out of scope. However, the CI/CD pipeline should be upgraded to produce containers and leverage the underlying features of OpenShift.

Windows applications

Windows applications have two options for containerization:

• Run in Linux containers, which is typically .Net CORE workloads
• Run in Windows containers, which were made available in OpenShift V4.6

In general, the decision criteria for Windows applications are as follows:

• .Net CORE move to Linux containers
• .NET, VB, C, or C# custom Windows App move to Windows containers

More detailed discovery is required to better determine the fit for containerization but assume at least half of the Windows applications can be containerized for planning purposes.

All other applications — migrate

All other applications would typically be migrated to the cloud, with the most common pattern being physical to virtual or virtual to virtual for most distributed workloads. “Exotics” or “non-mainstream” technologies require more careful consideration, as a cloud landing zone may not be readily available. iSeries and pSeries workloads can typically move to Power Systems Virtual Server in the IBM Cloud. Other workloads may require special hardware to be stood up in the CoLo area of IBM Cloud data centers, if possible (e.g., Unisys, Tandem Nonstop, etc.).

Mainframe workloads present additional complexities for defining application dispositions. The ultimate destination of these applications is not always clear cut, depending on the client’s overall mainframe strategy. For distributed workloads, the typical target landing zone is containerized or virtualized environments on x86 servers in the cloud. The target destination for mainframe applications can take on multiple flavors and can include the following, based on the client’s mainframe philosophy and business goals:

• Optimize applications on their current technology footprint to reduce compute and operations cost (compiler upgrades, coding efficiencies, etc.).
• Modernize/transform applications in place, continuing to run on the IBM Z platform (either z/OS or Linux on Z).
• Modernize/transform applications to run in a distributed cloud environment.
• Better utilize and access mainframe application assets from other distributed applications.
• Completely evacuate the on-premises data center, including mainframe workloads.

The answers to these questions will then help drive target dispositions, such as the following:

• Modernize the application to Linux on Z.
• Modernize the application to Linux on x86 in the cloud.
• Refactor the application in its current technology (platform and programming language) to drive operational efficiencies.
• Externalize key services as APIs.

For workloads that will stay on the mainframe, questions of where the mainframe will reside need to be answered:

• Retain in on-premises data center.
• Move to IBM Cloud Co-Lo facility.
• Move to IBM Z as a managed service provided by a global system integrator.

Consequently, the dispositioning of mainframe applications is much more involved, requiring more detailed client conversation and analysis of the applications in question. 

The following figure represents sample output from an application modernization Rapid Assessment in the context of developing a cloud-modernization proposal. The ability to quickly develop an opinionated point of view on the client’s application portfolio was a key differentiator of our approach:

At times, more detailed assessments may be required; however, the Rapid Assessment provides a quick and easy way to estimate the effort required to transform the application portfolio to the cloud and provides the inputs to determine the overall cloud transformation business case.