►
Description
Rodger Donaldson from the Bank of New Zealand (BNZ) presents their OpenShift Case Study as part of OpenShift Commons Gathering Red Hat Summit 2018 Banking on OpenShift Panel
A
Hi
there
so
we
started
our
journey
toward
OpenShift
with
a
business
problem.
We
have.
We
started
out
looking
at
an
area
of
our
business
that
was
giving
us
trouble,
which
was
our
small
medium
business
customers
trying
to
join
us
and
trying
to
draw
down
on
loans,
which
is
quite
critical
for
small
business
customers,
and
we
found
it
wasn't
working
very
well.
On
average,
on
average,
it
was
taking
about
six
hours
just
to
open
an
account
in
terms
of
the
staff
time
required,
and
it
was
quite
an
error-prone
process.
A
We
were
having
to
go
back
to
our
customers.
Ask
them
the
same
questions
over
and
over
again,
and
it
was
all
a
bit
rubbish.
We
sort
of
drilled
into
that,
and
we
said
okay.
Why
is
this?
Is
it
a
problem
with
our
staff
is
a
problem
with
our
processes
and
it
turned
out
that
the
answer
was
that
it
was
nothing
to
do
with
our
staff.
It
was
that
we
were
giving
them
bad
tools.
A
The
tools
we
were
giving
them
aren't
very
good
that
they
don't
follow
the
customer
conversations
and
what's
more,
there's
too
many
of
them.
So
we
found
that
just
join
the
bank.
We
were
asking
our
frontline
staff
to
use
19
separate
applications
with
repeated
data
entry
across
all
of
the
applications.
So
that
is
a
horrific
experience
for
the
front
liners
and
it
flows
through
to
that
bad
customer
experience
which
are,
then
you
ask
the
question
again
of
well.
Why
is
that?
A
And
when
we
started
looking
into
that,
we
had
built
a
lot
of
big
balls
of
mud,
very
traditional,
unified
ESB
services,
all
deployed
and
the
ESB
applications
that
try
to
do
everything
that
had
a
heavy
weight
deployment
model.
Because
of
this
we
have
a
low
release
cadence.
We
don't
trust
ourselves
to
make
change
and,
as
banks
tend
to,
we
then
put
a
lot
of
change
management
processes
to
try
and
protect
ourselves
from
breaking
things
from
releasing
things
that
have
got
problems.
A
This
means
we
have
lots
of
applications
at
this
point
with
a
quarterly
release
cycle,
where
even
a
small
change
can
take
once
you've
signed
off
on
testing
can
take
a
month
to
get
into
production.
So
at
that
point,
if
you're
a
developer
and
you've
been
told,
we've
got
a
new
regulatory
requirement
or
the
markets
changed,
and
we
need
to
push
something
out.
It
looks
easier
to
stand
up
a
whole
new
application
than
to
modify
an
existing
one,
which
is
not
really
ideal.
A
So
at
that
point
we
need
to
get
more
comfort
with
change,
which
means
small,
reliable
changes
that
leans
towards
the
micro
Service
style
pattern,
pulling
everything
into
twelve
factor
style
applications
so
that
you
get
comfortable
and
if
you
can
make
change
reliably,
you
can
then
go
faster
if
you
know
that
what
you're
doing
is
the
right
thing
that
it's
not
going
to
break
in
production,
then
your
developers
are
comfortable.
Your
testers
are
comfortable
and,
more
importantly,
your
business
owners.
Your
change
managers,
your
security
people,
are
all
comfortable.
A
One
of
the
things
when
we
talk
to
people
who
have
done
this.
That
was
quite
critical
is
that
you
have
to
have
a
platform
that
supports
the
style
of
application
development,
because,
if
you
don't,
instead
of
having
a
few
big
balls
of
mud,
you
have
dozens
hundreds
of
big
balls
of
most
small
balls
of
mud.
So
you
make
the
problem
worse,
not
better.
So
out
of
that,
we
picked
on
open
shift
as
a
container
platform.
We
wanted
the
orchestration
we
wanted
kubernetes.
A
We
wanted
as
a
packaged
app
so
that
we
could
run
quickly
rather
than
learning
kubernetes
from
scratch,
rather
than
learning
containers
from
scratch,
rather
than
learning
how
to
build
effective
pipelines
from
scratch,
we
stood
up
a
dev
team
to
refactor
one
of
our
problem:
child
applications.
We
stood
up
an
ops
team,
stand
up
open
shift
and
we
pulled
in
some
external
partners
like
OSS
in
section
6,
we
got
from
nothing
to
proof
of
concept.
In
six
weeks
we
showed
the
proof-of-concept
to
the
bank
directors.
They
looked
at
and
said.
A
This
is
how
banks
should
work
from
there.
We
got
to
production
and
eight
weeks
in
the
old
world.
With
this
application
it
took
a
month
to
do
a
release
to
production.
No
matter
how
small
the
change
was
in
the
new
world,
we
were
hitting
three
releases
per
week,
so
that's
a
massive
increase
in
productivity
and
that's
purely
a
function
of
how
confident
we
were
that
we
could
now
make
changes
without
breaking
the
world
from
there
we've
gone
strength
to
strength.
We've
got
more
and
more
people
on
platform.