Modernize Mainframe Workloads to AWS with Astadia Automated Refactoring

By Geert Coelmont, Sr. Solution Architect – Astadia
By Bruno Sahinoglu, Mainframe Specialist – AWS
By Paulo Coutinho, Sr. Partner Solutions Architect – AWS

Astadia

Legacy technologies such as COBOL, IDMS, Natural, Adabas, Assembler, IMS, and EGL, as well as their rapidly vanishing expertise, are becoming the number one burden for many mainframe customers.

In this post, we describe how Astadia can help customers quickly and safely move entire mainframe applications to Amazon Web Services (AWS).

Astadia can do this by refactoring towards cloud-native target languages such as Java or C#, cloud-first relational databases like Amazon Aurora, and Amazon Elastic Kubernetes Service (Amazon EKS) on a highly available, scalable, and secure AWS target architecture for mainframe workloads.

We highlight the key aspects in this approach:

• 100% automated code and data conversion.
• Automated testing tools for both batch and online workloads.
• Fully integrated automated workflow—from analysis, conversion, and building to AWS deployment and in-situ automated testing of the new cloud application.

Astadia is an AWS Select Tier Services and Software Partner that works with clients to modernize their IT investments to accelerate time to value, increase productivity, decrease risk, and optimize costs.

A Closer Look at Truly Automated Refactoring

Refactoring projects are often supported by tools to automate part of the work. Astadia provides truly automated refactoring, meaning both code and data conversions are 100% automated. Just as important, Astadia automates the testing of both online and batch workloads to the maximum extent.

To understand the importance of this automation, let’s look at a typical Astadia refactoring project.

Figure 1 – Project phases.

Each project is preceded by an assessment phase, where Astadia uses tools to perform an automatic analysis and discovery. This analysis serves as input for workshops with the customer where they agree on scope, desired target architecture,  and project plan.

The actual project then has four distinct phases, each with a clearly defined goal:

1. Factory certification: Completeness and syntactical correctness.
2. Factory exit: Isolated functional correctness.
3. System integration test: Integrated functional correctness.
4. User acceptance test: Overall functional and non-functional correctness.

The acceptance criteria for each phase are a number of “recordings.” These are sessions of real user interactions or batch workloads that were executed by the customer on a reference mainframe. Each project phase is then a continuous iteration of “convert/test/tune” cycles, where both the convert and test steps are 100% automated.

Convert-Test-Tune

In each cycle, conversion tools (Astadia’s CodeTurn and DataTurn) will re-convert the entire code base and the test data set. Test tools (Astadia’s TestMatch and DataMatch) will launch the acceptance tests against the freshly converted target application.

Original and target behavior are automatically compared, and any differences are reported to the team. Based on these reports, the migration specialists may, for instance, change some target configuration settings, improve some conversion rules, or fix an issue in the support libraries.

Once that is done, a new cycle can start to see if the issue is indeed resolved and that no regressions were introduced elsewhere.

Automated Workflow

A single cycle may consist of several dozen steps, so Astadia also automates the workflow. It uses Jenkins pipelines to execute all conversion steps in the right order, then build the target application, deploy to AWS, execute the tests, and produce the test reports.

This entire cycle can be performed in a matter of hours and is typically executed many times a day.

Full Automation

All of this wouldn’t be possible if the process wasn’t fully automated. For the project team, this means confidence and full control over the transformation process.

Full automation also adds a lot of flexibility to the project. For one, it allows the refactoring project to remain independent from day-to-day maintenance on the mainframe application.

At regular intervals throughout the project, Astadia will synchronize the project with the then-current production state of the application (sources, data structures, test data, and corresponding test recordings). From then on, the tools will simply convert and test this new state. The result is a near-zero freeze time.

Only at the very end of the project—typically one or two weeks before go-live—Astadia asks that the data structures be frozen and non-critical application changes be avoided.

Another example of flexibility: decisions can be made or altered until late in the project. For instance, Astadia may want to try out some alternative conversion rules that produce more maintainable code, or it may want to increase or reduce normalization in the relational model. All that needs to be done is to reconfigure the conversion tools, re-run the conversion and the tests, and check the results.

Thanks to full automation, this can happen without additional effort or risk until very late in the project.

Automated Testing

Last but not least: it’s hard to overestimate the importance of automated testing in refactoring projects. It’s a major factor in cost and risk reduction.

Take, for instance, the automated refactoring project that Astadia implemented at Société Générale Banque & Assurances Luxembourg. With applications comprising 10 million lines of code spread over 17,000 programs and 6,000 screens, the active management of testing was critical.

“Some of our core business applications received a technical upgrade, with major impact on all functions of the entire system,” said Luc Dosquet, at the time Deputy CIO of Société Générale Banque & Assurances. “We have been using TestMatch heavily to automatically compare the functioning and performance of the upgraded applications with our previous systems. Doing this, we did not only save several hundreds of man-days in testing, but we also improved the quality of the tests itself.”

Of course, a certain amount of manual testing will still be needed, such as some system integration tests and user acceptance tests. But automated testing helps to shorten these phases, too.

For instance, a Canadian public sector agency has executed two automated refactoring projects with Astadia. Thanks to the thorough automated testing throughout the project, they were able to reduce their typical three-month UAT phase to a single month.

AWS Solution Architecture

Astadia refactoring projects modernize mainframe applications to cloud-ready, native target technologies, out of the box. This is true for both the operating environment (platform, languages, database, client access) as well as for the development environment (build, debug and deployment tools).

Finally, integration layers like security, communication, printing, and scheduling may be modernized to native target equivalents.

Some of the technology mappings that Astadia can provide are:

With the above set of target technologies, Astadia refactored applications are ideally suited for deployment on the AWS Cloud.

The application will run as a native target application (for instance, a JVM) deployed as Kubernetes pods on Amazon EKS, with all of the corresponding benefits: automatic horizontal and vertical scaling, load balancing, rolling updates, and managed databases.

The below diagram shows the Astadia refactoring reference architecture for AWS:

Figure 2 – Astadia refactoring reference architecture for AWS.

This AWS reference target architecture provides the following benefits to mainframe customers:

• Cost efficiency through consumption-based pricing and AWS managed services.
• Avoids mainframe limited capacity using elastic services and global/regional redundancy.
• No vendor lock-in with portable and open technology stack.
• Fully integrates with other important architecture components that are provided by AWS-native services or AWS Partner solutions. This includes authentication and authorization, monitoring, logging, output management, jobs schedulers, and application integration, creating a cohesive IT cloud architecture capable of running and operate mission-critical applications.
• Based on modern and popular technology, mitigating the vanishing mainframe expertise.
• Allows the optimization and modernization of the workloads (migrated), taking advantage of the 200+ AWS services available for innovation.

Further Modernization: Do’s and Don’ts

An often-heard complaint is that an automatically refactored application can never be as good as a manually written program developed from scratch. While this may be true, it’s not a fair comparison. An automated refactoring project simply isn’t a rewrite project.

Refactoring will still get the best possible code quality but under two essential constraints: full automation and full functional equivalence. These constraints are essential when taking the first step—getting from mainframe to cloud with the least possible risk and effort, and in the shortest possible time frame.

In a second step, any kind of further improvements are possible, without limitations. Even a complete rewrite is still possible if there is a business case for it. More likely, you’ll want to modernize gradually—if, where, and when it makes sense.

One important remark: don’t try to manually improve the generated code while the project is still underway. Not only will this undo all of the benefits of true automation, but it will also hinder problem analysis. Issues could now be caused either by the conversion tools or by the manual changes.

In summary: avoid mixing risks. Concentrate on getting the application off the mainframe and in production on the cloud. Only then start with further manual modernization.

Sample Case

One of the more recent Astadia automated refactoring projects was at Foyer Group, an insurance company based in Luxembourg. Using the Astadia automated refactoring approach and tools, its mainframe with a mixture of COBOL/CICS, EGL, DB2, IMS, and VSAM and was fully decommissioned and replaced by a Kubernetes cluster running entirely in Java and DB2/LUW.

When going live, the refactored application ran exactly the same business functionality as the original mainframe application, but now on a modern platform and with a greatly simplified architecture and improved tooling.

This has several major benefits:

• Foyer now has an open infrastructure that makes interoperability easier compared to the mainframe system.
• The refactored application already runs in Kubernetes, which makes switching to cloud trivial.
• The number of tools and technologies required for development and implementation has been greatly reduced, which has a positive impact on infrastructure maintenance costs.
• Generalized DevOps concepts are now available to optimize the development cycle and achieve continuous industrialization of deliveries.

Conclusion

Refactoring projects provide the best overall results for modernization from mainframe to cloud. Contrary to mere replatforming, refactoring will modernize the application’s entire technology stack to native target technologies, allowing the best possible integration with the rich cloud ecosystem and unlocking a large pool of new talented workforce.

Fully automated refactoring projects—with 100% automated code and data conversion—provide major benefits, even compared to “almost-fully-automated” approaches. They are more flexible, allow near-zero freeze time and, combined with automated testing, they will considerably reduce risk, effort, and project duration.

.

.

Astadia – AWS Partner Spotlight

Astadia is an AWS Select Tier Services and Software Partner that works with clients to modernize their IT investments to accelerate time to value, increase productivity, decrease risk, and optimize costs.

Contact Astadia | Partner Overview | AWS Marketplace