That crucial point, buried in Yegge's 4,800-word rant: Google (just like most retail chains) has built a company on top of a collection of applications. Amazon (where Yegge worked for six years) has built its enormous E-Commerce success because it is not just a bundle of retail applications. It's a platform that lets customers interact, outside retailers sell and other third parties connect. But Amazon didn't start that way. And how it made the transition should have retail chains thinking hard about whether that's the right approach for them, too.
That's not to suggest that ex-Amazoner (and, so far, not yet ex-Googler) Yegge had nice things to say about the place he worked for six years. "Amazon does everything wrong," he wrote. "But there's one thing they do really, really well that pretty much makes up for ALL of their political, philosophical and technical screw-ups."
According to Yegge, the difference came sometime around 2002, when Amazon CEO Jeff Bezos issued a mandate that, going forward, all development teams would "expose their data and functionality through service interfaces." And that "there will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no backdoors whatsoever." And all those interfaces "must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions."
And one more thing: "Anyone who doesn't do this will be fired."
That's a platform. (Well, all except the part about nonconformists being fired—that's called "strong executive support for the platform approach.") In practice, it means that all of Amazon's applications had to be able to communicate with each other through standard interfaces. And all those standard interfaces had to be stable and secure enough that, if necessary, outsiders could connect and communicate in the same way.
Almost a decade later, it's obvious that the platform mandate has been very good for Amazon's business as a retailer. The ability to let other retailers use Amazon's API meant it was much easier for Amazon to offer itself as an online store for other retailers, including Target, which has discovered just how hard it is to replicate that type of platform's power and stability.
However, a big retail chain isn't Amazon (or Google or Facebook). Every big retailer has marketing applications, customer-loyalty applications, and E-Commerce and M-Commerce applications. But conventional retailers don't need to unify all their applications and expose their APIs so that lots of other retailers can use their stores (online and brick-and-mortar) to do business. That's Amazon's model. Then again, it's not the only way to use a platform.
What applications would it make sense to platform-ize in a retail chain? Definitely not some of them.What applications would it make sense to platform-ize in a retail chain? Definitely not your applications for handling payment cards—the less connections there, the better. Probably not loyalty-program applications, either, unless you're planning to give outsiders access to all that hard-won CRM data. An API to expose inventory levels and prices to the world in a highly accessible way? That's something your competitors would love, but it's exactly what you don't want to be doing.
In fact, almost everything that made sense for Amazon to turn into a platform—and thus expose to the outside world of customers and third-party retailers—makes zero sense for a retail chain to do.
On the other hand, consider one of the nastiest problems most chains face: dueling inventory systems, one for E-Commerce and at least one for in-store inventory. At most chains, those two inventory systems aren't integrated. They're barely on speaking terms, and they communicate through exactly the things that Amazon outlawed in 2002: special backdoors, direct links from one application into another and single-purpose reads of inventory data.
That's when there is a connection other than an associate jumping between a local-inventory screen and the Web site to tell a customer whether the item she's looking for is in the store, in another local store or is available online.
Now that's a candidate for a platform. Or at least it's a candidate for platform thinking.
What you want is for associates to be able to query all of the chain's inventory. And for the E-Commerce inventory to be available to stores and in-store inventory to be available to ship to E-Commerce customers. And for excess inventory to be under good enough control that you'll never have to sell any item at clearance that some customer anywhere in the world is willing to pay full price for.
You want an inventory platform. Not a single chain-wide application that replaces all your current inventory applications—that type of monolithic, single-point-of-failure application is an invitation to disaster—but a unified way for applications to query all your inventories, so new merged-channel inventory tricks don't require one-off connections and risk destabilizing the whole system.
That's why chains should be thinking hard about the platform question. Unfortunately, thinking is all that most chains will do. There's a reason it took Nordstrom years to create an enterprise-wide view of inventory, and why JCPenney is still working on the same problem. It's pretty much the same reason that it took a CEO's mandate to force platform thinking company-wide at Amazon.
Platforms are hard to do, they're expensive, and they're difficult to justify, because there's no single thing you can do with a platform that you can't do cheaper and easier by stringing a connection between one application and another.
That means it's not just IT that needs to be thinking about platforms. Without strong executive support for a platform approach, that's never going to happen, no matter how much sense it makes for a retailer.
And if Google's executives have that much trouble grasping the platform concept, as a retail CIO, you've got your work cut out for you.