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

February 15, 2018

Organizations are focusing investments on security and analytics, while actively researching emerging technologies such as machine learning and artificial intelligence, according to the 2018 CIO Tech Poll: Tech Priorities survey ...

February 14, 2018

With so many other initiatives to manage, DevOps isn't a top priority for all companies now. Many organizations believe it's wiser to wait. But in fact, the business case to integrate now is very strong — in fact, it's "do or die" territory. This infographic outlines some key reasons why organizations should integrate their software delivery value stream immediately ...

February 12, 2018

Accelerating multi-cloud deployments are enabling organizations to select the cloud platform that best meets the requirements of a specific application, according to the 2018 State of Application Delivery report from F5 Networks. However, this also increases the challenges many companies face in managing operations and security across multiple clouds as they transform their application portfolio to compete in the digital economy ...

February 08, 2018

The slowness of enterprise IT departments to embrace automated, cloud-native solutions for the cloud infrastructure challenges they face has resulted in IT infrastructure that is often ungoverned and insecure. And this is despite the fact that the cloud can be more secure as traditional data centers ...

February 06, 2018

Bank IT teams must embrace that their DevOps capabilities will determine their agile capability. Agile breaks down the barrier between the business and IT, and operations must be treated as a critical element of an agile program. In modern software delivery, the business, development and operations must execute as a unified team. To achieve this, banks are increasingly turning to Continuous Integration (CI) practices as part of the solution ...

February 05, 2018

IT professionals show a heightened concern for cybersecurity risk related to API use, according to a new survey conducted by Imperva. Specifically, 63 percent of respondents are most worried about DDoS threats, bot attacks, and authentication enforcement for APIs ...

February 01, 2018

DevOps are pretty clear for application development, those same applications often have a database back-end. If DevOps is increasing the frequency and reliability of new features for applications, a slower pace of database development can slow down and hinder those same releases ...

January 30, 2018

Without a doubt, DevOps is becoming the go-to strategy for organizations of all industries and sizes looking to master digital transformation and provide the fastest value to customers through software delivery. It is becoming clear that organizations adopting DevOps need a true leader (or engineer) to keep the transformation on track. The following are some tips when hiring for DevOps ...

January 29, 2018

When was the last time your company experienced a significant database error? If it happened in the last 3 months, you’re in good company. In a recent study, 60% of respondents reported a crash or significant database error occurring in the last 6 months. Roughly one in ten respondents reported a serious database problem in the past week ...

January 25, 2018

You've already recognized that business transformation requires digital transformation. Your organization is staffed with the best and brightest developers ready to implement the innovative, business-differentiating technologies you need to attract, engage, and retain customers. And you've invested in scaling Agile, driving DevOps adoption, automating the Continuous Delivery pipeline, and all the other components involved in moving from ideation to delivery as rapidly as possible. So what could possibly go wrong? Testing ...

Share this