Warum es nach hinten losgeht, wenn jedes Team seine eigene Pipeline baut

Stellen Sie sich vor: Ihr Unternehmen hat fünf stream-aligned Teams. Jedes Team baut seine eigene CI/CD-Pipeline von Grund auf. Eines setzt auf Jenkins, ein anderes auf GitLab CI, ein drittes schwört auf GitHub Actions. Jedes Team hat seine eigene Art, Staging-Umgebungen zu verwalten, in Produktion zu deployen und Secrets wie API-Keys oder Datenbankpasswörter zu speichern.

Zunächst sieht das nach Freiheit aus. Die Teams sind schnell. Sie wählen, was für sie funktioniert. Niemand wartet blockiert auf ein zentrales Team.

Aber nach ein paar Monaten zeigen sich die negativen Muster. Eine Sicherheitslücke wird in einer Pipeline entdeckt. Das Security-Team muss nun jedes Team einzeln aufsuchen, weil es keine einheitliche Möglichkeit gibt, den Fix anzuwenden. Ein Entwickler wechselt in ein anderes Team und muss eine völlig neue Pipeline von Grund auf lernen. Das Operations-Team versucht, die Anwendungszustände im gesamten Unternehmen zu überwachen, aber jedes Team liefert Logs in einem anderen Format.

Das ist keine Freiheit. Das ist Fragmentierung, getarnt als Autonomie.

Das Problem mit dem Bau von Grund auf

Wenn jedes Team seine eigene Pipeline unabhängig baut, zahlt das Unternehmen eine versteckte Steuer. Diese Steuer zeigt sich auf verschiedene Weise:

• Sicherheitsupdates dauern länger. Es gibt keinen zentralen Ort, um eine gemeinsame Abhängigkeit zu aktualisieren oder eine häufige Sicherheitslücke zu schließen.
• Wissenstransfer wird langsamer. Der Wechsel zwischen Teams bedeutet, Deployment-Workflows neu zu lernen, nicht nur die Fachdomäne.
• Operative Transparenz leidet. Monitoring, Logging und Alerting werden über Teams hinweg inkonsistent.
• Audits und Compliance werden mühsam. Jedes Team dokumentiert seinen eigenen Prozess, und es gibt keine einheitliche Sicht darauf, wie Änderungen in die Produktion gelangen.

Die Ursache ist nicht, dass die Teams inkompetent sind. Die Ursache ist, dass jedes Team immer wieder die gleichen Infrastrukturprobleme löst. Sie investieren Energie in die Verkabelung statt in das Produkt.

Was ein Plattform-Team tatsächlich tut

Ein Plattform-Team existiert, um diesen Kreislauf zu durchbrechen. Seine Hauptaufgabe ist es, gemeinsame Fähigkeiten aufzubauen und zu warten, die alle stream-aligned Teams nutzen können. Diese Fähigkeiten bilden das, was oft als interne Plattform bezeichnet wird.

Die Plattform kann umfassen:

• Standardisierte CI/CD-Pipelines
• Vorlagen für Entwicklungs- und Staging-Umgebungen
• Deployment-Tooling
• Zentralisiertes Monitoring und Logging
• Ein gemeinsames Secrets-Management-System

Aber hier ist der entscheidende Unterschied: Das Plattform-Team erledigt nicht die Arbeit der stream-aligned Teams. Es deployed keine Anwendungen. Es entscheidet nicht, wann ein Release stattfindet. Es schreibt keine Geschäftsfunktionen.

Das Plattform-Team baut das Fundament. Die stream-aligned Teams bauen darauf auf.

Die Bottleneck-Falle

Es gibt einen häufigen Fehler, den Unternehmen machen, wenn sie zum ersten Mal ein Plattform-Team bilden. Sie behandeln das Plattform-Team als das Team, das alles deployed. Wenn ein stream-aligned Team eine neue Version veröffentlichen muss, eröffnet es ein Ticket und wartet darauf, dass das Plattform-Team es erledigt.

Das macht das Plattform-Team zu einem Engpass. Jetzt reihen sich die stream-aligned Teams ein und warten darauf, dass das Plattform-Team Zeit hat. Der ganze Sinn eines Plattform-Teams war es, die Auslieferung zu beschleunigen, nicht zu verlangsamen.

Das richtige Modell ist Self-Service. Das Plattform-Team stellt Fähigkeiten bereit, die stream-aligned Teams eigenständig nutzen können. Das Plattform-Team definiert das Interface, die API, die Vorlage. Das stream-aligned Team führt die Pipeline aus, trifft die Entscheidung und trägt die Verantwortung für das Ergebnis.

Wenn etwas in der Pipeline kaputt geht, meldet es das stream-aligned Team dem Plattform-Team. Sie reparieren die Infrastruktur nicht selbst. Aber sie warten auch nicht auf die Erlaubnis zum Deployen.

Wie ein Plattform-Team sich entwickelt

Ein Plattform-Team kann nicht statisch sein. Die Bedürfnisse der stream-aligned Teams ändern sich im Laufe der Zeit.

Am Anfang reicht vielleicht eine einfache Pipeline, die baut, testet und deployed. Aber wenn die Organisation wächst, brauchen die Teams mehr. Ein Team benötigt Integrationstests mit einer echten Datenbank. Ein anderes braucht eine Staging-Umgebung, die die Produktion genau abbildet. Ein drittes benötigt Canary-Deployments, um Änderungen schrittweise auszurollen.

Das Plattform-Team muss auf diese Bedürfnisse hören und die Plattform entsprechend weiterentwickeln. Das ist kein einmaliger Bau. Es ist eine fortlaufende Beziehung zwischen dem Plattform-Team und den Teams, die es bedient.

Das Plattform-Team arbeitet auch nicht isoliert. Sie arbeiten oft mit einem Enabling-Team zusammen, um bestimmte Fähigkeiten zu verbessern. Sie könnten mit einem Complicated-Subsystem-Team zusammenarbeiten, wenn ein Teil der Plattform tiefgehendes Fachwissen erfordert, wie Datenbankreplikation oder Netzwerksicherheit.

Was sich ändert, wenn Sie es richtig machen

Wenn das Plattform-Team gut funktioniert, können sich stream-aligned Teams auf ihren Wertstrom konzentrieren. Sie müssen sich nicht darum kümmern, wie sie Server für die Pipeline einrichten. Sie denken nicht darüber nach, wie sie den Zugriff auf die Produktion sichern. Sie müssen nicht herausfinden, wie sie Logs aus allen Anwendungen aggregieren.

All das wird von der Plattform erledigt. Das stream-aligned Team schreibt Code, führt die Pipeline aus und liefert Funktionen aus. Die Plattform kümmert sich um den Rest.

Es geht nicht darum, Autonomie wegzunehmen. Es geht darum, unnötige Doppelarbeit zu vermeiden. Teams behalten die Kontrolle über ihre Deployment-Entscheidungen. Sie entscheiden weiterhin, wann sie releasen. Sie müssen nur nicht jedes Mal die Infrastruktur neu erfinden.

Eine kurze Checkliste für den Start eines Plattform-Teams

Wenn Sie darüber nachdenken, ein Plattform-Team zu bilden, hier ein paar Dinge, die Sie früh überprüfen sollten:

• Beginnen Sie mit dem größten Schmerzpunkt. Versuchen Sie nicht, am ersten Tag eine vollständige Plattform zu bauen. Wählen Sie eine Fähigkeit aus, mit der jedes Team kämpft, wie Secrets-Management oder Deployment-Vorlagen, und lösen Sie diese zuerst.
• Entwerfen Sie für Self-Service. Wenn Ihr Plattform-Team zu einem Gate wird, auf das alle warten müssen, haben Sie einen neuen Engpass geschaffen. Jede Fähigkeit sollte von stream-aligned Teams genutzt werden können, ohne ein Ticket zu eröffnen.
• Messen Sie die Adoption, nicht die Funktionen. Eine Plattform mit vielen Funktionen, die niemand nutzt, ist eine Belastung. Verfolgen Sie, wie viele Teams die Plattform tatsächlich nutzen, und hören Sie, warum andere sie nicht übernehmen.
• Planen Sie die Weiterentwicklung ein. Die Plattform muss sich ändern, wenn Teams wachsen. Bauen Sie Feedback-Schleifen ein, damit das Plattform-Team hört, was funktioniert und was fehlt.

Das Fazit

Ein Plattform-Team geht nicht um Zentralisierung der Kontrolle. Es geht darum, die langweilige, sich wiederholende Infrastrukturarbeit zu zentralisieren, damit sich stream-aligned Teams auf das konzentrieren können, was zählt: Wert für die Nutzer zu liefern. Wenn es richtig gemacht wird, macht das Plattform-Team jedes andere Team schneller, sicherer und konsistenter. Wenn es falsch gemacht wird, wird es zu einer weiteren Warteschlange.

Der Unterschied ist, ob Sie ein Fundament oder ein Tor bauen. Bauen Sie ein Fundament.