Identify Right Disposition Strategy for Mainframe Application Modernization

Mainframe Modernization finds resonance with most mainframe shops but determining the right set of future disposition is critical in adopting the optimal application migration strategy. An incorrect decision can essentially make or break your modernization journey. In this blog, we will discuss the factors that helps determine the right strategy for your mainframe applications.

The different modernization strategies that have successfully helped customers realize return on investment and align with the business goals are:

1.       Retain or Renew

Mainframes provides a cost-effective and extremely reliable platform for large workloads. In most cases, it’s better to make the best use of the existing platform, since the investment is already made. If the modernization risk is too high, and the existing legacy application meets the business needs, while delivering the necessary business value, an enterprise can opt for leveraging in-place modernization solutions. The modernization solutions like API enablement, DevOps adoption, Z analytics, and Batch modernization can help the enterprises to harness the power of mainframes, while getting maximum value from the application business. We can also reduce the mainframe run cost by applying MIPS optimization techniques, license consolidation etc. wherever applicable.

2.       Reengineer or Re-architect

Enterprises often choose to re-architect, when remaining on on-premises has high risk. This is because it becomes difficult to patch old systems (and thus reduce security vulnerabilities) or there are no longer any programmers who understand how the application works. Listed below are few options to re-engineer/refactor the applications –

  • Auto Code Conversion: Auto code conversion vendors are doing fairly a good job at converting legacy code into programming languages like Java, Microsoft .Net.  In these conversions, about 60-70% of converted code is of good quality, while the remaining can be integrated or re-factored. There are other options like BluAge or Heirloom, where the percentage of code converted can be much higher, but the limitation would need few proprietary libraries to be licensed
  • Reverse Engineering and Forward Engineering: In this approach, the business rules from the legacy application are mined and transformed into service-oriented or micro services-based architecture. Such options are expensive but deliver higher value
  • Green Field Development: Some customers opt to discard the legacy application altogether and start fresh technology development to drive their business
  • Replace with COTS: A potentially cheaper option to re-engineer is to replace with commercial-off-the-shelf products. Retail and Manufacturing industries where IT dependency is significantly lesser compared to Insurance and Banking institutions can look forward to such alternatives

3.       Rehost or Re-platform

Re-hosting or re-platforming is relatively a faster and cost-effective option to port or re-platform from the mainframe to another system environment. By adopting lift and shift strategy, the legacy application can be hosted on-premises or cloud by using emulated platforms like Micro Focus or Raincode to lower the run cost of the application. It also allows easier integration of the application with open source-based technologies.

4.       Retire

Applications which have reached the end-of-life cycle are best suited to be decommissioned and archived. Such functions can be gradually built on non-mainframe technologies which reduces the mainframe footprint. Data and functionality duplication can be reduced by consolidating applications.

The application migration strategies will be categorized into one of the following solutions based on technical and functional capability of the application as shown in Figure 1 below.

Here is what we would suggest the factors that can help the customers determine the technical maturity and business value of the application:

Factors Determining Technical Quotient:

1)      Legacy Tech Debt – Total number of application components, % of Non-Standard (Assembler, REXX, SAS, Easytrieve, custom-build software’s etc.) versus Standard (COBOL, PL1, SORT etc.). The higher the ratio, the greater is the risk in maintaining the application, time-to-market, and integration

2)      Tech Debt Weightage – Figure out the dependency of critical and non-critical business functions on non-standard technologies. The higher the dependency, greater is the need for modernization

3)      Third Party Software – Evaluate ISV (Independent Software Vendors) tools used by application stakeholders (tools other than standard operating tools like software configuration management tools, monitoring Tools, scheduling tools) and check for the dependency on these 3rd part s/w for continuing business as usual. Higher the dependency, more is the need to think on the modernization options

4)      Application Coupling – Are the application boundaries clearly defined? Is application data clearly segregated? Is business logic for the said application housed mostly in its application programs? The more negative the response to these questions, the larger the need to modularize the application

5)      Time to Change – Average turnaround time to deploy the applications from inception of business needs. Average component changes, and average lines of codes changed, % of repeating components getting changed during every requirement are all factors that will give you insights on application maintainability, and whether its cost-effective to re-write into a modernized, modular architecture

6)      No of Developers – Average number of developers & skillset needed for enhancement and support of the application. The more non-uniformity in number of developers and skillset, the higher is the need for evaluating technology standardization through application modernization

7)      MIPS – The higher the Peak MIPS (Millions of Instructions Per Second) utilization of the application, the greater is the need for reducing the running cost of the application’s adoption migration strategies like rehosting, re-platforming, COTS replacement

8)      Legacy Database – Applications with dependency on legacy database like CA Datacom, SUPRA DB, IDMS etc. are good candidates to migrate to RDBMS databases, which can be easily integrated, while providing better database administration features. Another important point is the use of non-ASCII data types like COMP, COMP-3, HEX for business-critical data, which limits data sharing with open-source platforms

Factors Determining Business Quotient:

1)      Business Criticality – Business significance of the applications whether it qualifies as system of records or system of differentiation? Does this application provide edge over your competition? Availability of application – business hours, 24* 7 would also be a determining factor. Any service level agreements with regards to monetary penalty associated with the application could be crucial in taking the decision.

2)      Frequency of Change – Number of compliance and non-compliance requirements an application undergoes. If the application is changed frequently and cost of change is high each time, it is an indication to modernize the application

3)      Inbound/Outbound Applications –Number of internal/external applications providing/receiving data from these applications or out of these applications?

4)      Production Tickets – Average monthly, quarterly, annual service tickets. % Of tickets resolved at L1, L2 & L3 stage

5)      Number of Users – Average number of users/stakeholders using the applications once, greater than once, always. Level of management mostly accessing this application – observers, contributors, influencers, decision makers

6)      SME Retirement – Number of years core SME support with legacy skills is available and ability to reduce dependency on them

7)      Scope for Application Consolidation – If any application is doing similar or near similar functions where the business functionality can be merged so that the application can be decommissioned.

8)      Application Shelf Life – Does the business see the application need in immediate term, medium term, long term?

Once we determine the technical quotient and business quotient of the application on a scale, for all applications on the legacy landscape a quadrant like below (Figure 2) would provide a view on appropriate solution suitable for the application.

Infosys with its proven Zero Disruption Modernization approach has helped several customers in determining the right migration strategy for enterprises across the globe. Mainframe Modernization team at Infosys has 100+ consultants, who can leverage comprehensive framework for top-down analysis and Infosys Live Enterprise Application Development Platform for doing bottom-up analysis. By blending appropriate domain knowledge during the assessment, Infosys offers best-in-class services in defining and deciding application dispositions, cost estimates and modernization timelines.

Author Details

Virendra Natthvji Shambharkar

Virendra Shambharkar is a Senior Technology Architect with Infosys and has 20 years of experience in mainframe technologies, mainframe modernization, data base migration, MIPS optimization, performance, and DB tuning, application portfolio assessment, mainframe rehosting, product conversion. He currently anchors Infosys Live Enterprise Application Development Platform’s mainframe modernization development and deployment.

Leave a Comment

Your email address will not be published.