5 key organizational models for DevOps teams

Johanna Ambrosio ·
Mar 8, 2022 · 7 min read · Leave a comment

If you’re just getting started with DevOps, there are several team organizational models to consider.

A few key points to keep in mind as you design your team structure:

Why building a DevOps team is important

Even though DevOps is arguably the most efficient way to get software out the door, no one actually ever said it’s easy. So building the right DevOps team is a critical step in the process.

The right DevOps team will serve as the backbone of the entire effort and will model what success looks like to the rest of the organization. There is no “one size fits all” however – each team will be different depending on needs and resources.

5 examples of DevOps team models

Here are five DevOps organizational models to consider as you get going, according to Matthew Skelton and Manuel Pais, experts who wrote a book called Team Topologies about this topic and then updated the book with a related microsite. Their work is a must-read for anyone who’s trying to figure out which DevOps structure is best for their company.

1. Dev and ops co-exist, with a “DevOps” group in between

This can be a good interim strategy until you can build out a full DevOps program. The DevOps team translates between the two groups, which pretty much stay in place as they currently are, and DevOps facilitates all work on a project.

Just don’t keep this structure in place too long. You don’t want to reinforce the separate silos as they currently exist for any longer than absolutely necessary.

2. Dev and ops groups remain separate organizationally but on equal footing

This is also a reasonable place to start: Everyone collaborates but can specialize where needed. Common tools will go a long way to helping facilitate good communication. In this model, several dev teams can be working on different products or services.

Make sure teams communicate regularly. Invite a rep from each camp to the other’s meetings, for instance. And appoint a liaison to the rest of the company to make sure executives and line-of-business leaders know how DevOps is going, and so dev and ops can be part of conversations about the top corporate priorities.

3. Create one team, maybe “no ops”?

In this model, a single team has shared goals with no separate functions. The reason it’s called “no ops” is because ops is so automated it’s like it doesn’t actually exist.

This level of automation is so “aspirational” that many experts express caution about this approach. To eliminate any hands-on tasks, teams would need extensive machine learning and artificial intelligence solutions, and a flat, streamlined organization that prioritizes communication and workflow. TL;DR: NoOps may not ever be a reality.

However, don’t use this as an excuse to do away with the ops team. You are going to need those folks. Devs can’t do it all.

4. Ops as infrastructure consultants

This model works best for companies with a traditional IT group that has multiple projects and includes ops pros. It’s also good for those using a lot of cloud services or expecting to do so.

Here, ops acts as an internal consultant to create scalable web services and cloud compute capacity, a sort of mini-web services provider. In our 2021 Global DevSecOps Survey, a plurality of ops pros told us this is exactly how their jobs are evolving — out of wrestling toolchains and into ownership of the team’s cloud computing efforts. Dev teams continue to do their work, with DevOps specialists within the dev group responsible for metrics, monitoring, and communicating with the ops team.

5. DevOps-as-a-service

You may decide your organization just doesn’t have the internal expertise or resources to create your own DevOps initiative, so you should hire an outside firm or consultancy to get started. This DevOps-as-a-service (DaaS) model is especially helpful for small companies with limited in-house IT skills.

Using DaaS in the short term offers another advantage: the opportunity to learn from your outsourcer how to eventually create your own internal DevOps team.

Make sure you understand the outsourcer’s security landscape and your own responsibilities in this area, as you would with any outside firm. The difference here is that the team, processes, and software the outsourcer plans to use will be deeply embedded in your company’s infrastructure — it’s not something you can easily switch from. Also ensure that the outsourcer’s tools will work with what you already have in-house.

Finally, keep a keen eye on costs and understand how the outsourcer will charge for its services.

Other organizational DevOps schemes include:

A two-tier model, with a business systems team responsible for the end-to-end product cycle and platform teams that manage the underlying hardware, software, and other infrastructure. DevOps and SRE groups are separate, with DevOps part of the dev team and Site Reliability Engineers part of ops. This model requires a mature operations and development culture.

Whichever organization model you choose, remember the idea of DevOps is to break down silos, not create new ones. Constantly reevaluate what’s working, what’s not, and how to deliver most effectively what your customers need.

Key characteristics of a successful DevOps team

Here are some key charecteristics that you can expect to find in a well running DevOps team:

Getting started with DevOps

There are a few steps to follow in order to get started on the planning and development of your DevOps team. Here are some pointers:

1. Create a roadmap. Start with the basic goals, add in wish list items, and write it all out attaching a timeframe as needed. The map should include a list of action items broken down by priority and who is responsible for completing each step.

2. Ensure buy-in, and maybe add a champion. Evangelize DevOps to the entire organization. Some teams find having a dedicated DevOps champion can help.

3. Select the solution. Consider the budget, needs, and knowledge levels to make the best technology choices for the team.

4. Automate processes where appropriate. DevOps doesn’t work without automation and for many teams, automation is the top priority. Look at areas where you can reduce manual work.

5. Set up monitoring. Have a process for monitoring security, metrics, and everything in between. Track progress. Always be able to give stakeholders a status update.

Johanna Ambrosio is a technology writer in the greater Boston area.

“DevOps teams can be organized in multiple ways. Identify the one that fits your organization.” – Johanna Ambrosio

Click to tweet

Open in Web IDE View source