6 Min. Lesezeit

Platform Engineering hat sich vom Buzzword zum Betriebsmodell entwickelt. Laut dem aktuellen State of Platform Engineering Report betreiben 55,9 Prozent der befragten Unternehmen bereits mehr als eine interne Entwicklerplattform. Gartner prognostiziert, dass bis Ende 2026 rund 80 Prozent der großen Engineering-Organisationen Platform-Teams etabliert haben werden. Gleichzeitig zeigt sich eine ernüchternde Lücke: Fast 30 Prozent der Teams messen ihren Erfolg gar nicht.

Das Wichtigste in Kürze

• 55,9 Prozent der Unternehmen betreiben mehr als eine interne Plattform (State of Platform Engineering Vol. 4, Januar 2026).
• 80 Prozent der großen Engineering-Organisationen werden bis Ende 2026 Platform-Teams haben (Gartner).
• 29,6 Prozent der Platform-Teams messen ihren Erfolg nicht. Der ROI-Nachweis bleibt die größte Schwäche.
• 94 Prozent sehen KI als kritisch für die Zukunft von Platform Engineering.
• Backstage (Spotify), Humanitec und Port sind die meistgenutzten Frameworks im DACH-Raum.

Was Platform Engineering ist und warum es DevOps ablöst

Platform Engineering beschreibt den Ansatz, interne Entwicklerplattformen (Internal Developer Platforms, IDPs) zu bauen und zu betreiben. Statt dass jedes Entwicklerteam seine eigene Infrastruktur konfiguriert, stellt ein zentrales Platform-Team standardisierte Self-Service-Werkzeuge bereit, die den gesamten Entwicklungszyklus abdecken: CI/CD-Pipelines, Kubernetes-Namespaces, Datenbanken, Monitoring-Dashboards.

Der Unterschied zu klassischem DevOps: DevOps hat die Silos zwischen Entwicklung und Betrieb aufgelöst, aber eine neue Last geschaffen. Entwicklerteams mussten plötzlich Terraform-Konfigurationen, Helm-Charts und Monitoring-Setups selbst verwalten. Platform Engineering kehrt diese kognitive Überlastung um: Das Platform-Team abstrahiert die Komplexität und die Entwickler nutzen eine definierte Schnittstelle.

Im DACH-Raum setzen Unternehmen wie die Deutsche Telekom, Siemens und BMW bereits auf interne Plattformen. Der Treiber ist pragmatisch: Entwicklerproduktivität steigern, Onboarding-Zeiten verkürzen und Compliance-Anforderungen zentral abbilden.

Was der State of Platform Engineering Report zeigt

Der vierte State of Platform Engineering Report, veröffentlicht im Januar 2026, basiert auf Befragungen von 518 Ingenieuren weltweit. Die Kernergebnisse:

Mehr als die Hälfte der Unternehmen betreibt bereits mehrere Plattformen, aufgeteilt nach Teams: Frontend, Backend, Data und KI. Das widerspricht der verbreiteten Annahme, dass eine einzige Plattform alle Bedürfnisse abdecken sollte. In der Praxis spezialisieren sich Plattformen entlang der Wertschöpfungskette.

Die größte Überraschung: 29,6 Prozent der Platform-Teams messen ihren Erfolg überhaupt nicht. Kein DORA-Metriken-Tracking (Deployment Frequency, Lead Time, Change Failure Rate), keine Entwicklerzufriedenheit, kein Kosten-Benchmarking. Für IT-Leiter, die vor dem CIO den Wert der Plattform-Investition rechtfertigen müssen, ist das ein strukturelles Problem.

94 Prozent der Befragten sehen KI als kritisch für die Zukunft von Platform Engineering. Konkret geht es um drei Anwendungsfälle: KI-gestützte Fehlerdiagnose in Produktionspipelines, automatische Konfigurationsgenerierung für neue Services und intelligente Empfehlungen für Security-Policies.

Das ROI-Problem: Warum Platform-Teams ihren Wert nicht beweisen können

Die 29,6 Prozent ohne Erfolgsmessung sind kein Randphänomen. Sie spiegeln ein grundlegendes Dilemma wider: Platform Engineering erzeugt indirekte Wertschöpfung. Die Plattform selbst generiert keinen Umsatz. Sie beschleunigt die Teams, die Umsatz generieren. Diese indirekte Wirkung ist schwer zu quantifizieren.

Unternehmen, die den ROI erfolgreich nachweisen, nutzen typischerweise drei Metriken:

Onboarding-Zeit. Wie lange braucht ein neuer Entwickler, bis er den ersten produktiven Code deployen kann? Unternehmen mit ausgereiften IDPs berichten von einer Reduktion von Wochen auf Stunden.

Deployment Frequency. Wie oft deployen Teams pro Tag oder Woche? Die DORA-Metriken (DevOps Research and Assessment) bieten hier einen anerkannten Benchmark.

Infrastruktur-Self-Service-Quote. Wie viel Prozent der Infrastruktur-Anfragen lösen Entwickler selbstständig über die Plattform, ohne ein Ticket an das Ops-Team zu stellen?

„Der Wert einer internen Plattform zeigt sich nicht in der Plattform selbst, sondern in der Geschwindigkeit der Teams, die sie nutzen.“
– platformengineering.org, State of Platform Engineering Vol. 4 (sinngemäß)

Die drei gängigsten Plattform-Frameworks

Backstage (Spotify). Open-Source-Framework für Developer Portals. Backstage bietet einen Software-Katalog, Templates für neue Services und ein Plugin-System. Große DACH-Unternehmen wie Siemens und die Deutsche Telekom nutzen Backstage als Basis für ihre internen Plattformen.

Humanitec. Ein Berliner Unternehmen, das mit dem Score-Format einen offenen Standard für Plattform-Konfigurationen entwickelt hat. Humanitec positioniert sich als die Schicht zwischen CI/CD und Cloud-Infrastruktur. Vorteil: weniger Custom-Code als bei Backstage.

Port. Internal Developer Portal as a Service. Port bietet ein fertiges Portal mit Self-Service-Aktionen, Scorecard-Tracking und einem Marketplace für interne Dienste. Geeignet für Teams, die schnell starten wollen, ohne ein Portal von Grund auf zu bauen.

KI und Platform Engineering: Warum 94 Prozent den Umbruch sehen

Die hohe Zahl überrascht nicht, wenn man die konkreten Anwendungsfälle betrachtet. KI verändert Platform Engineering auf drei Ebenen.

Automatische Fehlerbehebung. Wenn eine CI/CD-Pipeline fehlschlägt, analysiert ein KI-Agent die Logs, identifiziert die Ursache und schlägt einen Fix vor. GitHub Copilot Workspace und ähnliche Tools zeigen, wie das in der Praxis aussehen kann. Für Platform-Teams bedeutet das: weniger Tickets, schnellere Auflösung, mehr Self-Service.

Konfigurations-Generierung. Statt dass Entwickler manuell Helm-Charts oder Terraform-Module schreiben, beschreibt ein KI-Agent die gewünschte Infrastruktur in natürlicher Sprache und generiert die passende Konfiguration. Das senkt die Einstiegshürde für weniger erfahrene Entwickler erheblich.

Security-Policy-Empfehlungen. KI-gestützte Plattformen können Code-Repositories scannen und automatisch Empfehlungen für Netzwerk-Policies, RBAC-Rollen und Secret-Management aussprechen. Statt reaktiver Security-Reviews entsteht ein proaktiver Compliance-Layer, der in die Plattform eingebaut ist.

Der kritische Punkt: KI in der Plattform muss deterministisch und nachvollziehbar sein. Ein KI-generierter Helm-Chart, der in Produktion deployed wird, muss reviewbar sein. Platform-Teams, die KI einsetzen, brauchen klare Guardrails für die Validierung KI-generierter Konfigurationen.

Platform Engineering im DACH-Mittelstand: Andere Spielregeln

Die großen Reports stammen überwiegend aus dem US-amerikanischen und britischen Markt. Für den deutschen Mittelstand gelten andere Rahmenbedingungen.

Regulatorische Anforderungen wie NIS2, DORA und die DSGVO erzeugen einen zusätzlichen Treiber für Platform Engineering: Compliance-Anforderungen zentral in der Plattform abzubilden statt in jedem Team einzeln umzusetzen. Ein gut konfiguriertes IDP kann automatisch erzwingen, dass Logs 90 Tage aufbewahrt werden, dass Secrets nicht im Code landen und dass Container nur aus verifizierten Registries gezogen werden.

Gleichzeitig sind die Platform-Teams im Mittelstand deutlich kleiner als bei Tech-Konzernen. Zwei bis drei Ingenieure statt zehn bis zwanzig. Das spricht für kommerzielle Lösungen wie Humanitec oder Port gegenüber dem Engineering-intensiven Backstage. Die Entscheidung zwischen Build und Buy ist im Mittelstand anders gewichtet als bei einem Konzern mit 500 Entwicklern.

Was IT-Leiter jetzt tun sollten

Platform Engineering ist kein Hype mehr. Die Frage ist nicht ob, sondern wie. Drei konkrete Empfehlungen für IT-Leiter, die eine Plattform-Strategie aufbauen wollen:

Klein starten. Nicht mit einer unternehmensweiten Plattform beginnen. Einen Anwendungsfall wählen, z.B. das Onboarding neuer Microservices und dort den Wert nachweisen. Dann skalieren.

Messen ab Tag eins. Onboarding-Zeit, Deployment Frequency und Self-Service-Quote als KPIs definieren, bevor die Plattform gebaut wird. Nur so lässt sich der Vorher-Nachher-Effekt zeigen.

Platform-Team als Produktteam. Das Platform-Team behandelt die IDP wie ein internes Produkt. Die Entwickler sind die Kunden. Feedback-Schleifen, Roadmap-Planung und User Research sind nicht optional.

Fazit

Platform Engineering ist der logische nächste Schritt nach DevOps. Die Zahlen zeigen, dass die Adoption schneller wächst als erwartet, aber die Professionalisierung hinterherhinkt. Wer eine Plattform baut, ohne den Erfolg zu messen, riskiert ein teures Infrastrukturprojekt ohne nachweisbaren Geschäftswert. Wer hingegen mit klaren KPIs startet und die Plattform als Produkt behandelt, schafft einen messbaren Hebel für Entwicklerproduktivität und Time-to-Market.

Für den DACH-Mittelstand kommt ein weiterer Faktor hinzu: Compliance. NIS2, DORA und die DSGVO machen zentrale Sicherheitsstandards zur Pflicht. Eine gut gebaute Plattform kann diese Anforderungen einmal implementieren und für alle Teams erzwingen. Das spart nicht nur Entwicklerzeit, sondern auch Audit-Aufwand. Platform Engineering ist damit nicht nur ein Produktivitätswerkzeug, sondern auch ein strategisches Compliance-Instrument für regulierte Branchen.

Häufige Fragen

Was ist der Unterschied zwischen Platform Engineering und DevOps?

DevOps ist eine Kultur und Praxis, die Entwicklung und Betrieb zusammenbringt. Platform Engineering baut darauf auf und stellt zentrale Self-Service-Werkzeuge bereit, damit Entwicklerteams nicht jede Infrastruktur-Aufgabe selbst lösen müssen. Platform Engineering ist die Produktisierung von DevOps.

Braucht jedes Unternehmen ein Platform-Team?

Nicht zwingend. Für Unternehmen mit weniger als 50 Entwicklern ist der Overhead eines eigenen Platform-Teams oft zu hoch. Ab 50 bis 100 Entwicklern lohnt sich die Investition in der Regel, weil die Produktivitätsgewinne die Kosten übersteigen.

Was kostet eine interne Entwicklerplattform?

Die Kosten variieren stark. Ein kleines Platform-Team (2 bis 3 Ingenieure) plus Open-Source-Tools wie Backstage liegt bei 200.000 bis 400.000 Euro pro Jahr. Kommerzielle Lösungen wie Humanitec oder Port kosten je nach Nutzerzahl zwischen 50.000 und 200.000 Euro jährlich.

Ist Backstage die beste Wahl für den Einstieg?

Backstage ist das flexibelste Framework, erfordert aber erheblichen Engineering-Aufwand für Setup und Plugins. Für Teams, die schnell produktiv werden wollen, sind Port oder Humanitec oft die bessere Wahl. Backstage eignet sich für Unternehmen, die eine hochgradig angepasste Plattform aufbauen wollen.

Wie misst man den Erfolg einer internen Plattform?

Die drei wichtigsten Metriken: Onboarding-Zeit für neue Entwickler (Stunden statt Wochen), Deployment Frequency (wie oft Teams deployen) und Self-Service-Quote (wie viel Prozent der Anfragen ohne Ops-Ticket gelöst werden). DORA-Metriken bieten zusätzlich einen anerkannten Branchenbenchmark.

Weiterführende Artikel

• Kubernetes Cluster-Governance im Mittelstand – Warum Kontrolle wichtiger wird als Skalierung (cloudmagazin)
• FinOps – Wie Unternehmen Cloud-Kosten endlich in den Griff bekommen (cloudmagazin)
• DevSecOps im Aufwind – Wie deutsche Softwareteams Security in die Pipeline bringen (cloudmagazin)

Mehr aus dem MBF Media Netzwerk

• Edge Computing – Warum die Cloud für den Mittelstand nicht immer reicht (MyBusinessFuture)
• Cloud-Repatriation 2026 – Warum CIOs Workloads zurückholen (Digital Chiefs)

Quelle Titelbild: ThisIsEngineering / Pexels