Team and software architecture in harmony – a socio-technical system

Contents

Apparently, software architecture is only about structuring software and implementing non-functional requirements. But in reality, software is for people and people write software. Therefore, it is necessary to understand it as a socio-technical system. This has implications for the understanding of software architecture.

Eberhard Wolff

Eberhard Wolff is Head of Architecture at SWAGLab and has been working as an architect and consultant for more than twenty years, often at the interface between business and technology. He is the author of numerous articles and books, including on microservices, and is a regular speaker at international conferences. His technological focus is on modern architecture and development approaches such as cloud, domain-driven design, and microservices.

The term socio-technical system stands for an organized set of people and technologies linked to them, structured in a certain way to produce a specific outcome. It originates from research in coal mining in Great Britain in the 1950s, among other places. The idea of socio-technical systems is therefore not new and certainly not a fad. A key insight is that a company's success depends on how it functions as a socio-technical system, not simply as a technical system with replaceable individuals who are added and must adapt.

The designation already says what it's about: The system consists of a technical component (e.g., machines) and a social component (employees who operate and use technical components). Both can only be considered together, as they are closely linked. Therefore, human communication must also be considered alongside human-machine communication.

This approach is interesting for software development and architecture for several reasons: Firstly, software development is often understood and practiced as a purely technical task. However, this is only seemingly the case. Treating software as a socio-technical system offers the opportunity to achieve significant improvements. Secondly, most software does not solve purely technical problems but must provide economic benefits for users and other stakeholders.

This places the software in an important relationship with this group of people, as the value of the software is oriented towards the economic benefit for this group. This social aspect is central to the success of a software development project. And finally, software is implemented in teams. Thus, there is also a social network during development that needs to be managed. If this task is performed particularly well, development will be effective and efficient.

In fact, software architecture is closely related to both social systems – developers and users (see Figure 1). Software architecture must find a technical solution that sufficiently supports users. Qualities of the software such as usability, performance, scalability, or security must be considered. This part of the architecture can therefore only be evaluated with this social system. An architecture can only be measured by whether it provides sufficient qualities for the user group. What is subjectively impossible for some people to use may be acceptable or even ideal for others – just think of the debates about editors like Vim or Emacs.

The division of a system into modules serves to make the system's complexity manageable. Thus, modularization can only be evaluated with the respective development team. Even seemingly good modularization can be difficult for the team to understand and lead to low productivity. For example, a team might have taken over a system without a good handover from another team, so that the new team can hardly understand and modify it despite good modularization.

It is also conceivable that the system is poorly structured, but the team has become accustomed to this structure over a longer period and can therefore modify the system sufficiently well. Then the team can hardly hand over the software because a new team would have difficulty understanding it. This is less a technical problem and can be considered a social problem.

Conway's Law

Conway's Law states that an organization will develop a system whose design mirrors the communication structures of the organization. For software development, this means, for example: If two teams have two tasks and communicate with each other as needed, they will build two modules in the software that have an interface. Classically, Conway's Law was understood more as an obstacle: if teams are organized in a certain way, they can only create certain architectures. If there is a UI and a backend team, a UI and a backend will also emerge in the architecture.

However, the organizational chart is confused with communication. But people and teams also communicate when they have no obvious relationships in the organizational chart. While the organizational chart can have a significant influence on communication, it is not identical. This is also good news: while the organizational chart is static, any involved person can influence the communication flows in the project.

From the relationship between communication and architecture, another problem arises: if communication is no longer effective or breaks down, the system's architecture suffers. Especially in large projects, it is difficult to maintain good communication. Therefore, especially here, communication can become difficult first, and then the architecture can be affected.

Melvin Conway already described such problems in 1967 in the original paper on his law. If software architects want to maintain or even improve the quality of the architecture, they must influence communication in the project and ensure that it works.

Through the Inverse Conway Maneuver (see Figure 2), the understanding of Conway's Law has changed within the microservices movement: Instead of understanding it as an obstacle, it is now used for designing the architecture. When teams are defined and each is given a specific responsibility, these teams are likely to implement a module or microservice corresponding to their responsibility. Thus, organizing the organization in a certain way indirectly defines the architecture. The Inverse Conway Maneuver thus understands software as a socio-technical system and acts on the technical side through measures on the social side.