Many IT and DevOps shops always look at governance as a dirty word because it sounds too much like government, which sounds too much like bureaucracy and waste. The problem with governance is not with governance itself, but with how organizations have tried to implement (or not implement) it. Gartner defines IT governance as
…the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals.
That doesn’t sound so scary now does it? Yet very few organizations have done a good job of enforcing the policies, procedures, and architecture principles required for IT to ever achieve its mighty goals. Until now.
The DevOps movement is focused on delivering reliable code and doing it faster than ever before. To accomplish this goal, DevOps takes a chapter out of lean manufacturing and focuses on identifying bottlenecks in the SDLC (software development life cycle) and removing those bottlenecks, mostly by automation. The DevOps movement has brought things like security, policy enforcement, test driven development, continuous integration and deployments, and many other quality initiatives to the forefront. In essence, DevOps is automating many of the things that we have always hoped to drive into the organization through governance.
So let’s go back in time to put this in perspective. For those of us with a lot less hair who lived through the mainframe days, you will remember this. Back in the mainframe days, nothing went into production without going through the people who managed the mainframe. These folks had an amazing amount of veto power. If you did not follow their processes, which often included following a set of design and coding best practices, filling out the appropriate paperwork with the appropriate approvals, and bringing with you the change log and test results, your code was not going into production. Back then I called it a dictatorship, but it really was a manual form of governance.
When the PC era hit we were all freed from the tyrants, and we could deploy stuff like crazy all over the enterprise on machines everywhere. This became the start of IT chaos as we still know it today. Ungoverned software designs and deployments became a way of life in many organizations, creating much waste and lowering quality.
Enter the cloud and DevOps. Before the cloud, the only saving grace was that it took us so long to procure and set up servers that sometimes we had a chance to catch wind of the next chaotic ungoverned thing that someone was attempting to deploy into production. With the cloud, provisioning resources can be performed in minutes. Luckily, some smart folks looked at the possibilities of automating infrastructure and software deployments together as one and at how agile we could become if we could control and automate the entire SDLC, and hence the DevOps movement was born to pull us out of all the chaos.
DevOps was not born out of the desire to implement governance; it was born because people were tired of being on call 7x24x365 supporting low-quality applications that took forever to build and deploy. As the DevOps movement continues to grow and the adoption of quality and automation initiatives continues to attract fans, we finally are starting to get a taste of governance that does not taste like week old leftovers. If you were to take a poll you would find that DevOps is cool, governance is not. But under the covers, DevOps is enforcing standards, quality, automation, culture transformation, proactive monitoring, and all of the things that we have been trying to govern all along.
So I ask, is DevOps finally getting organizations to see the value of governance? I think so. As long as we don’t call it governance.