A few weeks back, my colleague Evan Riser and I held a webinar introducing the five disciplines of governance from Microsoft’s Cloud Adoption Framework. This blog post is the first in a series expanding on those concepts. If you didn’t get a chance to see the webinar, check it out here, but to quickly recap, the five disciplines are:
- Security Baseline
- Identity Baseline
- Cost Management
- Resource Consistency
- Deployment Acceleration
Today I’m going to focus on the last of those, Deployment Acceleration, as it really should be top of my mind for every IT leader. While there are many reasons to move to the cloud, delivering positive value back to the business, must be our guiding star. If we don’t significantly contribute to business success by creating the conditions for the business to use technology to innovate, we are just a cost center and can do nothing more than watch our budgets and our influence dwindle. By focusing on Deployment Acceleration, we have the opportunity to do more than constrain risk or manage costs. We can create positive business value, and in doing so, gain enough momentum that we might just be able implement some of the other disciplines at the same time.
So that’s the why, but what do we mean by Deployment Acceleration. Deployment Acceleration is the discipline of leveraging automation, self-service, templates and a fanaticism for delivering incremental value to compose your cloud environment. The technical skills include fluency with things like PowerShell, ARM templates, Azure Blueprint, Service Now and Terraform, but perhaps more important is the mindset. To deliver this to the business, you need to develop a consulting or product-oriented mindset. The automation templates that you create need to be driven less by what you want to control, and more by what the business wants to accomplish. You want development teams using your templates because they are so amazingly fit for purpose rather than because they have no alternative. Reducing friction rather than creating friction must be your mantra. And if the templates aren’t getting used, rather than asking yourself how you can force the organization to use them, you need to ask yourself what you can do to make your product good enough that the organization is dying to use it.
This is a monumental shift for IT organizations, and it may seem counterintuitive to include this under the broader category of governance, which has typically been about constraining risk. Indulge me in a metaphor that may make this clearer. The major control plane on a boat is typically a rudder. But that rudder depends on external thrust to actually work. On a boat that isn’t moving, the rudder does nothing. It’s called loss of steerage, and it’s why an engine failure on a boat can lead to sinking. Your governance controls suffer the same limitation. If the organization isn’t moving, the governance controls aren’t doing anything. And before someone says, “That’s the point of our governance, we are trying to prevent cloud adoption” I’d like to point out that the vast majority of organizations have a cloud strategy, and if you think you are preventing the business from using the cloud, they are probably going around you. You may have lost steerage, and in losing steerage, you’ve also lost the opportunity to be a positive contributor to business value.
The next part of this five-part series “The Five Disciplines of Cloud Governance” will cover Resource Consistency.