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

## Veille

Keynote **Gregor Hohpe** (Enterprise Strategist AWS, auteur *The Software Architect Elevator* et du livre en cours *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) à **PlatformCon 2022** sur **la magie des plateformes** — pourquoi les plateformes réussissent, ce qui les distingue d'une simple *IT Service Management*, et **les décisions d'architecture non-triviales** à prendre quand on en construit une. **Thèse-pivot** : *« les standards ne réduisent pas la créativité, ils peuvent la décupler »* — analogue Baltimore 1904 (incendie, pompes incompatibles), vis métrique ISO, HTTP, papier A4. **Citation canonique reprise de Peter / Thoughtworks** : ***« platforms centralize expertise but not innovation »*** — on ne réinvente pas la roue, mais on laisse l'innovation aux équipes proches du client. **Analogie pivot** : industrie automobile (Volkswagen Group construit Audi A4 et Bentley Bentayga sur la même plateforme), *« undifferentiated heavy lifting »* (vocabulaire AWS) sous le capot, différenciation visible côté client. **Trois propriétés d'une vraie plateforme** : (1) **low friction** — on ne peut pas forcer l'adoption, les équipes contourneront ; (2) **transparence** (pas une *black box*) — les utilisateurs doivent pouvoir diagnostiquer s'ils sont en cause ou si c'est la plateforme ; (3) **shared responsibility** (référence directe au *AWS Shared Responsibility Model*) — la plateforme ne corrige pas une appli mal conçue. **Anti-pattern explicite** : *« a common layer can be many things — it is not necessarily a platform »* ; l'IT Service Management traditionnelle a la même image (couche commune sous tout le monde) mais l'**interface est l'opposée** (high-friction, formulaires, bottleneck). **Deux voies de construction** : (a) anticiper tous les besoins (Hohpe : *« I don't feel I'm smart enough »*) ; (b) **évolution** à partir de pièces utiles, en observant l'usage. **Décisions à expliciter** : objectifs (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), forme de la courbe d'apprentissage (cliff, hockey stick, gear shift). **Concept canonique #1 — Floating platforms vs Sinking platforms** : quand la *base platform* (typiquement le cloud) gagne de nouvelles capacités, **deux stratégies opposées** : **sinking platform** (statique, dupliquant ce que la base offre maintenant, coulant à mesure que le niveau monte) vs ***floating platform*** (jette les morceaux devenus redondants, **re-monte au-dessus du nouveau niveau**, innove plus haut). Métaphore *« submarine and a boat »*. Implication contractuelle forte : **prévenir explicitement les stakeholders** que des composants seront supprimés quand la base les absorbe. **Concept canonique #2 — Fruit salad vs Fruit basket** : une plateforme n'est pas une collection de capacités juxtaposées (panier) mais un assemblage **proportionné et bite-sized** où les pièces interagissent — *« the per-kilo price for fruit salad is higher than for a fruit basket »*. Le titre dérive de l'expression *the magic of platforms* — l'effet contre-intuitif où **standardiser libère l'innovation au lieu de l'étouffer**, à condition de soigner l'interface, l'évolution et l'intégration entre les composants. À mobiliser pour : architectes plateforme, **Platform Engineering / IDP teams 2026** (référence fondatrice, prédate l'explosion *Internal Developer Platforms* mais structure le vocabulaire), DSI évaluant build-vs-stagnate face aux capacités natives cloud, COMEX produit. Convergence avec **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 — Platform comme pilier systémique).

## Titre Article

The Magic of Platforms

## Date

2022-06

## URL

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

## Keywords

Plateformes logicielles, platform engineering, Internal Developer Platforms IDP, Gregor Hohpe, AWS Enterprise Strategist, The Software Architect Elevator, Platform Strategy, PlatformCon 2022, undifferentiated heavy lifting, standards boostent l'innovation, Baltimore 1904 fire couplings, ISO metric screw, HTTP standard, A4 paper standard, centralize expertise not innovation, Peter Thoughtworks, automotive analogy Volkswagen MQB Audi Bentley, IT Service Management vs platform, low friction, transparence platform pas black box, shared responsibility model AWS, evolutionary platform design, cognitive load, learning curve cliff, hockey stick, gear shift, floating platforms, sinking platforms, base platform grows, submarine boat metaphor, fruit salad vs fruit basket, per-kilo price platform value, architecture as series of non-trivial decisions, samples blueprints self-service, compliance via platform, mechanisms platform value

## 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** : Keynote conférencier expérimenté à destination architectes, leaders Platform Engineering, CTO/VP Engineering, leaders d'équipes plateforme internes. Format ~15 minutes, registre **pédagogique et analytique**, ton **mesuré, démonstratif, argumenté par l'analogie**. Public cible : organisations qui construisent ou réfléchissent à construire une plateforme interne.

**Style** : Voix Hohpe — anglais clair, articulation **analogie historique → contre-intuition → règle d'architecture**. Structure narrative en spirale : commence par l'image naïve (couche commune + briques au-dessus) → introduit le doute *« there's a lot more behind it »* → déconstruit avec des exemples → reconstruit avec un cadre de décision. Vocabulaire **non-jargon** mais précis : *undifferentiated heavy lifting* (emprunté à Bezos / AWS), *low friction*, *shared responsibility*, *floating / sinking platforms*. Pas de slides surchargés, **une métaphore visuelle par concept** (camion de pompiers, vis métrique, bateau / sous-marin, panier vs salade de fruits).

**Aphorismes-clés** :
- *« Standards can boost creativity »* — *« nobody can come and say I cannot really be creative because you gave me A4 size paper »*
- *« Platforms centralize expertise but not innovation »* (citation de Peter / Thoughtworks)
- *« You cannot force anyone to get on your platform. If you try, they will find other ways to get their work done — and you know what, they probably should. They have work to do. »*
- *« A common layer can be many things. It is not necessarily a platform. »*
- *« Architecture is a series of non-trivial decisions »*
- *« When the base platform gains the capabilities you have built, you say: oh perfect, I don't need my part anymore. I can let the base platform handle that, and I innovate further on top. »* (floating platforms)
- *« The per-kilo price for fruit salad is higher than for a fruit basket »* (fruit salad vs basket)

**Métaphores travaillées** :
- ***Undifferentiated heavy lifting*** (automobile) — moteur, transmission, ABS, freinage, antipollution = invisible pour le client, fait une fois, partagé entre marques (Audi A4 → Bentley Bentayga sur la même plateforme VW Group).
- ***Fire hose coupling*** (Baltimore 1904) — l'absence de standard a brûlé une ville ; le standard a démultiplié la capacité d'entraide entre pompiers.
- ***Submarine and boat*** — sinking platform = sous-marin (coule), floating platform = bateau (monte avec la marée).
- ***Fruit salad vs fruit basket*** — la valeur est dans l'**intégration proportionnée** des morceaux, pas leur juxtaposition.

**Position épistémique** : prescriptive mais **non militante**. Hohpe ne dit pas *« voici le seul bon design »*, il dit *« voici les décisions que vous devez expliciter et leurs conséquences »*. Force du contenu : (a) **profondeur historique** (l'industrie automobile a résolu ce problème il y a des décennies — les plateformes ne sont pas neuves), (b) **précision conceptuelle** (le couple sinking / floating est un outil de pensée durable), (c) **honnêteté** (*« I don't feel I'm smart enough to anticipate everybody's needs »*).

**Autorité** : construite par (a) le rôle d'**Enterprise Strategist AWS** (vue à 360° des architectures cloud d'entreprise), (b) la **marque éditoriale** Hohpe (*Enterprise Integration Patterns* est canonique depuis 20 ans), (c) la **série Architect Elevator** (langage commun pour architectes seniors), (d) la **simplicité visuelle** des analogies (un schéma = une idée).

## Pense-betes

- **Date / source** : keynote **PlatformCon 2022** (juin 2022), enregistrement YouTube *The Magic of Platforms* (~15 min), page hub *platformengineering.org/talks-library/the-magic-of-platforms*.
- **Speaker** : Gregor Hohpe, Enterprise Strategist AWS, auteur *Software Architect Elevator* + livre en cours *Platform Strategy* (Leanpub).
- **Public** : architectes plateforme, Platform Engineering teams, CTO/VP Engineering.

### Thèse-pivot
> ***« Locking some things down — agreeing on a few things — can actually boost innovation and creativity. And platforms are right in the center of this. »***

### Standards = innovation booster (3 exemples)
| Exemple | Date | Leçon |
|---------|------|-------|
| **Incendie de Baltimore** | 1904 | Les pompiers des villes voisines ne pouvaient pas brancher leurs lances sur les hydrants → standard *Baltimore* depuis |
| **Vis métrique ISO** | parmi les premiers standards ISO | N'importe quelle vis conforme au standard se monte sur n'importe quel filetage conforme |
| **HTTP** | 1991+ | N'importe quel navigateur peut se connecter à n'importe quel serveur web — booster d'innovation massif |
| **Papier A4** | (référence) | 297 × 210 mm = 1/16 m² — *« nobody's creativity is impeded »*, au contraire, plus de débats sur la taille de l'enveloppe ou du tiroir |

### Analogie automobile (cœur du talk)
- Industrie auto résout *« the undifferentiated heavy lifting »* (moteur, transmission, ABS, antipollution, normes émissions) **une fois**.
- Met différents *« hats »* dessus pour différents segments.
- **VW Group construit Audi A4 et Bentley Bentayga sur la même plateforme** (le MQB n'est pas nommé mais c'est le référent).
- Le client voit la couleur, l'intérieur, le bruit des portes — pas le différentiel.

### Citation Peter / Thoughtworks (canonique)
> ***« Platforms are really a way to centralize expertise. You don't need to reinvent the wheel multiple times. But you do not centralize innovation — you leave that to the teams who are closest to the customer and have the best ideas. »***

### Trois propriétés d'une *vraie* plateforme
1. **Low friction** — *« you cannot force anyone to get on your platform; if you try, they will find other ways »*.
2. **Transparente (pas black box)** — les utilisateurs doivent diagnostiquer : *« is it me, or is it the platform ? »*.
3. **Shared responsibility** — analogie AWS : *« if you build a horribly insecure brittle non-scaling monolithic application, the platform itself cannot fix that for you »*.

### Anti-pattern explicite : IT Service Management déguisée en plateforme
- Image identique (couche commune + briques) mais **interface inverse** : high-friction, formulaires, bottleneck, ajouter un client coûte cher.
- *« Don't be fooled by the picture of the common layer — a common layer can be many things. It is not necessarily a platform. »*

### Deux voies de construction
| Voie | Description | Hohpe |
|------|-------------|-------|
| (a) **Anticiper** tous les besoins | *« You're somehow smarter than anybody else and you anticipate everybody's needs and you implement those things into your platform and everybody lived happily ever after. »* | Ton ironique, probablement irréaliste |
| (b) **Évoluer** | *« Start with some useful pieces, observe what people need, often you can do this through the platform usage yourself, and you start augmenting the platform. »* | Voie recommandée — Hohpe : *« I don't feel I'm smart enough to anticipate everybody's needs »* |

### Décisions architecturales à expliciter (les *« dials »*)
**Objectifs visés** :
- Réduire **cognitive load** / **learning curve**
- **Safer** : *« less likely to make mistakes »* — par *« hiding corner cases or complexities »*
- **Faster** : samples, blueprints, better self-service
- **Productivity** / **collaboration** / **compliance** / **minimizing mistakes**

**Mécanismes** : quels leviers tu utilises pour atteindre quoi.

### Formes de courbes d'apprentissage
| Forme | Description |
|-------|-------------|
| **Cliff** | *« Even if you want to do hello world it takes a certain amount of effort »* — initial high |
| **Linear (idéal)** | Rare en pratique |
| **Hockey stick** | Bake in assumptions → l'expérience initiale est facile, mais dès que les hypothèses ne tiennent plus, *« life becomes disproportionately harder »* |
| **Gear shift** | Moins pire que hockey stick : changer de service dans la plateforme, mais *« in between there's a gear shift, they need to learn new things »* |

### CONCEPT CANONIQUE — Floating platforms vs Sinking platforms

**Contexte** : *« in almost all cases you're not going to build a platform in isolation — you're going to build it on top of a base platform »* (le cloud / AWS étant l'exemple typique). **La base platform grossit aussi**. Décision stratégique majeure : que fait-on de notre plateforme quand la base absorbe certaines capacités ?

| Stratégie | Description | Métaphore | Verdict Hohpe |
|-----------|-------------|-----------|---------------|
| **Sinking platform** | Tu **gardes ta plateforme identique** parce que tu as investi dedans. La base monte. Ta plateforme **duplique** désormais des choses que la base offre nativement. *« As the water level rises »*, ta plateforme **coule** (devient un fardeau de maintenance, ralentit l'innovation). | Sous-marin qui coule | *« Might be justified from investment, but really you're sort of duplicating things that are now in the base platform »* — anti-pattern de facto. |
| ***Floating platform*** | Quand la base gagne les capacités que tu avais construites, tu dis : *« oh perfect, I don't need my part anymore — I can let the base platform handle that and I innovate further on top »*. **Tu jettes ce qui est devenu redondant, tu re-montes plus haut**, tu construis du nouveau. | Bateau qui flotte sur la marée | Voie recommandée — mais avec une **condition contractuelle** explicite. |

**Condition contractuelle (clé)** :
> ***« Both are sensible choices, and it's very important to make this clear upfront with your stakeholders. If you're building a floating platform, they need to be prepared that you will be throwing things away as soon as the base platform has the same capabilities. »***

**Implications pour le design / la gouvernance** :
- **Abstraction d'interface** : la plateforme doit exposer ses capacités via une interface stable — sinon, *« throwing things away »* casse les consommateurs.
- **Cycle de vie explicite** : marquer les composants *« deprecate when base provides this »* dès leur naissance.
- **Veille active sur la base platform** : la *roadmap* de l'éditeur de la base (AWS, GCP, Azure, Kubernetes, etc.) **est** ton sujet de pilotage.
- **Communication stakeholders** : prévenir avant la suppression, sinon c'est perçu comme un breach.
- **Mesure d'innovation** : la valeur d'une floating platform se mesure à **ce qu'elle construit *en plus***, pas à ce qu'elle conserve.

**Risque de la sinking platform** : sunk cost fallacy à grande échelle — *« on a déjà investi 3 ans dans ce module, on le garde »* alors que la base l'offre désormais en SaaS managé moins cher et mieux maintenu.

**Risque de la floating platform** : instabilité côté consommateurs si la communication est insuffisante. **Le contrat moral et technique avec les utilisateurs est la pierre angulaire**.

### CONCEPT CANONIQUE — Fruit salad vs fruit basket

**Contexte** : dernière décision du talk — *« how do the parts of your platform interact ? »*.

| Modèle | Description | Valeur de marché |
|--------|-------------|------------------|
| **Fruit basket** | Pièces fairly self-contained, juxtaposées. *« That is good but that's not the full strength of the platform. »* | Prix au kilo du fruit |
| ***Fruit salad*** | *« Right proportion of fruit in bite-sized pieces »*. *« If they need to be a little bit more apple than orange, you don't need to put a whole apple and a full orange »*. | ***« Per-kilo price for fruit salad is higher than for fruit basket »*** — la valeur émerge de l'**assemblage proportionné**. |

**Implication architecturale** : la plateforme doit **enabler de nouveaux use cases** par composition (le *picnic* avec la salade de fruits est plus facile que de trimballer un panier). Pour le Platform Engineering : penser **flows d'usage transverses** (cross-service), pas seulement catalogue de services indépendants.

### Articulation dossier veille

#### Convergence "platform engineering = orchestration de capabilities, pas catalogue"
- **Hohpe** (2022-06) : fruit salad > fruit basket, low friction + transparence + shared responsibility.
- **AI/works™ Thoughtworks** (2026-05-12) : six capacités couvrant tout le SDLC, Control Plane *« cost transparency + active guardrails + end-to-end lineage »* — la transparence de Hohpe industrialisée.
- **L'Usine Logicielle Augmentée Wescale** (2026-05-03) : six lignes de fabrication, Bon à Tirer humain, Juge Stratégique + Manager d'Agents — version chaîne de production de la plateforme Hohpe.
- **PROJ-AI Habert / WEnvision** (2026-05-05) : six zones, doctrine, Decision Records, *« 80% discipline, 20% techno »* — vocabulaire-doctrine qui complète Hohpe.
- → **Convergence** : la **proportion-assemblage** (fruit salad) reste le critère 2026.

#### Convergence "evolutionary platform > anticipative platform"
- **Hohpe** (2022-06) : *« I don't feel I'm smart enough to anticipate everybody's needs »*.
- **DORA AI ROI** (2026-04-21) : J-Curve, *« learning curve + verification tax + pipeline adaptation »*, ROI émerge **après** l'investissement.
- **Bain Rule of 40** (2026-04) : *Invest to Grow* > *Financialize* — la plateforme se conquiert par itération.
- → **Convergence** : la plateforme **mûrit par usage observé**, pas par planning omniscient.

#### Convergence "floating platforms = capability harvesting de la base"
- **Hohpe** (2022-06) : floating platform = on jette ce que la base absorbe.
- **Cherny Sequoia** (2026-05) : *« the harness becomes less important as the model improves »* — **le harness IA est une floating platform** au-dessus du modèle ; ce que le modèle absorbe (planning, sub-agents, prompt injection defense), le harness le perd.
- **Osmani Agent Harness Engineering** (2026-04-19) : *ratchet principle*, capacités du modèle remplacent le scaffolding.
- **Stripe Minions Part 2** (2026-02-19) : Toolshed ~500 MCP tools = floating platform sur le modèle, mise à jour continue.
- → **Convergence** : le pattern *floating platform* de Hohpe **anticipe par 4 ans** la doctrine *harness engineering* — la base (modèle) grossit, le harness (plateforme) remonte au-dessus, jette ce qui est devenu natif.

#### Convergence "shared responsibility model"
- **Hohpe** (2022-06) : *« platform cannot fix horribly insecure brittle non-scaling monolithic applications »*.
- **AWS Shared Responsibility Model** (référence implicite de Hohpe, Enterprise Strategist AWS).
- **DORA AI ROI** (2026-04-21) : *Trust, Platform, Data, Users, Guardrails* — 5 clés systémiques, dont *Users* et *Guardrails* matérialisent la responsabilité partagée.
- **Uber Engineering Agent Identity** (2026-05-21) : *« the secure path is also the easiest path for developers to implement A2A calls »* — shared responsibility traduite en doctrine sécurité agentic.

#### Tension productive avec l'IT Service Management traditionnelle
- **Hohpe** : *« a common layer can be many things — it is not necessarily a platform »*, distingue *IT Service Management* (bottleneck, formulaires) de *platform* (enabler).
- **Geudin / CIO Online** (2026-01-26) : *« logiciels et cloud prédateurs des budgets IT »* — les SaaS *« plateformes »* deviennent prédateurs faute de discipline FinOps + d'usage transparent.
- → **Lecture** : sans les 3 propriétés de Hohpe (low friction, transparence, shared responsibility), une *« plateforme »* dérive en *prédation budgétaire*.

### À mobiliser pour

- **Architectes plateforme / Platform Engineering leads** : référence fondatrice — couple **floating / sinking** comme outil de pilotage stratégique vis-à-vis des roadmaps des bases (cloud providers, Kubernetes, modèles LLM).
- **CTO / VP Engineering** : grille des 3 propriétés (low friction, transparence, shared responsibility) comme **diagnostic rapide** : *« ma "plateforme" est-elle vraiment une plateforme ou un IT Service Management déguisé ? »*.
- **DSI / Directions achats IT** : critère *fruit salad vs fruit basket* pour évaluer les *« plateformes »* éditeurs proposées (composition de valeur réelle vs juxtaposition de modules facturés séparément).
- **COMEX produit** : décision *« floating vs sinking »* à formaliser sur tout chantier plateforme — quels composants seront jetés quand la base les absorbe ? prévenir les stakeholders.
- **Platform Engineering 2026 (IDP / Backstage / port.io / Humanitec)** : le talk Hohpe donne le **vocabulaire fondateur** sous-jacent à toute la discipline IDP — *cognitive load reduction*, *self-service*, *blueprints*, *golden paths* dérivent de ce cadre.
- **Plateformes agentic IA (harness engineering)** : appliquer **floating platform** au harness — chaque release modèle (Opus 4 → 4.5 → 4.6 → 4.7) doit déclencher un audit *« qu'est-ce qu'on jette ? »*.

## RésuméDe400mots

**Gregor Hohpe**, Enterprise Strategist Amazon Web Services et auteur du *Software Architect Elevator*, livre en juin 2022 à **PlatformCon 2022** une keynote pédagogique de quinze minutes : *The Magic of Platforms*. Sa thèse-pivot inverse l'intuition courante : ***« les standards ne réduisent pas la créativité — ils peuvent la décupler »***. Trois exemples historiques l'étayent : l'incendie de Baltimore en 1904 (les pompes voisines ne pouvaient pas se brancher faute de standard de coupling), la vis métrique ISO, et HTTP — boosters d'innovation massifs. Le papier A4 ferme la démonstration : sa standardisation n'a jamais bridé la créativité, elle a au contraire évité d'argumenter sur la taille des enveloppes.

L'analogie cœur du talk est **l'industrie automobile** : Volkswagen Group construit Audi A4 et Bentley Bentayga sur la même plateforme. Le *« undifferentiated heavy lifting »* (vocabulaire AWS) — moteur, transmission, ABS, normes émissions — est fait une fois ; la différenciation visible reste côté client. Hohpe cite Peter de Thoughtworks : ***« les plateformes centralisent l'expertise, mais pas l'innovation »*** — celle-ci reste aux équipes proches du client.

Hohpe distingue trois propriétés d'une vraie plateforme : (1) **low friction** — on ne peut pas forcer l'adoption ; (2) **transparence** — l'utilisateur doit pouvoir diagnostiquer ; (3) **shared responsibility** — la plateforme ne sauve pas une appli mal conçue. Anti-pattern : *« une couche commune n'est pas nécessairement une plateforme »* — l'IT Service Management traditionnelle a la même image mais l'interface inverse (bottleneck, formulaires).

Deux voies de construction : anticiper tous les besoins (illusoire) ou **évoluer** à partir de pièces utiles. Décisions à expliciter : cognitive load à réduire, courbe d'apprentissage (cliff, hockey stick, gear shift).

Concept canonique #1 — ***floating platforms vs sinking platforms*** : quand la *base platform* (cloud) gagne des capacités, soit on garde notre plateforme identique (sinking, on duplique, on coule), soit on **jette les morceaux devenus redondants et on remonte plus haut innover** (floating). Métaphore : *submarine and a boat*. Condition contractuelle clé : prévenir explicitement les stakeholders qu'on jettera des choses.

Concept canonique #2 — ***fruit salad vs fruit basket*** : la plateforme n'est pas une collection juxtaposée mais un assemblage proportionné où les pièces interagissent. *« Per-kilo price for fruit salad is higher than for fruit basket. »*

Conclusion : architecture = série de décisions non-triviales ; les expliciter, c'est ça la *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 (Leanpub) (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→ composants absorbés par base platform (CONCEPT, 0.97)
- Sinking platform —converge_avec→ capacités de base platform qui montent (CONCEPT, 0.96)
- Floating platform —utilise→ communication explicite stakeholders (CONCEPT, 0.95)
- Fruit salad —surpasse→ 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/fr/fiches/hohpe-platformcon-magic-of-platforms-floating-platforms-2022-06/