Platform Engineering bei Puzzle – mehr als Tools und Technologie

In meinem letzten Blogbeitrag habe ich über Platform Engineering gesprochen – ein ganzheitlicher Ansatz, der die gesamte IT und teils sogar das Unternehmen erfassen kann. Dabei ging es darum, die Voraussetzungen für eine bessere Arbeit der Entwickler:innen zu schaffen und ein Produkt-Mindset für die interne IT zu etablieren.

Heute möchte ich darauf aufbauen. Ich werde über die Platform-Engineering-Initiative bei Puzzle sprechen. Es geht darum, wie wir Teile des Team-Topologies-Ansatzes testen, uns dem Produktgedanken annähern sowie vier Schlüssel zum Erfolg im Platform Engineering nutzen, die uns laut Thoughtworks als Leitplanken dienen.

Team Topologies

Manuel Pais und Matthew Skelton stellen in ihrem Buch Team Topologies vier verschiedene Teamtypen und drei Interaktionsmodi vor, um die Zusammenarbeit in der IT zu optimieren. Ihre Ansätze basieren auf Conways Gesetz, das besagt, dass die Kommunikations- oder Organisationsstruktur eines Unternehmens dessen Systemarchitektur (oder Softwarearchitektur) beeinflusst.

Im Mittelpunkt stehen die Stream-Aligned-Teams: Sie sind darauf ausgerichtet, möglichst fokussiert und effizient Unternehmenswert zu generieren. Sie arbeiten an einem einzigen, wertvollen Arbeitsstrom, um Kunden- oder Benutzerwert so schnell, sicher und unabhängig wie möglich zu liefern. Um dies zu ermöglichen, gibt es drei weitere Teamtypen: Das Plattform-Team stellt Infrastruktur als Service bereit, die Enabling-Teams bieten situative Unterstützung und die Complicated-Subsystem Teams kümmern sich um spezifische Nischenangelegenheiten mit hoher Komplexität.

Die Interaktion zwischen diesen Teams erfolgt in drei klar definierten Modi: X-as-a-Service, Kollaboration oder Facilitating.

Team Topologies bei Puzzle

Bei Puzzle arbeiten Software-, System- sowie Platform-Engineers gemeinsam mit UX-Spezialist:innen und Projektleitenden sowohl inhouse als auch in Kundenmandaten. Die interne Zusammenarbeit rund um die Plattform orientiert sich dabei an den Prinzipien von Team Topologies.

Das Platform-Engineering-Team selbst ist eine Zusammenführung von Container- & CI/CD-Engineers. Obwohl es heute offiziell als ein Team agiert, werden gewisse Aspekte noch aus legacy Organisationsstrukturen gehandhabt – eine Situation, deren Dauer noch evaluiert wird. Dieses Plattform-Team stellt das zentrale Element bereit: eine Kubernetes-Plattform. Sie dient als Basis für nahezu alle intern genutzten Services (wie z.B. das CRM) und wird von den Entwickler:innen für ihre Deployments genutzt. Das übergeordnete Ziel ist es, für alle Engineers Komplexität zu abstrahieren, Abläufe zu automatisieren und Self-Service zu ermöglichen. Um die Plattform stetig zu verbessern, erfragt das Team – unterstützt durch UX-Spezialist:innen – die Zufriedenheit und Wünsche der Stakeholder. Wie aus den Blogbeiträgen «Wenn Entwickler:innen weniger fluchen und mehr lieben – Platform Love mit DevEx und Platform Engineering» und «Von UX-Umfragen zum Backstage-MVP zur ganzheitlichen Developer Experience bei Puzzle» hervorgeht, schliesst dies neben technischen Nutzer:innen auch Ansprechgruppen wie CTO und CFO mit ein.

Im Sinne der Team Topologies nehmen verschiedene spezialisierte Gruppen bei Puzzle spezifische Rollen ein:

• Das UX-Team fungiert als Complicated-Subsystem-Team. Es hilft den Engineers, die Bedürfnisse der Kund:innen abzuholen, indem es Interviews facilitiert, die gesammelten Daten konsolidiert und diese zu aufschlussreichen Berichten bündelt.
• Die Engineers mit CI/CD-Fokus (auch ein Teil des Platform-Engineering-Teams) agieren als Enabling-Team. Sie unterstützen Entwickler:innen beim individuellen Aufbau und der Implementierung von CI/CD-Pipelines mit Best Practices sowie Knowhow und bieten dabei kollaborative Unterstützung. Im Zusammenhang mit der Plattform interagieren sie zudem ebenfalls im Modus X-as-a-Service. Ultimativ wird das Ziel eines kompletten Self-Service verfolgt. Die Nähe zu den Usern sowie die Anwendung unterschiedlicher Kollaborations-Modi stärken dabei einen kunden- oder produktzentrierten Mindset.
• Eine weitere Expertengruppe an Engineers widmet sich dem Thema Observability. Sie sind die Anlaufstelle für sämtliche Themen rund um die Beobachtbarkeit über den kompletten Plattform-Stack hinweg. Auch sie fungieren als Enabling-Team, das je nach Anforderung in Kollaboration arbeitet oder Plattformfähigkeiten als X-as-a-Service bereitstellt.

Bei Puzzle befinden wir uns momentan in einer Phase, in der wir vieles ausprobieren, hinterfragen und lernen – und dies geschieht bewusst gemeinsam mit den einzelnen Engineers. Dieser Approach mag bei der Umsetzung zwar etwas mehr Zeit in Anspruch nehmen, doch zeigt sich bereits jetzt eine hohe Akzeptanz und starkes Involvement der Mitarbeitenden. Davon versprechen wir uns eine fliessendere und nachhaltigere Transformation in Richtung echtem Platform Engineering.

Vier Schlüssel zum Platform-Engineering-Erfolg (nach Thoughtworks)

Bevor wir tiefer in unsere Puzzlespezifische Umsetzung eintauchen, lohnt sich ein Blick auf die von Thoughtworks definierten Erfolgsfaktoren des Platform Engineerings.

Diese vier Punkte passen erstaunlich gut zu unseren Erfahrungen und Zielen. Unsere bisherigen Erkenntnisse bei Puzzle bestätigen die Relevanz dieser Schlüssel.

1. Teamstruktur & Arbeitsweisen vor Tools priorisieren: Es ist verlockend, sofort die neuesten, glänzendsten Tools einzuführen. Aber Platform Engineering ist kein Tool-Problem – es ist ein soziotechnisches Problem. Viel wichtiger ist es, die richtigen Teamstrukturen (Hallo, Team Topologies!) und Kollaborationsmodi zu etablieren. Wie arbeiten Teams zusammen? Wer ist wofür verantwortlich? Erst wenn das klar ist, können Tools ihre volle Wirkung entfalten und nicht nur neue Silos schaffen.
2. Observability ermöglichen: Man kann nur verbessern, was man sieht! Eine erfolgreiche Plattform macht nicht nur die darunterliegende Infrastruktur, sondern auch die darauf laufenden Applikationen beobachtbar. Das bedeutet: Zentrales Logging, Metriken und Tracing müssen einfach zugänglich sein – sowohl für das Plattform-Team (um die Plattform zu optimieren) als auch für die Entwickler:innen (um ihre Apps zu debuggen und zu verstehen). Ohne Transparenz stochern alle im Nebel.
3. Den Erfolg der Plattform messbar machen: Bauchgefühl ist gut, Daten sind besser. Um den Wert der Plattform (auch gegenüber dem Management, Stichwort CFO!) zu belegen und die richtigen Prioritäten zu setzen, brauchen wir Metriken. Das können klassische DORA-Metriken sein, aber auch Dinge wie die Time-to-Onboard, die Entwicklerzufriedenheit oder die Adoptionsrate neuer Services. Messbarkeit schafft Vertrauen und lenkt den Fokus auf das Wesentliche: den Wertbeitrag.
4. Entwickler:innen befähigen & Produktivität steigern: das ultimative Ziel! Es geht nicht darum, Entwickler:innen Arbeit abzunehmen, sondern sie zu befähigen, produktiver zu sein und sich auf das zu konzentrieren, was wirklich zählt: Business Value liefern. Das erreichen wir durch Reduzierung der kognitiven Last, Self-Service-Angebote, klare «Golden Paths», Automatisierung und die Bereitstellung von Tools, die wirklich helfen und nicht im Weg stehen. Empowerment statt Bevormundung.

Diese vier Punkte passen meiner Meinung nach gut als Basis-Fokus für eine erfolgreiche Transformation in Richtung Platform Engineering. Sie zeigen auch, warum ein «Product Mindset» so entscheidend ist.

Product Mindset aufbauen

Kundenzentriertes Denken gilt nahezu als ein Synonym für Produktmanagement. Leider sind wir fast schon am Punkt, an dem «Produkt» und «Plattform» zusammen als Schimpfwörter betrachtet werden. Dies ist meiner Meinung nach allein dem mangelnden Produktverständnis sowie dem zu universell verwendeten Plattform-Engineering-Begriff geschuldet.

Grundsätzlich ist es überall dasselbe, aber insbesondere in dezentralen Teams oder Organisationen mit flachen Hierarchien: Ohne Vision und Roadmap wird es schwierig. Bei Puzzle steht «changing IT for the better» auf der Fahne. Und genau das wollten wir mit einer daraus abgeleiteten Vision für unser Platform Engineering Team weiterverfolgen:

«Wir befähigen Menschen und Unternehmen, indem wir Plattformen und Services entwickeln, die effiziente Workflows ermöglichen und eine Kultur der Zusammenarbeit stärken. So schaffen wir messbaren, nachhaltigen Wert, erleichtern die Arbeit der Engineers und maximieren den IT-Beitrag zur Wertschöpfung.»

Mit dieser Vision, ein bisschen Extra-Effort und einem sich entwickelnden neuen Mindset ist es schier unmöglich, stehenzubleiben. Unsere Roadmap gestaltet sich daher flexibel und kann auf Veränderungen gut reagieren. Sie kann sich je nach Feedback und neuen Erfahrungen weiterentwickeln oder gar komplett neu aufbauen. Basierend auf unseren beiden internen Untersuchungen (siehe Links zu den Blogbeiträgen weiter oben) und einer darauf folgenden Team-Retro haben wir folgende Punkte definiert, wie wir uns unserer Vision annähern können. Wichtig dabei ist zu verstehen, dass wir uns sowohl als Menschen, in unseren Workflows, als auch als Plattform-Engineering-Team weiterentwickeln müssen, wenn wir auch die nächsten fünf bis zehn Jahre zufrieden und erfolgreich sein wollen. In den nachstehenden sechs Punkten wird die Verbindung zu den obengenannten vier Schlüsseln deutlich:

• Definition der Rolle & Einführung eines Plattform POs (Schlüssel 1 & 3)
  Klarere Priorisierung und strategische Ausrichtung bei der Weiterentwicklung der Plattform und ihrer Fähigkeiten. Dies führt zu einer stärkeren Orientierung an den Nutzerbedürfnissen und einer insgesamt gesteigerten, messbaren Wertschöpfung durch die Plattform. Der Plattform PO wird für die Plattform-Roadmap zuständig sein.
• Plattform Status Quo eruieren (Schlüssel 3)
  Paralell zur Einführung eines Plattform POs arbeiten wir an der Auflistung der Toollandschaft und deren Kategorisierung. Dies soll dem Plattform-Team dabei helfen, ein gemeinsames Bild zum IST-Zustand zu erlangen. Basierend darauf können Verantwortlichkeiten geklärt und verteilt werden und eine Plattform-Roadmap ausgearbeitet werden. Getreu dem Motto: Erklär mir nicht, wohin ich gehen muss, stattdessen zeige mir, wo ich starten muss.
• Erarbeitung Golden Path / Plattform Starter Guide (Schlüssel 4)
  Neue Mitarbeitende können unsere Plattform schneller produktiv nutzen, was die Developer Experience von Beginn an verbessert und die Etablierung von Best Practices fördert. Gleichzeitig können auch bestehende Teams neue Projekte beschleunigt starten.
• Prüfung der Rolle eines Community-Managers (Schlüssel 1)
  Bessere Zusammenarbeit und Wissensaustausch zwischen den unterschiedlichen Divisions bei Puzzle, Aufbrechen von Silos durch die Förderung einer lebendigen internen Community rund um die Plattform. Dies soll auch die Feedbackschleifen zum Plattform-Team stärken, die Adoption von Services und Best Practices beschleunigen sowie eine Kultur der gemeinsamen Weiterentwicklung etablieren.
• Issue-Tracking / Übersicht verbessern (Schlüssel 1 & 4)
  Es herrscht Einigkeit darüber, dass gut beschriebene Issues und ein übersichtliches Board dabei helfen, effizient zu arbeiten. Trotzdem tun sich so viele schwer, es richtig umzusetzen. Ein kleines Gremium an Engineers hat die Aufgabe übernommen, eine Lösung zu erarbeiten. Ziel: leichtere Zusammenarbeit, bessere Transparenz und Nachvollziehbarkeit.
• Neuaufbau unseres Servicekatalogs in Backstage (Schlüssel 2 & 4)
  Gesteigerte Transparenz über das Serviceangebot und klare Verantwortlichkeiten, was die Auffindbarkeit von Ressourcen verbessert, die Selbstbedienung erleichtert und die allgemeine Entwickler-Effizienz erhöht. Ein guter Servicekatalog ist auch ein Schritt in Richtung besserer Observability. Ein entscheidender erster Schritt ist dabei die klare Definition, was unser Servicekatalog überhaupt alles beinhalten soll.

Zusammenfassung und Ausblick: Der Team-Puls schlägt …

Die Reise hin zu einem echten Platform Engineering ist, wie wir sehen, mehr als nur Technologie. Es geht um Menschen, Workflows und natürlich auch um Tools – aber eben in der richtigen Reihenfolge. Die vier Schlüssel von Thoughtworks – Team und Arbeitsweisen vor Tools, echte Observability, messbarer Plattformwert sowie Developer Experience – bieten dafür eine hervorragende Orientierung.

Bei Puzzle spüren wir, dass wir mit unserem Fokus auf Team Topologies, dem Product Mindset und den konkreten Roadmap-Punkten genau diese Schlüssel adressieren. Es braucht Zeit, bis alle vom Gleichen sprechen, die Vision verinnerlicht haben und wissen, wohin die Reise geht. Aber wir sind an einem Punkt, an dem die Diskussionen zeigen: Das Verständnis wächst, der Mindset entwickelt sich.

Es sind genau diese Tage, an denen spürbar wird, dass wir als Team zusammenwachsen und die Prinzipien leben, die die vielen Learnings, Fehler und Diskussionen wertvoll machen. Der Antrieb für Veränderung entsteht oft, wenn Dinge noch nicht optimal laufen. Die Fortschritte zeigen, dass sich der Einsatz lohnt, IT wirklich besser zu machen.

Wie eine grosse Persönlichkeit einmal sagte: Stay hungry. Stay foolish.

Welches sind deine bisherigen Erfahrungen in deiner Reise nach Platform Engineering? Wie nimmst du dein Team mit dem technologischen Wandel mit? Welches sind deine grössten Herausforderungen?

Auf einen Austausch mit dir zu diesem Thema würde ich mich enorm freuen.