5 Ways a Deployment-Only Focus Puts Your DevOps Efforts at Risk
Posted by Damon Edwards     December 22, 2017 IT Operations

post-deployment-operations-strategy-1.jpeg

Much of the DevOps conversation within enterprises focuses on getting products deployed quicker. "Deploy, Deploy, Deploy" is a common mantra, but what happens after deployment? How are you going to handle incidents? How are you going to scale? Who is going to do the operational work? How will they keep up as the cadence of deployments accelerates? Falling into the trap of thinking deployment is your finish line can doom your DevOps efforts.

At Rundeck, we see a lot of companies undergoing DevOps transformations. Here are the 5 key reasons we've seen DevOps initiative falter if equal emphasis is not placed on the pre- and post-deployment lifecycle stages:

 

1.  Forgetting that delivery is only one part of the end-to-end lifecycle.

Build to deployment is only a small part of the lifecycle of a service. This should go without saying, but you would be surprised how often this fact is overlooked or ignored. With the fixation on meeting delivery goals (often incentivized by business goals), post-deployment planning is often unofficially relegated to the "we'll figure that out later" category.

It is easy to lose sight of the fact that production operations is the portion of the lifecycle that matters most to customers. If the service isn't running and performing to expectations, what good are any new features? 

Operational excellence is essential to deliver on your DevOps goals. How will you monitor performance? How will you respond to incidents? How will you scale? These questions need to be answered as early in the lifecycle as possible. In high-velocity organizations, operational excellence starts during design and development. Following the traditional model of "putting off" investing in operational concerns until after deployment is a recipe for DevOps failure.

DevOps_too_much_dev1.png

 

2. Focusing on automation over collaboration

Improving collaboration and information flow is as critical to the success of your DevOps improvement efforts as automation. Moving the bits from point A to point B is the easy part. It is the policy, information, process, and tooling mismatches between different teams that continuously trip up an organization. When organizations focus only on getting to deployment, they aren't addressing the most expensive handoff, miscommunication, and rework problems that are plaguing their company.

To be clear, optimizing the dev, test, and deploy cycles of your delivery team is almost always a good thing. However, in an enterprise, nothing lives in isolation. If information is trapped inside those delivery teams, the classic bottlenecks and conflicts between development and operations don't go away. At best, the new shiny automation will replicate those existing problems. At worst, the pre-existing problems are going to be amplified.

Instead, focus on coordinating automation efforts across the entire lifecycle, so that collaboration and information flow are made easier. Deliver consistent automation that helps everyone collaborate on building, testing, deploying, and running high-quality services.

DevOps_collaboration_over_automation.png

 

3. Ignoring the destructive effects of request queues

Improving the flow of work before deployment without also improving the flow of work after deployment leads to the use of request queues (in the form of ticket queues) to manage the handoff between Dev teams working the new way and Ops teams working the old way.

While this may seem like a common-sense stopgap measure, request queues have a high economic cost and are generally corrosive to the health of an organization. Request queues result in long cycle time, increased risks, more variability, increased overhead costs, lower work quality, and reduced motivation.

When one part of an organization (Dev in this case) is optimized to move quickly under a continuous flow model, and the other part of the organization (Ops in this case) is not, we can expect long request queues to build up between the different parts of the organization. We know from a long history of queuing theory research in Lean and Agile that, the longer the request queues, the more destructive they are.

Request queues are destructive as they result in long cycle time, increased risks, more variability, increased overhead costs, lower work quality, and reduced motivation.

Only with a holistic view of development and operations activity can you design a flow of work that avoids the handoffs that lead to problematic requests queues. Wherever those handoffs can't be avoided, you will want to implement countermeasures, like Operations as a Service, to counteract the harmful effects of the request queues.request queues cause.png

4. Not amplifying the Ops to Dev feedback loops

One of the core ideas exposed by the research of Gene Kim (and his subsequent DevOps Handbook collaboration with John Willis, Patrick Debois, and Jez Humble) is that amplifying feedback loops is critical to organizational success. In fact, it is #2 on of their "Three Ways" DevOps methodology.

As Gene states, "The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made. The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it."

An organization that focuses on only optimizing the pre-deployment parts of the lifecycle aren't able to amplify or shorten the Ops to Dev feedback loops. Without those feedback loops, your improvement efforts are essentially flying blind.

operations-feedback-loop-1.jpeg

 

5. Missing the opportunity to rethink how Ops activity gets done and who does it

In the quest to shorten feedback loops and avoid unnecessary handoffs (and destructive request queues), high-performing companies are rethinking how they structure their technology organizations. Instead of the traditional method of dividing people up by functional silo (Dev, QA, Ops, etc.), they are using design patterns like cross-functional or product-aligned teams wherever possible. Rather than having a one size fits all approach, these organizations have experimented with different options and found what works best to optimize the flow of work within their organization.

Organizations that are focused on getting to deployment and aren't prioritizing what happens after deployment are missing out on the valuable learning experience. In most cases, you will find that a sub-optimal org structure will live on far longer than necessary if you aren't equally focused on improving the pre-deployment and post-deployment parts of the lifecycle.

DevOps_workshop1.jpg

 

OaaS, Rundeck, and Your Post-Deployment Improvement Strategy

I hope I've made a case for the importance of focusing your DevOps improvement attention across the full lifecycle of your services. The Operations as a Service (OaaS) design pattern can help you get rid of destructive request queues, improve collaboration, and improve feedback loops. 

With OaaS, those people who are closest to the problem have the authority to get things done. OaaS also makes it easy to safely distribute operations activity across your organization in ways that you might have thought weren't previously possible. 

For more on OaaS and how Rundeck can help your implementation, read our deep-dive guide here.

New Call-to-action