Team Topologies: Platform-as-a-Product (Teil 1)

Team Topologies schlägt vor, Infrastruktur-Teams zu Plattform-Teams zu wandeln. Daraus ergibt sich ein Wandel hin zu Platform-as-a-Product.

Dabei sind sich Matthew Skelton und Manuel Pais darüber im Klaren, dass dies mit Herausforderungen verbunden ist. Grund genug, dass wir uns ein wenig genauer damit beschäftigen!

Warum & Vorteile des Ansatzes

Werft doch einmal einen Blick auf die aktuelle Version der Cloud Native Landscape: Habt ihr einen Hauch von Überforderung gespürt?

Für jeden dieser Bereiche Optionen bewerten, ein Angebot auswählen, jenes erlernen, integrieren und betreiben; neben der Feature-Entwicklung als auch Produktbetreuung führt zu Überforderung und Verzögerungen.

Genau hier greift der Ansatz eines Platform-as-a-Product. Denn das Plattform-Team ist genau dafür da, diese Aufgaben und Herausforderungen für die anderen Teams zu bewältigen. Das Plattform-Team schafft die Basis der Wertschöpfung für alle anderen Teams. Das führt zu folgenden Vorteilen:   

• Es verringert die Durchlaufzeit und beschleunigt damit die Anwendungsentwicklung, was wiederum die Markteinführungszeit reduziert. 
• Die „cognitive load“ (mentale Last) wird reduziert. (Dieser Punkt wird im Team Topologies Kontext sehr stark hervorgehoben. Denn es ist eine Barriere, um Ownership aufzubauen. Es gibt auch ein Cognitive Load Assessment.)   
• Es ermöglicht autonome Teams, welche sich auf das wirklich Wichtige konzentrieren können – nämlich Probleme des Kunden lösen/Geschäftswert (stream-aligned Teams) generieren.
• Die Komplexität der Systemlandschaft kann damit reduziert werden.

Herausforderungen auf allen Ebenen (Watch outs)

Die meisten Unternehmen haben eine „Build for Re-Use“-Einstellung, die von Zentralisierung, von Fähigkeiten und durch eine Kombination aus Risikovermeidung und Kostensenkung angetrieben wird (Effizienz-Mindset).

Dies geht mit Top-Down-Governance (vielleicht sogar mit Elfenbeinturm-Architekten?), Großprojekten und zentralisierter Kontrolle einher. Dem gegenüber steht der Platform-as-a-Product-Ansatz, der kontinuierliche Verbesserung, Wahlfreiheit und Attraktivität anstrebt (Effektivitäts-Mindset).

Dies ist also mit Umdenken auf mehreren Ebenen verbunden. Hierfür möchte ich auf das BAPO-Modell verweisen. 

• B wie Business:  Ein Platform-as-a-Product-Ansatz hat einen Impact und/oder Auslöser in strategischen Unternehmenszielen, wie bspw. schnelles onboarden von Devs, schnellere Time-to-Market, Attraktivität für Entwickler oder schnelles skalieren.
• A wie Architecture: Ein Platform-as-a-Product-Ansatz hat (offensichtlich) einen großen Einfluss auf die Software-Architektur. Ein Platform-as-a-Product ist keine Sammlung von zufälligen oder gar verwaisten Tools und Services.
• P wie Process: Es ändert die Zusammenarbeit und was Teams von der Organisation erwarten können. Dabei ist die Plattform ein Angebot, das angenommen werden kann, aber kein „Muss“ ist. Die Autonomie der Teams bleibt erhalten, inkl. der damit verbundenen erweiterten Verantwortung und Kosten. Das schürt jedoch gleichzeitig den Anspruch an Attraktivität und Einfachheit der Nutzung der Plattform. 
• O wie Organisation: Ein Platform-as-a-Product-Ansatz ist jedoch auch mit einer organisatorischen Umgestaltung verbunden. Mehrschichtige Plattform-Teams, die bestehende Technologiesilos beibehalten, oder ticketgesteuerte Plattformbetriebsmodelle sind kein Platform-as-a-Product-Ansatzes. Der Platform-as-a-Product-Ansatz erfordert ein echtes (langlebiges und stabiles) Produkt-Team, welches sich auf interne Kunden konzentriert, dass sowohl mit dem Aufbau als auch mit dem Betrieb beauftragt sein sollte. Dies erfordert auch eine Überwindung der Produkt-vs-Projekt-Ansicht.

Platform-as-a-product – Was ist das? Ein Definitionsversuch. 

Platform-as-a-Product ist Wertschöpfungsgrundlage und Wertschöpfungsermöglicher. Gemäß Evan Bottcher ist eine Plattform in diesem Kontext: 

A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.

Martin Fowler, What I Talk About When I Talk About Platforms

Thoughtworks hat ein Modell mit fünf Hauptpfeilern der Plattform-Fähigkeit entwickelt. Zu diesen Fähigkeiten gehören die Bereitstellungsinfrastruktur, APIs und architektonische Korrekturen/Anpassungen, Self-Service-Daten, experimentelle Infrastruktur und Technologien für Kundenkontaktpunkte. Diese sollten also in den Überlegungen rund um Platform-as-a-Product berücksichtigt werden.

Annähernd an die Definition von Evan Bottcher und den fünf Hauptpfeilern lässt sich schlussfolgern^*, dass Plattformen Self-Service sind, Ökosysteme ermöglichen und tailormade sind.

Das möchte ich kurz ausführen.

Self-Service, Ökosysteme, Tailormade

Ziel bei einem Self-Service ist es, eine echte Selbstbedienung mit hohem Nutzwert anzubieten. Die Plattform bietet Werkzeuge und Dienste an, welche die Anwendungsteams nutzen können, um damit auch die Verantwortung für das, was sie end-to-end entwickeln, zu übernehmen. Team Topologies bietet dafür Interaktionsmuster (Facilitating, X-as-a-service, Collaboration) an, die sich über Zeit entwickeln können.

Ökosysteme ermöglichen bedeutet, dass die Plattform kompatibel und erweiterbar bleibt und „abstrahierte Optionen“ (APIs, Fassaden, etc.) zur Verfügung stellt. Das ermöglicht Schnelligkeit, Flexibilität, den Abbau von Barrieren, Experimentieren und Innovationen. Das ermöglicht
wiederum neue Business-Capabilities. Denn Innovationen können von drei Seiten kommen: vom Produktmanagement/Business, vom Kunden, aber auch von der Technologie-Seite.

Tailormade bedeutet, dass keine off-the-shelf-Lösung einfach so besorgt werden kann. Es bedeutet, dass die Tiefe und Breite der Plattform hoch-individuell ist. Natürlich werden wir dabei auch ein paar PaaS/SaaS-Modelle off-the-shelf nutzen, aber der Make-vs-Buy-Anteil als auch die gesamte Kombination, das Zusammenspiel und die Konfiguration von möglichen off-the-shelf-Lösungen und Eigenentwicklung ist dabei die Eigenleistung. Das kann einem niemand abnehmen.

Die vier Elemente des Platform-as-a-Product-Ansatzes

Bei einem Platform-as-a-Product-Ansatz sollten vier Elemente berücksichtigt werden: Plattform Value (Strategie), Plattform Customers, Plattform/Developer Experience und der Adoption Cycle. Man kann Produktmanagement auf diese „technische Sphäre“ anwenden; doch dazu mehr in meinem nächsten Blogartikel.

Ein Beispiel für ein Platform-as-a-Product habe ich auch dabei: NAIS.

Dabei handelt es sich um eine Open-Source-Anwendungsplattform (basierend auf Kubernetes), die darauf ausgerichtet ist, die Entwicklungsgeschwindigkeit zu erhöhen, indem sie die bestmöglichen Werkzeuge für die Entwicklung und Ausführung zur Verfügung stellt.

^* Alternative/ergänzende Schlussfolgerungen gerne im Kommentar hinterlassen. Ich freue mich auf augenöffnende Diskussionen!

Team Topologies