In the application development lifecycle, most organizations don’t do everything in-house. It’s typical to have some part of an application’s development or operations go to an outsourced service provider. The US outsourcing market currently employs about 350,000 full-time professionals, and that workforce is growing between 3 percent and 20 percent each year, depending on function, according to Everest Group’s research.
So how do you do outsourcing within the scope of DevOps? Those who deal with service providers need to understand that these are not typical contracts. There is no start, middle, or end, and deliverables are ill-defined and ongoing. Thus, the way you approach provider management is hugely different from traditional methods.
You need a new approach to align KPIs and deliverables, and you need to relearn vendor management. Here's a guide to the types of roles that are commonly outsourced, the key operational issues they bring, and how to resolve them within a DevOps context.
Growth leads to confusion
According to the report Global DevOps Platform Market 2016-2020, by the research firm Research and Markets, the DevOps market should see a sustained growth rate of around 20 percent (CAGR of 19.42 percent) through the end of the decade.
Those who are associated with any enterprise development team have seen this trend as well. Typical DevOps projects are driven by:
- The rise of cloud-based platform usage, providing centralized deployment, which is purpose-built for DevOps.
- The need to automate the popular agile methodology, allowing for quick construction and deployment of applications.
- The wide availability of DevOps tools to support continuous integration, continuous testing, continuous development, and continuous deployment, which all leads to continuous improvement.
It’s the growth in the use of DevOps, along with clear business cases, that is driving enterprises toward DevOps. Enterprises are also looking for ways to bring their outsourcing contracts along for the ride. This leads to some confusion, considering roles and responsibilities, investment in the DevOps culture, core intellectual property retention, and overall operational concerns.
Challenges in finding a common goal
Those in the know are advising that enterprises advance with caution. John Jeremiah, the Digital Research Team Leader at Hewlett Packard Enterprise, believes that for outsourced DevOps to work, there needs to be an understanding that all groups, even if they are working for different outsourcing companies, need to come together to meet a common goal.
“There should be an understanding that DevOps is a team effort, and the work between the groups needs to be seamless.” —John Jeremiah
Jeremiah, along with others, emphasizes that outsourcing comes with shared responsibilities among the different organizations that take specific roles in the DevOps processes. He describes DevOps as a way to optimize the end to end flow of business value, and IT service providers need to align and contribute to the full value chain, not their specialized silo. Dev, QA, and Ops must work in harmony to streamline delivery, automate to remove latency and continuously improve the value chain.
"The only way [the flow of business value] can happen is if all the participants in the value stream work together, not in isolation.”
—John Jeremiah
Eliminating isolation may be a good idea for enterprises, but it's an idea that runs counter to the culture at many outsourcing companies. In the past, work flowed upward, directly to the customer. Even if there were dozens of outsourcing firms, all of them focused upward in order to obtain both fees and validations that their work was acceptable.
In an outsourced DevOps scenario, the same organizations must focus all around. They must focus on their ultimate client, meaning the host enterprise, but must also look to other organizations that may have a staff that works for another outsourcer. They are told that they must work and play well together and that silos should not exist. However, it’s easy for these players to fall back on old habits and not interact with organizations that they consider their competition.
With outsourced DevOps, who owns what?
Another consideration is that those who provide outsourcing services for DevOps to IT are typically not willing to play the staff augmentation game. This means that they are not just body shops with collections of DevOps geeks that you can leverage to fill specific roles. They typically need to own the projects, applications, and processes.
In owning the projects, such as testing for a certain number of systems or deployment and operations, they may not be willing to work as well as they should with other outsourcing providers that own other parts fo the DevOps processes. Or at least that has been my experience.
Will your DevOps culture walk away in 6 months?
Other aspects to consider include the value of the DevOps culture and the value of the intellectual property. Those who outsource DevOps, and thus spend a great deal of time and money building a functional DevOps culture, may find that outsourcing firms have higher turnover, and thus they may build a wonderful culture that goes walking out the door in six months to a year.
A DevOps culture is really hard to build and very fragile once built. These cultures actually have a value, and when companies are priced for sale, the DevOps capabilities can be valued at as much as a million dollars per DevOps team member. If you don’t own the people, meaning they are not your employees, that value may not actually exist.
And what about your intellectual property?
Intellectual property should also be evaluated. While it’s unlikely that your outsourcing server providers will steal your proprietary ideas, it’s not unreasonable for DevOps team members to take their knowledge to other customers as they shift team members around.
All things considered, your enterprise may have a huge competitive advantage when considering its ability to accelerate the time it takes to get strategic new applications into production. However, you may find that your competition gains value from shared knowledge, as outsourcing/DevOps players move from company to company in the natural progression of their careers.
For instance, say you have some key outsourced players assisting you in building a unique DevOps process and toolset for your business. That solution would be valuable for your competition as well. If those outsourced players move to assisting your competition, they will likely bring your intellectual property with them, knowingly or not.
3 guidelines for outsourcing in a DevOps
Enterprises have a couple of choices to make when it comes to outsourced DevOps.
1. Use staff augmentation companies that provide people and don’t own the projects
In the case of DevOps, this includes the parts of the DevOps processes (testing, integration, deployment, etc.). Of course, this is outsourcing lite, and most consider it too expensive when compared to outsourced contracts, where you purchase pods of developers working to a single purpose, and typically at a discounted price.
2. Make sure the outsourced talent will work and play well with others
While this may sound like a simple message, many companies give lip service to it but behave differently. And there is no incentive for them to assist other outsourcing providers to be better at their jobs.
The best approach is to send the “work and play” message, but place it within a contract that is enforceable, with incentives in place to make it appealing to work well with the other groups in the DevOps organization. It’s not unusual for organizations to pay bonuses upon the achievement of KPIs that are predefined by the enterprise.
3. Outsourced DevOps will not work for everyone
Finally, consider that outsourcing DevOps has its pitfalls. Outsourcing DevOps is not the best idea for all companies or organizations within companies. You must approach outsourcing combined with DevOps carefully, understanding your own requirements, including what's been working and what's not been working in your industry. Best practices will emerge at some point, but as of now they have not shown up.
The key takeaway here is that outsourced DevOps may be one of those things that’s not a good idea now but perhaps will be in a few years. The more that skills, toolsets, processes, and best practices become commodities, the more it will make sense to burden outsource service providers with those tasks.
However, given the nature of DevOps and the fact that we’re at the beginning of the curve right now, it may be a while before that’s a reality.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
