We're Sorry, Love DevOps

Bill Bensing will talk about the upcoming book, Investments Unlimited, A Novel about DevOps, Security, Audit Compliance and Thriving in the Digital Age.


Bill Bensing

Software Factory - Managing Architect, Red Hat



Thank you Ben. So this community has long been exploring how information security and compliance objectives should be integrated into everyone's daily work. In fact, yesterday, we heard from the team at nationwide insurance about how audit and technology teams can work differently to get radically improved outcomes. So in parallel, another group of amazing and passionate people from this community have been attacking the problem from another angle and for nearly eight years. And it has culminated in a novella called investments unlimited, which is being published later this year. Bill Bening is a longtime scholar and theorist of what governance should look like and will be teaching us about a concept that they're calling automated governance. Here's bill.


Hey, everybody, bill Bening here like Saturday, um, to talk a bit about some of the automated governance. Um, but first before we get started, uh, a bit of my Beyonce role, if you like, what you're seeing here, go ahead and tweet on it. Um, if you have questions, let's tweet about it. Um, if you think there's something here that's wrong, definitely tweet about it and let's talk. And if you just simply want coffee and wanna let everybody know, go ahead and tweet about it. So real quick, let me introduce myself real quick. I'm bill Bening, as stated before. Um, bit of my background is, you know, coming up through the it ranks and focused on how to help make software delivery and the capability to software, uh, deliver software suitable for everybody, uh, regardless of where they may be in an enterprise. And so look at the sort of democratizing the ability to deliver software.


So that's by passion. And as we start thinking about moving this beyond into the next phases of DevOps, uh, modern governance is really the, the term that seems to come to mind. And I'll have to admit that I've I borrowed that from John Willis, I'm continuing to use it. Um, and so a bit of my driver here as you'll see today is really how can I help the world become its own software company? So imagine you're sitting there, you're at home making pizza with your son, all of a sudden you get a call. It's your board member board member lets you know, board member name's Bernard says, Hey, you got a problem, get an MRI, come your way you shrug, you know, for the folks that dunno what an MRI is. MRI stands for matter requiring immediate attention. It's from a highly regulated institution's financial institutions.


It's the, the number one signal from a regulator that you have a big big problem. And that right there is an investments unlimited. You know what investments unlimited is a story about how we responded or how an organization, a fixing organization responds to this R I a this truly existential crisis. Uh, the funny thing is the crisis to lawyers degree was caused by themselves. They thought they had great DevOps processes. They thought they had some amazing stuff going on, but what they realized is yeah, they had dev they had ops, but they completely missed the boat on security and compliance that right there is the real situation in industry today. And that's what this book's about. I can't really continue with this speech without giving much of homage too much. My team here. Um, this is probably one of the best experiences I had. It came out of, uh, the opportunities last year was a, uh, do paper we were working on and we, we wrote it in, in, you know, in that vein and this became an opportunity for it to become, uh, to become, uh, the book here, investment unlimited, but to give homage to everybody here, a lot of this here is like Helen DevOps Institute, you know, working with Jason Cox at Disney, uh, Topo, Topo, I guess you think everybody's seen the, the, the S3 playlist from Jason and in topos playlist recently came on.


Like everybody knows who Topo Powells a topos been. Great. Um, two big folks in here. Um, John re and Mike, uh, from PNC, a lot of this book and we'll cover it. They are significant in the experience of this book and it's, it was really fun to work with them and really see how they, uh, some of the, some of the, uh, lessons they learned hands on with this. And we got Andre from VMware, of course, John Willis. Um, and then last but not at least definitely Caleb and cables be great coming from KP G. So as you'll see here, this, everybody came together, brought their experiences from all sides of the organization who see, as you'll see here, people engaged in the organization in building software and running software, and some were engaged in other organizations, such as consultancies, helping, helping other organizations. There's a lot of use of organizations there, but helping folks, uh, to do this better. So it is a quite a comprehensive experience, but a bit about the book and where it came from. Uh, the book has actually been built upon thought leadership, uh, starting back in 2015 here and, and, you know, with those is going through these unlikely union and going all the way through the, uh, DevOps, automated governance and eventually making itself into the, uh, the investments unlimited. So what you're seeing here is this, this novel is an aggregation of this communal experience brought together and told in a way that, uh, makes it engaging, fun and enjoyable.


But one thing again, remember investments and unlimited is an experience. Um, it is a fictional story that does relay real world lessons. Let's focus on that real world lessons there. Um, it is more than theory and we'll talk a bit about some theory stuff today, but outside of theory, it is the collective experience and it's collective experience from practice and not just practice in general, but it is collective experience, successful practice. And so as we talk about the book and we'll go into some, some additional, uh, topics today, uh, what we want to talk to is understand like this, isn't just us saying, Hey, we think you should do this. This is what folks in this organ and folks in the office have done in the real world to make these successful outcomes. So what we'll cover here quickly in next 10 or so minutes, just a couple, two key concepts.


One, I wanna talk about three aspects of modern governance, but then I wanna pose maybe one unpopular opinion. So really using the term modern governance, but what is modern governance and modern governance is thinking differently. Automated governance, modern governance. First is all coming from what we really do is when we think differently, we wanna move from this concept of implicit security and compliance model model models to explicit security and compliance. So going from this implicit to explicit codification, and to do this, you have three key aspects. And first let's talk about the full experience, um, as with the presentation title. Um, you know, sorry, you have to remember that you bring everybody in to the SDLC to make automated and modern governance happen. Um, a great way to do this is through the DevOps, automated governance, reference architecture. What I love about this in the ICAS, the inputs outputs, risk controls, actors and actions is this is a great tool to sit an organization down and say, okay, what is our business architecture?


How should we operate as a company, take the tools out of it. How should we operate? How should we deliver software and make software delivery, a business process. When you start to ask questions and approach it from this framework, what you start to realize, especially on the governance side is the two types of toil that are out there. You have audit toil and then delivery toil. So let's dig a little deeper into those. What is audit toil? I think, think about audit toil. It's really the hu the it's that high toil human process. It's the humans in the middle that are taking evidence and material going through and saying, yes, this does or does not pass it's. Uh, it's you know, the one example is that can give, you know, two different auditors, the same controls and evidence, and they'll come back and give me two different audit outputs.


And you know, that right there itself is an exp is, is an example of how the toilet manifests itself. But then we get to delivery toil. So delivery toilet is really that it's the, the ambiguity around the audit process. People don't understand the audit process. Yes, you have the toil in executing it, but what happens when somebody doesn't know what they need to do, doesn't know the controls or doesn't understand what's being, um, informed back to them by a, a governing body that right there just causes a lot of time, unnecessary, uh, unnecessary work and or a rework, which hence gives you your two types of toils, the audit toil and delivery to another key aspect of this is objective, not subjective. And as we hear, as you saw, moving from explicit or moving from implicit to explicit objective to subjective, this is key here to automate any type of governance.


Things not only have to be machine readable, but they have to be explicit. You have to be able to codify them. So I'll show you an example of it thought looks like they codify here. But when I think of this new there's this concept called a governance contract, um, policy as code. But the idea here is if you can make it machine readable, machine readable and machine executable, it can be automated. So you wanna take concepts and things from the material. Let's just see here on the left hand side, this, this little output is, is some units have some job unit tests taking that information, and then serializing that into this contract, this, this codifiable, this machine readable format and capability. So then you can apply governance to it in a, in an automated fashion. So what does it look like to apply governance to something like this, this governance contract?


Well, you can see here, this is an example of OPA rego with OPA. You can use whatever, um, uh, whatever policy engine you may need. But the idea here is this governance contract defines the contract at agreement of what needs to be analyzed for the policy. So regardless of whatever your tool, your underlying component or system may be, that gives you the material. It has codified in such a way that it's a standard information approach for the organization. That way you can use tools such as OPA or whatnot, to then evaluate this. Now, the purpose behind this is as you get to Cod and you get to, and you get to this automated aspect, this is where you start to pull the humans out and redefine what the human's work is inside of the organization. Third one, black red, green. Now this is key. It's about observability.


What's good, what's bad. But most importantly, what's known. So let's start with green. Green's pretty simple. Talk about controls and compliance. These are the things that you have compliance and controls for, and you know, you eat them. That's fairly simple. Next is red red. Again, not let's say it's simple. We'll say it as, as simple too, but it's the controls, you know, you have to meet, but you aren't meeting them for some reason. Let's talk about black. Think about like a black hole. These are the unknown unknowns. This is the stuff that, you know, do these controls apply. Have we applied to right control? What don't we know that we don't need a do. As we start thinking about moving into the automated and modern governance perspective, this is where the we'll talk about the human power and human resources. This is how it's reallocated.


What you do is you want to reallocate people from being in the middle of just manually reviewing and you know, that being part of that audit toil and that delivery toil to now being part of understanding how to close that black hole. And this is key in the automated and modern governance process is taking the thought capability of the government's body and the governing organization itself and focus it on solving the problem of are these the right controls. Do we have enough controls? Are these controls applied properly thinking through all those, instead of ha, instead of asking them to say, Hey, check your email, read my sonar cube scan, for example, and tell me if I can go to, to production as we go through this. I like to think about this from a unit testing perspective, red, green refactor, but think about a black, red and green.


You're looking at your controls. You're unknowns. You're going from unknown to, okay. I don't need it, but at the red stays, I just need to figure out how to then, how to then build the procedure or modify my software to meet this compliance. And then you get to green. Um, this is really key. There is some data from some of the authors that, uh, from a couple of the authors, this showed that over the course of this is about eight months to 12 months. Just their unit testing went from something that was just very, very, um, very not well done to having a lot of green. And what they saw was the outcome of the quality and deployability of the software inside of their organization. So as you start thinking about the automated governance, it's yes, it's about applying governance, but it's also a way to establish what the norms of behavior are in your organization.


So let's talk about some opinions here. I've got an opinion for you. If you want one, I know there's a lot better to be around here, um, during, during the, uh, during the enterprise summit. And it's probably an unpopular opinion, but I'm, I'm gonna go with it. Some people probably think it's unpopular, repurposing your cab. Have you ever thought about just getting rid of your cab or repurposing your cab? I would argue with modern governance. This is key. What you wanna do is you wanna repurpose your cab to change your proof board. What you wanna do is you wanna make it work for you and perspectively not work against you. We know that, you know, these are there for a reason they're not meant to work against, but sometimes it can feel like that. What if you took your cab and changed it into a modern governance platform team? So if you repurposed your cab and did this, what would something like this look like?


Think about building an onroad. What you would wanna do is you want to focus on automating governance. You wouldn't try to get as much automated governance as there as possible, but you wanna focus on automating for your software. So take your cab, your change approval board and change the way it operates to focus on how you automate your, how do you automate, uh, and build this onroad approach. Once you build that onroad approach, which you're gonna notice is a lot of your investment happens up front to ensure you're getting your software ready and get it to a level of compliance that it can be automated, cuz there's no secret. Once you start out with this, there are hurdles and there are obstacles that you start with that in tradit that most people in the organization just simply escalate until they get somebody to sign up on the risk here.


What you're doing is you're forcing it to be confronted and as part of the on road. Now, once you do this, you'll start to realize you can build out canonical implementations, think about Preo 80 20. You realize that, okay. As I automate governance, the software I'm building, most of it, you know, not say most of it on average that's makes sense, but a lot of it can fit in these standard canonical implementations. So we have higher usability throughout the enterprise. And this is what it looks like to build the onroad. So if you think about your change approval board, change it from sort of being that this sort of list that put an obstacle in the middle of this perceived obstacle in the middle of getting to, to production, to really being a capability, to facilitate the flow of production, to understand what is or isn't in compliance, but also to be the way the organization continuously increases their compliance and security, um, stature over time, even though you'll have this one thing you realize, is it most likely won't disappear in its entirety?


Um, actually I love tole powers, capital one example around this and this a lot of what we wrote in the book around this area was from, to palette some, the experiences, uh, from Mike and John at PNC. The thing about the offroad is, is manual. You will have manual evaluation. Now you don't wanna do this for everything and you don't, it really should be the exception. And what you'll notice is the cost itself occur as every time you have a cap session and now why are we talking about the on road? Or we talking about the offroad when we just talked about this on road and never automating everything. That means problem is there is actually just some software that this may be appropriate for. Think about the rate of change around a piece of software. If you don't make a change on your piece of software for say three years at the time, do you really need to figure out how automated is it?


Is the investment in that worthwhile to do all the upfront investments to automate? Or do you just incur the cost every three years when you make that one change through the manual cap. But at the end of the day, as you start thinking of this, this is sort of the, the onroad versus offroad. And how do you organizationally change to provide these platform team concepts and these internal type products? And you'll notice the, uh, a big theme in the book is, you know, one of the initial themes is could you take this and make this an internal product? So no matter your road traveled, whether it's an onroad or an offroad, you always want to apply the same governance always apply the same governance. The governments posted the exact same standards. If you wanna integrate these lessons, and we want you to integrate these lessons into your governance process. So that's sort of the call to action here as we go through. And you, and you read the book, ask yourself, how do I go from cab to automated? Um, definitely read the book, check it out. Um, I'll give you a little hint. Uh, I, I call it summoning your inner, your inner Michelle and Omar. And, uh, when you read the book you'll, you'll, you'll know what I mean there. Um, but, uh, it's been great sharing these lessons with you, um, and enjoy the summit.