The Magic of Platforms

Kernpunkte

1. Datum / Quelle. Keynote PlatformCon 2022 (Juni 2022), YouTube-Aufzeichnung The Magic of Platforms (~15 Min.), Sammelseite platformengineering.org/talks-library/the-magic-of-platforms.
2. Sprecher. Gregor Hohpe, Enterprise Strategist AWS, Autor von Software Architect Elevator + demnächst erscheinendes Buch Platform Strategy (Leanpub).
3. Zielgruppe. Plattform-Architekten, Platform-Engineering-Teams, CTO/VP Engineering. ### Kernthese > "Manche Dinge festzuschreiben — sich auf ein paar Dinge zu einigen — kann Innovation und Kreativität tatsächlich fördern. Und Plattformen stehen genau in deren Zentrum." ### Standards als Innovationstreiber (3 Beispiele) | Beispiel | Datum | Lehre | |---------|------|--------| | Brand von Baltimore | 1904 | Feuerwehrleute aus Nachbarstädten konnten ihre Schläuche nicht an die Hydranten anschließen → seither der Baltimore-Standard | | ISO-Metrischschraube | einer der ersten ISO-Standards | Jede normgerechte Schraube passt in jedes normgerechte Gewinde | | HTTP | ab 1991 | Jeder Browser kann sich mit jedem Webserver verbinden — ein massiver Innovationstreiber | | DIN-A4-Papier | (Referenz) | 297 × 210 mm = 1/16 m² — "niemandes Kreativität wird eingeschränkt", im Gegenteil, weniger Streit über Umschlag- oder Schubladengröße | ### Automobil-Analogie (Kern des Vortrags)
4. Die Automobilindustrie löst "the undifferentiated heavy lifting" (Motor, Getriebe, ABS, Abgaskontrolle, Abgasnormen) einmal.
5. Setzt darüber je nach Segment unterschiedliche "Hüte" auf.
6. Der VW-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform. (MQB wird nicht namentlich genannt, ist aber gemeint).
7. Der Kunde sieht die Farbe, das Interieur, den Klang der Türen — nicht das Differential. ### Zitat Peter / Thoughtworks (kanonisch) > "Plattformen sind im Grunde ein Mittel, um Expertise zu zentralisieren. Man muss das Rad nicht mehrfach neu erfinden. Aber man zentralisiert nicht die Innovation — die überlässt man den Teams, die dem Kunden am nächsten sind und die besten Ideen haben." ### Drei Eigenschaften einer echten Plattform 1. Geringe Reibung — "man kann niemanden zwingen, auf die eigene Plattform zu wechseln; versucht man es doch, finden sie andere Wege". 2. Transparent (keine Black Box) — Nutzer müssen diagnostizieren können: "liegt es an mir oder an der Plattform?". 3. Geteilte Verantwortung — AWS-Analogie: "baut man eine furchtbar unsichere, instabile, nicht skalierende monolithische Anwendung, kann die Plattform selbst das nicht für einen reparieren". ### Explizites Anti-Pattern: als Plattform getarntes IT Service Management
8. Identisches Bild (gemeinsame Schicht + Bausteine), aber umgekehrte Schnittstelle: hohe Reibung, Formulare, Flaschenhals, das Hinzufügen eines Kunden ist aufwendig.
9. "Lasst euch nicht vom Bild der gemeinsamen Schicht täuschen — eine gemeinsame Schicht kann vieles sein. Sie ist nicht zwangsläufig eine Plattform." ### Zwei Aufbauwege | Weg | Beschreibung | Hohpe | |------|-------------|-------| | (a) Jeden Bedarf antizipieren | "Man ist irgendwie schlauer als alle anderen, antizipiert die Bedürfnisse aller und implementiert das in seine Plattform, und alle lebten glücklich bis ans Ende ihrer Tage." | Ironischer Ton, vermutlich unrealistisch | | (b) Evolvieren | "Man beginnt mit ein paar nützlichen Bausteinen, beobachtet, was die Leute brauchen — oft lässt sich das schon an der Plattformnutzung selbst ablesen — und beginnt, die Plattform zu erweitern." | Empfohlener Weg — Hohpe: "Ich halte mich nicht für schlau genug, um die Bedürfnisse aller zu antizipieren" | ### Explizit zu treffende Architekturentscheidungen (die "Regler") Verfolgte Ziele:
10. Kognitive Last. / Lernkurve reduzieren
11. Sicherer. "geringere Wahrscheinlichkeit, Fehler zu machen" — indem "Randfälle oder Komplexität verborgen werden"
12. Schneller. Samples, Blueprints, besseres Self-Service
13. Produktivität. / Zusammenarbeit / Compliance / Fehlerminimierung Mechanismen: welche Hebel für welches Ziel eingesetzt werden. ### Formen der Lernkurve | Form | Beschreibung | |-------|-------------| | Klippe | "Selbst für ein 'Hello World' braucht es einen gewissen Aufwand" — hoher Einstiegsaufwand | | Linear (ideal) | in der Praxis selten | | Hockeyschläger | Annahmen werden fest verbaut → der Einstieg ist leicht, aber sobald die Annahmen nicht mehr zutreffen, "wird das Leben unverhältnismäßig schwerer" | | Gangwechsel | weniger schlimm als der Hockeyschläger: Wechsel zwischen Diensten innerhalb der Plattform, aber "dazwischen gibt es einen Gangwechsel, man muss Neues lernen" | ### KANONISCHES KONZEPT — Floating Platforms vs. Sinking Platforms Kontext: "in fast allen Fällen baut man eine Plattform nicht isoliert — man baut sie auf einer Basisplattform auf" (die Cloud / AWS als typisches Beispiel). Auch die Basisplattform wächst. Wichtige strategische Entscheidung: Was macht man mit der eigenen Plattform, wenn die Basis bestimmte Fähigkeiten absorbiert? | Strategie | Beschreibung | Metapher | Hohpes Urteil | |-----------|-------------|-----------|---------------| | Sinking Platform | Man behält die eigene Plattform unverändert bei, weil man in sie investiert hat. Die Basis steigt. Die eigene Plattform dupliziert nun Dinge, die die Basis nativ anbietet. "Mit steigendem Wasserspiegel" sinkt die eigene Plattform (wird zur Wartungslast, bremst Innovation). | Sinkendes U-Boot | "Mag durch die Investition gerechtfertigt sein, aber im Grunde dupliziert man Dinge, die jetzt in der Basisplattform stecken" — de facto ein Anti-Pattern. | | Floating Platform | Wenn die Basis die selbst gebauten Fähigkeiten übernimmt, sagt man: "oh perfekt, den Teil brauche ich nicht mehr — das kann die Basisplattform übernehmen, und ich innoviere weiter oben". Man verwirft, was redundant geworden ist, steigt höher und baut Neues. | Boot, das mit der Flut steigt | Empfohlener Weg — aber mit einer expliziten vertraglichen Bedingung. | Vertragliche Bedingung (zentral): > "Beides sind sinnvolle Entscheidungen, und es ist sehr wichtig, das den Stakeholdern von vornherein klarzumachen. Wer eine Floating Platform baut, muss die Beteiligten darauf vorbereiten, dass Dinge weggeworfen werden, sobald die Basisplattform dieselben Fähigkeiten besitzt." Implikationen für Design / Governance:
14. Schnittstellenabstraktion. Die Plattform muss ihre Fähigkeiten über eine stabile Schnittstelle bereitstellen — sonst bricht das "Wegwerfen von Dingen" die Konsumenten.
15. Expliziter Lebenszyklus. Komponenten von Geburt an als "deprecate, sobald die Basis dies bietet" kennzeichnen.
16. Aktive Beobachtung der Basisplattform. die Roadmap des Basis-Anbieters (AWS, GCP, Azure, Kubernetes usw.) ist die Größe, an der man sich ausrichten muss.
17. Stakeholder-Kommunikation. vor der Entfernung warnen, sonst wird es als Vertrauensbruch empfunden.
18. Innovationsmaßstab. Der Wert einer Floating Platform bemisst sich daran, was sie zusätzlich aufbaut, nicht daran, was sie behält. Risiko der Sinking Platform: Sunk-Cost-Fallacy im großen Maßstab — "wir haben schon 3 Jahre in dieses Modul investiert, das behalten wir", obwohl die Basis es inzwischen als günstigeres, besser gewartetes Managed-SaaS anbietet. Risiko der Floating Platform: Instabilität auf Konsumentenseite bei unzureichender Kommunikation. Der moralische und technische Vertrag mit den Nutzern ist der Grundpfeiler. ### KANONISCHES KONZEPT — Fruit Salad vs. Fruit Basket Kontext: die abschließende Entscheidung des Vortrags — "wie interagieren die Teile der eigenen Plattform?". | Modell | Beschreibung | Marktwert | |--------|-------------|------------------| | Fruit Basket | recht eigenständige, nebeneinandergestellte Teile. "Das ist gut, aber das ist nicht die volle Stärke der Plattform." | Preis pro Kilo Obst | | Fruit Salad | "richtiges Verhältnis von Obst in mundgerechten Stücken". "Braucht es etwas mehr Apfel als Orange, muss man nicht einen ganzen Apfel und eine ganze Orange hineinlegen". | "Der Kilopreis für Obstsalat ist höher als für einen Obstkorb" — der Wert entsteht durch das proportionierte Gefüge. | Architektonische Implikation: Die Plattform muss durch Komposition neue Anwendungsfälle ermöglichen (ein Picknick mit Obstsalat ist einfacher als das Schleppen eines Korbs). Für Platform Engineering: in bereichsübergreifenden Nutzungsflüssen denken (cross-service), nicht nur in einem Katalog unabhängiger Dienste. ### Einordnung im Tech-Watch-Dossier #### Konvergenz "Platform Engineering = Orchestrierung von Fähigkeiten, kein Katalog"
19. Hohpe. (2022-06): Fruit Salad > Fruit Basket, geringe Reibung + Transparenz + geteilte Verantwortung.
20. AI/works™ Thoughtworks. (2026-05-12): sechs Fähigkeiten, die den gesamten SDLC abdecken, Control Plane "Kostentransparenz + aktive Guardrails + durchgängige Lineage" — Hohpes Transparenz industrialisiert.
21. L'Usine Logicielle Augmentée Wescale. (2026-05-03): sechs Produktionslinien, menschliches Bon à Tirer (Freigabe), Strategic Judge + Agent Manager — eine Fließband-Version von Hohpes Plattform.
22. PROJ-AI Habert / WEnvision. (2026-05-05): sechs Zonen, Doktrin, Decision Records, "80% Disziplin, 20% Technologie" — ein Doktrin-Vokabular, das Hohpe ergänzt.
23. → Konvergenz: Das proportionierte Gefüge (Fruit Salad) bleibt das Kriterium von 2026. #### Konvergenz "evolutionäre Plattform > antizipative Plattform"
24. Hohpe. (2022-06): "Ich halte mich nicht für schlau genug, um die Bedürfnisse aller zu antizipieren".
25. DORA AI ROI. (2026-04-21): J-Kurve, "Lernkurve + Verifikationssteuer + Pipeline-Anpassung", ROI entsteht nach der Investition.
26. Bain Rule of 40. (2026-04): Invest to Grow > Financialize — die Plattform gewinnt man durch Iteration.
27. → Konvergenz: Die Plattform reift durch beobachtete Nutzung, nicht durch allwissende Planung. #### Konvergenz "Floating Platforms = Ernte von Fähigkeiten aus der Basis"
28. Hohpe. (2022-06): Floating Platform = verwirft, was die Basis absorbiert.
29. Cherny Sequoia. (2026-05): "das Harness wird mit besser werdendem Modell weniger wichtig" — das KI-Harness ist eine Floating Platform über dem Modell; was auch immer das Modell absorbiert (Planung, Sub-Agents, Prompt-Injection-Abwehr), verliert das Harness.
30. Osmani Agent Harness Engineering. (2026-04-19): Ratchet-Prinzip, Modellfähigkeiten ersetzen Scaffolding.
31. Stripe Minions Part 2. (2026-02-19): Toolshed ~500 MCP-Tools = Floating Platform auf dem Modell, kontinuierliche Updates.
32. → Konvergenz: Hohpes Floating-Platform-Muster nimmt die Harness-Engineering-Doktrin um 4 Jahre vorweg — die Basis (Modell) wächst, das Harness (Plattform) steigt darüber, verwirft, was nativ geworden ist. #### Konvergenz "Shared Responsibility Model"
33. Hohpe. (2022-06): "die Plattform kann furchtbar unsichere, instabile, nicht skalierende monolithische Anwendungen nicht reparieren".
34. AWS Shared Responsibility Model. (impliziter Verweis von Hohpe, Enterprise Strategist AWS).
35. DORA AI ROI. (2026-04-21): Trust, Platform, Data, Users, Guardrails — 5 systemische Schlüssel, von denen Users und Guardrails die geteilte Verantwortung konkretisieren.
36. Uber Engineering Agent Identity. (2026-05-21): "der sichere Pfad ist für Entwickler auch der einfachste Weg, A2A-Aufrufe zu implementieren" — geteilte Verantwortung, übersetzt in eine agentische Sicherheitsdoktrin. #### Produktive Spannung mit traditionellem IT Service Management
37. Hohpe. "eine gemeinsame Schicht kann vieles sein — sie ist nicht zwangsläufig eine Plattform", in Abgrenzung von IT Service Management (Flaschenhals, Formulare) gegenüber Plattform (Enabler).
38. Geudin / CIO Online. (2026-01-26): "Software- und Cloud-Raubtiere der IT-Budgets" — "Plattform"-SaaS wird räuberisch ohne FinOps-Disziplin und transparente Nutzung.
39. → Lesart: ohne Hohpes 3 Eigenschaften (geringe Reibung, Transparenz, geteilte Verantwortung) driftet eine "Plattform" in budgetäre Raubwirtschaft ab. ### Relevant für
40. Plattform-Architekten / Platform-Engineering-Leads. eine grundlegende Referenz — das Begriffspaar Floating / Sinking als strategisches Steuerungsinstrument gegenüber den Roadmaps der Basis (Cloud-Anbieter, Kubernetes, LLM-Modelle).
41. CTO / VP Engineering. das Raster der 3 Eigenschaften (geringe Reibung, Transparenz, geteilte Verantwortung) als Schnelldiagnose: "ist meine 'Plattform' wirklich eine Plattform oder getarntes IT Service Management?".
42. CIOs / IT-Beschaffungsabteilungen. das Kriterium Fruit Salad vs. Fruit Basket zur Bewertung von Anbieter-"Plattformen" (echte Wert-Komposition vs. Nebeneinanderstellung separat abgerechneter Module).
43. Produkt-Führungsgremium. die bei jeder Plattforminitiative zu formalisierende Entscheidung "Floating vs. Sinking" — welche Komponenten werden verworfen, sobald die Basis sie absorbiert? Stakeholder vorwarnen.
44. Platform Engineering 2026 (IDP / Backstage / port.io / Humanitec). Der Hohpe-Vortrag liefert das Gründungsvokabular, das der gesamten IDP-Disziplin zugrunde liegt — Reduktion der kognitiven Last, Self-Service, Blueprints, Golden Paths leiten sich aus diesem Rahmen ab.
45. Agentische KI-Plattformen (Harness Engineering). Anwendung von Floating Platform auf das Harness — jede Modellveröffentlichung (Opus 4 → 4.5 → 4.6 → 4.7) sollte ein Audit auslösen: "was verwerfen wir?".