This is a transcript of episode 253 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Audit, compliance, security, and governance: these words all carry the heavy weight of bureaucracy, the feeling of a burden to be overcome. In the recently published learning novel ‘Investments Unlimited’ Bill Bensing and coauthors introduce the idea of automated governance, and in this conversation Bill and Jeffrey explore the difference between “governance theater”, automating away bullshit, and acting to get the real benefit.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Jeffrey: Welcome back to Troubleshooting Agile. This is Jeff Fredrick and I am once again without Douglas Squirrel, who is unfortunately not here. I am in sunny Las Vegas recording live at the DevOps Enterprise Summit, and I’m here with a guest. This is Bill Bensing , co-author of Investments Unlimited. Bill, welcome to the podcast.
Bill: Thank you for having me.
Jeffrey: Can you tell us a little bit about Investments Unlimited as a book and also how you came to be involved in it.
Bill: So we’ll start with Investments Unlimited as a book. So it’s a theme novel like The Phoenix Project, it’s a novel-
Jeffrey: A learning novel. So if you like The Goal, and The Phoenix Project, and The Unicorn Project, this is another where you jump into the story and learn things.
Bill: Exactly. So a theme novel, and it goes through a team and their individual experiences. They had decent DevOps practices, but all of a sudden they came to a situation where they had a large compliance problem, and it follows them through months of “how do we figure out this compliance issue,” identifying what the issue was, but also bringing it back into some of the DevOps practices. Everybody uses the term “shift left,” but DevOps focuses on developers and operations but they forgot security, compliance, and audit. So how do you bring some of those forgotten folks into the fold and make this a true, broad, organizational capability, not just something IT people do on a daily basis?
Jeffrey: So this is looking at the broader view of DevOps, not just as a development practice and that sort of stuff, but also about the organization: how do we get past those silos into the other areas, and other concerns of the organization?
Eyes on the Prize
Listen to this section at 02:01
Bill: Exactly. But also one argument to make today is, in a highly regulated organization such as “Investments Unlimited”—the fictional organization—security and compliance is a feature of their software, and it’s expected if not by their customers, then by the regulators. That broader aspect is a lot of organizations forget these are features, and these should be a part of the software that is being delivered, not something that’s tested in, exactly as you can’t test quality in to something. It needs to be planned as a feature of the software.
Jeffrey: Right. The idea of compliance as a feature is going to be a bit different than the way most people think about software and about security, which as you say is mostly tacked-on at the end. So how do we build it in? How did you personally come to be involved in writing this book? What’s your own background related to governance and DevSecOps and that kind of thing?
Bill: Broader background before I got into this was basically “shadow IT.” I am a proponent of shadow IT. I firmly believe it is the people in the business who don’t know enough about technology building solutions to a problem they see.
Jeffrey: Some of our listeners might not have ever heard that term. If you’ve ever been in a straight-off-a-product company, as most of my whole career has been-
Bill: There really is no shadow IT there.
Jeffrey: Well, there might be more than you might think, but anyway, explain what you mean by “shadow IT.”
Bill: At a normal organization, like a large aircraft manufacturer, they have an IT organization and then they have other aspects such as procurement, who procures the parts. Well, procurement needs software to do their job, and a lot of software is done on-, you know the most common server enterprise is Microsoft Excel.
Jeffrey: Laughs
Bill: So it comes to “Could you could you take that and make an application out of it to help the team?” And the person making that application happens to be in procurement and not on the IT team, that’s shadow IT. They’re writing software, they’re doing things people in IT would, but they’re not in the normal IT team, and so it’s not necessarily…
Jeffrey: It’s not visible. It’s hiding in the shadows.
Bill: Exactly.
Jeffrey: It’s IT development being done in the shadows of the organization, and it’s still a significant part of the created business value, but it doesn’t have the visibility and it doesn’t have the label of IT.
Bill: Exactly.
Jeffrey: So you’re a fan that, of distributing the ability to create solutions out to people who actually have the problems and the relevant domain knowledge.
Bill: I like the way you stated that, I’m stealing that. It’s such a better way to say it than “shadow IT.”
Jeffrey: So you’re you’re a fan of empowerment, which sounds like the opposite of governance? So that’s really funny that you would come in here and be like, “Yeah, I like this,” and then you write a book about how you shouldn’t be doing that.
Bill: Well, that’s where I get into my struggle because I like doing the shadow IT empowerment, but governance is very important, especially in these organizations. My experience was that governance holds you back, but as I got into my job at Red Hat a couple of years ago, this is where I started down this journey, working with the federal government and their concept of “authority to operate.” The government wants to empower people to write software for the defense industrial base, but then you have this authority, this governance, that just sort of stops things in its tracks, or that’s the perception. Now the thing about governance is it’s value-added, but how it’s implemented tends to be where everybody has the rub. And so aI was doing this thing called software Factory. So it’s CI/CD as a service basically, and then you have to get things ATO’d. You need auditors to say, “Yeah, this can go into production.” Or we have this idea of continuous authority to operate where there’s automation that determines whether it can or cannot go. I became infatuated with this because what I saw with continuous authority to operate was that could solve my shadow IT empowerment problem. I can empower people to write and then instantaneously they can find out whether it meets the governance standards and if it doesn’t, why? As I started going down this path, I met John Willis, the senior director in our Global Transformation office. There was a DevOps handbook, co author and a couple folks like that. Him and I worked on a couple internal hackathons, and then actually he eventually invited me to the DevOps Enterprise Forum in 2021 to help write a paper, which then became the book.
Don’t Just Minimize Annoyance
Listen to this section at 06:30
Jeffrey: Okay, fantastic. We’ve had John Willis on the podcast before, I’ve known him for many years. We always get into talking about Deming. So, one of the things we discussed before recording was the motivation for this kind of solution. Because you’re talking about automating governance, bringing security and compliance into the process and streamlining it. I challenged you if this just automating away bullshit or actually providing value, and you used a phrase I like and will stael in the future is “governance theatre.” It sounds like minimally you can make things more efficient because you automate the terribleness. But that’s not very interesting to me, to say “We have this manufactured problem of needing to sign off to a standard.” But what about the real efficacy part? Is there anything about this that if I actually cared about governance and the benefits that should accrue, about being more secure, anything that would lead me towards this automated approach?
Bill: You use the word care. Automated governance is for the organizations that truly care about security compliance as features of the software. You can do compliance theater, get a rubber stamp that makes customers feel good and that says I’m meeting some standard. But if you want to prove to yourself that you’re not just meeting but exceeding those standards or a higher one, because it’s a true core value of you and your organization, automation is the way to go. We were discussing Volvo crashing cars above and beyond the expected crash standards.
Jeffrey: That’s right. They did their own tests that weren’t government mandated because they had a mission to make safe cars. It wasn’t enough for them to just meet the government standards because they cared about true safety. And that’s what your analogy here is, that if you care about real security, real governance, then you should be looking to build it into your process.
Bill: Exactly. Real security, true security, true compliance, make it part of the standard process.
Jeffrey: Fantastic. Why should people care about this? Not for my clients, but why should I care about it for myself?
Bill: True compliance and true security, that’s giving you a lot of leeway…I hate to use the word branding, but automated governance makes a stronger product, builds a stronger business, a stronger culture around this. So why should I care? I’m thinking hard because I’m trying to be very careful about how my words come out. I don’t want to sound salesy, though I know I have at times.
Jeffrey: Because you’re passionate about it, it can become evangelistic.
Bill: Exactly.
Jeffrey: But evangelize for a minute here. Really, beyond the fact I’m required to do it, what benefit can accrue to me? Why should I become one of these people who care extra? It’s easy if I can say in the case of Volvo, “Should I actually make my car safe,” I can say “I want safe cars.” Why? “Because I want to save lives.” Why do I want this security compliance built into my process? What’s the organization I’m in where this is really important for me and I want us to have this?
Where Governance is Cherished
Listen to this section at 10:39
Bill: If you’re really wanting to be secure and compliant like the US federal government, what I’m ensuring is whatever they’re using is not just meeting some standard, but it’s above that. When they’re downrange there must be very low probability of certain things happening. Or a financial institution. If I really care about security and compliance, this is me making sure those types of data breaches or anything is not going to happen. My clients security is key. Now there’s business advantages to that as well.
Jeffrey: Volvo was able to sell some cars to people who cared about safety.
Bill: That was a big thing, if you bought a Volvo you knew you’re going to be safe.
Jeffrey: So the people who look at these things can look at the efficiency. “If we really if we really care about governance, this is what we’d be doing. We should be looking to automate this, building it from the beginning.” So I read the book, it will tell me exactly where I should start?
Bill: It will give you a really good idea of how to start having the conversation in your organization.We wanted the non-technical and the technical size of the organization to be able to put words in the storyline to what they need to achieve. We know when people are having conversations, whether you’re talking past each other or not using the same language, there’s a lot of reasons people don’t connect in the conversation, right? So this could be that nexus of conversation that a non-technical person can cite, “Hey, read this, this is what we’re looking to try to achieve as an outcome.” Or a technical person can slide it over to compliance, maybe even the CEO, and say “take the time to read this, these are the outcomes.” No matter wher you stand in relation to the process you can say “These are the outcomes that we want to look for.”
Jeffrey: I really appreciate that. You used the phrase “ubiquitous language” almost from a domain-driven science perspective. What you’re looking to provide in this book is a ubiquitous language for both business and technology so they can agree on what outcomes they care about.
Bill: Exactly.
Jeffrey: So in that way it will start a conversation for them about what their journey needs to be from this point. “How do we actually get there, should we make this investment? If we do, are we clear why is that we’re doing this?”
Bill: Exactly. It’s for people who want true security compliance. Maybe they can’t figure out how to get there yet. This is a way to be clear what they’re trying to get done.
Jeffrey: All right. Fantastic. So if any of our listeners read the book and have questions for you or if they disagree with you, what’s the best way for them to get ahold of you?
Bill: LinkedIn is always a good one. Tag me on LinkedIn at any post, or on Twitter hashtag me at the end.
Jeffrey: Fantastic. Links to those in the show notes. Thanks for being on as a guest, Bill.
Bill: Thank you very much for the invite.