Data & AI team structure: Case studies
Data & AI Team Structure - Case Studies - Team Topologies - Organizational Design - Xebia - Arjan van den Heuvel
Arjan van den Heuvel
root / tags / cognitive-load
3 Fiches
Data & AI Team Structure - Case Studies - Team Topologies - Organizational Design - Xebia - Arjan van den Heuvel
Arjan van den Heuvel
Neither Manager Nor Contributor - Nicolas Martignole - Career Paths - AI Impact - Staff Engineer - Le Touilleur Express
Nicolas Martignole
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).
**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).