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