8 Min. Lesezeit

Platform Engineering ist 2026 in der Breite angekommen. 55 Prozent der Organisationen haben ein Platform-Engineering-Team aufgebaut, bis Ende 2026 sollen es laut Gartner 80 Prozent der großen Software-Organisationen sein. Backstage dominiert den IDP-Markt mit rund 89 Prozent Anteil bei Unternehmen, die eine Internal Developer Platform produktiv betreiben. Für deutsche Cloud-Architekten bedeutet das: Die Entscheidung ist nicht mehr, ob ein IDP kommt, sondern wie schnell und mit welchem Scope.

VerwandtFinOps im Maturity-Check 2026  /  Kubernetes 1.36 Release 2026

Was Platform Engineering 2026 wirklich liefert

Was ist eine Internal Developer Platform? Eine IDP ist eine Self-Service-Schicht, die Entwicklern einen standardisierten Weg gibt, Anwendungen zu deployen, zu betreiben und zu überwachen. Sie abstrahiert die Komplexität von Kubernetes, Cloud-Infrastruktur, CI/CD-Konfiguration und Security-Policies. Für Entwickler heißt das: weniger YAML, weniger Ticket-Tanz, mehr Fokus auf Produkt. Für Ops-Teams heißt das: weniger Sonder-Deployments, durchsetzbare Defaults, reproduzierbare Setups.

Der Hintergrund der Adoption ist nicht Hype, sondern Knappheit. Infrastruktur-Expertise bleibt ein Fachkräftemangel-Thema, Entwickler sollen sich auf Business-Features konzentrieren. Gleichzeitig steigen die Compliance-Anforderungen. Die Mathematik ist simpel: Wenn ein zehn-köpfiges Platform-Team 200 Entwickler bedient, sind die Verhältnisse produktiv. Wenn jedes Feature-Team eigene Cloud-Setups betreibt, geht Zeit verloren, die nirgendwo zurückkommt.

Warum Golden Paths die wichtigste Komponente sind

Golden Paths sind vordefinierte, opinionated Workflows, die Entwickler durch die häufigsten Aufgaben führen. Ein typisches Beispiel: „Neuen Microservice erstellen“ generiert automatisch ein Git-Repository, CI/CD-Pipeline, Kubernetes-Manifeste, Monitoring-Setup und Security-Scanning. Der Entwickler muss nichts konfigurieren, die Defaults sind compliance-konform. Am Ende steht ein lauffähiger Service in Staging innerhalb weniger Minuten.

Der Unterschied zu einer simplen Dokumentation ist, dass Golden Paths ausgeführt werden. Der Entwickler klickt, die Plattform baut. Compliance-Defaults (Security-Scanner aktiviert, Network-Policies gesetzt, Logging integriert) sind automatisch drin, ohne dass das Security-Team jeden Service einzeln reviewen muss. Die Governance-Einsparung ist real: Reviews konzentrieren sich auf die Ausnahmen, nicht auf die Regel.

Der häufigste Fehler in Platform-Initiativen ist, sie als reines IT-Projekt zu betrachten. Eine Plattform ist ein Produkt. Sie braucht einen Product Owner, der Developer-Feedback sammelt, Roadmap priorisiert und Release-Zyklen plant. Organisationen, die diesen Shift vornehmen, kommen in 12 bis 18 Monaten auf belastbare Adoption. Organisationen, die die Plattform als Infrastruktur-Asset verwalten, haben nach 24 Monaten oft einen IDP, den Entwickler umgehen.

Der DIY-vs-Kauf-Entscheidungspunkt

Die Diskussion „DIY Backstage oder Managed IDP“ ist 2026 anders als noch vor zwei Jahren. Der DIY-Pfad mit Backstage Open Source ist mächtig, aber personalintensiv. Typischerweise braucht ein produktives Setup zwischen drei und sechs engagierte Engineers über mindestens zwölf Monate. Der Kauf-Pfad mit Anbietern wie Port, Roadie, Cortex, Humanitec oder Mia-Platform liefert fertige Basis-Funktionen und Golden Paths, mit Subscription-Preisen zwischen zwölf und fünfzig Euro pro Developer pro Monat.

Die Mathematik fällt oft zugunsten Managed aus. Ein Unternehmen mit 200 Entwicklern zahlt bei 30 Euro pro Head rund 72.000 Euro pro Jahr Subscription. Ein fünf-köpfiges DIY-Backstage-Team kostet in DACH zwischen 600.000 und 800.000 Euro jährlich. Wenn die Managed-Plattform 80 Prozent der eigenen Anforderungen abdeckt, ist die Entscheidung klar. Wenn nur 40 Prozent abgedeckt sind und der Custom-Teil strategisch relevant ist, wird DIY rechtfertigbar.

Ein dritter Weg ist hybrid: Managed Base-Plattform plus eigene Plugins für unternehmensspezifische Workflows. Dieser Ansatz holt die Geschwindigkeit des Managed-Pfads und vermeidet die Komplett-Abhängigkeit vom Anbieter. Für DACH-Unternehmen mit komplexer Compliance-Landschaft (NIS2, BAIT, regulatorisch sensible Daten) ist hybrid oft die praktikabelste Lösung.

In der Praxis sieht hybrid meistens so aus: Die Managed-Plattform bringt Service-Catalog, Scaffolder, Tech-Docs und Standard-Plugins mit. Das eigene Platform-Team baut zwei bis drei firmenspezifische Plugins dazu. Typische Beispiele sind Integrationen in interne Legacy-Systeme, Anbindung an spezielle Compliance-Tools oder Custom-Scaffolder für die hauseigenen Architekturstandards. Die Entwicklungs-Velocity ist höher als bei reiner DIY-Lösung, die Flexibilität ist höher als bei Full-Managed. Der Break-Even zwischen den drei Pfaden liegt meist zwischen 150 und 250 Entwicklern und entsprechender Compliance-Dichte.

Ein zusätzlicher Faktor in der Entscheidung ist die Datenlage. Eine Internal Developer Platform sammelt über die Zeit erhebliche Metadaten: Wie oft werden welche Services deployt, wer betreibt was, welche Abhängigkeiten bestehen, welche Patterns werden genutzt. Diese Daten sind für Governance, Capacity Planning und Security-Reviews Gold wert. Beim Managed-Anbieter liegen sie in der Cloud des Anbieters, bei DIY-Backstage bei dir. Für manche Compliance-Rahmen ist das ein Ausschlusskriterium, für andere ein akzeptabler Trade-off.

Wie KI-Integration die nächste Stufe verändert

Die Entwicklung zu KI-unterstützten IDPs ist 2026 im vollen Gange. 92 Prozent der CIOs planen KI-Integration in ihre Plattformen. In der Praxis bedeutet das: Natural-Language-Commands wie „Erstelle einen neuen PostgreSQL-Cluster und verbinde ihn mit der Staging-Umgebung“ werden vom IDP ausgeführt. Der Entwickler beschreibt die Intention, die Plattform mappt sie auf Golden Paths und Policies und führt die Aktion aus.

Die Chancen liegen bei Onboarding-Zeit und Self-Service-Tiefe. Neue Entwickler kommen schneller produktiv, weil sie die Plattform nicht erst erlernen müssen. Sie beschreiben ihr Anliegen, die Plattform handelt. Die Risiken liegen in der Governance. Wenn die KI falsch interpretiert oder Halluzinations-Outputs produziert, werden Ressourcen angelegt, die niemand wollte. Policy-Guards und Preview-Schritte vor Aktionen sind Pflicht.

Ein weiterer Aspekt ist die Bandbreite der Automatisierungs-Integration. Platform-Teams, die 2026 KI-Features einführen, sollten mit kleinen, reversiblen Workflows starten: Namespace-Anlage, Secrets-Rotation, Monitoring-Dashboards. Destructive Operations (Löschen, Production-Deployments) bleiben vorerst hinter manueller Bestätigung. Der Reifegrad der KI-Integration in IDPs ist Stand heute für niedrig-riskante Tasks belastbar, für Production-kritische Operationen noch nicht vollständig.

Die Auswirkung auf das Platform-Team selbst ist auch relevant. Je mehr Tasks die KI übernimmt, desto stärker verschiebt sich die Rolle der Platform-Engineers weg von direkter Ticket-Bearbeitung hin zu Policy-Design, KI-Training und Quality-Gating. Das ist eine attraktive Weiterentwicklung für technische Profile, verlangt aber Qualifikation in neuen Feldern wie Prompt-Engineering, Model-Governance und Observability für autonome Workflows. Organisationen, die diese Entwicklung antizipieren, haben im Personal-Markt einen Vorteil.

Die Security-Seite der KI-IDP-Integration ist der Punkt, der in Vorstandsvorlagen 2026 zunehmend auftaucht. Wer gibt einer KI in der Plattform welche Rechte? Wie wird der Audit-Trail geführt? Was passiert, wenn die KI halluziniert und eine falsche Ressource anlegt? Antworten auf diese Fragen müssen vor dem Rollout stehen, nicht danach. Die erfolgreichen Setups haben ein Policy-Framework, das KI-Aktionen auf definierte Bereiche begrenzt und Grenzübertretungen automatisch blockiert.

Was Cloud-Teams jetzt entscheiden

Für deutsche Cloud-Architekten und Engineering-Leiter ergibt sich eine klare Aufgabenliste. Wer bereits im Aufbau ist, sollte das Product-Mindset im Platform-Team verankern und Adoption-KPIs definieren. Wer noch evaluiert, sollte die DIY-vs-Managed-Rechnung mit konkreten Zahlen aus der eigenen Organisation machen und nicht aus generischen Marktberichten. Wer 2026 starten will, hat gerade das beste Zeitfenster: Die Tooling-Landschaft ist reif, die Anbieter sind etabliert und die Best Practices sind dokumentiert.

Parallel lohnt sich die Frage, welche organisatorische Konsequenz die IDP hat. In klassischen DevOps-Setups war jedes Feature-Team für seine eigene Infrastruktur verantwortlich, inklusive Monitoring, Scaling und Incident-Response. Eine IDP zentralisiert Teile davon im Platform-Team. Das verlangt eine klare RACI-Matrix: Wer besitzt welche Policy, wer entscheidet über Tooling-Standards, wer ist auf Call bei Plattform-Incidents. Organisationen, die diese Fragen vor dem Platform-Rollout klären, vermeiden die Konflikt-Welle, die sonst in Monat sechs kommt.

Ein weiterer struktureller Punkt ist das Verhältnis zwischen Platform-Team und Security-Organisation. Im idealen Fall sind beide eng verzahnt, mit geteilten Policies im IDP und gemeinsamen Review-Runden. In weniger idealen Fällen wird Security als Bremsklotz wahrgenommen. Das Platform-Team kann das auflösen, indem es Security-Anforderungen als Defaults in die Golden Paths eingebaut werden statt als separate Review-Pflicht. Der Effekt: Entwickler erleben Security nicht als Blocker, sondern als automatische Zutat.

Ein Punkt, der in Vorstandsvorlagen oft fehlt: Platform Engineering ist eine mehrjährige Investition. Die Kurve der Produktivitätsgewinne steigt erst nach 12 bis 18 Monaten spürbar an. Die Kosten sind in den ersten zwei Jahren durchaus real. Wer bei jedem Quartals-Review die ROI-Rechnung neu verhandeln muss, wird die Plattform nicht durchbringen. In der Realität bedeutet das: CTO und CEO müssen die Plattform-Vision mittragen, nicht nur der CIO. Platform Engineering ist eine Engineering-Investition, deren Wert sich in Developer-Produktivität und Reduktion von Coordination-Overhead manifestiert. Diese Metriken verlangen eigene Definitionen in der Organisation. Lead-Time for Changes, Deployment Frequency, Change Failure Rate und Mean Time to Recovery (DORA-Metriken) sind etablierte Kandidaten, die sich sowohl vor als auch nach dem Plattform-Rollout vergleichen lassen. Wer diese Zahlen nicht als Baseline vor dem Rollout hat, kann später keinen belastbaren Wirkungsnachweis liefern. Die erfolgreichen Setups haben ein mehrjähriges Commitment von der Geschäftsleitung. Sie berichten Fortschritt in belastbaren Metriken statt in Feature-Listen.

Häufige Fragen

Brauchen wir überhaupt ein eigenes Platform-Team bei unter 50 Entwicklern?

In der Regel nicht. Unter 50 Entwicklern reicht oft ein DevOps-Team, das klare Tooling-Standards setzt und bei Bedarf unterstützt. Die Investition in eine IDP lohnt sich bei 80 bis 100 Entwicklern aufwärts, wenn der Coordination-Overhead spürbar wird und Sonder-Setups sich mehrfach wiederholen.

Warum dominiert Backstage so stark?

Erstens Open Source mit aktiver CNCF-Community, zweitens modulare Plugin-Architektur, drittens First-Mover-Advantage aus dem Spotify-Kontext. Die Alternative Port, Cortex oder Humanitec haben bessere Out-of-the-Box-Experience, sind aber proprietär und erzeugen andere Lock-in-Profile.

Wie unterscheidet sich eine IDP von einer Cloud-Foundation oder Landing Zone?

Die Landing Zone ist die darunterliegende Cloud-Architektur (Netzwerk, Accounts, Identity). Die IDP sitzt darauf und liefert den Entwickler-zugewandten Self-Service-Layer. Beide Ebenen sind nötig, die Landing Zone ist in den meisten Unternehmen schon da, die IDP ist der nächste Schritt.

Wie starte ich konkret in den ersten 90 Tagen?

Mit drei Golden Paths, die die häufigsten Use Cases abdecken (neuer Microservice, neue Datenbank, neues API-Gateway). Parallel Backstage aufsetzen oder einen Managed-Anbieter evaluieren. Messen ab Tag eins, wie viele Teams die Golden Paths tatsächlich nutzen und wo sie daran vorbei arbeiten.

Wer sollte im Platform-Team sitzen?

Mix aus Infrastructure-Engineer, Frontend-Entwickler (für Backstage-Frontend), Product Owner mit Developer-Experience-Fokus und mindestens einem Security-Liaison. Eine Größenordnung von fünf bis acht Personen für den Aufbau, danach reduziert auf drei bis fünf für den Betrieb. Die wichtigste Eigenschaft ist Empathie für die Developer-Zielgruppe.

Mehr aus dem MBF Media Netzwerk

Quelle Titelbild: Pexels / ThisIsEngineering (px:3912478)