- 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.
Dont like the phrase "cloud platforms" in this context. And which (kind of) patterns, policies and processes are we talking about. I will explain …
Want to work with tech in DNB?
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:
- In the cloud, event/async patterns are often better to decouple our domains than synchronous APIs. This allows us to take full advantage of more efficient and resilient cloud patterns, and also open for future business innovation through pub/sub mechanisms and potential for proactive business led responses to customer events.
- Just because you can do it yourself in the cloud, doesn’t mean everyone should! Our pioneers into the cloud helped establish initial patterns, governance, tooling and learnt an immense amount in each DevOps team. This experience is invaluable, but in a world of Infra-as-code, doesn’t need to be replicated in all teams who may not wish to acquire and maintain all these competences. This is why we now implement PlatformOps as a paved road, to expedite and scale our DevOps teams and allow them to focus on other priorities.
- Finally, we increasingly see limitations with traditional analytical data warehouse models as we implement the three principles. Central to this is the need to converge how we handle operational and analytical data within a decentralised domain model. Here we have begun piloting data mesh patterns to make data more accessible and real-time
Lots of exiting activities coming to the blog soon!