After reviewing the articles (here and here) on DevOps driving the end to outsourcing I felt it would be constructive to provide an alternative point of view. The premise of the article is that because DevOps requires close collaboration between development and operations that it would be difficult if not impossible to effectively implement DevOps in a heavily outsourced environment. Additionally the productivity advantages of DevOps would help eliminate the need for outsourcing. Therefore, organizations wishing to see the advantages of DevOps should move away from outsourcing. While I can see the advantages of that approach, I also think that companies that have to live with outsourcing can’t ignore the benefits from implementing DevOps principles with a well-designed deployment pipeline.
From my perspective, companies looking to implement DevOps first need to start by understanding their architecture because it has such a large influence on how to effectively implement DevOps. If they have loosely coupled architectures that enable small teams to independently develop, qualify, and release code then they should look to the world of unicorns for how to implement DevOps. They should look at integrating operational people onto the development team and work to evolve the culture by blurring the lines and responsibilities between the two groups. This feels like a fairly straightforward process that many unicorns have proved to be very successful. For these types of organizations, I tend to agree with the articles recommendations that DevOps would work better without outsourcing.
The problem is that most large traditional organizations looking to implement DevOps don’t have the benefit of an architecture that enables small nimble teams to work independently. They typically have very tightly coupled legacy architectures that require 100-1000s of engineers to work closely together to develop, qualify, and deploy complex integrated systems. Ideally, they would re-architect their applications so they could see the benefits of nimble independent teams. The reality though is that this is just not practical for most traditional organizations in the short-term. Additionally, they can’t wait for the re-architecture before they start realizing the advantages that DevOps principles can provide with a well-designed deployment pipeline.
For these organizations implementing DevOps principles (the ability to release code to the customer on a more frequent basis while maintaining or improving stability and quality) is more about creating a well-designed deployment pipeline that builds up a more stable enterprise systems on a regular basis so it is much easier to release the code on a more frequent basis. This is done by creating a deployment pipeline that integrates the code across the enterprise system on a much more frequent basis with automated testing to ensure that new functionality is not breaking existing code and the code quality is kept much closer to release quality.
From my perspective this approach to DevOps is rather different from the more unicorn type approach described in this article. It though does address the biggest opportunity for improvement that does exist in more large traditional organizations which is coordinating the work across teams. In these cases the working code in the deployment pipeline is the forcing function used to coordinate work and ensure alignment across the organization. If the code from different teams won’t work together or it won’t work in production, the organization is forced to fix those issues immediately before too much code is written that will not work together in a production environment. Addressing these issues early and often in a deployment pipeline is one of the most important things large traditional organizations can and should be doing to improve the effectiveness of their development and deployment processes.
These benefits are even more pronounced when working in organizations that have outsource development across multiple companies around the world. Ensuring the different vendors don’t go off track and create code that won’t work together in production is critical and a well-designed deployment pipeline is a critical tool for coordinating development across different outsourced organizations in traditional tightly coupled systems. For these types of outsourced organization, DevOps principles while different are almost more important than they are for companies that do all their development internally.
About the Author/ Gary Gruver
Gary Gruver is an executive with a proven track record of leading Large-Scale Agile transformations and co-author of “A Practical Approach to Large-Scale Agile Development” and the new book, “Leading the Transformation: Applying Agile and DevOps Principles at Scale.” He is currently working to help organizations with their transformations after successfully leading two large transitions at HP and Macy’s. As the Director of Engineering at HP, he led a large organization (400+ developers) on a journey from waterfall to agile development. At Macy’s.com, as the VP of QE, Release, and Operations, he led the transition to Continuous Delivery. Reach him on twitter at: @GRUVERGary
When he’s not summiting El Capitan or off-roading in Baja, Dirk Morris spends his time as the founder and engineering visionary behind the Untangle network gateway platform. Prior to Untangle, Dirk was Chief Architect at Akheron Technologies, where he invented the patent-pending High Bandwidth Transparent Vectoring used in the company’s proxy firewall engine. He has also held positions as lead engineer at VerticalNet and H.L.L.C. Consulting, developing Java-based distributed monitor and intrusion detection systems. Dirk earned a Bachelor’s degree in Computer Science with a minor in Mathematics from Carnegie Mellon University. He worked on survivability simulations at CERT/CC (Computer Emergency Response Team), the University’s renowned, federally funded Center for Internet security.
