class PlatformEngineering extends DevOps?
Alle paar Jahre bekommt der Betrieb einen neuen Namen. 2020 habe ich Euch hier «class SRE implements DevOps» vorgestellt, ein Jahr später musste ich nachlegen und nannte SRE «die grösste Lüge seit Kanban» – nicht weil die Idee schlecht wäre, sondern weil so viele Firmen nur das Türschild ausgetauscht haben. Und jetzt, 2026, lese ich auf LinkedIn im Wochentakt: «DevOps ist tot. Lang lebe Platform Engineering.»
Zugegeben, bei so viel Beerdigungsstimmung werde ich neugierig. Wer ist da gestorben, wer erbt, und wer hat das Testament geschrieben? Schauen wir genauer hin.
Was ist da eigentlich neu?
Platform Engineering heisst: Eine Organisation baut sich eine interne Entwicklungsplattform – neudeutsch Internal Developer Platform (IDP) – und behandelt sie wie ein Produkt. Die «Kunden» dieses Produkts sind die eigenen Produktteams. Statt dass jedes Team seine Pipeline, sein Kubernetes-Setup und sein Monitoring selbst zusammenschraubt, bekommt es vom Plattform-Team vorbereitete, abgesicherte Wege: sogenannte Golden Paths. Selbstbedienung statt Ticket, Standard statt Bastelei.
Die Zahlen dazu sind eindrücklich. Gartner prognostizierte, dass bis 2026 rund 80 Prozent der grossen Software-Organisationen ein Plattform-Team haben werden – 2022 waren es erst 45 Prozent. Und die DORA-Forschung meldet für 2025: 90 Prozent der befragten Organisationen nutzen eine interne Plattform, 76 Prozent haben ein dediziertes Plattform-Team. Wer jetzt erst davon hört, ist also nicht früh dran – aber auch nicht zu spät, dazu gleich mehr.
Der eigentliche Grund: unsere Köpfe sind voll
Um zu verstehen, warum das gerade jetzt passiert, muss man ehrlich auf zehn Jahre DevOps zurückschauen. «You build it, you run it» war und ist das richtige Prinzip: Wer die Anwendung baut, verantwortet sie auch im Betrieb. Nur haben wir dabei etwas unterschätzt – die Rechnung zahlt das Hirn der Teams.
Ein Produktteam von heute soll sein Fachgebiet beherrschen, dazu Kubernetes, Infrastructure as Code, IAM-Policies, Observability, Security-Scanning und die halbe Cloud-Preisliste. Team Topologies von Matthew Skelton und Manuel Pais hat dafür den passenden Begriff geprägt: kognitive Last. Teams haben eine endliche Denkkapazität, und DevOps hat die Komplexität nicht beseitigt – es hat sie umverteilt. Auf alle.
Ich schrieb schon im SRE-Artikel von meiner Zeit als Leiter eines Betriebsteams, das für vier, fünf Entwicklungsteams den Betrieb stemmen sollte: Wir waren klug, wir waren automatisiert, und wir waren trotzdem chancenlos, weil das Modell uns verheizt hat. Platform Engineering ist die organisatorische Antwort auf genau diese Überlast – nicht auf DevOps selbst.
Das Autonomie-Paradox
Der spannendste Gedanke der aktuellen Debatte ist für mich dieser: Golden Paths schränken die Wahlfreiheit ein – und erhöhen damit die Autonomie. Klingt widersprüchlich? Ist es nicht. Ein lesenswerter Beitrag auf Java Code Geeks bringt es auf den Punkt: Es gibt zwei Sorten Freiheit – die Freiheit, die Infrastruktur beliebig zu konfigurieren, und die Freiheit, Produkt auszuliefern. Platform Engineering tauscht bewusst die erste gegen mehr von der zweiten.
Wer schon einmal in einem Unternehmen mit acht Teams und acht verschiedenen Deployment-Verfahren ein Incident-Wochenende erlebt hat, weiss, welche der beiden Freiheiten am Montag fehlt.
Bevor jetzt alle ein Plattform-Team gründen…
…kommt der Teil, den die Anbieter von Plattform-Produkten seltener zitieren. Dieselbe DORA-Forschung, die die Verbreitung misst, misst nämlich auch: Schlecht gemachte Plattformen können Durchsatz und Änderungsstabilität senken. Eine Plattform, die niemand wollte, ist kein Golden Path, sondern eine goldene Fussfessel – zentralisierte Bürokratie mit YAML-Anstrich.
Die Gegenmittel sind bekannt, und sie klingen verdächtig nach dem, was wir im Service Management seit Jahren predigen: Behandle die Plattform als Produkt mit echten Kunden. Fang mit einer minimum viable platform für den häufigsten Anwendungsfall an, nicht mit dem Fünfjahresplan. Miss Entwicklerzufriedenheit und Adoption, nicht nur Kosten. Und sorge dafür, dass die Plattform Feedback gibt – laut DORA ist «klare Rückmeldung über das Ergebnis meiner Aufgabe» die Plattform-Eigenschaft mit der stärksten Wirkung auf die Entwicklererfahrung.
An dieser Stelle schmunzle ich als ITIL-Mensch übrigens still in mich hinein: Ein Plattform-Team, das definierte Services über einen Katalog anbietet, Service Levels verspricht und seine Nutzer als Kunden begreift – das ist lupenreines Service Management. Wir nennen es nur nicht mehr so, weil es dann keiner mehr cool fände. 😊
Und wer braucht das jetzt wirklich?
Hand aufs Herz: Nicht jede Organisation. Schon beim SRE-Thema galt – wer deutlich unter hundert Engineers hat, sollte sich gut überlegen, ob er ein separates Team für irgendetwas gründet. Ein Zweierteam «Plattform» für drei Produktteams ist kein Platform Engineering, sondern ein umbenanntes Infrastruktur-Team mit neuem Backlog-Namen. Die Signale, ab wann es sich lohnt, sind ziemlich eindeutig: mehrere Teams lösen dieselben Infrastrukturprobleme unterschiedlich, das Onboarding neuer Leute dauert Wochen, und die erfahrensten Engineers verbringen ihre Zeit mit Infrastruktur-Fragen statt mit dem Produkt.
Für die Schweizer Realität mit ihren vielen mittelgrossen IT-Organisationen heisst das: Der erste Schritt ist selten ein neues Team, sondern ein ehrlicher Blick auf die kognitive Last der bestehenden Teams. Was davon ist Differenzierung, was ist Ballast? Der Ballast gehört auf einen gemeinsamen Pfad – ob den nun ein eigenes Team baut oder erstmal zwei Leute mit Produktdenken.
Mein Fazit
DevOps ist nicht tot. Platform Engineering ist DevOps, das erwachsen geworden ist: dieselben Prinzipien – Flow, Feedback, kontinuierliches Lernen – angewendet auf die eigene interne Infrastruktur, mit Produktdenken statt Projektdenken. Wer es als Ausrede benutzt, wieder ein zentrales Silo zu bauen und die Zusammenarbeit einzustellen, hat weder DevOps noch Platform Engineering verstanden – er macht das, was ich 2021 bei SRE die grosse Lüge nannte, einfach mit neuem Etikett.
Oder um im Bild meiner Artikel-Reihe zu bleiben: class PlatformEngineering extends DevOps – sie erbt alles Wesentliche und überschreibt nur, was sich in zehn Jahren als zu schwer für einzelne Teams erwiesen hat.
Quellen und weiterführende Links
- Gartner: Platform Engineering – Definition und Prognosen zur Verbreitung
- DORA: Platform Engineering Capability – Forschungsbefunde inkl. der Risiken
- Team Topologies – Skelton/Pais zum Konzept der kognitiven Last
- CNCF: What is Platform Engineering? – Begriffe IDP und Golden Path
- Java Code Geeks: Platform Engineering vs. DevOps – das Autonomie-Paradox
- Growin: Platform Engineering in 2026 – die fünf Verschiebungen im Überblick