10. ADOPT EVOLUTIONARY ARCHITECTURE
10
Refocus resources and efforts in building a
future-proof architecture.
…and stop trying to predict what the business and technology
will look like in the future.
11. AGENDA
The Dream
A New Beginning
The Cloud-Native Financial Institution
Fast-Track to Evolutionary Architecture
11
13. - Current status
- Tight coupling
- High complexity
- Large Regression tests
- Operational Issues
- Local and Enterprise
Change Advisory Boards
- Release is a pain
- Serious business losses
Image from: https://disrupt-and-innovate.org
2015
19. - Is the mainframe really the issue?
- Thousands of modules, programs,
copybooks, etc. in PL1 and Cobol.
- External interfaces have been estimated to
be > 50K.
- No documentation.
- Multiple versions with no way to know which
one to use.
- Same functionality implemented multiple
times.
2015
20. - Is the mainframe really the issue?
- Thousands of modules, programs,
copybooks, etc. in PL1 and Cobol.
- External interfaces have been estimated to
be > 50K.
- No documentation.
- Multiple versions with no way to know which
one to use.
- Same functionality implemented multiple
times.
2015
21. THE OUT OF MAINFRAME PROJECTS!
A.K.A. THE ”RECODE THE
BANK” PROJECTS
2015
22. - The system was complex to develop in.
However:
- All transactions hit one single DBMS.
- Very skilled DBA central unit with dedicated
specialists in any development team.
- Constant monitoring and optimization.
- RCAs on incidents seldom located root
causes on this platform.
DB2
2015
23. - Is the mainframe really the issue?
- It was true that the system was complex. But
just to develop in.
- All transactions hit one single DBMS.
- Very skilled DBA central unit with dedicated
specialists in any development team.
- Constant monitoring and optimization.
- RCAs on incidents seldom located root
causes on this platform.
DB2
2015
30. #2 BE SMART
30
- Define an Exit Strategy
- Use containers
- Segregate business logic from ”infrastructure wiring”
- Adopt an evolutionary architecture
31. AGENDA
The Dream
A New Beginning
The Cloud-Native Financial Institution
Fast-Track to Evolutionary Architecture
31
36. ENCLAVE - DEFINITION
MICROSERVICES FOR THE ENTERPRISE
36
An enclave is a self-sufficient, secured and isolated
platform composed of a set of services supporting
any number of external or internal applications that
resides within the same enterprise business
domain.
37. - It has a single inbound (API Gateway) and a single
outbound (Integration) network microsegment.
- Microservices in the API Gateway and Integration
Context are completely stateless (regarding the
transactions).
- It segregates business domains in different
microsegments of network
- Synchronous communication is discouraged
(besides for data queries).
- Mutual TLS everywhere microsegments are
crossed.
- Authorization through JWTs
SOME DETAILS
Security
Business
DomainsBusiness
DomainsBusiness
Domains
API Gateway
Integration
38. - It has a single inbound (API Gateway) and a single
outbound (Integration) network microsegment.
- Microservices in the API Gateway and Integration
Context are completely stateless (regarding the
transactions).
- It segregates business domains in different
microsegments of network
- Synchronous communication is discouraged
(besides for data queries).
- Mutual TLS everywhere microsegments are
crossed.
- Authorization through JWTs
SOME DETAILS
Security
Business
DomainsBusiness
DomainsBusiness
Domains
API Gateway
Integration
42. PRACTICAL EXAMPLE: PAYMENTS
42
Private
Banking
Mobile
Pay
Payment
Systems
• A payment is requested by a user in
MobilePay [Status: Pending]
• The request is committed in the
MobilePay enclave and a Local
Event is fired. [Status: Pending]
• Payment systems perform the
required checks and operations and
fires an Enterprise Event [Status:
Pending]
43. PRACTICAL EXAMPLE: PAYMENTS
43
Private
Banking
Mobile
Pay
Payment
Systems
• A payment is requested by a user in
MobilePay [Status: Pending]
• The request is committed in the
MobilePay enclave and a Local
Event is fired. [Status: Pending]
• Payment systems perform the
required checks and operations and
fires an Enterprise Event [Status:
Pending]
• Both Private Banking and
MobilePay enclaves receives the
Enterprise Event and update their
state [Status: Approved]
47. NEW TECH SOMETIMES MEANS INSTALL NEW STUFF…
ENDPOINT SECURITY
47
• Great idea with having Device
Management as security
cornerstone.
• However, that Access Proxy can be
very complex to implement.
Image from https://www.praetorian.com
48. ENCLAVES TO THE RESCUE
4848
• Great idea with having Device
Management as security
cornerstone.
• Specific enclaves for internal
applications will only be available to
authorised devices.
• For any other specialised use
evaluate on a per needed basis
avoiding the construction of
complex systems (SSH tunnelling,
Citrix, Jump Hosts, etc.)
49. AGENDA
The Dream
A New Beginning
The Cloud-Native Financial Institution
Fast-Track to Evolutionary Architecture
49
50. OPEN SERVICE BROKER API
50
A simple set of API endpoints which can be used to
provision, gain access to and managing service offerings.
51. ENCLAVES AT SCALE: OPEN SERVICE BROKER API
51
Business
Unit
API Cloud2 Delivery Non-Production Production
API
Create Enclave
API
Create
Business Domain
API
Create
Microservice
Cloud2 Engine
Cloud2 Engine
Cloud2 Engine
52. ENCLAVES ARE JUST ONE OF THE POSSIBLE BLUEPRINTS
52
Cloud Development Guild
(R&D) Automation
Application Blueprints
59. AT BESTSELLER WE STARTED FROM THE ORGANIZATION
59
Customer Consumer Products
Operations
Finance &
BI
Workforce
- Products instead of
Projects
- PO & SM as leaders
- DevOps culture
60. AND NOW WE TACKLE THE TECH: A NEW ERP SYSTEM
60
PL/SQL
61. WRAP UP
1.Stand on the shoulders of giants (your legacy)
2.Be Smart (avoid vendor lock-ins and expect migrations)
3.Future proof your applications
4.Automate and use Standards
5.Start from the organization and invest on your people
61
Angelo, worked in several companies during my carreer.Both in start-ups and large enterprises.
About the latter, I have been in Danske Bank for 7 years where I grew from IT Developer to Head of Software Engineering.Recently I joined BESTSELLER, one of the leaders in the Fashion Business.
Start-ups, you have a lot by default:
Quick decisions,
Fail fast
DevOps
Amazing development experience
0 legacy and full green field projects
very fast development
quick releases
fast, strong and direct feedback loops.
It is a real pleasure to work. However the challenge and impact is not there yet.
The Enterprise is quite the opposite.
Your company has already an impact on today’s market and you need to maintain it and expand it.
Your may be constrained by:
Current tech landscape
Organizational hirerarchy
Processes supporting different way of working
Needed integration to existing systems
In more detail, you are required to develop solutions that are already integrated in the enterprise technological landscape
And respect specific processes
From idea generation to production at Danske Bank you had to factor at leasr 70 days on top of the effort needed to develop and release the application or feature you wanted.
Our dream was the one shared by any other enterprise: to bring the way of working and time to market you can have in start-ups while having the amazing challenges that only the enterprise world can offer you.
From this the need for a higher degree of agility.
We were tasked with the great assignment of building a new Mobile Bank for the following reasons:
Higher availability
Higher release quality
Shorter time-to-market
… and at the same time remove dependencies from external IT company
We started in 2015 and we were standing on a platform on fire
Just to understand what this meant business wise, let’s take the MobilePay example.A very successfull peer-to-peer payment app Danske Bank released in Denmark in 2013.
Currently won the full market and aggregated 60+ banks in that market.
Danske Bank could not release it in time to other markets.Vipps was released 2 years later in Norway, before Mobile Pay, winning the market.
When MobilePay was released it was too late and it was later on closed down.
A lot of people blamed it on the mainframe!
Just because it was ugly…
But was it really that the issue?
Let’s look at its status…
And you may conclude that it is actually true…
Tens of projects were started with the only purpose of ”solving this issue”.
However this really cannot be it.We have built a humongous business completely on the mainframe… can this really be this useless?
However it really was not!
Legacy is not necessarily technical debt.
Let’s just zoom out a little and we will actually notice a middleware ring which every single transaction from our internal and customer facing applications must cross.
This was actually where most of the technical debt resided.
IMPORTANT STUFF #1You work in an enterprise. If you deny your legacy you will have no compentitive advantage over the upcoming new players in the market. You will be destroyed.Leverage on your legacy while removing technical debt instead.
So we started 2016 with getting code out there on several public cloud providers
To just be shut down 3 months later since we were forced back on prem.Management decided to build our own private cloud, so we started reinventing the wheel.
However, we did manage to get into prod by Q3 same year.
IMPORTANT STUFF #2Be smart!
But was it really that the issue?
Step 1: Create segregation through a layer of well defined APIs
Build business logic reusing data on the existing system
Migrate data while migrating to event driven design
We started to define a set of best practices that then, based on input from our experiences in production, turned into a full blown architecture description.
The microservices of course will be inside the network microsegments.
Different applications hitting different domains, as for instance B2B and B2C, or processing of external streams of data hit the enclaves ”above the stream”.Then we have central systems hosting cross functional systems and business logic ”below the stream”.
These systems host complex business logic, committing data continuously and emitting specific enterprise events.
From idea generation to production at Danske Bank you had to factor at leasr 70 days on top of the effort needed to develop and release the application or feature you wanted.
From idea generation to production at Danske Bank you had to factor at leasr 70 days on top of the effort needed to develop and release the application or feature you wanted.