Fundamentals of software architecture: Part 4

Dr. Gernot Starke

Dieser Artikel ist auch auf Deutsch verfügbar

• Part 1: Building, purpose, aesthetics
• Part 2: Terms
• Part 3: Tasks and activities
• Part 4: Who does what? (this article)

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.

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.

Monarchy

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.

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.

Advantages

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:

• A single person (architect) provides consistent, homogeneous decisions all of a piece.
• Furthermore, the architect can decide quickly since there is no need for time-consuming coordination. It is worth noting, however, that this potential advantage can easily disappear in large teams and with large systems!
• Someone who is very experienced in the technology or domain can effectively boost the performance of a less experienced team.

Disadvantages / risks

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

• The individual architect clearly represents a bottleneck in terms of time, availability, and know-how.
• If this person is absent due to illness or vacation, necessary decisions remain unmade.
• In somewhat larger teams or for large systems, it can happen that the single person is massively overloaded with a great many decisions (this detracts from the possible advantage of fast decision-making mentioned above).
• If this person lacks important knowledge or experience, the results of decisions may be suboptimal or the decisions may not be made at all. An even halfway experienced development team will immediately notice such deficits, which hinders acceptance of the corresponding architecture decisions (as well as of the architect).
• The lack of feedback in an absolute monarchy can mean that bad or incorrect decisions are only discovered too late, such as during testing or even production.

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.

• Offshoring or nearshoring: For cost reasons, an organization or a company hires teams or service providers located in other countries, tasking them entirely with implementation. The organization wishes to retain full authority over architecture decisions.
• The development of a small to medium-sized system is subject to high time pressure, and decisions must be made quickly.
• There is a significant difference in knowledge between the architect (very experienced) and the team (less experienced).
• The project involves a standard task, meaning that significant architecture decisions can be adopted from other projects (“the fifth compiler”). The architect has successfully developed such systems in the past and knows the typical approaches, technologies, and pitfalls.

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:

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.

Advantages

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:

• The organization relies heavily on clear role-based models and/or
• The organization has little experience with highly autonomous teams

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:

• The odd number ensures a clear majority when making decisions.
• Three people can communicate quickly, allowing for relatively fast decisions.

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.

Advantages

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.

Democracy

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:

• Do all decisions have to be made collectively or can the team delegate some decisions to subgroups or individuals?
• Are unanimous decisions required or is a simple majority sufficient?
• Are there types of decisions that require a supermajority, such as 75%?

Advantages

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.

Acknowledgements

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

Sources