Platform Strategy: When Standardization Speeds You Up

Ask most developers what they think of enterprise standards and you’ll get a sigh. Standards are the forms you fill out, the approved list you have to pick from, and the review board that meets once a month. In most organizations, standardization feels like the opposite of innovation.

Gregor Hohpe’s Platform Strategy: Innovation Through Harmonization argues that it doesn’t have to be that way. Done right, a platform can standardize and speed teams up at the same time. Hohpe calls this the platform paradox, and the book is about how to get it right.

It’s the follow-up to The Software Architect Elevator, and like that book, it’s practical, full of memorable metaphors, and grounded in real experience. (The print edition credits Michele Danieli and Jean-François Landreau as co-authors.) It covers what platforms are, how to set a strategy for them, how to design and build them, and how to organize teams around them.

Here are Clif’s notes.

The platform paradox

Traditional IT standardization works by restricting. You may use these three databases and no others. You must file a ticket to get a server. The standard reduces variety, and it slows people down in exchange for control.

A real platform standardizes by enabling. One of Hohpe’s examples is HTTP. It’s a strict standard, and because everyone follows it, millions of people have built things on top of it that its creators never imagined. The standard didn’t limit innovation. It made innovation possible.

That’s the paradox. When a platform takes care of the common, undifferentiated work, it frees teams to spend their effort where it matters. Harmonize the foundations, and you get more innovation on top, not less.

Most “platforms” aren’t platforms

One of the most useful parts of the book is a contrast between platforms and traditional IT services. Roughly:

Traditional IT service	Platform
Request it with a ticket	Use it yourself, on demand
Built for control	Built to enable
Usage is mandated	Adoption is earned
Resists change to stay stable	Evolves continuously
Becomes a bottleneck as it scales	Gets better as it scales

Run your own “platform” through that table. If it has a ticket queue, a mandate, and a backlog of unhappy users, it’s probably an IT service with a new name.

Fruit basket or fruit salad?

Hohpe’s most memorable image is the difference between a fruit basket and a fruit salad. A fruit basket is a bundle of separate things: here’s a source repository, a CI tool, a wiki, and a Kubernetes cluster. Good luck. A fruit salad is something new made from those ingredients, with the work of combining them already done.

Lots of organizations call a fruit basket a platform. They’ve bundled tools together, but every team still has to figure out how to wire them up. That’s not a platform. That’s a shopping list.

Simplify concepts, not parameters

This is the idea I think architects most need to hear. When teams try to “reduce cognitive load,” they often just hide settings. Default ten of the twenty parameters and call it simpler.

Hohpe points out that this frequently makes things harder. Behind each parameter is a concept. Hide half the concepts, and users are left trying to understand a system with missing pieces, like doing a jigsaw puzzle with half the pieces removed. Real simplification means building a better abstraction: a new, smaller set of concepts that actually makes sense in your domain. And the abstraction has to be honest. A platform that pretends networks never fail isn’t simple. It’s an illusion, and illusions eventually break.

This connects directly to Simple Isn’t Easy. Hiding complexity is easy. Removing it is simple, and much harder.

Platforms need a product mindset

Because adoption is earned rather than mandated, platform teams have to think like product companies. They need to know their users, prioritize ruthlessly, make trade-offs, and even market what they’ve built. A platform is an indirect value creator: it only produces value when other teams use it to build something.

That’s a different skill set from running infrastructure, and the book is candid that many organizations underestimate how high the bar is.

My favorite line in the book is a test you can apply to any platform:

If your users haven’t built something that surprised you, you probably didn’t build a platform.

Don’t build a pyramid

Hohpe also warns against the “pyramid” approach to business platforms: a grand design where common functionality sits at the bottom and every business unit’s needs are neatly anticipated above it. It assumes you can predict what everyone will need, and you can’t. As he put it in an interview about the book, we stopped building pyramids thousands of years ago for good reasons. Platforms should grow from real usage, not from a master plan.

Why this matters for battling complexity

I’ve argued that every organization has a complexity budget, and that you should standardize the boring parts so you can spend that budget where it counts. Platform Strategy is the best guide I’ve found to doing that well.

It’s also a warning. A badly built platform is one of the biggest sources of enterprise complexity there is: one more system everyone depends on, that nobody likes, and that can’t change. It’s the “one system to rule them all” I warned about in my vendor warning signs post, built in-house.

The difference between those two outcomes is the thinking in this book.

Who should read it

Platform and infrastructure teams, especially anyone building an internal developer platform.
Enterprise architects deciding what to standardize, and how.
IT leaders funding platform initiatives who want to know what success looks like before they spend the money.

You can get it as an ebook on Leanpub or in print. Read The Software Architect Elevator first if you haven’t. Then read this one before you build your next platform.