Host Intro (Gene Kim)

Thank you, Ben.

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.

In parallel, another group of amazing and passionate people from this community have been attacking the problem from another angle for nearly eight years, and it has culminated in a novella called Investments Unlimited, which is being published later this year.

Bill Bensing 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.

Bill Bensing

Hey, everybody. Bill Bensing here. I'm excited today to talk a bit about some of the automated governance.

But first, before we get started, a bit of my Beyonce rule: if you like what you're seeing here, go ahead and tweet on it. If you have questions, let's tweet about it. If you think there's something here that's wrong, definitely tweet about it and let's talk. And if you just simply want a coffee and want to let everybody know, go ahead and tweet about it.

So real quick, let me introduce myself. I'm Bill Bensing, as stated before. A bit of my background is coming up through the IT ranks and focused on how to help make software delivery and the capability to deliver software suitable for everybody, regardless of where they may be in an enterprise. So looking at democratizing the ability to deliver software: that's my passion. As we start thinking about moving this beyond into the next phases of DevOps, modern governance is really the term that seems to come to mind. I'll admit, I've borrowed that from John Willis, and I'm continuing to use it. A bit of my driver here, as you'll see today, is really: how can I help the world become its own software company?

Imagine you're sitting there, you're at home, you're making pizza with your son. All of a sudden you get a call. It's your board member. The board member lets you know, the board member's name is Bernard, says, "Hey, you've got a problem. You've got an MRIA coming your way." You shrug. For the folks that don't know what an MRIA is, MRIA stands for Matter Requiring Immediate Attention. In highly regulated institutions, financial institutions, it's the number-one signal from a regulator that you have a big, big problem. And that right there is in Investments Unlimited.

Investments Unlimited is a story about how an organization, a fictional organization, responds to this MRIA, this truly existential crisis. The funny thing is, the crisis, to a large 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 homage to my team here. This was probably one of the best experiences I had. It came out of the opportunities last year. It was a DOES paper we were working on, and we wrote it in that vein, and this became an opportunity for it to become the book here, Investments Unlimited.

To give homage to everybody here: Helen from DevOps Institute; Jason Cox at Disney; Topo Pal -- everybody's seen the Esri playlist from Jason, and then Topo's playlist recently came on, everybody knows who Topo is, Topo has been great; two big folks in here, John Rzeszotarski and Mike from PNC. A lot of this book, and we'll cover it, they are significant in the experience of this book, and it was really fun to work with them and really see some of the lessons they learned hands-on with this. Then we've got Andres from VMware, of course John Willis, and last but not least, definitely Caleb. Caleb's been great, coming from KPMG.

As you'll see here, everybody came together and brought those experiences from all sides of the organization. People are engaged in organizations in building software and running software, and some are engaged in other organizations, such as consultancies, helping other organizations. There's a lot of use of "organizations" there, but helping folks to do this better. So it is quite a comprehensive experience.

A bit about the book and where it came from: the book has actually been built upon thought leadership starting back in 2015, going through this unlikely union and going all the way through DevOps automated governance, and eventually making itself into Investments Unlimited. What you're seeing here is this novel is an aggregation of this communal experience brought together and told in a way that makes it engaging, fun, and enjoyable.

One thing, again, remember: Investments Unlimited is an experience. It is a fictional story that does relay real-world lessons. Let's focus on those real-world lessons. 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. Not just practice in general, but collective experience from successful practice. As we talk about the book and go into some additional topics today, what we want to talk through is: understand this isn't just us saying, "Hey, we think you should do this." This is what folks in the field have done in the real world to make these successful outcomes.

What we'll cover here quickly in the next ten or so minutes is two key concepts. One, I want to talk about three aspects of modern governance, but then I want to pose maybe one unpopular opinion.

Really using the term modern governance, but what is modern governance? Modern governance is thinking differently. Automated governance, modern governance -- where is this all coming from? What we want to do is think differently. We want to move from this concept of implicit security and compliance models to explicit security and compliance, so going from implicit to explicit codification.

To do this, you have three key aspects. First, let's talk about the full experience. As with the presentation title -- sorry -- you have to remember that you bring everybody into the SDLC to make automated and modern governance happen. A great way to do this is through the DevOps automated governance reference architecture. What I love about this and the IORCAAs -- the inputs, outputs, risks, 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.

Let's dig a little deeper into those. What is audit toil? Thinking about audit toil, 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." One example is they can give two different auditors the same controls and evidence, and they'll come back and give me two different audit outputs. That right there itself is an example of how the toil manifests itself.

Then we get to delivery toil. Delivery toil is really 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 informed back to them by a governing body? That right there just causes a lot of time, unnecessary work, and/or rework, which hence gives you your two types of toil: audit toil and delivery toil.

Another key aspect of this is objective, not subjective. As you saw, 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.

I'll show you an example of how it looks to codify here. There's this concept called governance contract, policy as code. The idea here is if you can make it machine readable and machine executable, it can be automated. You want to take concepts and things from the material you'll see here on the left-hand side -- this little output is some unit tests, some Java unit tests -- taking that information and serializing that into this governance contract, this codifiable, machine-readable format and capability, so then you can apply governance to it in an automated fashion.

So what does it look like to apply governance to something like this, this governance contract? You can see here this is an example of OPA, Rego with OPA. You can use whatever policy engine you may need, but the idea here is this governance contract defines the contract, that agreement of what needs to be analyzed for the policy. Regardless of whatever your tool, your underlying component, or system may be that gives you the material, it is 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. The purpose behind this is as you get to codifiable 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. This is key. It's about observability. What's good, what's bad, but most importantly, what's known.

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 meet them. That's fairly simple.

Next is red. Red, again, we'll say it is 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 a black hole. These are the unknown unknowns. This is the stuff that: do these controls apply? Have we applied the right control? What don't we know that we don't need to know?

As we start thinking about moving into the automated and modern governance perspective, this is where the human power and the human resources are reallocated. What you do is you want to reallocate people from being in the middle of just manual reviewing and being part of that audit toil and delivery toil, to now being part of understanding how to close that black hole. This is key in the automated and modern governance process: taking the thought capability of the governance body and the governing organization itself and focusing it on solving the problem of, are these the right controls? Do we have enough controls? Are these controls applied properly? Thinking through all of those instead of asking them to say, "Hey, check your email, read my SonarQube scan, for example, and tell me if I can go to production."

As we go through this, I like to think of it from a unit testing perspective: red, green, refactor. But think about black, red, and green. You're looking at your controls, your unknowns. You're going from unknown to, okay, I don't need it, but at the red stage I just need to figure out how to then build the procedure or modify my software to meet this compliance, and then you get to green.

This is really key. There is some data from a couple of the authors that showed that over the course of about eight months to 12 months, their unit testing went from something that was just not very well done to having a lot of green. What they saw was the outcome of the quality and deployability of the software inside their organization. As you start thinking about automated governance, yes, it's about applying governance, but it's also a way to establish what the norms of behavior are in your organization.

Let's talk about some opinions here. I've got an opinion for you if you want one. I know there's a lot that are going to be around here during the Enterprise Summit, and it's probably an unpopular opinion, but I'm going to 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 want to do is repurpose your CAB, the change approval board. What you want to do is make it work for you and prospectively not work against you. We know that 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?

If you repurposed your CAB and did this, what would something like this look like? Think about building an on-road. What you would want to do is focus on automating governance. You want to try to get as much automated governance there as possible, but you want to focus on automating for your software. Take your CAB, your change approval board, and change the way it operates to focus on how you automate and build this on-road approach.

Once you build that on-road approach, what you're going to notice is a lot of your investment happens upfront to ensure you're getting your software ready and get it to a level of compliance that it can be automated, because there's no secret: once you start out with this, there are hurdles and obstacles you start with that most people in the organization just simply escalate until they get somebody to sign off on the risk. Here, what you're doing is you're forcing it to be confronted as part of the on-road.

Once you do this, you'll start to realize you can build out canonical implementations. Think about Pareto 80/20. You realize that as I automate governance, the software I'm building, a lot of it can fit into these standard canonical implementations, so we have high reusability throughout the enterprise. This is what it looks like to build the on-road.

If you think about your change approval board, change it from being that perceived obstacle in the middle of getting to production, to really being a capability to facilitate the flow to production, to understand what is or isn't in compliance, but also to be the way the organization continuously increases their compliance and security stature over time.

Even though you'll have this, one thing you realize is it most likely won't disappear in its entirety. I love Topo Pal's Capital One example around this, and this is a lot of what we wrote in the book around this area, from Topo Pal and some of the experiences from Mike and John at PNC.

The thing about the off-road is it's manual. You will have manual evaluation. You don't want to do this for everything, and it really should be the exception. What you'll notice is the cost itself occurs every time you have a CAB session.

Why are we talking about the off-road when we just talked about this on-road and automating everything? The biggest 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 a time, do you really need to figure out how to automate 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 to the manual CAB?

At the end of the day, as you start thinking through this, this is the on-road versus off-road, and how do you organizationally change to provide these platform-team concepts and these internal-type products? You'll notice a big theme in the book, 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 on-road or an off-road, you always want to apply the same governance. Always apply the same governance. The governance boasts the exact same standards.

If you want to integrate these lessons -- and we want you to integrate these lessons into your governance process -- that's the call to action here. As you go through and read the book, ask yourself: how do I go from CAB to automated?

Definitely read the book. Check it out. I'll give you a little hint. I call it summoning your inner Michelle and Omar, and when you read the book, you'll know what I mean there. It's been great sharing these lessons with you, and enjoy the summit.