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

## Veille

Keynote by **Gregor Hohpe** (Enterprise Strategist at AWS, author of *The Software Architect Elevator* and of the forthcoming book *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) at **PlatformCon 2022** on **the magic of platforms** — why platforms succeed, what distinguishes them from plain *IT Service Management*, and **the non-trivial architecture decisions** to make when building one. **Pivot thesis**: *"standards don't reduce creativity, they can multiply it"* — analogous to Baltimore 1904 (fire, incompatible pumps), the ISO metric screw, HTTP, A4 paper. **Canonical quote borrowed from Peter / Thoughtworks**: ***"platforms centralize expertise but not innovation"*** — the wheel isn't reinvented, but innovation is left to the teams closest to the customer. **Pivot analogy**: the automotive industry (Volkswagen Group builds the Audi A4 and the Bentley Bentayga on the same platform), *"undifferentiated heavy lifting"* (AWS vocabulary) under the hood, differentiation visible on the customer side. **Three properties of a true platform**: (1) **low friction** — adoption can't be forced, teams will work around it; (2) **transparency** (not a *black box*) — users must be able to diagnose whether the fault lies with them or with the platform; (3) **shared responsibility** (direct reference to the *AWS Shared Responsibility Model*) — the platform does not fix a poorly designed application. **Explicit anti-pattern**: *"a common layer can be many things — it is not necessarily a platform"*; traditional IT Service Management has the same image (a common layer underneath everyone) but the **interface is the opposite** (high-friction, forms, bottleneck). **Two construction paths**: (a) anticipating every need (Hohpe: *"I don't feel I'm smart enough"*); (b) **evolution** from useful pieces, observing usage. **Decisions to make explicit**: objectives (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), shape of the learning curve (cliff, hockey stick, gear shift). **Canonical concept #1 — Floating platforms vs Sinking platforms**: when the *base platform* (typically the cloud) gains new capabilities, **two opposing strategies**: **sinking platform** (static, duplicating what the base now offers, sinking as the water level rises) vs ***floating platform*** (discards the pieces that have become redundant, **rises above the new level**, innovates further up). *"Submarine and a boat"* metaphor. Strong contractual implication: **explicitly warn stakeholders** that components will be removed once the base absorbs them. **Canonical concept #2 — Fruit salad vs Fruit basket**: a platform is not a collection of juxtaposed capabilities (a basket) but a **proportioned, bite-sized** assembly where the pieces interact — *"the per-kilo price for fruit salad is higher than for a fruit basket"*. The title derives from the phrase *the magic of platforms* — the counter-intuitive effect where **standardizing frees up innovation instead of stifling it**, provided the interface, the evolution, and the integration between components are handled with care. Relevant for: platform architects, **Platform Engineering / IDP teams 2026** (a foundational reference, predating the *Internal Developer Platforms* boom but structuring its vocabulary), CIOs assessing build-vs-stagnate against native cloud capabilities, product executive committees. Converges with **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 as a systemic pillar).

## Titre Article

The Magic of Platforms

## Date

2022-06

## URL

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

## Keywords

Software platforms, platform engineering, Internal Developer Platforms IDP, Gregor Hohpe, AWS Enterprise Strategist, The Software Architect Elevator, Platform Strategy, PlatformCon 2022, undifferentiated heavy lifting, standards boost 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, platform transparency not 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

**Profile**: Experienced keynote speaker addressing platform architects, Platform Engineering leaders, CTO/VP Engineering, internal platform team leaders. Format ~15 minutes, **educational and analytical** register, **measured, demonstrative, analogy-driven** tone. Target audience: organizations building or considering building an internal platform.

**Style**: Hohpe's voice — clear English, structured as **historical analogy → counter-intuition → architecture rule**. Spiral narrative structure: starts with the naive image (common layer + building blocks on top) → introduces doubt *"there's a lot more behind it"* → deconstructs with examples → reconstructs with a decision framework. **Non-jargon** but precise vocabulary: *undifferentiated heavy lifting* (borrowed from Bezos / AWS), *low friction*, *shared responsibility*, *floating / sinking platforms*. No overloaded slides, **one visual metaphor per concept** (fire truck, metric screw, boat / submarine, basket vs fruit salad).

**Key aphorisms**:
- *"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"* (quote from 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)

**Elaborated metaphors**:
- ***Undifferentiated heavy lifting*** (automotive) — engine, transmission, ABS, braking, emissions control = invisible to the customer, done once, shared across brands (Audi A4 → Bentley Bentayga on the same VW Group platform).
- ***Fire hose coupling*** (Baltimore 1904) — the absence of a standard burned down a city; the standard multiplied firefighters' capacity for mutual aid.
- ***Submarine and boat*** — sinking platform = submarine (sinks), floating platform = boat (rises with the tide).
- ***Fruit salad vs fruit basket*** — the value lies in the **proportioned integration** of the pieces, not their juxtaposition.

**Epistemic stance**: prescriptive but **not militant**. Hohpe does not say *"here is the one right design"*, he says *"here are the decisions you must make explicit and their consequences"*. Strength of the content: (a) **historical depth** (the automotive industry solved this problem decades ago — platforms are not new), (b) **conceptual precision** (the sinking / floating pairing is a durable thinking tool), (c) **honesty** (*"I don't feel I'm smart enough to anticipate everybody's needs"*).

**Authority**: built from (a) the role of **Enterprise Strategist AWS** (a 360° view of enterprise cloud architectures), (b) Hohpe's **editorial brand** (*Enterprise Integration Patterns* has been canonical for 20 years), (c) the **Architect Elevator series** (a common language for senior architects), (d) the **visual simplicity** of the analogies (one diagram = one idea).

## Pense-betes

- **Date / source**: **PlatformCon 2022** keynote (June 2022), YouTube recording *The Magic of Platforms* (~15 min), hub page *platformengineering.org/talks-library/the-magic-of-platforms*.
- **Speaker**: Gregor Hohpe, Enterprise Strategist AWS, author of *Software Architect Elevator* + forthcoming book *Platform Strategy* (Leanpub).
- **Audience**: platform architects, Platform Engineering teams, CTO/VP Engineering. ### Pivot thesis > ***"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 examples) | Example | Date | Lesson | |---------|------|--------| | **Baltimore fire** | 1904 | Firefighters from neighboring towns couldn't connect their hoses to the hydrants → the *Baltimore* standard since | | **ISO metric screw** | among the first ISO standards | Any screw conforming to the standard fits any conforming thread | | **HTTP** | 1991+ | Any browser can connect to any web server — a massive innovation booster | | **A4 paper** | (reference) | 297 × 210 mm = 1/16 m² — *"nobody's creativity is impeded"*, on the contrary, fewer arguments about envelope or drawer size | ### Automotive analogy (core of the talk)
- The auto industry solves *"the undifferentiated heavy lifting"* (engine, transmission, ABS, emissions control, emissions standards) **once**.
- Puts different *"hats"* on top for different segments.
- **VW Group builds the Audi A4 and the Bentley Bentayga on the same platform** (MQB isn't named but is the referent).
- The customer sees the color, the interior, the sound of the doors — not the differential. ### Peter / Thoughtworks quote (canonical) > ***"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."*** ### Three properties of a *true* platform 1. **Low friction** — *"you cannot force anyone to get on your platform; if you try, they will find other ways"*. 2. **Transparent (not a black box)** — users must be able to diagnose: *"is it me, or is it the platform?"*. 3. **Shared responsibility** — AWS analogy: *"if you build a horribly insecure brittle non-scaling monolithic application, the platform itself cannot fix that for you"*. ### Explicit anti-pattern: IT Service Management disguised as a platform
- Identical image (common layer + building blocks) but **reverse interface**: high-friction, forms, bottleneck, adding a customer is costly.
- *"Don't be fooled by the picture of the common layer — a common layer can be many things. It is not necessarily a platform."* ### Two construction paths | Path | Description | Hohpe | |------|-------------|-------| | (a) **Anticipate** every need | *"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."* | Ironic tone, probably unrealistic | | (b) **Evolve** | *"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."* | Recommended path — Hohpe: *"I don't feel I'm smart enough to anticipate everybody's needs"* | ### Architectural decisions to make explicit (the *"dials"*) **Objectives pursued**:
- Reduce **cognitive load** / **learning curve**
- **Safer**: *"less likely to make mistakes"* — by *"hiding corner cases or complexities"*
- **Faster**: samples, blueprints, better self-service
- **Productivity** / **collaboration** / **compliance** / **minimizing mistakes** **Mechanisms**: which levers you use to achieve what. ### Learning curve shapes | Shape | Description | |-------|-------------| | **Cliff** | *"Even if you want to do hello world it takes a certain amount of effort"* — high initial | | **Linear (ideal)** | Rare in practice | | **Hockey stick** | Bake in assumptions → the initial experience is easy, but once the assumptions no longer hold, *"life becomes disproportionately harder"* | | **Gear shift** | Less bad than hockey stick: switching services within the platform, but *"in between there's a gear shift, they need to learn new things"* | ### CANONICAL CONCEPT — Floating platforms vs Sinking platforms **Context**: *"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"* (the cloud / AWS being the typical example). **The base platform grows too**. Major strategic decision: what do you do with your platform when the base absorbs certain capabilities? | Strategy | Description | Metaphor | Hohpe's verdict | |-----------|-------------|-----------|---------------| | **Sinking platform** | You **keep your platform unchanged** because you've invested in it. The base rises. Your platform now **duplicates** things the base natively offers. *"As the water level rises"*, your platform **sinks** (becomes a maintenance burden, slows innovation). | Sinking submarine | *"Might be justified from investment, but really you're sort of duplicating things that are now in the base platform"* — a de facto anti-pattern. | | ***Floating platform*** | When the base gains the capabilities you had 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"*. **You discard what's become redundant, you rise higher**, you build new things. | Boat floating on the tide | Recommended path — but with an explicit **contractual condition**. | **Contractual condition (key)**: > ***"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 for design / governance**:
- **Interface abstraction**: the platform must expose its capabilities via a stable interface — otherwise, *"throwing things away"* breaks consumers.
- **Explicit lifecycle**: mark components *"deprecate when base provides this"* from birth.
- **Active monitoring of the base platform**: the *roadmap* of the base's vendor (AWS, GCP, Azure, Kubernetes, etc.) **is** the subject you must steer by.
- **Stakeholder communication**: warn before removal, otherwise it's perceived as a breach.
- **Innovation measure**: the value of a floating platform is measured by **what it builds *in addition***, not by what it retains. **Risk of the sinking platform**: sunk cost fallacy at scale — *"we've already invested 3 years in this module, we're keeping it"* even though the base now offers it as cheaper, better-maintained managed SaaS. **Risk of the floating platform**: instability on the consumer side if communication is insufficient. **The moral and technical contract with users is the cornerstone**. ### CANONICAL CONCEPT — Fruit salad vs fruit basket **Context**: the talk's final decision — *"how do the parts of your platform interact?"*. | Model | Description | Market value | |--------|-------------|------------------| | **Fruit basket** | Fairly self-contained, juxtaposed pieces. *"That is good but that's not the full strength of the platform."* | Price per kilo of 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"*** — the value emerges from the **proportioned assembly**. | **Architectural implication**: the platform must **enable new use cases** through composition (a *picnic* with fruit salad is easier than hauling around a basket). For Platform Engineering: think in terms of **cross-cutting usage flows** (cross-service), not just a catalog of independent services. ### Tech-watch dossier articulation #### Convergence "platform engineering = capability orchestration, not a catalog"
- **Hohpe** (2022-06): fruit salad > fruit basket, low friction + transparency + shared responsibility.
- **AI/works™ Thoughtworks** (2026-05-12): six capabilities covering the full SDLC, Control Plane *"cost transparency + active guardrails + end-to-end lineage"* — Hohpe's transparency industrialized.
- **L'Usine Logicielle Augmentée Wescale** (2026-05-03): six production lines, human Bon à Tirer (sign-off), Strategic Judge + Agent Manager — a production-line version of Hohpe's platform.
- **PROJ-AI Habert / WEnvision** (2026-05-05): six zones, doctrine, Decision Records, *"80% discipline, 20% techno"* — a doctrine-vocabulary that complements Hohpe.
- → **Convergence**: **proportioned assembly** (fruit salad) remains the 2026 criterion. #### 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 emerges **after** the investment.
- **Bain Rule of 40** (2026-04): *Invest to Grow* > *Financialize* — the platform is won through iteration.
- → **Convergence**: the platform **matures through observed usage**, not omniscient planning. #### Convergence "floating platforms = capability harvesting from the base"
- **Hohpe** (2022-06): floating platform = discard what the base absorbs.
- **Cherny Sequoia** (2026-05): *"the harness becomes less important as the model improves"* — **the AI harness is a floating platform** on top of the model; whatever the model absorbs (planning, sub-agents, prompt injection defense), the harness loses.
- **Osmani Agent Harness Engineering** (2026-04-19): *ratchet principle*, model capabilities replace scaffolding.
- **Stripe Minions Part 2** (2026-02-19): Toolshed ~500 MCP tools = floating platform on the model, continuous updates.
- → **Convergence**: Hohpe's *floating platform* pattern **anticipates by 4 years** the *harness engineering* doctrine — the base (model) grows, the harness (platform) rises above it, discarding what has become native. #### Convergence "shared responsibility model"
- **Hohpe** (2022-06): *"platform cannot fix horribly insecure brittle non-scaling monolithic applications"*.
- **AWS Shared Responsibility Model** (implicit reference by Hohpe, Enterprise Strategist AWS).
- **DORA AI ROI** (2026-04-21): *Trust, Platform, Data, Users, Guardrails* — 5 systemic keys, of which *Users* and *Guardrails* materialize shared responsibility.
- **Uber Engineering Agent Identity** (2026-05-21): *"the secure path is also the easiest path for developers to implement A2A calls"* — shared responsibility translated into agentic security doctrine. #### Productive tension with traditional IT Service Management
- **Hohpe**: *"a common layer can be many things — it is not necessarily a platform"*, distinguishing *IT Service Management* (bottleneck, forms) from *platform* (enabler).
- **Geudin / CIO Online** (2026-01-26): *"software and cloud predators of IT budgets"* — *"platform"* SaaS becomes predatory absent FinOps discipline and transparent usage.
- → **Reading**: without Hohpe's 3 properties (low friction, transparency, shared responsibility), a *"platform"* drifts into *budgetary predation*. ### Relevant for
- **Platform architects / Platform Engineering leads**: a foundational reference — the **floating / sinking** pairing as a strategic steering tool relative to base roadmaps (cloud providers, Kubernetes, LLM models).
- **CTO / VP Engineering**: the grid of 3 properties (low friction, transparency, shared responsibility) as a **quick diagnostic**: *"is my 'platform' really a platform or a disguised IT Service Management?"*.
- **CIOs / IT procurement departments**: the *fruit salad vs fruit basket* criterion for evaluating vendor-proposed *"platforms"* (real value composition vs juxtaposition of separately billed modules).
- **Product executive committee**: the *"floating vs sinking"* decision to formalize on any platform initiative — which components will be discarded once the base absorbs them? warn stakeholders.
- **Platform Engineering 2026 (IDP / Backstage / port.io / Humanitec)**: the Hohpe talk provides the **founding vocabulary** underlying the whole IDP discipline — *cognitive load reduction*, *self-service*, *blueprints*, *golden paths* derive from this framework.
- **Agentic AI platforms (harness engineering)**: applying **floating platform** to the harness — every model release (Opus 4 → 4.5 → 4.6 → 4.7) should trigger an audit: *"what do we discard?"*.

## RésuméDe400mots

**Gregor Hohpe**, Enterprise Strategist at Amazon Web Services and author of *The Software Architect Elevator*, delivered a fifteen-minute educational keynote at **PlatformCon 2022** in June 2022: *The Magic of Platforms*. His pivot thesis reverses the common intuition: ***"standards don't reduce creativity — they can multiply it"***. Three historical examples support it: the 1904 Baltimore fire (neighboring pumps couldn't connect for lack of a coupling standard), the ISO metric screw, and HTTP — massive innovation boosters. A4 paper closes the demonstration: its standardization never curbed creativity — on the contrary, it avoided arguments over envelope size.

The talk's core analogy is **the automotive industry**: Volkswagen Group builds the Audi A4 and the Bentley Bentayga on the same platform. The *"undifferentiated heavy lifting"* (AWS vocabulary) — engine, transmission, ABS, emissions standards — is done once; the visible differentiation stays on the customer side. Hohpe cites Peter from Thoughtworks: ***"platforms centralize expertise, but not innovation"*** — that stays with the teams closest to the customer.

Hohpe identifies three properties of a true platform: (1) **low friction** — adoption cannot be forced; (2) **transparency** — the user must be able to diagnose; (3) **shared responsibility** — the platform doesn't save a poorly designed app. Anti-pattern: *"a common layer is not necessarily a platform"* — traditional IT Service Management has the same image but the reverse interface (bottleneck, forms).

Two construction paths: anticipating every need (illusory) or **evolving** from useful pieces. Decisions to make explicit: cognitive load to reduce, learning curve (cliff, hockey stick, gear shift).

Canonical concept #1 — ***floating platforms vs sinking platforms***: when the *base platform* (cloud) gains capabilities, either the platform stays identical (sinking, duplicating, sinking), or **the pieces that have become redundant are discarded and the platform rises higher to innovate** (floating). Metaphor: *submarine and a boat*. Key contractual condition: explicitly warn stakeholders that things will be discarded.

Canonical concept #2 — ***fruit salad vs fruit basket***: the platform is not a juxtaposed collection but a proportioned assembly where the pieces interact. *"Per-kilo price for fruit salad is higher than for fruit basket."*

Conclusion: architecture = a series of non-trivial decisions; making them explicit is the *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/en/fiches/hohpe-platformcon-magic-of-platforms-floating-platforms-2022-06/