Alexander Kaserbacher
13.11.2023
Der Begriff Plattform ist überladen. Ich habe mir lange Zeit schwer getan, eine gute Einordnung zu finden. Umso riskanter ist es, wenn Menschen innerhalb eines Unternehmens ein unterschiedliches Verständnis eines Begriffes haben, der zentrale Architekturideen prägen soll. Immerhin hat er durch moderne Ideen wie Team Topologies (wo Plattform-Teams ein Element sind) eine zentrale Bedeutung gewonnen.
Wenn alle beteiligten Personen etwas anderes unter “Plattform” verstehen, dann rufen Architekturentscheidungen Missverständnisse hervor und Teams kommunizieren sie falsch. Dies führt nicht nur zu fehleranfälliger Implementierung, sondern auch zu Reibung und Spannungspunkten innerhalb der gesamten Organisation. Nur mit einer sauberen Begriffsdefinition von zentralen Architekturbegriffen kann eine sinnvolle Zielarchitektur entstehen!
Eine Plattform unterstützt Entwicklungsteams bei der Erstellung ihrer Software. Plattformen können im Grunde alles sein: Cloud-Plattformen, Betriebssysteme, Datenplattformen, App Stores, Kommunikationsplattformen, …
Plattform-Engineering ist die Disziplin des Entwerfens und Bauens einer “Internal Developer Platform” (oder kurz: IDP). Das ist ein spezifischerer Begriff als “Plattform”, weil er interne Entwickler:innen als Zielgruppe definiert. Er entspricht dem, was ich in dieser Blogreihe diskutiere. Ich verwende in diesem Kontext beide Begriffe synonym.
Für die weitere Diskussion ist es zudem wichtig, den Begriff “Produkt” zu klären. Ein Produkt liefert einen Mehrwert für Endanwender:innen und wird von diesen direkt benutzt. Produkte laufen entweder als Ganzes oder im Zusammenspiel aus mehreren Teilprodukten. Im Folgenden schreibe ich “(Teil-)Produkt”, um beide Begriffe zu vereinen.
Es gibt viele Ausprägungen von Plattformen. Nicht alle der folgenden drei Szenarien stellen eine Plattform bzw. IDP dar. Mehr dazu am Ende des Artikels.
Szenario 1
Manche Plattformen sind als Laufzeitumgebungen implementiert. Meistens koordinieren sie jegliche Kommunikation zwischen (Teil-)Produkten auf der Plattform und stellen Dienste zur Verfügung, die Produkte zwingend benötigen. Diese sind somit ohne die Plattform nicht ausführbar. Abbildung 1 zeigt dieses Modell.
Dies ist vor allem dann nützlich, wenn die (Teil-)Produkte mit der Plattform ein Ökosystem bilden sollen. Insbesondere ist die Plattform so in der Lage, strikte Regeln an die (Teil-)Produkte vorzugeben. Ein Beispiel dafür ist iOS, das als Laufzeitumgebung für Apps fungiert und einen Rahmen vorgibt. So ist der Zugriff auf die Kamera oder andere Hardware-Funktionalität über iOS als Plattform reglementiert. Dies ist vor allem dann nützlich, wenn die (Teil-)Produkte mit der Plattform ein Ökosystem bilden sollen. Insbesondere ist die Plattform so in der Lage, strikte Regeln an die (Teil-)Produkte vorzugeben. Ein Beispiel dafür ist iOS, das als Laufzeitumgebung für Apps fungiert und einen Rahmen vorgibt. So ist der Zugriff auf die Kamera oder andere Hardware-Funktionalität über iOS als Plattform reglementiert.
Solche Plattformen müssen nicht notwendigerweise Betriebssysteme sein, sondern können auch Cloud-Plattformen als Laufzeit-Umgebung umfassen, bspw. AWS-Services oder Kubernetes.
Abbildung 1: (Teil-)Produkte sind auf Plattform installiert und kommunizieren darüber
Szenario 2
(Teil-)Produkte sind in diesem Szenario selbstständig lauffähig. Plattformen fungieren hier eher als Zulieferer für Produkt-Teams. Sie liefern Vorlagen und sinnvolle Konfiguration für die Infrastruktur der (Teil-)Produkte, z.B. für einen Microservice in einem Kubernetes-Cluster mit Datenhaltung. Abbildung 2 illustriert diese Idee.
Abbildung 2: Produkte sind unabhängig ausführbar
Dieses Modell erlaubt es, dass Teams autonom arbeiten. Da die Laufzeit-Infrastruktur innerhalb des (Teil-)Produktes (und nicht der Plattform) ist, können Teams im Gegensatz zu Szenario 1 auch eigenständig und unabhängig Änderungen daran vornehmen.
Szenario 3
Die Plattform stellt zentrale Infrastrukturkomponenten zur Verfügung, z.B. einen Message Bus. Im Vergleich zu Szenario 1 ist dies aber nur Infrastruktur für zentrale Kommunikation zwischen (Teil-)Produkten, nicht aber Laufzeit-Infrastruktur für einzelne (Teil-)Produkte. Abbildung 3 zeigt diesen Fall.
Abbildung 3: Ein zentraler Event-Bus
Jedes der oben genannten Szenarien stellt eine mögliche Ausprägung des Plattformbegriffs dar und hat unterschiedliche Implikationen auf (Teil-)Produkte, deren Architektur und die einbettende Organisation.
Um die Szenarien zu bewerten, diskutieren wir erstmal wichtige Ziele, die wir mit einer guten Plattform erreichen wollen:
Produkt-Teams werden befähigt, ihr (Teil-)Produkt zu liefern, ohne jede zugrunde liegende Technologie bis ins Detail kennen zu müssen
Eine Plattform ist immer eine Abstraktion für Produkt-Teams. Je höher der Abstraktionsgrad von Technologien, desto einfacher ist der Umgang mit Implementierungsdetails. Beispielsweise ist die Installation von Anwendungen auf Serverless-Umgebungen (wie AWS Fargate) oder OpenShift-Clustern einfacher als die Konfiguration von Kubernetes-Ressourcen.
Produkt-Teams sind in der Lage, ganzheitliche Verantwortung über ihr (Teil-)Produkt (von Anforderungen und User Interface bis zur Laufzeit-Infrastruktur) zu übernehmen
Wenn Produkt-Teams abhängig von Plattformen sind, entsteht oft eine Situation gegenseitiger Schuldzuweisungen (“Das Plattform-Team hat nicht geliefert”). Daher ist es wichtig, dass Produkt-Teams die Verantwortung und die Kontrolle über ihr (Teil-)Produkt haben. Dafür brauchen sie Zugriff auf den Technologie-Stack und Betriebsaspekte.
Eine Plattform darf also keine Aspekte vor Produkt-Teams verstecken. Die Laufzeit-Infrastruktur muss transparent und zugänglich sein - sowohl für Produkt- als auch für Plattform-Teams.
Anforderungen werden von Produkt-Teams selbstständig umgesetzt; sie sind nicht abhängig von Plattform-Teams
Produkt-Teams sind nicht auf die Umsetzung von Funktionen in der Plattform angewiesen, um ihre eigenen Features implementieren zu können. Eine Plattform soll eine Vereinfachung für die Arbeit von Produkt-Teams darstellen, darf aber keine Voraussetzung dafür sein.
Plattformen etablieren eine zentrale Stelle, wo Teams Erfahrungen sammeln und anderen Teams zur Verfügung stellen
Vorlagen (wie weiter oben erwähnt) spielen auch hier eine zentrale Rolle. Wissen und Erfahrungen aus Produkt-Teams können nicht nur in Dokumentation gegossen werden, sondern auch in Vorlagen, die dann per Knopfdruck von Produkt-Teams provisioniert werden.
Aus den Zielen können wir wichtige Charakteristika ableiten, die eine gute Plattform erfüllt:
Abbildung 4: Eine Plattform auf Basis dieser Charakteristika
Abbildung 4 illustriert eine Plattform nach der Idee der fünf Charakteristika. Einerseits verantwortet die Plattform geteilte Infrastruktur, andererseits liefert sie Vorlagen für Infrastruktur der (Teil-)Produkte. Diese Infrastruktur kontrollieren Produkt-Teams selbst. Sie können aber auf das Wissen der Plattform anhand der Vorlagen zurückgreifen.
Darüber hinaus stellt die Plattform Werkzeuge zur Verfügung, die Teams zur Verwaltung ihrer Infrastruktur benutzen können. Dies sind beispielsweise Hilfestellungen zum Management von Containern oder zur Automatisierung von manuellen Deployment-Schritten.
Szenario 2 und 3 entsprechen recht offensichtlich den Charakteristika und sind direkt in Abbildung 5 auffindbar.
Eine Antwort bin ich Euch noch schuldig: Ist Szenario 1 eine Plattform anhand der oben definierten Charakteristika? Zumindest das Charakteristikum “Produktansatz” ist teilweise verletzt. Die Plattform ist verpflichtend für (Teil-)Produkte, die ohne die Plattform nicht ausführbar sind. Dadurch entstehen sehr schnell Abhängigkeiten von Produkt-Teams gegenüber der Plattform. Diese können unter Umständen erst dann liefern, wenn die Plattform zugrunde liegende Funktionalität bereitstellt.
Aus diesen Gründen lasse ich bei solchen Szenarien meist Vorsicht walten. Ich empfehle, eine solche Plattform nur dann umzusetzen, wenn Sie keine andere Wahl haben und eine sehr hohe Kontrolle über ihre (Teil-)Produkte ausüben müssen (wie es beispielsweise bei Apples iOS und ihrem App Store der Fall ist).
Die fünf Charakteristika bilden eine Basis für weitere Artikel dieser Blogreihe. Über die nächsten Wochen werde ich immer wieder Beiträge rund um das Thema “Plattform-Engineering” veröffentlichen. Eine Übersicht findet ihr hier.
Ihr habt Fragen oder Herausforderungen im Bereich “Plattform-Engineering”? Hier findet ihr meine Kontaktdaten - ich freu mich von euch zu hören.
Mehr zu diesem Thema, insbesondere organisatorische Auswirkungen auf Plattform-Teams im Cloud-Native-Kontext, findet ihr auf unserer Session beim Architektur-Punsch. Einfach anmelden!