Ops, just get out of the way

Share twitterlinkedinmail

I recently read an article that described an “evolved” DevOps environment.  If I understood it correctly, in an evolved DevOps environment, the role of Ops is to put core services in place, and then get out of the way.

The argument was that generalist DevOps teams may not want to be in the business of running the infrastructure and platform – and may not have the necessary skills anyway to do so efficiently.   The author stated that in an evolved DevOps environment, the Ops team’s role is “to provide core platforms and capabilities for developers, support them, but largely stay behind the scenes.”  This will allow Dev to focus on application architectures, developer workflows, tools, and how the company builds applications. [1]

Now I’m all for progress and continuous improvement.  I’m always open to new ways to innovate and deliver business value.  But for Ops to “just get out of the way” seems counter to everything I’ve read and learned about the philosophy behind DevOps.  For Ops to be subservient to Dev… just sounds wrong.

It seems to me that an organization investing time and energy in DevOps wants (requires?) its IT organization to better collaborate.  Why then would that organization then make a deliberate decision to revert to a state where Dev and Ops do not have to interact as much? I thought that one of the core premises of DevOps was to tear down this so-called “wall of confusion” between the Dev and Ops teams.

I suppose that when Ops does its job well, it becomes invisible from the customer perspective.  But that doesn’t make Ops any less important in the value stream to the customer.

But “get out of the way”?

If Ops simply is expected to get out of the way, that seems to me to be the first step down a slippery slope of IT reverting back to working in silos.

Ops is “the man behind the curtain”      

One of the objectives of DevOps is to improve the velocity of IT.  Velocity, by definition, is “speed with direction”.  Dev and Ops, collaborating as a team, can delivery velocity; but one without the other just results in misaligned effort.

But DevOps must be more than just velocity.  This is where business relies on the skills and expertise of Ops to deliver the “must haves” for any use of technology – reliability, resiliency, consistency, capacity, continuity, and stability.

Perhaps Ops should be thought of as being the “man behind the curtain”.   If you’ve watched the Wizard of Oz, you’ll recall that it was the “man behind the curtain” that made Oz so great and powerful.

Ops is the component that ties everything together – not only the applications from Dev, but also security, software, infrastructure, governance – and delivers the critical “last mile” between the solution and the consumer that is so important to the user experience.  Applications, security, user interfaces – all are useless without the contribution from Ops.

Maybe it should be “OpsDev”?

A DevOps approach values velocity and collaboration. But many organizations look at DevOps as a way to make frequent changes.  If the focus of DevOps is only on making frequent changes, the workload for Ops increases, or worse, results in Ops becoming a bottleneck.

Maybe we’ve been looking at this all wrong.  Maybe the right approach is “OpsDev”.

OpsDev begins with the end in mind.  DevOps typically focuses on challenges from the developer perspective, focusing on issues like how to push changes and code.  Rather than push changes from Dev to Ops, perhaps the right approach would be to have Ops pull changes from Dev to progress code from environment to environment.

By starting from the Ops perspective, the team can first ensure that the infrastructure considerations – resiliency, consistency, capacity, continuity, and stability –  as well as the various application and security components, are all understood and modeled before development begins.  The environments in which the components will be deployed for production can be modeled. With this information, the procedures for deploying components to target environments can then be modeled, scripted, and automated as much as possible. By doing the above, the development team can replicate the application and environment models and automated procedures consistently.  As a result, the development and test teams will know and understand the production constraints and parameters early on, allowing the applications to be developed with those constraints and parameters in mind.[2]

The right role for Ops?

So, what is the right role for Ops in a DevOps world?

Is it simply to setup core services then get out of the way?  Should Ops be subservient to the other parts of IT and just take and fulfill orders?

If Ops is relegated to a subservient role of “order taker”, or is expected to just get out of the way, I would call that ‘waste’ – the underutilization of a skill set. Operations is a skillset – no different than development or design or security – that is critical for business success.  Ops is not more or less important than any of the other components.  But Ops cannot become relegated to the ‘back room’.

My conclusion is that Ops must be a valuable and equal contributor in a DevOps environment.  Here are a few ways that Ops should contribute:

  • Platform Provider – Ops must think in terms of self-contained platforms, and not just integrated components. Platforms must be complete with basic monitoring, alerting, and the appropriate levels of redundancy and resiliency.
  • Service Provider – Perhaps Service Desk as a service? There’s an interesting potential here for providing a single point of contact, not just for IT, but for other business functions within an organization as well, providing the capability for managing workflow across an entire value stream within a business.
  • Process and automation engineer – Who better than Ops to drive repeatability, consistency, effectiveness, and eliminate waste within IT? But Ops should take this one step further and design the techniques and tools that ensure repeatability, consistency, effectiveness, and efficiency.

Ops can only take on these roles when it is involved from the beginning of the development cycle.  Ops must be involved with the strategy and design of software development.   It takes both Ops and Dev to deliver the user experience demanded by the business – doing one without the involvement of other is waste.  Dev and Ops must collaborate – not stay out of each other’s way –  throughout the software development cycle with this common goal in mind.

Find the right way forward for ITSM and DevOps within your organization with our “Next Generation ITSM” consulting services.   Contact Tedder Consulting today!

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit:  The Wizard of Oz, MGM, 1939.

[1] Haff, Gordon.  “DevOps success: A new team model emerges”. The Enterprisers Project. 6/14/2017. Web. Retrieved 8/7/2017.

[2] “OpsDev is coming”. TechTarget: IoT Agenda.  8/2/2016. Web. Retrieved 7/31/2017.


Share twitterlinkedinmail

6 thoughts on “Ops, just get out of the way”

  1. Great article Doug. Either way you go Dev push Ops and/or Ops push Dev to continue to learn from one another and support our customers. At the same time, we are growing as teams, pushing one another and hopefully at the end growing our business.

    1. Thanks Connie for reading the article and for your comments. I would agree – DevOps can only be successful if Dev and Ops are working together and growing as a team.

Leave a Reply

Your email address will not be published. Required fields are marked *