March 9, 2022 By John De Marco 6 min read

This Rapid Assessment defines high-level criteria that can be quickly applied to the application portfolio to rapidly disposition all applications to a cloud journey.

Dispositioning an application portfolio against the various hybrid cloud modernization and migration journeys often needs to be done quickly — sometimes in a matter of hours — in order to estimate the effort to modernize and migrate the applications to hybrid cloud.  

This “Rapid Assessment” approach has been developed to drive application modernization and application migration estimates when it is not possible to conduct a detailed application portfolio analysis. Instead, the applications are assessed and assigned to a simple set of dispositions (Refactor, Containerize, Migrate, Leave As-Is) using a minimal number of inputs: operating system platform, programming language, bespoke vs. COTS vs. SaaS apps and mission-critical vs. non-mission-critical apps.

This approach allows the application dispositions to be determined in a matter of hours with an accuracy of 80-90%, versus more detailed assessments that take months.  

Rapid Assessment overview

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. 

Rapid Assessment: Distributed applications

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:

Figure 1: Distributed application decision criteria.

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 application decision criteria

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. 

Sample Rapid Assessment output

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:

Figure 2: Sample application modernization Rapid Assessment output.

Summary

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.

Learn more and get started with application modernization.

Was this article helpful?
YesNo

More from Cloud

IBM Tech Now: April 8, 2024

< 1 min read - ​Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 96 On this episode, we're covering the following topics: IBM Cloud Logs A collaboration with IBM watsonx.ai and Anaconda IBM offerings in the G2 Spring Reports Stay plugged in You can check out the…

The advantages and disadvantages of private cloud 

6 min read - The popularity of private cloud is growing, primarily driven by the need for greater data security. Across industries like education, retail and government, organizations are choosing private cloud settings to conduct business use cases involving workloads with sensitive information and to comply with data privacy and compliance needs. In a report from Technavio (link resides outside ibm.com), the private cloud services market size is estimated to grow at a CAGR of 26.71% between 2023 and 2028, and it is forecast to increase by…

Optimize observability with IBM Cloud Logs to help improve infrastructure and app performance

5 min read - There is a dilemma facing infrastructure and app performance—as workloads generate an expanding amount of observability data, it puts increased pressure on collection tool abilities to process it all. The resulting data stress becomes expensive to manage and makes it harder to obtain actionable insights from the data itself, making it harder to have fast, effective, and cost-efficient performance management. A recent IDC study found that 57% of large enterprises are either collecting too much or too little observability data.…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters