Wir haben dutzende interne Developer-Plattformen mit echtem Budget und ehrlicher Begeisterung entstehen und dann innerhalb eines Jahres still und leise verkümmern sehen. Das Muster ist so beständig, dass wir es inzwischen als Design-Vorgabe behandeln und nicht als Überraschung.
Warum Plattformen aufgegeben werden
Den meisten gescheiterten IDPs liegt dieselbe Ursache zugrunde: Sie wurden für das mentale Modell des Plattform-Teams gebaut, nicht für den Arbeitsalltag der Anwendungs-Engineers. Ein Golden Path, der für jede Aufgabe eine neue Abstraktion verlangt, konkurriert direkt mit den Shell-Skripten, denen ein Team bereits vertraut — und die Shell-Skripte gewinnen meistens.
- Die Plattform löst die Probleme des Plattform-Teams, nicht die der Nutzer.
- Einen neuen Service einzubinden dauert länger, als es von Hand zu tun.
- Es gibt keinen klaren Verantwortlichen, wenn nachts um 2 Uhr etwas kaputtgeht.
Die Plattform als Produkt behandeln
Die IDPs, die überleben, haben einen Product Manager, eine von Nutzerinterviews getriebene Roadmap und ehrliche Adoptions-Metriken. Wir beginnen jedes Projekt damit, drei Teams eine Woche lang zu begleiten und jeden Befehl aufzuschreiben, den sie ausführen, um eine Änderung auszuliefern. Dieses Protokoll — nicht eine Referenzarchitektur — wird zum Backlog.
Eine interne Plattform gewinnt Akzeptanz wie jedes Produkt: indem sie schon beim allerersten Versuch schneller ist als die Alternative.
Den Golden Path zum schnellen Weg machen
Das eine Feature, das Akzeptanz treibt, ist ein Self-Service-Scaffold, das einen Engineer in Minuten vom leeren Repository zu einem laufenden, beobachtbaren Service bringt.
$ idp new service --template go-api
✓ repo created, CI wired, dashboards provisioned
✓ staging deploy live in 4m12sWenn dieser Befehl wirklich schneller ist, als die Konfiguration eines Nachbarteams zu kopieren, muss man Akzeptanz nicht mehr verordnen. Messt den Erfolg daran, wie viele Teams von sich aus zur Plattform greifen — alles andere ist Selbstbetrug.