Pragmatische Evolution von Platform Engineering für die Cloud

Die Entwicklungsteams werden durch die wachsende Komplexität der Cloud-Umgebungen und die Notwendigkeit, kontinuierlich neues Wissen zu erwerben, ausgebremst statt beschleunigt. Hinzu kommen zusätzliche Herausforderungen wie die Gewährleistung von Compliance, Kostenoptimierung sowie Datenschutz und Sicherheit. Der Weg zurück zu einem traditionellen, Ticket-basierten Betriebsmodell, das eine sichere und kostenoptimierte Konfiguration von Betriebsumgebungen sicherstellt, aber Entwicklungsteams oftmals ausbremst, wirkt allerdings wie ein Rückschritt.

Platform Engineering

Platform Engineering schlägt hier einen Mittelweg ein, indem es standardisierte Plattformdienste bereitstellt, die es den Entwicklungsteams ermöglichen, selbstständig die benötigten Ressourcen zu provisionieren und zu verwalten. Durch die Bereitstellung wiederholbarer Muster und Best Practices reduziert es die Komplexität und ermöglicht den Entwicklerteams, sich auf die Implementierung von Geschäftslogik zu konzentrieren, statt wertvolle Zeit in die Einrichtung und Wartung von Infrastruktur zu investieren. Gleichzeitig werden Governance, Compliance und Kostenüberwachung auf Plattformebene integriert. Somit fungiert Platform Engineering als Katalysator, um Entwicklungsgeschwindigkeit, Flexibilität und Innovationsfähigkeit signifikant zu steigern, ohne die Kontrolle zu verlieren.

Platform Engineering für die Cloud ist somit weit mehr als nur eine technische Disziplin; es ist eine strategische Entscheidung. Dabei reicht es nicht aus, sich allein auf technische Aspekte wie eine passende Architektur und neue Infrastruktur-Technologien zu fokussieren. Es müssen auch organisatorische Aspekte betrachtet werden. Wie Gregor Hohpe treffend formuliert: Der Gang in die „Cloud ist ein Lifestyle Change“ Hoh21.

Cloud Native Maturity Matrix

Ein hilfreiches Werkzeug, um die Reise in die Cloud zu planen, ist das Reifegradmodell: Cloud Native Maturity Matrix Rez18. Reifegrad-Modelle sind, wie der britische Statistiker George Box 1976 sagte, nicht perfekt, aber sie können nützlich sein. Die Matrix besteht aus zwei Dimensionen: Die x-Achse zeigt, wo man auf der Reise steht, während die y-Achse die verschiedenen Themen abbildet, die zu berücksichtigen sind.

Eines vorweg: Natürlich gibt es erfolgreiche Unternehmen, die sich in der blauen Zone befinden. In diesem Beispiel wenden sie gerade so agile Methoden an, arbeiten in einem hierarchischen Umfeld mit geplanten Release-Zyklen und betreiben ihre Software auf eigenen Bare-Metal-Servern. Solche Unternehmen können erfolgreich sein, weil ihre Kultur und Prozesse genauso konservativ gestaltet sind wie ihre betriebliche Infrastruktur. Wenn ein solches Unternehmen allerdings das strategische Ziel verfolgt, in die pinke Zone zu gelangen, um „Cloud-native“ zu werden, bedeutet das eine massive Transformation auf allen Ebenen.

Am Beispiel der Cloud Native Maturity Matrix kann das bedeuten, eine kollaborative Kultur zu forcieren, in der datengetriebene Produktentwicklung gelebt wird. Die Softwarearchitektur ist möglicherweise modularisiert, um unter anderem von den Vorteilen des Cloud-Betriebs mit Containern zu profitieren.

Wenn man diese Matrix betrachtet, könnte der falsche Eindruck entstehen, dass Unternehmen nur dann „Cloud-native“ sein können, wenn sie Microservices mit Kubernetes in einer kollaborativen Unternehmenskultur betreiben. Vielmehr möchten die Autoren dieser Matrix ausdrücken, dass eine moderne Infrastruktur allein noch keine Cloud-native-Vorteile bringt. Eine Organisation, die konservative Methoden in der Produktentwicklung einsetzt, wird bei der Adaption von Cutting-Edge-Technologien vermutlich nicht erfolgreich sein. Vorherrschende konservative Organisationsstrukturen würden sich dagegen wehren und Architekturen nicht zur Technologie passen. Beispielsweise sind Continuous Deployment und der Betrieb von eigenen Kubernetes-Clustern viel zu komplex, wenn es keine DevOps-getriebene Entwicklungskultur oder kein Know-how zu Site Reliability Engineering [Bey16] im Unternehmen gibt.

Kurz gesagt: Wenn ein Unternehmen in einer der Dimensionen zu weit zurückliegt, nützt es nicht, in anderen Bereichen voranzupreschen. Der Engpass bestimmt die Geschwindigkeit des Gesamtsystems (Theory of Constraints). Es ist wichtig zu verstehen, dass ein Reifegrad-Modell dabei hilft, den richtigen Lernpfad zu beschreiten. Heutzutage werden solche Modelle oft dazu verwendet, Organisationen oder sogar einzelne Teams zu bewerten, aber das ist nicht der richtige Ansatz. Vielmehr ist es ein Werkzeug, um die nächsten Evolutionsschritte zu planen.

Die Cloud Native Maturity Matrix verdeutlicht, dass der Weg in die Cloud ein mehrdimensionaler Prozess ist, der potenzielle Engpässe berücksichtigt. Es ist nicht immer ein geradliniger Weg, sondern oft ein iterativer Prozess des Lernens und Anpassens.

Szenario: Die Cloud-Reise von Outfitprint

Um die Herausforderungen und Lösungsansätze des Platform Engineerings in der Cloud besser zu veranschaulichen, werfen wir einen Blick auf das fiktive Unternehmen Outfitprint. Das Unternehmen hat sich auf individuell bedruckte Kleidung spezialisiert. Bis vor 15 Jahren waren sie ein reines Filialgeschäft, bei dem Kunden die Grafiken und das Material vor Ort auswählten. Die IT-Abteilung spielte zu dieser Zeit keine große Rolle und wurde als reines Costcenter betrachtet. Das Hauptziel war es, die Betriebskosten gering zu halten. Dann begann Outfitprint mit den ersten Schritten im Onlinehandel. Allerdings stieß das Unternehmen bald mit steigender Last an betriebliche Grenzen ihrer Standard-E-Commerce-Lösung. Die Hardwarebeschaffung und -erweiterung wurden komplizierter. Damit wurde auch die Verfügbarkeit von Infrastruktur und Operation Engineers zu einem großen Problem. Diese Herausforderungen und ständiges Firefighting im Betrieb haben dazu geführt, dass sich das Unternehmen für den Betrieb in der Public Cloud entschieden hat.

Wenige Jahre darauf entschied sich Outfitprint zusätzlich, zu einem Technologieunternehmen zu werden. Seitdem hat sich die IT-Landschaft von Outfitprint stark weiterentwickelt. Die Betriebsabteilung wurde zur Platform-Engineering-Abteilung mit mehreren spezialisierten Teams, die sich um Betrieb, Observability und CI/CD kümmern. Daraufhin wurden eine Betriebsplattform, Observability-Infrastruktur, CI/CD-Tooling und ein Secret-Manager eingeführt. Allerdings treten noch heute immer wieder Probleme auf, wie beispielsweise Ausfälle des Build-Servers oder Kapazitätsprobleme. Das Platform Engineering ist aufgrund der Annahme, dass Managed-Cloud-Services den Bedarf an menschlicher Kompetenz verringern würden, geschrumpft, obwohl der Arbeitsaufwand weiterhin hoch ist. Zusätzlich gibt es viele Entwicklungsteams, die auf Unterstützung warten.

Um die Wartezeiten zu verringern, ermöglicht das Platform Engineering den Entwicklungsteams, auf Anfrage sich selbst die benötigte Infrastruktur, wie beispielsweise Datenbanken, zu beschaffen. Dazu erhält jedes Entwicklungsteam einen großzügigen Zugang zur Cloud-Konsole. Allerdings sind die Teams oft unsicher, welche Lösung für ihre spezifischen Anforderungen am besten geeignet ist, und benötigen weiterhin Unterstützung. Um diesem Bedarf gerecht zu werden, bietet das Platform Engineering Interview-Sessions und Beratung an. Obwohl dieser Ansatz kurzfristig zeitintensiv ist, zahlt er sich mittelfristig aus: Die Entwicklungsteams erweitern kontinuierlich ihr Wissen und ihre Fähigkeiten, wodurch sie zunehmend selbstständiger agieren können und das Platform Engineering entlastet wird.

Reise der Platform-Engineering-Abteilung

Wie lassen sich diese Herausforderungen pragmatisch angehen? Welche Fallstricke gilt es zu vermeiden? Im Folgenden wird die Reise der Platform-Engineering-Abteilung näher beleuchtet. Ziel ist es, ihre Herausforderungen zu lösen und das Plattformangebot zu verbessern. Dabei werden die gewonnenen Erkenntnisse und mögliche Lösungsstrategien diskutiert. Bei der Betrachtung der Situation von Outfitprint fallen einige Herausforderungen ins Auge: Die Kosten sind unerwartet stark gestiegen und es gibt offensichtliche Flaschenhälse in den Prozessen. Dabei können nicht alle Probleme auf einmal gelöst werden. Stattdessen sollte man sich Schritt für Schritt an die drängendsten Herausforderungen herantasten und passgenaue Maßnahmen entwickeln, die zur Reife und Historie des Unternehmens passen. Es sollte nicht mit großen Änderungen überfordert werden.

Hohe Kosten in der Public Cloud

Bei Outfitprint herrscht ein Missverständnis darüber, dass eine Cloud-Migration automatisch zu Kosteneinsparungen führt. Tatsächlich sind die reinen Infrastrukturkosten in der Public Cloud oft höher als On-premises. Der Mehrwert liegt vielmehr in der gewonnenen Flexibilität und der Möglichkeit, sich auf das Kerngeschäft zu konzentrieren, statt Ressourcen im Betrieb zu binden. Trotz Optimierungsmaßnahmen wie Skalierungsmechanismen und Ressourcenreservierung ist die Nutzung der Public Cloud langfristig oft nicht kostengünstiger als der Betrieb einer On-premises-Cloud im eigenen Rechenzentrum. Zwar können durch die Auslagerung in die Public Cloud Kosten für Miete, Ausstattung und Fachpersonal eingespart werden, doch die höheren Infrastrukturkosten der Public Cloud gleichen diese Einsparungen häufig wieder aus.

Es lohnt sich, die Gründe für eine Entscheidung zugunsten der Public Cloud genauer zu betrachten. Insbesondere für Unternehmen, die sich noch in der Anfangsphase der Produktentwicklung befinden, bietet die Public Cloud entscheidende Vorteile. Das primäre Ziel in dieser Phase ist die Validierung des Produkts und des Geschäftsmodells. Hierfür ist es oft nicht sinnvoll, eigenes Fachpersonal und die Infrastruktur eines Rechenzentrums vorzuhalten. Stattdessen kann durch die Nutzung von Public-Cloud-Services die Komplexität ausgelagert werden, die nicht zum Kerngeschäft gehört.

Sobald ausreichend Erfahrung und Expertise aufgebaut wurden, kann der Wechsel zu einer eigenen On-premise-Cloud in Betracht gezogen werden. Durch den Betrieb in einem unternehmenseigenen Rechenzentrum lassen sich die anfänglich höheren Investitionen in die Public Cloud mittelfristig amortisieren. Als Faustregel gilt: In Phasen der Unsicherheit, etwa beim Aufbau neuer Produkte und Dienste, ist die Nutzung einer Public Cloud oft die beste Wahl. Sind hingegen die Anforderungen und der Ressourcenbedarf gut planbar, kann die Investition in eine eigene Infrastruktur langfristig wirtschaftlicher sein.

Kasten 1: Kostenoptimierung muss organisatorische Aspekte berücksichtigen

Auf den ersten Blick scheinen die Maßnahmen zur Kostenoptimierung rein technischer Natur zu sein, doch sie beinhalten auch organisatorische Aspekte. Obwohl die Entwicklungsteams aufgrund ihres Zugriffs auf die Infrastruktur die Kostenoptimierungen selbstständig hätten umsetzen können, ist eine Beratung vom Platform Engineering erforderlich.

Zum einen, um sicherzustellen, dass diese Maßnahmen tatsächlich ergriffen werden, und zum anderen, um die Entwicklungsteams bei der korrekten Implementierung zu unterstützen. Denn es sollte nicht außer Acht gelassen werden, dass diese Maßnahmen nicht zum üblichen Know-how von Entwicklungsteams gehören.

Strategie: Selfservice-Plattform

Ein weiteres Missverständnis betrifft die Notwendigkeit einer internen Selfservice-Plattform. Nicht immer ist der Aufbau einer solchen Plattform erforderlich. In manchen Fällen kann die Nutzung einer Managed Application Platform wie Heroku Her ausreichen. Heroku ist das Paradebeispiel einer hochabstrahierten Applikationsplattform, auf deren zugrunde liegende Infrastruktur Nutzende nicht zugreifen können. Diese Plattform bietet Deployments von Anwendungen, die Nutzung verschiedener Persistenz-Produkte, umfassendes Monitoring und viele andere komplementäre Dienste an, die einfach zu nutzen und hochgradig integriert sind. Solche Plattformen sind zwar nicht billig, ersparen jedoch den Aufwand für den Aufbau und die Betreuung einer eigenen Lösung. Allerdings sind solche Plattformen eher in kleineren Softwareunternehmen, Projekten und Start-ups üblich, da die Kosten bei größeren Unternehmen zu hoch wären.

Klar ist aber auch, dass nicht jedes Unternehmen die Ressourcen hat, einen eigenen Heroku-Klon aufzubauen. Der Schlüssel liegt darin, klein anzufangen und einem klaren Produktgedanken zu folgen: Das Platform Engineering stellt zentrale Services und Infrastruktur bereit, während die Entwicklungsteams nach dem Prinzip „You build it, you run it“ für ihre eigenen Anwendungen verantwortlich sind. Das Plattformteam trägt ähnliche Verantwortlichkeiten wie die Entwicklungsteams. Denn auch eine Plattform ist letztendlich Software, die entwickelt, bereitgestellt, überwacht und im Störungsfall betreut werden muss.

Die Hauptaufgabe des Plattformteams besteht darin, die Verfügbarkeit und kontinuierliche Weiterentwicklung der Plattformdienste sicherzustellen – unabhängig davon, welche konkreten Anwendungen auf der Plattform laufen. Dieses Modell der aufgeteilten Verantwortlichkeiten (Shared Responsibility Model) ähnelt dem Ansatz von Public-Cloud-Services, bei denen eine klar abgegrenzte Aufteilung der Zuständigkeiten zwischen Provider und User besteht.

Selfservice-Plattformen können in verschiedenen Ausbaustufen realisiert werden. Die höchste Abstraktionsstufe ist erreicht, wenn sämtliche Komponenten selbst entwickelt werden und die Plattform vollständig automatisiert ist. Das bedeutet jedoch nicht, dass solche Plattformen auch den größten Erfolg versprechen. Es sind auch deutlich einfachere Ansätze möglich, im Rahmen einer sogenannten Thinnest Viable Platform (TVP), die mit dem Bedarf mitwächst.

So kann eine Plattform beispielsweise lediglich aus einer umfassenden Dokumentation mit Anwendungsbeispielen bestehen, ergänzt durch vordefinierte Templates für Deployments oder durch Runbooks, die bewährte Vorgehensweisen beschreiben.(vgl. Bot18, [Ske19], Seite 184).

Analyse: Umfragen

Wie entscheidet sich nun, welche Ausbaustufe einer Selfservice-Plattform die aktuell richtige für ein Unternehmen ist? Der Ansatz Team Topologies von Matthew Skelton und Manuel Pais [Ske19] gibt darauf eine erfrischend pragmatische Antwort: Man befragt die Entwicklungsteams, welche genauen Tätigkeiten sie aktuell überlasten, die über die reine Entwicklungstätigkeit hinausgehen.GitH

Um herauszufinden, welches Abstraktionsniveau im ersten Schritt für Outfitprint das Richtige ist, empfiehlt es sich, die Entwicklungsteams nach ihrer aktuellen subjektiven Erfahrung mit dem aktuellen Betrieb zu befragen. Eine gezielte Umfrage kann dabei helfen, Unsicherheiten und Herausforderungen zu identifizieren, die über die reine Softwareentwicklung hinausgehen. Ein Beispiel für eine Frage in solch einer Umfrage zeigt Kasten 2.

Kasten 2: Beispiel-Frage, um Unsicherheiten und Herausforderungen zu identifizieren

Wie bewerten Sie Ihre Erfahrungen beim Betrieb der Software?

Berücksichtigen Sie dabei folgende Aspekte: Wissen Sie, wie jeder Service überwacht wird, und haben Sie Zugriff auf die entsprechenden Daten? Werden angemessene Alerts (mit wenigen falsch-positiven Ergebnissen) gesendet? Sind Logs und andere Zustandsinformationen zugänglich und leicht zu finden? Sind Datenflüsse zwischen Services relativ einfach nachzuvollziehen?

[ ] 1 (schlecht)
[ ] 2
[ ] 3
[ ] 4
[ ] 5 (sehr gut)
[ ] Ich bin nicht für Betrieb, Überwachung und Reaktion auf Alerts zuständig
Zusätzlicher Kommentar: (Freitextfeld)

Durch solche Umfragen können wertvolle Erkenntnisse gewonnen werden, die auf den ersten Blick nicht offensichtlich sind. Insbesondere die Freitextfelder bieten Raum für detailliertes Feedback. So kann sich beispielsweise herausstellen, dass das eingesetzte Observability-Tooling nicht die benötigten Metriken liefert, was gerade bei der Behebung von Incidents problematisch sein würde. Um beim Szenario zu bleiben, nehmen wir an, dass die Umfrage bei Outfitprint weitere Probleme identifizieren konnte. Die Entwicklungsteams haben Schwierigkeiten mit der Infrastrukturautomatisierung, insbesondere beim Einsatz von Terraform. Es erfordert sowohl umfangreiches Wissen über das Tooling als auch über den verwendeten Cloud-Provider. Eine mögliche Maßnahme zur Verbesserung besteht darin, Beispielkonfigurationen und bewährte Vorgehensweisen zu dokumentieren und zentrale Terraform-Module für typische Anwendungsfälle bereitzustellen, die weniger Detailwissen erfordern.

Ein weiteres Problem besteht darin, dass die Teams Schwierigkeiten beim Debuggen ihrer Services in der Cloud haben. Hier kann es hilfreich sein, praktische Tool-Schulungen anzubieten, um den Betrieb in der Cloud für die Entwicklungsteams zu erleichtern. Ein großes Problem besteht auch bei der Konfiguration von Datenbanken. Hier fehlt es oft an Kenntnissen darüber, wie die richtige Konfiguration gefunden werden kann. Eine mögliche Lösung besteht darin, eine kleinere Auswahl an Konfigurationsoptionen anzubieten, in sogenannten T-Shirt-Größen, mit nur wenigen speziellen Optionen. Allerdings müssen dabei Kompromisse gemacht werden, da solche eingeschränkten Optionen möglicherweise nicht so effizient oder kosteneffektiv sind.

Analyse: Value-Stream Mapping

Ein weiteres Problem, das bei der Umfrage nicht entdeckt wurde, ist die Identifizierung der Flaschenhälse (Bottlenecks) in einem langsamen Entwicklungsprozess. Hier kann ein Value-Stream Mapping (Wertstromanalyse) helfen. Durch Wertstromanalyse können Engpässe und unproduktive Wartezeiten identifiziert werden, die normalerweise unbemerkt bleiben würden. Es werden dabei alle Schritte einer Wertschöpfungskette quantifiziert und die Zeiten, in denen auf etwas gewartet wird, aufgezeichnet. Abbildung 2 zeigt eine stark vereinfachte Value-Stream Map für den Software-Delivery-Prozess bei Outfitprint. Es wird jeder Schritt, jedes Arbeitspaket einer Wertschöpfungskette quantifiziert. Jeder dieser Arbeitsschritte hat eine eigene Bearbeitungszeit (Lead Time). Um zusätzlich noch Probleme bei der Qualitätssicherung aufzudecken, kann der Prozentsatz der korrekt abgelieferten Arbeitspakete angegeben werden (% Complete & Accurate). Eine essenzielle Information ist jedoch die Wartezeit zwischen den Arbeitspaketen, die den Prozess unnötig verzögern.

Abb. 2: Vereinfachte Darstellung einer Value-Stream Map für den Software-Delivery-Prozess
von Outfitprint — Abb. 2: Vereinfachte Darstellung einer Value-Stream Map für den Software-Delivery-Prozess von Outfitprint

Ein auffälliger Flaschenhals ist die Wartezeit von zwei Tagen vor dem Integration Testing, das selbst nur fünf Minuten dauert. Diese Wartezeit ist länger als die Bearbeitungszeit des gesamten restlichen Prozesses. Der Grund für diese Verzögerung liegt in der notwendigen Koordination und Kommunikation zwischen den Entwicklungsteams, um für kompatible Schnittstellen-Versionen in der Integrationstest-Umgebung zu sorgen. Dieses Problem ist in der Praxis sehr häufig anzutreffen.

Es wird deutlich, dass eine Beschleunigung der einzelnen Arbeitsschritte nur geringe Auswirkungen hat, solange die Wartezeiten bestehen bleiben. Diese Zeitspannen werden auch als „Cost of Delay“ bezeichnet. Eine Verkürzung der Testdauer um eine Minute bringt wenig, wenn vorher zwei Tage auf die Abstimmung gewartet werden muss. Aus dieser Analyse lässt sich für Outfitprint eine weitere Maßnahme ableiten: der Einsatz von asynchroner Integrationstest-Ausführung. Durch den Einsatz asynchroner Integrationstest-Ausführung in Form von Consumer-Driven Contract Testing CDCT können reale Wartezeiten im Software-Delivery-Prozess reduziert werden. Das Platform Engineering kann hier unterstützend tätig werden, indem es die notwendige Infrastruktur und Werkzeuge für eine effiziente asynchrone Testausführung bereitstellt.

Dadurch können Schnittstellen bereits auf Unittest-Ebene validiert werden, was den Bedarf an aufwendig koordinierten synchronen Ausführungen von Integrationstests reduziert. Durch den Einsatz von CDCT erhalten Teams eine klare Übersicht, welche Schnittstellenversionen in den jeweiligen Releases verwendet werden. Im Optimalfall kann sogar die Integrationstest-Umgebung komplett abgeschaltet werden, was zusätzlich zu einer signifikanten Reduktion von Kosten und Koordinationsaufwand führt. Dennoch bleibt die Verantwortung für die Schnittstellenabsprachen weiterhin bei den Entwicklungsteams.

Strategie: Die Plattform als Produkt

Zusätzlich zur technischen Umsetzung der Plattformverbesserungen ist es wichtig, die Vorteile der Plattform klar zu kommunizieren. Eine reine Ankündigung reicht hier nicht aus. Hohe Migrationsaufwände können zudem die Akzeptanz der neuen Plattformverbesserungen erschweren, da die Teams oft bereits etablierte und funktionierende Prozesse haben. Ein vielversprechender Ansatz ist es, die interne Plattform als Produkt zu betrachten, bei dem die Entwicklungsteams die primären Anwenderinnen und Anwender darstellen. In den frühen Phasen der Einführung kann die Nutzung der Plattform für die Entwicklungsteams auf freiwilliger Basis erfolgen. Langfristig könnte sie sich jedoch zum Standardverfahren für den Betrieb entwickeln.

Das Platform Engineering kann eine dedizierte Person für das Produktmanagement einsetzen und die Anforderungen der Entwicklungsteams evaluieren, um Features zu identifizieren, die sie optimal unterstützen könnten. Es ist wichtig, dass diese Features zuvor als Hypothesen betrachtet und priorisiert werden.

Ziel ist es nicht, eine möglichst vollständige Plattform am Beispiel von Heroku zu schaffen, sondern gezielt und bedarfsgerecht die Funktionen zu priorisieren, die den Entwicklungsteams den größten Nutzen bringen. Konkret bedeutet dies, dass die Entwicklung mit Kernfunktionen beginnt, die akute Probleme lösen – wie die selbstständige Konfiguration von Firewall-Regeln. Diese Funktionalität kann durch Mechanismen wie Pull-Requests und anschließende Code-Reviews durch das Platform Engineering implementiert werden oder durch anwendungsfreundliche Schnittstellen wie grafische Bedienoberflächen, die im Hintergrund automatisierte Validierungen auf Basis globaler Policies ermöglichen. Sogenannte Pioneer- oder Pilot-Teams, die freiwillig die Plattform nutzen und ihre Erfahrungen teilen, können ebenfalls dazu beitragen, die Glaubwürdigkeit und Transparenz der Plattform zu stärken. Diese Pilot-Teams sind Entwicklungsteams, die ihre Anwendungen vor der generellen Verfügbarkeit der neuen Betriebsplattform migrieren werden. Es hat sich als gute Strategie erwiesen, eine Selfservice-Plattform mit einem oder wenigen Pilot-Teams zu starten, um eine benutzungszentrierte Entwicklung zu verfolgen. Es gelten also auch hier ähnliche Prinzipien wie für die übliche Produktentwicklung.

Die Zusammenarbeit zwischen dem Pilot-Team und dem Platform Engineering ist auf eine enge Kooperation ausgerichtet. Im Vordergrund steht eine Produktentwicklung, die sich durch einen direkten und kontinuierlichen Austausch mit den Anwenderinnen und Anwendern, also dem Pilot-Team, auszeichnet. Dies führt zu praxisnahem Feedback und sichert die Ausrichtung der Plattformentwicklung an realen Anforderungen.

Die enge Kooperation zwischen dem Pilot-Team und dem Platform Engineering ist ein bewusst gewählter, aber nur kurzfristiger Arbeitsmodus. In dieser frühen Phase der Plattformentwicklung ermöglicht die intensive Zusammenarbeit eine praxisnahe und bedarfsorientierte Gestaltung der Plattform. Team Topologies bezeichnet diesen Modus der „Kooperation“ jedoch ausdrücklich als temporäre Maßnahme, da eine zu lange andauernde enge Kopplung die Autonomie und Effizienz der Teams beeinträchtigen kann. Sobald die Plattform einen ausreichenden Reifegrad erreicht hat, sollte wieder eine losere Kopplung zwischen den Teams angestrebt werden.

Bei der Auswahl eines geeigneten Pilot-Teams für die Einführung einer neuen Plattform sind verschiedene Kriterien zu berücksichtigen. Die Priorisierung dieser Kriterien hängt stark von den individuellen Unternehmenszielen ab. Zu den wichtigsten Auswahlkriterien zählen:

Compliance-Anforderungen: Teams, die entweder besonders geringe oder besonders komplexe Compliance-Vorgaben erfüllen müssen, eignen sich oft als Pilot-Teams. Bei geringen Anforderungen kann die Einführung der Plattform schneller erfolgen, während bei komplexen Vorgaben wertvolle Erfahrungen gesammelt werden können.
Betriebsanforderungen: Sowohl Teams mit besonders geringen als auch mit hohen Betriebsanforderungen können als Pilot-Teams infrage kommen. Geringe Anforderungen ermöglichen eine unkomplizierte Einführung, während hohe Anforderungen dazu beitragen, die Plattform unter realen Bedingungen zu testen.
Delivery-Performance: Teams, die von einer verbesserten Delivery-Performance besonders profitieren würden, sind ebenfalls gute Kandidaten. Dies trifft vor allem auf Bereiche zu, die als wesentliches Differenzierungsmerkmal (Business Differentiator) dienen und daher eine stark wettbewerbsorientierte Marktpositionierung aufweisen. Ein früher Zugang zu einer Selfservice-Plattform kann diesen Teams helfen, ihre Entwicklungszyklen zu beschleunigen und damit schneller auf Marktanforderungen zu reagieren.
Neu gegründete Teams: Diese Teams haben den Vorteil, dass sie sich leichter auf neue Prozesse und Umstände einlassen können als bestehende Teams. Sie können sich von Anfang an auf die neue Plattform ausrichten und diese ohne Altlasten nutzen. Allerdings können neue Teams nicht dazu beitragen, einen geeigneten Migrationspfad für Bestandsanwendungen zu entwickeln.
High-Performance-Teams: Teams, die entweder eine geringe Arbeitsbelastung haben oder über umfassende cross-funktionale Expertise verfügen, sind ebenfalls gut geeignet. Sie haben die Kapazitäten oder das Know-how, um die Einführung der Plattform voranzutreiben und wertvolles Feedback zu liefern. Ein zentraler Aspekt der Plattformentwicklung mit einem Pilot-Team liegt in der gezielten Unterstützung während des Migrationsprozesses. Hierbei steht die Förderung der Selbstständigkeit im Umgang mit der neuen Plattform im Vordergrund – eine entscheidende Voraussetzung für die spätere effektive Eigenverantwortung der Teams.

Ein wichtiges Ergebnis dieser Zusammenarbeit sollte eine konzentrierte und leicht zugängliche Produktdokumentation sein. Sie ermöglicht ein eigenständiges Onboarding durch das Pilot-Team und dient als Grundlage für nachfolgende Entwicklungsteams. Der Fokus liegt dabei auf einer anwendungsorientierten Dokumentation, die praxisnahe Anleitungen und konkrete Beispiele bietet. Detaillierte Beschreibungen der Plattformarchitektur sollten hingegen nicht Teil dieser Produktdokumentation sein. Diese gehören nur in die Architekturdokumentation der Plattform. Pilot-Teams erfüllen auch eine entscheidende Rolle im Prozess der Etablierung neuer Plattformen, denn sie können zu mehr Glaubwürdigkeit, Transparenz und Vertrauensbildung beitragen. Ihre Erfahrungen und Meinungen haben besonderes Gewicht bei anderen Entwicklungsteams innerhalb der Organisation. Durch das Teilen ihrer Erfahrungen mit der Plattform, beispielsweise bei internen Konferenzen, werden sie indirekt zu Botschaftern für die Plattformnutzung, indem sie sowohl von deren Vorteilen als auch ihren Herausforderungen berichten. Aus diesem Grund könnte auch die Vernetzung und Reputation des Teams im Unternehmen bei der Auswahl von Pilot-Teams eine Rolle spielen.

Support und Coaching

In der Praxis von Outfitprint treten weiterhin Probleme auf, insbesondere nach der Implementierung der Plattformverbesserungen. Es wird deutlich, dass das Platform Engineering klare Grenzen setzen muss, welche Lösungen es aktiv unterstützen kann und welche nicht. Gelegentlich entwickeln Entwicklungsteams eigene Lösungen, die vom Platform Engineering aufgrund ihrer Überlastung nicht unterstützt werden können. Manchmal stellt auch die Migration in die Cloud selbst die größte Herausforderung dar. Obwohl die Teams den Wunsch haben, zu migrieren, fehlt ihnen häufig die Zeit, sich intensiv damit auseinanderzusetzen. Der hohe Druck, neue Features zu entwickeln, lässt kaum Raum für die Beschäftigung mit der Migration. Es wäre ideal, wenn das Platform Engineering eine umfassende Rundumbetreuung bieten könnte, aber leider fehlen dafür die Ressourcen. Die Arbeitsrealität der Teams ist für das Platform Engineering oft nicht gut sichtbar, wodurch viele potenzielle Quick Wins ungenutzt bleiben. Die Entwicklungsteams haben oftmals bessere Lösungen und es stellt sich die Frage, wie es gelingen kann, die guten Ideen und Alternativen der Entwicklungsteams schneller zu erkennen und in das Plattform-Produkt einzubringen. Die Erfahrung zeigt, dass beim Übergang zu einer neuen Plattform zunächst der Bedarf an Support für Entwicklungsteams ansteigt, bevor die erhoffte Selbstständigkeit der Nutzenden und damit einhergehende Reduktion des Support-Aufwands eintritt. Um das Risiko einer Überlastung des Platform Engineerings zu reduzieren, sollten klar abgegrenzte Support-Strukturen definiert werden. Nach dem Ansatz Team Topologies ist hierfür die Bildung sogenannter Enabling Teams (siehe Kasten 3) bzw. Traveling Experts geeignet [Ske20].

Kasten 3: Enabling Teams

Enabling Teams bieten Support und Coaching für abgegrenzte Leistungsbereiche an, wie zum Beispiel:

Cloud-native Architektur
Datenbank- und Ressourcenkonfiguration
Test- und Delivery-Pipeline
Threat Modeling und Ableitung von Policies
Unterstützung bei Incidents

Diese unterstützende Teamstruktur bietet spezialisiertes Wissen und Fähigkeiten, um die Entwicklungsteams in bestimmten Bereichen zu befähigen und zu unterstützen. Sie fungieren als Brücke zwischen den Entwicklungsteams und dem Platform Engineering, indem sie einen effizienten Wissenstransfer fördern. Enabling Teams arbeiten eng mit den Entwicklungsteams zusammen und unterstützen sie bei konkreten Herausforderungen. Sie können Schulungen und Beratungen übernehmen und tragen dazu bei, dass gute Ideen und Anforderungen an das Platform Engineering weitergeleitet werden.

Ein Fokus auf eine organisatorische und kulturelle Transformation beim Platform Engineering bildet eine solide Grundlage für die Cloud-native Transformation. Wie die Cloud Native Maturity Matrix verdeutlicht, ist der Weg in die Cloud ein mehrdimensionaler Prozess, der potenzielle kulturelle und technische Engpässe ebenso berücksichtigt wie unpassende Prozesse. Die Evolution einer Selfservice-Plattform ist nicht immer ein geradliniger Weg, sondern oft ein iterativer Prozess des Lernens und Anpassens.

Fazit: Eine ganzheitliche Betrachtung

Basierend auf der Reise, die am Beispiel von Outfitprint beschrieben wurde, konnten sich folgende Empfehlungen für eine pragmatische Evolution von Plattform-Services in der Cloud ableiten lassen:

Eine Bestandsaufnahme durchführen, um die drängendsten Herausforderungen zu identifizieren. Dazu gehören Umfragen der Entwicklungsteams sowie Wertstromanalyse zur Identifizierung von Flaschenhälsen im Entwicklungsprozess.
Notwendigkeit einer Selfservice-Plattform evaluieren und diese gegebenenfalls als internes Produkt aufbauen, bei dem die Entwicklungsteams die primären Anwenderinnen und Anwender darstellen.
Zusammenarbeit mit Pilot-Teams, um frühzeitig wertvolles Feedback aus der Praxis zu erhalten und die Plattform bedarfsorientiert weiterzuentwickeln.
Enabling Teams als Brücke zwischen Platform Engineering und Entwicklungsteams etablieren, um einen effizienten Wissenstransfer und Support zu gewährleisten.
Kontinuierliche Verbesserung der Plattform durch permanente Feedback-Schleifen sicherstellen.

Ich danke meinen Kollegen, die mir inhaltliches Feedback zu einer früheren Version dieses Artikels gegeben haben: Sven Johann, Felix Thiele, Markus Harrer, Theo Pack.