June 10, 2014

As we look at enterprises adopting DevOps (yes, enterprises are adopting DevOps, in droves), the question regarding outsourcing always comes up. Many (read: most) enterprises have at least some of their application delivery or IT operations outsourced to an external vendor. This may be the traditional ‘offshoring’ where work is offloaded to an external, offshore and usually cheaper provider; to a true supply chain model, where external and internal providers deliver components of the application delivery supply chain. Both scenarios have a significantly different impact on DevOps adoption. (Yes, I am over simplifying outsourcing, but it serves the purpose for this discussion).

Strategic Outsourcing:

This is the scenario where an enterprise decides that it is cheaper or from a business perspective, better to outsource all or part of their application delivery to another provider, which excels in that space. This decision to outsource may be done due to cost reasons or due to the simple fact that the organization believes that it does not need to have that capability in house. It is better to hire someone to deliver it. The commonest example would be a company hiring an organization like IBM to run its data centers. The organization chooses to not hire staff to run data centers. It makes sense to let IBM do it. Another example would be a retailer hiring an external vendor to build and deliver its mobile apps. Again, they may have strategically decided that these are capabilities they do not have in-house. Instead of building a new mobile team from scratch, lets have a company that provides mobile app building as a service, deliver it.

In the latter scenario, DevOps is not that much of a problem. When you outsource an entire application, you outsource the delivery pipeline too. If the entire mobile app development is outsourced, the DevOps part remains limited to ensuring that the movie app can access the back-end systems it needs to, hopefully thru well defined and managed APIs. Now in the first scenario, if you build an application in-house and deliver it to a production environment managed by an external vendor, you need to do a hand off and receive the appropriate feedback to improve continuously. If the contracts are not set in stone, a Continuous Delivery model can be managed with the external vendor partnering with the organization.

I am not trivializing the planning and collaboration that needs to be done. But if the external vendor is a true partner, this can be achieved. The enterprise in question still needs to ‘own’ the portfolio management, planning, release management and governance of the application being delivered. And yes, if the vendor is not willing to partner and/or the contracts and set in stone and cannot be amended to provide for a ‘DevOps’ style model of collaboration without lawyers getting involved – you are up the proverbial creek without a paddle. You may put away your ‘DevOps for Dummies‘ book and find one titled ‘Contract Negotiation For Dummies’.

Supply Chain:

The DevOps adoption challenge become more interesting in a supply chain model, where an entire applications delivery ’s not outsourced, but individual components are being delivered by separate providers in the supply chain. These may not all be external suppliers the enterprise has outsourced to. More than likely they will be a combination of internal and external providers. Internal providers are easier to deal with. Barring politics and lack of buy-in from senior management, one can apply the DevOps principles to get the suppliers on-board. Best practices like creating a central enterprise-wide ‘DevOps Center of Excellence’ and developing internal DevOps evangelists, go a long way in getting the required buy-in.

If you have external providers, the situation can become tricky. Multiple providers developing and/or testing individual components leads to a many to many coordination and collaboration needs. Contracts get in the way. If two providers cannot communicate directly with each other and have to always go thru you the enterprise, you have a problem. If every time you try to make a change based on feedback, as required for DevOps adoption, the vendor pulls out their contract and/or charges you a change fee, you most certainly have a problem. I recently met with a customer whose external provider for Dev – Test environments charges $10,000 for each change to the base VM image. They can’t afford to make adjustments to their environments – ‘production like environments’ are not an option.

The only solution here is to seek to get the external providers to see their value in working with you to adopt DevOps. If they see the value in the efficiencies and reduction of waste DevOps can bring to them, and allow them to deliver higher quality software in lesser time, with fewer resources, that may win them over. If however, their contracts are written in a way that faster delivery, more efficient delivery or fewer people needed hurts their bottom line, not much can be done.

Your mileage may vary

So, is outsourcing the death of DevOps? Or DevOps the death of outsourcing? Not at all. Organizations cannot have all the IT skills they need in house. They will need to bring expertise in from external vendors. Outsourcing is here to stay. The advent of DevOps and the need to collaboration, agility and responsiveness to feedback that is needed to adopt DevOps goes to say that future contracts will be written with these goals in mind. This is not an unreasonable expectation. System Integrators I interact with are seeing that already in RFPs they are receiving from enterprises looking to partner with them on a DevOps journey. This is really not an option. With all the external pressures – lowering costs, need for innovation at speed and the need to be more agile and responsive to the market is compelling enterprises to adopt DevOps. It is also compelling outsourcers to change how they evolve from suppliers to partners for their clients. DevOps, in my opinion will bring on the next generation of outsourcing.

Related posts: