Is Outsourced Operations a DevOps Anti-Pattern?

In theory, outsourcing offers many benefits, from labor elasticity to economies of scale. It has the potential to release more management time and mindshare for the things that matter — things that contribute to customer value or competitive advantage.

Yet the large scale functional outsourcing of IT services in previous decades often failed to deliver ROI. And for some, the reputation of any IT outsourcing remains tarnished by association.

Conversely, few modern businesses would question the benefits of using cloud computing. Letting a hyper-scale cloud provider handle the heavy lifting associated with traditional IT infrastructure and operations is standard practice these days.

So, why are some technology leaders reluctant to work with third parties for the remaining management overhead, even when using a cloud-based infrastructure? Is all outsourcing inherently flawed, or can outsourced operations management be effective when combined with modern ways of working? In short, is it possible for a business to embrace DevOps principles to unlock those theoretical benefits of outsourcing without creating additional problems?

To answer these questions, it’s worth clarifying what we mean by DevOps and looking more closely at the challenges associated with outsourcing.

DevOps defined

It is also possible to implement highly effective DevOps practices while running separate infrastructure and operations teams. This is clearly evident in Site Reliability Engineering (SRE) where software engineering principles are applied to IT operations in a forward-thinking operating model. You don’t need to be the size of Google to make it work either.

Challenges with outsourcing

Seven sins of functional outsourcing:

  1. Handoffs — every time we hand over from one group to another, we lose information and context. That’s an inescapable fact of human communication. Lost information leads to defects, lower quality, and waste.
  2. Handoffs also result in queues, which mean more waiting and more waste.
  3. Batching of work — handoffs and queues result in larger batches of work, which means longer lead times and increased cost of delay. This is compounded by the high transactional cost of taking work from one silo to another: people are incentivized to batch work to reduce costs. So high-value and low-value features get lumped together, and all work — whether high or low value — is delivered at the same (sluggish) pace.
  4. Silos optimize locally, focussing on the goal of the silo (like ‘100% uptime’, or ‘ship more features faster’, to choose extreme examples). This can ignore the goal of the system (happy customers who spend more money).
  5. Friction and blame — local optimization for local goals, the inevitable defects arising from handoffs, and delays caused by queues and large batch sizes reduce trust between functional groups. Low trust environments tend to give rise to more rigid contract structures and greater scrutiny. This adds further overhead and contributes to spiraling costs, delays, and inflexibility.
  6. Lack of contractual flexibility — the functional division of responsibilities can also inhibit agility. Once contracts have been signed, changes to specifications are difficult to manage across external silos.

Functional alignment vs product alignment

Today, progressive organizations generally opt for cross-functional, multiskilled, product-centric teams. Each team is as self-sufficient and autonomous as possible. Dependencies on other teams are kept to a minimum and they pretty much handle the entire product lifecycle. By reducing handoffs and keeping work in one place, the negative impact of silos is greatly reduced: everyone is focused on the same objectives and target outcomes.

If you can maintain all the capabilities needed to build and run everything customers demand within a sustainable team of seven plus or minus two people, then this is probably the way to go.

But this is rarely possible.

Smaller businesses often need specialist skills beyond those that can feasibly be maintained in-house. In fact, hiring specialists too early is a sign of premature scaling, which results in business failure for 70 percent of scale-ups. What’s more, many businesses need flexible capacity and don’t have a permanent requirement for Kubernetes architects, for example.

Larger businesses will inevitably need more than nine people, which means multiple teams. With teams aligned to products, rather than functions or projects, handoffs can be minimized to improve effectiveness. But once you move beyond a handful of product teams, the dynamics change, and new challenges emerge. This is the time to think about introducing advanced capabilities such as self-service platforms (to avoid repetition between teams) and SRE (to protect teams from unplanned work). We cover these areas in more detail in a separate blog about cloud operating models.

So, is outsourced operations a DevOps anti-pattern?

Sophisticated, modern operations management that’s fit to support the business-critical applications of technology companies demands a specialist skillset. And if you can’t hire it, or don’t want to hire it yet, partnering with a digital-native operations expert is the best way forward.

We, "NovelVista Learning Solution" have expertise in providing high end training & Certification programs for ITIL®, PRINCE2,PMP, SIAM, Cloud, AWS, Devops etc