Was ist Platform Engineering?

Lernziele

Nach dieser Lektion kannst du erklären, welches organisatorische Problem Platform Engineering löst, was eine Internal Developer Platform (IDP) ist und warum der Kunde der Plattform der Entwickler ist — nicht der Endnutzer. Du kannst die Disziplin sauber von klassischem Infrastruktur-Betrieb abgrenzen und im Interview begründen, woran man Plattform-Erfolg misst und woran ausdrücklich nicht.

Das Problem: „You build it, you run it” skaliert nicht von allein

DevOps hat ein berechtigtes Versprechen: Das Team, das Software baut, betreibt sie auch — kurze Feedback-Schleifen, echte Verantwortung. Bei fünf Teams funktioniert das. Bei fünfzig Teams kippt es: Jedes Team braucht plötzlich jemanden, der Kubernetes versteht, Terraform schreibt, CI-Pipelines wartet, Monitoring aufsetzt, Security-Scans einbaut und Cloud-Kosten im Blick behält. Das ist Cognitive Load, der nichts mit dem eigentlichen Produkt zu tun hat.

Die Folgen sind vorhersehbar: fünfzig leicht unterschiedliche Pipelines, drei konkurrierende Logging-Stacks, Onboarding-Zeiten von Wochen, und ein Security-Team, das Compliance über fünfzig Insellösungen hinweg durchsetzen soll. Historisch gab es darauf zwei Antworten, und beide scheitern auf ihre Art: Das zentrale Ops-Team wird zum Ticket-Flaschenhals („Staging-Umgebung beantragt, Lieferzeit zwei Wochen”), die volle Dezentralisierung erzeugt Wildwuchs und überforderte Produktteams.

Platform Engineering ist der dritte Weg: Wiederkehrende Infrastruktur-, Delivery- und Compliance-Probleme werden einmal zentral gelöst und den Teams als Self-Service angeboten — nicht als Ticket-Dienstleistung und nicht als Zwangsvorgabe.

Die Lösung: eine interne Plattform mit Entwicklern als Kunden

Die Definition, die du im Interview parat haben solltest: Platform Engineering ist die Disziplin, eine interne Plattform zu entwerfen, zu bauen und zu betreiben, die Entwicklungsteams per Self-Service mit allem versorgt, was sie zum Bauen, Deployen und Betreiben ihrer Anwendungen brauchen — mit Sicherheit, Observability und Compliance als eingebauten Standards statt als nachgelagerter Prüfung.

Drei Worte in dieser Definition tragen das Gewicht:

Self-Service — der Unterschied zum klassischen Infra-Team liegt nicht in der Technik, sondern im Liefermodell. Ein Team, das auf Zuruf Namespaces anlegt, ist Dienstleister. Ein Team, dessen Nutzer sich Namespaces selbst provisionieren — innerhalb definierter Leitplanken — baut ein Produkt.

Plattform — gemeint ist die Internal Developer Platform (IDP): kein einzelnes Tool, sondern eine zusammenhängende Schicht aus Capabilities. Typische Bausteine: ein Developer Portal mit Service-Catalog, Scaffolding-Templates für neue Services, eine geteilte CI/CD-Strecke, eine Compute-Abstraktion über Kubernetes, Observability und Identity/Secrets als fertige Services.

Standards eingebaut — wer den Golden Path der Plattform nutzt, bekommt Security-Scans, Dashboards und sinnvolle Defaults geschenkt, ohne sie zu kennen. Der sichere Weg ist gleichzeitig der bequemste — das ist der Mechanismus, über den Plattformen Compliance erreichen, ohne Gatekeeper zu sein.

Wichtig für die Abgrenzung: Kubernetes ist häufig der Unterbau einer IDP, aber nicht die Plattform selbst. Ein Cluster ohne Templates, Portal und Self-Service ist Infrastruktur — Entwickler stehen davor wie vor einem Rohbau.

So dünn wie möglich: die Thinnest Viable Platform

Eine verbreitete Fehlannahme ist, dass eine Plattform erst „fertig” sein muss, bevor sie nützlich ist. Das Gegenteil stimmt. Das Konzept der Thinnest Viable Platform (TVP) besagt: Baue die kleinste Abstraktion, die den größten realen Schmerz löst — das kann anfangs ein gut gepflegtes Wiki mit einem CI-Template sein — und erweitere nur dort, wo Nutzungsdaten und Feedback echten Bedarf zeigen.

Beide Extreme sind teuer: Eine zu dicke Plattform wird zur Black Box, hinter der Entwickler nichts mehr debuggen können, und bindet das Plattform-Team an Features, die niemand nutzt. Eine zu dünne Plattform löst den Schmerz nicht und treibt Teams zurück in Eigenbau-Lösungen. Wo die richtige Grenze liegt, ist eine Produktentscheidung, keine technische — deshalb behandelt Lektion 2 die Plattform konsequent als Produkt.

Erfolg messen: Outcomes statt Cluster-Uptime

„Wie misst du, ob deine Plattform erfolgreich ist?” ist eine der häufigsten Interview-Fragen in diesem Feld. Die schwache Antwort zählt Tickets oder Uptime. Die starke Antwort misst, was die Plattform bei ihren Kunden bewirkt:

• DORA-Metriken der Produktteams: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore. Wenn die Plattform wirkt, bewegen sich diese Werte — bei den Teams, nicht beim Plattform-Team.
• Time-to-First-Deploy: Wie lange braucht ein neues Team oder ein neuer Service von null bis zum ersten Produktiv-Deployment? Eine der direktesten Plattform-Metriken überhaupt.
• Adoption Rate: Welcher Anteil der Teams nutzt die Golden Paths freiwillig? Adoption ist die ehrlichste Metrik, weil sie nicht erzwungen werden kann — niemand „adoptiert” eine Plattform, die langsamer ist als der Eigenbau.
• Developer Satisfaction: regelmäßige Umfragen, etwa entlang des SPACE-Frameworks.

Cluster-Uptime ist dabei nicht egal — sie ist Hygiene-Faktor. Aber ein Plattform-Team, das nur Uptime berichtet, hat seinen Kunden noch nicht verstanden.

Praxis: Pitch und Capability-Inventur

Zwei Übungen, beide schriftlich:

1. Der 90-Sekunden-Pitch. Schreibe in maximal acht Sätzen, wie du einem CTO ohne Plattform-Vorwissen erklärst, warum die Organisation ein Plattform-Team braucht. Regeln: kein Tool-Name, kein Buzzword ohne Erklärung, mindestens eine Zahl oder messbare Größe (z. B. Onboarding-Dauer, Lead Time). Lies den Pitch laut — alles, was du stockend vorliest, streichst du.
2. Capability-Inventur. Nimm deine aktuelle Organisation (oder eine fiktive Firma mit 30 Teams) und lege eine Tabelle mit den Zeilen Scaffolding, CI/CD, Compute, Observability, Secrets/Identity, Dokumentation/Discovery an. Trage pro Zeile ein: Was existiert heute? Wer betreibt es? Ist es Self-Service, Ticket oder Eigenbau pro Team? Markiere die zwei Zeilen mit dem größten Schmerz — das wäre dein TVP-Startpunkt.

Beide Artefakte kannst du im Interview wörtlich verwenden, wenn nach Erfahrung oder Vorgehen gefragt wird.

Typische Stolperfallen

Plattform mit Kubernetes gleichsetzen. Wer auf „Was ist eure Plattform?” mit einer Cluster-Beschreibung antwortet, hat die Produktschicht übersehen — und genau darauf zielt die Frage.

Adoption per Dekret. „Ab Q3 müssen alle Teams die Plattform nutzen” erzeugt Compliance auf dem Papier und Shadow IT in der Realität. Plattformen gewinnen über Überlegenheit, nicht über Anordnung.

Big Bang statt TVP. Achtzehn Monate im stillen Kämmerlein eine „vollständige” IDP bauen und dann launchen — das Risiko, am Bedarf vorbeizubauen, ist enorm. Klein starten, mit echten Pilot-Teams iterieren.

Den falschen Kunden bedienen. Wenn Priorisierung primär nach Management-Wünschen statt nach Entwickler-Schmerz erfolgt, entsteht eine Plattform, die in Steering-Folien gut aussieht und im Alltag ignoriert wird.

Interview-Vorbereitung

Die Standardfrage „Was ist Platform Engineering?” beantwortest du am stärksten in dieser Reihenfolge: Problem (Cognitive Load und Wildwuchs bei skalierendem DevOps) → Definition (Self-Service-Plattform mit Entwicklern als Kunden) → IDP konkret (zwei, drei Capabilities nennen) → Erfolgsmessung (DORA, Time-to-First-Deploy, Adoption).

Rechne mit diesen Follow-ups:

• „Worin unterscheidet sich das von DevOps?” — DevOps ist Kultur und Praxis, Platform Engineering ein dediziertes Produkt-Team, das diese Kultur skalierbar macht (ausführlich in Lektion 4).
• „Was genau ist eine IDP?” — Keine Tool-Liste, sondern eine Produktschicht aus Self-Service-Capabilities: Portal, Templates, Delivery, Compute, Observability, Identity.
• „Braucht jede Firma ein Plattform-Team?” — Ehrlich antworten: Unter etwa 20–30 Entwicklern lohnt ein dediziertes Team selten; dort reichen Konventionen und ein paar geteilte Templates.
• „Woran erkennst du, dass eine Plattform scheitert?” — Sinkende Adoption, wachsende Escape-Hatch-Nutzung, Teams bauen wieder Parallel-Infrastruktur.

Zusammenfassung

Platform Engineering löst das Skalierungsproblem von DevOps: Statt dass jedes Team Infrastruktur-Expertise duplizieren muss, liefert ein dediziertes Team eine IDP — Self-Service-Capabilities mit eingebauten Standards, so dünn wie möglich (TVP), gemessen an Outcomes wie DORA-Metriken und freiwilliger Adoption. Der Kunde ist der Entwickler, das Liefermodell ist Produkt statt Ticket.

Was „Produkt” hier konkret bedeutet — Roadmap, interne SLAs, Priorisierung, Deprecation — ist das Thema der nächsten Lektion.