- Richard Attlee
As the old joke goes: “How do you eat an elephant?” Answer: “In small pieces”.
This applies when we modernise DNB’s legacy technology, where we have great business value in what we deliver today (legacy in the positive sense of the word), but often not how we do it technically (legacy in the negative sense – and often how we use the term in IT).
Our challenge is to build upon the positive aspects of our legacy, while we stepwise address the need to modernise the negative or restrictive aspects of our tech that can constrain our future business ambitions. Here we have three key principles (following leaders who have gone before us).
Principle one – Domain Driven Architecture
Principle one is the small pieces, in our world we call these domains and we follow an approach of domain driven design.
This means creating (or in most cases, carving-out) independent service domains, fully controlling their own data and clearly defining how they interact with the rest of the ecosystem by their integrations (REST APIs and event based messaging).
This means that they are designed to be bounded contexts and independently deployable. Although aligned to “micro-service” thinking, our domains can be realised internally in different ways and are set to a size that adds value for the bank (micro, medio or macro, but all bounded). The value here being effectiveness and agility. The effectiveness is about balancing business composability and technical complexity, which I won’t go into here, but agility brings us onto the second principle …
Principle two – DevOps teams
For us this means we have joint change and run teams that deliver one or more of these service domains end-to-end. These DevOps teams, have stable resourcing and are responsible for developing and improving their service domain(s).
This continuity in team members ensures we have strong ownership and long-term thinking for how to develop the service domains over time. Their agility is supported by automation where the teams automate system lifecycle management with processes and tooling to improve development and feedback loops to/from operational performance with CI/CD.
Principle three – Cloud
We use AWS and Azure to ensure these DevOps teams are independent and agile. This reduces teams’ dependence on central infrastructure teams and legacy change processes (legacy in the negative sense 😉).
Here we automate the patterns, policies and processes as code in the cloud. So teams can self-service and manage their own infrastructure and platform services. Teams, and the bank further benefit from cloud scaling and access to the innovative services. While avoiding the disruption and expense of periodic tech refreshes on-prem.…
Where are we on the journey?
We are well on the way, but there is much elephant left to eat. Our first phase started in 2017–2020, where we modernised our mobile channels following the three principles above (DDD, DevOps, Cloud).
We did this while encapsulating the backend technology behind a common API layer, but leaving this legacy largely intact. From 2020–22, we rolled out DevOps to all teams and continued to move our web customer channels and open-banking APIs to the cloud.
In addition, we began the more complex work of decoupling and modernising the systems supporting our key products and business processes. Here we continue to follow the three key principles with our payments, customer and general ledger modernisations.
In 2023 we intend to further accelerate modernisation with additional domains and grow our DevOps teams with more engineers.
We learn and adjust
We also try to learn and adjust as we progress, below are a few examples:
Lots of exiting activities coming to the blog soon!