Raj Fowler

Hello, everyone. I'm Raj Fowler, and I'm joined today by Sergio Pereira-Lopes and Matt Stokes.

We all know that transforming a bank-wide critical dependency into a platform service is no mean feat. Well, that's exactly what NatWest have done to their identity service, embracing DevOps principles and taking their strategy, organization, culture, ways of working, and technology through a paradigm shift.

NatWest are now one step closer to achieving their ambitions of being a relationship bank in a digital world, enabled through a simple, safe and smart identity service. And Serge is going to take us through how that happened.

Sergio Pereira-Lopes

Thank you, Raj.

So what vision did we have? We really set out our transformation journey to understand how IAM self-service can unlock productivity and value across our organization. And that was really through focusing on automation and focusing on changing or transforming our operating model to enable self-service.

That then would contribute to making NatWest a simpler, safer, and smarter relationship bank in a digital world.

The focus for us within identity services was about reducing waiting times for our consumers, automating and deploying automated deployments through testing, organizing our organization to be centered around value and delivering value for our customer, and improving feedback loops, both internally within our organization and externally with our consumers.

NatWest Group, or Identity Services within NatWest Group, services around three million actual banking consumers through multiple different channels, and 25,000 colleagues all working in different locations.

We provide identity services across all NatWest products and technologies, therefore making it a critical service to our bank to enable value.

Each one of our services required manual onboarding. So each application that required our services required someone to go in and manually update configurations.

Each application, or each onboarding, was treated as a project, an independent project itself, which really brought about a project mindset within our organization.

Off the back of this, we were seeing huge constraints in innovation and also our ability to keep up with technology remediation. We were building up legacy infrastructure every time we were building.

So what did our world look like?

We had a huge backlog and different ways of demand entering our system of work, be it through email, be it through a conversation with a developer in our organization, or in some cases, even a conversation at a lift.

Those conversations in regards to the backlog were accumulating into a huge timeframe for assessment, so understanding the customer requirements was becoming difficult and was growing. Each item in our backlog required an independent assessment phase. Therefore, it was becoming increasingly unsustainable for our architecture or solution architecture community to keep up.

This translated into our development teams and community who were building bespoke solutions for projects or different parts of the organization, and that was bringing about a huge amount of escalation because the capacity within the teams was not there to service the demand that we had and the requirement.

Testing was becoming a bottleneck and an issue within our organization as each solution required its bespoke testing approach, and that accumulated in a saturation of our testing environments and our testing teams, which slowed down the delivery life cycles.

Releasing into production and actually delivering value within our organization became a problem as we weren't able to release the value quick enough in regards to the demand. The context switching across the different teams meant that this was slowing down release, and we weren't able to release into production at a rate that we were receiving demand in through our front door.

Our operating model and the way that we were working was disparate, and we didn't know who was doing what at what time for our consumers. This was accumulating into high cost of delivery for our consumers. On average, it was roughly around £15,000 to £30,000 to onboard the IAM capability onto an application. With the backlog of 80, that accumulated into a £3 million wastage of delivery investment.

Effort to deliver into production was exceeding over 20 days. Therefore, actually implementing value to the customer was being slowed down, and even before that, the ability to get onto our backlog and prioritize the work into our organization was taking up to 90 days. Therefore, even from idea to value, to even have that conversation was taking three months.

So effectively, we had to change the way that we approached the work and approached the way that we were doing things today.

We still have, within our organization, a 60% supported model, the one that I just described before. But we have been able to transform our organization to a more self-service model. So effectively, turning our organization into a self-service restaurant as opposed to an à la carte restaurant.

This basically meant that we could focus on patterns, and we could focus on repeatable, reusable adoption processes, which, in essence, enabled our customer, instead of having a menu that had 60 items, we reduced that menu down to three or four concise things that our consumers really needed and they could use.

We removed bespoke solutions and went on to patternized solutions. We automated the process. We created technology that orchestrated our journey in line with the customer needs.

We used metrics to drive decisions. We reduced and understood our work in progress and the demand that we were getting through the front door. That enabled teams to experiment through the system of work, understand the system of work and the constraints within it, and process-improve on that journey of developing value to our customers.

In essence, what we wanted to do, we wanted to become the identity services McDonald's: provide good quality food at a reasonable price, at a time that suits the consumers.

We now provide identity services at a reasonable price, at a time that suits the consumer, and solutions that enable value as quickly as possible. The effect of that is reduced cost to the organization. It's also reduced the effort it takes to onboard identity solutions into the organization. And the lead time on demand has reduced significantly because our consumers can now enter the IAM buffet as opposed to having to wait at the restaurant.

I'll hand over to Matt, who will explain a little bit more in detail around the technology that we used and built that enabled the success that we're seeing through our self-service harness. Matt.

Matt Stokes

Thank you, Sergio.

So I'm going to run through, at a very high level, one of the technical solutions that we built to help get to this outcome.

So we affectionately call this one the IAM Robot. And it was important that we built this one using the existing ecosystem of tools that we have available in the bank, as well as any shared services that are provided and are available to us.

For the IAM Robot, we need to follow DevOps best practices for all of the components in here, as well as the theory of constraints, to make sure that we are controlling this configuration on each of the platforms that we're automating.

We want to encapsulate those patterns that Sergio was talking about a second ago. So where that very specific IAM knowledge and an understanding of the technicalities of the platform is, we want to encapsulate that and abstract that away from the user who's trying to onboard their application.

We want all of the good things that you expect when you're doing configuration management. So we want you to be able to declaratively define your application. The user should just declaratively define some data that describes the application, and we want that to be idempotently applied to the platform so that we aren't bombarding our servers with requests, and we don't have to worry about cluster replication when we make some call that wasn't needed. And we want to make sure that any inputs to this tool are validated early and continuously, whether that be the patterns themselves or the configuration that's coming in from the user trying to onboard. So they need to validate early and all the way through the lifecycle to get to production.

If we look at the diagram on the right here, at the top, we have some very important concepts in the robot. Firstly, we have the pattern definition, and secondly, the app-specific config. At this level, we'll be using Ansible, which we have available in the bank. The pattern definition is essentially just going to be an Ansible task list that describes how to stamp out this pattern on the IAM platform. That can use various variables that might come in from the application config or other sources.

If we jump very quickly to the bottom of the diagram, we have the IAM Robot modules. Here we're using Python. We're using Python because we can integrate it with Ansible very easily. This will provide utilities that the pattern definer might use for various different outcomes in their pattern. But more importantly, it will also provide the API clients that are needed to talk to the platforms that we might need to onboard an application.

Now, if we get to the middle part, this is the part that's actually going to be consuming all of these components. At the top there, we have the orchestrator. This uses TeamCity to pull together all of these components at runtime and put them in the correct place and set them all up so that we have everything available that we need to do a deployment to any given environment on the route to production. It has an understanding of all of the environments on the way there, and it has an understanding of how, where, and why these components are stored in immutable artifacts in Artifactory so that it can retrieve them and set them up properly.

Then it passes on to the configuration manager part of the tool. This is essentially the Ansible that we were talking about. We trigger Ansible with some specific setup for this use case. That Ansible basically merges all of the config that might come in from the user, in this case, which will just be YAML key values. So it's pure data coming in from the user trying to onboard their app. It will merge all of that at various levels of specificity. There might be some values that you want applied globally. There might be some that should only apply to a given environment.

It sets all of that up, and then it gets into the pattern definition and triggers that task list so that we are actually now onboarding the application following this pattern template. This will call through to any of the modules that we have defined that they want to use. So the API clients, in this case, to actually deploy to the PingFederate and PingAccess servers that we're using in this identity and access management platform.

Then it will use some of those modules to produce reports and logs, all of which also get stored up in Artifactory so that we can track what's going on through this tool.

I'll hand back to Sergio now so he can go through some of the cultural changes that happen along with this technical solution.

Sergio Pereira-Lopes

Excellent. Thank you, Matt.

With technology changes, there inevitably needs to be a cultural change and mindset shift. We're very conscious of this within identity services in NatWest, and we focused on three main areas.

We really wanted the team to change the mindset from a project delivery mindset to a more product-based delivery operating model. This enabled our engineers and our community to really think that IAM capabilities are infinite, and they need to be built as such. Previously, we were built within time frames. Now we build capabilities for the long term, ensuring that we're building value for our consumers consistently.

We also wanted to foster a culture of process improvement that enabled us to basically transition the mindset to ensuring that our capabilities have longevity, and to ensure that actually we could demonstrate that we were better today than we were yesterday, which inevitably will put us in a great stead for the outer years.

We used metrics for decision-making. We understood the demand that were coming in, we understood the system of work that we were working through, and we succinctly went through the constraints that we were finding, and still are. But we used the data, and we used the metrics to drive those decisions and understand where we can best deliver value for our consumers, as opposed to it being a perception game of a project manager or a head of technology.

So what was the impact?

The impact really was focused around being simpler, safer, and smarter within identity services in NatWest.

By simple, we standardized, and we made the onboarding process predictable. Therefore, our consumers understood what they were getting and when they were getting it, and they could plan for that.

We wanted a true self-service model which removed dependencies of delivery off IAM specialism and back onto the application teams. And we automated and made that a much safer environment for our consumers to use.

We wanted to be smarter by increasing our ability to generate innovation, ensuring that our capabilities could be built for future use, but also keeping up with market pace and ensuring we've got the right identity solutions for our customers in the long term, which inevitably builds a safer banking environment for our consumers.

The benefits and values we adhere to within NatWest bank are to ensure that we're inclusive, curious, robust, sustainable, and ambitious.

By inclusive, we've changed the way that we deliver our capabilities and put the control within the application team's gift, as opposed to them having a dependency on us, which enabled a much better engineering working environment across the bank. Therefore, IAM is now inclusive in delivery as opposed to it being a bespoke service.

Curious: we wanted to keep pace with innovation, and we enabled that with the capacity that we brought within the teams by streamlining our processes and ensuring that we've got self-service, which brought capacity within the team to be innovative and also ensure that process improvements was at the front of their minds when developing solutions.

Robust: we now have the capacity to actually invest in our infrastructure, make sure it's resilient, and also improve our service offerings for our consumers.

Sustainable: we reduce cost. We're continually reducing cost and delivery timelines for our consumers. Therefore, we're delivering value to our customer quicker, and we can pivot to market reactions if required for our identity services.

Ambitious: in my mind, we need to get to a 90% self-service capability model for identity services. Therefore, building our capabilities with self-service in mind is at the forefront. We want zero downtime deployments. Therefore, our consumers can use our environments, deploy into production without having a constraint on having identity services available.

And we want the wait times to go down. So we want to get to a five-day deployment into production average, and that will ensure that consumers can deliver smarter, faster.

Some key metrics that were driven out of what we've done so far: we've been able to see a 40% self-service journey. But even with that 40%, we've seen a 70% reduction in IAM effort, i.e. our teams, therefore increasing capacity to focus on things like innovation and process improvements and resiliency of our platform.

We've seen a 65% increase in customer and employee satisfaction. Our customers are getting what they need quicker, easier, and smarter.

70% reduction in the backlog we're seeing. Therefore, actually the throughput and velocity of what we're delivering is improving.

All this has been done in a reasonably short space of time, but the metrics show the value that it brings to our organization and our consumers.

When asking what our customers need and when they need it, the biggest feedback that we've had is that we're now able to deliver a service that meets their needs rather than building a service that we think they need. And that's really at the forefront of what we're trying to transition to.

So what help do I need for the future? How can you guys help me? I think really a further understanding in the cloud infrastructure and how that can improve automated self-service journeys. That would be very beneficial. We're going through a transformation at the moment to try and understand that cloud journey.

I think understanding internal cost models on how we actually demonstrate the cost of delivery, that would be useful for us, and how to influence the mindset across the whole organization, top to bottom, and demonstrating how this really can take us forward is really where I would ask for help from this community.

Thank you for listening to myself. I'll hand over to Raj. Thank you.

Raj Fowler

Thanks, Serge. Thanks, Matt. That was very informative and hopefully helpful to the audience.

I really like the restaurant analogy. For those of you who've watched Gordon Ramsay's Kitchen Nightmares, we've had a bit of that journey: picking up a restaurant that had a massive queue out the door, people waiting to be seated, different stages of their meal, not knowing what the menu was, creating their own meals, kitchen staff running around with their hair on fire, waiters not sure which table to work on next, ultimately leading to only three customers paying the bill each month despite the restaurant being jam-packed.

I think most people probably identify their platform service in that state at the moment, and transitioning that from a kind of à la carte Michelin restaurant to really understanding what the customers need. They didn't need the Michelin star. They didn't need à la carte. They just needed to understand what was on the menu, how what they wanted fitted with the menu, and to be able to service that themselves in that kind of McDonald's style, Subway-style kind of model.

And moving so much of the workload and transitioning the mindset and the organization and enabling technology to kind of enable that fast-flow, self-service model in a safe and controlled way, in a regulated environment, has been outstanding.

For anybody who's been to a McDonald's or anything like that, Burger King recently, with the little touchscreens and going through that seamless end-to-end flow and the kitchens and everything being organized for that fast, effective delivery of consistent value, consistent food, it is exactly what's been done here.

And that ambition to get to 90% plus and focus on innovation like multi-factor authentication and digital identity and stuff like that, it is really then driving identity services forward and ultimately driving that relationship component of NatWest wanting to become a relationship bank in the digital world.

So hopefully that was really useful for everyone, and thank you for listening.