Drei Teams arbeiten parallel an CDK-Modulen. Keiner weiß vom anderen.
Erst als die Pipelines kollidieren, fällt es auf. Jeder hat sein eigenes Ding gebaut.
Das ist kein Zufall. Das ist Conway's Law in Aktion.
Kognitive Überlastung produziert Chaos
Ich sehe das ständig. Teams entwickeln Features, managen Infrastruktur und machen Support gleichzeitig.
Ein Engineer sitzt an einem neuen Service. Alle 20 Minuten kommt eine Slack-Nachricht zu Deployment-Problemen.
Der Context Switch kostet massiv Zeit. Fokus ist unmöglich.
Wenn Standards fehlen, Arbeiten doppelt gemacht werden und ständige Unterbrechungen den Alltag bestimmen, hast du ein strukturelles Problem.
Keine Tool-Frage. Eine Organisationsfrage.
Die Architektur zeigt die Teamstruktur
Wenn ich mir eine AWS-Architektur anschaue, sehe ich sofort die Teams dahinter.
Monolithische Accounts mit hunderten Services durcheinander? Ein großes Team ohne klare Grenzen.
Jedes Microservice mit eigenem Monitoring, Logging und Deployment-Setup? Isolierte Teams ohne Platform-Unterstützung.
Ein weiteres Beispiel: Ein Unternehmen implementierte fünf unterschiedliche Logging-Systeme, weil verschiedene Abteilungen ihre eigenen Standards entwickelten, ohne dass eine zentrale Architekturvorgabe existierte.
Conway's Law funktioniert in beide Richtungen. Schlechte Teamstrukturen produzieren schlechte Architekturen.
Aber du kannst auch gezielt gute Architekturen fördern, indem du Teams richtig strukturierst.
Team Topologies als Sprache
Team Topologies definiert vier Teamtypen: Stream-Aligned, Platform, Enabling und Complicated-Subsystem Teams.
Das ist kein Framework zum Implementieren. Das ist eine Sprache, die zeigt, warum es stockt.
Platform Teams bauen Standards. Stream-Aligned Teams konsumieren sie. Die Arbeit fällt nur einmal an.
Bei großen Tech-Companies wie Amazon oder Spotify gibt es mehrere Platform Teams für unterschiedliche Bereiche. Aber das Prinzip bleibt gleich.
Der häufigste Fehler? Platform Teams werden zu Gatekeepern.
X-as-a-Service nicht Ticket und warten
Die Lösung liegt in der Self-Service-Mentalität.
Das Platform Team baut nicht für einzelne Anfragen. Es stellt Produkte bereit, die Stream Teams eigenständig nutzen können.
Wenn ein Stream Team jedes Mal ein Ticket aufmachen muss, um eine neue Umgebung zu bekommen, hast du verloren.
Infrastructure as Code. Dokumentierte APIs. Klare Schnittstellen.
Bei AWS sehe ich das oft mit Landing Zones oder Service Catalogs. Das Platform Team definiert den Rahmen, aber die Stream Teams deployen selbst.
Der Schlüssel: Platform Teams müssen ihre internen Kunden verstehen. Wenn drei verschiedene Stream Teams nach dem gleichen Feature fragen, ist das ein Signal.
Drei Metriken für Platform-Team-Erfolg
Erstens: Wie lange dauert es von "Ich brauche X" bis "Ich habe X"?
Wenn Stream Teams Tage oder Wochen warten müssen, ist das Platform Team ein Bottleneck.
Zweitens: Wie oft kommen die gleichen Fragen?
Ständige Slack-Nachrichten wie "Wie deploye ich das?" bedeuten schlechte Dokumentation oder falsche Abstraktion.
Drittens: Wiederverwendung.
Nutzen mehrere Stream Teams die gleichen Platform-Services, oder baut jeder wieder sein eigenes Ding?
Bei einem gut funktionierenden Platform Team werden neue Stream Teams schnell produktiv. Die Grundlagen sind schon da.
Ein gutes Signal: Wie viele Deployment-Pipelines laufen pro Woche ohne Platform-Team-Involvement? Je höher die Autonomie, desto besser.
Der verteilte Monolith
Die meisten Unternehmen machen es falsch herum. Sie ändern die Architektur, behalten aber die alte Teamstruktur bei.
Das Ergebnis? Ein verteilter Monolith. Das Schlimmste aus beiden Welten.
Technisch sind es separate Services. Aber jedes Deployment braucht Koordination über alle Services hinweg, weil ein Team alles anfasst.
Du hast die Komplexität von Microservices, aber null Autonomie.
Team Topologies sagt: Stream-Aligned Teams sollten End-to-End-Verantwortung haben. Von Frontend bis Datenbank für ihren Bereich.
Wenn du das nicht machst, kämpfst du permanent gegen Conway's Law an. Und verlierst.
Evolution statt Revolution
Ich fange mit den Teams an, aber nicht mit einem Big Bang.
Der dritte Weg: Kleine, autonome Einheiten schaffen und dann wachsen lassen.
Ich suche mir einen Bereich aus, der relativ abgegrenzt ist. Ein Feature, eine Domain. Und bilde dafür ein echtes Stream-Aligned Team mit End-to-End-Verantwortung.
Die dürfen dann ihre Services so bauen, wie es richtig ist. Mit klaren Schnittstellen zum Rest.
Das wird zum Vorbild.
Parallel identifiziere ich die gemeinsamen Probleme. Deployments, Monitoring, Secrets Management. Und starte ein kleines Platform Team, das genau dafür Lösungen baut.
Nicht für alles auf einmal. Für die größten Schmerzpunkte.
Die Architektur folgt dann nach. Wenn Teams autonomer werden, entkoppeln sie automatisch ihre Services. Sie wollen nicht mehr auf andere warten.
Woran du erkennst dass es funktioniert
Realistisch? Sechs bis zwölf Monate, bis du echte Veränderungen siehst.
Aber die ersten Erfolge kommen schneller. Nach zwei, drei Monaten merkst du, ob es zieht.
Teams hören auf, sich gegenseitig zu blockieren. Stream Teams warten nicht mehr, bis jemand anderes "ihr Ding" deployed.
Die Slack-Kanäle ändern sich. Weniger "Wer kann mir helfen?", mehr "Wir haben das selbst gelöst".
Teams fordern ihre eigenen Standards. Wenn ein Stream Team zum Platform Team kommt und sagt "Wir brauchen das als Service, nicht als Ticket", haben sie verstanden.
Team Topologies funktioniert nicht, wenn es nur in Orgcharts steht.
Es funktioniert, wenn Teams anders arbeiten, anders kommunizieren und anders liefern.
Das siehst du an Deployment-Frequenz, an Lead Time, an der Stimmung.
Wenn Leute sagen "Wir kommen endlich voran", bist du auf dem richtigen Weg.