Microservices: Architektur oder Organisation?

Architektur und Organisation sind eigentlich zwei getrennte Bereiche. Microservices haben das Gesetz von Conway wieder entdeckt – und ziehen daraus interessante Konsequenzen. Was bedeutet es, wenn Architektur und Organisation eigentlich dasselbe sind?

Softwarearchitektur regelt eigentlich "nur" die Struktur von Softwaresystemen – und ist für Verständlichkeit und Wartbarkeit zentral. Also ist Architektur sehr wichtig – aber "nur" ein technisches Thema. Das Gesetz von Conway stellt aber eine Verbindung zwischen Architektur und Organisation her. Das Gesetz besagt, dass eine Organisation nur solche Architekturen hervorbringen kann, die ihren Kommunikationsstrukturen entspricht. Der Grund dafür: Jeder in der Organisation arbeitet an einem Teil der Architektur. Wenn zwei Teile der Architektur eine Schnittstelle haben, müssen die zuständigen Team-Mitglieder die Schnittstelle abstimmen – also haben sie eine Kommunikationsbeziehung.

Die Organisation und die Architektur sind nur zwei Seiten derselben Medaille. Das Gesetz von Conway ist von 1968 und erlebt gerade eine Renaissance: Microservices nutzen das Gesetz aus. Statt die Einschränkungen durch die Kommunikationsbeziehungen bei der Architektur hinzunehmen, richten Microservice-Projekte die Organisation nach der Architektur aus. So ist gewährleistet, dass die Architektur eingehalten wird. Schließlich kann die Organisation nur Architekturen hervorbringen, die ihren Kommunikationsstrukturen entspricht. Also kann sie nicht gegen eine Architektur verstoßen, die ihren Kommunikationsstrukturen entspricht.

Wenn die Teams dann auch noch nach fachlichen Komponenten aufgeteilt sind, kann jedes Team an einer eigenen Aufgabe arbeiten. So wird das parallele Arbeiten an verschiedenen Features möglich. Also gibt es Teams für Fachlichkeiten wie den Bestellprozess oder die Lieferung. Und auch jeweils fachliche Komponenten, die die Teams implementieren.

Neu ist die Aufteilung der Teams nach Fachlichkeiten nicht. Neu sind Microservices: Sie erlauben eine große technische Unabhängigkeit. Jeder Microservice kann beispielsweise in einer anderen Programmiersprache für eine andere Plattform implementiert sein. Daher erlauben Microservices unabhängige Teams, die beispielsweise Technologien nicht mehr koordinieren müssen.

Auswirken und offene Fragen

Die Unabhängigkeit löst ein entscheidendes Probleme bei der Skalierung von Teams: Die Anzahl der möglichen Kommunikationsbeziehungen wächst quadratisch mit der Anzahl der Teammitglieder. Große Teams erzeugen also einen Kommunikations-Overhead – wenn die Kommunikation nicht eingeschränkt wird. Wegen der Unabhängigkeit der Komponenten erlauben Microservices genau eine solche Einschränkung, weil einige Themen wie Technologien nicht mehr diskutiert werden müssen.

Aber sind das schon alle Auswirkungen von "Architektur = Organisation"? Einige Fragen bleiben offen. Wenn Architektur und Organisation so stark voneinander abhängen, müssen Architekten dann auch die Organisation beeinflussen? Sollten Architekten Manager sein? Wenn eine Architektur untersucht wird, kann man die Organisation außen vor lassen?

Eine weitere Auswirkung stellt schon das ursprünglichen Paper von Conway dar: Weil Kommunikation in großen Organisationen schwierig ist, kann die Kommunikation zusammenbrechen. In der Folge bricht die Architektur zusammen. Und so entsteht das perfekte Desaster: ein großes Projekt mit einem großen Team und einer kaputten Architektur. Ein großes Team aufzubauen ist attraktiv, so Conway weiter: Für ein kompliziertes Problem erzeugt ein großes Team den Eindruck, dass dem Problem adäquat begegnet wird. Und der Status eines Managers hängt davon ab, wie viele Mitarbeiter an sie berichten.

Der Gesetze zwei

Dann erwähnt Conway noch das Parkinsonsche Gesetz – das aber nicht ganz ernst zu nehmen ist. Es besagt, dass eine Aufgabe sich immer so weit ausdehnt, bis alle Ressourcen ausgenutzt werden. Ein großes Team kann sich auch dann mit einer Aufgabe erschöpfend beschäftigen, wenn sie von einem kleinen Team erledigt werden könnte. Es gibt sicherlich Aufgaben, die nur große Teams erledigen können. Aber große Teams haben – wie Parkinson beschreibt – Nachteile, sodass man mit großen Team vorsichtig sein muss – und auch mit dem Vergrößerern von Teams.

Fazit: "Architektur = Organisation" ist eine sehr interessante und alte Idee – deren vollständige Auswirkungen noch nicht klar sind. ()