Die Platform-Insel: Warum niemand auf unserer Plattform deployt

Jedes zweite Unternehmen hat eine. Die meisten haben sechsstellig investiert. Und in fast jedem Fall ist die meistgenutzte Funktion der Passwort-Reset-Link. Die Rede ist von Internal Developer Platforms (IDPs) – den hauseigenen Entwicklerplattformen, die alles können, aber von niemandem genutzt werden.

Das Phänomen der Platform-Insel

Du kennst das: Das Unternehmen kauft oder baut eine Platform. Ein Team von Plattform-Ingenieuren arbeitet monatelang an der Architektur. Es gibt eine schicke UI, CI/CD-Pipelines, Self-Service-Schnittstellen. Die Plattform wird mit einem großen Launch gefeiert – und dann passiert: nichts.

Die Teams arbeiten weiter wie vorher. Sie nutzen ihre eigenen Skripte, ihre eigenen Workflows, ihre eigenen Verzeichnisse. Die Plattform wird zur digitalen Geisterstadt.

Warum?

Drei Gründe, warum Plattformen scheitern

1. Die Plattform löst kein echtes Problem

Der häufigste Fehler: Die Plattform wurde gebaut, weil das Management eine Plattform wollte – nicht, weil die Entwickler ein Problem hatten.

Eine Plattform, die kein akutes Schmerzgefühl adressiert, wird nie adoptiert. “Schau mal, wir haben eine schöne UI für Kubernetes-Deplyments” ist kein Wertversprechen. “Dein Deployment braucht bisher 45 Minuten und drei E-Mails an das Ops-Team – ab jetzt geht es in drei Minuten per Klick” schon.

2. Zu viel Komplexität, zu wenig Standardisierung

Viele Plattformen versuchen, alle möglichen Workflows abzubilden. Das Ergebnis: Sie können alles, aber nichts richtig. Die Bedienoberfläche ist überladen, die Dokumentation veraltet, die Schnittstellen inkonsistent.

Die erfolgreichsten Plattformen beschränken sich auf wenige, aber exzellent umgesetzte Golden Paths: Einordnige, dokumentierte, getestete Standard-Workflows für die häufigsten Aufgaben.

3. Keine Migration, kein Druck

Die größte Hürde ist die Bestandsarbeit: Bestehende Projekte laufen mit alten Skripten, Makefiles und Handbuch-Wissen. Solange diese funktionieren, gibt es keinen Grund umzusteigen.

Die plattform baut, aber niemand migriert die Bestandsprojekte. Und ohne Migration bleibt die Plattform leer.

Was Plattformen stattdessen brauchen

Aus der Beobachtung funktionierender Plattformen (Backstage, interne Developer Portals bei Spotify, Red Hat, Netflix) lassen sich fünf Prinzipien ableiten:

1. Pain before Platform

Bevor du eine Plattform baust, finde heraus, wo der Schmerz am größten ist. Miss die Zeit, die Teams mit manuellen Prozessen verlieren. Sprich mit den Entwicklern, nicht mit den Vorgesetzten.

Eine Plattform, die den größten Schmerz zuerst adressiert, wird adoptiert. Eine Plattform, die “alles” kann, wird ignoriert.

2. Golden Paths, keine Workflow-Engine

Definiere genau 3-5 Standard-Workflows, die wie im Schlaf funktionieren. Alles andere ist zweitrangig.

3. Self-Service mit Sicherheitsnetz

Entwickler müssen die Plattform nutzen können, ohne ein Ticket schreiben zu müssen. Aber jede Aktion muss auditiert und rückgängig machbar sein.

4. Migration ist kein nachträglicher Gedanke

Ein Drittel des Plattform-Budgets gehört in die Migration. Automatisierte Migrations-Tools, Import-Schnittstellen, Kompatibilitäts-Modi – alles, was den Umstieg erleichtert.

5. Metriken und Sichtbarkeit

Die Plattform muss messen, ob sie genutzt wird. Anzahl aktive Projekte, Deployment-Frequenz, Time-to-Production. Diese Metriken gehören ins Management-Dashboard – und wenn sie stagnieren, ist das ein Alarmzeichen.

Das Gegenbeispiel: Spotify und Backstage

Spotify baute Backstage, weil das Infrastructure-Team in 50 Teams mit unterschiedlichen Sprachen, Tools und Deployment-Prozessen keinen Standard-Workflow hatte. Der Schmerz war real: Ein neues Service brauchte Wochen, um durch alle Prüfungen zu kommen.

Backstage automatisierte genau diesen einem Workflow: Service-Template generieren → CI/CD anbinden → Deployment-Richtlinien einhalten → Monitoring einrichten. Nicht mehr, nicht weniger.

Das Ergebnis: Backstage wurde von Spotify-intern adoptiert, später open-sourcet, zur CNCF-Graduierung geführt – und ist heute die am weitesten verbreitete Internal Developer Platform der Welt. Helen Greul, Head of Engineering für Backstage bei Spotify, berichtete in einem Interview mit The New Stack, dass Spotify eine freiwillige 99% Plattform-Adoption erreicht hat. Ihr Schlüssel: “With a product thats built for developers, with empathy for developers, they recognize the value.”

Warum? Weil es einen Workflow perfekt automatisierte – den mit dem größten Schmerz.

Fazit: Weniger ist mehr

Eine erfolgreiche Plattform ist keine Plattform, die alles kann. Es ist eine Plattform, die eine Sache so gut macht, dass kein Entwickler mehr ohne sie arbeiten will.

Wenn deine Plattform nach einem Jahr noch keine 80% Adoption hat, liegt es nicht an den Entwicklern. Es liegt am Platform-Design. Stell die Frage anders: Nicht “Was kann die Plattform?”, sondern “Welches Problem löst die Plattform für wen – und wie messe ich, ob es gelöst ist?”

Plattform-Inseln entstehen nicht durch böswillige Entwickler, sondern durch Plattformen, die Probleme lösen, die niemand hat.