Understanding Modularity: How Apple, Bloomberg, and Amazon Kept Strategic Coherency
Clay Christensen, Ben Thompson, the iPhone, A&P, Bloomberg Terminals, Prime Air and AWS.
There is a podcast of this memo available if you prefer listening to it. You can find it on our podcast feed here (Apple, Spotify).
Clay Christensen is known for his brilliant theories on Disruptive Innovation and the “Jobs to Be Done” framework, but he also gained minor infamy for predicting the demise of Apple multiple times. His prediction hinged on the idea of modularity. Later, another brilliant analyst, Ben Thompson, would start to articulate what the theory was missing. We will add to that conversation, first by using different business examples to showcase the theory and then later by returning to Apple.
Explaining Modularity.
At the core of a lot of business success and failure is the concept of modularity. It is a word that is often used synonymously with commoditization. Though, more precisely modularity is when a business activity becomes standardized and independent from other activities within in the business. Essentially, modularity dictates what activities a business should do internally versus outsource1.
For example, if you are opening a local grocery store, you will not build your own credit system nor manually measure and package each item you sell, but simply work with outside vendors who do both. However, if you opened a supermarket at the beginning of the 20th century, you would have regularly extended credit to your customers and have had to individually measure and package each item you sold. This is because there was no standardized credit system nor a standardized way to purchase most food. As most industries mature, there is a tendency for it to become modular and as a result activities that were previously in-housed are outsourced. The supermarket doesn’t extend credit, various credit card companies and banks do. The supermarket doesn’t measure and package each item in its store, the food vendors do.
Embracing Modularity.
The financial data service firm Bloomberg originally assembled their own computers for clients. This is because when they launched their service in 1982, PCs were uncommon, and most companies didn’t have the knowhow to purchase them nor operate them (the first Mac wouldn’t be introduced until 1984). However, as PCs gained prominence, Bloomberg exited the computer assembly business. In essence, the PC became “modularized”, and Bloomberg no longer needed to in-house this function to support their core business of providing financial data.
With the idea of modularity comes standardization, which allows different elements of a business to easily “interface”2 with other elements. Bloomberg could treat the computer the same way as any start-up can today, that is as an element of the business, that despite being of high importance, could reliably be outsourced.
Now just because something can be outsourced, doesn’t mean it should be. The decision to outsource or not is contingent on whether there is an overriding benefit in terms of any preference the end customer values (whether that be cost, experience, or something else is dictated by what the customer values).
Now for a counter example, we show when something shouldn’t be modularized.
Building Off of Modularity.
When Amazon was founded, they used already existing payment options, an already existing internet, and already existing logistics providers. All of the most expensive infrastructure aspects to build Amazon were already in place and modularized. Anyone could adopt a card processor, create a website on the internet, or pay a 3rd party logistics provider to ship a package. The modularization of these elements were key to allowing Amazon to operate without having to burn through billions in capex before they shipped their first book. (In fact, Jeff Bezos is so grateful for this that part of his impetus of creating Blue Origin is to carry the cost of creating “space infrastructure” for others to build off of).
Amazon, though, didn’t just rely on 3rd party logistics providers indefinitely. They eventually built their own logistics network, spending over $100bn in capex in the process. Why they would do this is simple: there was an overriding benefit in terms of improved shipping times, increased capacity, and presumably lower costs. Logistics was a modular function only if Amazon was okay with average delivery speed and architecting their warehouse footprint to the shipper, but as fast delivery was becoming core to Amazon’s value prop, they needed to in-house this function in order to improve it. In a counterfactual world where same day shipping already existed, Amazon would never have built this infrastructure. Supporting this is the fact that Shopify briefly flirted with the idea of building their own logistics network before simply partnering with Amazon.
Amazon is not the exception though. Alibaba and Mercado Libre were born in markets where not only was fast and reliable logistics absent, so was secure and easy electronic payment. Thus, Alibaba would create Cainiao and Alipay, and Mercado Libre would create Mercado Envios and Mercado Pago. In-housing3 these functions created a clear benefit for Alibaba and Mercado Libre and so they both took on the expensive and complicated task of building payments and logistics infrastructure. Their aims of creating online retail platforms that facilitated the sale of goods electronically necessitated it.
In contrast, since the payment industry was more developed in the U.S., there was no benefit for in-housing this function at Amazon. The Amazon Pay initiative would come a full 13 years after Amazon was founded and never gained much off-site (or on-site) usage. This contrasts with Mercado Pago and Alipay, who launched just 4 and 5 years after their respective ecommerce sites were founded and both became important facilitators of payments on-site and off-site.
Partitioning Internal Functions to Modularity.
Amazon again provides further education on modularizing business activity with Amazon Web Services, or AWS. From a 2016 TechCrunch article:
It began way back in the 2000 timeframe when the company wanted to launch an e-commerce service called Merchant.com to help third-party merchants like Target or Marks & Spencer build online shopping sites on top of Amazon’s e-commerce engine. It turned out to be a lot harder than they thought to build an external development platform, because, like many startups, when it launched in 1994, it didn’t really plan well for future requirements. Instead of an organized development environment, they had unknowingly created a jumbled mess. That made it a huge challenge to separate the various services to make a centralized development platform that would be useful for third parties.
At that point, the company took its first step toward building the AWS business by untangling that mess into a set of well-documented APIs. While it drove the smoother development of Merchant.com, it also served the internal developer audience well, too, and it set the stage for a much more organized and disciplined way of developing tools internally going forward.
Instead of simply keeping this new internet infrastructure business for “Merchant.com” and “Amazon.com”, they effectively modularized themselves by standardizing the interface, making it independent of other internal business activities, and offering it externally.4
It makes sense that in 2002, when the seeds of AWS were in their infancy, Bezos wrote his decisive “API Mandate” Memo. He was thinking about what business activities within their organization should be standardized and independent from each other. While the original version is not available, the gist is reported as follows:
All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
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 back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
All service interfaces, without exception, 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.
The API (application program interface) is the perfect example for the point: every application needs to have a literal interface that is standardized, externalizable, and is the exclusive point of communication. We can think of the the API example as a general metaphor for modularization. Amazon would essentially modularize their in-house web services to make it a stand-alone business. The AWS that “retailer” Amazon.com uses is no different than the AWS offered publicly.
Importantly, AWS wasn’t kept to just support Amazon’s retail operations because there would have been no benefit to keeping it in-house. AWS is not a business activity that could provide the retailer a lasting and notable benefit and so modularizing that function didn’t hamper their retail business. Interestingly, Amazon is doing a similar thing again, this time with their logistics infrastructure. At this point there is less of a benefit to keeping the logistics platform exclusive to the Amazon retail platform as the initial aim of 1 day delivery has been largely achieved and consumers who care about quick delivery are all already Amazon customers5. Thus, they have begun modularizing this business and offering it externally.
In short, when a business function no longer serves much benefit to the organization and there are alternatives, it often does not make sense to keep it in-house. Amazon (and Bezos) has proven to be a master of not just knowing when to in-house business activity, but also when to modularize it.
Consumer Preferences Matter.
Clay Christensen would get Apple wrong by applying his disruption framework theory to the company. Ben Thompson summarizes the argument well below:
Briefly, an integrated approach wins at the beginning of a new market, because it produces a superior product that customers are willing to pay for. However, as a product category matures, even modular products become “good enough” – customers may know that the integrated product has superior features or specs, but they aren’t willing to pay more, and thus the low-priced providers, who build a product from parts with prices ground down by competition, come to own the market. Christensen was sure this would happen with the iPod, and he – and his many adherents – are sure it will happen to the iPhone.
In other words, it’s not enough to say the iPhone has saturated the high end market and that growth will slow; rather, the iPhone will soon overshoot customers completely, and will in fact plummet in total sales in the face of good-enough Androids available for hundreds of dollars less than the overpriced iPhone 5C.
While it is true that Androids are “good enough” on many vectors versus iPhones, what was missed was simple: consumer’s preference more than cost and performance attributes. As we outline in our Consumer’s Hierarchy of Preferences piece:
The Consumer’s Hierarchy of Preferences is the idea that consumers have an internal “weighting” of desires, and once a desire is filled to a certain degree, addressing their next order desire becomes more important.
Apple consumers value much more than the cost and performance of the phone—they care about the look and feel of it. They value of everything “just working” in an intuitive manner and also the cultural cachet Apple products hold. This is much easier to do when a company is fully integrated, controlling the hardware and software. In our opinion, what Christensen missed was that this integration was providing a benefit in terms of a preference the end customer valued. Beyond a point, cost reductions are no longer a primary concern of the consumer and other fulfilling other preferences takes precedence6.
There is another important lesson to draw from this though: integration wasn’t just core to Apple’s ethos, it was totally in-line with their business model. Making the software and device together enabled each to work together better, which was a key component of Apple’s value prop. We point this out because Apple was not incentivized to modularize their business because much more would be lost than gained. For example, licensing their iOS separately to OEMs or working with Microsoft’s Zune Marketplace to enable song transfers to the iPod would have both made the business worse off by eroding their competitive advantages and creating an offering that did not meet many consumer preferences.
In short, just because something can be modularized, doesn’t mean it should be. If Apple had modularized their iOS mobile operating system it would have no doubt created a new stream of cash flow for the company, but they also would have lost the ability to deeply integrate their operating system with their hardware. To quote Ben Thompson again:
Modularization incurs costs in the design and experience of using products that cannot be overcome, yet cannot be measured. Business buyers – and the analysts who study them – simply ignore them, but consumers don’t.
Again, that decision, on whether or not a company should keep a business activity in-house is contingent on whether there is an overriding benefit in terms of any preference the end customer values.
Closing Thoughts.
In the Bloomberg example, it made sense for the company to outsource a business activity that became modularized. With Amazon Logistics we saw how a company may opt for a unique in-house solution versus a “good enough” modularized one, and with AWS we saw a company modularize their own in-house solution and turn it into a stand-alone business. In all of these cases these businesses made decisions that were both in-line with 1) their financials and 2) a value prop that resonated with their customers. Apple modularizing aspects of their business may have been a good (short-term) financial decision, but it was not consistent with offering a product that resonated with their customers.
Understanding when a business activity becomes modularized and what sort of opportunity that represents is key for managers to navigate shifting competitive landscapes.
We will be releasing a new memo every Friday morning. Subscribe below to receive it!
Just because an activity can be treated modularly by a business, does not mean that that module is a commodity business. Word processors can be thought of as modular since no company is going to make their own in-house word processor, however Microsoft Word is not a commodity business, despite other businesses being able to treat it as a modular component.
An interface is how two elements of a business interact with each other, whether that be two internal elements or an internal and external element.
Alibaba’s Logistics Platform Cainiao was more a partnership with various 3PL services, but they still initially controlled it and ended up directly investing in several of the partners.
While it’s not common, offering a service externally may not be necessary to be considered “modularization”. However, once a service is standardized and made independent, it seldom makes sense to not also offer it externally. Imagine if Microsoft developed Word just to use it internally or if eBay bought PayPal to then make the platform exclusive to on-site payments.
Unlike with AWS, modularizing logistics may cause their retail offering to lose some differentiation. This is presumably outweighed by the gains they can make by extending their logistics platform to merchants who are not currently on FBA (Fulfillment by Amazon).
This is what Ben Thompson alludes to in the same article when he notes that Christensen’s examples of disruption were primarily geared to B2B markets, where the buyers cared most about specs and cost.
Well written!
Excellent