Platform Engineering ist Mainstream — Jetzt kommt der schwierige Teil

Alle haben jetzt eine Plattform

Platform Engineering hat gewonnen. Zumindest auf dem Papier.

Knapp 90 % der Unternehmen haben inzwischen irgendeine Form von Plattform-Initiative. Kubernetes läuft bei 92 % der Container-nutzenden Organisationen. Ein durchschnittliches Unternehmen betreibt 6,3 Cluster. Die KubeCon Amsterdam 2026 steht vor der Tür, und niemand diskutiert mehr, ob man eine Plattform braucht.

Die Debatte hat sich verschoben: Warum scheitern so viele Platform-Teams trotz massiver Investitionen?

Die Zahlen sind ernüchternd. 45,3 % der Teams kämpfen mit Developer-Adoption. 29,6 % messen Erfolg überhaupt nicht. 18,3 % haben null messbare Ergebnisse geliefert. Und 40,9 % können innerhalb von zwölf Monaten keinen Mehrwert nachweisen.

Das ist kein Adoptionsproblem. Das ist eine Execution-Krise.

Die Adoptionslücke, über die niemand spricht

Hier ist die unbequeme Wahrheit: 36,6 % der Plattform-Adoption passiert per Anordnung. Nur 28,2 % entsteht, weil Entwickler tatsächlich Mehrwert in der Plattform sehen.

Denk mal drüber nach. Mehr Teams nutzen die interne Plattform, weil sie müssen, als weil sie wollen. Das ist kein Product-Market-Fit. Das ist Compliance.

Die Symptome sind überall:

• Entwickler bauen Workarounds statt Golden Paths zu nutzen
• Teams betreiben Shadow-Infrastruktur neben der „offiziellen” Plattform
• Plattform-Features werden für Architektur-Diagramme gebaut, nicht für echte Workflows
• Onboarding dauert Wochen, wenn es Stunden dauern sollte

Wenn deine Entwickler um deine Plattform herumarbeiten, hast du keine Plattform. Du hast ein Hindernis.

„Shift Down” statt „Shift Left”

Die Branche hat Entwicklern jahrelang gesagt, sie sollen „nach links shiften” — Verantwortung für Security, Testing, Infrastruktur, Observability übernehmen. Das Ergebnis? Entwickler, die in operativen Aufgaben ertrinken, statt Features zu bauen.

Die Gegenbewegung heißt Shift Down: Komplexität eliminieren statt umverteilen.

Der Unterschied ist entscheidend:

• Shift Left: „Entwickler, hier ist ein Terraform-Modul. Lern Terraform.”
• Shift Down: „Beschreib, was du brauchst. Die Plattform kümmert sich um Terraform, Kubernetes, Netzwerk und DNS.”

Eine gut umgesetzte Plattform schult Entwickler nicht über Infrastruktur. Sie macht Infrastruktur unsichtbar für die 80 % der Fälle, die keine Custom-Konfiguration brauchen. Die restlichen 20 %? Escape Hatches gibt es. Aber sie sollten Ausnahmen sein, nicht der Standard.

Deshalb funktioniert der MVP-Ansatz: Teams, die innerhalb von 4–6 Wochen einen fokussierten Golden Path für einen konkreten Schmerzpunkt liefern, sehen Adoption. Teams, die 18 Monate an einer umfassenden Plattform bauen, die niemand bestellt hat, sehen Anordnungen.

KI hat die Bedeutung von „Plattform” verändert

Kubernetes war ursprünglich für stateless Webanwendungen gedacht. Dann Datenbanken. Dann Batch-Jobs. Heute laufen 82 % der Container-Nutzer auf Kubernetes in Produktion — und KI ist ein zentraler Treiber.

KI ist nicht einfach ein weiterer Workload. Sie verändert Plattform-Anforderungen grundlegend:

• GPU-Scheduling hat nichts mit CPU-Scheduling zu tun. Ressourcen sind teuer, knapp und werden teamübergreifend mit konkurrierenden Prioritäten geteilt.
• Training-Jobs sind stoßartig und langlebig. Sie passen nicht in Autoscaling-Modelle, die für HTTP-Traffic designed sind.
• Datenpipelines schaffen neue Abhängigkeiten zwischen Storage, Compute und Model-Serving, für die traditionelle Plattformen nicht gebaut wurden.
• Inference braucht vorhersagbare Latenz bei unvorhersagbarer Last — genau die Kombination, die naive Scaling-Konfigurationen zerlegt.

Für Platform-Teams heißt das: Multi-Plattform-Umgebungen betreiben. Applikationsplattformen, Datenplattformen und KI-Plattformen dienen grundlegend unterschiedlichen Zwecken. 55,9 % der Organisationen betreiben bereits mehrere Plattformen — by Design, nicht aus Versehen.

Die Mittelstands-Implikation? Du brauchst nicht alle drei am ersten Tag. Aber deine Plattform-Architektur sollte sie aufnehmen können, ohne dass ein Rewrite nötig wird.

FinOps ist jetzt ein Plattform-Thema

Kubernetes macht Skalierung trivial einfach. Geldverbrennen aber auch.

Die Flexibilität, die Container so mächtig macht — dynamisches Scaling, Resource-Sharing, Multi-Tenant-Cluster — hat klassisches Kostenmanagement gesprengt. Wenn Cluster über Clouds, Regionen und On-Premise-Umgebungen verteilt sind, wird die Frage „Wo geht das Geld eigentlich hin?” verdammt schwer zu beantworten.

Platform-Teams übernehmen das zunehmend:

• Echtzeit-Kostenattribution nach Namespace, Team und Service — nicht nur Monatsrechnungen
• Automatisches Rightsizing basierend auf tatsächlicher Nutzung vs. angeforderten Ressourcen (die Lücke beträgt typischerweise 30–60 %)
• Anomalie-Erkennung, um Kostenspitzen zu fangen, bevor sie auf der Rechnung landen
• Showback- und Chargeback-Modelle, die Kosten für die verursachenden Teams sichtbar machen

Das ist kein Nice-to-have. In Unternehmen, wo Cloud-Ausgaben der drittgrößte Budgetposten nach Gehältern und Büromiete sind, ist Kostentransparenz eine strategische Anforderung. Und das Platform-Team ist das einzige Team mit genug Querschnitts-Sicht, um das zu liefern.

Compliance als Plattform-Feature

Zwischen NIS2 (seit Dezember 2025 in Deutschland durchsetzbar), dem EU AI Act und der expandierenden DSGVO-Auslegung ist regulatorische Compliance ein Plattform-Thema geworden — kein Quartals-Audit.

Der praktische Shift: Compliance wandert in die Pipeline.

• Policy-as-Code blockiert nicht-konforme Konfigurationen vor dem Deployment
• GitOps-Workflows stellen sicher, dass jede Änderung nachvollziehbar und auditierbar ist
• Datenresidenz-Durchsetzung auf Cluster-Ebene, nicht auf Applikationsebene
• Continuous Monitoring ersetzt periodische Audits

Für mittelständische Unternehmen ist das eigentlich eine gute Nachricht. Wenn Compliance ein Plattform-Feature ist, implementierst du es einmal. Jedes Team, das über die Plattform deployt, bekommt Compliance by Default. Die Alternative — jedes Team implementiert eigene Audit-Trails, Zugriffskontrollen und Datenresidenz-Logik — skaliert nicht.

Was tatsächlich funktioniert

Nach der Arbeit mit Platform-Teams verschiedenster Unternehmensgrößen trennt Folgendes die 35 %, die in sechs Monaten Mehrwert liefern, von den 41 %, die in zwölf Monaten keinen nachweisen können:

1. Dedizierte Product Ownership

Nur 36,6 % der Platform-Teams haben einen dedizierten Platform Product Manager. Der Rest verlässt sich auf Engineers „mit Product-Mindset”. Das reicht nicht. Jemand muss die Roadmap ownen, Adoption messen und harte Priorisierungsentscheidungen treffen. Ein Engineer, der nebenbei Product-Thinking macht, wird immer Bauen über Messen stellen.

2. Mit einem Schmerzpunkt starten

Die größte Falle ist die Big-Bang-Plattform. Nimm den einen Workflow, der deinen Entwicklern am meisten wehtut. Bau einen Golden Path, der 80 % der Fälle abdeckt. Liefer ihn in Wochen, nicht Monaten. Miss Adoption sofort. Dann erweitern.

3. Das Richtige zum Einfachsten machen

Wenn dein Golden Path ein 40-seitiges Wiki braucht, ist er nicht golden. Entwickler wählen immer den Weg des geringsten Widerstands. Die Aufgabe deiner Plattform: Der korrekte Weg muss auch der einfachste Weg sein.

4. Messen oder sterben

29,6 % der Teams messen gar nicht. Wenn du nicht zeigen kannst, dass Deployment-Frequenz gestiegen ist, Lead Time gesunken ist oder Developer-Zufriedenheit sich verbessert hat — kannst du Investment nicht rechtfertigen. Starte mit DORA-Metriken und Platform NPS. Komplexität kommt später.

5. Adoption als Signal behandeln, nicht als Ziel

Adoption per Anordnung beweist nichts außer Autorität. Freiwillige Adoption beweist Mehrwert. Tracke beides, optimiere aber auf freiwillige Nutzung.

Das Fazit

Platform Engineering ist nicht schwer wegen Kubernetes, Terraform oder Service Meshes. Es ist schwer, weil ein Produkt für interne Entwickler dieselbe Disziplin verlangt wie jedes andere Produkt: Nutzer verstehen, Ergebnisse messen, schnell iterieren und ehrlich sein über das, was funktioniert.

Das Tooling war nie besser. Die Herausforderung ist alles drumherum.

Wenn dein Platform-Team mit dem Kopf nach unten Features baut, ohne wöchentlich mit Entwicklern zu sprechen, Adoption ehrlich zu messen und ROI quartalsweise nachzuweisen — hör auf zu bauen. Fang an zuzuhören.

Die nächste Welle von Platform Engineering wird nicht dadurch definiert, wer den besten Tech-Stack hat. Sondern dadurch, wer Plattformen baut, die Entwickler tatsächlich nutzen wollen.