Assess Your Mainframe Applications for Modernization Readiness

Mainframes host critical applications consisting of millions of lines of code (LOC) across hundreds of online transactions and batch processes, built over decades in various programming languages such as COBOL, PL/I, Natural, Assembler, Ideal, and others. Companies often don’t have visibility of their entire application portfolio, active and inactive components, baseline inventory that limits the knowledge of application dependencies, interfaces, data flows, interactions with upstream and downstream systems, and other application characteristics., It is important to define and implement the modernization strategy for these applications, which are currently facing various challenges.

This blog post is an overview of how you can discover your overall mainframe application environment and conduct or oversee an application rationalization exercise, identify application boundaries, and determine inventory for the active applications which are in scope of modernization. Many companies engage a system integrator to do this work, but at minimum, you should be aware of the activities they will perform.

Scope

This blog provides a high-level overview of how to conduct an assessment for your mainframe environment and inventory assessment for each individual application. The various techniques we describe apply to any application running in the mainframe environment, whether they’re batch, online or system utilities.

Assessment types:

There are two types of assessment of the mainframe application environment: 1) a Portfolio Assessment and 2) an Inventory Assessment. In this blog post, we will focus on the Portfolio Assessment.

1. Portfolio Assessment: If your organization has decided to migrate all the workloads from the mainframe but does not have full visibility of which applications are running and their target disposition, then a Portfolio Assessment will be needed.

A Portfolio Assessment is conducted top-down, beginning with business and organization functions and drilling down into applications and technologies. The assessment consists of a series of workshops, and interviews with application owners, business users, and technical and business subject-matter experts (SMEs) to gather application information, and review existing architecture, application documentation and other information about applications in each business unit. This assessment could take anywhere between 8-16 weeks to complete, depending on the size of the mainframe, the code base, and the number of applications.

The outcome of the Portfolio Assessment is:

1. An application rationalization
2. An overall summary
3. Application grouping and sequencing
4. A high-level migration roadmap

And optionally, you may need an Inventory Assessment, depending on the understanding of your application estate.

1. Application Rationalization:  This is the process of identifying all applications running on the mainframe and determining their target disposition, such as Rehost, Replatform, Refactor, Rearchitect, Repurchase, Retain and Retire – these migration patterns are commonly referred to as the Seven R’s.

With Replatforming, you may move an application to new run-time technology, such as a mainframe replatforming tool. For Rehost, you might move some applications to a hardware emulator (if one exists), or to a colocation facility. With Refactoring, you would migrate the application’s source code and related assets to new programming languages or other technologies using automated tools. A Rearchitect project involves a redesign and rewrite of the original application. Repurchase means you buy an off-the-shelf replacement product that takes on the original functionality of the application. Or, you might decide to either Retain the existing application on the mainframe, or Retire it from use completely.

After generating an initial list of applications running on the mainframe from the customer SMEs, each application is thoroughly vetted via a series of questions across various dimensions, including business criticality, technical complexity, application health, data volumes, quality of the documentation. For each of the applications, the target disposition is determined – which migration R pattern is used for each application?

Here we list sample questions from each area that can help determine the target disposition for each application. There are five key areas to survey when determining the target disposition for the applications:

• • Business Criticality: How does this application support the business? What’s the financial impact if it fails? How many users? Transaction volumes? Regulatory & compliance requirements?
  • Technical Complexity: What is the technical nature of the application and its complexity? What programming languages and technologies were used? How many integration interfaces and application dependencies are there? How complex is the maintenance? How much technical depth exists? What are the agility challenges and skills shortage issues?
  • Application Health:  What is the current status of the application? Is it meeting Service Level Agreements (SLAs) for batch & online? How many failures, incidents, or trouble tickets during the last year? What issues are there with uptime? How many releases and enhancements were there in the previous year?
  • Support Level & Data Volumes: What is the background for application size and SLAs? How big is the application – number of programs, total Lines of Code? How much data does the application handle? What are the performance SLAs? Are there specific application pain points?
  • Level of documentation: What is the level of documentation available for the application?  Is there documentation for architecture and interfaces? Is there a runbook? What are the naming conventions? How are job schedules and ad hoc requests handled? Are applications commented?

Figure 1. A map of information flow showing how each type of assessment questions: Business Criticality, Technical Complexity, App Health and Support, Volumes, and Documentation flow into a Scorecard which eventually determines the Migration “R” Pattern.

Each question has its own weight and associated score. Once the data is captured for all the questions, then target disposition is determined by the tool managed by the service provider.

Upon completion of the application rationalization, you or your service provider should create a high-level overview of each application and its target migration pattern, as in the diagram below.

Figure 2 . A sample rationalization diagram showing each application under individual business areas, with color coding on each application to indicate whether the app is to be re-engineered, re-platformed, re-factored, re-purchased, or retired.

(Note that in this example, there are a variety of patterns used. If those business services are tightly-coupled, we will try to keep the “pattern mixing” to a minimum to simplify integration.)

2. Overall Summary – This section represents all the key findings and observations captured during the application rationalization exercise. In addition, it summarizes the report’s detailed results, including highlights, immediate cost-saving opportunities, etc. Here’s an example representation.

Figure 3. Sample Executive Summary of the lines of code analysis. Left pie/bar chart shows a breakdown of languages and apps by business unit, and right pie/bar chart shows breakdown of LOC by business unit and types of external interfaces. Also “Key Highlights” showing observations drawn from the code analysis

In addition, there may be a Business Unit Level Summary that documents individual applications from each business unit. This provides an example of description and summary information for each application and describes the logic for migration pattern selection.

Figure 4. Sample business unit-level summary detailing applications, business functions, technical infrastructure, observations, and business initiatives and conclusions based on data gathered.

3. Grouping & Sequencing – This is the process of identifying and segregating applications that are standalone or dependent on each other. This grouping helps build the migration wave plan. If the applications are highly integrated, then wave planning should be done by leveraging data augmentation or application integration to provide a transition from an on-prem mainframe architecture to a hybrid architecture.
4. High-level Migration Roadmap – Once the applications are identified, documented and grouped/sequenced, you can create a migration plan. Prioritize the groupings and place them into migration phases based on business importance and technical fitness. For example, if one group depends on another before it, that dictates a sequence. The migration roadmap may also include an initial POC phase to prove the approach before actual migration.

Figure 5. Sample migration roadmap timeline showing the three migration waves. Each wave contains several applications, and for each wave timeline, dates are reflected for code conversion, integration, testing and cutover.

2. Optional: Inventory Assessment: But how do we get a technical understanding of the applications themselves? What’s in them? How do they integrate with one another? What are the interdependencies? In our next article, we will describe how an Inventory Assessment might be done to analyze the application code prior to planning and executing the migration.

Conclusion

When you’re preparing for a mainframe application migration, you will need a thorough understanding of your applications and what you’d like to do with them. Seldom will you be migrating applications all with the same pattern, and seldom will you migrate them all at the same time. Creating a Portfolio Assessment, with its Application Rationalization, Grouping and Sequencing and the High-Level Migration Roadmap components will give you a set of assets that help prioritize, sequence, and plan for the migration activities.

About the authors: