Thoughts on Platforms

I'm a big fan of Steve Yegge. I think that his recent platforms rant is, once you look past the haha-Google-doesn't-get-it and haha-Google-employee-bashes-Google+-on-Google+, a contemporary classic essay on platforms and technology strategy. Articulate, entertaining, irreverent and really insightful—like Steve himself, I'm told.

A friend of mine sent round an email recently asking for thoughts on it. What was Yegge trying to say? Here's what I think: he was trying to say a number of things.

1. A key business/product truism: "a platform-less product will always be replaced by an equivalent platformized product". If your product isn't a platform then prepare to be disrupted by someone who builds a platform and a competing product on top. Platforms enable unimagined/uncontemplated user needs to be met. Ultimately, platforms win.
2. You can't just build a product, slap an API on top and call it done. That's not a platform and it's probably not even a good API. You need to design this stuff in from the very beginning.
3. Once you've decided that you're going to build platforms (rather than adding an API as an afterthought), the way to get good at exposing platforms externally is to live them internally.
4. To live platforms internally they need to pervade your organization, all your thinking and your internal architecture. It can't be just "hey we have an RPC interface". How is that service registered and discovered programmatically? How are quota and rate limits managed? Pluggable authentication? Front-to-back end-to-end tracing? How is it regression-tested as it evolves? Can anyone in the company just pick up the docs for the service and start calling it? Is there an SLA? How is capacity planned and provisioned? Talking of docs, do you have reference manuals and tutorials, code samples, lists of error messages and so on? Who gets paged if it goes down as a result of a supporting service going down? You don't have a platform unless you have a consistent, uniform approach to all these horizontals supporting a vertical API.
5. If you design your internal systems with a platform mindset then every day you're dogfooding your own platform efforts. It'll be easier to expose a rich and thorough platform to your customers and users, and the quality of the platform you expose will be higher.

The part of Yegge's story about Bezos reminded me of my own similar experience. In 1997 I started work at an investment bank in London. The CIO there had just decided that from now on every app developed internally should be delivered in a browser. If you don't build web-enabled apps then you're out. He had mugs and t-shirts made with slogans such as "web or dead" and "wired or fired". He gave them out to employees. I think I still have my web or dead one.

But this seemed like insanity at the time. Internet Explorer 3 was the default browser. The investment bank I'd just come from didn't even have internet access, or browsers, on their desktops. There were many people at the bank who thought that this web app idea was the most stupid idea ever, particularly those who only knew COBOL. Or had spent years building thick clients in Visual C++ or VBA.

I was impressionable, though, kept my head down and became good at building web apps.

And! Once the bank had developed web-based trading apps and web-based finance apps and web-based legal apps and web-based book-building apps for internal use... waddyaknow we could make these same apps available directly to our customers in their browsers. This was utterly revolutionary—and gave us an enormous market advantage, literally years ahead of our competitors.

It couldn't have happened without everyone internally living, breathing, and being hired and fired around, this internal mandate for browser-based apps. The skills we built and lessons we learned while solving for our internal apps were all directly applicable to the turning inside-out of these same apps.

I think that's similar in spirit to Yegge's point. You'll get good at externalizing platforms by internalizing them.