# hohpe-platformcon-magic-of-platforms-floating-platforms-2022-06

## Veille

Keynote von **Gregor Hohpe** (Enterprise Strategist bei AWS, Autor von *The Software Architect Elevator* sowie des demnächst erscheinenden Buchs *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) bei **PlatformCon 2022** über **die Magie von Plattformen** — warum Plattformen erfolgreich sind, was sie von reinem *IT Service Management* unterscheidet, und **die nicht-trivialen Architekturentscheidungen**, die beim Aufbau einer solchen zu treffen sind. **Kernthese**: *"Standards schränken Kreativität nicht ein, sie können sie vervielfachen"* — analog zu Baltimore 1904 (Brand, inkompatible Pumpen), der ISO-Metrischschraube, HTTP, DIN-A4-Papier. **Kanonisches Zitat, entlehnt von Peter / Thoughtworks**: ***"Plattformen zentralisieren Expertise, aber nicht Innovation"*** — das Rad wird nicht neu erfunden, aber die Innovation bleibt den Teams überlassen, die dem Kunden am nächsten sind. **Zentrale Analogie**: die Automobilindustrie (der Volkswagen-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform), *"undifferentiated heavy lifting"* (AWS-Vokabular) unter der Haube, Differenzierung sichtbar auf der Kundenseite. **Drei Eigenschaften einer echten Plattform**: (1) **geringe Reibung** (*low friction*) — Adoption lässt sich nicht erzwingen, Teams umgehen sie sonst; (2) **Transparenz** (keine *Black Box*) — Nutzer müssen diagnostizieren können, ob der Fehler bei ihnen oder bei der Plattform liegt; (3) **geteilte Verantwortung** (direkter Verweis auf das *AWS Shared Responsibility Model*) — die Plattform behebt keine schlecht konzipierte Anwendung. **Explizites Anti-Pattern**: *"eine gemeinsame Schicht kann vieles sein — sie ist nicht zwangsläufig eine Plattform"*; traditionelles IT Service Management zeigt dasselbe Bild (eine gemeinsame Schicht unter allen), aber die **Schnittstelle ist das Gegenteil** (hohe Reibung, Formulare, Flaschenhals). **Zwei Aufbauwege**: (a) jeden Bedarf antizipieren (Hohpe: *"Ich halte mich nicht für schlau genug dafür"*); (b) **Evolution** ausgehend von nützlichen Bausteinen, unter Beobachtung der Nutzung. **Explizit zu treffende Entscheidungen**: Ziele (kognitive Last ↓, sicherer / weniger Fehler, schneller durch Samples/Blueprints/Self-Service, Compliance), Form der Lernkurve (Klippe, Hockeyschläger, Gangwechsel). **Kanonisches Konzept Nr. 1 — Floating Platforms vs. Sinking Platforms**: Wenn die *Basisplattform* (typischerweise die Cloud) neue Fähigkeiten erhält, gibt es **zwei entgegengesetzte Strategien**: **Sinking Platform** (statisch, dupliziert, was die Basis nun bietet, sinkt mit steigendem Wasserspiegel) vs. ***Floating Platform*** (verwirft die redundant gewordenen Teile, **steigt über das neue Niveau**, innoviert weiter oben). Metapher *"U-Boot und Boot"*. Starke vertragliche Implikation: **Stakeholder explizit vorwarnen**, dass Komponenten entfernt werden, sobald die Basis sie absorbiert. **Kanonisches Konzept Nr. 2 — Fruit Salad vs. Fruit Basket**: Eine Plattform ist keine Sammlung nebeneinandergestellter Fähigkeiten (ein Korb), sondern ein **proportioniertes, mundgerechtes** Gefüge, in dem die Teile interagieren — *"der Kilopreis für Obstsalat ist höher als für einen Obstkorb"*. Der Titel leitet sich vom Ausdruck *the magic of platforms* ab — der kontraintuitive Effekt, bei dem **Standardisierung Innovation freisetzt, statt sie zu ersticken**, sofern Schnittstelle, Weiterentwicklung und Integration der Komponenten sorgfältig gehandhabt werden. Relevant für: Plattform-Architekten, **Platform-Engineering-/IDP-Teams 2026** (eine grundlegende Referenz, die dem *Internal-Developer-Platforms*-Boom vorausging, aber dessen Vokabular strukturiert), CIOs, die Build-vs-Stagnate gegenüber nativen Cloud-Fähigkeiten bewerten, Produkt-Führungsgremien. Konvergiert mit **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Plattform als systemischer Pfeiler).

## Titre Article

The Magic of Platforms

## Date

2022-06

## URL

https://platformengineering.org/talks-library/the-magic-of-platforms

## Keywords

Software-Plattformen, Platform Engineering, Internal Developer Platforms IDP, Gregor Hohpe, AWS Enterprise Strategist, The Software Architect Elevator, Platform Strategy, PlatformCon 2022, undifferentiated heavy lifting, Standards fördern Innovation, Baltimore 1904 Feuerwehrkupplungen, ISO-Metrischschraube, HTTP-Standard, DIN-A4-Papierstandard, Expertise zentralisieren, nicht Innovation, Peter Thoughtworks, Automobil-Analogie Volkswagen MQB Audi Bentley, IT Service Management vs. Plattform, geringe Reibung, Plattform-Transparenz, keine Black Box, Shared Responsibility Model AWS, evolutionäres Plattformdesign, kognitive Last, Lernkurve Klippe, Hockeyschläger, Gangwechsel, Floating Platforms, Sinking Platforms, Basisplattform wächst, U-Boot-Boot-Metapher, Fruit Salad vs. Fruit Basket, Kilopreis Plattformwert, Architektur als Abfolge nicht-trivialer Entscheidungen, Samples Blueprints Self-Service, Compliance über die Plattform, Mechanismen Plattformwert

## Authors

**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services, architecte logiciel, auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk, écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech*, expérience CTO Allianz, conseil C-suite, conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).

## Ton

**Profil**: Erfahrener Keynote-Sprecher, adressiert an Plattform-Architekten, Platform-Engineering-Leiter, CTO/VP Engineering, Leiter interner Plattform-Teams. Format ~15 Minuten, **lehrreiches und analytisches** Register, **maßvoller, demonstrativer, analogiegetriebener** Ton. Zielgruppe: Organisationen, die eine interne Plattform aufbauen oder dies erwägen.

**Stil**: Hohpes Stimme — klares Englisch, aufgebaut als **historische Analogie → Kontraintuition → Architekturregel**. Spiralförmige Erzählstruktur: beginnt mit dem naiven Bild (gemeinsame Schicht + Bausteine darüber) → weckt Zweifel *"da steckt viel mehr dahinter"* → dekonstruiert anhand von Beispielen → rekonstruiert mit einem Entscheidungsrahmen. **Jargonfreies**, aber präzises Vokabular: *undifferentiated heavy lifting* (entlehnt von Bezos / AWS), *low friction*, *shared responsibility*, *floating / sinking platforms*. Keine überladenen Folien, **eine visuelle Metapher pro Konzept** (Feuerwehrwagen, Metrischschraube, Boot / U-Boot, Korb vs. Obstsalat).

**Zentrale Aphorismen**:
- *"Standards können Kreativität fördern"* — *"niemand kann sagen, ich kann nicht wirklich kreativ sein, weil ihr mir Papier im A4-Format gegeben habt"*
- *"Plattformen zentralisieren Expertise, aber nicht Innovation"* (Zitat von Peter / Thoughtworks)
- *"Man kann niemanden zwingen, auf die eigene Plattform zu wechseln. Versucht man es doch, finden sie andere Wege, ihre Arbeit zu erledigen — und wisst ihr was, das sollten sie wahrscheinlich auch. Sie haben Arbeit zu tun."*
- *"Eine gemeinsame Schicht kann vieles sein. Sie ist nicht zwangsläufig eine Plattform."*
- *"Architektur ist eine Abfolge nicht-trivialer Entscheidungen"*
- *"Wenn die Basisplattform 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."* (Floating Platforms)
- *"Der Kilopreis für Obstsalat ist höher als für einen Obstkorb"* (Fruit Salad vs. Basket)

**Ausgearbeitete Metaphern**:
- ***Undifferentiated heavy lifting*** (Automobil) — Motor, Getriebe, ABS, Bremsen, Abgaskontrolle = für den Kunden unsichtbar, einmal erledigt, markenübergreifend geteilt (Audi A4 → Bentley Bentayga auf derselben VW-Konzern-Plattform).
- ***Feuerwehrschlauch-Kupplung*** (Baltimore 1904) — das Fehlen eines Standards brannte eine Stadt nieder; der Standard vervielfachte die Fähigkeit der Feuerwehrleute zu gegenseitiger Hilfe.
- ***U-Boot und Boot*** — Sinking Platform = U-Boot (sinkt), Floating Platform = Boot (steigt mit der Flut).
- ***Fruit Salad vs. Fruit Basket*** — der Wert liegt in der **proportionierten Integration** der Teile, nicht in ihrer Nebeneinanderstellung.

**Epistemische Haltung**: präskriptiv, aber **nicht militant**. Hohpe sagt nicht *"hier ist das eine richtige Design"*, sondern *"hier sind die Entscheidungen, die explizit zu treffen sind, und ihre Konsequenzen"*. Stärke des Inhalts: (a) **historische Tiefe** (die Automobilindustrie hat dieses Problem vor Jahrzehnten gelöst — Plattformen sind nichts Neues), (b) **konzeptionelle Präzision** (das Begriffspaar Sinking/Floating ist ein dauerhaftes Denkwerkzeug), (c) **Ehrlichkeit** (*"Ich halte mich nicht für schlau genug, um die Bedürfnisse aller zu antizipieren"*).

**Autorität**: gestützt auf (a) die Rolle als **Enterprise Strategist AWS** (ein 360°-Blick auf Enterprise-Cloud-Architekturen), (b) Hohpes **redaktionelle Marke** (*Enterprise Integration Patterns* gilt seit 20 Jahren als kanonisch), (c) die **Architect-Elevator-Reihe** (eine gemeinsame Sprache für Senior-Architekten), (d) die **visuelle Einfachheit** der Analogien (ein Diagramm = eine Idee).

## Pense-betes

- **Datum / Quelle**: Keynote **PlatformCon 2022** (Juni 2022), YouTube-Aufzeichnung *The Magic of Platforms* (~15 Min.), Sammelseite *platformengineering.org/talks-library/the-magic-of-platforms*.
- **Sprecher**: Gregor Hohpe, Enterprise Strategist AWS, Autor von *Software Architect Elevator* + demnächst erscheinendes Buch *Platform Strategy* (Leanpub).
- **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)
- Die Automobilindustrie löst *"the undifferentiated heavy lifting"* (Motor, Getriebe, ABS, Abgaskontrolle, Abgasnormen) **einmal**.
- Setzt darüber je nach Segment unterschiedliche *"Hüte"* auf.
- **Der VW-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform** (MQB wird nicht namentlich genannt, ist aber gemeint).
- 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
- Identisches Bild (gemeinsame Schicht + Bausteine), aber **umgekehrte Schnittstelle**: hohe Reibung, Formulare, Flaschenhals, das Hinzufügen eines Kunden ist aufwendig.
- *"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**:
- **Kognitive Last** / **Lernkurve** reduzieren
- **Sicherer**: *"geringere Wahrscheinlichkeit, Fehler zu machen"* — indem *"Randfälle oder Komplexität verborgen werden"*
- **Schneller**: Samples, Blueprints, besseres Self-Service
- **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**:
- **Schnittstellenabstraktion**: Die Plattform muss ihre Fähigkeiten über eine stabile Schnittstelle bereitstellen — sonst bricht das *"Wegwerfen von Dingen"* die Konsumenten.
- **Expliziter Lebenszyklus**: Komponenten von Geburt an als *"deprecate, sobald die Basis dies bietet"* kennzeichnen.
- **Aktive Beobachtung der Basisplattform**: die *Roadmap* des Basis-Anbieters (AWS, GCP, Azure, Kubernetes usw.) **ist** die Größe, an der man sich ausrichten muss.
- **Stakeholder-Kommunikation**: vor der Entfernung warnen, sonst wird es als Vertrauensbruch empfunden.
- **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"
- **Hohpe** (2022-06): Fruit Salad > Fruit Basket, geringe Reibung + Transparenz + geteilte Verantwortung.
- **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.
- **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.
- **PROJ-AI Habert / WEnvision** (2026-05-05): sechs Zonen, Doktrin, Decision Records, *"80% Disziplin, 20% Technologie"* — ein Doktrin-Vokabular, das Hohpe ergänzt.
- → **Konvergenz**: Das **proportionierte Gefüge** (Fruit Salad) bleibt das Kriterium von 2026. #### Konvergenz "evolutionäre Plattform > antizipative Plattform"
- **Hohpe** (2022-06): *"Ich halte mich nicht für schlau genug, um die Bedürfnisse aller zu antizipieren"*.
- **DORA AI ROI** (2026-04-21): J-Kurve, *"Lernkurve + Verifikationssteuer + Pipeline-Anpassung"*, ROI entsteht **nach** der Investition.
- **Bain Rule of 40** (2026-04): *Invest to Grow* > *Financialize* — die Plattform gewinnt man durch Iteration.
- → **Konvergenz**: Die Plattform **reift durch beobachtete Nutzung**, nicht durch allwissende Planung. #### Konvergenz "Floating Platforms = Ernte von Fähigkeiten aus der Basis"
- **Hohpe** (2022-06): Floating Platform = verwirft, was die Basis absorbiert.
- **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.
- **Osmani Agent Harness Engineering** (2026-04-19): *Ratchet-Prinzip*, Modellfähigkeiten ersetzen Scaffolding.
- **Stripe Minions Part 2** (2026-02-19): Toolshed ~500 MCP-Tools = Floating Platform auf dem Modell, kontinuierliche Updates.
- → **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"
- **Hohpe** (2022-06): *"die Plattform kann furchtbar unsichere, instabile, nicht skalierende monolithische Anwendungen nicht reparieren"*.
- **AWS Shared Responsibility Model** (impliziter Verweis von Hohpe, Enterprise Strategist AWS).
- **DORA AI ROI** (2026-04-21): *Trust, Platform, Data, Users, Guardrails* — 5 systemische Schlüssel, von denen *Users* und *Guardrails* die geteilte Verantwortung konkretisieren.
- **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
- **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).
- **Geudin / CIO Online** (2026-01-26): *"Software- und Cloud-Raubtiere der IT-Budgets"* — *"Plattform"*-SaaS wird räuberisch ohne FinOps-Disziplin und transparente Nutzung.
- → **Lesart**: ohne Hohpes 3 Eigenschaften (geringe Reibung, Transparenz, geteilte Verantwortung) driftet eine *"Plattform"* in *budgetäre Raubwirtschaft* ab. ### Relevant für
- **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).
- **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?"*.
- **CIOs / IT-Beschaffungsabteilungen**: das Kriterium *Fruit Salad vs. Fruit Basket* zur Bewertung von Anbieter-*"Plattformen"* (echte Wert-Komposition vs. Nebeneinanderstellung separat abgerechneter Module).
- **Produkt-Führungsgremium**: die bei jeder Plattforminitiative zu formalisierende Entscheidung *"Floating vs. Sinking"* — welche Komponenten werden verworfen, sobald die Basis sie absorbiert? Stakeholder vorwarnen.
- **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.
- **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?"*.

## RésuméDe400mots

**Gregor Hohpe**, Enterprise Strategist bei Amazon Web Services und Autor von *The Software Architect Elevator*, hielt im Juni 2022 bei **PlatformCon 2022** eine fünfzehnminütige, lehrreiche Keynote: *The Magic of Platforms*. Seine Kernthese kehrt die gängige Intuition um: ***"Standards schränken Kreativität nicht ein — sie können sie vervielfachen"***. Drei historische Beispiele untermauern sie: der Brand von Baltimore 1904 (benachbarte Pumpen ließen sich mangels Kupplungsstandard nicht anschließen), die ISO-Metrischschraube und HTTP — allesamt massive Innovationstreiber. DIN-A4-Papier rundet die Demonstration ab: seine Standardisierung hat die Kreativität nie gebremst — im Gegenteil, sie ersparte Streit über die Umschlaggröße.

Die zentrale Analogie des Vortrags ist **die Automobilindustrie**: Der Volkswagen-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform. Das *"undifferentiated heavy lifting"* (AWS-Vokabular) — Motor, Getriebe, ABS, Abgasnormen — wird einmal erledigt; die sichtbare Differenzierung bleibt auf der Kundenseite. Hohpe zitiert Peter von Thoughtworks: ***"Plattformen zentralisieren Expertise, aber nicht Innovation"*** — die bleibt bei den Teams, die dem Kunden am nächsten sind.

Hohpe identifiziert drei Eigenschaften einer echten Plattform: (1) **geringe Reibung** — Adoption lässt sich nicht erzwingen; (2) **Transparenz** — der Nutzer muss diagnostizieren können; (3) **geteilte Verantwortung** — die Plattform rettet keine schlecht konzipierte Anwendung. Anti-Pattern: *"eine gemeinsame Schicht ist nicht zwangsläufig eine Plattform"* — traditionelles IT Service Management zeigt dasselbe Bild, aber die umgekehrte Schnittstelle (Flaschenhals, Formulare).

Zwei Aufbauwege: jeden Bedarf antizipieren (illusorisch) oder ausgehend von nützlichen Bausteinen **evolvieren**. Explizit zu treffende Entscheidungen: zu reduzierende kognitive Last, Lernkurve (Klippe, Hockeyschläger, Gangwechsel).

Kanonisches Konzept Nr. 1 — ***Floating Platforms vs. Sinking Platforms***: Wenn die *Basisplattform* (Cloud) Fähigkeiten hinzugewinnt, bleibt die Plattform entweder unverändert (Sinking, dupliziert, sinkt), oder **die redundant gewordenen Teile werden verworfen und die Plattform steigt höher, um zu innovieren** (Floating). Metapher: *U-Boot und Boot*. Zentrale vertragliche Bedingung: Stakeholder explizit vorwarnen, dass Dinge verworfen werden.

Kanonisches Konzept Nr. 2 — ***Fruit Salad vs. Fruit Basket***: Die Plattform ist keine nebeneinandergestellte Sammlung, sondern ein proportioniertes Gefüge, in dem die Teile interagieren. *"Der Kilopreis für Obstsalat ist höher als für einen Obstkorb."*

Fazit: Architektur = eine Abfolge nicht-trivialer Entscheidungen; sie explizit zu machen ist die *magic of platforms*.

## GrapheDeConnaissance

- Gregor Hohpe —travaille_chez→ Amazon Web Services (ORGANISATION, 0.97)
- Gregor Hohpe —publie→ The Software Architect Elevator (DOCUMENT, 0.97)
- Gregor Hohpe —publie→ Platform Strategy (DOCUMENT, 0.95)
- Gregor Hohpe —publie→ The Magic of Platforms (keynote PlatformCon 2022) (DOCUMENT, 0.98)
- Standards —améliore→ innovation et créativité (CONCEPT, 0.95)
- Incendie Baltimore 1904 —soutient→ nécessité des standards de coupling (CONCEPT, 0.95)
- HTTP —améliore→ innovation web (CONCEPT, 0.97)
- Industrie automobile —utilise→ plateforme partagée multi-marques (METHODOLOGIE, 0.96)
- Volkswagen Group —a_créé→ Audi A4 et Bentley Bentayga sur même plateforme (TECHNOLOGIE, 0.95)
- Peter (Thoughtworks) —affirme_que→ « platforms centralize expertise but not innovation » (CITATION, 0.96)
- Plateforme —utilise→ low friction (CONCEPT, 0.97)
- Plateforme —utilise→ transparence (pas black box) (CONCEPT, 0.97)
- Plateforme —utilise→ shared responsibility (CONCEPT, 0.97)
- Shared responsibility —observé_dans→ AWS Shared Responsibility Model (METHODOLOGIE, 0.95)
- IT Service Management traditionnelle —s_oppose_à→ plateforme low-friction (CONCEPT, 0.93)
- Plateforme évolutive —surpasse→ plateforme anticipative (METHODOLOGIE, 0.94)
- Floating platform —réduit→ Base platform (CONCEPT, 0.97)
- Sinking platform —converge_avec→ Base platform (CONCEPT, 0.96)
- Floating platform —utilise→ communication explicite stakeholders (CONCEPT, 0.95)
- Fruit salad vs fruit basket —surpasse→ Fruit salad vs fruit basket (CONCEPT, 0.95)
- Plateforme —utilise→ composants proportionnés bite-sized (CONCEPT, 0.94)
- Gregor Hohpe —affirme_que→ l'architecture est une série de décisions non-triviales (AFFIRMATION, 0.95)
- Floating platform —converge_avec→ doctrine harness engineering 2026 (METHODOLOGIE, 0.88)
- The Magic of Platforms —converge_avec→ AI/works™ + Wescale Usine Logicielle + PROJ-AI + DORA AI ROI (CONCEPT, 0.9)

---
Canonical: https://www.thekb.eu/de/fiches/hohpe-platformcon-magic-of-platforms-floating-platforms-2022-06/