Thursday, October 20, 2011

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.

2 comments:

Ed Shaz said...

Going back to Yegge for a minute, I thought his post was an honest and crucial stepping stone for Google.
Apparently, many Google employees, and others tied to Mountain View, thought so too.

Sadly, morale was again kicked in the nuts by a dismissive, snarky,
Sergey Brin.

gkc said...

Hi Isaac,

When you say "You need to design this stuff in from the very beginning" ... I disagree. I'm not sure you meant it because later on you say "design ... with a platform mindset" which is (to my mind) quite different.

I don't know of many platforms which were created, from day one, as platforms. Platforms tend to emerge from successful products. Any of the things I've ever done that approached platform-ness started out as specific solutions to specific problems which after various rounds of a-ha! moments eventually evolved into platform-like things which supported the original solutions but also an entire class of solutions to similar problems.

If you start by trying to create a platform, you will likely fail. On the other hand, if in the course of building your product and iterating it into what customers actually want, thus making it wildly successful - if in the course of doing that you are "designing with a platform mindset", then you have a fighting chance of making the next evolutionary leap - extracting and then abstracting the platform from the product.

Did Google start by designing a platform? I don't think so. Amazon? Twitter? It may well have been in the back of people's minds at those companies, but I am willing to bet that the products came first and the platforms after.

@gkc