Plattform-Teams lieben es, Plattformen zu bauen. Genau das ist die Falle. Der häufigste Weg, eine Plattform-Initiative scheitern zu lassen, ist, sich achtzehn Monate lang einzuschließen, „alles auf einmal" zu entwerfen und ein Monument zu enthüllen, das niemand nutzt — weil es zu spät kam und die Probleme von gestern löst. Die Alternative heißt thinnest viable platform (TVP) und verlangt einen Denkwechsel: vom „Infrastrukturprojekt" zum „Produkt".
Ein Golden Path ist kein Scaffolder
Zuerst zu den Begriffen. Ein Golden Path (Netflix' Paved Road, Thoughtworks' Paved Path) ist der empfohlene, vom Plattform-Team unterstützte Weg, eine Routineaufgabe zu lösen: einen Service erstellen, eine Datenbank anbinden, Monitoring einrichten. Das Schlüsselwort ist unterstützt. Abweichungen sind erlaubt, doch das abweichende Team trägt die Supportkosten selbst.
Hier stolpern alle über den Umfang. Ein Golden Path ist nicht „der Scaffolder hat ein Repo angelegt". Er ist eine durchgängige Route: Code → CI → Registry → Deploy → Monitoring → On-Call. Wenn Ihr „goldener Pfad" an einem generierten Dockerfile endet, haben Sie eine Vorlage gebaut, keinen Pfad. Ein echter Pfad bringt eine Entwicklerin bis zum Produktivservice — mit HPA, PDB, NetworkPolicy, Dashboards, Multi-Burn-Rate-SLO-Alerts und einem ausgefüllten Runbook von Anfang an — ohne eine einzige Entscheidung, die man falsch treffen kann.
Ein reifer Golden Path hat vier Eigenschaften: er ist optional (die Plattform macht den richtigen Weg zum einfachsten, nicht zum einzigen — Zwang tötet Innovation), durchgängig, versioniert (go-microservice-v2, -v3; alte Versionen werden abgekündigt, nicht gelöscht) und im Besitz eines konkreten Teams innerhalb der Plattform-Organisation.
TVP: mit einem Pfad für ein Team beginnen
Die Versuchung ist, jede Sprache, jedes Szenario, jede Cloud abzudecken, bevor der erste Nutzer da ist. TVP kehrt die Reihenfolge um: einen Golden Path für ein Team wählen, ausliefern, den Schmerz dokumentieren, davon ausgehend erweitern. Die Erfolgsmetrik ist nicht „wie viele Features die Plattform hat", sondern eine einfache Frage: Hat das Team diesen Weg gewählt, oder nutzt es ihn, weil es gezwungen wurde? Wenn es ihn freiwillig wählt, funktioniert der Weg. Wenn nicht, haben Sie interne Bürokratie mit einem hübschen Portal gebaut.
Daraus folgt: Die Adoption Rate zählt mehr als jede technische Metrik. Drift Rate (wie viele Services den Pfad nach dem Start verlassen haben) und Time-to-Prod sind Diagnostik; die freiwillige Wahl ist die Diagnose.
Erst standardisieren, dann automatisieren
TVP hat eine eingebaute Sicherung, die man in der Eile leicht übersieht: einen kaputten Prozess zu automatisieren, macht das Scheitern nur schneller und konsistenter. Der klassische Fall ist ein fünftausend Zeilen langes Bash-Skript für AWS-Provisioning, ersetzt durch Crossplane. Es funktionierte nicht „wegen der Automatik", sondern weil zuerst der korrekte deklarative End-State formalisiert wurde und erst dann der Übergang dorthin automatisiert.
Das Symptom einer Verletzung erkennt man sofort: Der Golden Path beschreibt eine Ad-hoc-Sequenz („zuerst dies applyen, dann die ConfigMap bearbeiten, dann neu starten…") statt eines deklarativen End-States. Die Heilung: zuerst den End-State festlegen (eine Crossplane Composition, ein ApplicationSet, ein Helm-Chart mit klugen Defaults) und erst dann den Automatisierungs-Glue schreiben.
Der schmale, langweilige Stack als Gegenpol
Es gibt einen zweiten Weg, eine Paved Road zu bauen, das Gegenteil des „Self-Service-Buffets": ein schmaler, langweiliger, opinionierter Default-Stack. Amazons interne Teams leben nach einem Entscheidungsbaum: Lambda als Standard → bei Erreichen der Limits ECS auf Fargate → EC2 nur für Legacy; State ist DynamoDB, der Klebstoff ist S3, IaC ist CDK. Nicht „wähle ein beliebiges Tool aus einem erschöpfenden Katalog", sondern „hier sind zwei Optionen, die wir beide um drei Uhr nachts reparieren können".
Die Logik ist dieselbe wie beim Golden Path, nur auf die Spitze getrieben: Wildwuchs (Sprawl) ist der wahre Feind von Systemen, die länger leben als die Teams, die sie gebaut haben. Wenige Standardmuster schlagen eine Vielzahl einzeln rechtfertigbarer Entscheidungen. Beschränkungen sind hier Leitplanken, kein Käfig: Lambdas Limits zwingen dazu, früh über Chunking und Idempotenz nachzudenken. Eine bezeichnende Anekdote aus der Praxis: Eine Aurora-Datenbank wurde für einen einzigen Forscher aufgesetzt; Jahre später war der Forscher weg, die Datenbank lebte weiter. Das ist operative Schuld, die Menschen überdauert — genau das, was ein schmaler Stack verhindert.
Was man mitnehmen sollte
Ein Golden Path ist ein Produkt, kein Werkzeug: Er hat einen Eigentümer, Versionen, Nutzer, die man nicht zwingen kann, und eine Metrik der freiwilligen Wahl. Bauen Sie ihn nach TVP — schmal, für ein Team, vom Schmerz ausgehend erweiternd — standardisieren Sie den Prozess, bevor Sie ihn automatisieren, und denken Sie daran, dass der beste Golden Path manchmal nicht der flexibelste, sondern der langweiligste ist. Eine Plattform, die widerwillig genutzt wird, kostet mehr als gar keine: Sie zahlen sowohl für die Infrastruktur als auch für den Umweg, den die Teams ohnehin bauen werden.