Platform Engineering verstehen – mit Eishockey!

Der Zamboni-fahrende Eishockeyspieler: Ein bekanntes Problem

Wer verstehen will, warum Platform Engineering heute so wichtig ist, muss zurückblicken: Früher schrieb man Code und reichte ihn an das Ops-Team weiter, doch dann kam DevOps mit dem Versprechen: «You build it, you run it.» Mehr Ownership, schnellere Rückmeldungen, bessere Qualität. In der Realität bedeutete das oft Überforderung.  Entwickler:innen, eigentlich fokussiert auf Features, mussten sich nun auch mit Kubernetes, CI/CD, Sicherheits-Patches und der Komplexität des CNCF-Universums auseinandersetzen. Das Resultat: kognitive Überlastung.

In unserer Eishockeyanalogie würde das bedeuten: Ein Eishockeyspieler, der eigentlich Tore schiessen sollte, muss plötzlich auch die Schlittschuhe schleifen, Trainingspläne entwerfen und in der Drittelpause den Zamboni fahren. Klar, dass da der Fokus aufs Spiel verloren geht – ebenso wie die Freude und Produktivität.

Platform Engineering: Ein neuer Mindset

Hier setzt Platform Engineering an. Es geht nicht nur um Tools oder neue Jobtitel, sondern um ein ganzheitliches Verständnis. Wie ich in meinem Blogbeitrag Platform Engineering: Ein holistischer Ansatz für eine zukunftssichere IT erklärt habe, geht es bei Platform Engineering letztendlich um einen Wandel in der IT. Denn entscheidend ist der Perspektivenwechsel: Die Plattform wird als Produkt behandelt. Die Entwickler:innen sind ihre Kund:innen. Ziel ist es, einen sogenannten «golden path» zu schaffen – einen gut ausgebauten, sicheren und schnellen Weg, Updates an die Endkund:innen zu bringen. Und das möglichst ohne Frust aufgrund komplexer Infrastruktur.

Wo startet man? Und wo kommt nun Eishockey ins Spiel?

Unsere Landkarte: Das CNCF Maturity Model

Die CNCF beschreibt in ihrem Maturitätsmodell für Platform Engineering (siehe Abbildung) fünf Kernaspekte mit vier Reifegrade. Nachfolgend erklärt mit Eishockey-Analogien.

• Investment: Das Eishockeyfeld /-Stadion
  Dieser Aspekt beschreibt, wie Personal und Budget für die Plattform zugewiesen werden. Die Entwicklung geht hier von einer provisorischen Lösung, vergleichbar mit einem zugefrorenen Teich (Provisional) bei dem jede:r selbst Hand anlegt, bis hin zu einer strategischen Investition, die einer professionellen Arena (Scalable) gleicht. Dabei steht das Gesamterlebnis für die Entwickler:innen im Fokus.
• Adoption: Das Fitnessstudio
  Warum und wie nutzen Entwickler:innen die Plattform? Die Entwicklung reicht von einer vom Management verordneten Pflicht (Push), bei der das Team wie auf Befehl des Trainers zum Training erscheint, hin zu einem freiwilligen Sog (Pull). Hier gleicht die Plattform einem hochmodernen Fitnessstudio, das die Entwickler:innen aus eigenem Antrieb nutzen, weil es sie in ihrer Arbeit besser macht und einen klaren Mehrwert bietet.
• Interfaces: Der Spielplan
  Wie interagieren Nutzer:innen mit der Plattform? Der Weg führt von chaotischen, manuellen Prozessen, bei denen der Coach nur Anweisungen von der Bank zuruft (Provisional), über standardisierte Vorlagen hin zu Self-Service-Lösungen. Diese gleichen dem persönlichen digitalen Spielbuch eines Spielers (Scalable) auf einem Tablet, das sie befähigt, während des Spiels selbstständig auf Situationen zu reagieren.
• Operations: Der Körper des Spielers
  Dieser Aspekt umfasst den gesamten Lebenszyklus eines Plattform-Services. Die Entwicklung geht von rein reaktiver Fehlerbehebung – der Spieler muss eine Verletzung auf der Bank selbst versorgen (Provisional) – über zentrales Tracking hin zu proaktiven Massnahmen zur Verletzungsprävention (Scalable), wie Physiotherapie, um Probleme zu verhindern, bevor sie überhaupt entstehen.
• Measurement: Die Spielerentwicklung
  Hier wird der Prozess zur Sammlung von Feedback und zur Lernfähigkeit beschrieben. Dies reicht von informellen Befragungen – der Trainer fragt im Vorbeifahren: «Wie fühlt es sich an?» (Provisional) – bis hin zur Gewinnung tiefer Einblicke. Ähnlich wie nach einem Spiel werden hier die reinen Statistiken mit der Videoanalyse kombiniert (Scalable), um das Warum hinter den Daten zu verstehen und die Entwicklererfahrung proaktiv zu steuern.

Ohne Teamstruktur kein Erfolg

Die Organisationsstruktur – und damit der Kommunikationsfluss – und die Architektur entwickelter Systeme sind untrennbar miteinander verbunden – das besagt Conway’s Law. Um diesen Zusammenhang bewusst zu gestalten, kann man sich an den Ideen aus dem Buch «Team Topologies» orientieren. Dabei werden nicht nur klare Team-Typen definiert, sondern auch die Art und Weise, wie sie miteinander interagieren – ihre Interaktionsmodi.

Um es anschaulich zu machen, übertragen wir das Ganze auf eine gut aufgestellte Eishockeymannschaft. Die Team-Typen lassen sich wie folgt verteilen:

• Die Platform Teams sind das Stadion-Management: Sie kümmern sich um Infrastruktur, Eisqualität, Licht und Ton – damit die Spieler:innen performen können.
• Die Enabling Teams sind die Trainer:innen: Sie helfen bei neuen Methoden, geben Feedback, trainieren.
• Die Stream-aligned Teams sind die Spieler:innen: Sie stehen auf dem Eis, schiessen Tore und holen die zahlenden Fans ins Stadion.

Doch klar definierte Teams allein genügen nicht. Entscheidend ist auch die Art der Zusammenarbeit – die Interaktionsmodi. Sie legen fest, wie sich die unterschiedlichen Teams unterstützen und wie die Kommunikation zwischen Spielern, Trainern und Stadion-Management konkret abläuft. Um nicht nur das Spiel, sondern die Meisterschaft zu gewinnen.

Fazit: Platform Engineering ist Teamsport! Egal ob du eine Meisterschaft gewinnen oder grossartige Software liefern willst. Es braucht ein starkes Team. Platform Engineering ist der strategische Aufbau dieses Teams mit klaren Rollen, guten Tools und einer Plattform, die allen hilft, ihr Bestes zu geben.

Mehr Informationen zur Analogie im Talk!

An der Cloud Native Zürich 2025 hielt ich gemeinsam mit Daniel Binggeli einen Talks zum Thema «What Platform Engineering and Ice Hockey Have in Common?». Den ganzen Vortrag kannst du hier im Video nachschauen.