How a UK Bank Is Visualizing Its Way Through Mainframe DevOps Constraints
Overview: Learn how a major UK bank is using Compuware Topaz for Program Analysis to visualize and understand complex mainframe programs and discover issues that could potentially thwart their DevOps progress.
Rather than suffer the time, expense and risk of re-platforming mainframe applications supporting customer-facing digital innovation, one of our customers—a large UK bank—has determined its working code is gold and vital to its DevOps journey.
As part of this journey, the bank’s debit cards development team is leveraging its existing debit card platform to create a new service that empowers customers to independently upgrade or downgrade their bank accounts. One of the team members, Richard, a skilled engineer, is writing the back-end mainframe application that will automatically order and issue to customers the appropriate debit card for the new account they select.
This service will remove the extra steps and time-consuming process of speaking with a call-center person to order the cards. It also gives the bank a competitive advantage over banks that aren’t offering a similar service to customers.
Digging into Code Constraints
The debit card platform relies heavily on a fourth-generation programming language (4GL) with a COBOL layer on top that orchestrates the 4GL calls. The debit cards development team has been reusing a lot of this procedural code, which was generated 20 or 30 years ago, because “our standards dictate we should reuse our existing APIs as far as possible,” Richard said.
Many DevOps-driven organizations have been wise to follow this “syntax is syntax” philosophy, realizing it doesn’t matter “if it’s C, C++, C#, COBOL, .Net—it all just needs to be harmonized,” as another customer put it at our 2018 Customer Advisory Council.
However, this philosophy is untenable without all teams and all platforms thriving under one DevOps culture, using the same modern processes, leveraging the same or similar tools that integrate across-platforms and support automation, visibility and agility.
When Richard began writing the debit-card issuing application, he couldn’t see or understand exactly what the 4GL was doing; nor could anyone else.
“There is only one subject matter expert for this at the bank whom I’m aware of, and they’re at the London site. But we have operations at three main sites in the UK and off shore. There also are no tools that allow the team to delve into this code to visualize and understand what it’s doing,” he said.
This lack of program understanding, even for a highly experienced engineer like Richard, quickly became a constraint on the progress of the automatic card ordering and issuing project.
Getting Visual Clarification
Fortunately, when it came time to test the new service, Richard was able to use the Runtime Visualizer feature in Compuware Topaz for Program Analysis to literally see into the 4GL.
While Topaz for Program Analysis also provides static code analysis, which maps all potential calls to other program modules, if used in the wrong context it can easily lead to developer inefficiency from information overload. Runtime Visualizer is valuable in that it maps the topology of all program modules that are executed based on the input data driving the process.
This enabled Richard to watch the actual execution of the program at both the COBOL application and 4GL layers, opening his eyes to the risks and inefficiencies of the latter.
“I was taken aback by the visualization of the actual execution, because it was the first time we’d seen what the 4GL was doing underneath the covers. It spawned this enormous process, which we never quite appreciated was as complex as it turned out to be. If it calls wrong it could potentially be really complex and expensive to fix,” he said.
With a deeper understanding of the application, the team can redesign the application structure; how the application accesses data; and the data model and index structure.
Having a way to display the risk and potential costs tied to the 4GL also empowered the debit cards development team to make a business case for funding to replace their 4GL code and invest in modernizing this portion of the debit card platform on the mainframe.
These changes will enable the team to truly drive innovation of an automatic card ordering and issuing service for the bank’s customers; generate new cost savings through more efficient use of manpower and CPU; and reduce the risk of failure while working with “the unknown.”
Visibility Matters in DevOps
Richard and his team might not understand the 4GL, but they don’t need to when they can use Topaz for Program Analysis to visualize the code and understand how things are working. They’re using this throughout most phases of development, from when they first begin system testing, into unit testing, into integration testing if issues come from user testing.
“If we have difficulty, now we can go in and use the visualizer to see what’s going on, whereas before we were blind to what it was doing,” he said.
This visibility is key to discovering programs and code that could potentially undermine innovation as well as those that can be leveraged to accelerate the bank’s mainframe-inclusive DevOps journey.