Bildquelle: Pexels / Kindel Media / https://www.pexels.com/photo/two-men-working-in-the-office-7651806/
Plattformengineering bekommt ein Einstiegszertifikat, aber gute Plattformen entstehen nicht aus Badges
Plattformengineering ist in vielen Unternehmen längst kein Nebenthema mehr. Interne Developer Portals, Self-Service-Infrastruktur, GitOps-Strecken, Guardrails für Sicherheit und ein sauberer Betriebsweg für Entwicklungs-Teams landen heute immer häufiger in einer gemeinsamen Verantwortungszone. Genau deshalb ist die neue CNCF-Zertifizierung CNPA interessanter, als sie auf den ersten Blick wirkt. Sie macht sichtbar, dass Plattformengineering nicht mehr nur ein Sammelbegriff für „irgendwas zwischen DevOps, SRE und Cloud“ ist, sondern als eigenständiges Rollenbild mit klaren Grundlagen behandelt wird.
Für Leser ohne Zertifizierungsbezug: Die CNCF ist die zentrale Stiftung hinter Kubernetes und vielen Cloud-Native-Projekten. Zertifizierungen dieser Organisation sind keine Garantie für gute Umsetzung im Unternehmen, aber sie zeigen sehr früh, welche Fähigkeiten der Markt als gemeinsames Mindestverständnis für bestimmte Rollen akzeptiert. Wenn eine neue Prüfung genau Themen wie Plattform-APIs, Developer Experience, Observability, Security und DORA-Metriken zusammenzieht, ist das ein ernstes Signal für IT-Leitungen und Plattformverantwortliche.
Die eigentliche Nachricht ist nicht die Prüfung, sondern das neue Rollenbild
Am 15. Juni 2025 hat die CNCF die Zertifizierung Certified Cloud Native Platform Engineering Associate, kurz CNPA, offiziell vorgestellt. Laut CNCF wurde sie mit Beiträgen aus mehr als 50 Unternehmen entwickelt und soll grundlegende Fähigkeiten für den Aufbau, die Automatisierung und den Betrieb cloud-nativer Plattformen validieren. Schon diese Beschreibung ist aufschlussreich. Es geht nicht bloß um Kubernetes-Bedienung, nicht bloß um Pipelines und auch nicht bloß um Architektur. Die Prüfung zieht mehrere Disziplinen zusammen, die in der Praxis oft künstlich getrennt werden.
Die offiziellen Domain-Gewichte machen das besonders klar. Der größte Block entfällt auf Platform Engineering Core Fundamentals mit 36 Prozent. Hinzu kommen Observability, Security und Conformance mit 20 Prozent, Continuous Delivery mit 16 Prozent, Plattform-APIs und Provisioning mit 12 Prozent, Internal Developer Platforms und Developer Experience mit 8 Prozent sowie Measuring your Platform mit weiteren 8 Prozent. Genau diese Mischung ist interessant. Eine Plattform wird hier nicht als Tool-Sammlung verstanden, sondern als Betriebsprodukt für interne Teams, das zugleich sicher, messbar, automatisierbar und für Entwickler benutzbar sein muss.
Damit beschreibt die CNCF implizit ein Rollenbild, das in vielen IT-Organisationen noch nicht sauber verankert ist. Oft betreibt ein Team Kubernetes, ein anderes verwaltet CI/CD, ein drittes baut Backstage oder ein Serviceportal, und Security oder Governance kommen erst später als Prüfschritt dazu. CNPA zieht diese Felder wieder zusammen. Die Botschaft ist nüchtern: Plattformengineering ist keine lose Schnittmenge, sondern eine eigenständige Arbeitsdisziplin mit technischer und organisatorischer Verantwortung.
Warum das für ITSM und IT-Management wichtiger ist als für Prüfungssammler
Auf dem Papier ist CNPA eine 120-minütige, online beaufsichtigte Multiple-Choice-Prüfung für 250 US-Dollar. In der Unternehmensrealität ist der interessantere Punkt aber ein anderer. Wer Plattformengineering so definiert, verschiebt auch die Verantwortung im Betrieb. Interne Plattformen sind nicht mehr nur Enablement-Projekte für Entwickler. Sie werden zu einem steuerbaren Service: mit Katalogen, Self-Service-Schnittstellen, Policies, Zuständigkeiten, Metriken und operativen Erwartungen.
Gerade aus ITSM-Sicht ist das relevant. Eine interne Plattform verspricht meist weniger manuelle Tickets, schnellere Bereitstellung und klarere Standards. Das funktioniert aber nur, wenn Self-Service-Angebote wirklich zu Rollen, Freigaben, Sicherheitsgrenzen und Supportprozessen passen. Wer nur Infrastruktur automatisiert, ohne Ownership, Eskalationswege und Messpunkte mitzudenken, baut zwar APIs, aber noch keinen belastbaren Service. Genau deshalb ist es bemerkenswert, dass die CNCF im Grundlagenkatalog nicht nur Technik, sondern auch Developer Experience und DORA-Metriken verankert.
Das ist mehr als modernes Vokabular. Developer Experience bedeutet in diesem Zusammenhang, dass ein Plattformteam nicht nur etwas Technisches bereitstellt, sondern die Nutzbarkeit seines Angebots verantwortet. DORA-Metriken wiederum zwingen dazu, Wirkung messbar zu machen, statt Plattformarbeit nur über interne Architekturästhetik zu rechtfertigen. Ein Team, das Self-Service predigt, aber Deployments verlangsamt, Incident-Wege vernebelt oder Freigaben an unklaren Standards scheitern lässt, hat keine gute Plattform gebaut. Es hat nur neue Komplexität hinter eine hübschere Oberfläche verschoben.
Der neue Lernpfad macht eine zweite Verschiebung sichtbar
Besonders interessant wird CNPA im Zusammenspiel mit der inzwischen ebenfalls verfügbaren Zertifizierung CNPE. Während CNPA Grundlagen für eine breite Einstiegsrolle definiert, beschreibt CNPE laut CNCF einen fortgeschrittenen, praxisnahen Pfad für erfahrene Plattformingenieure und Architekten. Dort geht es nicht mehr um einen reinen Wissensnachweis, sondern um eine hands-on Prüfung mit Linux-Remote-Desktop, Terminal und webbasierten Oberflächen. Auch die Domains verschieben sich: GitOps und Continuous Delivery, Plattform-APIs und Self-Service-Fähigkeiten erhalten dort jeweils 25 Prozent Gewicht, dazu kommen Observability, Operations, Security und Architektur.
Diese Zweistufigkeit ist der eigentliche strategische Punkt. Plattformengineering bekommt damit nicht nur ein Zertifikat, sondern einen sichtbaren Entwicklungspfad. Für Unternehmen ist das hilfreich, weil Rollenmodelle dadurch weniger schwammig werden. Wer heute einen internen Plattformbereich aufbauen oder professionalisieren will, braucht meist beides: Leute mit solider Breite und Leute mit tiefer operativer Umsetzungsstärke. Bisher wurde diese Entwicklung oft über sehr unterschiedliche Zertifikate, private Erfahrungslisten oder reine Bauchgefühle gesteuert. Die neue CNCF-Struktur gibt dafür zumindest einen gemeinsamen Referenzrahmen.
Das heißt nicht, dass jedes Unternehmen sofort Prüfungsbudgets hochfahren sollte. Es heißt aber, dass Plattformarbeit sich immer weniger plausibel als informelles Nebenprojekt führen lässt. Wenn ein Hersteller, ein Trainingsökosystem und eine Fachcommunity dieselben Themen so klar bündeln, wächst auch der Druck auf IT-Leitungen, Rollen, Erwartungen und Lernpfade intern sauberer zu definieren.
Wo Zertifizierungen helfen und wo sie sogar gefährlich überschätzt werden
CNPA kann für Unternehmen nützlich sein, wenn die Prüfung als Strukturgeber verwendet wird. Sie hilft dabei, Bewerberprofile zu schärfen, Junior- und Mid-Level-Rollen sauberer abzugrenzen und Lernpfade zwischen DevOps, SRE, Plattformbetrieb und Developer Enablement zu ordnen. Gerade dort, wo Plattformteams gerade erst entstehen, kann ein gemeinsamer Referenzrahmen unnötige Streitigkeiten über Zuständigkeit und Kompetenz reduzieren.
Gefährlich wird es, wenn Zertifizierungen als Ersatz für Teamdesign missverstanden werden. Eine gute Plattform entsteht nicht, weil mehrere Personen denselben Badge tragen. Sie entsteht, wenn Produktdenken, Betriebsverantwortung, Sicherheitsgrenzen, Supportmodell, Backlog-Priorisierung und Nutzbarkeit zusammenpassen. Wer Self-Service einführt, ohne einen belastbaren Supportpfad mitzudenken, produziert genauso Reibung wie ein Team, das Guardrails ohne Ownership definiert oder ein Developer Portal baut, ohne die tatsächlichen Probleme der internen Teams zu verstehen. Das Ergebnis ist dann Sichtbarkeit ohne Entlastung.
Genau an dieser Stelle ist Plattformengineering Führungsarbeit. Die Zertifizierung kann Wissen ordnen. Sie kann aber weder ein Betriebsmodell ersetzen noch die Konflikte zwischen Standardisierung und Ausnahmen auflösen. Ein gutes Plattformteam braucht deshalb nicht nur technische Tiefe, sondern auch klare Produktverantwortung, saubere Schnittstellen zu Security und ITSM sowie die Bereitschaft, Erfolg über Nutzungsdaten, Lead Time, Störungsbild und Zufriedenheit der internen Teams zu messen.
Was IT-Leitungen daraus praktisch ableiten sollten
Der erste sinnvolle Schritt ist eine Rollenprüfung. Gibt es in Ihrer Organisation bereits ein echtes Plattformteam oder nur verstreute Plattformaufgaben in mehreren Bereichen? Wenn Zuständigkeiten für Self-Service, Plattform-APIs, Developer Portals, Policies und Observability unklar verteilt sind, wird auch das beste Zertifizierungsprogramm nur Kosmetik bleiben.
Der zweite Schritt ist die Lernlogik. CNPA eignet sich als Signal für eine breite, gemeinsame Basis. CNPE zeigt dagegen, wie tief der Pfad in Richtung Produktionsreife und Plattformarchitektur führen kann. Unternehmen sollten diese Unterscheidung nutzen, um Ausbildungs- und Entwicklungswege klarer aufzubauen, statt alle Teammitglieder mit denselben Erwartungen zu überladen.
Der dritte Schritt betrifft die Steuerung. Wenn die CNCF Plattformarbeit ausdrücklich mit Developer Experience und DORA-Metriken verbindet, dann sollte auch intern messbar werden, welchen Effekt die Plattform tatsächlich hat. Gute Fragen sind nicht nur: Welche Tools haben wir? Sondern: Welche manuellen Übergaben sind verschwunden? Wie schnell kommen Teams zu einer Standardumgebung? Welche Sicherheitskontrollen sind automatisiert, ohne den Fluss zu zerstören? Und wo produziert die Plattform selbst noch unnötige Tickets oder Schattenpfade?
Unterm Strich markiert CNPA deshalb mehr als eine neue Badge. Die Zertifizierung macht sichtbar, dass Plattformengineering als eigenständige Disziplin in eine erwachsenere Phase eintritt. Für Unternehmen ist das eine Chance, Rollen, Lernpfade und Betriebsverantwortung klarer zu ordnen. Der Nutzen entsteht aber erst dann wirklich, wenn aus dem Prüfungsstoff ein besseres Plattformprodukt für interne Teams wird.
