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:
- A traditional strategy
- A DevOps strategy for small organizations
- 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.
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.
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
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.