DevOps: Embedding vs Centralization

DevOps have been making the rounds in many technology-driven industries. Ever since the concept was introduced in the late 2000s, it has meant many different yet related things. For some, it’s a new buzzword; for others, it’s an essential part of software development.

As the meanings converged over the years, DevOps are now understood as a twofold concept, with one focusing on methodology and the other on engineers themselves. They overlap as part of the DevOps methodology implies the distribution and activity of engineers within the company.

There are disagreements, however, on how such teams should function. As DevOps are the gray eminence of the software development world, integrating them into the company processes is challenging. DevOps engineers should be able to get an in-depth look into existing processes, necessitating a high level of practical expertise within each team, and a complete overview of the company, requiring a broad spectrum of knowledge.

No single solution exists because one option isn’t necessarily better than the other. Your decision on whether to embed or create a centralized DevOps team depends on the intricacies of your business.

DevOps: culture first

Part of the art of implementing DevOps is understanding the methodology and underlying goals. No amount of CI/CD, automation, and process optimization will work if no one follows the methodology and agreed conventions. DevOps engineers should be able to first have social influence, which is gained through education and benefits both the teams and the business at large.

Culture underlies all practical operations. As an example, we can turn to the classic case of implementing a new data collection tool within a team. As long as there are no budgetary constraints, purchasing and implementing one within an existing tech stack is relatively easy.

Issues often arise in having the team make consistent use of the tool. Breaking into new habits is often much more complicated as, how the story goes sometimes, there is an initial interest which then quickly vanishes. Soon the tool may lie forgotten, never having the intended impact on operations.

In most cases, it’s somewhat expected that people will be naturally averse to change, especially when that affects their work. Unfortunately (or fortunately, depending on how you look at it), the DevOps methodology always involves change. It may be gradual and continual, but it’s always there.

The necessity for change stems from one of the foundational DevOps principles – the destruction of siloed work. Teams have to communicate, work, and approach challenges together, which means adjusting and changing (sometimes even introducing new) processes.

DevOps engineers become a necessity as the culture and mindset shift would be exceedingly difficult without experts in that specific methodology. They can identify areas where changes would be most impactful and start implementing the cultural shift. Yet, at the same time, they have to have some authority to minimize the possibility of friction between teams.

Therefore, the method of DevOps integration depends, at least partly, on the ways they can exert cultural influence. Depending on company size, department sizes, and many other social factors, the effectiveness of embedded or centralized teams will differ.

Embedded DevOps

Regardless of the social and business factors at play, there are some objective benefits of either choice of DevOps integration. Embedded engineers will be able to work much more closely with each team and get to know their processes better.

Additionally, DevOps engineers will become a part of the team, which provides them the unique opportunity to push automatization and methodologies from within. They can match the needs of that particular team much better than a centralized and independent DevOps department could.

Finally, it’s much easier to assess how many engineers are needed if they are embedded within existing teams, reducing the likelihood of overspending and wasting resources. In some sense, embedding is less resource intensive in the short term.

Unfortunately, it’s not all benefits for embedded engineers. There are several practical issues, which I will outline below, but also theoretical conflicts within such an approach. DevOps is about minimizing silos across development departments. Embedding engineers within existing silos makes it harder for them to break away from the practices that led to them in the first place.

Additionally, it’s much harder for the scattered DevOps engineers to properly ensure alignment with business requirements. As they are a part of the team, they are also influenced by it, making it harder to push possibly unpopular changes that may be beneficial for the business at large.

Moreover, a DevOps engineer that’s embedded in another team (e.g., web development) will have a much harder time developing their own skills. Their team might not be able to guide them toward growth due to a lack of experience with DevOps. They will also be unable to (as easily) bounce ideas back and forth or discuss potential changes with other experts.

Getting a good picture of the overall business needs according to DevOps methodology will be somewhat more difficult. Even with many embedded DevOps engineers, finding unity between all of them will be troublesome. As most businesses run on KPIs, OKRs, or any other metric, each team will have their own, which means they might clash with DevOps methodology.

Centralized DevOps

Another option is to create a centralized and independent DevOps team, which would work with all development and engineering teams to implement the culture and methodology. Again, such an approach has its own benefits and drawbacks.

One of the greatest advantages is that they can fully commit to implementing true DevOps. They have their own independent goals that can be easily made to match business strategy and alignment.

Additionally, since they work with many teams simultaneously instead of being limited to one, engineers get a better overall understanding of the flaws and strengths of the entire development pipeline. They are also free to propose implementations without fear of internal pushback.

Finally, an independent department creates an environment where DevOps engineers can both grow professionally and validate their ideas between themselves. 

One of the drawbacks, however, is that an independent department is usually more expensive, all else being equal. Even with numerically the same amount of engineers as it would be in an embedded approach, a team lead or head will be required.

In addition, the implementation might be a little slower as engineers will have to constantly work with teams externally, meaning more meetings, more processes, and more discussions.

Also, it should be considered that the gray eminence picture will be much starker with an independent team. DevOps engineers will often come into a team, investigate processes, and propose solutions. No matter the approach, it always seems as if an outsider is attempting to influence your team, which inevitably leads to friction.

Conclusion

DevOps implementation, whether within teams or independently, has an enormous long-term impact. Switching between the approaches is costly, both financially and socially, as lots of people will have to be moved around, new processes will have to be created, and, potentially, someone will have to be hired (or fired).

Setting out on the right foot from the get-go is essential to the long-term success of DevOps. Unfortunately, there’s no easy solution to the problem. Embedding DevOps engineers within teams may be beneficial for smaller organizations, while independence could be better for large companies.

Cultural considerations, however, should precede either of the choices. Analyzing the current state of affairs and picking the approach that would let DevOps engineers implement their methodology with the least amount of friction should be chosen.