Fast and Fearless Change for Mainframe Applications—Without Repeating Risks

Just like the Fast and Furious movie franchise, it seems like mainframe modernization is a predictably repeated story that never runs out of sequels in most enterprises, even if the plot is pretty much the same every time.

Organizations delay changing and evolving their application estates because developers fear they will break systems they don’t understand, and IT operators fear what will happen if live mainframe production environments are disrupted in any way.

Regardless, enterprises must realign their most critical core systems to keep up with the pace of change required to become more agile and responsive to customer needs, or they will risk losing customers. Instead of fearing change on the mainframe, we should fear not changing fast enough.

Breaking the calcification of COBOL

As an early programming language, COBOL isn’t particularly complex in and of itself. There’s a rather limited instruction set, and when most COBOL code was written, there was no need to even think about object orientation—much less extended libraries and frameworks or a distributed cloud architecture.

The calcification that prevents refactoring doesn’t come from COBOL, it comes from the fear of change: the risk of layering on each additional procedure and workaround, in order to add just one more feature to the monolith.

As new code is appended one function at a time over the years to adapt to change, mainframe-based applications start to accrete technical debt and become more unstable and harder to change without failures.

Worse still, at this point, nobody knows the intent of the original builders, as they have likely already moved on or retired from those roles long ago, without leaving behind adequate documentation.

Rather than having to check out, review, and rebuild the whole program every time a change is needed, what if we could instead refactor mainframe programs into separate logical components? Then, even an individual developer could check just one component of the whole program out, and develop and test a new feature in isolation, away from the entire monolith.

Finally, we may be able to realize the dream of agile development on the mainframe, without the fear of failure.

Refactoring monoliths with BMC AMI DevX Code Insights

Calling up mainframers from retirement is probably not feasible, and even if an organization has retained COBOL developers, they are likely to be in short supply. Enterprises need a way to convey the intent of those original, expert builders into a system that is more object-oriented and understandable to modern development teams.

BMC has released BMC AMI DevX Code Insights, a solution that allows developers to scan an entire mainframe application for business logic and structure, and then extract a limited section of the monolithic program for isolated development, testing, and replacement.

The extracted section here is a subprogram with discrete inputs and outputs, a truly modular component that developers can work with in parallel to other teams working on their own subprograms. Subprograms can even be called on via APIs and exposed to external services.

Rather than needing to check out the whole stack, subprograms undergoing development and testing can be inserted into teams’ DevOps, and GitOps automation scripts and delivery tools of choice. This enables shift-left testing practices, a core tenet of modern agile development that discovers bugs and errors earlier, when they are far less labor-intensive and costly to fix.

Of course, even if we can isolate certain features of the monolith as subprograms, that doesn’t mean the original business logic was simplistic, especially if it was a section of the application that was updated several times with complex IF/THEN/GOTO statements and looping returns.

Here’s where a little sensory enhancement can save the day. BMC AMI DevX Code Insights includes a Runtime Visualizer feature that charts out a call-by-call working model of the running mainframe application, including inputs and outputs, files and database access, which can be replayed any time or watched in real time.

Rather than uprooting the whole tree trunk, developers can just snip off the logical branch they need to work with.