The Governance Mismatch
October 23, 2017

Mark Schwartz
Amazon Web Services

DevOps poses a unique challenge and opportunity for IT governance. Traditionally we have governed IT in terms of projects. We lump a number of requirements, fulfilling a number of business needs, together into a bundle we call a project. We then build a business case for that project, put it through some governance process, perhaps an IT steering committee or some variation on one, to decide whether to allow it to proceed and to give it a place in the company's priorities. Once the project is ongoing, the team conducting it reports on its progress against its objectives, and probably against its planned costs and schedule, and some sort of oversight mechanism is in place to review, and perhaps act on, those results. You could say that our unit of governance is the "project," or that we govern at the granularity of the project. The project is a grouping of requirements, a thing that can be planned, an initiative that begins and ends.

Of course project-oriented governance lends itself to the Waterfall model. A fixed set of requirements; a plan; a Gantt chart; a well-defined series of phases; a result at the end – this is a natural way to treat a conglomeration of requirements that has an approved business case and a committed plan.

DevOps offers us a very different manner of execution. It is flow based, with new requirements being pulled into a pipeline, worked on, and deployed quickly to users: it optimizes the lead time for getting requirements into production by automating the delivery process and by eliminating handoffs between functional silos. Each individual requirement travels its own path to production, as if it were a packet making its way across the Internet. Our unit of execution is the individual user story or task, and with very frequent deployments, DevOps can reach single piece flow.

So we find ourselves in a position where we are governing at the project level yet executing at the individual requirement level – a somewhat disturbing mismatch. The consequence is that we are forced to hold requirements in inventory, so to speak, or plan in large batches of requirements.

In order to make a business case and present an adequately sized business proposal to the steering committee, we still need to assemble a large batch of requirements. In order to report on the status of – what? – something that can have a status, I suppose, we still report on the status of projects. We forego, in other words, the full benefits of DevOps – the ability to work leanly by reducing our batch size.

But how else can we govern? What exactly can a steering committee greenlight, and how does it know how that thing is progressing?

I'd like to suggest that the answer is simple and staring us in the face. Or rather, answers, because I believe there are two approaches. The first is to govern by business objectives. We determine a business objective that will have concrete business outcomes, preferably measurable ones. Then we make a business case – formal or informal – that therobjective is worth investing a particular amount of money in. If we decide that it is, we hand the objective to an empowered team and ask them to start accomplishing it – immediately. Because we are in a DevOps world, they should be able to begin deploying functionality virtually right away. We observe the business results they achieve, determine whether they are worth continued investment, and adjust our plans.

The second alternative is to govern IT investment the way we govern the rest of our company – without a governance process. The IT organization is allocated a budget and expected to make good decisions on how to spend it to accomplish the company's objectives. It is assessed and guided like any other part of the company – let's say that the CEO evaluates the CIO's performance and gives feedback to steer IT's direction. What is evaluated is the business outcome of the IT organization's decisions. The advantage of this approach is that it allows for continual transformation, continuous investments in systems, rather than the periodic, on-again-off-again flow of investment when we organize around projects.

It's one thing to reap operational advantages from DevOps. It is a different thing to maximize the value that DevOps can deliver to the enterprise, strategically as well as tactically. For that, we need to rethink governance.

Mark Schwartz, Enterprise Strategist at Amazon Web Services (AWS), is the Author of "A Seat at the Table"

The Latest

June 21, 2018

DevSecOps is quickly gaining support and traction, within and beyond information security teams. In fact, 70% of respondents believe their culture can embrace the change needed to fuse Security and DevOps, according to a new survey of 80 security professionals by Aqua Security ...

June 20, 2018

The larger the company size, the higher the proportion of low IT performers, according to the State of DevOps: Market Segmentation Report from Puppet, based on the 2017 State of DevOps Survey data ...

June 18, 2018

An overwhelming 83 percent of respondents have concerns about deploying traditional firewalls in the cloud, according to Firewalls and the Cloud, a survey conducted by Barracuda Networks...

June 14, 2018

Despite the vast majority of cloud management decision-makers believing that DevOps and microservice enablement are important, very few believe that their organizations are capable of delivering them today — a gap that is costing the average enterprise $34 million per year, according to new report from the Ponemon Institute ...

June 12, 2018

Dev teams are doing their best to give the customers what they want, but oftentimes find themselves in between a rock and a hard place. Teams are struggling to get up to speed with new tools that are meant to make their lives easier and more realistic to hit deadlines. With spring cleaning season upon us, take time this season to tune up agile processes and continue the work of advancing the shift towards DevOps ...

June 11, 2018

The ability to create a culture of DevOps is critical to any organization's ability to deliver applications and services at a high rate of speed, but can we clearly and concisely answer the question: What exactly is DevOps? Despite the best intentions, some large companies are struggling to understand what DevOps actually is, and what it takes to fully implement its concepts and reap its benefits ...

June 07, 2018

The Twelve-Factor App is a methodology that offers a 12-step best practice approach for developers to apply when building software-as-a-service apps that are both scalable and maintainable in a DevOps world. As software continues to be written and deployed at a faster rate and in the cloud, development teams are finding there is more room for failure and vulnerabilities. This blog series will discuss how to build a Twelve-Factor app securely ...

June 05, 2018

Everyone understands the importance of code quality for applications, particularly when DevOps results in releases becoming faster and faster, reducing the room for error. The same issues increasingly apply to databases, which are a vital part of DevOps workflows. Fail to integrate the database into DevOps and you'll face bottlenecks that slow down your processes and undermine your efforts ...

June 04, 2018

DevOps and security traditionally have been siloed functions and security is often seen as a policing function by DevOps team members. However, more mature business leaders are trying to bridge the gap between the two functions to achieve business excellence. This theme was evident from our recent survey where 39% of respondents cited that DevOps and development teams care greatly about their cybersecurity posture, showing that the silo between security/IT and development teams is diminishing ...

May 31, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on the top tools to support DevSecOps. Part 5, the last installment, offers some final thoughts about "tools" that are not necessarily technology ...

Share this