Platform Engineering: Vom Regenbogenteam zur reiferen Plattform

Mit dem Platform Engineering Maturity Model will die Cloud Native Computing Foundation (CNCF) Organisationen auf dem Weg hin zu einer individuell wunschgemäß funktionierenden Entwicklerplattform konkret unterstützen. Die Motivation und die Theorie dahinter hat der Beitrag Platform Engineering: Fitnessplan für Entwicklerplattformen bereits dargelegt. Wie gut die Umsetzung des Modells in der Praxis gelingt, dazu äußern sich im Folgenden verschiedene Plattformexpertinnen und -Experten.

Im Zuge der KubeConEU 2025 in London habe ich eine Umfrage zur praktischen Anwendung des Platform Engineering Maturity Models durchgeführt, um zunächst herauszufinden, welche aktuellen Herausforderungen und Trends die Teilnehmenden derzeit im Platform Engineering sehen. Weitergehende Fragen zu den Kernaspekten des Platform Engineering Maturity Models (Investment, Adoption, Interfaces, Operations und Measurement) sollten zeigen, welche Ziele sie Plattformteams anstreben und welche Reifegrade (Provisional, Operational, Scalable und Optimizing) sie dabei beschäftigen.

Die Ergebnisse der nicht repräsentativen Umfrage vermitteln ein Stimmungsbild und geben einen groben Eindruck vom Status Quo des Platform Engineering in vielen Organisationen.

Plattformteams kämpfen mit Überforderung und mangelnder Klarheit

Dabei zeigt sich immer wieder eine zentrale Herausforderung: Plattformteams sind überlastet mit all den Aufgaben, die sich um sie herum anhäufen, da sie für zu viele Funktionalitäten verantwortlich sind. "Ich habe einen Platform Engineer sagen hören, dass er sein Team das Regenbogenteam nennt, weil sie sozusagen alle Farben unter der Sonne vereinen. Was er damit meint, ist, sie haben zu viele verschiedene Aufgaben, und sie versuchen dennoch alles richtigzumachen. Am Ende geraten sie aber in die Falle und bleiben bei der Arbeit an der Plattform ebenso wie bei deren Wartung stecken", erklärt Abby Bangser, Principal Engineer von Syntasso. Sie gehört zu der Gruppe, die das Platform Engineering Maturity Model erarbeitet hat.

Die große Zahl an Plattformfunktionalitäten führt zu erheblichem Mehraufwand bei den verantwortlichen Teams. "Zu viel Betrieb (Ops)", nennt etwa Till Adam, Cloud Platform Engineer von dmTech, als aktuell größte Herausforderung in seinem Plattformteam. Ein entscheidender Faktor dabei ist – wie im Platform Engineering Maturity Model beschrieben – die Schnittstelle der Plattform zur Bereitstellung von Funktionalitäten. Einige Befragte arbeiten zwar bereits an einem Self-Service-Ansatz, behalten aber oft noch Abhängigkeiten zu den Plattformteams durch manuelle Schritte innerhalb ihrer Bereitstellungsprozesse.

Das Platform Engineering Maturity Model der CNCF (Abb. 1)

(Bild: CNCF)

Erschwerend hinzu kommt der Aspekt der Adoptionsstrategie. Häufig stellen nur noch die Plattformen Infrastruktur für Applikationsteams bereit. Dadurch muss die Plattform zwangsläufig mehr Funktionen anbieten und mehr Nutzer betreuen. Mit Blick auf die Adoptionsstrategie ihrer Plattformen ist Gabi Beyer, Sustainability Engineer bei re:cinq, sicher: "Die Applikationsteams haben keine andere Wahl. Die Plattform ist bereits fest in ihre Arbeitsabläufe integriert."

Für Abby Bangser ist ein Grund für die vielen zu verantwortenden Plattform-Funktionen die unklare Definition des Begriffs Plattform: "die Verwirrung, die entstanden ist, weil die Terminologie und das Marketing sowie die Sprache rund um Plattformen alle sehr ähnlich erscheinen. Wenn aber die Leute die Produkte tatsächlich in die Hand nehmen, sehen sie plötzlich ganz anders aus. Es herrscht daher Unsicherheit darüber, was Platform Engineering genau ist, welche Produkte dazu gehören und wie sie funktionieren."

Mangelnde Investitionsbereitschaft und fehlende Erfolgsmetriken für Plattformteams

Während Plattformteams auf der einen Seite über zu viele unterschiedliche Verantwortlichkeiten klagen, fehlen ihnen auf der anderen Seite die notwendigen Investitionen. "Firmen sind meistens nicht gewillt [in Plattformen] zu investieren und sehen keinen Nutzen darin, sondern outsourcen beispielsweise lieber", ist Philip Welz, Cloud Solution Architect bei White Duck, überzeugt. Auch Gabi Beyer hat ähnliche Erfahrungen in früheren Plattformprojekten gesammelt: "Als ich zu dem Projekt stieß, gab es nicht genügend Ressourcen. Es gab lediglich ein separates CI-Team (Continuous Integration) mit zwei Mitarbeitern und ein Plattformteam mit ebenfalls zwei Mitarbeitern."

Ein Grund für die fehlende Investitionsbereitschaft liegt möglicherweise darin, dass es vielen Plattformteams noch schwerfällt, die Erfolge der Plattform zu messen. So sammeln sie zwar meist ad hoc oder auch konsistent Metriken, wie im Platform Engineering Maturity Model beschrieben, es besteht jedoch häufig keine Einigkeit darüber, was genau zu messen ist, um auch die für den Geschäftsbereich relevanten Erfolge der Plattform zu überprüfen. So räumt Till Adam ein: "Wir machen einmal im Jahr eine Umfrage, wie zufrieden die Nutzer sind. Aber das ist natürlich relativ anekdotisch, wenn man die Leute fragt: Wie zufrieden seid ihr? Dann melden sich fünf, die zufrieden sind. Dann ist eben alles toll."

Selbst wenn der Wille zu mehr Investitionen gegeben ist und die Organisationen das Problem der zu kleinen Plattformteams lösen, bleibt eine weitere Herausforderung: das Know-how. "Eine unserer größten Herausforderungen ist derzeit die Skalierung unseres Teams und die Einstellung von Mitarbeitern, die nicht nur Cloud-Natives sind, sondern auch programmieren können – denn das ist es, was wir in unserem Plattformteam suchen", berichtet Miles Bryant, Staff Engineer Platform von Monzo.

Künstliche Intelligenz als Lösung und Problem zugleich

Um das Problem der zu kleinen Plattformteams langfristig zu lösen, greifen viele Organisationen einen generellen Trend der IT-Branche auf: Künstliche Intelligenz. So versuchen Plattformteams verstärkt KI in ihre Arbeitsabläufe einzubauen. Auch Miles Bryant bestätigt den Trend zu vermehrtem KI-Einsatz, warnt jedoch auch vor potenziellen Gefahren: "Wir fangen an zu unterscheiden zwischen Unternehmen, die KI einfach überall einbauen, wo sie es können, nur weil sie meinen, dass sie KI brauchen, und Unternehmen, die etwas tiefer darüber nachdenken, wie sie KI optimal nutzen können."

Im ersteren Fall riskieren Unternehmen, nur die durch zu kleine Plattformteams ausgelösten Symptome zu bekämpfen. Auf der anderen Seite kann KI jedoch auch dazu beitragen, das zugrundeliegende Problem weiter zu eskalieren. Denn sie erweitert Abby Bangser zufolge auch den Verantwortungsbereich von Plattformteams: "Wir sollten dann nicht mehr nur KI für die Entwickler als Plattform-Funktionen bereitstellen, sondern auch die Fähigkeit einführen, KI-Anwendungen und die damit verbundenen Tools zu hosten." In diesem Fall ergibt sich durch den Trend zu mehr KI-Einsatz paradoxerweise eine noch größere Belastung der Plattformteams, denn das Wissen und die Fertigkeiten hierfür müssen meist erst einmal aufgebaut werden, ohne dass es mehr Personal gibt.

Platform-as-a-Product als Brücke zum Geschäftsbereich

Um das Problem der fehlenden Investitionsbereitschaft in Plattformteams zu lösen, beschreiten einige Organisationen einen Weg, der sich aus den Reifegraden des Investitions-Aspekts des Platform Engineering Maturity Models ableitet: der Produktansatz (siehe Abbildung 1). Gute Erfahrungen damit hat beispielsweise Gabi Beyer bei re:cinq gemacht: "Ein Teil unserer Arbeit bestand darin, [...] das Plattformteam in ein Produktteam zu überführen, damit es wie ein Produkt behandelt werden kann – im Einklang mit allen anderen Produktteams. Wir haben festgestellt, dass es viel einfacher ist, das Unternehmen für die Plattformentwicklung zu gewinnen, wenn es sich um ein Produkt handelt, weil man Dinge besser planen und alle anderen Teams besser einbeziehen kann. Man benötigt zwar immer noch mehr Arbeitsstunden und Personalressourcen, aber diese Festlegung vereinfacht es, das Budget auszurichten."

Der Trend zu Platform as a Product spiegelt auch einen Wechsel in der Sichtweise von Teams auf ihre Plattformen wider. Es geht nicht mehr primär darum, eine Ansammlung von Tools bereitzustellen, sondern die Plattformen sollen einen klaren Mehrwert für die Nutzer liefern. Till Adam ist davon überzeugt, dass der Fokus auf das Produktverständnis beispielsweise auch dabei hilft, die Plattform firmenintern zu popularisieren. Der Mehrwert der Plattform wird damit zu einem entscheidenden Faktor, den es aber auch zu messen gilt. Die Metriken kommen dem Team aber auch in der Kommunikation über seine Plattform zugute – beispielsweise gegenüber den Geschäftsbereichsverantwortlichen. Das kann auch zu einer größeren internen Wertschätzung führen.

Bestenfalls geht die Wertschätzung sogar so weit, dass sich Nutzer nicht nur als Kunden, sondern als Teil der Plattform sehen. Im Platform Engineering Maturity Model entspricht dies der Strategie der "Adoption Participatory" (siehe Abbildung 1). "Zu vielen der übergeordneten, nutzerorientierten Aspekte wie Werkzeugen, Schnittstellen oder Dashboards kann jeder bei Monzo beitragen", sagt Miles Bryant. "Wir haben eine offene Codebasis, die jeder nutzen kann, um den Code einzusehen und zu erweitern. Und tatsächlich waren viele der besten Tools, die wir auf unserer Plattform haben, ursprünglich nur ein Nebenprojekt eines Applikationsteams, wurden dann aber zu einem unternehmensweiten Tool."

Mit Mut und Freude zu mehr Reife

Die Umfrage unter den Plattformexpertinnen und -experten macht deutlich, dass viele Organisationen die gleichen oder zumindest ähnliche Herausforderungen entlang der Reifegrade des Platform Engineering Maturity Model teilen. Die meisten Befragten finden sich über die einzelnen Aspekte hinweg zumeist im zweiten oder dritten Reifegrad wieder. Als eine der Autoren des Modells bringt Abby Bangser ihre Freude darüber zum Ausdruck: "Spannend finde ich, dass sich viele Leute selbst in Stufe 2 eingeordnet haben – und zwar mit Stolz, oder zumindest mit Freude. Das beweist, dass viele das Modell nutzen, um ehrlich zu verstehen, wo sie stehen, und nicht, um lediglich beweisen zu wollen, dass sie besser sind als alle anderen."

Die Umfrage legt allerdings auch nahe, dass viele Unternehmen und Teams mit dem erreichten Reifegrad noch nicht zufrieden sind und die jeweils nächste Stufe anstreben. Dazu braucht es vor allem klare Verantwortlichkeiten, nutzerzentriertes Denken und messbaren Mehrwert. Fortschritt ist sichtbar – aber er braucht Zeit, Mut zur Fokussierung und vor allem: ein gemeinsames Verständnis davon, was "gute Plattformarbeit" eigentlich bedeutet. Das Platform Engineering Maturity Model hilft dabei.

(map)