Big Enterprise Software – eMarkets Meetup

Make the Connection
Big Enterprise Software
Introduction - Setting the cat amongst the pigeons
“The gap between what enterprise-class commercial packages
provide and what is actually needed is widening. This is
especially true for internet facing applications. Innovative
solutions that really scale and easily support modern techniques
such as continuous delivery are written by practitioners for
practitioners. They originate with many internet scale companies
and are refined as open source software. Big enterprise solutions
often obstruct effective delivery due to their accumulated bloat,
cumbersome licensing restrictions, and feature sets that are
driven by check-lists and imaginary requirements far removed
from the realities of most development teams.”
Introduction - Continued
- Many passionate views/opinions received
- Comments made publicly and privately
Why do I care?
- Our approach has caused waves in the organization
- We are envied for our rate of delivery and value
add to our business
- We work with extremely talented people in an
engaging environment
- We do very cool stuff!
- Our developers do not support our architectural
blueprints, what?
- Communicate feedback received
- Understand our current state
- Find common ground
Your Thoughts and Opinions
Your Thoughts and Opinions - Continued
Your Thoughts and Opinions
Differences in interpretation of “Big Enterprise
- Open Source vs Commercial eg. IBM Websphere
Application Server vs Apache Tomcat
- Java EE vs Java Vanilla
- Java vs Other eg. Golang
Open Source vs Commercial
- Strong view that we could achieve equal or
better results with Open Source Software
- Apache Tomcat, Jboss?
Java EE vs Java Vanilla
- Strong concerns raised on the testability of Java EE
- Alternatives proposed to container based component
model of Java EE
Java vs Other
- Strong views that Java is ‘Dead’
- ‘Modern’ languages emerging Scala, Golang
Our Current State in Context
- eMarkets architecture blueprint based on Java
Enterprise Edition
- Vendor partnership with IBM in line with Standard
Bank group technology standards
- Middleware technology stack comprises IBM
Websphere Application Server coupled with
Websphere Message Broker and IBM MQ
- Infrastructure provisioned globally with patterns
for high availability and scalability
Our Current State in Context – Challenges Faced
- Message Broker – Steep learning curve, inhibits
effective use of the technology
- Testability of Java EE stack has proven challenging
- Implementing high availability also proving
- Support engagement is ‘complicated’
- ActiveMQ – Break away from the Standard Bank
mold, but will it stand the test of time, and
capacity, and resilience, and availability, and …
Our Current State in Context – The Reality
- We are a bank
- We have 40 000+ employees
- We have a global presence and footprint in 20+
- We have a customer base of more than 5.4m
- We are an enterprise
Our Current State in Context – The Reality
- We have to be aware of the scale of the
environment that we are building software for
- Standard Bank is 152 years old, we are building
strategic systems that will probably outlive our time
at the bank and will still need to be maintained
- Our business operates 24/5/365 in geographically
dispersed regions. Our systems have to be
- Our business is increasingly dependent on our
- We have to be responsible
- Architectural blueprints, vendor partnerships,
enterprise platforms, maybe we need it?
Common Ground
- We will not be bleeding or leading edge, but should
we stop looking at industry trends, CERTAINLY
- Changing the direction of the Titanic is slow, but
our culture and approach has certainly caused big
- Our focus on strong engineering practices and a
drive for constant improvement sets us apart, we
are certainly on a good wicket to drive and
influence future change
Common Ground - Continued
- You have the support of an architecture team that
is willing to think critically and challenge the status

similar documents