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.
"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
Prabhat Srivastava, Rod
Ainge, Anna Burch, Kevin
Kilroy and Saberesh
Parthasarathy collaborate
in Bankwest's head office.
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
D
The company
wanted to
leverage
20 years'
worth of
investment
in its existing
programs and
modules
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
22 // JULY/AUGUST 2017 ibmsystemsmag.com
pg 20-25.indd 4
6/13/17 10:09 AM

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page.
If you would like to try to load the digital publication without using Flash Player detection, please click here.