Connecting Software Delivery to Business Outcomes: The Epic Balance of Moving Faster and Safer while Reducing Risk (Europe 2021)

Welcome to our world where software applications are the critical driver of business performance. Every moment, business is won or lost based on the software we deliver to our customers. And the demands of the customer are ever growing. That’s why companies across all industries are prioritizing software delivery to get better, more secure and compliant software to their customers faster. Nationwide Building Society is in the midst of an Agile transformation, driven by an exciting DevOps strategy. This strategy is enabling the secure delivery of new capabilities to ensure customer needs can be met faster, while meeting the compliance requirements necessary in a highly-regulated industry. Balancing developer innovation and autonomy with governance and compliance guardrails hasn’t been easy though. While their journey continues, Nationwide has made considerable progress, creating a modern, best in class software delivery architecture and culture, ensuring customer need is always front of mind. The need for speed is proportional to the need for safety. So, how do you deliver new capabilities to customers faster without compromising security? How do you adapt existing DevOps workflows to assure governance and compliance? How do you deliver consistent value? In this talk, Sacha Labourey, Chief Strategy Officer at CloudBees; Ben Angell, DevOps Engineering Lead, and Sanmat Jhanjhari, DevOps Lead at Nationwide will discuss the path they’ve taken and the lessons they’ve learned along the way. This session is presented by CloudBees.


Sacha Labourey

Chief Strategy Officer, CloudBees


Sanmat Jhanjhari

DevOps Lead, Nationwide Building Society


Ben Angell

DevOps Engineering Lead, Nationwide Building Society



Welcome everybody to DevOps enterprise summit, I'm CloudBees chief strategy officer. And today we're going to be talking about this challenge that organizations frequently have on one hand, they want to go fast, but on the other, they want to go with safe and have peace of mind. So how do you handle those two challenges? So to talk about this today, I have with me Ben Joel, head of dev ops engineering, head Oban, Sasha, and I have son Matt, the Genji dev ops lead and our son, Matt. All right. So, so Boz Ben on some math work for nationwide building society. So if you live outside of the UK, you might or might not have heard of nationwide, but if you live in the UK, there is absolutely no question that you have heard about nationwide. It's a, it's a real east Oracle institution. So Ben, can you tell us more about nationwide?


Yep, certainly. Uh, thanks, Sasha. Um, I'm sure people have heard of nationwide building society, uh, if you're based in the UK, but just as a quick recap, it's a financial services organization. Uh, it's a mutual organization, which means we don't have shareholders. Our members, our customers are essentially the, uh, the, the people who, uh, are the shareholders of the organization. Uh, we sell a variety of financial services products, so mortgages, credit cards, loans, et cetera. And we have about, I think, 15 million customers or members, uh, up and down the country. Uh, we employ about 18,000 people based, uh, right across the UK. Uh, and we have some tech hubs, uh, in London and in the Southwest of England, uh, in Swindon. Uh, so I guess the most exciting thing about, uh, nationwide at the moment is we've just started to look at the future of work, uh, in terms of, uh, how we employ people, where our teams are located, how we, uh, uh, enable those, um, employees to work as effectively as we possibly can. That's really, really good for me as an engineering manager is on, uh, building my function, building the engineering function, because it enables us to really reach out across the UK and select the best engineers we can possibly find and not be constrained by geographical limitations.


That's great. And so as part of nationwide, tell us more about your responsibilities there then.


Yeah, so I'm the, um, I lead the CICB platform, uh, engineering capability team, and I guess I got to take it back, uh, a bit, so we've got a, I've got a very big engineering function, as you can imagine. Uh, and we're always looking at how we can be more, um, uh, more efficient, um, embed, deeper controls into the way we work. Uh, we are very reflective of, you know, of how we operate and we've long realized that we really can, can adopt DevOps, methodologies and exploits CIC D um, to enable us to give better service back to our, our customers, our members. Uh, so, uh, I'm tasked with building the CICB function, the platform team, um, the engineering platform team, which is going to enable us to build the right CIC D solutions, um, to enable our broader business area to our engineers who are based across our business areas to deliver really good, effective pipelines, safe and controlled pipelines. So, so lots of work, um, very, very busy, um, really interesting stuff actually, and, uh, actually quite exciting as well because we can already see some real benefits of working in this way.


All right. That's great. Thanks, Ben. So what about you said that,


Yeah. Hi, um, I'm hands-on DevOps practitioner and leading the team of dev ops engineer. And the responsibility is about the designing building and optimizing the tooling. That's reserved for the enterprise customers and the, that enabled us to put our customers in a position where they can build that pipeline pipelines in a more with a greater confidence.


Alright, thank you so much. So, as I was saying, it's introduction a few minutes ago today. What we want to talk about is really this challenge that most. And when I say most, I actually mean organization are going through at one point, which is you have released this initial push that all organizations have to increase their velocity, increase the pace at which they get really software. They want to go faster. Um, and that's great. It creates a lot of energy. It's a positive change and they start typically creating a lot more value. Um, but I think start to pick up the resist realizations that comes that is, this needs to be managed essentially, essentially there needs to be kind of another whole framework. Does that make sure that going fast, that does not happen at the expense of going safe, right. That is anything from secure compliant and so on. So lots of constraints on, on businesses, especially in the financial industry. Right. And so how do you manage those two worlds and is that even possible? Can you get those that are Citi and peace of mind? So that's what we're going to be covering today. So Ben yours, uh, go fast person in, in, in, in that story. So, uh, when did this journey to go fast, started at nationwide?


Uh, yeah, so I guess it was probably mid 2018 or early 2018. So a few years ago now where we had a number of really critical services. Uh that's uh, we knew, uh, underwent high levels of change, high cadence of change. Uh, and, um, but we're heavily regulated like all financial service products are. So we, we started to look at Pathfinder activity, so, so understand how we can manage the CGI elements of CIC D um, perhaps more efficiently. And that was really, really successful. It was, uh, showed us very early, um, what could be done, what could be achieved in terms of automating our pipelines, um, what we could use in terms of tooling and a new guard, rails, and processes and controls to embed, you know, really, really good compliance, continuous compliance, right the way through the CGI, uh, journey. So that, that enabled us to show back to our broader, um, engineering community and, and our wider business areas, uh, what could be achieved by adopting DevOps methodologies and being more agile and, uh, you know, using proper CIC D uh, solutions.


So that was a part of finder and really to give us that credibility and to show what could be achieved. We've gone on from there and started to build out lots of these solutions as enterprise, so they can be scaled, uh, become available to the broader engineering community and start to see those benefits, uh, happen across the wider organization. So that's pretty much, um, I guess in a nutshell where it started early 2018, uh, until now, uh, we've gone through the Pathfinder proving phase. We, we, we now know this is the right thing to do for our organization and we're in scale-up mode as we speak.


All right. That's great. We, we here's this, uh, this quite a bit, actually this notion of Pathfinders that makes it possible to discover out of what we all know about software delivery and dev ops as might, you know, might be the best practices, but how does that apply specifically to your organization? Every organization is going to be slightly different. So that's, that's very powerful. Um, and so you, you were saying a few minutes ago is that nationwide is perceived as this, uh, quote unquote old and venerable institution, but, um, at first sight, you know, if you're a developer, is that might not be where intuitively you would think, oh yeah, I'm going to go out nationwide. And I'm going to have fun with software. I'm going to use modern tools and practices, and yet that's exactly what you're doing. And you just describe how you initiate it, that does that deep transformation. So how do you work to change that perception, for example, in terms of recruitment and so on to, to make sure you get, to find the persons that wants to join that, uh, that revolution within nationwide.


Good question. I mean, we are a very, a very open, vulnerable, um, organization, and we have a very low risk appetite as all financial services organizations do, and we're not going to compromise on that. So certainly the work we're doing, uh, is about embedding further control in the way that we operate, but enabling us to go faster, to automate a lot of the processes that we have. I think there is a perception perhaps incorrectly though, that if you have that appetite, that low risk appetite, it means you don't want to be innovative, uh, or look at new tooling or new solutions or new opportunities. And that that's, that's not correct. We, we are looking at some really, really interesting tooling solutions now, we've we have a really exciting cloud strategy. Um, you know, lots, lots of ambition around adopting cloud services around SAS, around, uh, you know, um, on prem cloud exploitation and the tooling that goes with that as well.


So I guess how I'm addressing that is talking at events like this. Um, and just showing that, uh, most nationwide is not going to, um, compromise on the, the standards we set ourselves in the controls that we know we have in place and the level of risk we're prepared to take on. Uh, we are really, really keen to understand better, uh, some of the technologies that are out there, the solutions that the new ways of working the processes, um, how they can better enable us to be more effective. So it's, it's quite, it's an exciting place to be right now. There's, there's lots happening, uh, lots of opportunity. Um, w we are, as, as mentioned earlier, very reflective as an organization. We, you know, we, we, we set us very high, high bar for ourselves, uh, and we know that we, we continually have to evolve and change, um, to, you know, to be a successful as with


That's great. So, so bedding, um, in, in that first phase, I would say where you, you, you do that fast finder work rides. There is an entire environment that gets build practices that get defined and everything is focused on going fast. So my experience working with customers is that typically the first year or the first two years are the best, right? It's a, it's a honeymoon is a receipt, just huge excitement across all teams. There is a huge push in favor of change and good results come out. But as any good thing, at some point, the bill comes on the table and, uh, you have other type of stakeholders coming up, uh, such as finance, and they ask very fundamental financial questions. So, uh, we spent quite a bit of money on, on this transformation. So what was the return on investment, the ROI of this, uh, does it truly make sense? Did you treat use costs? Did it increase sales? So they're looking at it from a PR standpoint, you know, in a, in a pretty, uh, uh, basic and logical way, right? Show me the money. Uh, did you see that and how did you go through that? Yeah,


So w we're working through that now? So you're absolutely right. The first two years were incredibly busy. Um, and we, we, we were, it was all about proving and showing what could be achieved. Um, but as, uh, agile and dev ops, understanding appetite has grown, um, the awareness has grown and the challenge, the questioning around the true business benefit has also grown. And, and that's a lot of my time now is talking to people perhaps from outside engineering. I'm not talking about the engineering, uh, ins and outs of dev ops or CRCD tool chains, but the actual business benefit. And I think there's, you know, I can't really understate this enough. One of the most important things you can do when you're building your devil's strategy and even at right at the start, when you're Pathfindering is to start to look at how you measure efficiencies.


So the before and after view, so how efficient is your organization really? Do you have some really good metrics? You're really good key points, indicators of where your efficiencies or even inefficiencies lie. And then just how you can address that through adopting DevOps, CRCD ways of working, because the reason that's so critical is you will be challenged, um, as every good organization should be challenging. What is the business benefit of doing this? This is, this is very, very heavy investment that we're having to make here. Uh, this is a big change to the way we used to working. So what is the business benefit? Why would, why would the business wants to sponsor this or support this? Uh, you have to have those measures in place, um, before and after, you know, these are, this is how efficient we currently are. This is how efficient we are. Now. There's a Delta here about Delta shows us that this is an investment worth making. Uh, if you don't have that, it's very, very difficult, but, you know, to your point, Sasha, you, you may go through Pathfinder and then find you can't go further because that your business doesn't understand what benefit can be handed back to, back to our business.


Yeah. And then w one point you made that I felt was really good, pretty obvious when you think about it, but, uh, you know, uh, we, we always, we're always smarter after, um, is, is this notion that sometimes when we go through this transformation, we build a way to measure as part of this, right? Because before it ends, everything gets harder and it's, it's, it's messy. And, uh, so it's hard to define boundaries where you can measure things. However, when you met those finance teams, they were saying, so what's a change. And when asking for a change, they're asking you, what was the value before, when you did not necessarily start by measuring, but you started maybe by improving things, but without this baseline. So don't forget to measure before you get started, essentially what advice,


Right? Absolutely. And this isn't about weaponizing data. This is about understanding the metrics that you're working to and the Delta, therefore, the improvement that you can hand back re read really critical. Yeah.


Yeah. So, so what are some of those key metrics that's made it possible for your team to, to show to the finance teams that there is indeed a big impact? Uh, can you share some of that? I'm sure you had many, but, uh,


Uh, yeah, I guess from a high level, point of view, we can, um, I mean the standard dev ops metrics in terms of, um, you know, how quickly we can pass, um, our code through its software delivery life cycle, uh, we got some really good tooling in place to enable us to spot where handoffs are happening. That's a, that's a really telling metric, um, and where, where doubles can therefore automate that handoff process. So I'm talking about things like, uh, infrastructure as code, um, your test automation, your, your assurance activities, uh, around scanning for vulnerabilities, et cetera. If you can show how automation can take out time on handoff, uh, that that's a really powerful message. The other, I guess, the other metric, which is important to us is, uh, lots of our Pathfinders, um, had to, uh, deliver some, uh, some CRCD tools to enable them to pathfind for want of a better way of describing it.


Uh, there's a real clear metric for us as we're delivering the enterprise solution. What we're doing is, uh, being able to enabling ourselves to displace those tools. So we are, uh, moving tool costs as well. Now this is something which lands very well, um, with your finance, um, your colleagues, because this is all about taking cost out of your organization, if you can. So there's some really, really clear and relatively easy to mind metrics that you can pull there. You can, um, you can see your software delivery life cycle, and you can see the journey that your code is taking. Uh, but also you can see where duplication exists in terms of your tooling usage and how you might be able to, uh, address that.


So at this point, where did you stand in your transformation and what is that, what are the next big things you want to tackle? Uh, and as part of this, what's interesting to me as well is what type of profiles are you looking for the most to compliment your team for that next?


Well, we've got loads to do still, um, uh, I mean, yeah, huge volume of work. I almost don't know where to start. So I think we've got real focus now on our source code management's approach and how we really, um, mature that we've got good source code management, um, adoption or processes in place already, but how do we exploit the tooling we've got and we've invested in, uh, to scale that further. I think we know that infrastructure is code, uh, is a big area of focus for us. Uh, again, we, we really good at building good environments, test environments, et cetera, but we're really keen to look at how we further automate that as part of the pipeline. Uh, and I guess deployments is, um, where we're looking at now very closely in terms of, you know, we know what RCI solution looks like. We've proven it's a good solution, um, CD.


Um, we know there's going to be an awful lot of, um, demand for that from an our business areas. We know there's difference, um, strategies around deployment blue-green Canary deployments, et cetera. So I think there's real focus now turning to how we deliver the right solution to enable that, to scale across the organization. I guess your second question talking about the, um, the sort of engineers we'd want. I think, you know, technically proficient is, is really of course important, but what I like about everything is that ability to engage, to understand this new way of working this DevOps agile driven way of working is really, really important. That's as engineers come into our, into our organization, they're really comfortable working in that way, uh, and, and re and, and actually a bit of a fan of it as well. Um, you know, on the fan, uh, um, uh, uh, of being more agile and, and devil's ways of working, I've been around the block a few times, to be honest, I'm, I'm used to a way of working. Um, I can see massive improvement and massive benefits to be had. And so I I'd beat the drum of laws, uh, internally in the organization about how this can, uh, can improve our organization. And, and I expect engineers to come in with similar passion, uh, and, um, you know, belief that this is the right thing to be doing.


Yeah, I've rarely heard organizations that say we need less, uh, smart people and developers, uh, I'm half surprised by your answer. Um, so it's really impressive to see in just how in just a few years, uh, you've transformed essentially what, what is a pretty traditional it department and, and shake it up, you know, ways that it can do things faster, create excitement and demonstrate business value to, to, to, to, to the business. Right. But because all of the best stories always have a, but at some point, uh, let's go through the other side of, of, of the coin, right. And, and going fast is one thing, but this cannot come at the expense of peace of mind, right. Uh, and under a peace of mind, I cover things that are security, safety compliance, and so on. And we know that the financial sector is extremely regulated and this for good reason. So send that this is your field. And, and can you tell us when you started to realize as this new approach, uh, following the digital transformation means that you would have to also evolve the processes as it relates to safety, security and compliance?


Absolutely. I think that's really important and I think it's quite easy to deploy fast, but keeping it safe and secure and specifically, specifically in a regulatory environment is quite challenging. So, uh, as we are the centralized team from CSED capabilities perspective, so we, I would, I would like to answer this in two parts. One is delivering the CICT capabilities in itself, right. Which is for the development teams, because developing teams are building the pipelines, delivering the code from source code to the production, consuming those capabilities. So it's, it's quite important that, that the fundamental toolings are safe and secure. So the way we approach is, um, we have the, the, the deploy, those tool sets in a, in a release patient where in, we deploy as an alpha beta and GA as well as we perform a lot of checks. The, the threat model is specifically, uh, if we focused on to make sure that the controls are in place, if there are any threats related to the consumer consumption of that particular tool, as well as identifying the risks and mitigating those risks, as well as part of the pipeline itself.


The second part to it is the pipelines because development team is specifically focusing on building their pipeline consumption, uh, consuming those, uh, enterprise tooling. The way we encourage customers are building the type pipeline templates wherein we increase them to the bacon, all the controls, like security compliance, quality checks as part of the pipeline itself. And if someone needs to override, because of some reason they need to go in and seek, um, an approval from the security representative within their area. So we were also focusing on empowering the customers, empowering the developers to innovate, to pro, to practice and new ways of working, but keeping the society safe and secure, as well as delivering the values as fast as we can.


Okay. Does that makes sense? So, so, um, so you've provided some of those tools, frameworks, and templates, essentially, you were describing, so that developers can, without having to worry about the, how can instantiate the right behavior within their life cycle and, and, and you work on making sure those templates do the right thing, right. Yeah. And do you, do you handle, uh, just a safety security this way, or do you also handle compliance in the same way?


Yeah, so we, we have, uh, a compliance acquired broad term. So we also, the code is compliant. The processes are compliant. So the way we do is okay, as soon as the code K checks in to enter the source control, it goes through various phases. The compliance from the, from the pull request perspective, compliance from the scanning perspective, whether the, the, the code is the code that we develop a resident and is secure, is compliant as well as the, the open source code that which developer has downloaded. It should be coming from the binary repository, which is proxy to the remote repositories, and then going into the, the, the scanning of the container itself, which I'm going to deploy. So that's the, that's the developer part of compliance. The second part is about the, the approach to Embase embed those control, the work that we do.


So what it does, it, it helps us to product to keep the products and services safe and keeping our members and colleagues safe and safe and delivering the, the, what we call it as safer and sooner. What it does is ensure the fast space deployment, as well as we ensure that we have sufficient controls to reduce the risk and, and, and delivering a safely. And how does it involve it involves identifying the risk as early as possible are really in the development stage itself so that we, we identify the right work right time and mitigate those risks. So the way we are doing is we are moving away from the discrete processes, separate controls, uh, processes, which are quite confusing and complicated from the customer point of view. So for example, multiple points of engagement, multiple assessments, and the, it creates a lot of confusion for the customer because are so many processes.


So what we do is, is we have the intelligent controls that aims to drive a consistent and standard approach for understanding the risks, risks across the society. And this enabled the confidence in our risk position and ensure that the right controls are embedded to reduce the risks. And there are various parts. What we do with is the consistent risk assessments, minimum viable controls, minimum viable governance, automation, assurance to so-and-so on. So there are a lot of, uh, work that we have been doing recently about ensuring those controls and the risks are identified and are embedded within the pipeline itself.


Yeah, that's great. So essentially, what, what we can see here, uh, is that I think is, is, is, is super interesting, is that as we talked to Ben, we had this first wave where we spent a lot of time automating the software delivery process. And now son, Matt, you're talking about how you're automating the compliance process as well, by embedding it essentially, and compliance in the wider sense of security and so on by automating, by embedding those requirements into the software that we reprocess. Right. So that both can be achieved at the same time, in some way at the same cost, from a development standpoint. Right. Yep. All right. So, uh, some that one thing's, that's very intriguing is obviously how do you encourage collaboration and adoption at the same time, uh, while, uh, you know, empowering the developers and the team. So, uh, we know that sometimes, uh, when you talk about security and safety and complaints, that's not the best way to get, uh, to get, uh, developers excited. So how do you get that going? Yeah.


Right. Interesting. So, so nationwide believes in an empowering people and creating an environment of accountable freedom. That's really buzzword. That's been used in nationwide quite often. And it is one of the key pillar and, and a nationwide leading leadership framework as well. Like, and what developer wants to do is constantly looking for the new experience, new libraries for consumption of new tools and applications. And so why not? Why don't we do it for the DevOps tools as well? So the way we, the way we do is in the enterprise tooling capability, we work with the, we are aligned with the value stream teams. We, our feature teams work with the illustrator team to deliver based on their requirements. We are defined what are the key requirements that need to be enabled from the centralized team? So we have product owner, which closely working with the business to identify their needs and prioritize the backlog for us.


And that way we manage the, the, uh, the requirements as well as working with the customer, help us to assess whether the work that's being delivered from the centralized team is, is good fit for purpose fit for use. So we get the fast feedback. The nationwide is going through a big transformation phase at the numb. And so there are a lot of teams which are still learning what the CIC is all about. And there are a lot of things which are literally one click deployment, one click, no click, actually to develop a check in the code and code code, maybe going to the pipeline and going into the, uh, into the production deployment. But again, they're passing all the checks. So what we do is we work with, uh, with the teams and embed the DevOps engineer within the team to understand how their ways of working are identifying, where are the bottlenecks and work with them to, uh, create the value stream mapping.


Now, what we do is, is, um, is after identifying the gaps, we work on those gaps and fill those gaps. And then the, the team members are shadowing the, the, actually the, the customer, which we are working with us and thereafter, we do a reverse shadow to make sure that the, the controls are the improvement that we are bringing into the pipeline for those customers are well understood. And then once after, after finishing the river sharing process, we sit back, we just completely come off and then work with another value stream where they need our help to amplify their release frequencies. Thanks then.


So how did that relation with Ben go? Uh, you might have been first, uh, on, on, on two opposite side of the stable, but ultimately this will only work for the company if you can both win.


Oh, that's really interesting. I think so. So me and Ben has originally started this whole DevOps development engineering, and then which turned into CSED platform team. And so relationship with Ben is, is actually we are all aligned. We work in agile framework and the, the, the controls, again, the way the work comes into our team is decided by the product owner. And Ben is in the leadership forum as well, to understand which are the critical customers, which are the customer that we should be focusing on, where we can drive the values faster and better, and then prioritize the work. So it's really, really going well with the working with the leadership team, as well as, uh, as well as the value stream team, which we are closely working with.


So, uh, I'm going to ask both of you a last question. If anybody, uh, in a different company was to start the same journey today, what would be your advice to them then? Any, any advice you want to share?


Well, there's lots of lessons learned. I think I mentioned a minute ago, it's measuring, uh, your, your organizational efficiency, um, before you even start the work, I think is probably the most important bit of advice I could give, uh, because you need to be able to describe, um, how efficient you are as an organization and how it dev ops CI CD pipelines will, uh, enable improvements in, in, in that efficiency. Um, it's absolutely critical. I can't understate it enough. It's absolutely critical that, uh, that you're in a position to be able to do that. And describe that. Uh, that's a, that's a massive, um, lesson learned me and an advice I would give to anyone if they're starting this journey right now.


Thank you, Ben, what about you send Matt?


Yeah, I think just to add to Ben's point is important thing is go back to basics is important to understand, uh, what are the requirements we often see in past not only this organization, the organization as well is the tooling most emphasis on tooling. So don't go on to link first, understand what are the capabilities which are missing focus on those capabilities, understand the requirement, what is required for an organization to deliver something. And that's really, really important. And again, work on a product centric way. Don't deliver it in a big bang approach. And VP is the first thing, get the fast feedback, and then definitely you'll get a success. And specifically around aligning with the value stream teams. That's really, really critical parts about delivering any centralized services if we really desire to do so.


Thank you, son, Matt. Uh, thanks to both of you. Thank you, Ben. I thank you, son, Matt, and, uh, to everybody listening to us, I hope that you enjoy this a speaking session for DevOps enterprise summit. And, uh, I know that the three of us will be online to, to answer some questions. So have a great day. Thank you, Ben. Thank you so much.


Thank you, Sasha. Thanks


Sasha. Have a great day.