Platform
Engineering:
IDP aufbauen.
Was Platform Engineering ist, aus welchen Bausteinen eine Internal Developer Platform besteht, wie Sie sie in fünf Schritten aufbauen und woran solche Plattformen scheitern. Am Ende steht, was davon in der Fabrik trägt, wo IT und OT an derselben Software arbeiten.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Was ist Platform Engineering?
Platform Engineering ist der Aufbau und Betrieb einer internen Entwicklerplattform (Internal Developer Platform, IDP). Über sie holen sich Entwicklerteams Infrastruktur, Pipelines und Monitoring per Self-Service, statt jedes Mal eine eigene Toolchain zu bauen. Das senkt die kognitive Belastung (Cognitive Load) der Teams. Das interne Entwicklerportal ist die Oberfläche dieser Plattform, bekannte Portale sind Backstage, Port und Cortex.
Stand: 18. Oktober 2026 · Backstage 1.55 · CNCF Platform Engineering Maturity Model · DORA-Report 2025
Das Problem dahinter kennen wir aus vielen Projekten. Nach zwei, drei Jahren DevOps pflegt jedes Team seine eigene Pipeline, seinen eigenen Helm Chart und seine eigene Ecke im Monitoring. Wer ein neues Team einarbeitet, zeigt ihm nicht einen Weg, sondern sieben, und jeder davon hängt an einer anderen Person.
Platform Engineering zieht daraus eine einfache Konsequenz. Aus „You build it, you run it“ wird „You build it, we make it easy to run it“. Ein eigenes Team, das Platform Team, baut die gemeinsamen Wege und behandelt die Plattform als internes Produkt. Es hat eine Roadmap, die Entwicklerteams sind seine Kunden, und sein Erfolg misst sich daran, wie viele Teams die Plattform freiwillig nutzen.
Die Begriffe Platform Team und Thinnest Viable Platform stammen aus dem Buch Team Topologies von Matthew Skelton und Manuel Pais. Dass der Teamschnitt am Ende die Architektur bestimmt, beschreibt Conway’s Law. Wie sich Teams danach schneiden lassen, begleiten wir im DevOps Coaching. Die Kurzdefinition steht im Glossar unter Platform Engineering.
Den Teams den richtigen Weg so leicht machen, dass sie ihn freiwillig gehen.
Für Industrial DevOps ist das doppelt interessant. Im Werk liefert die IT mehrmals pro Woche aus, während die Automatisierung ihre SPS-Stände noch per Projektarchiv verteilt. Eine Plattform ist der Ort, an dem beide denselben Weg nutzen. Wie das aussieht, zeigt Abschnitt 10.
Quellen: DORA, Capability Platform Engineering. Gartner hatte 2022 vorhergesagt, dass bis 2026 rund 80 % der großen Software-Engineering-Organisationen Platform Teams aufbauen. DORA misst 2025 bereits 76 %. Teamgröße und Verhältnis sind Erfahrungswerte aus unseren Projekten.
Ist Platform Engineering bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Welches Problem löst Platform Engineering?
Platform Engineering löst das Skalierungsproblem von DevOps. „You build it, you run it“ funktioniert, solange ein Team überschaubar viel betreibt. Mit jedem neuen Werkzeug wächst aber, was ein Entwickler im Kopf haben muss: Kubernetes, Pipeline-Syntax, Monitoring, Security-Scanner, Infrastructure as Code.
Im Alltag sieht das unspektakulär aus. Ein Entwickler verbringt einen Nachmittag damit, herauszufinden, warum die Pipeline des Nachbarteams anders signiert als die eigene. Ein Cluster-Update später lässt sich die Staging-Umgebung nicht mehr nachbauen, weil die Hälfte davon einmal von Hand eingerichtet wurde und das nirgends steht.
AIOhne Platform Engineering
- Jedes Team baut seine Pipelines selbst
- Deployment-Wege unterscheiden sich von Team zu Team
- Entwickler verbringen Stunden mit YAML statt mit Fachlogik
- Umgebungen kommen per Ticket, nach Tagen
- Wissen steckt in einzelnen Köpfen
Mit Platform Engineering
- Standardisierte Pipelines als Self-Service
- Golden Paths für die häufigsten Aufgaben
- Entwickler arbeiten an der Fachlogik
- Umgebungen in Minuten statt Tagen
- Wissen steckt in der Plattform, versioniert in Git
Was unterscheidet Platform Engineering von DevOps und SRE?
DevOps liefert die Kultur, Platform Engineering die Werkzeuge und Site Reliability Engineering (SRE) die Zuverlässigkeit im Betrieb. Die drei ersetzen einander nicht, sie beantworten verschiedene Fragen.
Platform Engineering ist deshalb auch kein Nachfolger von DevOps. Es setzt die DevOps-Praxis voraus und nimmt den Teams den Unterbau ab, den bisher jedes Team für sich gebaut hat. Wie sich das verschiebt, wenn Steuerungen und SPS-Projekte dazukommen, ordnet unser Artikel DevOps vs. Platform Engineering in der Industrie ein.
Im Mittelstand übernimmt oft ein einziges Team alle drei Rollen. Es treibt die DevOps-Kultur, baut die Plattform und hält die Produktion stabil. Die Trennung ist eine gedankliche, keine organisatorische. Wichtig ist nur, dass jemand bewusst an der Plattform arbeitet und nicht bloß an Toil, der manuellen Routinearbeit, die sich endlos wiederholt.
Aus welchen Bausteinen besteht eine interne Entwicklerplattform?
Eine Internal Developer Platform besteht aus fünf Bausteinen: Provisioning, Deployment Pipelines, Observability, Security Guardrails und dem Developer Portal. Kaum ein Unternehmen braucht alle fünf vom ersten Tag an.
Fangen Sie dort an, wo die Teams am meisten Zeit verlieren. Die Abbildung zeigt, wie die Schichten übereinanderliegen. In der Liste darunter steht zu jedem Baustein, welche Werkzeuge typisch sind und wie er in der Fabrik aussieht.
- /01
Infrastructure Provisioning
Umgebungen und Cloud-Ressourcen per Self-Service.
Ein Team fordert eine Umgebung, Datenbank oder Message Queue an und hat sie nach Minuten, weil die Plattform sie aus deklarativen Modulen erzeugt. Crossplane bildet Cloud-Ressourcen als Kubernetes-Objekte ab und passt, wenn die Plattform ohnehin auf Kubernetes steht. Terraform deckt zusätzlich VMs, Netzwerk und Geräte außerhalb des Clusters ab.
Typische Tools: Terraform, OpenTofu, Crossplane, Pulumi
In der Fabrik: Testanlage, virtuelle SPS oder Edge-Gateway für ein Projekt bereitstellen
- /02
Deployment Pipelines
CI/CD als wiederverwendbare Vorlage.
Alle Teams nutzen dieselben Quality Gates, Security-Checks und Rollout-Strategien. Wer eine neue Pipeline braucht, bindet die Vorlage ein und schreibt sie nicht von vorn.
Typische Tools: Jenkins Shared Libraries, GitLab CI Templates, GitHub Actions, Argo CD
In der Fabrik: SPS-Projekt bauen, gegen die virtuelle Steuerung testen, im Wartungsfenster ausrollen
- /03
Observability
Monitoring, Logging und Tracing als Dienst.
Teams instrumentieren ihre Services mit wenigen Zeilen und bekommen Dashboards und Alerts, die schon eingerichtet sind. Einen eigenen Monitoring-Stack pro Team gibt es nicht mehr.
Typische Tools: Prometheus, Grafana, OpenTelemetry, Datadog
In der Fabrik: Maschinen- und Pipeline-Daten über OPC UA oder MQTT im selben Dashboard
- /04
Security Guardrails
Policy-as-Code statt Freigabe per E-Mail.
Schwachstellen-Scans und Compliance-Regeln laufen in jeder Pipeline mit. Ein Verstoß stoppt den Build, bevor er in Produktion kommt, und nicht erst im nächsten Audit.
Typische Tools: OPA/Gatekeeper, Kyverno, Trivy, Snyk
In der Fabrik: Prüfregeln aus IEC 62443, etwa welche Zone mit welcher sprechen darf
- /05
Developer Portal
Die Startseite der Plattform.
Service-Katalog, Dokumentation, API-Referenzen, Templates und Ownership an einer Stelle. Das Portal zeigt, was existiert und wem es gehört. Die Arbeit erledigen die Bausteine darunter.
Typische Tools: Backstage, Port, Cortex, OpsLevel
In der Fabrik: Anlagenkatalog: welcher Softwarestand läuft auf welcher Linie, wer hat ihn freigegeben
Internes Entwicklerportal oder interne Entwicklerplattform?
Das interne Entwicklerportal ist die Oberfläche, die interne Entwicklerplattform (Internal Developer Platform, IDP) der Unterbau, und Platform Engineering die Disziplin, die beides als Produkt betreibt. Wer nur das Portal einführt, bekommt einen Katalog ohne Knöpfe. Wer nur die Plattform baut, hat Self-Service-APIs, die niemand findet.
Die Frage kommt meist in derselben Lage auf. Ein Team hat ein Developer Portal evaluiert, die Demo hat überzeugt, und dann zeigt sich, dass hinter den Templates noch nichts steht, was sie ausführen könnte. Die Reihenfolge lautet deshalb fast immer: erst der Golden Path, der wirklich automatisiert, dann das Portal darüber.
AI- /01
Internes Entwicklerportal
Die Oberfläche.
Service-Katalog, Software-Templates, Dokumentation, Ownership und Scorecards an einer Stelle. Das Portal zeigt, was existiert, wem es gehört und welcher Weg empfohlen ist. Ausgeführt wird die Aktion eine Schicht tiefer.
Typisch: Backstage, Port, Cortex, OpsLevel
- /02
Interne Entwicklerplattform (IDP)
Der Unterbau.
Englisch Internal Developer Platform. Sie ist das, was tatsächlich passiert, wenn jemand im Portal auf „Service anlegen“ klickt: Provisioning, Pipelines, Policies, Observability. Die IDP funktioniert auch ohne Portal, dann über Repository-Templates und eine Kommandozeile.
Typisch: Crossplane, Terraform, Argo CD, Kyverno, OpenTelemetry
- /03
Platform Engineering
Die Disziplin.
Das Team, das beides als internes Produkt betreibt, mit Roadmap, internen Kunden, gemessener Adoption und Betrieb. Fehlt diese Rolle, veraltet die Plattform binnen eines Jahres, weil niemand die Templates nachzieht.
Typisch: Produktverantwortung, Roadmap, Adoption-Metriken, SLAs
Wofür steht IDP im Platform Engineering?
Im Platform Engineering steht IDP für Internal Developer Platform, also die interne Entwicklerplattform. Die zweite Bedeutung stammt aus der IT-Sicherheit. Dort meint IdP den Identity Provider, den Dienst, der Anmeldungen per SAML oder OIDC ausstellt. Beide begegnen Ihnen im selben Stack und haben nichts miteinander zu tun.
Die Verwechslung kostet echte Zeit. Wer im Architektur-Meeting „wir brauchen einen IDP“ sagt, meint je nach Sitznachbar eine Self-Service-Plattform oder Keycloak. Schreiben Sie die Abkürzung beim ersten Auftreten aus. Das kostet vier Wörter und spart eine halbe Sitzung. Beide Begriffe sauber getrennt finden Sie unter Internal Developer Platform (IDP) im Glossar.
Ein Portal beantwortet die Frage „Welche Services gibt es, und wem gehören sie?“ Eine Plattform beantwortet „Wie bekomme ich in zehn Minuten einen neuen Service, der die Compliance-Regeln erfüllt?“ Welches Portal die richtige Basis ist, hängt weniger an der Feature-Liste als am Betriebsaufwand. Die Vor- und Nachteile von Backstage gegenüber Port und Cortex haben wir im Anwendungsfall für IT-Unternehmen nebeneinandergelegt.
Was ist ein Golden Path?
Ein Golden Path ist der empfohlene, fertig gebaute Weg für eine häufige Aufgabe, etwa einen neuen Service anlegen oder eine Datenbank bereitstellen. Netflix nennt dasselbe Prinzip Paved Road. Teams dürfen abweichen, der Weg ist aber so bequem, dass die meisten ihn freiwillig nehmen.
Guardrails sind die Regeln daneben: Policies, Security-Checks und Compliance-Vorgaben, die die Plattform automatisch prüft. Sie halten niemanden auf, der auf dem Weg bleibt. Sie greifen erst, wenn eine Änderung etwas Gefährliches tun würde, etwa ein Image ohne Signatur ausrollen.
Drei aus der IT, einer aus der Automatisierung. Der vierte zeigt, dass das Prinzip nicht an Kubernetes hängt.
- /01
Neuen Microservice anlegen
- 01Template im Developer Portal auswählen
- 02Repository entsteht mit Pipeline, Dockerfile und Helm Chart
- 03Erste Pipeline läuft, der Service steht in Staging
- 04Dashboard und Alerts sind schon eingerichtet
- /02
Datenbank bereitstellen
- 01Formular: Typ, Größe, Region
- 02Ein Terraform-Modul legt die Datenbank an
- 03Zugangsdaten landen im Secret-Manager
- 04Backup-Policy und Monitoring sind aktiv
- /03
Vorschau-Umgebung pro Pull Request
- 01Pull Request öffnen
- 02Die Plattform baut eine Vorschau-Umgebung
- 03Die URL steht als Kommentar im Pull Request
- 04Nach dem Merge wird die Umgebung wieder gelöscht
- /04
SPS-Änderung auf eine Linie bringen
- 01Änderung im Git-Branch des SPS-Projekts
- 02Pipeline übersetzt und testet gegen eine virtuelle Steuerung, etwa PLCSIM Advanced
- 03Schichtleitung gibt im Portal frei, Freigabe und Prüfbericht werden gespeichert
- 04Rollout im Wartungsfenster, der Softwarestand ist pro Anlage dokumentiert
Hinter vielen dieser Wege steht GitOps mit Argo CD. Die Plattform schreibt den gewünschten Zustand in Git, und Argo CD gleicht ihn mit dem Cluster ab, über App-of-Apps, ApplicationSets und Multi-Cluster-Sync. Typische Fehlerbilder wie OutOfSync-Zustände oder falsch gesetzte Sync-Waves behandeln wir im Workshop ArgoCD & GitOps mit KI.
Wie baue ich eine Internal Developer Platform auf?
In fünf Schritten, klein beginnend und an echter Nachfrage entlang: Engpässe erfassen, die kleinste nützliche Plattform festlegen, ein Platform Team benennen, den ersten Golden Path automatisieren, dann messen und ausbauen. Das Portal kommt erst, wenn hinter ihm etwas funktioniert.
Der teuerste Fehler ist der große Wurf. Zwölf Monate entsteht eine Plattform, die kein Team bestellt hat, und dann nimmt das erste Pilotteam sie nicht an. Die fünf Schritte unten setzen deshalb bei einem Engpass und einem Team an.
AI- /01
Engpässe erfassen
Fragen Sie Ihre Teams, wo sie Zeit verlieren, was sich wiederholt und worauf sie warten. Zählen Sie nach, wie lange ein neues Team bis zum ersten Deployment in Produktion braucht. Diese eine Zahl ist später Ihr wichtigster Vergleichswert.
- /02
Thinnest Viable Platform festlegen
Der Begriff stammt aus Team Topologies und meint die kleinste Plattform, die Teams wirklich entlastet. Suchen Sie den einen Engpass, der die meisten Teams trifft, und lösen Sie ihn zuerst. In IT-Organisationen ist das oft die Bereitstellung von Umgebungen, in der Fertigung meist die Versionierung der SPS-Projekte.
- /03
Platform Team benennen
Zwei bis vier Personen, die ausschließlich an der Plattform arbeiten und die Entwicklerteams als Kunden behandeln, mit Roadmap, Feedback-Runden und Zusagen zur Verfügbarkeit. Wer das Team nebenbei Tickets abarbeiten lässt, bekommt keine Plattform.
- /04
Ersten Golden Path automatisieren
Bauen Sie den einfachsten Weg, einen neuen Service anzulegen und auszurollen, und zwar vollständig automatisiert. Der Weg muss so bequem sein, dass Teams ihn freiwillig nehmen. Das Portal kommt danach.
- /05
Messen und ausbauen
Verfolgen Sie Adoption, Time-to-First-Deploy und die Zufriedenheit der Teams. Ausgebaut wird, was die Teams nachfragen, nicht was im Architekturdiagramm gut aussieht.
Wo steht Ihre Organisation heute?
Das Platform Engineering Maturity Model der CNCF unterscheidet vier Stufen von Provisional bis Optimizing. Es bewertet fünf Aspekte getrennt, nämlich Investment, Adoption, Interfaces, Operations und Measurement, denn kaum eine Organisation ist überall gleich weit. Bei den Schnittstellen kann schon Self-Service laufen, während die Messung noch fehlt.
Quelle: CNCF TAG App Delivery, Platform Engineering Maturity Model. In unseren Projekten erreichen mittelständische Unternehmen die Stufe Scalable bei den Schnittstellen typischerweise nach 12 bis 18 Monaten.
Ab welcher Größe lohnt sich eine eigene Plattform?
Nach unserer Erfahrung ab etwa fünf Produktteams oder 30 Entwicklern. Darunter reicht meist ein Repository mit CI/CD-Templates und Infrastructure-as-Code-Modulen, das ein erfahrener Kollege mitpflegt. Für das erste Platform Team planen wir zwei bis vier Personen, später einen Platform Engineer auf 10 bis 15 Anwendungsentwickler. Ab etwa 50 Entwicklern kommt jemand dazu, der die Plattform als Produkt verantwortet.
Wer vor Schritt 1 wissen will, wo das eigene Team insgesamt steht, beginnt mit dem DevOps-Reifegrad-Check.
3 Minuten · ohne Anmeldung · Ergebnis sofort
Woran erkennen Sie, dass die Plattform wirkt?
Eine Plattform wirkt, wenn Teams sie freiwillig nutzen und schneller in Produktion kommen. Messen Sie dafür die Adoption, die Zeit bis zum ersten Deployment eines neuen Teams, die vier DORA-Metriken und regelmäßig die Zufriedenheit der Entwickler, etwa nach dem SPACE-Framework.
AIEine Entwicklerin braucht eine Testumgebung, klickt sie sich selbst zusammen und hat sie nach acht Minuten. Vorher war das ein Ticket und drei Tage Warten. In den Kennzahlen zeigt sich das erst nach Wochen, die Nachbarteams fragen noch am selben Tag, wann sie dazukommen.
Neu im DORA-Report 2025 ist der Zusammenhang mit KI. Bei hoher Plattformqualität wirkt sich der Einsatz von KI-Assistenten deutlich positiv auf die Leistung der Organisation aus, bei niedriger Qualität kaum. Die Plattform entscheidet also mit, ob Coding-Agenten Zeit sparen oder nur schneller Unordnung erzeugen. Details zu den Kennzahlen stehen in unserem Artikel DORA-Metriken messen.
Die Plattform liefert die Werkzeuge. Genutzt werden sie nur, wenn die Teams sich trauen, Fehler offen anzusprechen. Mehr dazu unter DevOps-Kultur mit psychologischer Sicherheit und Fehlerkultur.
Woran scheitern interne Entwicklerplattformen?
Selten an der Technik. Interne Entwicklerplattformen scheitern meist daran, dass sie am Bedarf der Teams vorbei gebaut, als Pflicht verordnet oder nach dem Start nicht weiter gepflegt werden.
Die fünf Muster unten begegnen uns in Projekten immer wieder. Keines davon fällt erst nach einem Jahr auf. Wer weiß, worauf er achten muss, sieht jedes schon in den ersten Wochen.
- /01
Das Portal kommt zuerst
Ein Katalog ohne Knöpfe.
Die Demo eines Developer Portals überzeugt in einer Stunde. Steht dahinter kein automatisierter Weg, öffnen die Teams das Portal zweimal und schreiben danach wieder Tickets.
BesserErst den Golden Path automatisieren, dann die Oberfläche darüber bauen.
- /02
Der große Wurf
Zwölf Monate Bauzeit, kein Pilotteam.
Ein Plattform-Programm mit Architekturdiagramm, Lenkungskreis und Ausschreibung, aber ohne ein Team, das die erste Version nutzt. Bis zum Start haben sich die Teams längst eigene Lösungen gebaut.
BesserMit einem Pilotteam und einem Engpass beginnen und nach sechs bis acht Wochen das erste Ergebnis zeigen.
- /03
Pflicht statt Angebot
Wer muss, baut sich einen Umweg.
Wird die Plattform per Anordnung zur einzigen Option, entstehen Schatten-Pipelines auf eigenen Runnern, die niemand sieht. Die Adoption steht dann auf dem Papier, gearbeitet wird woanders.
BesserDen Golden Path so bequem bauen, dass Abweichen mehr Arbeit macht als Mitgehen. Verpflichtend sind nur die Guardrails, die Sicherheit oder Compliance verlangen.
- /04
Das Ticket-Team mit neuem Namen
Aus Ops wird Platform, die Warteschlange bleibt.
Das Platform Team arbeitet nebenher das alte Ops-Backlog ab. Für Self-Service bleibt keine Zeit, und nach einem Jahr ist die Plattform eine weitere Ticketkategorie.
BesserDas Team fest besetzen und jede Anfrage, die zum dritten Mal kommt, als Kandidaten für den nächsten Golden Path behandeln.
- /05
Niemand misst
Ohne Zahl kein Budget im zweiten Jahr.
Knapp ein Drittel der Plattform-Teams misst den eigenen Erfolg gar nicht, so die Auswertung des vierten State of Platform Engineering Report (platformengineering.org, 2026). In der Budgetrunde fehlt dann die Antwort auf die Frage, was die Plattform gebracht hat.
BesserVor dem Start die Zeit bis zum ersten Deployment eines neuen Teams messen und danach jedes Quartal wieder.
Quelle zu /05: State of Platform Engineering Report, Vol. 4, Befragung von über 500 Platform Engineers. Die übrigen Muster sind Erfahrungswerte aus unseren Projekten.
AIDORA beschreibt für Plattformen eine J-Kurve. Nach einem ersten Gewinn sinkt die Leistung, sobald die Plattform komplexer wird, und steigt erst wieder, wenn sie reifer ist. Der DORA-Report 2024 fand dazu passend, dass Plattformen die Produktivität heben, Durchsatz und Stabilität der Änderungen aber sinken können, wenn niemand die Plattform selbst gut betreibt. Eine Plattform ist Software, und schlechte Software bremst. Wer die Delle kennt, bricht im dritten Monat nicht ab, sondern schaut, welcher Golden Path gerade hakt.
Was bringt Platform Engineering in der Fabrik?
In der Industrie bringt Platform Engineering IT und OT auf einen gemeinsamen Weg. SPS-Code, Edge-Software und Cloud-Services laufen durch dieselbe Pipeline, mit derselben Freigabe und demselben Nachweis. Die Plattform ist dort meist schlanker als in der Cloud, und das ist richtig so.
Genau das ist der Kern von Industrial DevOps: Software für Maschinen und Anlagen so ausliefern, wie gute IT-Teams es längst tun, ohne die Regeln der Produktion zu brechen.
AIEin Beispiel aus dem Alltag. Eine Automatisierungsingenieurin ändert eine Schrittkette. Ohne Plattform überträgt sie das Projekt vom Laptop auf die Anlage und trägt den Stand hinterher in eine Excel-Liste ein, wenn die Schicht es zulässt. Mit Plattform schiebt sie die Änderung in einen Branch. Die Pipeline übersetzt das Projekt, testet es gegen eine virtuelle Steuerung, prüft die Regeln nach IEC 62443 und rollt im geplanten Wartungsfenster aus.
Fragt dann der Auditor, wer die Änderung an Linie 3 wann freigegeben hat, ist die Antwort ein Eintrag im Deployment-Protokoll mit Name, Zeitpunkt und Prüfbericht. Niemand muss dafür einen Aktenordner suchen.
Ehrlich gesagt ist die OT beim Self-Service noch nicht so weit wie die IT. Viele Engineering-Werkzeuge lassen sich nur eingeschränkt automatisieren, und nicht jede Steuerung hat eine brauchbare Simulation. Wie weit Golden Paths in der SPS-Entwicklung heute tragen, ordnet unser Artikel Platform Engineering in der Industrie im Detail ein. Den Hintergrund zur IT/OT-Konvergenz erklärt das Glossar.
Was eine Fabrik-Plattform mindestens braucht
- 01SPS-Projekte, HMI und Edge-Software in Git statt auf dem Netzlaufwerk
- 02Eine Pipeline, die gegen eine virtuelle Steuerung testet
- 03Eine Freigabe, die Name, Zeitpunkt und Prüfbericht speichert
- 04Einen Katalog, der zeigt, welcher Stand auf welcher Anlage läuft
- 05Security-Regeln nach IEC 62443 als automatische Prüfung
Abb. 11 · Die gemeinsame Pipeline als Kern einer Plattform zwischen IT und OT
Häufige Fragen zu Platform Engineering
- Was ist Platform Engineering?
- Platform Engineering ist die Disziplin, interne Entwicklerplattformen (Internal Developer Platforms, IDP) zu entwerfen und als Produkt zu betreiben. Entwicklerteams bekommen darüber Self-Service-Zugang zu Infrastruktur, Deployments und Observability, statt jedes Mal eine eigene Toolchain zu bauen. Das senkt die kognitive Belastung der Teams.
- Wie baue ich eine Internal Developer Platform auf?
- Eine Internal Developer Platform entsteht schrittweise: Engpässe der Teams erfassen, die kleinste nützliche Plattform (Thinnest Viable Platform) festlegen, ein kleines dediziertes Platform Team benennen, den ersten Golden Path automatisieren und danach an Adoption und Durchlaufzeit messen. Wer mit dem Portal beginnt statt mit dem automatisierten Weg dahinter, baut eine Oberfläche ohne Funktion.
- Was ist der Unterschied zwischen einem internen Entwicklerportal und einer internen Entwicklerplattform?
- Das interne Entwicklerportal (Developer Portal) ist die Oberfläche mit Service-Katalog, Templates, Dokumentation und Ownership. Die interne Entwicklerplattform (Internal Developer Platform, IDP) ist der Unterbau, der beim Klick tatsächlich etwas tut: Provisioning, Pipelines, Policies, Observability. Platform Engineering ist die Disziplin, die beides als Produkt betreibt. Ein Portal ohne Plattform ist ein Katalog ohne Knöpfe, eine Plattform ohne Portal eine Sammlung von APIs, die niemand findet.
- Wofür steht IDP im Platform Engineering?
- Im Platform Engineering steht IDP für Internal Developer Platform, die interne Entwicklerplattform, die Provisioning, Pipelines, Policies und Observability als Self-Service bereitstellt. Die gleichlautende Abkürzung IdP bezeichnet in der IT-Sicherheit den Identity Provider, also den Dienst, der Anmeldungen per SAML oder OIDC ausstellt. Beide kommen im selben Stack vor, meinen aber verschiedene Dinge.
- Was ist der Unterschied zwischen Platform Engineering und DevOps?
- DevOps beschreibt Kultur und Praxis der Zusammenarbeit von Entwicklung und Betrieb. Platform Engineering ersetzt DevOps nicht, es setzt darauf auf und baut die wiederverwendbaren Dienste, mit denen Teams diese Praxis ohne eigenen Infrastruktur-Unterbau leben können. Es löst die Überlastung, die entsteht, wenn jedes Team Kubernetes, Pipelines, Monitoring und Security selbst betreiben muss.
- Was macht ein Platform Engineer?
- Ein Platform Engineer baut und betreibt die interne Plattform: Infrastruktur-Module, Pipeline-Templates, Policies und die Automatisierung hinter dem Portal. Anders als im klassischen Betrieb arbeitet er nicht Tickets ab, sondern entwickelt Self-Service-Wege, die andere Teams ohne ihn nutzen können. Seine Kunden sind die Entwicklerteams im eigenen Haus.
- Braucht jede Internal Developer Platform ein Developer Portal?
- Nein, und oft ist das Portal nicht der richtige erste Schritt. Solange zwei bis drei Teams an der Plattform hängen, reichen ein Repository mit Templates und eine gute README. Ein Portal lohnt sich, sobald niemand mehr überblickt, welche Services existieren, wem sie gehören und welcher Golden Path für welchen Fall gilt. In unseren Projekten ist das ab etwa 30 bis 50 Services der Fall.
- Backstage, Port oder Cortex: welches Developer Portal passt?
- Backstage ist Open Source, stammt ursprünglich von Spotify und ist heute ein CNCF-Projekt. Es passt zu Organisationen mit eigenem Plattform-Team und hohem Anpassungsbedarf; bis zum produktiven Portal vergehen erfahrungsgemäß 6 bis 12 Monate. Port ist SaaS und schneller eingerichtet. Laut Preisseite (Stand Oktober 2026) ist Port bis 15 Nutzer kostenlos, der Basic-Plan kostet ab 30 US-Dollar pro Nutzer und Monat bei jährlicher Abrechnung. Cortex ist ebenfalls SaaS, legt den Schwerpunkt auf Service-Scorecards und Ownership und passt zu SRE-geprägten Organisationen mit vielen Services.
- Wann braucht mein Unternehmen Platform Engineering?
- Typische Anzeichen sind mehr als fünf Entwicklerteams, wiederkehrende Infrastruktur-Anfragen, lange Wartezeiten auf Umgebungen und uneinheitliche Deployment-Wege. Ein guter Test ist die Frage, wie lange ein neues Team bis zum ersten Deployment in Produktion braucht. Sind es Wochen statt Tage, lohnt der Blick auf eine Plattform.
- Lohnt sich Platform Engineering ab welcher Team-Größe?
- Nach unserer Erfahrung ab etwa fünf Produktteams oder 30 Entwicklern. Darunter reicht meist eine schlanke Sammlung von CI/CD-Templates und Infrastructure-as-Code-Modulen. Ab 50 Entwicklern ist ein dediziertes Platform Team die Regel.
- Welche Reifegrade gibt es im Platform Engineering?
- Das Platform Engineering Maturity Model der CNCF unterscheidet vier Stufen: Provisional, Operational, Scalable und Optimizing. Bewertet werden fünf Aspekte getrennt: Investment, Adoption, Interfaces, Operations und Measurement. Eine Organisation kann deshalb bei den Schnittstellen schon Self-Service bieten und bei der Messung noch am Anfang stehen.
- Was ist ein Golden Path?
- Ein Golden Path ist der empfohlene, vorgefertigte Weg für eine häufige Aufgabe, etwa einen neuen Service anlegen oder eine Datenbank bereitstellen. Er ist nicht verpflichtend, aber so gut gebaut, dass Teams ihn freiwillig nehmen. Netflix nennt dasselbe Prinzip Paved Road.
- Welche Tools brauche ich für Platform Engineering?
- Ein Standard-Toolset gibt es nicht. Häufig sind Backstage, Port oder Cortex als Developer Portal, Crossplane oder Terraform für das Provisioning, Argo CD für GitOps-Deployments, OPA oder Kyverno für Policy-as-Code und Prometheus mit Grafana für Observability. Crossplane verwaltet Cloud-Ressourcen als Kubernetes-Objekte und passt zu Plattformen, die ohnehin auf Kubernetes stehen; Terraform ist die breitere Wahl, wenn auch VMs, Netzwerk und Edge-Geräte dazugehören.
- Wie messe ich Developer Experience (DevEx)?
- Bewährt sind das SPACE-Framework von GitHub und Microsoft Research mit den Dimensionen Satisfaction, Performance, Activity, Communication und Efficiency sowie DX Core 4 mit Speed, Effectiveness, Quality und Impact, jeweils ergänzt um die vier DORA-Metriken. Konkret messen Sie Time-to-First-Deploy neuer Teams, Deployment-Frequenz, Durchlaufzeit von Pull Requests und den Toil-Anteil pro Sprint.
- Wie hoch ist die Toil-Reduktion durch eine IDP?
- Im Median unserer Projekte 2023 bis 2025 sank der Toil-Anteil zwölf Monate nach Einführung von 40 bis 55 Prozent auf 15 bis 25 Prozent. Die Einrichtung neuer Services dauerte statt zwei bis vier Wochen noch ein bis zwei Tage, das Onboarding neuer Entwickler statt zwei Wochen noch drei Tage.
- Warum scheitern interne Entwicklerplattformen?
- Meist nicht an der Technik, sondern an der Reihenfolge und am Betrieb. Typische Muster sind ein Developer Portal ohne automatisierten Unterbau, ein großes Plattform-Programm ohne Pilotteam, eine Plattform als Pflicht statt als Angebot, ein Platform Team, das nebenbei das alte Ops-Backlog abarbeitet, und fehlende Messung. Laut viertem State of Platform Engineering Report misst knapp ein Drittel der Plattform-Teams den eigenen Erfolg gar nicht.
- Welche Zertifizierungen gibt es für Platform Engineering?
- Die CNCF bietet zusammen mit der Linux Foundation zwei Zertifizierungen an. Der Certified Cloud Native Platform Engineering Associate (CNPA) ist seit Juni 2025 der Einstieg und prüft Grundlagenwissen. Der Certified Cloud Native Platform Engineer (CNPE) kam im November 2025 dazu, ist eine praktische Prüfung in einer echten Umgebung und deckt Plattform-Architektur, GitOps, Self-Service-APIs, Observability und Policy-Durchsetzung ab.
- Wie groß muss ein Platform Team sein?
- Für den Start reichen zwei bis vier Personen, sofern sie dediziert an der Plattform arbeiten und nicht nebenbei das Ops-Backlog abarbeiten. Als Faustregel planen wir einen Platform Engineer pro 10 bis 15 Anwendungsentwickler. Ab etwa 50 Entwicklern kommt eine Person dazu, die die Plattform als Produkt verantwortet.
- Wie hängen Platform Engineering und GitOps mit Argo CD zusammen?
- Argo CD und Flux sind das übliche Deployment-Backend einer IDP. Entwickler lösen Deployments über das Portal aus, die Plattform erzeugt daraus ApplicationSets in Git, und Argo CD synchronisiert sie auf die Cluster. Die IDP verbirgt das YAML, GitOps liefert Audit-Trail und Rollback.
- Ist Platform Engineering auch für industrielle Umgebungen relevant?
- Ja, wenn IT- und OT-Teams an derselben Software arbeiten. In der Fabrik ist die Plattform meist schlanker als in der Cloud: SPS-Projekte in Git, eine Pipeline, die gegen eine virtuelle Steuerung testet, eine Freigabe mit Protokoll und ein Katalog, der zeigt, welcher Softwarestand auf welcher Anlage läuft. Die Security-Regeln nach IEC 62443 laufen dabei als automatische Prüfung in der Pipeline mit.
Sie wollen eine Plattform, ohne ein eigenes Platform Team aufzubauen? Comquent betreibt CI/CD- und Plattform-Dienste als Managed DevOps Service (DevOps Outsourcing): Jenkins, GitLab CI, Azure DevOps, Argo CD und Kubernetes als laufender Service mit SLA. So beginnen Sie mit Platform Engineering, ohne sofort Stellen aufzubauen.
Wie geht es bei Ihnen mit Platform Engineering weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
DevOps vs. Platform Engineering für SPS & OT
Wie weit Golden Paths und Self-Service in der OT heute tragen, mit Beispielen aus der SPS-Entwicklung.
Was ist Industrial DevOps? Der komplette Leitfaden
DevOps-Prinzipien für cyber-physische Systeme, von der IT/OT-Konvergenz bis zur ersten Pipeline.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Reifegradmodelle und Value-Stream-Mapping für Ihre DevOps-Bewertung.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance