Platform Strategy

What it’s about

Gregor Hohpe, author of Enterprise Integration Patterns and The Software Architect Elevator, writes about why so many internal platforms disappoint and what a platform strategy actually involves. It’s less about technology choices and more about decisions: what to standardise, who the platform serves, and how to avoid building something nobody needs. I’m partway through.

What I learned

Think in platforms, and know your customer. The platform’s customer is the internal team building products. That sounds obvious until you notice how many platforms are designed around the platform team’s preferences instead.

Paved roads beat toolkits, but a golden path must not become a cage. Handing teams a box of tools leaves every team to assemble the same thing. A paved road gives them a working default. But if the road is the only option, people route around it, so it should be the most attractive choice rather than a mandate.

Use domain-driven design to decide what a platform should own. Generic subdomains (things every company needs) are usually best bought. Core domains (where the business competes) belong to product teams. Platforms earn their keep in supporting domains: important and shared, but not differentiating. I wrote this up as Where Platforms Fit: DDD Subdomains.

A platform’s job is to reduce cognitive load. If teams have to understand everything underneath, the platform hasn’t done its job.

What I applied

The book gave me words for something I’d done before reading it. At Sky I led the UI of a low-code workflow platform, and the part that worked best was a set of templates and reusable building blocks that gave people a working, well-structured workflow on day one (Building a Low-Code BPMN Workflow Platform). That was supporting-domain work: shared and valuable, but not what any one product competed on. It was also a paved road, not a mandate.

Now I ask “which domain is this?” before proposing anything shared. If it’s generic, I look for something to buy. If it’s core, I leave it with the product team.

Finishing it

I finished it in October 2026, and the second half gave me some of the ideas I now use most:

• Platforms as translators between what developers declare and what the cloud provides, kept true by an observe → analyse → act loop (Cloud Platform Translators).
• Kent Beck’s explore, expand, extract, and my conclusion that exploring with users matters most (Explore, Expand, Extract).
• Why platforms built in one shot fail, and how to grow one: breadth against depth, an upward spiral, a public roadmap, designing for people who join late, and letting users shift gear (Growing a Platform: Breadth, Depth and Gear Shifting).
• A sharper view of low-code tools (Low-Code Platforms: Where Do They Belong?) and of metrics (Goodhart’s Law).

The thing I enjoyed most was how much room it left for my own ideas. Reading it is where using calisthenics as a metaphor for engineering really clicked for me. It works for me, and it may work for others: sometimes a new metaphor connects something that was hard to grasp before. That’s the thinking behind the Lab and the metaphor notes on this site.

Where it connects

Where Platforms Fit: DDD Subdomains · Golden Paths · Internal Developer Platform · Golden Paths and the Recommended Routine · Thinking in Platforms · Domain-Driven Platform Engineering