00:00:13

Thank you, Jacob and Daniel. All right. So last year here at DevOps enterprise Europe, all of us were odd and amazed at the presentation from nationwide building society. The largest organization of its kind from Patrick Eldridge, their chief operating officer and Janet Chapman, one of the three mission leaders, they presented on their DevOps journey and how they were able to respond, adapt, and better serve their customers during the worst economic downturn in nearly a century. And I am so delighted that this year we have another team from nationwide presenting. Leanne bridges has spent decades in compliance and is their risk COE lead and the chief product owner for intelligent control. She will be presenting with mark Randell, their DevOps and SRE ways of working consultant. They will be presenting on the challenge that every technologist faces in terms of ensuring security and compliance. I love this talk because it highlights the sometimes absurd hoops that every product team needs to go through when they're trying to do the right thing and what the world could look like. If one actually designs a control environment to truly make it easy, chooses the right things and do the right things, right. And if you think that compliance controls all fit into a continuous delivery pipeline, I know that you'll be blown away too. So here's Leanne and mark.

00:01:35

Hello and welcome. We're here from nationwide building society in the UK. And we're going to talk to you about creating safe and controlled environments where teams can thrive doing DevOps. We'll introduce you to our beloved nationwide building society provide you some context on what drove us into action. And then we'll describe what we did. And of course, most importantly what we learned, but first of all, we'll introduce ourselves. So my name is Leon bridges and I'm the chief product owner for intelligent control at nationwide. I often say that I feel like I've been training for this role for my whole career. Having spent 20 plus years in compliance oversight and assurance roles. What we're building is really what I wish I had when I started out. If you've ever been through a post-incident review or an audit finding, you will know how frustrating it is to have someone tell you that the calls were something really simple, yet overlooked being someone that's told someone that news is just heartbreaking. And it's just so frustrating for everyone. My goal with this work is to really help minimize that failure to support the ongoing assurance and compliance activity in our organization, but also to help my colleagues build good things.

00:02:47

And I'm Mark Randall. And I drive the ways of working experiments that we run into dev ops and site reliability engineering or SRE. But the biggest surprise of this role for me has going from navigating or even fairing controls to really respecting them. And dare I say, loving them. I've learned so much. And the, the, the jargon, the language barrier between Leanne and me at the start was it was immense, but hugely rewarding to, to get over that and what we've built in and what we're sharing is hugely valuable to nationwide. And I think, um, uh, you know, super interesting for, for your organizations as well,

00:03:29

Which makes me really happy because I've always believed that creativity can love constraint and dev ops can love controls.

00:03:38

So nationwide is the world's largest building society and the UK second largest mortgage provider. And one of the UKs largest savings providers, origins line, a company formed in wheelchair in England in 1846. So 175 years ago. But during our long history, we've often been first to market with technology innovations. So we launched the first internet retail banking service in 1997, and then the first mobile banking platform in 2012, we're very proud of our society. And this is this slide highlights many good reasons for that last year. We helped one in six first time buyers buy their own homes and we created a 1 billion pound loan funds to incentivize greener homes. Last year, Patrick Altra Jan, Janet Chapman talked to you about our pivot from functional alignment to the establishment of our long lived business aligned member missions. Our journey of improving ways of working is still progressing brilliantly.

00:04:38

And that's why we're here today. So we're not just going to talk, we're not going to talk to you about why or how to do DevOps. We assume you already have a vision of what, what good looks like and have some pockets of great success. And you're already sure that you want to scale things up. We want to talk to you about creating an environment where teams doing DevOps can thrive and even be reinforced and encouraged by controls. So for that, we need our controls to be appropriate, or you, they must only exist in response to relevant risks. They must be executed via efficient processes that minimize extraneous cognitive load, and they must promote autonomy. Or as we call it a nationwide accountable freedom before we get properly started in our story, we wanted to share a metaphor that we find useful, forget dev ops, forget financial services, forget it just for a second and consider a teenager.

00:05:36

We've all been my months. So adolescents are enthusiastic and ambitious that they're starting to do new things that have greater consequences, like driving a car. And they love to challenge the status quo. And we see a parallel here to teams doing DevOps. They've read the unicorn project. They know there's a better way, perhaps were once the proof of concept, but they're growing up and they've got life services now. And the one does of GDPR and PCI compliance are in scope for their services, but maybe just maybe they, they still feel a bit rebellious when it comes to navigating risks and controls. The guardians of teenagers have a pretty tough, and some might often say thankful thankless task. They're still legally and morally accountable for the teenager, but they're all has to evolve. They know that they need to, and that they need to enable more autonomy for the teenagers to thrive and guardians of teenagers.

00:06:34

One way to conceptualize the risk and control functions that we're talking about. They know agility is essential for business survival. They know streamlined team autonomy as a key enabler, but they still have to preserve safety. And in the case of a regulated industry like banking, this is to retain the license to remain in business. So this is a time for empathy and understanding, and maybe even a time for some family values within organizations. So our story begins a few years ago, we had a rigorous, standardized compliant, controlled project delivery methodology. It was very safe, but it was slow. And it certainly wasn't suited to regular software releases. So we experimented with new ways of working and had some great early agile successes. Some of which you had of about here at this DevOps enterprise summit, back in 2019, Jen milestone and Richard James presented all about this. So we've evolved our project methodology into what we call our adaptive change framework. And it was designed to enable right-size standardization of, of delivery processes, but we couldn't take high risks around this. And as far as the expression goes, throwing out some wine with the cork was, was not an option.

00:07:56

So what effectively happened was the, our, our tight controls persisted, and seemingly seemingly they even multiply to, to, to perhaps overcompensate for some of the freedoms that we tried to create teams looking to deliver changes, cause sometimes find themselves navigating 30 different control processes collectively containing over 2000 controls. And I feel like a drunkness, but I swear back in 2019, at one point I saw a guard rail that someone had created and stuck to a whiteboard describing how to use it properly. So it was clear that we needed to react to this. And that's where the idea of intelligent control came in. And I'm going to hand over to, Leon's talk about this.

00:08:41

Thanks mark. I thought I'd take the opportunity first to frame controls. Sometimes it can feel quite jargonistic and unique to financial services, but I've worked across a number of sectors and in each of them, they've all sought to do the same thing or be in with different names. Each of them ultimately controls are the must do, and they should do things. They support accuracy, consistency, repeatability, traceability, transparency, and all of those other good things that you expect in any regulated sector. That also what is relied upon by those with specific accountabilities in financial services, we've got something called the senior manager's regime. They had delegated accountabilities to specific and named individuals. So we need to ensure that the processes that those people are accountable for, but also the processes that our members depend upon run effectively and run as you'd expect them to. So whichever sector you come from, whichever industry you represent, you'll be familiar with control in some way, shape or form.

00:09:39

So the need for control arises. When we identify risk conventionally, this would have been done within a risk management life cycle, or at some point in, and particularly in a kind of project management lifecycle, somewhere in that project delivery, um, timeline, usually it's a bit of a one and done. So you'd assess risk at one point, and then you wouldn't do anything else until audit oversight, assurance, quality management, or whoever comes along and tells you that what you've built isn't good enough. And then you get issues that need to be resolved that consume energy and resource to put things right. I've a lot of lived experience, uh, this resulted in masses of rework. So I've seen many times over what happens when you assess risk at the wrong point in the timeline when you have that kind of almost stop stop. So sometimes I've heard this referenced as a series of false summits, just when you think that you've understood your risk and managed it, you're told that that was just some of the risks.

00:10:33

You've only assessed security risk, for example, early on in a process. And then as the process kind of evolves and moves through you learn that there are these other different control processes that mark referenced that's frustrating. Rework is expensive and it's, time-consuming, it's also, as I say, some frustrating thing is the worst kind of conversation for somebody like me to have to have with the delivery team because delivery teams want to deliver stuff. They want to get stuff done. And so if we can ensure that they're fully informed upfront with as much of the requirements as they need through that development life cycle, we can ensure that we build the right thing in the right way. If we can move on to the next slide, please, we developed a solution and we worked with some folks that you'll know and love, including John smart and the sooner safer, happier team.

00:11:21

We recognized early that a key challenge was getting the right people close enough to the work at the right time. This is what we started to call intelligent control. It's about us seeking to take the right approach, a considered approach to understanding risk and understanding control or the right point in development journeys. It was about us bringing together the right people so that we could facilitate that collaboration to achieve the right outcome sooner and safer. Some call it agile risk management, others call it, um, different aspects of kind of lean control or other, but however we frame it, the intent is very much to understand what you're dealing with before you set out on the journey like those false summits, you wouldn't navigate a landscape without understanding where you're going on, the journey you're going on in the equipment. You need to get you there.

00:12:07

Controls are very much that. And so understanding as much as you can upfront enables you the kind of most impediment free journey as possible as you move forward. So we saw an opportunity to streamline the way that we assess risk is that kind of first entry point. We knew that each of our risk owners, each of those senior managers for the senior manager regime with the accountability, each had an individual risk assessment. In some cases that would involve a product team delivering up to 12 different risk assessment activities. And again, it's time consuming and again is cumbersome. So we sought to streamline that and simplify. And we created something that we call the unified risk assessment that enables us to just bring all of those different risk criteria together so that we can assess risk once and then fully informed had that holistic view of the control required to build the right thing and build the thing. Right?

00:12:59

And so we also recognize that we needed to align with the way in which developers work. And so we started to create user stories or what we call control stories. The key thing here though, is to understand why you need them in the first place. And one of the real smart points that came through in this work is we've kind of codifies the outcome of a unified risk assessment to inform the controls that we need. We've created a lineage between the outcome of the risk assessment and the control stories, which means there's absolute clarity. The muster we should do this helps us to prioritize. So if you can only invest in one of those controls, which one do you choose and what does that mean for our risk position? And it also starts to provide us with a metric. So the extent of the control, which is embedded by design is known it's quite foundational and basic, but it gives us really good clarity across each of the different products that we deliver and serve.

00:13:57

So it was pretty simple for us really, if we consolidated the risk assessment so that it gets completed once we can iterate thereafter, it means that we can enable that kind of addition to the backlog, but also then that, that kind of alignment or integration with a continuous improvement loop. And that was where it got really smart because it started to give us the data that enables us some of that kind of continuous compliance, monitoring, or continuous assurance activity. It also enables us to give a Sheeran's at that minimum viable control, having been operational before we're asked to approve a release. So it starts to move us away from reactive and to what that kind of proactive or preemptive view of understanding if a product or service is safe for release before we get to the end, before we get to that kind of pressure point of time, um, when we've run out of time in terms of being able to prove that out, it's also continuous.

00:14:49

And so it's something that we cyclically over and over again. So rather than it be that kind of one and done instead, this becomes part of that, that kind of linear narrative. So this is continuous. Um, so as the product evolves and iterates, the risk position can be continuously adjusted, controls are introduced to retard is required, and we're able to persistently align and persistently integrate with that continuous improvement lifecycle. So you may recognize some or all of this in the context of the ways that you work. I advocate is a mechanism to understand the risk that you manage every day is hugely important for product owners is hugely important for those with accountability, but it also really helps to underpin some of the kind of assurance the attestation, the compliance activity that you at some stage will, will need to undertake if we can jump on to the next slide.

00:15:43

So this is really one of our dashboards and the reason I've included this is just to give you a flavor of how we're able to provide that informedness to those products owners, to, to those, with accountability, we can align these to suit the different aspects of the extent to which control is embedded, but we can also start to pull in where we've got controls, which are automated. We can pull those into that dashboard and enable that visibility also is hugely important because you can also drill through. And so you can start to understand why is that green? Why is that not green? What are we going to get to that position that we need to? So it's really useful for auditors and overseers and testing teams, um, compliance and assurance and all of those different things to support both. That's a station to regulate through an industry bodies, but also in response to things when things go wrong. So if you've got a post-incident review and inquiry or even legal proceedings, this can be super valuable because you're able to provide that traceability and the evidentiary putty back to the point in time when risk was considered, decisions were made about the controls that you invested in. And that for me is really key as someone who's spent kind of 20 plus years working around audit oversight and compliance that traceability of compliance, that proof point and the provability that the right decisions were made by the right people is incredibly important.

00:17:03

Next slide. Thank you. And so really this is a journey for us. Um, I'm not going to sit here and say that we're in the best place and we've, we're finished and everything's great. It's very much a learning journey, and we're very much on that journey. Um, mobilizing this activity is an easy product teams, get the shivers when risks quick, turn up and risk broker, usually a real long way away from the actual work that gets done. I see intelligent control is a mechanism by which we bridge that gap, but how we bring together those two different parts of the organization in two different kind of mindsets of people. And that's where a lot of this work has been about facilitating that right kind of collaboration. So we can bring the right people together at the right time, so that the outcomes that we're seeking are met and understood where we've got risk in the thing that we're going to do.

00:17:50

And a lot of the stuff that we do around technology particularly brings risk. It has risk in her and in it, we can't get away from risk. And so it's about how we manage it. It's about how we remove the fear from the work that we do, because we bring it into a scheme of management through the risk and control activity that we have. This isn't all that we learned though. We also found that one of the things, when we stopped in challenged, why we're doing some of the things that we're doing, we didn't need to do them anymore. Sometimes this was a legacy or a hangover from a previous audit previous incident, some something that had gone wrong at some stage in the past, but sometimes it was just because things have moved on it moved on, but we were so beholden to the control activity that we stuck with.

00:18:31

It we've uncovered examples of genuine waste rework and unnecessary spend, but we've also uncovered some pockets of some folk doing some really great work, attempting something similar to intelligent control. And then by us almost being able to kind of amplify or connect their already good work with other already good work, it made a huge different is it really kind of enabled us to start to bring forward that good practice, but join the dots so that we were able to kind of amplify the value that it created. One of the key things there was that we always needed to uncover the Providence of the controls so that we could help others agree, which ones were needed and continue to have value. One thing we didn't find was lots of paperwork, almost worse was we found loads of different tools. Um, if you've worked anywhere near financial services, you will know that they're already a myriad of Excel spreadsheets everywhere you go.

00:19:22

There are varying levels of sophistication and lots of different elements of access that kind of siloed approach to control management was further siloed through the way in which tooling was used to record some of those outcomes, which means a huge amount of duplication. It means a huge amount of rework just in some of that, um, activity that sits behind, but pulling this work into one space. And so you'll have seen on the slides earlier, we use JIRA to facilitate the control story. We use ThoughtSpot to facilitate those outfits by streamlining and simplifying that pipeline for us, made a huge difference in terms of how we can enable visibility and how we can enable visibility for the right people at the right time.

00:20:06

We found also that you can work hard to clarify what you're doing around intelligent controls, but it still wouldn't be enough. Um, we needed to re baseline more than once to ensure that folk had consistency in their understanding. Uh, everyone will still have their own ideas about what it means. So we, we go through all kinds of different aspects of myth-busting and other, but we found that that kind of regular bite-sized communication being clear in our messaging from the get-go, but also being persistent in how we, how we share that message. So we have a regular monthly demo, which is really well attended, and it's always really heartening for me to see people from the top of the organization all the way down through we work the basis of invoice over inflect and therefore a door's always open. And we had these kinds of very open and public showcases.

00:20:53

And I think bringing that kind of real lived experience and those real life stories enable other people to see the value in terms of what we're doing and enable them to kind of get over some aspects of that fear of different and that fear of change. So it enables them to really start to adopt. This is a different mechanism of doing that work, but for all of our good intentions, this has changed and changes unsafe to, to people that empowerment can be threatening to teams who haven't experienced it before. And we find that sometimes people find rural comfort in living a really tightly controlled space being told what to do and when to do it and how to do it, and whether or not that was good enough sometimes can feel quite comfortable, particularly if it's an environment or a situation that you're uncertain or so it's important for us to take time to support people. And we found that enabling people through that change curve is really key. And again, that referenced back to the reliance on community, on communication and the education and training. We created something that we call the icy academy, the intelligent control academy, and it's a huge online learning resource. And again, we use that then to, to bank down those demos and the different book passing constant we facilitate and provide so that we've got that persistent and enduring reference Monica handover to you.

00:22:16

Thanks, Dan. So another interesting finding was that sometimes we discovered the, the challenge or rather the opportunity lay in the processes the teams have chosen to follow, uh, not actually the letter, the controls. So for example, some teams were already eligible to deploy their code to production as pre-approved changes, but they are simply unaware how to do this. And one final learning is quite simple. One, which is, which is the name, the name intelligent control didn't always work out so well for us. So in our heads, the words intelligent, referred to intelligently allocating controls, but in some people's heads, it sounded like we thought that controls or worse, they were unintelligent. It even sounded like a, to some people that was talking about some kind of AI or machine learning marketecture type thing. So lean control is proving a bit more of a popular name. And I think even the sooner, safer, happier authors are considering centering that for future additions of that book.

00:23:17

So in terms of the future of this field, we feel like control has a lot to learn by following more closely in the footsteps of DevSecOps. For example, building on our control stories and implementing automated tests for control validation in the CIC D pipeline. And we've already started exploring inner sourcing and, and reuse of control tests in this way. I'm not trying to start the latest portmanteau here, but if I would, it would definitely be called dev control ops. And then, and that is pretty exciting. If you are taking steps yourselves to around holistic views of control and security, or are doing anything similar to this, we would love to talk to you.

00:24:00

So in conclusion, creativity can love constraints and DevOps can love controls. I liken this to living in a shared house. You can do what you love in your room, but you need to respect the boundaries of that room and the people that you live with. If you're going to impact them, you need to communicate, collaborate and find the right outcome for everybody. Sometimes that might mean not doing something. And sometimes you just have to be cool with that because if your colleagues telling you, no, it's not because they want to ruin your party. It's because that's the right thing to create their safe environment for everybody. This is where empathy and that constant focus on a shared goal is so important. If we're working together, if we're working as a family, we're going to ride that rollercoaster of change together, and we're going to get to the right place.

00:24:42

In the end. This work is really powerful by simplifying and streamlining the controls that we operate in the way in which we embed them by design. And by default into the work that we do makes a huge difference. I've had over 20 years experience of compliance and assurance and oversight. And so if the outcome of this work were available to me, it would save me such a huge amount of time. Um, it would make such a difference to the way in which you're able to focus on the things that really matter, and the things that really warrant the attention to ensure that we're doing the right thing for us. It nationwide, that's the right thing by our bar members. Ultimately, the goal of this work is to enable our colleagues like mark, to thrive, doing DevOps, to not be the impediment for them, but instead be part of the pathway. But I know there will never be finished. There is no path degree or no kind of end point. Instead, this is very much about us staying connected, working together to continuously deliver safe value. So that was everything I wanted to share with you today. Thank you.

00:25:49

Thanks.