The Great Wall of IT

Hopes and Dreams

When I think of the hopes and dreams that DevOps and Site Reliability Engineering, or SRE, were intended to bring us, it saddens me a little that people think it’s all about automation. This is only one element of what is in large part an entire cultural shift in the way we do things – or at least it should be.

In this article, I will identify 3 cultural challenges that should be faced before implementing any automation  – Roles, Organization and Failure.

For decades, the method for the Software Delivery Lifecycle has operated as an incomplete Deming Cycle, which is a simple cycle of Plan – Do – Check – Act. In practice, much of the Software Development Lifecycle has been a one-shot Plan, a much-repeated Do-Check cycle, followed by single one-shot, big-bang Act. Typically, the planning followed by cycles of Do-Check have occurred in the Dev world, and when Dev is ready, it has thrown the lot over the Great Wall of IT for Ops to Act. We had dreamed of a better world.

The Real World

The Deming Cycle has been much more effectively implemented for Agile, mostly in the Dev domain. Developers have reduced change risk to production systems through smaller incremental changes, but that Great Wall of IT still exists. Often I’ve seen development squads run iterative Deming Cycles and produce releasable content at the end of a series sprints. Those many releases are accumulated into a single one-shot, big-bang Act for Operations to support.

DevOps is supposed to be the Great Wall Buster*. Its intent was to crash through that wall to ensure much faster delivery. While speed has increased, there’s also been a problem: It’s not so much that current DevOps transformations have broken down the wall, it’s more correct to say they’ve created a one-way fast track gateway!

Divided We Fall

DevOps automation toolchains have done a fantastic job of fast-tracking those risk-reduced iterations, but the speed, communication and collaboration paths are still one-way to delivery. Those paths are still ‘pushing’ the Act requirement onto Operations. Not surprisingly, much of the early sponsorship for DevOps has come from Development teams already reaping the benefits of Agile transformation. Operations resources have then been delegated the task and responsibility of acting.

The response from Operations to meet the demand and cadence of change in DevOps, while ensuring production reliability, is seen through SRE. As with DevOps, the pillars on which this discipline depends can be easily correlated to those in DevOps. However, Operations typically motivates and drives implementations.

The result is something all-too-familiar: Development pushes a DevOps agenda, Operations pushes an SRE agenda, and despite both having the same founding principles, that Great Wall of IT is still standing.

The Great Wall of IT should not be seen as a technical barrier, a business barrier, or even a process barrier – it’s a cultural barrier and possibly the hardest one for us to break down, but fundamentally, the most important.

United We Conquer

The first challenge is that organizations must remove the concept of siloed job roles, while also ensuring that people retain their identity through skills and specializations. Let’s replace ‘not my job’ pre-conceptions with ‘we can do anything’. We must simultaneously respect that each individual has their own role to play, their own unique skills and strengths they bring to an organization.

This should be the basic premise for the second challenge, where we build one collaborative team and not two teams, labelled development and operations, divided by a cultural barrier. In this team we can ensure that operational support is considered and baked in from Day One, and that everybody owns the responsibility for ensuring quality development.

The Final Challenge

What remains once we have conquered our cultural adversity? It’s the acceptance of failure as part of our Software Delivery Lifecycle and the inclusion of feedback into our flow automation. With the acceptance of failure comes learning, development and growth. It enables higher quality systems and enhances our knowledge. This final challenge is one that deserves more time and detail and I will cover in a later blog.

Stephen Walters, Solution Architect, xMatters inc.

*The DevOps Handbook, Chapter 7, “How to Design Our Organization and Architecture with Conway’s Law in Mind” (Gene Kim, Jez Humble, Patrick Dubois, John Willes)