Team und Softwarearchitektur im Einklang – ein soziotechnisches System

Scheinbar geht es bei Softwarearchitektur nur um die Strukturierung von Software und die Umsetzung von nicht funktionalen Anforderungen. Aber in Wirklichkeit ist die Software für Menschen da und Menschen schreiben die Software. Daher ist es notwendig, sie als ein soziotechnisches System zu begreifen. Das hat Auswirkungen auf das Verständnis von Softwarearchitektur.

Der Begriff Soziotechnisches System steht für eine organisierte Menge von Menschen und mit diesen verknüpfte Technologien, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Er geht auf Forschung unter anderem im Steinkohlebergbau in Großbritannien in den 1950er-Jahren zurück. Die Idee von soziotechnischen Systemen ist somit nicht neu und schon gar keine Mode. Eine Kernerkenntnis ist, dass der Erfolg eines Unternehmens davon abhängt, wie es als soziotechnisches System funktioniert, nicht einfach als ein technisches System mit ersetzbaren Individuen, die hinzugefügt werden und sich anpassen müssen.

Die Bezeichnung sagt bereits, worum es geht: Das System besteht aus einer technischen Komponente (etwa Maschinen) und einer sozialen Komponente (Mitarbeiterinnen und Mitarbeiter, die technische Komponenten bedienen und nutzen). Beide lassen sich nur gemeinsam betrachten, da sie eng miteinander verknüpft sind. Deswegen muss man auch menschliche Kommunikation neben der Mensch-Maschine-Kommunikation betrachten.

Dieser Ansatz ist für Softwareentwicklung und -architektur gleich aus mehreren Gründen interessant: Erstens wird Softwareentwicklung oft als eine rein technische Aufgabe begriffen und betrieben. Das ist sie aber nur scheinbar. Software als soziotechnisches System zu behandeln, birgt die Chance, wesentliche Verbesserungen zu erreichen. Zweitens löst die meiste Software keine rein technischen Probleme, sondern muss für Anwenderinnen und Anwender sowie andere Stakeholder einen wirtschaftlichen Nutzen haben.

Damit steht die Software in einem wichtigen Verhältnis zu dieser Personengruppe, da der Wert der Software sich an dem wirtschaftlichen Nutzen für diese Gruppe orientiert. Dieser soziale Aspekt ist zentral für den Erfolg eines Softwareentwicklungsprojekts. Und schließlich wird Software in Teams implementiert. Auch bei der Entwicklung gibt es also ein soziales Geflecht, das es zu verwalten gilt. Wenn man diese Aufgabe besonders gut erfüllt, wird man effektiv und effizient entwickeln.

Tatsächlich steht Softwarearchitektur in einem engen Zusammenhang mit beiden sozialen Systemen – Entwickler und User (siehe Abbildung 1). Softwarearchitektur muss eine technische Lösung finden, die Nutzerinnen und Nutzer ausreichend unterstützt. Dabei sind Qualitäten der Software wie Benutzerfreundlichkeit, Performance, Skalierbarkeit oder Sicherheit zu betrachten. Dieser Teil der Architektur ist daher nur im Zusammenspiel mit diesem sozialen System bewertbar. Eine Architektur lässt sich nur daran messen, ob sie ausreichende Qualitäten für die Benutzergruppe mit sich bringt. Was für einige Personen subjektiv unmöglich zu benutzen ist, kann für andere akzeptabel oder gar ideal sein – man denke nur an die Auseinandersetzungen zu Editoren wie Vim oder Emacs.

Die Aufteilung eines Systems in Module dient dazu, die Komplexität des Systems beherrschbar zu machen. Damit ist die Modularisierung nur im Zusammenspiel mit dem jeweiligen Entwicklungsteam bewertbar. Auch eine scheinbar gute Modularisierung kann für das Team schwer verständlich sein und zu geringer Produktivität führen. Beispielsweise kann ein Team ein System ohne eine gute Übergabe von einem anderen Team übernommen haben, sodass das neue Team es trotz guter Modularisierung schwer verstehen und ändern kann.

Es ist auch denkbar, dass das System zwar schlecht strukturiert ist, aber das Team sich über einen längeren Zeitraum an diese Struktur gewöhnt hat und daher das System ausreichend gut ändern kann. Dann kann das Team die Software schwerlich abgeben, weil ein neues Team Schwierigkeiten hätte, sie zu verstehen. Das ist weniger ein technisches Problem, sondern lässt sich als ein soziales Problem auffassen.

Das Gesetz von Conway

Das Gesetz von Conway besagt, dass eine Organisation ein System entwickeln wird, dessen Design die Kommunikationsstrukturen der Organisation kopiert. Für die Softwareentwicklung bedeutet das beispielsweise: Wenn zwei Teams zwei Aufgaben haben und darüber bei Bedarf miteinander kommunizieren, werden sie in der Software zwei Module aufbauen, die eine Schnittstelle haben. Klassisch hat man das Gesetz von Conway eher als ein Hindernis begriffen: Wenn Teams in einer bestimmten Art organisiert sind, können sie nur bestimmte Architekturen erstellen. Sind ein UI- und ein Backend-Team vorhanden, werden auch ein UI und ein Backend in der Architektur entstehen.

Dabei wird jedoch das Organigramm mit Kommunikation verwechselt. Aber Menschen und Teams kommunizieren auch dann, wenn sie im Organigramm keine offensichtlichen Beziehungen besitzen. Zwar kann das Organigramm einen wesentlichen Einfluss auf die Kommunikation ausüben, aber es ist nicht deckungsgleich. Das ist auch eine gute Nachricht: Während das Organigramm statisch ist, kann jede involvierte Person die Kommunikationsflüsse im Projekt beeinflussen.

Aus dem Zusammenhang zwischen Kommunikation und Architektur ergibt sich ein weiteres Problem: Wenn die Kommunikation nicht mehr effektiv ist oder zusammenbricht, leidet die Architektur des Systems darunter. Gerade bei großen Projekten ist es schwierig, eine gute Kommunikation zu bewahren. Daher kann es insbesondere hier dazu kommen, dass zunächst die Kommunikation schwierig und dann die Architektur in Mitleidenschaft gezogen wird.

Solche Probleme hat Melvin Conway schon 1967 im ursprünglichen Paper zu seinem Gesetz beschrieben. Wenn Softwarearchitektinnen und -architekten die Qualität der Architektur erhalten oder gar verbessern wollen, müssen sie auf die Kommunikation im Projekt Einfluss nehmen und gewährleisten, dass sie funktioniert.

Durch das Inverse Conway Maneuver (siehe Abbildung 2) hat sich im Rahmen der Microservices-Bewegung das Verständnis für das Gesetz von Conway gewandelt: Statt es als Hindernis zu verstehen, will man es nun für die Gestaltung der Architektur nutzen. Wenn Teams definiert werden und jedes eine bestimmte Verantwortung erhält, werden diese Teams voraussichtlich jeweils ein Modul oder einen Microservice implementieren, der ihrer Verantwortung entspricht. Das Aufstellen der Organisation auf eine bestimmte Weise definiert somit indirekt die Architektur. Das Inverse Conway Maneuver versteht Software demnach als soziotechnisches System und wirkt durch Maßnahmen auf der sozialen Seite auf die technische ein.