Operations is Dead, but Please Don’t Replace it with DevOps

OK, so the title is provocative, but bear with me here. Recently I spent a mind-expanding day at DevOpsCon in Israel – I presented the first keynote, which aimed to set the scene for why DevOps is a necessary reaction to some broad organizational and technological changes. What was really interesting however was to hear a range of presentations from different people, all reflecting on what DevOps means for organizations. And there truly was a cross section of people – from dyed-in-the-wool operations practitioners, to development leads, from business users to CIOs, the day ran the gamut of the vested interests involved in the broader operations arena.

And at the end of it I was left with a slightly nervous feeling that in advocating the rise of DevOps, we run the risk of removing one archaic and broken system, only to replace it with more of the same.

The worrying thing was the hallway comments from people who were attending the event in order to formulate a plan to “implement a DevOps team” within their organization. That entire aim missed the point of DevOps as an organizational trend. I spent 45 minutes or so talking about how broken current approaches are – siloed teams, each with differing motivations and areas of focus doesn’t deliver consistency. Neither does the fact that these teams are generally talking in different languages, at cross purposes and with wildly different priorities.

To simply rip this out and replace it with a siloed DevOps team doesn’t help that at all. DevOps isn’t about particular toolsets and neither is it about implementing a black ops team to go around operational turf protection. Rather DevOps is a humanistic movement, one which should be almost completely focused on communication, on bridge building and on the identification of common interest. My frustration was lessened somewhat after reading a post by Jez Humble on the subject. Somewhat confrontationally entitled “There’s No Such Thing as a “DevOps Team”, the core thesis of the post was that

the Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems. Devops proposes instead strategies to create better collaboration between functional silos, or doing away with the functional silos altogether and creating cross-functional teams (or some combination of these approaches).

In this modern world, where the delivery of agile solutions on an ongoing basis is a non-negotiable requirement for success, organizations need to set themselves an objective to cross functionalize as much within their organizations as possible. This is part of the reason that every step up the stack delivers incremental benefits. Automating infrastructure deployment does much to build bridges between application operations and systems operations teams, and creates common goals where formerly they were hard to identify. Similarly the move from infrastructure up the stack to PaaS all of a sudden means that development and operational tasks are developed and achieved with commonality.

Individual functional silos increase the occurrence of problems. Why? To revert to the previously mentioned post:

…functional silos often get created in reaction to a problem (which they inevitably exacerbate). At the beginning of an interview with Elisabeth Hendrickson I posted recently, she discusses working at a product company which was suffering a series of quality problems. As a result, they hired a VP of QA who set up a QA division. The net result of this, counterintuitively, was to increase the number of bugs. One of the major causes of this was that developers felt that they were no longer responsible for quality, and instead focussed on getting their features into “test” as quickly as they could. Thus they paid less attention to making sure the system was of high quality in the first place, which in turn put more stress on the testers. This created a death spiral of increasingly poor quality, which led to increasing stress on the testers, and so on

Functional silos (and a standalone DevOps team is a great example of one) decouple actions from responsibility. Functional silos allow people to ignore, or at least feel disconnected from, the consequences of their actions. DevOps is a cultural change that encourages, rewards and exposes people taking responsibility for what they do, and what is expected from them. As Werner Vogels from Amazon Web Services says, “you build it, you run it”.

So a “DevOps team” is a risky and ultimately doomed strategy. Sure there are some technical roles, specifically related to the enablement of DevOps as an approach and these roles and tools need to be filled and built. Self service platforms, collaboration and communication systems, tool chains for testing, deployment and operations are all necessary. Sure someone needs to deliver on that stuff. But those are specific technical deliverables and not DevOps. DevOps is about people, communication and collaboration. Organizations ignore that at their peril.

4 Comments
  • Interesting to hear the DevOps movement may be distracted from converging on best practices and principles. A siloed “DevOps Team” is definitely not a step in the right direction.

    DevOps principles and practices combined with PaaS characteristics will quicken IT solution development and delivery. A DevOps focus on continuous activity execution (e.g. continuous build, continuous integration, continuous test, continuous delivery) can create an agile ‘no wait’ environment. Teams do not have to wait for the next script to run or for the next activity to commence. By incorporating automation into developer and operations processes, teams bypass time consuming manual tasks and gain faster phase execution. Both DevOps and PaaS promote simple, on-demand self-service environments that shield team members from complexity and reduce skill hurdles. By offering on-demand self-service access, rapid business innovation and experimentation is possible. By reducing complexity, team members are not required to obtain special training and skills before consuming IT services and infrastructure.

  • Pingback: Devops – It’s about critical thinking & the evolutionary “WHY” of Silos. | Byron Miller

  • ‘DevOps? Perhaps I’m missing something here, but isn’t this just a transient human label (and probably for the HR department’s benefit) to a strategy, effort, and culture to automate every aspect of a modern solution to achieve NIST-like definitions of self-service features, agile scale-out/up, and a lowest cost end-to-end product offering usually via an Internet based online channel? We used to call the pure higher level business automation around this with terms like BPM and ‘Lean Processes’. People have great tendencies to assign new meanings to emerging ‘cloud semantics’ I feel, that are really easily broken down into common sense descriptions of ‘stuff’ we already intuitively know is just part of delivering an online global scale product or service experience today.

  • Interesting article – and all the more important when you realize it’s not just Dev and Ops that needs to be considered. The security team, the compliance team, the legal team, etc. all of these disciplines need to be factored in and not managed as silos. And it’s not just process and communication, it’s having tools that integrate information in a way that is natural for the user of the tool.

    Thanks,
    Mark Troester
    Sonatype
    @mtroester

  • At CollabNet, we are seeing three broad models to try to address the challenges faced by IT.

    The first is, as Ben mentions, a new DevOps organization. This introduces a silo between Dev and Ops, which does not necessarily improve communication or teamwork between all the groups. In these situations, the groups definitely need to work with a platform that tries to increase collaboration between the teams. Even with such a platform, organizations see only incremental improvements with this approach. However, if this new silo is introduced as a catalyst specifically to drive change to one of the other two models then it might make sense. One measure of success is how fast the new group disappears.

    The second model is one where the IT data center drives to position itself as an IaaS or PaaS provider. The development team becomes completely responsible for the operation of applications in production and the data center is treated almost as an external provider. The development teams will need to think carefully about new systems and processes. It is likely that they will need to invest heavily in Continuous Deployments tools and processes. Without this investment there is a risk of perpetuating the Dev and Ops Silos. The Ops team needs to work with the Dev team to define standard target platforms. These platforms need to be versioned and have a lifecycle, they cannot be frozen in time. Measures of success include: Reducing cycle time for Move to Production and Reduced Operational spend as non-standard platforms are deprecated from production.

    The final model is one that was described in Gene Kim’s book “The Phoenix Project” and numerous blogs (including other posts by Ben). This is the more “humanist” approach and works based on a full partnership between the Agile development teams and Agile infrastructure provider teams. This is where we believe the future of the DevOps movement is headed. The results are felt at the business level in terms of improvements to quality of service, reduced cycle times, increased innovation, and lower costs. Measures of success include breaking down silos of information, process and tools as well as people. It does little good to simply bang the two organizations together and re-label it “DevOps”. Anyone who writes code is a Developer, everyone involved in specifying, creating, delivering and operating code in production is in Operations. We are all stakeholders in the end-to-end process from business requirements (User stories) to delivered value (high quality code in production).

  • Pingback: On the Stackholm Syndrome – And in Defense of Traditional IT Vendors | The Diversity Blog - SaaS, Cloud & Business Strategy

  • Pingback: July 2013 Newsletter |Metafor Software

  • Pingback: Operability can Improve if Developers Write a Draft Run Book | Software Operability

  • Pingback: Choose Culture over Tools for Devops Success | UNICOM Seminars

  • Pingback: What Team Structure is Right for DevOps to Flourish? | Matthew Skelton

  • Pingback: Lean Software Development Principle – Deliver Fast | Craig on software development

Leave a Reply