Teilen auf
Nahezu alle Menschen nutzen heute Informationstechnik. Die Technik vereinfacht unser Leben – aber je mehr sie leistet, desto komplexer wird sie und desto schneller wachsen die Erwartungen der Anwender:innen. IT-Unternehmen stehen deshalb vor gewaltigen Herausforderungen: Getrieben durch Marktveränderungen, Globalisierung, geändertes Kaufverhalten und anderen Umständen müssen die internen Strukturen, Produktportfolios und Prozesse regelmäßig angepasst werden. Allerdings fehlt es in der IT-Landschaft mit ihren oft monolithischen Altsystemen häufig an der notwendigen Flexibilität. Moderne Architektur auf Basis alter Organisation – das funktioniert selten gut. Viele IT-Projekte scheitern an dieser Problematik.
Will man Software mit moderner Architektur erschaffen, muss man sicherstellen, dass die Team-Architektur dazu nicht im Widerspruch steht. Die Strukturen eines Unternehmens und die ihrer Produkte lassen sich nicht voneinander trennen. Der amerikanische Informatiker Melvin E. Conway leitete aus dieser Tatsache das nach ihm benannte Gesetz ab: „Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“ Die Strukturen beeinflussen und bedingen sich also gegenseitig. Die Folge: Wenn Firmen kompliziert gestaltet sind, sind auch die durch sie erarbeiteten Produkte kompliziert.
Team-Topologien und die vier Team-Typen
Um dem vorzubeugen und zu begegnen, lohnt sich die Analyse der Kommunikationspfade in der Softwarearchitektur – sie lässt aufschlussreiche Rückschlüsse auf das Unternehmen zu. Ergibt sich in der Architektur kein „sauberes“ Bild, ist dies ein guter Anlass, tiefer zu bohren – und sich mit Team-Topologien auseinander zu setzen.
Team-Topologien – als Methodik eingesetzt – ermöglichen es, Organisationsformen und ihre Effekte systematisch zu ergründen. Die Autoren des Buches Team Topologies, Matthew Skelton und Manuel Pais, gehen davon aus, dass im Prinzip nur vier unterschiedliche Arten von Teams existieren, um moderne Applikationen zu erstellen und zu betreiben. Die Firma kann diese vier Arten als Zielpunkt von strukturellen Veränderungen nutzen, was bedeutet, dass alle Teams, Projekte und Abteilungen sich in Richtung einer der folgenden Teamtypen entwickeln:
- Stream-Aligned Teams richten sich an Wertströmen aus. Konkret kann das ein bestimmtes Produkt oder Service sein, oder eine Menge von Eigenschaften im Produkt. Stream-Aligned Teams sind daher nah an den Wünschen und Anforderungen der Kunden und bekommen von diesen Feedback – sie bilden die Basis einer Organisation, während sie von den anderen drei Teamtypen unterstützt werden.
- Enabling Teams setzen sich aus Spezialist:innen für technische oder produktbezogene Bereiche zusammen. Diese Spezialistenteams arbeiten beratend oder lehrend mit den Stream-Aligned Teams zusammen. Dadurch erhalten letztere mehr Freiraum für die wertschöpfende Arbeit. Enabling Teams sehen ihre Aufgabe darin, einerseits immer bei Innovationen vorne zu sein. Andererseits sollen sie sich selbst durch eine effektive Zusammenarbeit im Team und nach außen überflüssig machen.
- Complicated-Subsystem Teams sind für die Entwicklung und die Wartung von Teilen der Applikationen verantwortlich, die ein ausgeprägtes Spezialistenwissen benötigen. Sie beherrschen wichtige Systeme, deren Verfügbarkeit und Weiterentwicklung sie den Stream-Aligned Teams abnehmen.
- Platform Teams schließlich reduzieren die Arbeitslast der Stream-Aligned Teams durch die Übernahme von Unterstützungs- und Infrastrukturaufgaben wie Monitoring oder Deployment. Sie arbeiten eng mit den Stream-Aligned Teams zusammen und legen hohen Wert auf Benutzerfreundlichkeit und Zuverlässigkeit ihrer Services.
Zusammenarbeit für Erfolg
Daraus ergeben sich drei Varianten der Zusammenarbeit: Stream-Aligned Teams befinden sich untereinander üblicherweise in direkter Zusammenarbeit. Im Facilitating Mode unterstützt und ergänzt ein Enabling Team ein anderes Team mit Kompetenzen, die dort fehlen. Der dritte Typus einer Zusammenarbeit – das X-as-a-Service-Modell – besteht in der Bereitstellung von Diensten über Schnittstellen. Dabei ist es essenziell, dass diese sauber und eindeutig definiert sind. Eine direkte anfängliche Zusammenarbeit hilft in diesem Falle, die Schnittstellen zu etablieren.
Die vier Team- und drei Zusammenarbeits-Typen bilden ein wirksames Koordinatensystem, das den Zustand der Organisation offenbart. Weiterhin lässt sich daraus gut eine Ziel-Konstellation ableiten, um eine Autonomie und eine Vermeidung kognitiver Last zu erreichen. Zudem lassen sich die zeitlichen Verläufe dieser Konstellationen formulieren.
Ein Beispiel: Ein Stream-Aligned Team A übernimmt die Verantwortung für einen Wertstrom. Es benötigt Unterstützung durch ein Enabling Team B, um sich mit dieser für sie neuen Technologie vertraut zu machen. Die Beziehung zwischen den Teams muss sich nun über die Zeit wandeln: Die Abhängigkeit von Team B, die zunächst fachliche Lücken schließt, darf nicht dauerhaft bestehen, da sonst Team A seine Aufgabe nicht mehr ohne Team B erfüllen kann. Team B steht zudem anderen Teams nicht zur Verfügung. Die Abhängigkeit bremst alle Prozesse aus. Team A muss daher die nötigen Kenntnisse soweit aufbauen, dass es auf eigenen Füßen stehen kann.
Fazit: Ziele definieren und koordinieren
Die Klarheit in der Formulierung von Zielen, Ist- und Soll-Zuständen ist der große Nutzen eines solchen Koordinatensystems. Es erlaubt die Sichtbarmachung, Beschreibung, Diskussion des Zustandes einer Organisation, und seinen geplanten, zielgerichteten Wandel. Dies alles wird in Zukunft noch viel relevanter, da immer mehr Applikationen entstehen, die miteinander vernetzt sein werden – und die damit eine noch viel größere Dynamik in die Branche bringen.
