A digest of organizational structures in quest for continuous delivery

🇬🇧 🇧🇷

The DevOps movement, as vividly portrayed in the novel The Phoenix Project, came up as a cultural shift to break down the silos in large organizations, better integrating development and operations teams through collaboration. However, this collaboration can happen in different ways from an organizational perspective: developers and infrastructure specialists can be part of different departments or can be together in a single cross-functional team. With advancements in PaaS offers, it is possible even to envision developers themselves taking operations responsibilities.

Our research at IME-USP (University of São Paulo) aims to investigate how software-producing companies are organizing their development and operations teams. We are taking this endeavor by interviewing software professionals to understand how things are really happening in the real world. With our research, we hope to provide a theory to support organizations in designing their organizational structures toward continuous delivery and providing guidance on the consequences of a given organization structure choice.

Based on the careful analysis of the conducted interviews, we elaborated a theory describing the organizational structures used by industry in the real world regarding how the work of developers and infrastructure engineers can be coordinated in the pursuit of continuous delivery. In this digest, we present our current understanding of such organizational structures: segregated departments, collaborating departments, API-mediated departments, and single departments. Each of these structures has core properties, commonly seen in organizations with a given structure, and supplementary properties, which may or may not be present, but, when present, supports the structure explanation.

Pictures in toothpick man style representing the four organizational structures of our taxonomy (explained in this post).

Figure 1 - The four organizational structures of our taxonomy

The presentation of this taxonomy has already been accepted for publication in the Information and Software Technology, a very reputable academic journal in our field.


Download the full paper here


Between the paper submission and acceptance (almost one year), we have been working to evolve our taxonomy based on its use with practitioners. The most relevant changes from this evolution are the renaming of concepts, aiming for more objectiveness and less confusion for the taxonomy users. In this digest, we present the taxonomy in its latest version (June 2021).

Diagram with the four organizational structures and their supplementary properties, all of them explained in this post. Diagram with boxes and arrows.

Figure 2 - High-level view of our taxonomy in its latest version (jun 2021)

In the following, we present each structure alongside its core and supplementary properties.

Segregated dev & infra departments

Segregated, or siloed, departments is “the pre-DevOps” structure existing in large organizations, presenting limited collaboration among departments and barriers for continuous delivery. This structure is considered to be the problem that DevOps came to solve.

Figure shows an operator and a developer, each one inside a different circle. They have their backs to each other. Communication flows through letters, more from developer to operator than from operator to developer.

Figure 3 - With segregated departments, operators and developers are each one in their own bubbles. They do not interact directly too much, and communication flows slowly by bureaucratic means (ticket systems).

Core properties:

Collaborating dev & infra departments

This structure focuses on collaboration among developers and the infrastructure team. It is the way the book “The Phoenix Project” portrays DevOps.

Figure shows an operator and a developer, each one inside a different circle. They are looking to each other and are holding hands (with some difficulty).

Figure 4 - With collaborating departments, operators and developers in different departments seek to work together, even if not easy, by direct contact and close collaboration.

Core properties:

Supplementary properties:

API-mediated dev & infra departments

In this case, there is an infrastructure team (also called the platform team), and it provides highly automated infrastructure services (“the platform”) abstracting the infrastructure to empower product teams.

Figure shows an operator and a developer, each one inside a different circle. The operator provides an interface that is consumed by the developer (UML notation).

Figure 6 - The platform team provides automated services to be used, with little effort, by developers (the platform API mediates the interaction between developers and the platform team). The platform team and developers are open to hear and support each other.

Core properties:

Supplementary properties:

Single dev/infra department

A single department takes responsibility both for software development and infrastructure management. It is more aligned with the Amazon motto “You built it, you run it,” giving more freedom to the team along with a great deal of responsibility.

Figure shows an operator and a developer, they are inside the same circle.

Figure 5 - A single department takes care of both development and infrastructure.

Core properties:

Supplementary properties:

Other supplementary properties

To know the details about how we conceived these structures, read the full paper!


Download the full paper here


Summary

Now we briefly provide for each discovered structure: (i) the differentiation between development and infrastructure groups regarding operations activities (deployment, infrastructure setup, and service operation in run-time); and (ii) how these groups interact (integration).

Just a few more considerations

First, if one classifies a specific organization as adhering to one of the above structures, it does not mean that the particular company will necessarily follow all the structure characteristics. Each organization is unique and has some adaptations for its context. Nonetheless, the model can assist reasoning in understanding organizations and in supporting decision-making regarding organizational changes.

For now, we believe our taxonomy provides the following primary benefits:

Another distinctive characteristic of our model is that it is grounded on data retrieved from software professionals in the real world.