Plattformen, Teams und APIs: Wie passt das zusammen?

Erik Wilde

This article is also available in English

Dieser Artikel ist Teil einer Reihe.

• Teil 1: Gängige Methoden im Umfeld soziotechnischer Architekturen
• Teil 2: Plattformen, Teams und APIs: Wie passt das zusammen? (dieser Artikel)
• Teil 3: Soziotechnische Architektur als Wettbewerbsvorteil

Von Seiten zu Diensten

Anfang der 2000er-Jahre war der Erfolg des Webs eine epochale Wende. Tim O’Reilly, Verleger und Gründer des bekannten Medienhauses, war einer der ersten, der das Web nicht nur als menschenorientiertes System (mit dem Webseiten an Browser verteilt werden), sondern auch als globale Diensteplattform für die Kommunikation zwischen Programmen betrachtete.

Diese Perspektive vertrat er Anfang 2000 in Gesprächen mit Jeff Bezos, dem damaligen CEO von Amazon. Zu dieser Zeit war Amazon ein schnell wachsender Online-Marktplatz. Bezos ließ sich von der Argumentation inspirieren, dass die Zukunft darin liegt, Unternehmen schneller und flexibler zu machen, und dass Dienste dafür die richtigen Bausteine sind.

Er reagierte schnell und entschlossen: Im Jahr 2002 verfasste Bezos das bekannte „Bezos Mandat“.

Jeff Bezos forderte in prägnanter Weise, dass künftig alle Teams bei Amazon ihre Dienste über programmierbare Schnittstellen (APIs) anbieten müssen. Diese Schnittstellen sollten so gestaltet sein, dass sie auch von externen Konsument:innen genutzt werden können. Ziel war es, die vorher oftmals enge Kopplung zwischen Komponenten zu verringern und alle Dienste leicht auffindbar sowie wiederverwendbar zu machen.

Dabei ließ das Mandat offen, welche Technologie für die Schnittstellen genutzt wird, solange diese netzwerkbasiert sind.

Die Motivation war klar: Als schnell wachsender und sich dynamisch verändernder Marktplatz benötigte Amazon eine IT-Kultur und -Struktur, die Geschwindigkeit und Flexibilität priorisiert. Klassische Probleme der Softwareentwicklung wie lange Entwicklungszyklen und hoher Koordinationsbedarf zwischen Teams sollten reduziert werden.

Das „Bezos Mandat“ war so einfach wie radikal und krempelte die Software-Architektur des Unternehmens um, mit dem Ziel, schneller neue Wertschöpfung zu ermöglichen.

Als Resultat dieses Mandats wurden 2004 die ersten E-Commerce-APIs geschaffen, die das Wachstum des Amazon-Marktplatzes vorantrieben. Weitaus einflussreicher war jedoch die Öffnung der Amazon Web Services (AWS) APIs ab 2006, die komplett neue Geschäftsfelder eröffneten.

Doch wie sah dieses Mandat aus, das einen so tiefgreifenden Einfluss auf den Erfolg von Amazon hatte?

Jedes Team hat ein API

Um es Amazon-Teams zu ermöglichen, so schnell wie möglich zu entwickeln, sollte die Abhängigkeit von anderen Teams minimiert werden. Dies wurde erreicht, indem jedes Team ein API (im Mandat wurde noch der Begriff „Service“ verwendet) zur Verfügung stellen musste. Das Mandat war kurz und bestand aus den folgenden Punkten:

1. Alle Teams müssen künftig ihre Daten und Funktionen über Service-Schnittstellen offenlegen.
2. Teams müssen über diese Schnittstellen miteinander kommunizieren.
3. Keine andere Form der Kommunikation ist erlaubt: keine direkte Verknüpfung, kein direktes Lesen des Datenspeichers eines anderen Teams, kein Shared-Memory-Modell, keine Hintertüren. Die einzige erlaubte Kommunikation erfolgt über Aufrufe von Service-Schnittstellen über das Netz.
4. Es spielt keine Rolle, welche Technologie verwendet wird: HTTP, Corba, PubSub, benutzerdefinierte Protokolle – alles ist erlaubt.
5. Alle Service-Schnittstellen müssen ausnahmslos von Grund auf so konzipiert sein, dass sie externalisiert werden können. Teams müssen planen und entwerfen, um Schnittstellen für externe Entwickler zugänglich zu machen. Keine Ausnahmen.

Zur Zeit des Mandats war dies ein radikaler Ansatz, der dafür sorgte, dass Team-Interaktionen deutlich besser skalierten als die damals üblichen, engeren Integrationen. Betrachtet man das Bezos-Mandat aus dieser Perspektive, wird klar, dass es primär dazu gedacht war, Abhängigkeiten zwischen Teams zu minimieren („loose coupling“) und die Interaktionen zwischen Teams auf einen klar definierten Kanal zu beschränken.

Interessant ist zudem, welche Folgen dieses Mandat hatte. Steve Yegge hat diese in seinem populären „Google Platforms Rant“ von 2011[1] beschrieben, in dem er über seine Erfahrungen bei Amazon spricht. Dabei wird deutlich, dass die Umsetzung des Bezos-Mandats komplex war und Jahre in Anspruch nahm. In einem API-basierten Unternehmen ändern sich grundlegende Dinge, wie etwa das Auffinden von Fehlern oder das Lokalisieren von Diensten.

Hier soll es jedoch weniger um die technische Komplexität dezentraler Software-Architekturen gehen, sondern vielmehr darum, wie Team- und Technik-Strukturen miteinander verbunden sind.

Wie Teams interagieren

Das Bezos-Mandat hat radikal verändert, wie Teams interagieren, indem die lose Kopplung als Default (oder streng genommen als einzig erlaubte Variante) etabliert wurde. Das bedeutet jedoch nicht automatisch, dass die Zusammenarbeit zwischen verschiedenen Teams einfacher oder weniger komplex wird.

Der Ansatz der Team Topologies, der seit der Veröffentlichung des gleichnamigen Buchs 2019[2] an Bedeutung gewonnen hat, setzt hier neue Schwerpunkte. Einer der beschriebenen Ansätze ist das Konzept eines „Team-APIs“. Dieses umfasst nicht nur das technische API eines Teams (wie im Bezos-Mandat gefordert), sondern auch weitere Aspekte wie Praktiken und die beteiligten Personen eines Teams. Die Idee dahinter ist, dass die lose Kopplung durch zusätzliche Informationen ergänzt wird, die für die Interaktion mit einem Team relevant sind.

Dies führt zu einer weiteren Stärkung der Autonomie von Teams, die nach außen als Dienstanbieter agieren. Gleichzeitig steigt jedoch auch die Menge der Aufgaben, die Teams bewältigen müssen, da sie den gesamten Entwicklungsprozess eigenständig verantworten.

Um diesen natürlichen, aber unerwünschten Nebeneffekt der größeren Autonomie zu managen, wurde das Modell einer Plattform eingeführt – nicht nur in der klassischen Variante der „Infrastrukturplattform“, sondern auch in der moderneren Ergänzung durch eine „Internal Developer Platform (IDP)“.

Team-Effizienz und Plattformen

Der fundamentale Unterschied zwischen einer Infrastruktur Plattform und einer IDP besteht darin, dass erstere aus marktüblichen Bausteinen besteht (z. B. Laufzeitumgebung und Programmiersprachen), während letztere spezifisch auf die Bedürfnisse und Praktiken einer Organisation zugeschnitten ist.

Aus diesem Grund gibt es in den oben erwähnten Team Topologies das Konzept von Plattform GroupsTeams. Deren Aufgabe besteht darin, anderen Teams wiederkehrende und potenziell zeitraubende Aufgaben abzunehmen und diese stattdessen in der IDP umzusetzen. Die regulären Teams (in der Sprache von Team Topologies die “Stream-aligned Teams”) können dadurch effizienter arbeiten, weil sie bestimmte Aufgaben in die Plattform auslagern.

Aus der Sicht von Team Topologies werden damit zwei Ziele erreicht: Einerseits gibt es die „Logical Platform“, die als eine schlüssige Plattform wahrnehmbar und konsumierbar ist. Diese ermöglicht es Teams, auf der Plattform aufbauend einfacher zu entwickeln. Andererseits gibt es die „Platform Groups“, die in ihrer Gesamtheit, aber gegebenenfalls unabhängig voneinander, an der Bereitstellung und Weiterentwicklung der Logical Platform arbeiten.

Ein weiterer Vorteil des Plattformkonzepts ist, dass es die Standardisierung von Komponenten erleichtert und fördert. Haben Teams zuvor beispielsweise verschiedene Komponenten für das Monitoring verwendet, so kann in einer Plattform das Monitoring als Dienst angeboten werden, der auf einer standardisierten Lösung basiert.

Platform Engineering unterstützt Teams

Der Begriff des Platform Engineering bezeichnet einen soziotechnischen Ansatz, bei dem die Teamstruktur und die Aufgaben innerhalb des Entwicklungsprozesses genutzt werden, um die mentale Last der Teams zu reduzieren und die Effizienz des Entwicklungsprozesses zu verbessern.

Die heutige Popularität von Platform Engineering und Plattform-Teams ist vor allem auf zwei Aspekte zurückzuführen. Zum einen ist dies die rasante Zunahme der digitalen Produkte, die zur Folge hat, dass Effizienzgewinne bei deren Entwicklung immer größere Auswirkungen haben. Zum anderen sind es die steigenden Anforderungen daran, wie schnell digitale Produkte und Lösungen entwickelt werden können.

Wird dies einfacher und schneller (und damit auch kostensparender), können beispielsweise Strategien verfolgt werden, die stärker explorativ ausgerichtet sind. Und dies führt zum letzten fehlenden Teil im modernen Plattform-Puzzle…

Effizienz und Effektivität von Teams

Platform Engineering beschäftigt sich primär mit der Effizienz des Entwicklungsprozesses. Das ist für sich genommen notwendig und nützlich, bedeutet jedoch nicht automatisch, dass auch die richtigen Dinge entwickelt werden.

Hier kommt die Optionalität ins Spiel, die von Stephen Fishman und Matt McLarty in einem neuen Buch detailliert untersucht wird. Optionalität bedeutet, strategisch darauf zu achten, dass möglichst viele Optionen zur Verfügung stehen, um größere Wertschöpfung in einer Organisation zu erreichen, und dass dieser Prozess einer ständigen Optimierung unterzogen wird.[3]

Damit dies geschehen kann, so Fishman und McLarty, sollte der Default in einer Organisation darin bestehen, die Wiederverwendbarkeit von geschäftlichen Diensten zu erleichtern. Hier schließt sich der Kreis zum Bezos-Mandat, das zu Beginn dieses Beitrags vorgestellt wurde.

Während das Bezos-Mandat oft zitiert wird, wird es in seiner radikalen Variante nur selten umgesetzt. Das liegt unter anderem daran, dass es nicht immer der kostensparendste Weg für ein Geschäftsmodell zu einem bestimmten Zeitpunkt ist. Vielmehr investiert es in den Ansatz, Dienste besser zu entkoppeln und dadurch mehr Optionen für zukünftige Entwicklungen zu schaffen. Dieser Ansatz, „Unbundling“ genannt, wird von Matt McLarty wie folgt beschrieben:

Unbundling erfordert Aufwand und Ressourcen, und die Sichtweise des Unbundlings folgt einer strategischen Logik, die nicht in allen Fällen angemessen ist. Lose Kopplung ist ebenfalls nicht ohne Kosten zu haben. Doch diese Aufwände sind eine Investition in Resilienz und Flexibilität – Werte, die in einer sich immer schneller ändernden Welt zunehmend an Bedeutung gewinnen.

Das bedeutet jedoch nicht, dass sowohl Business als auch IT komplett umgestellt werden müssen. Vielmehr erfordert es einen neuen Fokus, der auf Teams, ihre Interaktionen und das Potenzial dieser Struktur abzielt. Team Topologies hat hierzu das Konzept der „Thinnest Viable Platform“ eingeführt, das keinen radikalen Neuanfang verlangt. Stattdessen zielt es darauf ab, eine minimalistische Plattform bereitzustellen, die nur die notwendigsten Funktionen bietet, um Produktteams zu unterstützen, ihre Arbeit zu erleichtern und unnötige Komplexität zu vermeiden.

Dies zeigt sich auch im Markt für API-Produkte, die das Unbundling in Organisationen unterstützen. Nach einer gewissen Stagnation ist die Dynamik in diesem Bereich stark gestiegen. Es gibt viele neue Anbieter für Portale und Marktplätze, und Organisationen investieren zunehmend strategisch in API-Strategien und -Programme. Das ist zu einem Teil sicher auch der Tatsache geschuldet, dass ohne APIs viele der attraktiven AI-Ansätze nicht funktionieren können, aber der Trend zu einem strategischeren API Management begann bereits vor dem aktuellen AI Trend.

Dieser Artikel ist Teil des INNOQ Technology Briefings – unserem Report für Technologieentscheider:innen. Jetzt herunterladen und mehr zum Thema soziotechnische Architekturen erfahren.

Quellen