So you’ve heard about DevOps. That is great. You’ve decided that your organization could really benefit from a “DevOps transformation”. Even better. You’ve even gone above and beyond, and memorized the following definition for DevOps:

DevOps is the union of people, process and technology to enable continuous delivery of value to customers.

Awesome.

But what should you do next? How do you deal with the fact that the developers in your organization cannot or will not own the process of delivering into production? How do you deal with the fact that your operations engineers cannot or do not fully understand the software to which they have been given stewardship?

How do you get your “Dev” and “Ops” to work together? How do you become a “DevOps” organization?!?

Method #1: You Build It – You Operate It!

If your developers are already, among other things, for whichever reasons, tasked with deploying software, monitoring it in production, and dealing with live site incidents (LSIs), then congratulations, you are already half way there. More than half, really. The organizational structure, tearing down the walls between “Dev” and “Ops” is as difficult as it was about a decade ago, when the Agile movement introduced the notion of tearing down the walls between testers and programmers (a.k.a. “Dev” and “QA”), as well as that between developers and business (i.e. Scrum teams consisting both developers and business people). It is even more difficult in some organizations, where developers report to the VP of R&D, while operation engineers report to the VP of Operations; the first common manager who connects both departments is the CEO. Not the person who should be burdened with getting these two realms to cooperate.

Other organizations are not so lucky. But do not despair; the following methods describe how to enable an organization’s DevOps efforts through collaboration of separate “Development” and “Operations” departments/teams.

Method #2: Embedded Ops

In an organization where development and operations exist in two separate hierarchies (a.k.a. “silos”), if you have enough operations engineers, you should assign – embed - one in each development team. This engineer would be responsible to field all of their development team’s questions and requests, and would be responsible to help the development team deliver their software into production.

This setup has the benefit of being able to create self-managing teams who ultimately own the responsibility of deploying software to production, and making their product “ops-friendly” (e.g. automatically testable, deployable, include monitoring hooks, etc.), while maintaining a governed center of excellence (COE) that defines how software should be built, deployed, tested, and monitored.

If you have more operations engineers than development teams (yes, I know how unlikely that is…), the remaining engineers can focus on cross-cutting concerns such as monitoring overall systemwide health, and creating tools to be used by the teams for their operational efforts.

The embedded Ops engineers can, instead of merely handling the operational workload for their respective teams, help the developers cross-train so that they can become more independent, allowing such teams to move towards the first method. This can free up the embedded engineer to rejoin the main Ops team, or to move on to helping a newly formed team, or an existing team that requires extra attention.

Method #3: Liaison Ops

Many organizations, like those described in the previous section have separate “dev” and “ops” departments. Unlike the aforementioned group, however, these organizations do not have enough operations engineers to dedicate to each development team. In this case, we want to put each Ops engineer in charge of serving several teams. This engineer will have to help each team, and balance their workload with the needs of all of the teams with whom they are liaising. The liaising operations engineer will have the same responsibilities and roles as do the embedded engineers; the only difference is in the number of teams they support.

Sooner or later, liaising Ops engineers become bottlenecks, or at least find scheduling to be difficult. For this reason, if the embedded Ops engineers have the option to train their teams to operational independence, the liaising ops must make training their developers for independence a high priority.

A question that invariably comes up is “how many teams can a liaising operations engineer support?” The answer is, of course, “it depends”. It depends on both the engineer and the teams.

Method #4: The Operational Service Team

Sooner or later, organizations with embedded or liaising operations engineers want to – or must – gravitate towards the servicing model. In this model, the operations team does not support individual development teams directly, except in extreme cases. If an engineer from this operations team has to help a development team deploy their code or debug it in production, then there was a procedural failure at some point.

The role of the service team is to create tools, skills, and knowledge that enable development teams to deploy and own their code in production. This may include creating scripts and templates that automate the build and release processes, setting up automated security and quality checks as gates for continuous delivery, setting up dashboards, system health checks, etc. If it is unique to a team’s product, the team owns it. If it is a cross-cutting concern, the ops team owns it. The ops team provisions environments, or enables teams to provision environments within guidelines and constraints; the developers consume the services.

The Operational Service Team may also be responsible to create DevOps-related knowledge for the teams to consume. This may come in the form of any thing from wiki pages to providing formal or ad-hoc training.

Note that this method is very similar to the first method. In both cases, the development teams are responsible for their code all the way in to production. The primary difference, is that in the first method, there is no operations team; in the fourth (this) method, the operations team serves as a center of excellence.

Summary

Hopefully, this post will help you determine where your organization is in its DevOps journey, and help you figure out where you want to be.

Good luck, and safe journeys,

Assaf