Bankwest Modernizes Its Mainframe Integration Environment
UP CLOSE
| Customer: Bankwest Headquarters: Perth, Australia Business: Retail and business banking services Challenge: Reducing complexity between front- and back-end banking platforms Solution: Taking advantage of Java on the mainframe to reduce reliance on traditional middleware Hardware: An IBM z Systems zEnterprise BC12 Software: IBM WebSphere Application Server Liberty, Open Services Gateway initiative (OSGi) applications, Apache Maven, Git Stash, TeamCity and Proteus |
Companies know they don’t operate in a vacuum. This is perhaps most evident in the banking industry, as the Perth, Australia-based Bankwest is very aware. Competition in this space is fierce, and any missteps can result in a hit-the-bricks customer mentality.
That’s why Bankwest has put several modern customer-facing technologies in place, including mobile and online, to make it easier for its customers to do business. This directly aligns with Bankwest’s purpose: helping people achieve what matters today, and for generations to come.
Legacy back-end systems can be an impediment to efficiently extending these offerings, however, creating a level of complexity that may slow time to market and hinder the implementation of future technologies.
According to Kevin Kilroy, senior IT specialist, Bankwest, this was the case at his organization. As he puts it, “If we can’t adapt at speed, we can very easily be disrupted by more agile startups.”
Realizing its middleware-based approach to data transfers was holding it back, Bankwest tasked its core engineering team with simplifying the stack to find ways to allow front-end apps to integrate directly with the company’s core mainframe-based banking system. This resulted in what the company calls Prime 2, a simple, lightweight suite of mainframe-based RESTful APIs that are directly accessible by modern web apps and mobile clients.
“This enables us to focus on delivering superior customer and user experiences. We’ve reduced software layers and duplication, our infrastructural footprint and time to market for solutions to be developed, while also modernizing our technology by using Java* on the mainframe,” Kilroy says.
Back-End Complexity
A division of the multinational Commonwealth Bank of Australia (CBA), Bankwest has a presence throughout Australia. It specializes in both retail and business banking, including checking and savings accounts, credit cards and loans.
Although it does share some of its basic computing resources, such as payroll, with CBA, it’s largely autonomous when it comes to developing its own IT solutions, including mobile and online services and its core banking system, which currently runs on an IBM z Systems* zEnterprise* BC12 (zBC12).
Developed 20 years ago using PL/I, this system “was the first real-time banking system in the world to use a relational database,” Kilroy says
A number of upstream and downstream channel systems—online banking, contact center, mobile, risk management, lending processing, brokers and payments—had been developed throughout 20 years, using a range of integration technologies and middleware techniques, which led to duplication of effort and heavy resource consumption. And with customers increasingly choosing to bank online and on mobile devices, and the resulting proliferation of channels and front-end technologies, Bankwest could foresee issues regarding back-end complexity and delays in development time.
“If someone wanted to use the mobile banking application to have a look at their account, the mobile app would connect to a middleware application and then that middleware would interface with the mainframe. So while that gives you certain benefits in that these systems would be talking to the mainframe, it also introduces another layer of complexity,” Kilroy says. “For example, when developing solutions, you might need to make changes in the core banking system, but then you might also need to make changes in the middle-tier application that’s interfacing with the mainframe. This is expensive in terms of both time and money.”
When considering how to address this, one of Bankwest’s high-level goals was to simplify the stack by removing middleware where it could. This would help simplify application management because it would have fewer moving parts.
The initial iteration of Bankwest’s prime directive (i.e., Prime 1) was an interface involving a low-level TCP/IP socket integration that enabled a middle-tier application to send XML to the mainframe and then in turn receive XML responses. Although the company wanted to retain that type of interface, Bankwest felt it needed to be modernized, incorporating both TCP/IP sockets and HTTP.
“We’re here to try and really optimize everything around our customers. … So by both leveraging and modernizing the investment in our mainframe, we can now do that in a more timely fashion.”
—Keven Kilroy, senior IT specialist, Bankwest
“The goal was to evolve Prime 1, not necessarily change it. With that in mind, we would have both Prime 1 and Prime 2 running in parallel, with all new apps being built using Prime 2,” Kilroy notes. “We can still support the middle tier and existing apps that use Prime 1. But what Prime 2 would give us is the capability to define RESTful APIs within the mainframe so we can take an existing PL/I program, define what that will look like in a RESTful API and then generate all of the necessary Java code.”
To support this effort, the company wanted to take advantage of the API economy, which allows developers to create APIs to link services, applications and systems across platforms. Increasingly, integration between companies has become the dominant trend in this space. For example, it’s now much easier for third-party businesses to integrate with each other’s systems, having common interfaces, RESTful APIs with which they’re familiar and the lightweight JSON data type.
Not only does API integration work between companies, but also between modern web browsers, mobile clients and back-end systems, as in the case of Bankwest. By developing its own suite of RESTful APIs, the company wanted to have a foundation in place through which it could develop and deploy apps within days. This would allow it to leverage the benefits of its mountains of data and the 20 years’ worth of investment in its existing PL/I programs and modules without having to create new integration interfaces every time a new business capability was needed.
“We could’ve easily taken the approach of introducing another piece of middleware to open up the data, but that would’ve been in a less optimal format than developers have come to expect these days. So by creating our own framework, we have complete and fine-grain control over how the data looks, what it contains and what it references,” Kilroy says.
A Massive Time Saver
Of course, achieving these goals required a lot of effort, both internally and externally. Initial work began during one of Bankwest’s “Hackdays,” where people within the business—in IT and beyond—come together to work on initiatives that will benefit the business and customers. In this case, a short proof of concept was developed that demonstrated the capability to present mainframe data directly to web apps running in the browser in JSON format. This was then shown to business stakeholders to generate buy-in and support for the idea.
After approval, development began in earnest. With assistance from IBM, Bankwest created new CICS* V5.2 environments to host the Java Runtime Environment running bimodal CICSPlex* with the CICS V5.1 environments that host the PL/I programs and modules. This facilitated a two-speed development capability where developers could take advantage of the Java improvements in 5.2 without a five- to six-month project to upgrade all the other environments from CICS 5.1 to 5.2.
Bankwest also made the decision to auto-generate the Java code required to create the RESTful API on the mainframe. This meant that a CICS PL/I developer could take existing business processes and open them to the web without having to know how to code in Java. This was developed using Xtend from Eclipse, which gives developers the ability to program in a functional way while also generating idiomatic Java that’s not based on brittle template files.
“We can literally get prototypes up within hours, which is great if we’re giving demonstrations to users within the bank. If you were to write that Java from scratch, you couldn’t do it at the same speed. You’d have to write all of the validation and error handling—this takes a lot of time. Instead, we can generate all of that from the framework, which is a massive time saver,” Kilroy says.
To ensure application stability, security and automation, Bankwest deployed a number of other solutions. As Kilroy explains, “One of the properties that’s made the core banking system successful over time is the modular nature of the PL/I programs. We have a certain degree of isolation within this structure, which means defects within a specific PL/I program or module don’t compromise the entire system. This behavior is something we wanted to mirror in the Java REST framework, so we utilized OSGi Alliance applications for that. This allows us to deploy the RESTful endpoints in isolation from each other, and thereby achieve similar isolation/resilience properties as the PL/I programs.”
These OSGi applications run within IBM’s WebSphere* Application Server Liberty profile in CICS V5.2 on the Bankwest mainframe.
This dovetails nicely with the development process of a CICS PL/I programmer working on creating business logic in PL/I and pushing both the PL/I and Java OSGi applications together as an atomic unit through the environments, all the way to production. In support of this, Bankwest developed a continuous integration, deployment and test pipeline using Apache Maven, Git Stash, TeamCity and Proteus, a PL/I source-code management system. This provides a secure, audited, repeatable and automated pathway to production.
Frictionless Customer Service
Over the last few years, Bankwest has been building an Infrastructure-as-a-Service (IaaS) platform using the open-source cloud computing platform OpenStack. Although the mainframe is Bankwest’s system of record, this IaaS-based cloud infrastructure is where it hosts front-end apps, including JavaScript, HTML and CSS mobile apps, which then communicate over HTTP to the mainframe. This, according to Kilroy, “is about having that capability to develop and create environments to deploy in an automated and repeatable way.”
In fact, one of its goals when starting down this path was to build an improved experience so when developers are creating an application that interfaces with the core banking system, they can use modern RESTful techniques that give them fine-grain control over the process. For example, to institute a new data format in the future, they can quickly integrate that change in a manner an off-the-shelf package wouldn’t.
The bank’s ultimate goal was to better serve its customers by deploying a seamless integration platform that could easily be updated as needed. “We want to make things as frictionless for our customers to bank with us as possible. So, for example, when you apply for a product, we don’t want to be asking you to re-enter the same data over,” Kilroy says. “We want to streamline that process so they can move on to the things that matter to them. We’re here to try and really optimize everything around our customers. And to support that—even taking into account future apps that haven’t been invented yet—we need the proper systems in place. So by both leveraging and modernizing the investment in our mainframe, we can now do that in a more timely fashion.”