Was sind die Schienen Ihrer SAFe Agile Release Trains? Wie werden sie gebaut, und warum sind sie so entscheidend? In diesem Vortrag am SAFe Leadership Forum zeige ich, wie Platform Engineering das Fundament schafft, das agilen Teams ermöglicht, kontinuierlich Wert für Fast Flow zu liefern.
Die Herausforderung: Kognitive Belastung in SAFe#
Die Continuous Delivery Pipeline im SAFe-Framework enthält alle Workflows, Aktivitäten und Automatisierungen, die agile Teams benötigen. Das ist bereits sehr viel. Aber es wird noch schlimmer. In SAFe praktizieren Teams “You build it, you run it”, was bedeutet, dass jeder Agile Release Train Infrastruktur (Cloud oder On-Premise), Laufzeitumgebungen wie Docker oder Kubernetes, CI/CD-Tools wie GitLab oder CircleCI, Monitoring mit Prometheus oder Dynatrace, Security-Scanning mit Snyk oder SonarQube und Kollaborationstools wie Jira oder Confluence benötigt.
In grossen Organisationen mit mehreren ARTs unterhält jeder seinen eigenen Continuous Delivery Pipeline. Das führt zu Inkonsistenzen, einer explodierenden Tool-Landschaft und einer kognitiven Belastung, die für die Teams schlicht zu hoch ist. Ihr Fokus verschiebt sich vom Entwickeln von Lösungen zum Verwalten von Infrastruktur.
Team Topologies und SAFe zusammengedacht#
2019 veröffentlichten Matthew Skelton und Manuel Pais “Team Topologies”, was einen enormen Einfluss auf die Organisation von Teams hatte. Sie identifizierten vier grundlegende Topologien: Stream-aligned Teams, die an einer Produktdomäne arbeiten, Enabling Teams, die anderen helfen, Hindernisse zu überwinden, Complicated Subsystem Teams und Platform Teams, die Fähigkeiten für alle anderen Teams bereitstellen.
Wenn wir diese Topologien mit SAFe kombinieren, wird das Bild klar. Innerhalb eines Agile Release Trains gibt es agile Teams (Stream-aligned), ein System Team (Enabling) und ein Platform Team. Für grössere Organisationen mit mehreren ARTs kann es sogar sinnvoll sein, einen dedizierten Platform ART mit 50 bis 120 Personen aufzubauen.
Die Plattform als internes Produkt#
Das Platform Team entwickelt ein internes Produkt. Die Kunden dieses Produkts sind die agilen Teams und ARTs. Die Plattform stellt alle Werkzeuge und Fähigkeiten bereit, die diese Teams zum Erstellen ihrer Lösungen brauchen: Observability, Security, CI/CD, Infrastruktur-Provisionierung und mehr.
Eine entscheidende Unterscheidung: Das Platform Team macht nicht das Monitoring für die Teams. Es stellt die Fähigkeit des Monitorings bereit. Die Teams selbst nutzen diese Werkzeuge, um ihre Lösungen zu überwachen, weil sie DevOps praktizieren. Sie bauen es, sie betreiben es. Das Platform Team generiert Wert für die agilen Teams, und die agilen Teams generieren Wert für ihre Kunden.
“Das Platform Team gibt den Teams nur die Fähigkeit. Das Ausführen liegt bei den Teams, weil sie DevOps praktizieren.”
Architekturprinzipien: Die schwebende Plattform#
Beim Aufbau einer solchen Plattform sind zwei Konzepte entscheidend. Erstens: Verwenden Sie Adapter für jedes Tool, das Sie integrieren. In meinen 22 Jahren Karriere habe ich ständig gesehen, wie Tools kamen und gingen. Man weiss nie, wie lange GitLab, GitHub oder ein anderes Tool bestehen bleibt. Mit Adaptern können Sie Tools einfach austauschen, ohne die Teams zu beeinträchtigen.
Zweitens: Folgen Sie dem “Floating Platform”-Konzept von Gregor Hohpe aus seinen Büchern über Plattformstrategie und Cloud-Strategie. Die Idee: Bauen Sie eine Plattform mit ausgezeichneter Developer Experience, integrieren Sie alle Tools und Cloud-Anbieter, aber abstrahieren Sie sie niemals weg. Duplizieren Sie keine Features. Wenn Sie das tun, wird Ihre Plattform in die Tiefe gezogen und beginnt zu sinken. Eine schwebende Plattform schwebt über den Tools und macht sie auf eine kontrollierte, strukturierte Weise zugänglich.
Live-Demo: Die Plattform in Aktion#
Während des Vortrags habe ich eine Plattform demonstriert, die wir gemeinsam mit der LGT aufgebaut haben, einer Privatbank aus Liechtenstein. Diese Plattform, die wir Zühlke Platform Plane nennen, zeigt, wie eine moderne interne Entwicklerplattform aussieht:
- Self-Service-Portal: Teams können Repositories erstellen, Datenbanken bereitstellen und Anwendungen deployen, ganz ohne Tickets oder Wartezeiten.
- Single Sign-On: Ein Login gibt Zugang zu allen Tools. Kein Jonglieren mehr mit verschiedenen Konten und Passwörtern.
- Spaces: Jedes Projekt oder Produkt erhält seinen eigenen Space, hinterlegt mit einem Kubernetes-Cluster. Eigentümer können Teammitglieder in Sekunden onboarden und offboarden.
- Partner-Konzept: Externe Partner bringen ihre eigene Identität mit, werden über Microsoft Entra integriert und können ihre Teams selbst verwalten.
- KI-gestützte Features: Ein KI-Assistent beantwortet Dokumentationsfragen, analysiert Docker-Images und hilft bei der Log-Analyse. Wenn alles auf einer Plattform vereint ist, wird die Erstellung solcher KI-Anwendungsfälle einfach.
- FinOps: Kostenverfolgung ist integriert, damit Teams sehen, was ihre Anwendungen kosten, und entsprechend optimieren können.
- Security-Scanning: Alle Repositories und Container-Images werden kontinuierlich auf Schwachstellen gescannt, mit vollständiger Nachverfolgbarkeit.
“Wenn ein Entwickler eine Anwendung deployt, bekommt er automatisch Monitoring, Logging, Dashboards, einfach alles. Er muss sich um nichts davon kümmern. Das ist die Kraft einer solchen Plattform.”
Warum Platform Engineering für SAFe wichtig ist#
Gartner identifiziert Platform Engineering als einen der Top-Technologietrends, und McKinsey sowie BCG stimmen zu. Sie prognostizieren, dass 75 % der Organisationen in Zukunft eine solche Plattform haben werden. Im Kontext von SAFe ist diese Plattform nichts weniger als Ihre Continuous Delivery Pipeline: die Schienen für Ihre Agile Release Trains.
Das Platform Engineering Team erstellt die Plattform als internes Produkt. Es ist ein Self-Service-Portal mit allen Fähigkeiten und Werkzeugen, die agile Teams brauchen, um ihre Lösungen zu erstellen. Damit wird die Plattform zum Fundament Ihrer gesamten SAFe-Transformation.
Kernaussagen#
- Kognitive Belastung ist der Engpass: Wenn jeder ART seine eigenen Tools und Infrastruktur verwaltet, wird die Komplexität unbeherrschbar. Platform Engineering löst dieses Problem.
- Team Topologies und SAFe passen zusammen: Platform Teams in SAFe liefern das Fundament, das Stream-aligned Teams brauchen, um sich auf die Wertschöpfung zu konzentrieren.
- Die Plattform ist ein internes Produkt: Behandeln Sie sie wie ein Produkt mit internen Kunden. Das Platform Team baut sie, die agilen Teams nutzen sie.
- Adapter und schwebende Plattform: Integrieren Sie Tools, ohne sie zu abstrahieren. Bleiben Sie flexibel für die Zukunft.
- Self-Service ist unverzichtbar: Kein Ticket-Ops. Teams müssen eigenständig Leute onboarden, Umgebungen erstellen und Anwendungen deployen können.
- KI wird auf einer Plattform einfach: Wenn alle Tools, Daten und Fähigkeiten an einem Ort sind, ist das Erstellen von KI-Anwendungsfällen wie Lego spielen.
- Wir treten in das Zeitalter der Industrialisierung der Softwareentwicklung ein: Platform Engineering macht dies möglich.