Gregor Hohpe: Floating vs Sinking Platform Strategy

Key takeaways

1. 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.
2. Speaker. Gregor Hohpe, Enterprise Strategist AWS, author of Software Architect Elevator + forthcoming book Platform Strategy (Leanpub).
3. 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)
4. The auto industry solves "the undifferentiated heavy lifting" (engine, transmission, ABS, emissions control, emissions standards) once.
5. Puts different "hats" on top for different segments.
6. VW Group builds the Audi A4 and the Bentley Bentayga on the same platform. (MQB isn't named but is the referent).
7. 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
8. Identical image (common layer + building blocks) but reverse interface: high-friction, forms, bottleneck, adding a customer is costly.
9. "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:
10. Reduce cognitive load / learning curve
11. Safer. "less likely to make mistakes" — by "hiding corner cases or complexities"
12. Faster. samples, blueprints, better self-service
13. 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:
14. Interface abstraction. the platform must expose its capabilities via a stable interface — otherwise, "throwing things away" breaks consumers.
15. Explicit lifecycle. mark components "deprecate when base provides this" from birth.
16. 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.
17. Stakeholder communication. warn before removal, otherwise it's perceived as a breach.
18. 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"
19. Hohpe. (2022-06): fruit salad > fruit basket, low friction + transparency + shared responsibility.
20. 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.
21. 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.
22. PROJ-AI Habert / WEnvision. (2026-05-05): six zones, doctrine, Decision Records, "80% discipline, 20% techno" — a doctrine-vocabulary that complements Hohpe.
23. → Convergence: proportioned assembly (fruit salad) remains the 2026 criterion. #### Convergence "evolutionary platform > anticipative platform"
24. Hohpe. (2022-06): "I don't feel I'm smart enough to anticipate everybody's needs".
25. DORA AI ROI. (2026-04-21): J-Curve, "learning curve + verification tax + pipeline adaptation", ROI emerges after the investment.
26. Bain Rule of 40. (2026-04): Invest to Grow > Financialize — the platform is won through iteration.
27. → Convergence: the platform matures through observed usage, not omniscient planning. #### Convergence "floating platforms = capability harvesting from the base"
28. Hohpe. (2022-06): floating platform = discard what the base absorbs.
29. 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.
30. Osmani Agent Harness Engineering. (2026-04-19): ratchet principle, model capabilities replace scaffolding.
31. Stripe Minions Part 2. (2026-02-19): Toolshed ~500 MCP tools = floating platform on the model, continuous updates.
32. → 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"
33. Hohpe. (2022-06): "platform cannot fix horribly insecure brittle non-scaling monolithic applications".
34. AWS Shared Responsibility Model. (implicit reference by Hohpe, Enterprise Strategist AWS).
35. DORA AI ROI. (2026-04-21): Trust, Platform, Data, Users, Guardrails — 5 systemic keys, of which Users and Guardrails materialize shared responsibility.
36. 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
37. Hohpe. "a common layer can be many things — it is not necessarily a platform", distinguishing IT Service Management (bottleneck, forms) from platform (enabler).
38. Geudin / CIO Online. (2026-01-26): "software and cloud predators of IT budgets" — "platform" SaaS becomes predatory absent FinOps discipline and transparent usage.
39. → Reading: without Hohpe's 3 properties (low friction, transparency, shared responsibility), a "platform" drifts into budgetary predation. ### Relevant for
40. 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).
41. 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?".
42. 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).
43. 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.
44. 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.
45. 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?".