Disciplined Agile

IT Operations Teaming Strategies

Your organization will need to organize the person(s) involved with IT operations as appropriate for your situation. In this section we share three common patterns for doing so: 

  1. A traditional strategy
  2. A DevOps strategy for small organizations
  3. A DevOps strategy for large organizations 

First, let’s explore the traditional approach to organizing an operations team. This is depicted in Figure 1. With this strategy the development teams and the operations team(s) are kept separate, often because the skillsets are perceived to be distinct and sometimes because of a strict interpretation of separation of duties requirements in regulations such as PCI-DSS. A release manager, and in larger organizations a release management team, is responsible for shepherding releases of new functionality into production. The operations team is responsible for running the solutions in production, for maintaining and evolving the IT infrastructure, for monitoring running systems, and for addressing problems as best they can. There is often an IT support team, not shown in Figure 1, helping end users. 

Traditional Operations

Figure 1. A traditional approach to operations (click on diagram for larger version).

The small-organization DevOps teaming strategy is depicted in Figure 2. This works well in organizations with a handful of systems, where each system is being evolved by a solution delivery team, and where a “you build it, you run it” approach has been adopted by the delivery teams. In this case the delivery teams themselves are responsible for developing, releasing, operating, and (very likely) supporting their solution.

DevOps Small Organizations

Figure 2. A DevOps approach to operations in small organizations (click on diagram for larger version). 

You can see that there in Figure 2 that there is someone in the role of “DevOps Engineer”, a specialist role. This role is common when organizations are either new to DevOps or are very small. In small organizations a DevOps Engineer is typically a “jack-of-all-DevOps-trades” who takes on the responsibilities of several of the roles in Figure 3 (Release Manager/Coordinator, Database Administrator, Tool smith, and sometimes even Operations Engineer). As your organization grows you’ll find that these specialist roles will emerge and that DevOps Engineer goes away. In organizations new to DevOps you’ll often see them call their more senior developers DevOps Engineers, particularly those on teams following the Continuous Delivery: Lean or Continuous Delivery: Agile lifecycles. 

The large-organization DevOps teaming strategy is depicted in Figure 3. As an organization grows they realize that the “you build it, you run it” philosophy at the team level doesn’t scale very well by itself. The people on a given team can and should operate and support the specific functionality that they are responsible for, but that functionality is hosted within your overall enterprise ecosystem. Because there is a shared ecosystem, there are some common issues across teams that are better handled at the strategic level. For example, this may include: 

  • Having a Release Manager/Coordinator to coordinate and guide the deployment efforts across dozens or even hundreds of teams
  • Operations engineers to operate and evolve common infrastructure such as the network, your servers, and your external services (e.g. the cloud)
  • Disaster planning, simulation, and mitigation
  • Managing the enterprise ecosystem configuration
DevOps Large

Figure 3. A DevOps approach to operations in large organizations (click on diagram for larger version).

We’ve seen all three of these approaches, and combinations thereof, work quite well in practice. As usual, context counts – different situations require different teaming strategies.