Wie baut man eine Internal Developer Platform mit Backstage auf?
Direkte Antwort
Der belastbarste Weg zu einer Internal Developer Platform mit Backstage beginnt nicht mit vollständiger Abdeckung, sondern mit einem einzigen, gut ausgearbeiteten Golden Path für den häufigsten Anwendungsfall im Unternehmen — etwa "neuer Microservice mit Standard-CI/CD" —, der erst nach nachgewiesenem Nutzen auf weitere Anwendungsfälle erweitert wird.
"Eine Plattform mit zehn halbfertigen Golden Paths wird seltener genutzt als eine Plattform mit einem einzigen, wirklich reibungslosen Golden Path.
Viele Backstage-Einführungen scheitern nicht an der Technologie, sondern am Versuch, von Beginn an alle denkbaren Entwicklerbedürfnisse gleichzeitig abzudecken, statt mit einem kleinen, aber tatsächlich genutzten Kern zu starten.
Mit dem Software Catalog als Basis beginnen
Backstages Kernfunktion ist der Software Catalog, ein zentrales Verzeichnis aller Services, ihrer Besitzer und ihrer Abhängigkeiten — dieser Katalog allein schafft bereits Transparenz über eine oft historisch gewachsene, unübersichtliche Servicelandschaft.
Der Aufbau des Katalogs sollte automatisiert aus bestehenden Quellen erfolgen (Git-Repositories, CI/CD-Konfiguration), statt manuell gepflegt zu werden, weil ein manuell gepflegter Katalog erfahrungsgemäß schnell veraltet und an Vertrauenswürdigkeit verliert.
Einen einzigen Golden Path vollständig ausarbeiten
Statt gleichzeitig Templates für viele verschiedene Anwendungsfälle zu bauen, sollte zunächst ein einziger, häufig benötigter Anwendungsfall (etwa "neuer REST-Microservice in Python") als vollständiger Self-Service-Workflow implementiert werden — von der Codegenerierung über CI/CD-Einrichtung bis zum ersten Deployment.
Dieser fokussierte erste Schritt liefert einen sichtbaren, überzeugenden Erfolg, der die Akzeptanz für weitere Golden Paths im Unternehmen erhöht, statt mit einer breiten, aber oberflächlichen Abdeckung zu starten.
Akzeptanz durch tatsächlichen Nutzen statt Vorgabe erreichen
Eine interne Plattform wird nur genutzt, wenn sie für Entwicklungsteams tatsächlich schneller ist als der bisherige Weg — eine Plattform, die zusätzlichen Aufwand erzeugt, wird trotz offizieller Vorgabe umgangen.
Regelmäßiges Feedback von den ersten Nutzerteams und die Bereitschaft, den Golden Path basierend auf diesem Feedback anzupassen, ist entscheidender für den langfristigen Erfolg als die technische Vollständigkeit der Plattform beim Start. Ein messbarer Erfolgsindikator dafür ist die Zeit bis zum ersten erfolgreichen Deployment eines neuen Services ("Time to First Deploy") — sinkt dieser Wert spürbar gegenüber dem manuellen Vorgehen, ist das ein belastbareres Signal für echte Akzeptanz als reine Nutzungszahlen des Portals.
Wann passt es — wann nicht?
Passt gut
- ✓Es gibt einen klar erkennbaren, häufig wiederkehrenden Anwendungsfall (etwa "neuer Microservice") in mehreren Teams
Passt nicht
- ✗Es gibt nur sehr heterogene, seltene Anwendungsfälle ohne klares Muster