Dieser Artikel ist auch auf Deutsch verfügbar

The answer (naturally) is once again it depends, but you probably already knew that or recalled it from the previous articles. In the area of software architecture, there are no standard solutions for all cases, and that is no less true for how to divide up the work.

But let’s go through it step by step: What options are there in the first place? On one hand, we could maximally centralize the decision-making authority by entrusting all of it to a single, dedicated person. On the other, we could simply delegate the architecture tasks to the entire development team for a maximally distributed approach. A number of other possibilities lie between these two extremes, some of which can be seen in Figure 1 (from Toth [1] and Hohpe [2])

Note: For simplification, the situations sketched out here refer to teams of moderate size, with no more than 8–12 persons. For larger teams or groups of multiple teams, different or additional rules must apply. I will address these in the upcoming (fifth) article in this series.

Four ways in which the software architecture role can be assigned, from centralized to distributed, monarchy to democracy; see Toth and Hohpe in the sources at the end of the article
Four ways in which the software architecture role can be assigned, from centralized to distributed, monarchy to democracy; see Toth and Hohpe in the sources at the end of the article

Figure 1 shows four points along the spectrum between a fully centralized model (a.k.a. “monarchy” or “autocracy”) to a fully distributed and purely democratic one.


A single person makes the decisions and is empowered to issue instructions to the development team. The team simply receives the instructions or specifications. A monarchy can suppress feedback (absolute monarchy) or systematically solicit it (benevolent dictator, as per Hohpe [2]). The main feature of a monarchy is a single person who makes the architectural decisions, while the team simply implements the structures and concepts as specified.

This style of work is frequently associated with an organizational separation between the development team and the architecture: The responsibility for architecture decisions lies within a different department or organization than the implementation. In other words, absolute monarchs generally do not have a hand in the source code themselves.

Monarchy variants
Monarchy variants

However, there are also situations in which benevolent dictator participate actively in development, and sometimes they are even exceptionally familiar with the source code. Numerous examples of benevolent dictators can be found in the open source environment. For example, Guido van Rossum, the inventor of the Python language, has long been called the “Benevolent Dictator” of the Python community.

These latter cases differ only slightly from the model of architect in the team described below.


Even if a monarchy appears very old school from the perspective of agile software development and seems less attractive to a development team, it still has some intrinsic advantages:

Disadvantages / risks

Having a single person as decision-maker also brings with it a number of systemic disadvantages, of course:

When should it be used?

Based on the advantages and disadvantages listed above, I have identified a few situations in which a monarchical organization might work. I consider the main prerequisite to be appropriate qualifications for the architect role in terms of both technical and communication skills.

Architect in the team

This model with a single specified person in the architect role is also considered a classic organizational model. Here as well, a single person handles the main architecture design tasks, but in this case the person is an integral member of the development team. Gregor Hohpe refers to this model as primus inter pares (translation: “first among equals,” see [2]), and explains it as follows:

Architects are embedded into teams where they are just-another-team-member but one who focuses on the system structure and trade-offs, perhaps taking a longer-term view compared to other team members (and using a fancy Latin name).

In contrast to the monarchical model, a primus inter pares can and should encourage the development team to make their own decisions. The architect in the team can actively participate in the development, but should at least function as a coach for others in critical instances.

Unlike the monarchical approaches, however, a primus inter pares does not have absolute decision-making authority, and they should justify their decisions and strive for consensus within the team. Nevertheless, this person can still make unilateral decisions when necessary.

In general, this organizational model places considerable requirements on the technical, methodological, and communication skills of the person in question.


A single person simplifies the interactions between other stakeholders and the development team. As with a monarchy, the responsibility for architecture decisions is clearly regulated. Likewise, this model also results in consistent decisions that are all of a piece.

Development teams can provide feedback and receive explanations, as well as direct support in matters of architecture.

Disadvantages / risks

The decisions still depend heavily on the knowledge and availability of a single person. This so-called bus factor [3] of 1 can represent a significant risk in situations that pose difficulties in terms of time, technical aspects, or subject matter.

When should it be used?

Due to the high communication burden between the team and the architect, the team should not be significantly larger than 5–8 persons. If a team requires more coaching, an architect within the team can handle this. This organizational model requires the availability of a person (architect) with the experience and knowledge required for the situation, which should cover at least the technology employed. Ideally, the architect should also be familiar with the subject matter domain. They must always be able and willing to provide extensive coaching within the team.

This model can also be used in situations where:

In my experience, this model is frequently used in the area of embedded/real-time systems or highly regulated areas like medical technology, aviation, or safety systems.

Now let’s take a step further in the direction of distributed models, where the architecture role is split among a number of people.

Architecture agents

Multiple people share the architectural work. It might be that individual people are responsible for specific topics or activities due to their specialized knowledge. The designation “architecture agents” comes from Stefan Toth ([1]).

The precise way in which these responsibilities are divided up can vary considerably, whether by individual specialties or with topic-focused guilds (see [4]). The composition of this “architecture team” can change occasionally to offer more intensive coaching for other team members, prepare people for the architecture role, or take advantage of their specialized knowledge when appropriate.

From my experience, I recommend three people for this model:

If this model sounds interesting to you, I recommend taking a look at the so-called Spotify model with its tribes, chapters, squats, and guilds.


As a small group, the architecture agents can discuss their decisions efficiently. This ensures that the decisions are always made with a certain amount of feedback, which considerably lowers the risk of careless mistakes while improving the quality of the decisions.

The rest of the team has access to multiple points of contact and coaches, meaning that questions are generally answered more quickly than with the single-person models.

Plus, this model facilitates the efficient transfer of architecture knowledge throughout the team, which reduces dependences on individuals and raises the bus factor.

All of these advantages of the agents model contribute to high acceptance of architecture decisions within the team. This is especially true if the agent role is regularly rotated to involve additional people in the architecture work.

Disadvantages / risks

The selection of the agents requires a certain amount of organizational work and decision-making, generally on the part of management. Establishing appropriate communication processes between the agents can also require a certain amount of effort.

This comes atop the already inherent communication and coordination work among the agents. The result is additional time overhead compared to purely monarchical models, but I believe this is more than compensated by the increased quality of the decisions and the greater acceptance.

There is also a risk that the selection of the agents could lead to disputes within the team since not everyone is permitted to participate in the decision-making.

When should it be used?

When the knowledge or experience of an individual person is no longer sufficient or if the tasks involved in a project are too extensive or difficult, the distributed agents model is worth considering.

It is also excellently suited for establishing and disseminating architecture skills and know-how within the team.

The approach of rotating the agents also helps ensure consistent architecture work within teams that experience high volatility. Unpleasant tasks can be distributed among the agents to share the burden.

Personal experience

I have had extremely positive experiences using this model with 2–3 architects in the team. We agents were able to mutually support each other even during hectic or difficult situations and still arrive at appropriate decisions.

For that reason, this model is my personal recommendation as long as no clear constraints speak against it.


If we are already splitting up the architecture work anyway, we could also simply distribute it throughout the entire team. In this case, the full team votes on all architecture questions and decisions without outside input.

It goes without saying, there are many ways to tweak this approach, such as:


A democratic model includes everyone on the development team in the decision-making, which generally leads to high acceptance. The fact that the collective experience of all team members enters into the decisions is another plus.

Disadvantages / risks

A typical democracy is characterized by political calculations as well as coalitions and compromises. When a democratic organizational model is used in software development, there is a risk that separate decisions will linked by deal-making (“You get your way on topic A if you agree to my preference on topic B”). This can easily erode the consistency of decisions as fluctuating majorities within the team lead to shifting preferences or priorities.

It can also take a long time to make decisions due to prolonged debates within the team. Arriving at a consensus in an 8–10 person team takes much longer (!!) than among just two or three people.

In my opinion, these factors diminish the acceptance of purely democratic models, leading the developer teams to transition to an agents model of their own accord.

When should it be used?

In small teams (max. 7–8 persons) with very homogeneous know-how and for projects with very low time pressure (but do such projects even exist?), a fully distributed model can work well.

This approach is also a good fit for smoothly functioning teams with a good communication culture and mutual acceptance.

Summary: Once again, it depends

Once again, it depends: There is no single, clearly superior organizational model for software architecture. The diverse requirements and contexts of software systems are best served with an appropriately adapted work model. Even the centralized models so often criticized in the agile world have their justified use cases, especially under organizational conditions such as outsourcing or offshoring.

There is much to be said for explicitly discussing the potential work models within the team. Ask your team the question “How should we work on the upcoming project?”

A developer team can also adapt the work model on the fly to suit the given situation, such as switching from an agent or democratic model to a primus inter pares over the holidays or in preparation for a critical deadline.

It is worth keeping an open mind in this respect.


Thanks to Martina “m” and Martin Weck for their thorough reviews!


  1. Stefan Toth: “Vorgehensmuster für Softwarearchitektur”, Carl–Hanser Verlag, 3rd edition 2019. Here, Stefan Toth presents four different collaboration models that he calls “classic architect,” “supporting architect,” “architecture agents,” and “no specified architect.”  ↩

  2. Gregor Hohpe: Organizing Architecture  ↩

  3. The bus factor is a measurement of the risk resulting from the availability of individuals, derived from the phrase “in case they get hit by a bus.”  ↩

  4. Jon Moore: Architecture Guild. The original title is “Architecture with 800 of My Closest Friends: The Evolution of Comcast’s Architecture Guild” with the following explanation of an architecture guild: “The Architecture Guild is a grass roots framework that has been used to cut across organizational boundaries to identify solid, workable, default recommendations for technologies and practices explicitly modeled on existing successful decentralized groups like the IETF (Jon Moore on InfoQ)”  ↩