Team Topologies E-Book

Matthew Skelton

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 435

Beschreibung

Mit gut geplanten Teamstrukturen die Softwareentwicklung nachhaltig beschleunigen - International richtungsweisende Methode, um leistungsfähige Teams zu formen - Anwendbares Praxiswissen: Wie Sie funktionierende Teamgrenzen bestimmen und Team-APIs entwerfen - Kombiband: Enthält neben dem Hauptwerk »Team Topologies« das Workbook zur Interaktion verteilt arbeitender Teams. Effektive Softwareteams sind für jedes Unternehmen unerlässlich, um kontinuierlich und nachhaltig Werte zu schaffen.  Team Topologies ist ein praktisches, schrittweise anpassbares Modell für die Gestaltung von Organisationen und die Interaktion von Teams. Es basiert auf vier Teamtypen und drei Formen der Teaminteraktion und versteht Teams als entscheidenden Faktor der Wertschöpfung. Mit der technologischen und organisatorischen Reife einer Organisation werden sich Teamstrukturen und Kommunikationswege kontinuierlich weiterentwickeln. Im Bestseller Team Topologies präsentieren die IT-Berater Matthew Skelton und Manuel Pais eine grundlegende Weiterentwicklung des Organisationsdesigns für die Entwicklung von Software. Anhand von Fallstudien und Beispielen aus der Industrie beschreiben sie eine klar definierte Vorgehensweise für die Interaktion und das Zusammenwirken von Teams. Ihre Methode trägt entscheidend dazu bei, die Architektur von Software klarer und nachhaltiger zu gestalten und Probleme zwischen Teams in wertvolle Signale für eine sich selbst lenkende Organisation zu verwandeln. - Verstehen Sie das Conway'sche Gesetz und seine Bedeutung - Vereinfachen Sie mit vier Teamtypen die Organisation moderner Softwareteams - Gestalten Sie Teamgrenzen – und -APIs und reduzieren Sie die kognitive Belastung Ihrer Entwicklungsteams - Verbessern Sie durch drei Formen der Interaktion die Bereitstellung von Software - Nutzen Sie den Betrieb der Software als sensorischen Input zur Selbststeuerung Ihrer Organisation

Leseprobe

Team Topologies

Organisation von Business- und IT-Teams füreinen schnellen Arbeitsfluss

Inklusive

Interaktionen in verteilten Teams – Workbook

Team-Topologies-Patterns für eineproduktivere Zusammenarbeit

Matthew Skelton, Manuel Pais

Deutsche Übersetzung vonMichael Plöd

Matthew Skelton, Manuel Pais

Lektorat: Ariane Hesse

Übersetzung: Michael Plöd

Copy-Editing: Claudia Lötschert, www.richtiger-text.de

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-96009-231-5

PDF

978-3-96010-836-8

ePub

978-3-96010-837-5

mobi

978-3-96010-838-2

1. Auflage 2024

Translation Copyright © 2024 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English original »Team Topologies: Organizing Business and Technology Teams for Fast Flow«, Copyright © 2019 by Matthew Skelton and Manuel Pais, ISBN 9781942788812; »Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working« Copyright © 2022 by Matthew Skelton and Manuel Pais, ISBN 9781950366347. This translation is published and sold by permission of IT Revolution Press LLC, which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Hinweis:

Dieses Buch wurde mit mineralölfreien Farben auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie. Hergestellt in Deutschland.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autoren noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

MATTHEW

Meiner Frau Suzy Beck – für all ihre Unterstützung und Inspiration.

MANUEL

Für Katie, meine Lebensgefährtin und Hochburg unserer Familie – danke für deine unermüdliche Liebe und Unterstützung.

Für Dan und Ben, die täglichen Quellen der Wärme – hoffentlich kann dieses Buch dazu beitragen, dass ihr versteht, was Daddy beruflich macht.

Inhalt

Team Topologies

Vorwort

Vorwort des Übersetzers

Einleitung

Teil ITeams als entscheidendes Mittel bei der Lieferung

Die wichtigsten Erkenntnisse

1Das Problem mit Organisationsdiagrammen

Kommunikationsstrukturen einer Organisation

Team Topologies: Eine neue Art, über Teams zu denken

Das Revival von Conway’s Law

Kognitive Belastung und Engpässe

Zusammenfassung: Überdenken Sie Teamstrukturen, Zweck und Interaktionen

2Das Conway’sche Gesetz und seine Bedeutung

Das Conway’sche Gesetz verstehen und anwenden

Das Reverse Conway Maneuver

Softwarearchitekturen, die einen teamorientierten Arbeitsfluss fördern

Organisationsgestaltung erfordert technische Expertise

Beschränken Sie unnötige Kommunikation

Achtung! Naive Anwendungen des Conway’schen Gesetzes

Zusammenfassung: Conway’s Law ist entscheidend für effizientes Teamdesign in der Tech-Branche

3Teamorientiertes Denken

Setzen Sie auf kleine, langlebige Teams als Standard

Gute Grenzen verringern die kognitive Belastung

Entwerfen Sie »Team-APIs« und gestalten Sie Teaminteraktionen

Warnung: Engineering-Praktiken sind unerlässlich

Zusammenfassung: Begrenzen Sie die kognitive Belastung von Teams und gestalten Sie Teaminteraktionen, um einfacher und schneller zu arbeiten

Teil IITeam Topologies, die für einen reibungslosen Arbeitsfluss sorgen

Die wichtigsten Erkenntnisse

4Statische Team Topologies

Team-Anti-Patterns

Design für den Fluss des Wandels

DevOps und die DevOps-Topologien

Erfolgreiche Team-Patterns

Überlegungen bei der Auswahl einer Topologie

Verwendung von DevOps-Topologien zur Weiterentwicklung der Organisation

Zusammenfassung: Adaptieren und entwickeln Sie Team-Topologien, die zu Ihrem aktuellen Kontext passen

5Die vier grundlegenden Team Topologies

Stream-aligned Teams

Enabling Teams

Complicated-subsystem Teams

Platform Teams

Vermeiden Sie Team-Silos im Zuge des Wandels

Eine gute Plattform ist »gerade groß genug«

Ordnen Sie die bekannten Teamtypen den grundlegenden Team Topologies zu

Zusammenfassung: Verwenden Sie lose gekoppelte, modulare Gruppen von vier spezifischen Teamtypen

6Entscheiden Sie sich für teamorientierte Grenzen

Ein teamorientierter Ansatz für Zuständigkeiten und Grenzen von Software

Versteckte Monolithen und Kopplung

Softwaregrenzen oder »Bruchflächen«

Beispiel aus der realen Welt: Fertigungsindustrie

Zusammenfassung: Wählen Sie Softwaregrenzen, die der kognitiven Belastung des jeweiligen Teams entsprechen

Teil IIIEvolution von Teaminteraktionen für Innovation und schnelle Lieferfähigkeit

Die wichtigsten Erkenntnisse

7Die Modi der Teaminteraktion

Gut definierte Interaktionen sind der Schlüssel zu effektiven Teams

Die drei wesentlichen Modi der Teaminteraktion

Teamverhaltensweisen für jeden Interaktionsmodus

Auswahl geeigneter Modi für die Teaminteraktion

Auswahl der grundlegenden Teamorganisation

Wählen Sie Teaminteraktionsmodi, um Unsicherheiten zu verringern und den Arbeitsfluss zu verbessern

Zusammenfassung: Drei gut abgegrenzte Modi der Teaminteraktion

8Entwickeln Sie Teamstrukturen mit einem Gespür für organisatorische Belange

Wie viel Collaboration ist für jede Teaminteraktion angemessen?

Beschleunigung des Lernens und der Übernahme neuer Praktiken

Konstante Evolution der Team Topologies

Die Kombination von Team Topologies für mehr Effektivität

Auslöser für die Evolution von Team Topologies

Selbststeuerung von Design und Entwicklung

Zusammenfassung: Evolutionäre Team Topologies

Schlussfolgerung: Das digitale Betriebsmodell der nächsten Generation

Anhang AGlossar

Anhang BLiteraturempfehlungen

Anhang CLiteraturverzeichnis

Anhang DDanksagungen

Interaktionen in verteilten Teams – Workbook

Vorwort

Einleitung

1Überblick – Fokus auf remote Teaminteraktionen

Was braucht ein Unternehmen, um in einer remote-orientierten Welt erfolgreich zu sein?

Verwenden Sie den Team-API-Ansatz zum Definieren und Kommunizieren von Verantwortlichkeiten und Team-Fokus

Abhängigkeiten mit einfachen Tools verfolgen und blockierende Abhängigkeiten entfernen

Kommunizieren Sie viel, dokumentieren Sie schriftlich aber nur das Nötigste

Zusammenfassung: Gestalten und definieren Sie die Art und Weise, wie Teams interagieren

2Teamabhängigkeiten

Team-API

Tracking von Abhängigkeiten

Netzwerke aufbauen: Kaffee, Gespräche, interne Konferenzen

3Festlegung von Teamgrenzen

Vertrauensgrenzen für Gruppen

Einrichtung des Online-Raums

Teamorientierte Konventionen für Chat-Tools

4Zweckmäßige Interaktionen

Modi der Teaminteraktion: Ein Rückblick

Beobachten von Teaminteraktionen

Klärung von Kommunikationszweck und -kanälen

Für die Klarheit des Zwecks von Plattformen und Services sorgen

5Nächste Schritte

Entwerfen und Durchführen einer Plattform-Umfrage zur Developer Experience

Definieren Sie Namens- und Nutzungskonventionen für Chat-Tools

Verwenden Sie die Team-API mit mehreren Teams, um Teamgrenzen zu definieren und zu präzisieren

Erstellen und teilen Sie einen Durchführungsplan

Liste der Ressourcen

Über die Autoren

Stimmen zu Team Topologies

Gesamtindex

Team Topologies

Vorwort

Unsere Systeme klein und einfach zu halten, ist ein erstrebenswertes Ziel, dem sich aber sogar die meisten erfolgreichen Systeme widersetzen. Lehman’s Law der Softwareevolution, und insbesondere das kontinuierliche Wachstum, beschreibt den ständigen Druck, neue Funktionalitäten hinzuzufügen, wenn Systeme genutzt und neue Anforderungen oder Möglichkeiten wahrgenommen werden. Die Fähigkeit, mit dieser zunehmenden Komplexität nicht nur irgendwie umzugehen, sondern sie sogar gewinnbringend zu nutzen, erhöht die Bedeutung von zwei Bereichen des Designs: dem Design von Systemen und dem Design der Organisation, die Systeme erstellt und weiterentwickelt. Wir verfügen über eine beträchtliche Anzahl von Veröffentlichungen, die sich auf den ersten Bereich konzentrieren, d. h. auf System- und Softwaredesign und -architektur, einschließlich einer ständig wachsenden Anzahl von Büchern über Domain-driven Design und Softwarearchitektur. Team Topologies befasst sich mit der Gestaltung der Softwareentwicklungsorganisation unter Berücksichtigung von Conway’s Law.

Die Grundthese […] ist, dass Organisationen, die Systeme entwerfen […], gehalten sind, Entwürfe zu erstellen, die eine Kopie der Kommunikationsstrukturen dieser Organisationen sind. Wir haben gesehen, dass diese Tatsache wichtige Implikationen für das Management des System-Designs hat. In erster Linie haben wir ein Kriterium für die Strukturierung von Design-Organisationen gefunden: Ein Design-Aufwand sollte nach dem Bedarf an Kommunikation organisiert werden.1

Das obige Zitat aus der Schlussfolgerung von Mel Conways klassischem Paper über Organisationsdesign für Softwareentwicklung ist ein sehr passender Anfang für dieses Buch. Team Topologies beschreibt organisatorische Muster für die Teamstruktur und die Art der Interaktion, wobei die Kraft, die die Organisation auf das System ausübt, als ein treibendes Design-Anliegen betrachtet wird.

Mit zunehmender Komplexität des Systems steigen in der Regel auch die kognitiven Anforderungen an die Organisation, die das System aufbaut und weiterentwickelt. Die Beherrschung der kognitiven Belastung durch Teams mit klaren Zuständigkeiten und Grenzen ist ein besonderer Schwerpunkt der Teamgestaltung im Rahmen des Team-Topologies-Ansatzes. Zur Erzielung angemessener, abgegrenzter Verantwortlichkeiten wird eine natürliche und relativ unabhängige System-(Unter-)Struktur angestrebt, an der sich die Teams dann ausrichten. Dabei wird das Conway’sche Gesetz berücksichtigt und genutzt, um kohäsive Strukturen mit klaren Grenzen und loser Kopplung zu gewährleisten (bekannt als umgekehrtes Conway-Manöver, das hier beschrieben wird).

Wenn das alles wäre, wäre Team Topologies eine nützliche Ausarbeitung von Conways Paper und würde sie in den aktuellen Kontext stellen. Natürlich ist Team Topologies noch mehr als das. Insbesondere werden vier Team-Patterns aufgezeigt und ihre Ergebnisse, ihre Form und die Kräfte, die sie betreffen und von denen sie geprägt werden, beschrieben. Stream-aligned Teams sind die primäre Teamform. Diese Teams sind für den Arbeitsfluss optimiert und verfügen über alles, was sie brauchen, um eine kontinuierliche Wertschöpfung zu erzielen und auf die damit verbundenen Rückkopplungszyklen voll zu reagieren. Das bedeutet, dass beim System-Design nicht nur eine lose Kopplung angestrebt wird, sondern eine Dekomposition, die den Arbeitsfluss unterstützt und die Abhängigkeiten und den Koordinationsbedarf zwischen Stream-aligned Teams verringert. Complicated-subsystem Teams und Platform Teams reduzieren die Belastung der Stream-aligned Teams, wobei letztere interne Kunden der Subsystem- oder Plattformfähigkeiten der ersteren sind (und alle Phasen der Entwicklung, Lieferung und des Betriebs für mehrere Stream-Teams unterstützen). Enabling Teams dienen ebenfalls anderen Teams, aber sie sind Dienstleister, die den Stream-aligned Teams dabei helfen, neue Techniken zu erlernen, neue Technologien zu erforschen usw., sodass die Stream-aligned Teams ihren Fokus beibehalten und gleichzeitig ihre Effektivität steigern können.

Matthew Skelton und Manuel Pais haben ihre beträchtliche Erfahrung eingebracht, indem sie beschrieben haben, was diese verschiedenen Teamformen brauchen, um erfolgreich zu sein. Sie bringen aber auch Variationen im Kontext hervor, identifizieren die daraus resultierenden Designimplikationen und weisen auf zu vermeidende Anti-Patterns hin. Mit enormer Großzügigkeit fügen sie auch Erkenntnisse aus einschlägigen Arbeiten hinzu und weisen auf diese hin. Zusammen mit einer Reihe von Fallstudien ergänzt dies das Buch weiter.

Team Topologies verbessert und bereichert unser Verständnis der Organisationsarchitektur durch die nuancierte Darstellung der wichtigsten Strukturmuster, Interaktionsmodi oder Dynamiken und Überlegungen zur Evolution. Aufgrund seiner Klarheit und Fokussierung dient es als pragmatischer Leitfaden für die Bildung von Teams und die Bewältigung ihrer Herausforderungen oder für die Unterstützung bestehender Teams bei der effektiven Wertschöpfung.

– Ruth Malan, Architektur-Consultant beiBredemeyer Consulting

Vorwort des Übersetzers

Als die englische Version von Team Topologies im Jahr 2019 erschien, wurde das Buch sehr schnell durch viele von mir geschätzte Fachleute, insbesondere aus der Domain-driven Design Community, erwähnt. Es dauerte auch nicht lange, bis Team Topologies Einzug in meinen Alltag als Berater im Umfeld soziotechnischer Architekturen hielt. Viele meiner Kunden wollten mit modernen technischen Architekturen und kollaborativer fachlicher Modellierung ein schnelleres Time-to-Market erreichen. Team Topologies füllte an dieser Stelle eine wichtige Lücke, indem es eine gut kommunizierbare und verständliche Idee sowie eine Terminologie für Teams und ihre Interaktionsformen lieferte.

Team Topologies zu übersetzen, war für mich eine spannende Herausforderung. Es war selbstverständlich mein Ziel, dass die Essenz und die Inhalte in dieser deutschen Ausgabe klar und verständlich vermittelt werden. Weil zentrale englische Begriffe der Team-Topologies-Terminologie wie die vier grundlegenden Teamtypen und drei Interaktionsmodi auch in der deutschsprachigen Community verwendet werden, habe ich sie in meiner Übersetzung beibehalten.

Diese Übersetzung wäre ohne die Unterstützung einiger Personen nicht möglich gewesen. Mein aufrichtiger Dank geht an zahlreiche Expertinnen und Experten aus meinem Umfeld, die mich seit vielen Jahren mit ihrem Fachwissen und ihrer Hingabe unterstützt und inspiriert haben. Im Kontext dieser Übersetzung ist es mir ein Anliegen insbesondere Jochen Christ, Anja Kammer, Simon Harrer, Gerrit Beine, Susanne Kaiser und Henning Schwentner namentlich zu erwähnen. Ein besonderer Dank gilt auch den Autoren Matthew Skelton und Manuel Pais, die mit ihrem Buch eine unverzichtbare Ressource für die Gestaltung moderner Delivery-Organisationen geschaffen haben und in zahlreichen persönlichen Gesprächen auf Konferenzen immer spannende Impulsgeber für mich sind. Mein Dank gilt auch Ariane Hesse von O’Reilly Deutschland für die stets angenehme und produktive Zusammenarbeit. Abschließend möchte ich auch meiner Frau und meinen beiden Stieftöchtern für ihre Geduld und ihre Unterstützung während der Übersetzungsarbeiten danken.

Widmen möchte ich diese Übersetzung dem viel zu früh verstorbenen Stefan Tilkov, der für mich weit mehr als ein Vorgesetzter war. Stefan war für mich immer ein wichtiger Mentor, ein fordernder Sparringspartner und vor allem ein Vorbild. Ruhe in Frieden Stefan.

Ich hoffe, dass Ihnen diese Übersetzung ebenso viel Einsichten und Inspiration bietet wie mir vor einigen Jahren das Original.

– Michael PlödFellow @ INNOQ

Einleitung

Bei [modernem] Organisationsdesign geht es um die Gestaltung für kollaborative Technologien, für die Stimme der Kundschaft.

–Naomi Stanford, Guide to Organization Design

Teams befinden sich ständig im Wandel, aber sie sind auch Ihre beste Chance, kontinuierlich und nachhaltig Wertschöpfung zu erzielen, indem Sie sie auf das Geschäft ausrichten. Idealerweise sollten Teams langlebig und autonom sein und über engagierte Teammitglieder verfügen. Teams leben jedoch nicht in Isolation. Sie müssen verstehen, wie und wann sie miteinander interagieren. Und diese Teaminteraktionen müssen sich im Laufe der Zeit weiterentwickeln, um die verschiedenen Phasen der Entwicklung und Umsetzung zu unterstützen, die Produkte und Technologien während ihrer Lebensdauer durchlaufen. Kurz gesagt: Unternehmen müssen nicht nur autonome Teams anstreben, sondern auch sich selbst ständig überdenken und weiterentwickeln, um den Kundinnen und Kunden schnell einen Mehrwert zu bieten.

Dieses Buch bietet ein praktisches, schrittweises, anpassungsfähiges Modell für die Gestaltung von Organisationen, das wir in Unternehmen mit unterschiedlichem Reifegrad eingesetzt haben und das sich bewährt hat: Team Topologies.

Team Topologies ist jedoch keine allgemeingültige Formel, um Softwaresysteme erfolgreich zu entwickeln und zu betreiben. Es gibt Teams und Organisationen, die mit einer ganz anderen Organisationsdynamik als der hier beschriebenen und empfohlenen erfolgreich sind (insbesondere in Organisationen mit einer ausgezeichneten Kultur und bereits vorhandenen Best Practices).

Team Topologies soll klare Muster liefern, die für viele verschiedene Teams und Organisationen einfach zu befolgen und zu interpretieren sind, und nicht herausragenden Spielern vorschreiben, wie sie zu spielen haben. Wir betrachten Team Topologies als eine Reihe von Musikstücken für ein Orchester oder eine Big Band, nicht als die Melodie für eine Top-Jazztrompeterin. Gedruckte Noten für ein großes Musikensemble tragen zum Erfolg der Gruppe bei, schreiben aber nicht jeden Aspekt der Darbietung vor. Viele Details bleiben dem Ensemble überlassen, um sie je nach Anlass, Veranstaltungsort oder Zusammensetzung der Spielerinnen und Spieler zu interpretieren. Ebenso ist es von großem Wert, sich auf ein kohärentes Vokabular und eine gemeinsame Arbeitsweise in den Teams zu einigen, um eine gute Bereitstellung von Software zu erreichen.

Der Ansatz von Team Topologies hilft Organisationen, die Schwierigkeiten haben, einen Weg zur Optimierung ihrer Teamstruktur zu finden, oder denen noch nicht bewusst ist, welche Auswirkungen die Gestaltung von Teams auf gute Geschäftsergebnisse und insbesondere Softwaresysteme haben kann. Team Topologies hilft Unternehmen, schneller und kontinuierlicher als bisher erfolgreich zu sein.

Dieses Buch richtet sich an alle, denen die Effizienz der Bereitstellung und des Betriebs von Softwaresystemen am Herzen liegt: Führungskräfte auf C-Level (einschließlich CTOs/CIOs, CEOs, CFOs usw.), Manager, Abteilungsleiterinnen, Softwarearchitekten und Systemarchitektinnen sowie alle anderen, die an der Entwicklung oder dem Betrieb von Softwaresystemen beteiligt sind und die Bereitstellung und den Betrieb dieser Systeme effektiver gestalten wollen oder müssen.

Wie wir dazu kamen, dieses Buch zu schreiben

Im Jahr 2013 entwickelte Matthew in einem Blogbeitrag mit dem Titel »What Team Structure Is Right for DevOps to Flourish?«1 die ursprünglichen DevOps-Topologien (und Anti-Patterns), während er bei einem Unternehmen in Großbritannien DevOps und Continuous Delivery einführte. Damals kämpfte das Unternehmen, das er beriet, mit der Einführung moderner Ansätze für die Bereitstellung von Software, und die frühen Topologiemuster, die Matthew entwickelte, boten dem Unternehmen eine Möglichkeit, verschiedene Optionen zu erkunden.

Manuel interviewte Matthew auf der Softwareentwicklungskonferenz QCon London im Jahr 2015, wo Matthew über das Conway’sche Gesetz und die frühen DevOps-Topology-Muster sprach. Der daraus resultierende Artikel »How Different Team Topologies Influence DevOps Culture« (Wie verschiedene Team-Topologien die DevOps-Kultur beeinflussen) wurde von InfoQ veröffentlicht und in mehrere Sprachen übersetzt2. Später im selben Jahr half Manuel dabei, die DevOps-Topology-Muster zu erweitern, und es gab hierzu Beiträge aus der Community.

Seitdem hat sich die Verwendung der DevOps-Topology-Muster sprunghaft erhöht. In Vorträgen, Artikeln und Gesprächen wurde immer wieder auf sie Bezug genommen. Sie haben Organisationen aller Größen und Branchen auf der ganzen Welt dabei geholfen, über die Beziehungen zwischen Teams nachzudenken und darüber, wie ihre Interaktionen sowohl die Organisationskultur als auch die Softwarearchitektur beeinflussen.

Im Laufe der Zeit wurde uns klar, dass die ursprünglichen DevOps-Topologien eine statische Sicht auf die Beziehungen zwischen den Teams darstellten, die zwar für die ersten Diskussionen nützlich, aber in ihrem Umfang recht begrenzt war. Durch unsere Erfahrung mit Schulungs- und Beratungsunternehmen aus der ganzen Welt haben wir festgestellt, dass einige Teams besser relativ isoliert oder autonom arbeiten, während andere Teams besser mit starker Kollaboration arbeiten. Wir haben uns gefragt, warum das so ist, und wir haben unsere Ideen auf der Grundlage des Feedbacks unserer Kunden weiterentwickelt.

Dies führte letztendlich zu den Team Topologies, wie sie in diesem Buch vorgestellt werden: ein dynamischer und sich weiterentwickelnder Ansatz zur Gestaltung von Organisationen, der auf realen Szenarien aus verschiedenen Regionen und Branchen basiert.

Wie man dieses Buch benutzt

Team Topologies soll ein praktisches Buch sein. Wir haben die Absicht, Inhalte zu vermitteln, die interaktiv sind und so viel Lernstoff liefern, wie wir auf diesen Seiten unterbringen können. Deshalb haben wir einige Design-Entscheidungen getroffen, die Ihnen die Navigation in diesem Buch erleichtern werden.

Zum einen ist das Team Topologies in drei Teile gegliedert:

Teil I des Buchs untersucht das Conway’sche Gesetz, die Art und Weise, wie organisatorische Zusammenhänge die Gestaltung der Systeme, die wir schaffen, einschränken, und wie wir diese Neigung zu unserem Vorteil nutzen können. Anschließend definieren wir, was wir unter Teams verstehen, und betrachten einige praktische Einschränkungen, die eine effektive Teamarbeit beeinflussen.

In Teil II untersuchen wir eine Reihe von statischen Team-Patterns, die sich in der Branche bewährt haben, und die Auswirkungen bei der Wahl eines Patterns gegenüber einem anderen unter Berücksichtigung des Conway’schen Gesetzes und des organisatorischen Kontexts. Dieser Teil soll Ihnen dabei helfen, über Team-Topologien nachzudenken, die im Großen und Ganzen für Ihren organisatorischen Kontext geeignet sind. Dieser Teil gibt Ihnen auch eine Hilfestellung bei der Entscheidung, wie die Teams auf die einzelnen Komponenten eines Systems ausgerichtet werden können, wobei das Conway’sche Gesetz und die grundlegenden Team-Topologien berücksichtigt werden.

In Teil III schließlich befassen wir uns mit der Frage, wie sich die Organisation weiterentwickeln lässt, um leistungsstarke Fähigkeiten für Innovation und schnelle Lieferung als Reaktion auf einen sich schnell ändernden operativen Kontext bereitzustellen. Wir erläutern, wie Sie den Team-Topologies-Ansatz nutzen können, um eine sensibilisierte Organisation zu schaffen, die auf die Anforderungen des Markts und der Nutzerinnen reagiert und die Auswirkungen auf die Einstellung von Mitarbeitern und deren Fähigkeiten berücksichtigt.

Jeder Teil beginnt mit einer Aufschlüsselung der wichtigsten Aussagen aus den einzelnen Kapiteln. Überall in den Kapiteln haben wir Abbildungen und Hinweise eingefügt, um Informationen hervorzuheben, die unserer Meinung nach hilfreich sind. Außerdem stellen wir Ihnen leicht nachvollziehbare Szenarien, Fallstudien und konkrete Empfehlungen für verschiedene Situationen zur Verfügung.

Und schließlich haben auch die Formen, Farben und Muster, die in vielen der Figuren zu finden sind, eine durchgängige Bedeutung im gesamten Buch. Hier ist die Legende:

Abbildung 1: Die vier Teamtypen und drei Interaktionsmodi

Für ein umfassendes Verständnis sollten Sie das Buch von der ersten bis zur letzten Seite lesen, denn der Stoff baut sich Kapitel für Kapitel auf. Wir haben das Material jedoch so geschrieben, dass jeder Abschnitt relativ unabhängig ist.

In diesem Sinne finden Sie hier einige Szenarien mit entsprechenden Möglichkeiten, das Buch zu lesen, die zu Ihrer aktuellen Situation passen könnten:

•

Ich brauche mehr Klarheit über die verschiedenen Teamtypen und welche Teamtypen effektiv sind.

–Lesen Sie

Kapitel 1

(Überblick), dann

Kapitel 4

(Statische Topologien), dann

Kapitel 5

(Grundlegende Topologien).

•

Ich muss ein großes, monolithisches Softwaresystem aufteilen.

–Lesen Sie

Kapitel 6

(Grenzen) und dann

Kapitel 3

(Das Team).

•

Ich muss die Architektur eines Softwaresystems verbessern.

–Lesen Sie

Kapitel 2

(Conways Gesetz), dann

Kapitel 4

(Statische Topologien) und dann

Kapitel 6

(Grenzen).

•

Ich muss die Effektivität von Softwareentwicklungsteams verbessern.

–Lesen Sie

Kapitel 3

(Das Team), dann

Kapitel 6

(Grenzen), dann

Kapitel 5

(Grundlegende Topologien).

•

Ich muss die Moral und Effektivität innerhalb der Teams verbessern.

–Lesen Sie

Kapitel 3

(Das Team) und dann

Kapitel 5

(Grundlegende Topologien).

•

Ich muss verstehen, wo ich Aufwand betreiben muss, um das erwartete Wachstum zu erreichen.

–Lesen Sie

Kapitel 1

(Überblick), dann

Kapitel 5

(Grundlagen), dann

Kapitel 8

(Topologie-Evolution).

•

Ich muss verstehen, wie ich Team-Topologien weiterentwickeln kann, um sich ändernden Business-Anforderungen gerecht zu werden.

–Lesen Sie

Kapitel 7

(Dynamische Aspekte) und dann

Kapitel 8

(Topologie-Evolution und organisatorisches Erkennen).

Wichtige Einflüsse, die dieses Buch geprägt haben

Neben unseren eigenen Erfahrungen ist dieses Buch stark von mehreren verwandten Ansätzen und Denkweisen beeinflusst. Erstens gehen wir davon aus, dass eine Organisation ein sozio-technisches System oder Ökosystem ist, das durch die Interaktion von Individuen und Teams innerhalb der Organisation geformt wird; mit anderen Worten, dass eine Organisation die Interaktion zwischen Menschen und Technologie ist. In dieser Hinsicht deckt sich das Buch mit Ideen aus folgenden Bereichen: Kybernetik (insbesondere die Verwendung der Organisation als »Sensing-Mechanismus«, die bis ins Jahr 1948 zurückreicht, als Norbert Wiener sein Buch Cybernetics: Or Control and Communication in the Animal and the Machine veröffentlichte), Systems Thinking (insbesondere die Arbeit von W. Edwards Deming) und Ansätze wie das Cynefin-Framework zur Bewertung der Komplexität von Domänen (beschrieben von Dave Snowden und Mary Boone in ihrem 2007 in der Harvard Business Review erschienenen Artikel mit dem Titel »A Leader’s Framework for Decision Making«) sowie die Theorie der adaptiven Strukturierung (ein Begriff, der von Gerardine DeSanctis und Marshall Scott Poole in ihrem Organization Science-Artikel »Capturing the Complexity in Advanced Technology Use« geprägt wurde: »Adaptive Structuration Theory«, in dem sie betonten, dass die Auswirkungen von Technologie keine Selbstverständlichkeit sind, sondern davon abhängen, wie Gruppen und Organisationen sie wahrnehmen).

Zweitens gehen wir davon aus, dass »das Team« etwas ist, das sich anders verhält als eine bloße Ansammlung von Individuen, und dass das Team in seiner Entwicklung und Funktionsweise gefördert und unterstützt werden sollte. In dieser Hinsicht stützen wir uns auf die Ideen von Bruce Tuckman (der in seinem Papier Developmental Sequence in Small Groups aus dem Jahr 1965 das Vier-Stufen-Modell – Forming, Storming, Norming, Performing – für die Entwicklung von Teams vorschlug), Russ Forrester und Allan Drexler (die in ihrem Paper A Model for Team-Based Organization Performance aus dem Jahr 1999 die Leistung teambasierter Organisationen untersuchten), Pamela Knight (die in ihrem Paper Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model aus dem Jahr 2007 Beweise dafür fand, dass Storming während der gesamten Lebensdauer eines Teams stattfindet), Patrick Lencioni (der sich in seinem bahnbrechenden Buch The Five Dysfunctions of a Team: A Leadership Fable mit Fragen der Teaminteraktion beschäftigt) und ähnliche Theorien und Forschungen, die sich mit Teams befassen.

Drittens gehen wir davon aus, dass das Conway’sche Gesetz (oder eine Variante davon) ein starker Treiber für die Gestaltung von Softwareprodukten ist und dass Unternehmen davon profitieren würden, wenn sie sich explizit mit den Implikationen dieses Gesetzes auseinandersetzen würden. In dieser Hinsicht stützen wir uns auf Schriften und Ideen von Mel Conway, Ideen der Softwarearchitekturberaterin und Preisträgerin des Teamorganisations-Designs Ruth Malan, von James Lewis, dem technischen Direktor von ThoughtWorks und einem der Befürworter des »umgekehrten Conway-Manövers« sowie von ähnlichen Autoren und Praktikern.

Schließlich stützen wir uns auf zahlreiche Quellen, die praktische Erfolge bei der Entwicklung und dem Betrieb von Softwaresystemen in großem Maßstab dokumentieren, darunter Organisationen wie Adidas, Auto Trader, Ericsson, Netflix, Spotify, TransUnion und andere. Die Größe und Schnelligkeit dieser Unternehmen hat es ihnen ermöglicht, innerhalb von einigen Monaten bis hin zu einigen Jahren handfeste Vorteile aus Veränderungen in der Organisationsstruktur und der Interaktion zwischen den Teams zu erzielen.

Wir hoffen, dass Sie auf Ihrer Reise durch dieses Buch dazu inspiriert werden, Ihre Vorstellungen von Teams, ihren Strukturen und ihrer Funktionsweise zu hinterfragen.

TEIL I

Teams als entscheidendes Mittel bei der Lieferung

Die wichtigsten Erkenntnisse

Kapitel 1

•Das Conway’sche Gesetz legt nahe, dass die gemeinsame Entwicklung von Softwarearchitekturen und Teaminteraktionen von großem Nutzen ist, da es sich um ähnliche Antriebskräfte handelt.•Team Topologies klärt den Zweck und die Verantwortlichkeiten von Teams und steigert so die Effektivität ihrer Beziehungen untereinander.•Team Topologies verfolgt einen humanistischen Ansatz bei der Entwicklung von Softwaresystemen und stellt gleichzeitig Organisationen für strategische Anpassungsfähigkeit auf.

Kapitel 2

•Unternehmen sind dazu gezwungen, Designs zu erstellen, die ihre Kommunikationswege widerspiegeln.•Das Design der Organisation schränkt den »Suchraum nach Lösungen« ein und begrenzt die Möglichkeiten im Design von Software.•Die Forderung, dass jede mit jedem kommunizieren muss, ist ein Rezept für Chaos.•Wählen Sie Softwarearchitekturen, die einen teamorientierten Arbeitsfluss fördern.•Die Beschränkung der Kommunikationswege auf genau definierte Teaminteraktionen führt zu modularen, entkoppelten Systemen.

Kapitel 3

•Das Team ist das effektivste Mittel zur Bereitstellung von Software, nicht einzelne Personen.•Begrenzen Sie die Größe von Multi-Team-Gruppierungen innerhalb der Organisation auf der Grundlage von Dunbars Zahl.•Schränken Sie die Zuständigkeiten der Teams so ein, dass sie der maximalen kognitiven Belastung des Teams entsprechen.•Legen Sie klare Verantwortungsgrenzen für Teams fest.•Ändern Sie das Arbeitsumfeld für Teams, um ihnen zum Erfolg zu verhelfen.

1

Das Problem mit Organisationsdiagrammen

Organisationen sollten als komplexe und anpassungsfähige Organismen und nicht als mechanistische und lineare Systeme betrachtet werden.

–Naomi Stanford, Guide to Organisation Design

Mitarbeiterinnen und Mitarbeiter im Technologiebereich sind ständig in Aktion: Sie erstellen und aktualisieren Systeme in einem unglaublichen Tempo und kombinieren verschiedene Arten von Technologien, um ein überzeugendes Benutzererlebnis zu schaffen. Mobile Anwendungen, Cloud-basierte Dienste, Webanwendungen und eingebettete, tragbare oder industrielle IoT-Geräte müssen alle effektiv zusammenarbeiten, um die gewünschten Geschäftsergebnisse zu erzielen.

Heutzutage beeinflussen diese Systeme fast jeden Aspekt unseres täglichen Lebens in einer Weise, die immer tiefgreifender ist. Wenn Software schlecht konzipiert ist – oder noch wichtiger, wenn die Interaktion zwischen der Software, dem Anbieter und den Kunden nicht übereinstimmt –, hat das negative Auswirkungen auf die Menschen. Sie können weit weg von zu Hause gestrandet sein, wenn eine Anwendung für Taxidienste ausfällt. Sie können möglicherweise ihre Miete nicht mehr bezahlen, wenn die Software oder die Prozesse für das Internetbanking ausfallen. Sie können sogar ihr Leben in Gefahr sehen, wenn ein medizinisches Gerät ausfällt. Noch nie war explizites sozio-technisches Design so wichtig wie heute.

Entwicklung und Betrieb dieser hochkomplexen, miteinander vernetzten Softwaresysteme sind Teamaktivitäten, die die gemeinsamen Anstrengungen von Menschen mit unterschiedlichen Fähigkeiten über verschiedene Plattformen hinweg erfordern. Darüber hinaus müssen moderne IT-Organisationen Softwaresysteme schnell und sicher bereitstellen und betreiben, während sie gleichzeitig wachsen und sich an Veränderungen und Zwänge im geschäftlichen oder gesetzlichen Umfeld anpassen müssen. Unternehmen können nicht mehr zwischen einer Optimierung der Stabilität und einer Optimierung der Geschwindigkeit wählen.

Doch trotz dieser Risiken und Anforderungen organisieren viele Unternehmen ihre Mitarbeiter und Teams immer noch auf eine Weise, die für die moderne Softwareentwicklung und den Betrieb kontraproduktiv ist. Unternehmen, die sich zu sehr auf Organigramme und Matrixstrukturen verlassen, um die Arbeit aufzuteilen und zu kontrollieren, schaffen oft nicht die notwendigen Voraussetzungen, um Innovationen zu fördern und gleichzeitig ein hohes Arbeitstempo zu erreichen. Um dies zu realisieren, brauchen Unternehmen stabile Teams, effektive Teamstrukturen und -interaktionen. Sie müssen in fähige, kompetente Teams investieren, die die Grundlage für Agilität und Anpassungsfähigkeit bilden. Um in einem immer härter umkämpften Markt bestehen zu können, brauchen Unternehmen Teams und Mitarbeiterinnen und Mitarbeiter, die in der Lage sind, zu erkennen, wann sich das Umfeld ändert, um sich entsprechend weiterzuentwickeln.

Die gute Nachricht ist, dass es möglich ist, gleichzeitig schnell und sicher zu sein – mit der richtigen Einstellung und mit Tools, die sowohl Anpassungsfähigkeit als auch Wiederholbarkeit fördern und die Teams und Menschen in den Mittelpunkt stellen. Wie Mark Schwartz und seine Mitautoren in ihrem 2016 erschienenen Buch Thinking Environments schreiben, »muss die Organisationsstruktur die Verantwortlichkeiten so koordinieren, dass das Ziel, qualitativ hochwertige und wirkungsvolle Software zu liefern, unterstützt wird.«1

Als Mitglieder der Technologieteams, die diese Schnittstellen betreuen, müssen wir unser Denken ändern. Wir müssen Teams nicht mehr als Ansammlung austauschbarer Individuen betrachten, die erfolgreich sind, solange sie den »richtigen« Prozess befolgen und die »richtigen« Werkzeuge verwenden, sondern wir müssen Menschen und Technologie als ein einziges sozio-technisches Mensch-Computer/ Kohlenstoff-Silizium-Ökosystem betrachten. Gleichzeitig müssen wir sicherstellen, dass die Teams intrinsisch motiviert sind und eine echte Chance haben, in einem solchen Gefüge ihre beste Arbeit zu leisten.

In diesem Kapitel wird Team Topologies als ein anpassungsfähiges Modell für die Gestaltung von Technologieorganisationen vorgestellt, mit dem Unternehmen Geschwindigkeit und Stabilität gleichermaßen erreichen können. Doch zunächst wollen wir uns ansehen, wie sich die realen Kommunikationsstrukturen in den meisten Organisationen oft von dem unterscheiden, was uns das Organigramm verrät, und welche Auswirkungen das hat.

Kommunikationsstrukturen einer Organisation

Die meisten Unternehmen möchten oder müssen eine genormte Sicht auf ihre Teams und Mitarbeiter haben, das sogenannte »Organigramm«. In diesem Diagramm werden die Teams, Abteilungen, Referate und andere Organisationseinheiten sowie ihre Beziehungen zueinander dargestellt. Es zeigt in der Regel hierarchische Berichtslinien, die Kommunikationswege »von oben nach unten« in der Organisation implizieren.

Das Organigramm hat im Zusammenhang mit der Entwicklung von Softwaresystemen durchaus seine Berechtigung, insbesondere im Hinblick auf die Einhaltung von Vorschriften und gesetzlichen Bestimmungen. In einem hochgradig kollaborativen Kontext mit Ungewissheit über die Resultate führt es jedoch zu unrealistischen Erwartungshaltungen, wenn man sich auf das Organigramm als zentralen Mechanismus für das Aufteilen der zu erledigenden Arbeit verlässt. Wir müssen uns stattdessen auf entkoppelte, langlebige Teams verlassen, die effektiv zusammenarbeiten können, um die Herausforderung zu meistern, ein Gleichgewicht zwischen Geschwindigkeit und Verlässlichkeit herzustellen.

Das Problem, wenn wir das Organigramm für bare Münze nehmen, besteht darin, dass wir versuchen, Menschen so zu strukturieren, als wären sie eine Software, die ihre Kommunikation ordentlich innerhalb der vorgegebenen Leitlinien hält. Aber die Menschen beschränken ihre Kommunikation nicht nur auf die Linien im Organigramm. Wir wenden uns an diejenigen, auf die wir angewiesen sind, um unsere Arbeit zu erledigen. Wir weichen die Regeln auf, wenn es nötig ist, um unsere Ziele zu erreichen. Deshalb sehen die tatsächlichen Kommunikationslinien ganz anders aus als im Organigramm, wie in Abbildung 1-1 dargestellt.

Das Denken in Organigrammen ist das Problem

Wie in Abbildung 1-1 dargestellt, helfen uns herkömmliche Organigramme nicht beim Verständnis der tatsächlichen Kommunikationsmuster in unserer Organisation. Stattdessen müssen Unternehmen ein realistischeres Bild von der erwarteten und der tatsächlich stattfindenden Kommunikation zwischen Einzelpersonen und Teams entwickeln. Diese Diskrepanzen geben Aufschluss darüber, welche Arten von Systemen für das Unternehmen besser geeignet sind.

Darüber hinaus neigen Entscheidungen, die auf der Struktur von Organigrammen basieren, dazu, nur für einen Teil des Unternehmens zu optimieren und die vor- und nachgelagerten Auswirkungen zu ignorieren. Lokale Optimierungen helfen den direkt involvierten Teams, aber sie tragen nicht unbedingt dazu bei, die Wertschöpfung für die Kunden insgesamt zu verbessern. Ihre Auswirkungen sind möglicherweise vernachlässigbar, wenn es größere Engpässe im Arbeitsablauf gibt. Wenn beispielsweise Teams Cloud as Code und Infrastructure as Code einsetzen, kann sich die Zeit für die Bereitstellung einer neuen Infrastruktur von Wochen oder Monaten auf Minuten oder Stunden verkürzen. Wenn jedoch jede Änderung von einem Gremium, das sich einmal pro Woche trifft, genehmigt werden muss, dann wird die Geschwindigkeit der Bereitstellung bestenfalls wöchentlich sein.

Systems Thinking konzentriert sich darauf, ganzheitlich zu optimieren, den gesamten Arbeitsfluss zu betrachten, festzustellen, was heute der größte Engpass ist, und ihn zu beseitigen. Dann wiederholen Sie das. Team Topologies konzentriert sich darauf, wie man dynamische Teamstrukturen und Interaktionsmodi einrichtet, die den Teams helfen, sich schnell an neue Bedingungen anzupassen und eine schnelle und sichere Softwareauslieferung zu erreichen. Vielleicht ist das heute noch nicht Ihr größter Engpass, aber irgendwann werden Sie mit dem Problem starrer Teamstrukturen mit schlechter Kommunikation und/oder unzureichenden Prozessen konfrontiert sein, die die Auslieferung verlangsamen.

Abbildung 1-1: Organigramm mit tatsächlichen Kommunikationslinien

In der Praxis kommunizieren Menschen seitwärts oder »horizontal« mit Menschen aus anderen Berichtslinien, um ihre Arbeit zu erledigen. Diese Kreativität und Problemlösungsfähigkeit müssen zum Wohle des Unternehmens gefördert werden und dürfen nicht darauf beschränkt sein, die Kommunikation und das Berichtswesen von oben nach unten und von unten nach oben zu optimieren.

Die Vorstellung, dass das Organigramm ein getreues Abbild dessen ist, wie die Arbeit erledigt wird und wie die Teams miteinander interagieren, führt zu ineffektiven Entscheidungen bezüglich der Verteilung von Arbeit und Verantwortlichkeiten. So wie ein Softwarearchitekturdokument veraltet ist, sobald die eigentliche Entwicklung der Software beginnt, so ist auch ein Organigramm oft nicht immer mit der Realität im Einklang.

Wir sind selbstverständlich nicht die ersten, die das Ungleichgewicht zwischen den formalen Organisationsstrukturen und der Art und Weise, wie die Arbeit tatsächlich erledigt wird, feststellen. Das Buch Improving Performance: How to Manage the White Space on the Organization Chart von Geary Rummler und Alan Brache legte den Grundstein für die kontinuierliche Verbesserung und das Management von Geschäftsprozessen. Der jüngste Fokus (zumindest in der IT) auf Produkt- und Teamzentrierung, wie er in Mik Kerstens Buch Moving from Project to Product zum Ausdruck kommt, ist ein weiterer wichtiger Meilenstein. Wir sind der Meinung, dass Team Topologies ein weiteres Teil dieses Puzzles ist – insbesondere durch klare und flexible Teamstrukturen, Verantwortlichkeiten und Interaktionsmodi.

Jenseits des Organigramms

Wenn also Organigramme keine genaue Darstellung von Organisationsstrukturen sind, was dann? Niels Pflaeging, Autor von Organize for Complexity, identifiziert nicht eine, sondern drei verschiedene Organisationsstrukturen in jeder Organisation:2

Formale Struktur (das Organigramm) – erleichtert die Befolgung von Vorschriften (Compliance)

Informelle Struktur – das »Einflussgebiet« zwischen Individuen

Wertschöpfungsstruktur – wie die Arbeit tatsächlich erledigt wird, basierend auf der zwischenmenschlichen und teamübergreifenden Wertschätzung

Pflaeging schlägt vor, dass der Schlüssel zu erfolgreichen wissensbasierten Arbeitsorganisationen in den Wechselwirkungen zwischen der informellen Struktur und der Wertschöpfungsstruktur (d. h. den Interaktionen zwischen Menschen und Teams) liegt.3 Andere Autoren haben ähnliche Charakterisierungen vorgeschlagen, wie z. B. Frédéric Laloux in Reinventing Organizations oder der Holocracy-Ansatz von Brian Robertson.4

Der Ansatz von Team Topologies erkennt die Bedeutung von informellen und wertschöpfenden Strukturen an, wie sie von Pflaeging definiert wurden. Durch die Stärkung von Teams und deren Behandlung als grundlegende Bausteine rücken die Individuen in diesen Teams enger zusammen und agieren als echtes Team und nicht nur als Gruppe von Menschen. Durch die ausdrückliche Einigung auf bestimmte Interaktionsmodi mit anderen Teams werden die Erwartungen an das Handeln klarer, und das Vertrauen zwischen den Teams wächst.

In den letzten Jahrzehnten hat es viele neue Ansätze für die Organisation von Unternehmen gegeben, aber in der Regel bleibt das neue Design eine statische Sicht auf die Organisation, die die realen Verhaltensweisen und Strukturen, die nach einer Umstrukturierung entstehen, nicht berücksichtigt. Der Ansatz des »Matrix-Managements« beispielsweise, der in den 1990er-Jahren entstand und in den folgenden Jahrzehnten sehr populär wurde, versuchte, der inhärenten Komplexität hochgradig unklarer, hochqualifizierter Arbeit dadurch zu begegnen, dass die einzelnen Mitarbeiter sowohl den Geschäfts- als auch den Bereichsleiterinnen unterstellt waren. Trotz des klareren Fokus auf den Geschäftswert im Vergleich zu einer rein funktionalen Organisation von Teams ist dies immer noch eine statische Sicht der Welt, die veraltet ist, wenn sich die Geschäfts- und Technologied-Domänen schnell weiterentwickeln.

Für Arbeitnehmer können Umstrukturierungen, wie die Einführung von Matrix-Management, jede Menge Angst und Sorgen mit sich bringen. Oft werden sie als Zeit- und Arbeitsaufwand betrachtet, die das Unternehmen eher zurückwerfen, als es voranzubringen. Sobald die nächste technologische oder methodische Revolution ansteht, wird das Unternehmen eine weitere Umstrukturierung vornehmen, die etablierte Formen der Kommunikation aufbricht und welche die Teams aufspaltet, die gerade erst begonnen haben, ihren Groove zu finden.

Der Ansatz von Team Topologies fügt die dynamischen und sensorischen Aspekte hinzu, die für Technologie-Organisationen erforderlich sind und die im traditionellen Organisationsdesign fehlen.

Es wird immer deutlicher, dass das Verlassen auf eine einzige, statische Organisationsstruktur, wie dem Organigramm oder dem Matrix-Management, für effektive Ergebnisse in modernen Softwaresystemen ungeeignet ist. Statt einer einzigen Struktur ist ein Modell erforderlich, das sich an die aktuelle Situation anpassen lässt – eines, das berücksichtigt, wie Teams wachsen und miteinander interagieren.

Team Topologies bietet den (r)evolutionären Ansatz, der erforderlich ist, um Teams, Prozesse und Technologien für alle Arten von Organisationen aufeinander auszurichten.

In ihrem ausgezeichneten Buch von 2015, Guide to Organisation Design: Creating High-performing and Adaptable Enterprises, nennt Naomi Stanford fünf Faustregeln für die Gestaltung von Organisationen:5

Gestalten Sie, wenn es einen zwingenden Grund gibt.

Entwickeln Sie Optionen, um sich für ein Design zu entscheiden.

Wählen Sie den richtigen Zeitpunkt für den Entwurf.

Suchen Sie nach Hinweisen darauf, dass die Dinge aus der Balance geraten sind.

Bleiben Sie wachsam für die Zukunft.

Im weiteren Verlauf dieses Buchs werden wir untersuchen, wie Sie diese fünf Heuristiken für die Gestaltung von Organisationen nutzen können.

Team Topologies: Eine neue Art, über Teams zu denken

Der Team-Topologies-Ansatz bringt neue Denkansätze für effektive Teamstrukturen für die Bereitstellung von Unternehmenssoftware. Er bietet einen konsistenten, umsetzbaren Leitfaden für die Weiterentwicklung des Teamdesigns, um kontinuierlich mit den Veränderungen in den Bereichen Technologie, Menschen und Business Schritt halten zu können. Er umfasst Größe, Form, Platzierung, Verantwortlichkeiten, Grenzen und Interaktion von Teams, die moderne Softwaresysteme entwickeln und betreiben.

Team Topologies bietet vier grundlegende Teamtypen – Stream-aligned, Platform, Enabling und Complicated-subsystem – sowie drei zentrale Teaminteraktionsmodi – Collaboration, X as a Service und Facilitating. Zusammen mit der Berücksichtigung des Conway’schen Gesetzes, der kognitiven Belastung von Teams und der Frage, wie man zu einer wahrnehmungsfähigen Organisation wird, führt Team Topologies zu einem effektiven und humanistischen Ansatz für den Aufbau und Betrieb von Softwaresystemen.

Insbesondere wird untersucht, wie sich verschiedene Team-Topologien mit der technologischen und organisatorischen Reife entwickeln können. Phasen der technischen und produktbezogenen Exploration erfordern in der Regel ein hochgradig kooperatives Umfeld (mit sich überschneidenden Teamgrenzen), um erfolgreich zu sein. Die Beibehaltung der gleichen Strukturen (etablierte Technologien und Produkte) nach Abschluss der Explorationsphase kann jedoch zu vergeblichen Anstrengungen und Missverständnissen führen.

Durch die Betonung eines anpassungsfähigen Modells für die Organisationsgestaltung und die aktive Berücksichtigung der Beziehungen zwischen den Teams bietet der Team-Topologies-Ansatz einen wichtigen technologieunabhängigen Mechanismus für moderne softwareintensive Unternehmen, um zu erkennen, wann eine Änderung der Strategie erforderlich ist (entweder aus geschäftlicher oder aus technologischer Sicht). Das Ziel ist, Teams dabei zu unterstützen, Software zu produzieren, die den Kundenbedürfnissen entspricht und die einfacher zu erstellen, zu betreiben und zu verantworten ist.

Team Topologies legt auch Wert auf einen humanistischen Ansatz bei der Entwicklung und Erstellung von Softwaresystemen. Es betrachtet das Team als untrennbares Element der Softwareentwicklung und erkennt an, dass Teams eine begrenzte kognitive Kapazität haben, die es zu respektieren gilt. Zusammen mit dem dynamischen Teamdesign, das sich auf das Conway’sche Gesetz stützt, wird Team Topologies zu einem strategischen Werkzeug für die Lösungsfindung.

Das Revival von Conway’s Law

Wir haben bereits erwähnt, wie wichtig das Conway’sche Gesetz für die Gestaltung und Entwicklung von Teams ist. Aber worum geht es bei diesem Gesetz genau?

Im Jahr 1968 veröffentlichte der Computer-Systemforscher Mel Conway in der Zeitschrift Datamation einen Artikel mit dem Titel How Do Committees Invent?, in dem er die Beziehung zwischen der Organisationsstruktur und dem daraus resultierenden Design von Systemen untersuchte. Der Artikel ist voll von glänzenden Einsichten, von denen wir einige später in diesem Kapitel behandeln, aber dies ist der Satz, der als Conways Gesetz bekannt wurde: »Organisationen, die Systeme entwerfen […] werden zwangsläufig Designs produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind«6.

Conway stützte seine Beobachtung auf Organisationen, die frühe elektronische Computersysteme entwickelten. In seinen Worten weist dieses »Gesetz« auf die starke Korrelation zwischen den realen Kommunikationswegen einer Organisation (den von Pflaeging erwähnten Wertschöpfungsstrukturen) und der daraus resultierenden Softwarearchitektur hin7 oder auf das, was der Autor Allan Kelly als »homomorphe Kraft« bezeichnet8. Diese homomorphe Kraft führt dazu, dass die Softwarearchitektur und die Teamstrukturen tendenziell die gleiche Form haben. Mit anderen Worten: Die Entwicklung von Software erfordert ein Verständnis der teamübergreifenden Kommunikation, um realistisch beurteilen zu können, welche Art von Softwarearchitekturen praktikabel sind. Wenn die gewünschte theoretische Systemarchitektur nicht mit dem Organisationsmodell übereinstimmt, muss eines der beiden Modelle geändert werden.

Eric Raymond hat dies in seinem Buch The New Hacker’s Dictionary auf humorvolle Art und Weise erklärt: »Wenn Sie vier Gruppen an einem Compiler arbeiten lassen, erhalten Sie einen 4-Pass-Compiler«9.

Seit 1968 wird immer deutlicher, dass das Conway’sche Gesetz weiterhin für jede Software gilt, die entwickelt wird. Diejenigen von uns, die Softwaresysteme entwickelt haben, die einer »Architekturvorlage« entsprechen mussten, können sich sicher an Zeiten erinnern, in denen es sich anfühlte, als ob wir gegen die Architektur ankämpften, anstatt dass sie uns half, unsere Arbeit in die richtige Richtung zu lenken. Nun, das ist Conways Gesetz in der Praxis.

Die Teamstrukturen müssen mit der gewünschten Softwarearchitektur übereinstimmen, sonst besteht die Gefahr, dass unausgegorene Designs entstehen.

Eine Art »Wiederbelebung« des Conway’schen Gesetzes fand um 2015 statt, als Microservices-Architekturen auf dem Vormarsch waren. Insbesondere James Lewis, Technischer Direktor bei Thoughtworks, und andere kamen auf die Idee, ein »umgekehrtes Conway-Manöver« (Inverse oder Reverse Conway Maneuver) anzuwenden, bei dem sich eine Organisation darauf konzentriert, die Teamstrukturen so zu organisieren, dass sie zu der Architektur passen, die das System aufweisen soll, anstatt von den Teams zu erwarten, dass sie einem vorgeschriebenen Architekturdesign folgen.10

Die wichtigste Erkenntnis dabei ist, dass es grundlegend falsch ist, Softwarearchitektur als ein eigenständiges Konzept zu betrachten, das isoliert entworfen und dann von einer beliebigen Gruppe von Teams umgesetzt werden kann. Diese Kluft zwischen Architektur- und Teamstrukturen ist bei allen Arten von Architekturen zu beobachten: von Client-Server über SOA bis hin zu Microservices. Aus diesem Grund müssen Monolithen aufgebrochen werden (insbesondere jeder nicht aufteilbare Teil der Software, der die kognitiven Fähigkeiten eines einzelnen Teams übersteigt), wobei der Teamfokus beibehalten werden muss – ein Thema, das wir in Kapitel 6 eingehend erörtern werden.

Kognitive Belastung und Engpässe

Wenn wir von kognitiver Belastung sprechen, ist es naheliegend, dass eine Person nur eine begrenzte Menge an Informationen zu einem bestimmten Zeitpunkt in ihrem Gehirn speichern kann. Das Gleiche gilt für ein Team, wenn man die kognitiven Kapazitäten aller Teammitglieder zusammenzählt.

Wir diskutieren jedoch kaum über die kognitive Belastung, wenn wir einem bestimmten Team Verantwortlichkeiten oder Teile einer Software zuweisen. Vielleicht, weil es schwierig ist, sowohl die verfügbaren Kapazitäten als auch die kognitive Belastung zu quantifizieren. Oder vielleicht, weil erwartet wird, dass sich das Team an das anpasst, was man ihm aufträgt, ohne Fragen zu stellen.

Wenn die kognitive Belastung nicht berücksichtigt wird, sind die Teams überfordert und versuchen, eine übermäßige Anzahl von Aufgaben und Domänen zu übernehmen. Einem solchen Team fehlt die nötige Bandbreite, um sein Fachgebiet zu beherrschen, und es hat mit den durch einen Kontextwechsel entstehenden Kosten zu kämpfen.

Miguel Antunes, leitender Softwareingenieur für Forschung und Entwicklung bei OutSystems, einem Anbieter von Low-Code-Plattformen, erzählte ein Beispiel für genau diese Herausforderung. Das Engineering Productivity Team bei OutSystems war fünf Jahre alt. Die Aufgabe des Teams bestand darin, Produktteams dabei zu unterstützen, ihre Builds effizient durchzuführen, die Infrastruktur zu pflegen und die Testausführung zu verbessern. Das Team wuchs ständig und übernahm zusätzliche Aufgaben in den Bereichen Continuous Integration (CI), Continuous Delivery (CD) und Infrastrukturautomatisierung.

Als Opfer ihres eigenen Erfolgs war die Sprint-Planung für das inzwischen achtköpfige Team ein Sammelsurium von Anfragen, die sich auf die verschiedenen Aufgabenbereiche verteilten. Es war schwer, Prioritäten zu setzen, und der häufige Wechsel des Kontexts selbst innerhalb eines einzigen Sprints führte zu einem Motivationsverlust. Das ist nicht überraschend, wenn wir die drei Elemente der intrinsischen Motivation von Dan Pink betrachten: Autonomie (die durch das ständige Jonglieren mit Anfragen und Prioritäten von mehreren Teams zunichte gemacht wird), Beherrschung (»Tausendsassa, der nichts beherrscht«) und Zweck (zu viele Zuständigkeitsbereiche).11

Abbildung 1-2: Hindernisse für einen schnellen Arbeitsfluss

Während das Team in diesem Branchenbeispiel interne Dienstleistungen für Entwicklungsteams erbrachte, ist der Effekt bei Teams, die an Software für externe Kunden arbeiten, der gleiche. Die Anzahl der Services und Komponenten, für die ein Produktteam verantwortlich ist (mit anderen Worten: die Anforderungen an das Team), wächst in der Regel mit der Zeit. Die Entwicklung neuer Dienste wird jedoch oft so geplant, als ob das Team von Anfang an Vollzeit zur Verfügung stünde und die kognitive Belastung gleich null wäre. Diese Vernachlässigung ist problematisch, denn das Team muss weiterhin bestehende Services reparieren und verbessern. Letztendlich wird das Team zu einem Lieferengpass, da seine kognitive Kapazität bei Weitem überschritten wurde. Dies führt zu Verzögerungen, Qualitätsproblemen und oft auch zu einem Rückgang der Motivation der Teammitglieder.

Wir müssen das Team an die erste Stelle setzen und dafür eintreten, seine kognitive Belastung zu begrenzen. Das explizite Berücksichtigen der kognitiven Belastung kann ein wirksames Instrument sein, um die Teamgröße festzulegen, Verantwortlichkeiten zuzuweisen und Grenzen zu anderen Teams zu ziehen. (Wir werden dies in Kapitel 3 ausführlich behandeln.)

Insgesamt plädiert der Team-Topologies-Ansatz für eine Organisationsgestaltung, die den Fluss des Wandels und Rückmeldungen aus laufenden Systemen optimiert. Dies erfordert eine Begrenzung der kognitiven Belastung von Teams und eine explizite Gestaltung der Kommunikation zwischen ihnen, um die Softwaresystemarchitektur zu schaffen, die wir benötigen (basierend auf dem Conway’schen Gesetz).

Zusammenfassung: Überdenken Sie Teamstrukturen, Zweck und Interaktionen

Die Entwicklung und der effektive Betrieb von Software für moderne, vernetzte Systeme und Dienste erfordert, dass Unternehmen viele verschiedene Dimensionen berücksichtigen. In der Vergangenheit haben die meisten Unternehmen die Softwareentwicklung als eine Art Fertigungsprozess betrachtet, der von einzelnen Personen in funktionalen Spezialgebieten durchgeführt wird, wobei große Projekte im Voraus geplant werden und die sozio-technische Dynamik kaum berücksichtigt wird. Dies hat zu den in Abbildung 1-2 dargestellten Problemen geführt.

Die Agile-, Lean-IT- und DevOps-Bewegungen haben den enormen Wert kleinerer, autonomerer Teams aufgezeigt, die sich an den Geschäftsabläufen orientieren, in kleinen, iterativen Zyklen entwickeln und ausliefern und den Kurs auf der Grundlage des Feedbacks der Benutzer korrigieren. Lean IT und DevOps förderten auch große Fortschritte bei Telemetrie- und Metrik-Tools für Systeme und Teams, die den Entwicklerinnen und Betreibern von Software helfen, proaktive, frühzeitige Entscheidungen auf der Grundlage von Trends aus der Vergangenheit zu treffen, anstatt nur auf Vorfälle und Probleme zu reagieren, sobald sie auftreten.

Traditionelle Unternehmen waren jedoch aufgrund ihrer Organisationsmodelle oft nur begrenzt in der Lage, die Vorteile von Agile, Lean IT und DevOps voll auszuschöpfen. Es überrascht daher nicht, dass der Schwerpunkt auf der unmittelbaren Automatisierung und der Einführung von Tools liegt, während kulturelle und organisatorische Veränderungen eher beiläufig angegangen werden. Letztere Veränderungen sind viel schwieriger zu visualisieren, geschweige denn, ihre Wirksamkeit zu messen. Doch die richtige Teamstruktur, der richtige Ansatz und die richtige Interaktion sowie das Verständnis dafür, dass sie sich im Laufe der Zeit weiterentwickeln müssen, sind entscheidende Faktoren für den Erfolg auf lange Sicht.

Vor allem traditionelle Organigramme passen nicht zu dieser neuen Realität der häufigen (Um-)Gestaltung von Teams für die kollaborative Wissensarbeit in einem Umfeld voller Unsicherheit und Neuheit. Stattdessen müssen wir uns das Conway’sche Gesetz (organisatorisches Design hat Vorrang vor dem Design der Softwarearchitektur), Einschränkungen der kognitiven Belastung und einen teamorientierten Ansatz zunutze machen, um Teams mit klaren Zielen zu bilden und Teaminteraktionen zu fördern, die den Fluss der Softwarelieferung und die strategische Anpassungsfähigkeit in den Vordergrund stellen.

Das Ziel von Team Topologies ist es, Ihnen einen Ansatz und mentale Hilfsmittel an die Hand zu geben, die es Ihrer Organisation ermöglichen, sich anzupassen und dynamisch die Orte und den Zeitpunkt zu finden, an denen eine Zusammenarbeit erforderlich ist, sowie den Zeitpunkt, an dem es am besten ist, sich auf die Arbeitsausführung zu konzentrieren und den Kommunikationsaufwand zu reduzieren.

Hinweis

Bei unseren Recherchen für dieses Buch sind wir auf ein faszinierendes Beispiel für strategisches und kooperatives Handeln in einem ganz anderen Bereich gestoßen. Es stellte sich heraus, dass Zackenbarsche und Muränen, scheinbar nicht verwandte Arten (Silos?), explizit (über Signale) zusammenarbeiten, um kleinere Fische zu jagen, die sich in Felsspalten verstecken. Die Muräne schleicht sich in die Spalten und verscheucht kleinere Fische, die dann gezwungen sind, herauszukommen und so leichte Beute für den Zackenbarsch zu werden. Lesen Sie weiter, um herauszufinden, wie Sie es den Zackenbarschen und Muränen in Ihrem Unternehmen ermöglichen, ihre Kräfte zu bündeln, um bessere Abläufe und Geschäftsergebnisse zu erzielen!

2

Das Conway’sche Gesetz und seine Bedeutung

Das [Conway’sche Gesetz] veranlasst uns, immer wieder zu fragen: »Gibt es ein besseres Design, das uns aufgrund unserer Organisation nicht zur Verfügung steht?«

– Mel Conway, Toward Simplifying Application Development, in a Dozen Lessons

In Kapitel 1 haben wir erörtert, warum Unternehmen die Organisation von Teams als einen wesentlichen Erfolgsfaktor betrachten müssen. Wir haben auch die zugrunde liegenden Ideen und Prinzipien besprochen, die zum Verständnis der Funktionsweise von Teams innerhalb einer Organisation beitragen. Wir haben einige zentrale Konzepte vorgestellt, auf die wir im Laufe des Buchs aufbauen werden. In den verbleibenden Kapiteln von Teil I werden wir genauer erörtern, was das Conway’sche Gesetz über Teams, Organisationsstrukturen und Softwarearchitektur aussagt; anschließend werden wir darauf eingehen, was ein teamorientierter Ansatz bedeutet. Ziel von Teil I ist, Ihnen die grundlegenden Prinzipien für die Organisation und die Gestaltung von Teams zu vermitteln, die Sie verstehen müssen, wenn Sie sich mit Team Topologies befassen, angefangen mit dem Conway’schen Gesetz.

Das Conway’sche Gesetz verstehen und anwenden

Das Conway’sche Gesetz ist von entscheidender Bedeutung, wenn es darum geht, die Kräfte zu verstehen, die bei der Organisation von Teams im Spiel sind, und zwar inmitten der lang anhaltenden, unbeaufsichtigten Auswirkungen, die sie auf unsere Softwaresysteme haben können, da diese größer und vernetzter geworden sind als je zuvor. Aber Sie fragen sich vielleicht, ob ein Gesetz aus dem Jahr 1968 über Softwarearchitektur den Test der Zeit überstanden hat.

Schließlich haben wir einen langen Weg hinter uns: Microservices, die Cloud, Container, Serverless. Unserer Erfahrung nach können solche Neuerungen Teams helfen, sich lokal zu verbessern, aber je größer die Organisation ist, desto schwieriger wird es, die Vorteile voll auszuschöpfen. Die Art und Weise, wie Teams zusammengesetzt sind und interagieren, basiert häufig auf vergangenen Projekten und/oder Legacy-Technologien (die das neueste Org-Chart-Design berücksichtigen, das Jahre, wenn nicht Jahrzehnte alt sein kann).

Wenn Sie jemals für ein großes Unternehmen gearbeitet haben, sind Ihnen wahrscheinlich Beispiele für monolithische, gemeinsam genutzte Datenbanken begegnet, die ein ganzes Unternehmen versorgen. Natürlich gab es in der Vergangenheit triftige Gründe für die Vorherrschaft monolithischer Datenbanken (z. B. die zunehmende Spezialisierung von Mitarbeiterinnen und Mitarbeitern sowie Teams auf technischen Ebenen), bis DevOps und Microservices an Bedeutung gewannen. Faktoren wie Projektorientierung, Kostensenkungen durch Outsourcing oder Juniorteams ohne ausreichende Erfahrung haben dazu beigetragen, dass sich dieses (jetzt erkennbare) Anti-Pattern durchgesetzt hat. Monolithische Datenbanken verkoppeln die Anwendungen, die von ihnen abhängen, und werden zu Anziehungspunkten für kleinteilige Logikänderungen auf Datenbankebene (mehr dazu in Kapitel 6). Um dies zu vermeiden, benötigen Unternehmen nicht nur gute architektonische Praktiken, sondern auch Teamstrukturen und -zusammensetzungen, die mit dieser neuen Denkweise in Einklang stehen.

Der Sportartikelhersteller Adidas durchlief eine interessante Transformation, bei der er das Conway’sche Gesetz als treibende Kraft für die Gestaltung seiner Organisation betrachtete. Wie Fernando Cornago, Senior Director of Platform Engineering, und Markus Rautert, Vice President of Platform Engineering and Architecture, erläuterten, wurde ihre IT-Abteilung von einer Kostenstelle mit einem einzigen Anbieter, der den Großteil der Software bereitstellte (was häufige Übergaben erforderte), und nur wenigen internen Entwicklerinnen und Entwicklern (die mehr verwalteten als entwickelten) zu einer produktorientierten Teamorganisation. Adidas investierte 80 % seiner technischen Ressourcen in den Aufbau eigener Softwareentwicklungskapazitäten durch cross-funktionale Teams, die sich an den Bedürfnissen des Business orientierten. Die anderen 20 % wurden einem zentralen Plattformteam gewidmet, das sich um die technischen Plattformen und die technische Entwicklung sowie um die Beratung und das Onboarding neuer Fachkräfte kümmerte. Adidas konnte die Release-Frequenz seiner digitalen Produkte um das Sechzigfache erhöhen und gleichzeitig einen positiven Einfluss auf die Softwarequalität verzeichnen.1

Neben empirischen Erkenntnissen gibt es auch immer mehr Forschungsergebnisse, die die von Conway skizzierten Tendenzen im Allgemeinen bestätigen. Alan MacCormack und seine Kollegen von der Harvard Business School untersuchten verschiedene Open-Source- und Closed-Source-Softwareprodukte und fanden »starke Belege für die Hypothese, dass die Architektur eines Produkts tendenziell die Struktur der Organisation widerspiegelt, in der es entwickelt wird«2.

Studien in anderen Branchen, wie dem Fahrzeugbau und der Entwicklung von Flugzeugtriebwerken, bestätigen diesen Gedanken.3 Tatsächlich gibt es genügend Branchenstudien, die zeigen, dass die homomorphe Kraft, die im Conway’schen Gesetz beschrieben wird, auf breiter Basis gilt.

Dieses Zitat von Ruth Malan ist gewissermaßen die moderne Version des Conway’schen Gesetzes: »Wenn die Architektur des Systems und die Architektur der Organisation nicht übereinstimmen, gewinnt die Architektur der Organisation«.4 Malan erinnert uns daran, dass die Organisation gezwungen ist, Entwürfe zu erstellen, die der realen Kommunikationsstruktur der Organisation vor Ort entsprechen oder diese nachahmen. Dies hat erhebliche strategische Auswirkungen für jedes Unternehmen, das Softwaresysteme konzipiert und entwickelt, sei es intern oder über Zulieferer.