Governance As a Service

Most software governance is feared solely due to poor design and inconsistent execution. BUT! There is a reality where governance is good and wanted, and governability is indeed sought after by those governed. And no, this reality is not some version of corporate Stockholm Syndrome. Autonomous governance is what the masses want, and it’s provided best when governance is offered as a service.

Governance as a service is what all highly-regulated organizations need. If it’s so necessary, why is this the first time you are hearing about it? Let’s take a trip through the rabbit hole.

Autonomous Governance

Autonomous, in this case, is not a fancy-schmancy buzzword. Autonomous has nothing to do with machine learning or artificial intelligence. Instead, it describes a higher-level systems design that judiciously applies automation. This concept comes from Chapter 7 – The Evolution of Automation from the Site Reliability Engineering book. It is critical to ground this point right now. Why? Automation is not a panacea. Automating the wrong things allows you to create adverse outcomes efficiently. To illustrate this further, let’s simply fork the first paragraph.

“For SRE Governance, automation is a force multiplier, not a panacea. Of course, just multiplying force does not naturally change the accuracy of where that force is applied: doing automation thoughtlessly can create as many problems as it solves. Therefore, while we believe that software-based governance process automation is superior to manual operation processes in most circumstances, better than either option is a higher-level system design requiring neither of them—an autonomous system. Or to put it another way, the value of automation comes from both what it does and its judicious application.”

Site Reliability Engineering

Ok, this makes sense. I’ll bet you are asking yourself, “how do we do this in my company?” Here is the bottom line up front: it is best to autonomize the governance process and offer it as-a-service to your technical teams (Governance as a Service).

“Bill, that sounds great. But, HOW?!?!”

Inspiration for Governance as a Service

What would your governance and audit process look like if there were zero handoffs and it could be administered within sixty seconds or less?

I often wonder why I can offload infrastructure management to a third party but I cannot offload governance. A cloud vendor’s business is predicated upon being the expert at operating their service. A service that you need. Consuming such services allows you to reinvest resources into core value-creation activities instead. 

So, why can’t this model exist for governance? Why can’t I simply submit my software to a “vendor” and have them identify and fix end-to-end security and compliance issues? How nice would it be if our organizations could declare their security and compliance expectations as they do with infrastructure as code?

The reality is most bits and pieces exist to achieve to do this. Some may think, “Well, X-tool, and T-tool provide parts of it.” The problem with this line of logic is the hand-offs created by the amalgamation of all this tooling across the full governance process. Teams collect data from these tools and pass the data to other teams with incongruent means. These other teams run more tools and collect more data, thus perpetuating this vicious cycle of incongruence. This situation is what makes the governance process tough.

Ultimately, it’s up to the subjective judgment of an independent person with no context of the software to decide if it passes muster. It’s no wonder audits are burdensome. Our governance process is difficult because of these handoffs and the confusion they create. So, why not get rid of the handoffs? 

Governance as a Service integrates the governance process and tools in such a way that any individual could request a review and be provided concrete feedback within sixty seconds.

The Journey to Wonderland

Let’s get tactical. Once you’ve read this article, you should have your first steps to creating a governance-as-a-service approach for your organization.

Do you remember that classic IaaS/PaaS/SaaS diagram that’s been around for years? The below diagram is what I’m referring to. One day, I’ll locate the true origin of this diagram.

What I appreciate about this graphic is how it demonstrates the shifting responsibilities from a customer to a provider. Don’t get caught up in the specific content of this diagram for now. This reference illustrates the migration of duties from a customer (or consumer) to a provider. 

Governance as a Service shifts the responsibility of governance tasks from a governance model consumer to a governance model provider. GaaS offers a future where governance model consumers offload many governance tasks to a provider. This provider is an expert at executing those tasks. The provider’s value is their ability to help the consumer meet the requirements of their governance model. 

While GaaS shifts the responsibility of the governance tasks from a consumer to a provider, it does not shift the total accountability to the provider. Let’s relate this to a typical software development team. 

A development team decides to go from managing all or parts of its internal infrastructure to a Platform as a Service (PaaS). The development team operates their application on the providers’ internal infrastructure rather than their hand-built, self-managed servers and network. The agreement between the development team and the PaaS provider ensures that the provider is responsible for a timely resolution in the case of service, network, or other failures unrelated to the application. Additionally, the provider now has economic incentives to be proactive given frequent and longer-than-expected failure resolutions risk future business between the development team—the provider begins to treat their service offering as a product.

I’m limiting my terms to “provider” and not “vendor.” This nuance is critical. As-A-Serivce is a consumption model that can be provided by more than vendors. The service can be provided by another team. Regardless of who the provider is, the shifts in responsibilities are the same.

The Governance as a Service Model

The graphic below illustrates the movement from traditional enterprise software governance to governance as a service. There are four (4) key points you must take away.

First, all security, compliance, and audit expectations must be codified to be machine-readable. Governance as a Service does not allow for subjective interpretation of a governance requirement. A key driver for pursuing GaaS is to be a forcing function to implement policy in a black/white and declarative way.

Second, you are moving the security and compliance validation accountability from the software engineering team to a Governance Engineering team. The software engineering team must only be accountable for the technology directly required to validate the features of their software. 

Third, the Governance Engineering team is accountable for understanding the organization’s security and compliance requirements. They are also The governance engineering team is responsible for autonomizing the governance process by amalgamating all components into a singular interface for the software engineering teams.

The Governance Engineering team is what makes this all possible. Their core value is to drive developer productivity by resolving how software engineering teams, security, compliance, and audit professionals interface within the company’s governance process. They buy, build, and integrate all the disparate technologies to create an internal platform-like service; they are fundamentally building a product.

 The components in this diagram are not meant to be comprehensive. They are a starting place to help establish the notional direction. Other aspects to include in the GaaS should be processes such as penetration testing.

Fourth, automating the governance process is the goal. To some, this may read as if you simply abstract CI/CD tooling from the developer. The GaaS encapsulates the technology that assesses the software’s governance state and automates the audit process.

For Next Time

Governance as a Service is how your organization can increase productivity across many functions required to ensure your software systems meet muster. The fundamental tenant of the GaaS approach is restructuring ownership and governance implementation flow. One must encapsulate all security, compliance, and audit concerns into a separate world.

For my next deeper dive into this topic, I’ll cover how GaaS is an implementation of the NIST 800-207 Zero-Trust architecture, why this is important, and my reasons for this approach is a game changer.

- About The Authors

Bill Bensing

Bill Bensing tranforms Shadow IT into legitimate software development organizations. Bill's recent thought-leadership is proving software devliery velocity and highly secure and compliant software are not mutally exclusive. He lives in Tampa Bay, FL, area.

Follow Bill on Social Media

• 
•