Der Platform Program split war ein entscheidender Schritt für Uber, als das Wachstum des Teams die Entwicklung zu bremsen begann. Diese Entscheidung veränderte sowohl die Architektur als auch die Organisation gleichzeitig.
Das Problem trat nicht auf Code-Ebene, sondern auf Ebene der Teaminteraktionen auf. Als die Ingenieurorganisation von Uber auf etwa 100 Personen anwuchs, wurde die Trennung in Backend, Frontend und Mobile zum Engpass. Jede Funktion erforderte eine Koordination zwischen mehreren Teams, von denen jedes sein eigenes Backlog und Prioritäten hatte. Infolgedessen sank die Liefergeschwindigkeit, trotz des Wachstums des Teams. Parallel dazu existierte ein monolithischer API-Service, der weiterhin wuchs und regelmäßig Ausfälle verursachte.
Die Lösung begann nicht mit Mikrodiensten, sondern mit einer Änderung der Teamstruktur. Der Platform Program split wurde eingeführt: cross-funktionale Programm-Teams übernahmen die Verantwortung für produktbezogene Funktionen end-to-end, während Plattform-Teams für Infrastruktur und gemeinsame Dienste zuständig waren. Dies verringerte die Abhängigkeit zwischen den Teams und beseitigte die Notwendigkeit, sich für jedes Release „abzusprechen“. Erst nach diesem Schritt wurde die mikroskopische Architektur zu einer logischen Fortsetzung und nicht zu einem Ausgangspunkt. Der Kompromiss ist hier offensichtlich: Die Autonomie der Teams wächst, aber die Komplexität der Koordination von Plattformverträgen und Standards nimmt zu.
Die Migration zu Mikrodiensten erfolgte schrittweise und unter dem Druck des Hyperwachstums. Es wurde eine einfache Regel eingeführt: Alles Neue muss außerhalb des Monolithen gebaut werden. Dies verhinderte Blockaden zwischen den Teams. Gleichzeitig wuchs der Monolith weiter — das Geschäft fügte neue Funktionen schneller hinzu, als die Dekomposition stattfand. Diese „schmutzige Übergangsphase“ dauerte etwa zwei Jahre. Wichtig ist, dass Uber nicht versuchte, das System auf einmal neu zu schreiben: Stattdessen entwickelte sich die Architektur weiter und gab dem System Zeit zum Überleben.
Die Umsetzung wurde von zusätzlichen ingenieurtechnischen Lösungen begleitet. Es entstanden interne Werkzeuge, die das Skalieren und die Entwicklung unterstützten. Es gab Anforderungen an die Benennung von Diensten — aufgrund des Wachstums des Systems begannen informelle Namen, die Navigation und das Onboarding zu behindern. Es wurde auch offensichtlich, dass Standardwerkzeuge für solch einen Umfang nicht ausreichten, weshalb ein Teil der Plattformlösungen intern entwickelt wurde. Dies ist ein typischer Trade-off: Die Beschleunigung der Entwicklung durch maßgeschneiderte Werkzeuge erhöht die Kosten für deren Wartung.
Ein separater Aspekt sind die Neuschreibungen (rewrites). Unter den Bedingungen des Hyperwachstums wurden sie zur regelmäßigen Praxis. Jede Neuschreibung gab dem System einen neuen „Puffer“, löste jedoch das Problem nicht für immer. Diese wichtige Beobachtung zeigt: Ein Rewrite ist hier kein Planungsfehler, sondern ein Signal dafür, dass das Geschäft die aktuelle Architektur überholt. In einem solchen Modell wird Stabilität zu einem vorübergehenden Zustand.
Die Ergebnisse lassen sich nicht auf eine Metrik reduzieren — in den Ausgangsdaten sind sie nicht vorhanden. Die indirekten Effekte sind jedoch klar. Der Platform Program split verringerte organisatorische Blockaden und beschleunigte die Lieferung. Der Übergang zu Mikrodiensten ermöglichte es den Teams, unabhängig zu wachsen. Gleichzeitig wurde das System erheblich komplexer: Die Anzahl der Dienste wurde in Tausenden gemessen, und selbst Jahre später bleibt ihre Zahl vergleichbar. Dies bestätigt, dass Skalierbarkeit auf Kosten eines Anstiegs der operationellen Komplexität erreicht wurde.
Zusätzlich trat ein weiterer Effekt zutage: Architektur und Organisation wurden untrennbar. Der Platform Program split legte faktisch die Grenzen der Dienste und Verantwortungsbereiche fest. Dies stimmt mit der industriellen Beobachtung überein: Die Struktur der Teams hat direkten Einfluss auf die Struktur des Systems. Bei Uber war dieser Einfluss bewusst und steuerbar.
Es ist auch erwähnenswert, dass solche Lösungen nur bei hoher Dichte an Ingenieurtalent funktionieren. Der Ansatz mit autonomen Teams und verteilter Architektur erfordert reife Ingenieure und starke Plattformstandards. Ohne dies degeneriert das System schnell.
Letztendlich kann der Platform Program split als pragmatische Antwort auf Hyperwachstum betrachtet werden. Es ist kein Versuch einer „idealen Architektur“, sondern ein Weg, spezifische Einschränkungen in der Geschwindigkeit der Entwicklung zu beseitigen. Mikrodienste sind in dieser Geschichte eine Folge und nicht die Ursache. Und die zentrale Lektion hier ist, dass Skalierung synchronisierte Änderungen in Architektur, Prozessen und Teamstrukturen erfordert.