Wenn eine interne Developer Platform scheitert, hinterlässt sie mehr als technische Schulden – sie hinterlässt Lektionen, die die gesamte Branche weiterbringen können. eBays gescheitertes Plattformprojekt Velocity ist eines der seltenen Beispiele, bei dem ein Technologiekonzern offen genug ist, die eigenen Fehler zu benennen.
Platform Engineering: Was eBays gescheitertes Velocity-Projekt der Branche hinterlässt
eBay hat mit seinem internen Plattformprojekt „Velocity” einen kostspieligen Lehrgang durchlaufen – und die Erkenntnisse daraus sind für Unternehmen, die eigene Developer Platforms aufbauen, von erheblichem praktischem Wert. Das Scheitern des Projekts offenbart strukturelle Fehler, die in der Branche weitaus häufiger vorkommen als öffentlich eingestanden wird.
Zu viel Plattform, zu wenig Nutzerzentrierung
Das Kernproblem bei Velocity war kein technisches, sondern ein strategisches: Das Plattformteam baute an einer Lösung, ohne die tatsächlichen Arbeitsabläufe der Entwickler ausreichend zu verstehen. Die Plattform wurde intern konzipiert wie ein Produkt für externe Kunden – mit eigenem Roadmap-Prozess, eigenem Releasemanagement und eigenen Qualitätsstandards.
Was dabei fehlte, war die kontinuierliche Rückkopplung mit den internen Nutzern. Developer Platform Teams neigen dazu, in einer Art organisatorischer Isolation zu arbeiten und Anforderungen top-down zu definieren, anstatt Bottom-up aus dem Entwickleralltag zu schöpfen.
Die Abstraktionsfalle
Ein weiteres strukturelles Problem: Velocity versuchte, zu viele Komplexitätsebenen auf einmal zu abstrahieren. Der Ansatz, eine einheitliche Plattform über heterogene Systemlandschaften hinweg zu legen, führte zu einer Abstraktionsschicht, die weder flexibel genug für die Nutzer noch wartbar genug für das Plattformteam war.
In der Praxis führte das dazu, dass Entwicklungsteams Workarounds etablierten – und die Plattform damit de facto umgingen.
Der sogenannte „Golden Path”, also der empfohlene Standardweg durch eine Plattform, muss tatsächlich der einfachste Weg sein. Ist er das nicht, werden Entwickler ihn meiden.
Governance ohne Adoption ist wirkungslos
eBays Erfahrung zeigt auch, dass Plattform-Governance nicht durch Vorschriften durchgesetzt werden kann. Velocity wurde zeitweise als verpflichtend deklariert – was zu oberflächlicher Compliance, aber keiner echten Adoption führte. Teams nutzten die Plattform formal, entwickelten aber parallele Prozesse.
Für Platform Engineering gilt: Die Bereitschaft zur Nutzung entsteht durch Mehrwert, nicht durch Verpflichtung.
Incentive-Strukturen und konkreter Nutzennachweis sind wichtiger als interne Richtlinien.
Was funktioniert hat – und warum
Trotz des Scheiterns des Gesamtprojekts haben einzelne Komponenten von Velocity überlebt und wurden in Folgeprojekte integriert. Das betrifft vor allem die Teile, die:
- isoliert funktionsfähig waren,
- klaren Mehrwert boten,
- von kleinen, engagierten Teams iterativ weiterentwickelt wurden.
Das Muster ist bekannt aus erfolgreichen Platform-Engineering-Projekten anderer Unternehmen: Kleine, modular aufgebaute Plattformkomponenten mit schnellen Feedbackzyklen überleben häufiger als monolithische Plattformvisionen.
Einordnung für deutsche Unternehmen
Für deutsche Unternehmen, die aktuell eigene Internal Developer Platforms aufbauen oder evaluieren, liefert eBays Erfahrung konkrete Orientierungspunkte. Die Frage, ob eine Plattform intern als Produkt geführt werden sollte, ist längst nicht mehr akademisch – sie entscheidet über Akzeptanz und ROI.
Wer Platform Engineering als reines Infrastrukturprojekt begreift, unterschätzt den organisatorischen Aufwand. Entscheidend ist:
- Wer sind die internen Nutzer?
- Welche Pain Points werden tatsächlich adressiert?
- Kann das Plattformteam mit echten Nutzungsdaten arbeiten?
Gerade in mittelständischen Strukturen, wo Entwicklungsressourcen knapp sind, gilt:
Weniger Plattform mit höherer Adoption ist belastbarer als eine umfassende Lösung, die intern umgangen wird.
