Commentary: Moving from COBOL on a mainframe to Java in the cloud can be tricky. Learn how automated, AI-assisted testing improves the process.
Nearly two-thirds of large enterprises are running mainframe-based apps dating back two decades, according to the recent Mainframe Modernization Business Barometer Report from Advanced. Over a quarter of businesses run production applications that are as much as 30 years old–some even go back to the 1960s.
In other words, as much as we like to tout the cool, new tech, many enterprises are mired in not-so-cool, old tech.
For example, in a conversation with a friend at a U.S. public pension fund with nearly $100 billion under management, he told me they decided to take action and migrate most of their remaining mainframe applications from COBOL to Java. Why move from COBOL? Well, for one thing, it was hard to find developers that knew the language, or wanted to, with COBOL ranking #1 as the “most dreaded” programming language in Stack Overflow’s annual survey. But there were more reasons for embracing Java, starting with a desire to make better use of DevOps to improve software delivery.
Less COBOL, more DevOps
When migrating from COBOL (or any language) to Java (or any language), it’s smart to start with testing requirements. After all, much of your code may no longer even be used. And as you migrate to Java, you definitely need unit tests to know where you have arrived and to ensure a code base you can confidently upgrade over time as requirements constantly change. In the case of this pension fund, they decided to start with AI-powered Diffblue to automate writing those unit tests, something I’ve addressed before.
Migrating or upgrading decades-old apps can be complex, yet companies increasingly feel compelled to go that route. Data suggests more modernization took place in 2020 than years prior, as businesses confronted the shifts in demand and operational disruption of the pandemic.
SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)
Businesses are under pressure to create new value for their customers. Coupled with the demand for software-based products and services, the trend of competitive differentiation through technology isn’t a huge surprise. Additionally, organizations are finding that traditional approaches to software development and delivery are not sufficient to meet these needs, giving rise to trends like DevOps. By moving from COBOL to Java, for example, companies like this pension fund are able to embrace containerization and cloud.
The alternative–mainframe code, applications, and environments–created significant speedbumps for the company:
Rigid and difficult to access development and test systems.
Extreme sharing of environments, causing bottlenecks in development and test.
Code that is difficult to understand, difficult to establish dependencies within.
Unfamiliar or unknown build and deploy procedures.
Back level software, with no idea how to upgrade or what impact that may have.
Inability to make changes.
Lack of integration/coordination with other platforms.
The company’s first thought was to try to embrace DevOps while sticking with COBOL and their mainframes. However, implementing a culture of DevOps against a mainframe environment is incredibly difficult. First, the lack of a service-oriented architecture and extensibility make “systems thinking” a challenging task. Second, the core concept around DevOps is to connect development with technology operations. Big Iron is notoriously expensive to extend, which makes enabling mobile access to data a risky move. When the system itself is the biggest hurdle to realizing a culture of continual experimentation and learning in the name of competitive edge, it is time to replace the system.
“IT moves heaven and earth”
My pension fund friend runs a large software shop for the fund, with more than 150 people in IT. As it should, business requirements are driving his strategy to embrace a DevOps approach and move as many workloads as possible off the mainframe to Java.
“What I heard from the business…was IT moves heaven and earth to get us our enhancements, to get us fixes, and to roll out our application changes,” he said. “However, every time they rolled something out, it broke something else. I see that as a challenge to try to solve and incorporate into our internal IT processes. It’s really a culture change. I have taken it upon myself to improve our regression testing to hopefully speed our delivery and give our delivery higher quality.”
So far the pension fund has successfully moved 70% of its COBOL code to a Java code base covered by tests, with another two million lines of code remaining on the mainframe written in COBOL. But that change is coming: “We haven’t really gone live yet into multiple development environments so we don’t really know about what the performance is going to be,” he said, until it goes live into the company’s DevOps pipeline.
As developers check in code, the company automatically runs Diffblue Cover to generate Junit tests. Cover allows the developer to incrementally build test suites to measure progress and detect unintended side effects. Tests can be run continuously. Results are provided immediately.
The move off the mainframe has been an enormous effort, he said, and the fund isn’t yet ready to embrace automated coding in other areas outside of testing. But his team is exploring options in the cloud. He moved identity management to Okta, however, so that’s a start.
“We want to be nimble, flexible and where we can go from Azure to AWS, and wherever else, with containers and Kubernetes in the future,” he said. “We are investing a lot in DevOps, test automation and automating the business of IT. My focus has been in improving our quality of code, development operations, and getting our organization to a point where we can open up to cloud computing.”
Disclosure: I work for AWS, but the views expressed herein are mine.