Distilled : Steve Yegge’s platform rant
I came across this now legendary rant by Steve Yegge 5–6 years ago. While it was amusing and interesting then, I have now been trying to convert Myntra’s supply chain technology to a platform for over the last year and a half and have found it really relevant when thinking about what a platform is, what it means to build one, and how would you know if you succeeded in building one.
I have revisited the article over and over again over the last few months. What consistently amazes me about it is that it couples deep technical and organizational insight with damn good writing. It is a long post, and I love reading it, but I finally decided to extract the parts which most appealed to me in it. One reason for this is to crystallize my own understanding of it, and another is to freeze my understanding of it as of this point. I guess it might be interesting later on revisit this and see how much things have changed.
The follow are what I believe to be the key parts of the article.
- SOA-driven design enables Platforms.
- “All teams will henceforth expose their data and functionality through service interfaces” — this unlocks capabilities for re-use. This is the beginning of a platform.
- “All service interfaces, without exception, must be designed from the ground up to be externalizable.” — This truly unleashes the platform built under the previous dictat by implicitly mandating all softer aspects of an externally used service (rate limiting, identity, security, documentation, uptime etc). Organizing into services taught teams at Amazon not to trust each other in most of the same ways they’re not supposed to trust external developers.
- The big realization Bezos had was that he can’t always build the right thing, that he can’t build one product and have it be right for everyone.
- Bezos realized that he couldnt provide everyone with the right “products” : interfaces and workflows that they liked and felt at ease with.
- A platform-less product will always be replaced by an equivalent platform-ized product.
- Conversely, a platform needs a killer app. Facebook — that is, the stock service they offer with walls and friends and such — is the killer app for the Facebook Platform.
- Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone.
- The Golden Rule of platforms is that you “Eat Your Own Dog food”.
- The Golden Rule of Platforms can be rephrased as “Start with a Platform, and Then Use it for Everything.” You can’t have secret back doors for internal apps to get special priority access, not for ANY reason.
- A platform is an “externally programmable” system.
The first 3 points are talking about the technical aspects of building a platform.
Points 4–8 talk about how platforms fit in the business context. These are the things a business should try to evaluate when thinking of how to build. Should you build a platform? How would it aid the business in the way that it plans to grow? Is it worth the extra technical overhead that probably would not be there if you built a more tightly knit “product”?
Points 9–11 talk about the organizational thought-process for building platforms and for me, they are really, REALLY, the heart of the matter. Even as Steve’s post suggests, Google isn’t bad at platforms because they dont have the technical capacity (obviously) or business need. They are bad at it because the organization does not think about platforms as independent things on which mutiple products could be built. Teams are focussed on delivering value via products, which are then mostly not re-usable in the business context and have to be re-invented again and again as the business changes to try and do different things.
Point#11 is the litmus test of a platform — can others use the offered capabilites efficiently, without jumping through 20 hoops to build meaningful products and deliver business value. If it cannot be used “programmatically” by complete “outsiders”, it is not a platform.