Team Topologies und soziotechnisches Design

Teamdesign ist Architekturarbeit

Kapitel 3 hat gezeigt, dass das Gesetz von Conway keine Kuriosität ist, sondern eine Kraft: Das System, das eine Gruppe von Teams baut, bildet tendenziell ab, wie diese Teams kommunizieren. Wenn das stimmt, dann ist die Entscheidung, wie Teams gebildet werden, was jedes verantwortet und wie sie zusammenarbeiten, eine Architekturentscheidung mit ebenso dauerhaften Folgen wie die Wahl einer Datenbank oder eines Integrationsstils. Die Disziplin, Softwarestruktur und Teamstruktur gemeinsam zu gestalten, heißt soziotechnische Architektur.

Der einflussreichste praktische Ansatz dafür ist Team Topologies von Matthew Skelton und Manuel Pais (IT Revolution, 2019; zweite Auflage 2025). Er geht von einem einfachen Ziel aus, dem schnellen Fluss (Fast Flow): einem stetigen, nachhaltigen Strom kleiner Änderungen von der Idee bis in die Produktion, mit wenig Warten zwischen Teams. Dann bietet er ein kleines Vokabular, um Organisationen zu gestalten, die das erreichen: vier Teamtypen, drei Interaktionsmodi, eine Grenze namens kognitive Last des Teams und eine Technik, um die Nähte zu finden, entlang derer sich Software und Teams aufteilen lassen.

Mehrere Grundannahmen ziehen sich durch den Ansatz. Das Team, nicht der Einzelne, ist die Liefereinheit: Arbeit wird an Teams vergeben, Verantwortung liegt bei Teams, und Teams sind langlebig, damit sie Wissen über ihre Domäne und ihren Code ansammeln, statt für ein Projekt zusammengestellt und danach wieder verstreut zu werden. Teams sind klein, meist fünf bis neun Personen, weil Vertrauen und gemeinsames Verständnis jenseits dieser Größe schnell abnehmen (die Autoren stützen sich auf Robin Dunbars Forschung zu Gruppengrößen). Und Teamgrenzen sollten für den Fluss von Änderungen gestaltet werden, nicht nach der Bequemlichkeit von Berichtswegen oder der Geschichte, wer was gebaut hat.

Für Architekten verändert das die Aufgabe. Eine vorgeschlagene Service-Grenze ist nur gut, wenn ein Team sie vollständig verantworten kann; ein vorgeschlagenes Team ist nur tragfähig, wenn der Code, den es verantwortet, ihm erlaubt zu arbeiten, ohne drei andere Teams um Erlaubnis zu fragen. Wer Kästchen zeichnet, ohne zu fragen, wer jedes davon verantworten wird, entwirft nur das halbe System.

Die vier grundlegenden Teamtypen

Team Topologies vertritt die Auffassung, dass fast jedes Team in einer Softwareorganisation einem von vier Typen angehören sollte. Der Sinn so weniger Typen ist Klarheit: Jeder Typ hat einen anderen Zweck, eine andere Art, Erfolg zu messen, und eine andere Beziehung zu den übrigen Teams; wer den Typ eines Teams kennt, weiß also, was er von ihm erwarten kann.

Ein Stream-aligned Team ist auf einen Strom von Änderungen ausgerichtet: ein Produkt, eine Customer Journey, eine Nutzergruppe oder eine fachliche Fähigkeit. Es verantwortet seinen Teil durchgängig, von der Erkundung über den Bau bis zum Betrieb in der Produktion, und sollte die meisten Änderungen liefern können, ohne auf jemanden zu warten. Stream-aligned Teams sind der Standard und sollten die große Mehrheit bilden; die anderen drei Typen gibt es, um ihre Last zu verringern.

Ein Plattformteam stellt interne Dienste (Deployment-Pipelines, eine Laufzeitumgebung, Observability, Dateninfrastruktur) als Produkt bereit, das Stream-aligned Teams per Self-Service nutzen. Eine gute Plattform wird an der Geschwindigkeit ihrer Nutzer gemessen, nicht an ihrer eigenen Feature-Liste. Ein Enabling Team besteht aus Fachleuten, die anderen Teams helfen, eine fehlende Fähigkeit zu erwerben, etwa Testautomatisierung, Observability-Praktiken oder ein neues Framework, und dann weiterziehen; sein Erfolg zeigt sich daran, dass das andere Team es nicht mehr braucht. Ein Complicated-Subsystem-Team verantwortet einen Teil, der seltenes Fachwissen erfordert, etwa eine Preis-Engine auf Basis versicherungsmathematischer Modelle, einen Solver zur Routenoptimierung oder einen Video-Codec, damit Stream-aligned Teams ihn nutzen können, ohne ihn beherrschen zu müssen. Das Buch betont, dass dieser Typ sparsam und nur bei echtem Spezialwissen eingesetzt werden sollte.

Drei Interaktionsmodi

Teamtypen sagen, was Teams sind; Interaktionsmodi sagen, wie sie zusammenarbeiten. Skelton und Pais argumentieren, dass unklare, spontane Zusammenarbeit zwischen Teams eine Hauptursache für Verzögerungen ist, weil jedes ungeplante Gespräch eine Abhängigkeit darstellt. Sie empfehlen daher, dass jedes Paar von Teams, das zusammenarbeiten muss, bewusst einen von drei Modi wählt, für einen festgelegten Zeitraum.

Bei Collaboration arbeiten zwei Teams eng an einem gemeinsamen Ziel zusammen, mit verschwimmenden Zuständigkeiten, zum Beispiel während sie herausfinden, wie eine neue Fähigkeit aufgeteilt werden sollte. Das bringt schnelles Lernen, kostet aber beide Teams Kapazität und kognitive Last und sollte daher zeitlich begrenzt sein. Bei X-as-a-Service stellt ein Team etwas bereit (eine API, eine Plattformfähigkeit, eine Bibliothek), das ein anderes mit wenig oder ganz ohne Abstimmung nutzt; das skaliert gut, funktioniert aber erst, wenn die Grenze gut verstanden und die Schnittstelle gut ist. Bei Facilitating hilft ein Team, typischerweise ein Enabling Team, einem anderen, etwas zu lernen oder ein Hindernis zu beseitigen.

Die Modi sollen sich ändern. Ein häufiger Ablauf ist erst erkunden, dann festigen: Ein Plattformteam arbeitet einige Wochen mit einem Stream-aligned Team zusammen, um eine neue Fähigkeit zu entwerfen, macht daraus dann ein Self-Service-Angebot und wechselt zu X-as-a-Service. Die Modi dienen auch als Sensor. Wenn ein Team, das einen Service als Service nutzen soll, ständig Meetings braucht, sind die Schnittstelle oder die Grenze wahrscheinlich falsch; wenn zwei Teams seit einem Jahr zusammenarbeiten, sind sie vielleicht in Wahrheit ein Team, oder die Trennung zwischen ihnen liegt an der falschen Stelle.

Kognitive Last als Entwurfsrandbedingung

Die Idee der kognitiven Last stammt aus der pädagogischen Psychologie. John Swellers Cognitive Load Theory, erstmals 1988 veröffentlicht, ging von der Beobachtung aus, dass das menschliche Arbeitsgedächtnis nur wenige neue Elemente gleichzeitig halten und verarbeiten kann, sodass Unterricht so gestaltet werden sollte, dass er es nicht überlastet. Die Theorie unterscheidet intrinsische Last (die inhärente Schwierigkeit des Stoffs), extrinsische Last (Schwierigkeit, die durch die Art der Aufgabenstellung entsteht) und, in späteren Arbeiten, lernbezogene Last (germane Load: Anstrengung, die dauerhaftes Verständnis aufbaut). Die Forschung diskutiert noch, ob die lernbezogene Last eine eigene Kategorie ist, und Team Topologies nutzt alle drei als praktische Heuristik, nicht als Messgröße.

Abschnitt 3.7 hat die Teamversion dieser Idee eingeführt: alles, was ein Team im Kopf behalten muss, um das zu bauen, zu betreiben und zu ändern, was es verantwortet. Hier geht es darum, sie als Entwurfsrandbedingung zu nutzen. Wenn eine Architektur einem Team mehr zuweist, als es verstehen kann, sind die Folgen vorhersehbar: langsamere Lieferung, oberflächliche Fixes, eine fragile Rufbereitschaft, Wissen, das sich auf ein oder zwei Personen konzentriert, und schließlich Kündigungen. Es sind dieselben Symptome, die oft schlechten Entwicklern oder schlechtem Code angelastet werden.

Das Buch bietet Faustregeln, um die Verantwortlichkeiten eines Teams nach der Komplexität der Domäne zu bemessen: Geben Sie jede Domäne einem einzigen Team; ein Team kann meist zwei oder drei einfache Domänen bewältigen; ein Team, das eine komplexe Domäne verantwortet, sollte nichts anderes verantworten; und kein Team sollte zwei komplizierte Domänen verantworten. Man kann Teams auch direkt fragen, zum Beispiel mit einer kurzen Umfrage dazu, wie gut sie ihre Systeme verstehen, wie sicher sie sich in der Rufbereitschaft fühlen und wie viel Zeit in Werkzeuge statt in die Domäne fließt. Wachsende Ticket-Warteschlangen, lange Einarbeitungszeiten und häufige Übergaben an die eine Person, die eine Komponente versteht, sind nützliche indirekte Signale.

Die architektonischen Antworten spiegeln die drei Arten von Last. Verringern Sie die extrinsische Last mit Plattformen, Automatisierung, Paved Roads und guter Dokumentation. Begrenzen Sie die intrinsische Last, indem Sie Service- und Modulgrenzen so ziehen, dass der Anteil jedes Teams an der Domäne zusammenhängend und von beherrschbarer Größe ist, und indem Sie tiefe Spezialgebiete hinter Schnittstellen von Complicated Subsystems legen. Schützen Sie die lernbezogene Last, indem Sie Zeit zum Lernen lassen; hier helfen Enabling Teams.

Team-APIs und die Thinnest Viable Platform

Wenn Teams in bewusst gewählten Modi zusammenarbeiten, braucht jedes Team ein klares Gesicht gegenüber dem Rest der Organisation. Team Topologies nennt das die Team-API: alles, was das Team anbietet und erwartet. Dazu gehört die technische API (Endpoints, Events, Bibliotheken sowie ihre Regeln für Versionierung und Abkündigung), aber auch die menschliche Schnittstelle: Dokumentation und Onboarding-Leitfäden, die Roadmap und aktuellen Prioritäten des Teams, seine Arbeitsweisen, die Kanäle, über die es erreichbar ist, wie man Arbeit bei ihm anfragt und mit welchen Antwortzeiten zu rechnen ist.

Eine Team-API aufzuschreiben ist eine günstige und aufschlussreiche Übung. Sie zwingt ein Team zu sagen, was es verantwortet, was meist Services ohne Verantwortliche und umstrittene Daten offenlegt, und sie gibt anderen Teams eine Möglichkeit zur Zusammenarbeit ohne Meeting. Viele Organisationen führen sie als kurze Seite im Repository des Teams, die jedes Quartal zusammen mit der Architekturdokumentation überprüft wird.

Die Plattform verdient besondere Sorgfalt, weil hier gute Absichten am häufigsten schiefgehen. Eine Plattform, die als großes internes Projekt mit langer Roadmap und verpflichtender Einführung gebaut wird, kann leicht kognitive Last hinzufügen, statt sie zu verringern. Skelton und Pais empfehlen die Thinnest Viable Platform: die kleinste Menge an Diensten, Dokumentation und Standards, die ihre Nutzer tatsächlich schneller macht. Für eine kleine Organisation kann das eine gut gepflegte Seite sein, die auflistet, welche Dienste des Cloud-Anbieters die Teams nutzen sollen und wie; für eine große kann es eine Internal Developer Platform sein. Platform Engineering wird ausführlich in Kapitel 10 behandelt; entscheidend ist hier, dass eine Plattform ein Produkt ist, dessen Kunden andere Teams sind, und dass sie als solches gestaltet und gemessen werden sollte.

Bruchlinien: wo Software und Teams aufgeteilt werden

Wenn ein Teil des Systems für ein Team zu groß geworden ist, muss er aufgeteilt werden, und die Aufteilung muss sowohl für den Code als auch für die Teams funktionieren. Team Topologies nennt die natürlichen Nähte, entlang derer sich Software teilen lässt, Bruchlinien (Fracture Planes). Das Buch nennt mehrere, und die erste ist meist die beste: ein Bounded Context aus dem Domain-Driven Design, weil eine Grenze, die der Sprache und den Regeln des Geschäfts folgt, zusammengehörige Änderungen tendenziell beieinanderhält.

Die anderen sind nützlich, wenn sie mit einem echten Unterschied darin übereinstimmen, wie Teile des Systems behandelt werden müssen. Eine Aufteilung allein entlang einer Technologiegrenze (zum Beispiel ein Mobile-Team und ein Backend-Team) ist in der Regel die schwächste Wahl, weil die meisten Änderungen sie dann überqueren; das ist genau die geschichtete Teamstruktur, vor der das Gesetz von Conway warnt.

Das Gesetz von Conway, das Inverse Conway Maneuver und seine Grenzen

Team Topologies ist im Grunde ein Werkzeugkasten für das Inverse Conway Maneuver, das Abschnitt 3.7 beschrieben hat: Legen Sie die gewünschte Architektur fest, und gestalten Sie dann Teams und Interaktionsmodi so, dass das Gesetz von Conway das System in diese Richtung treibt. Seine Ergänzungen sind praktischer Natur. Teamtypen sagen, welche Art von Team jeden Teil verantworten sollte; Interaktionsmodi sagen, welche Teamgrenzen dünn sein sollen (X-as-a-Service) und welche vorübergehend dick (Collaboration); die kognitive Last sagt, wie viel jedes Team verantworten kann; Bruchlinien sagen, wo geschnitten wird.

Die Grenzen aus Abschnitt 3.7 gelten weiterhin und verdienen es, in diesem Zusammenhang wiederholt zu werden. Eine Neuorganisation der Teams strukturiert eine eng gekoppelte Codebasis nicht um: Monatelang nach einer Neuorganisation kämpfen die neuen Teams gegen die alte Architektur, weshalb Teamänderungen und Architekturänderungen als ein gemeinsames Programm geplant werden sollten. Grenzen, die zu früh in Teams verfestigt werden, machen Fehler teuer; viele Organisationen halten unsichere Grenzen daher innerhalb eines Teams oder eines modularen Monolithen, bis sie Belege haben. Und häufige Neuorganisationen zerstören das Wissen langlebiger Teams, auf das der Ansatz angewiesen ist.

Fachleute sind sich auch uneinig, wie wörtlich der Ansatz anzuwenden ist. Befürworter schätzen das gemeinsame Vokabular, das vage Klagen (wir warten ständig auf das Datenteam) in gestaltbare Fragen verwandelt (welchen Interaktionsmodus wollen wir mit dem Datenteam, und was würde ihn zu X-as-a-Service machen?). Kritiker warnen, dass die vier Typen oft als Etiketten auf eine unveränderte Organisation geklebt werden, dass echte Teams manchmal Typen mischen (ein Plattformteam, das auch ein Complicated Subsystem verantwortet) und dass der Ansatz wenig über Finanzierung, Führungsstruktur oder Anreize sagt. Beide Punkte sind berechtigt: Die Typen sind eine Entwurfshilfe, kein Organigramm, und die Autoren selbst stellen sie als Ausgangspunkt für fortlaufende Anpassung dar.