Software Architects and Autonomous Teams

How Does a Software Architect Fit into Autonomous Teams?

Software architects are responsible for the architecture of a system. This includes the overall design, the corresponding components, and their communication.

One popular definition of architecture is “stuff that’s hard to change”. I’d argue that a good architect makes change easier — thus reducing architecture.
Martin Fowler

A software architect should also aim for maintainability and sustainability of a system, thus making assumptions on the system usage and trying to verify these. In contrast, a developer’s point of view of the system is more fine-granular, focused on the implementation details and limited to the components’ context regardless whether the component is only a smaller part of the overall system. The outcome of this is a discrepancy between what is seen as the most important component of a system (the developers perspective, most likely technical) and what is the most important component in the context of the whole system (addressing both the component’s technical and business relevance). Thus, an architect has make sure to create and distribute a shared global understanding of the system. Apart from the communicational aspects, an architect could define guidelines for teams to prevent uncontrolled technology growth. This is necessary if there are either management decisions to cooperate with certain technology partners only (eg. Oracle) or the organization is not able to make good architectural desicions, eg. because of missing experience/ maturity. An example for such a guideline could be the decision to use REST over SOAP for communication or recommendations on choosing a programming language. Within these boundaries, teams should have the possibility to interact and make decisions on their own.

However the movement from functional teams towards cross functional and autonomous teams blurr the lines of responsibilities and the capabilities to make decisions. How can a software architect facilitate the idea of autonomous teams?

Social aspects of developing software

This article mainly elaborates on how a software architect fits into autonomous teams, whereas the role of an architect is interpreted as a mediator between teams. Therefore it is crucial to understand the aspect of communication in terms of developing software. Social interactions between individuals and groups have a great impact on the success of software development projects. 1968 Melvin E. Conway found out that an organization is constrained to create systems which are reflections of their communication. Hence, any friction in communication between departments or any complex workflow is likely to be reflected within the software. Communication is the result of the corporate culture, hence changes in communication means changing at least parts of the corporate’s culture. Ignoring this dependency will result in frictions and lack of understanding of strategic/ management decisions. Referring to a software development process, you need to ensure that someone is taking care of discovering and removing any negative influence on social interactions between all involved departments. This article takes the architect in account for such duties and responsibilities.

Functional Teams vs. Cross Functional Teams

Functional teams are teams with the focus on one skill set. A functional team of database administrators has a huge expertise in managing databases but most like little knowledge about web frontend technology, whereas a team of frontend specialists cannot administer databases, but create great websites. The communication within the group of the specialists has low barriers, because they are all grouped into teams, which enables them to share their specific knowledge easily.

However building software usually needs a subset of different skills, eg. backend, database, frontend, UI, UX and operations. Functional teams are highly skilled but the external communication path (between the teams) is very heavy weighted and often fails due to miscommunication. To tackle this problem, the agile movement came up with the idea of cross-functional teams, where teams are constituted by members with different skill sets.

This enables the database specialist to closely work together with the backend developer. There are two major benefits: on the one hand, special knowledge can easily be shared across skill boundaries, on the other hand decisions which affect the product can be made directly considering feedback from all involved parties. Both of them foster the team’s autonomy.

Cross Functional Teams vs. Autonomous Teams

Building cross functional teams, doesn’t implicitly result in having autonomous teams. This strictly depends on some further key drivers like the team’s maturity, social capabilities, and the context size of their area of responsibility, leadership and organizational structure.

Having a cross functional team enables you to address business goals directly to the team. Functional autonomous teams are constrained to solve problems within their special field, which means a team of backend developers will build a performant webshop backend but will likely fail on building a nice storefront. Having multiple autonomous teams requires a clear and solid communication path between the different teams. If you cannot provide such, your teams likely have to deal with a huge communicational overhead which results in decreasing developer experience and therefore inefficiency due to frictions and frustration. Frustration and frictions between teams causes the members to be more likely to reject being responsible for their product.

Indeed the role of a software architect has a broad range of interpretations. Many believe a software architect is somebody who primarily:

takes decisions regarding the software architecture as well on some hardware related topics
is more related to the C-levels
is responsible for the quality of software
enforces technical standards, tools and platforms

This strongly contradicts the idea of autonomous teams because it shifts the responsibility for core decisions away from the teams and prohibits the willingness to take over responsibility, which is essential for autonomy. If a team does not agree with a decision, they tend to blame the architect for any related failure.

However, the role of a software architect within a cross-functional team can be implemented in two ways, each has specific characteristics.

Architect as a role in a team

As already mentioned, having multiple autonomous teams eases the communication and collaboration between skill silos but requires a very good communication path to external teams. The technical solution for that is well defined APIs for the system-to-system communication. The non-technical solution can be achieved with proper team design. To prevent a lack of functionality as well as overengineering a system’s integration (eg. in form of an API), the best design evolves from cross team communication. The team member feeling responsible for the architecture has to ensure to get the team to know the consumer’s requirements. He facilitates the external communication and if necessary the cooperation with other teams.

The architect as part of the team is not a single, dedicated role. It’s more an extension to another role, whereas the focus is most likely but not limited to a role, that is strongly related to a developer role (eg. backend/frontend developer). Typically an architect knows how to write software and already has several years of experience. You can think of a senior developer or tech lead whose main focus is doing architectural work. The drawback of this design is that it’s crucial for the overall system that the architects within the teams have a clear overview across all components and common requirements. Without a clear responsibility there might be team members who feel responsible for the architecture on a voluntary basis. If that fails, the system’s landscape could mess up. Bear in mind that even if the architect in this approach is not a dedicated role, there is still the need of having a dedicated person within the team owning this attachment. Otherwise your team members may feel left alone and take decisions they are not capable to take.

Architect-as-a-service

In this scenario, the architect, or the architects are not part of the development team. Within an organizational diagram they could be a team, but since it can be a single person role, I’d say it’s more like a pool of skilled person(s). The Architect-as-a-service can be consumed from teams whenever it is necessary, eg. API design review, support for technological decisions or even to contribute to the code base.

It is important that the time the architect works for/ in a team has a defined start and end date. The architect will come as a promoter/ enabler and the goal is to close knowledge/ competence gaps within the team and streamline the teams effort to the company goals. She aims for making her role within the team obsolete. As an architect is not assigned to a specific team, her responsibility is to have a clear high-level perspective of the overall system landscape.

The architect-as-a-service offers several advantages over the prior approach:

Due to the meta-involvement in all teams, an architect is able to spread success stories across the teams.
Having a dedicated instance to identify common requirements (standards). No need to reinvent the wheel multiple times.
Communicational overhead is not directly within the teams, whereby this primarily is true for social interactions and knowledge sharing across teams. The architect-as-a-service can moderate and foster communication paths, where it is vital for the project’s success.
The architect has a less emotional relationship to a team’s product which facilitates more pragmatic decisions/ advice.
Being not a full-time team member, the architect can focus more on specific topics and architectural work than a developer who implements features.

There are several downsides that come along with the approach of having architects-as-a-service. Due to her temporary engagement within a team, the architect has to have a strong focus to get the team enabled until she leaves again. During the time of collaboration, the team has effectively more development resources, however the architect should not be treated as a full-time team member to get features in place. It’s a small gap between being part of the team in a very special role without being noticed as a stranger. This requires the architect to have a huge social and communicative competence. Additionally the architect-as-a-service always has to consider herself rather as an advisor than a decision maker. The ownership and responsibility for the system remains within the team. Enforcing decisions for the team apart from the aforementioned architectural boundaries and leaving them alone with the maintenance and ongoing support, will end up in distrust, frustration and the loss of the willingness to take over the responsibility for the system.

To summarize, the final decision about any changes to the software architecture still belongs to the teams but they can get support, review and expertise at any time from outside.

Recap

The software architect role is a role for professionals. It requires high skills and experience in both management and technical aspects. The architect should not be treated as a single point of knowledge and should not be the only one being responsible for a system. Rather the architect is more like a mentor and enabler to the teams. Depending on your team structure (cross-functional team vs. autonomous team) and skill sets, the architect can be part of a product team or available as a service on demand. Both models come with advantages and disadvantages. Having a dedicated architect enforcing technological decisions contradicts the goal of having autonomous teams and impedes the team from taking over full responsibility. However architecture still needs, in the vast majority, somebody to care about. This person, respectively the architect, has to focus on communication, removing frictions and a coherent understanding of the system’s purpose and design across all participants.

To complete, I want to express my thanks to Eberhard Wolff and my wonderful colleague Niko Huber for spending their time improving and reviewing this article. Your feedback was always an eye-opener.

Thank you for reading. You can reach me out via: