Platform Ecosystems: Aligning Architecture, Governance, and Strategy (2014)
Part IV. Orchestrating Evolution
Introduction
Chapter 10. Evolving a Platform
Abstract
This chapter explains how a platform owner can orchestrate the evolution of a platform. We begin by describing a bathtub model of innovation stocks and flows and then describe a litmus test for identifying which resources in a platform's ecosystem can give it a competitive advantage. We then describe how dynamic alignment of a platform's architecture and its governance accelerate its evolution. We trace the influence of that alignment and governance on the short, medium, and long term metrics of platform evolution. We first tackle how a platform owner can bolster a platform's resilience, scalability, and composability in the short term, followed by stickiness, synergy, and plasticity in the medium term. We conclude with a discussion of how a platform owner can orchestrate envelopment by a platform while rebuffing envelopment attacks on the platform, ensure a platform's durability, and orchestrate platform mutation in the long run.
Keywords
evolutionary speed; scalable platform; evolving platform boundary; Icarus Paradox stocks and flows; orchestration; business ecosystems
It is not the strongest or the most intelligent who will survive but those who can best manage change.
Charles Darwin
In This Chapter
• Parallels between platforms and evolutionary biology
• The “bathtub model” of innovation stocks and flows
• Creating and sustaining a competitive advantage: The litmus test
• Lessons on evolution speed from American military doctrine
• Aligning architecture and governance
• Ensuring platform resilience, scalability, and composability
• Growing platform stickiness with app developers and end-users
• Evolving the platform core and its boundary
• Growing platform synergy
• Orchestrating platform plasticity
• Orchestrating vertical and horizontal platform envelopment
• Orchestrating platform durability
• Orchestrating platform mutation
The central idea in evolutionary biology is that multiple species compete over scarce resources in a changing environment. Charles Darwin (Figure 10.1), the originator of this idea, suggested that the ones that survive are not the strongest or the cleverest but the ones that are most adaptive to their environment. Evolution is then simply the process of adaptation, rewarded by the survival of the fittest. This biological analogy is a powerful metaphor for understanding the evolution of platforms. Rival platforms are akin to competing species, competing for the same pool of adopters in a complex, turbulent environment.
FIGURE 10.1 Charles Darwin (1809–1882) originated contemporary ideas of evolutionary survival. Source: Hutton Webster, Modern European History, D.C. Heath & Co., Boston, 1920.
Like living organisms, platforms have the potential to adapt and evolve to sustain themselves over long periods. Thinking of a platform as a living entity then implies that its primary goal becomes survival. It will survive only if there is a symbiotic relationship—an implicit contract—between the platform owner and its app developers to help the latter reach higher in return for their support of the platform’s goals. It requires a mindset that is tolerant of new ideas, being fair, and focused primarily on longevity rather than profitability.
However, grasping the evolution of software platforms is challenging for most of us who were trained to think of software projects in terms of operational and implementation metrics such as efficiency, effectiveness, and quality. Thinking of platform evolution as software development is a counterproductive analogy for orchestrating ecosystems. A more productive analogy is the production of a daily newspaper, which must deliver a fresh edition every morning. Its structure, such as its major sections, does not change from day to day, but the content evolves. Stock tickers and economic indicators in the financials page change little, but their content is updated each morning. A platform’s ecosystem must similarly constantly balance change and stability as it evolves.
This chapter delves into how a platform owner can orchestrate the evolution of a platform. We begin by describing a “bathtub model” of innovation stocks and flows and then describe a litmus test for identifying which resources in a platform's ecosystem can give it a competitive advantage. We emphasize how the only source of sustainable advantage that a platform owner can count on is evolutionary speed. We then describe how dynamic alignment of a platform's architecture and its governance accelerate its evolution. We trace the influence of these two levers for orchestration on the short-, medium-, and long-term metrics of platform evolution, described in Chapter 7. We first tackle how a platform owner can bolster a platform's resilience, scalability, and composability in the short term, followed by stickiness, synergy, and plasticity in the medium term. We conclude with a discussion of how a platform owner can orchestrate envelopment by a platform while rebuffing envelopment attacks on the platform, ensure its durability, and orchestrate platform mutation in the long run.
10.1 The bathtub model: ecosystem innovation as stocks and flows
Complex systems such as platform ecosystems are partially designed and partially evolved (de Weck et al., 2011, p. 168). Evolution of a platform ecosystem can be envisioned as inflows and outflows of innovations, as illustrated in Figure 10.2. Think of this as the “bathtub theory” of platform evolution. Inflows are innovations that enter an ecosystem, contributed primarily by app developers and the platform owner, and to a lesser extent by end-users, upstream suppliers in the platform’s value chain, and ideas copied from rival platforms. Outflows are innovations that are copied by rival platforms. The net difference between inflows and outflows—what is left in the reservoir—are a platform ecosystem’s stocks of innovation that can potentially differentiate it from rival ecosystems. (The stock is the shaded portion in Figure 10.2.) These are features, functions, and assets that are unique to a platform’s ecosystem. Differentiation using the shaded part of Figure 10.2 is the essence of platform strategy and the key source of competitive advantage. In the long run, it is the shaded stock unique to a platform’s ecosystem that determines its long-term prosperity.
FIGURE 10.2 Innovation stocks and flows in the bathtub model of platform evolution.
The goal of effective ecosystem orchestration by a platform owner then is twofold: (1) growing the stock of innovations and (2) using these to competitively differentiate a platform from its rivals.
10.1.1 Growing the stock
Growing the stock of innovations unique to a platform ecosystem requires reducing the outflow and increasing the inflow. The outflow is a function of the intensity of rivalry among competitive platforms and the occasional protections using patents. In competitive platform markets, reducing the outflows is usually challenging. This is especially true when a platform establishes a dominant design, and its core features are so readily replicated that they become merely the cost of entry into its market but no longer serve as differentiators. For example, Android had a late start and lagged in its capabilities compared to iOS, which subsequently became the smartphone industry’s dominant design. However, it replicated almost all core features of iOS’s dominant design in about half a decade (from 2007 to 2013) and gained a billion end-users in the process by 2014. Once replicated, new innovations do not differentiate a platform from its rivals. They simply become a baseline expectation among potential adopters of a platform. This pattern repeats itself like clockwork in almost every era of technology innovation, beginning with Citibank’s introduction of ATM machines that differentiated it only during the 6 months it took its rivals to introduce theirs. If the speed of outflows through copying is high, inflows must be increased to keep the stock stable and substantially increased to grow it relative to rival platforms. Platform owners usually have a limited ability to reduce outflows, so must focus primarily on increasing inflows. A platform ecosystem’s capacity to nurture a stream of valuable new functionality can allow it to innovate faster than rivals can replicate it (Boudreau, 2010).
10.1.1.1 Architecture–governance alignment
Increasing innovation inflows into a platform’s ecosystem requires two things from a platform owner with respect to app developers.
1. Motivation. Creating the motivation to innovate around a platform is primarily done through governance that creates strong incentives for app developers. It also enriches the diversity of the pool of ideas for augmenting the native capabilities of a platform.
2. Ability. Creating the ability to innovate around a platform is primarily the role of platform architecture that makes it easier, cheaper, and faster for app developers to use a platform as a springboard for their own development work. A recent study of platforms from 1990 to 2004 found that opening up platforms to outside developers increased the rate of innovation by 500% (Boudreau, 2010). However, a rich pool of diverse ideas dispersed across the ecosystem will not add up to much without a capacity—platform owners’ and app developers’—to act on them. For this, a platform’s ecosystem must be evolvable. Evolvability is a platform ecosystem’s capacity to rapidly adapt to unanticipated changes in its competitive environment (Baldwin and Woodard, 2009; de Weck et al., 2011). Evolvability is determined in large part by the choice of a platform’s architecture (de Weck et al., 2011, p. 141; Iansiti and Levien, 2004, p. 152). This is because the viability of various modular operators, described in Chapter 9, are directly enabled and constrained by its architecture. A platform’s architecture serves as its DNA—largely irreversible and enduring—that provides a blueprint for the evolutionary trajectories that a platform can and cannot pursue, the types of innovations that do and do not emerge around it, and the vibrancy of its ecosystem.
Motivation without ability is as worthless as ability without motivation. Therefore, platform governance must be aligned with platform architecture (Tiwana, 2008b; Tiwana and Konsynski, 2010). One must mutually reinforce the other so their joint effect exceeds their sum of parts. Architecture and governance are deeply interwoven and inseparably intertwined in shaping the evolutionary trajectory of platforms. Alignment allows their evolution to be propelled by the invisible hand of the market and orchestrated by architecture. This is why we described platform architecture and governance as the two gears of a platform’s evolutionary motor (see Figure 10.3). Such architecture–governance alignment is the predictor of a platform’s evolution, and the majority of this chapter describes how such alignment can be achieved. The two must interlock for the evolutionary motor to move forward; their mis-locking exacts evolutionary penalties. It is therefore platform evolution where platform architecture meets platform governance.
FIGURE 10.3 Architecture and governance—gears of a platform’s evolutionary motor—must interlock.
Governance and architecture can act as a system, mutually reinforcing each other. Neither alone is as effective as the two together. They have a two-way effect; both are affected by each other and affect each other. It is not only platform architecture that determines feasible governance strategies but also governance choices by platform owners that lead to architectures evolving along different trajectories over time. We therefore must think in terms of the codesign and coevolution of architectures and governance (Tiwana et al., 2010). The same architectures will lead to different types and levels of innovation under different governance structures. However, the consequences of different architectures on innovation within a platform’s ecosystem cannot be predicted without considering the motivations and incentives of app developers and the broader competitive environment within which a platform exists. Platform governance can therefore reinforce or weaken the benefits of platform architecture depending on whether they are aligned or misaligned. Their alignment encourages and also allows the ecosystem to absorb variety and experimentation in apps that augment the platform. (Architecture–governance alignment also shapes the evolution of apps, which is discussed in the next chapter.)
10.1.2 Creating and sustaining a competitive advantage
Merely growing the stock of innovation—what’s left in the bathtub in Figure 10.2—does not create a competitive advantage for a platform. A platform owner’s responsibility is for developing and sustaining a competitive advantage that differentiates a platform from rivals. Even if a platform begins with a clear competitive edge or technical superiority, it is only a matter of time that rivals will erode any such advantage if the payoffs are large enough. Put another way, beginning with a competitive advantage does not mean that it will be sustainable. Therefore, one must think in terms of sustainability of a temporary advantage rather than search for the Holy Grail of durable competitive advantage.
Platform owners must begin by abandoning the fantasy that there even exists such a thing as a durable competitive advantage. The idea belongs with the likes of the Tooth Fairy and the Abominable Snowman. (I will refrain from putting Santa Claus on this list.) Instead, any competitive advantage is temporary and fleeting. A platform must become adept at finding new sources of temporary advantage. Therefore, success in platform markets depends on maintaining a steady stream of innovation inflows into the ecosystem that is faster than the speed at which rivals can copy it. Evolution speed then becomes a source of competitive advantage.
10.1.2.1 The resource litmus test
To understand how competitive advantage is created and sustained, focus on an ecosystem’s stock of “resources” (i.e., what is left in the bathtub in Figure 10.2) at any point in time. A resource refers to tangible assets such as a platform’s capabilities, functionality, user base, complementing apps, and patents as well as its intangible resources such as brand recognition and reputation.1 Intangibles such as brands are messier to count on because once they define the dominant design for a platform’s market category, there are no guarantees that their value can be captured exclusively by the platform owner. Xerox copiers, Scotch tape, the IBM PC, and iPhone define their entire product categories to such a large extent that they have become generic labels used to describe their many clones. This is particularly true of software-based platforms.
Identify the key resources of a platform, focusing specifically on what the platform owner directly contributes to the platform’s ecosystem. To keep this list focused on the key resources, put it on one side of an index card. For each resource, use the resource litmus test below to identify whether it can competitively differentiate a platform from its rivals. The resource litmus test is based on an assessment of four properties of a resource (Table 10.1).
1. Valuable: Is it of value in the platform’s market and industry?
2. Rare: Do very few rival platforms have it?
3. Inimitable: Is it difficult (prohibitively costly or time-consuming) for a rival platform to imitate?
4. Nonsubstitutable: Can something else substitute for it?
Table 10.1
The Resource Litmus Test
The more of these properties a resource possesses, the more likely it can help competitively differentiate a platform from its rivals. A resource can help create a competitive advantage if it is valuable and rare. A resource can help sustain a competitive advantage if it is inimitable and nonsubstitutable. The mere possession of a resource does not give a platform a competitive edge; a platform owner must have the capability to widely exploit it as well. Alignment of a platform’s architecture with governance facilitates this.
As an illustration, Table 10.2 uses this resource litmus framework for a back-of-the-napkin comparison of one platform (iOS) with three rival platforms (Android, Blackberry, and Windows Mobile). The table succinctly helps recognize the competitive edge of individual rival platforms and therefore helps envision an actionable roadmap for evolving a platform. The list of resources in this example is merely illustrative and by no means comprehensive. A valuable resource must also be rare to create a temporary advantage for a platform (i.e., very few rival platforms should possess it). It must be inimitable and nonsubstitutable for it to sustain that edge. Therefore all four resource properties should have checkmarks in them for a resource to be an enduring source of differentiation. None of the resources in the quick-and-dirty analyses meet those criteria, suggesting that there is no durable source of competitive advantage in the market of these platforms. This is the norm for platform markets with Red Queen competition and the only source of advantage for any platform is evolving faster than rivals.
Table 10.2
An Illustration of the Application of the Resource Litmus Test
10.1.3 Evolution speed: lessons from the American military doctrine
If no temporary advantage is sustainable in the evolutionary Red Queen race, a platform must become adept at finding new sources—streams rather than events—of temporary advantage. Think of baby steps to create a steady flurry of temporary advantages. Evolution speed matters (Baldwin and Clark, 2000, p. 404); faster evolution increases the odds of gaining an unchallenged edge for at least as long as the time it takes rival platforms to replicate new innovations. In Red Queen-dominated platform markets, it is better to act quickly and iteratively than perfectly. In contrast, slower evolution leads to missed windows of opportunity.
Although business strategists often compare competition among rivals to a game of chess, viewing platform orchestration as playing a chess master is a counterproductive exercise. Multiple chess pieces don’t move simultaneously and they don’t have vested interests and their own mind. Insights into speeding evolution instead come from an unexpected source: the American military doctrine in the 1950s Korean War. John Boyd, an American Air Force colonel, is credited with introducing the idea of the OODA loop. The OODA acronym refers to the cycle of Observe → Orient → Decide → Act, as illustrated in Figure 10.4. The key idea in this military doctrine was the emphasis on executing faster OODA loops than an enemy plane, which is widely believed to be instrumental in many aerial combat dogfight victories. If this notion reminds you of the Red Queen phenomenon, it would be useful to translate John Boyd’s ideas into a platform setting to see its direct applicability.
1. Observation: collection of data from across the ecosystem
2. Orientation: analysis and synthesis of data to develop an evolving mental model of the platform or app in the context of its current competitive environment
3. Decision: deciding on a course of action based on the above
4. Action: the execution of that decision. The actions in modular platforms are typically one of five modular operators described in Chapter 9. Sometimes, when the environment changes in the midst of an OODA loop, it is necessary to cancel the action at the end of an OODA loop. In real options terms, this is exercising the abandonment option.
FIGURE 10.4 The military doctrine of OODA loops applied to platform ecosystems.
Boyd's premise was that faster OODA loops provide a momentary edge over rivals. Agility is more important than raw power in this perspective. The key to creating an edge over rivals is to shorten the lag between the four steps of the loop. This is identical to the premise of Red Queen competition where the goal is to adapt faster than rival platforms.
Rivalry within and among platform ecosystems is more akin to encounters between fighter planes. Arial dogfights have much more in common with platform markets than does chess: Brief air combats parallel shorter technology lifecycles in platform markets, unfamiliar terrains parallel emerging markets, unpredictable weather parallels a volatile environment, and actions with immediate consequences that might kill you before the next move parallels the surprisingly fast mortality of dominant platforms. Each OODA loop in platform markets can use as its input (observation) not only information about the consequences from the previous loop but also from rival actions, changes in the competitive environment, new technology advances outside the ecosystem, and insights into the dynamics of the platform’s market. Feedback delays in absorbing such new information can lead two similar systems to evolve very differently (Meadows, 2008, p. 2). The same signals are often available from the environment to all competing platforms; the difference in their evolution then results from variance in their ability to decode them and rapidly act on them, or the speed and numbers of concurrent OODA loops. All else being equal, the lesson from this military doctrine is that the platform that wins out in Red Queen competition is one that evolves faster than its rivals.
However, the Goldilocks rule applies to the speed with which feedback is incorporated in evolving a platform as well. While reducing lag in feedback loops mitigates decay in evolution speed, feedback that is absorbed too fast can create instability because of overreacting to inputs in subsequent OODA loops. There must therefore be a balance between inertia and momentum (Shy, 2001, p. 83). Too much of either can derail platform evolution.
The key to increasing innovation inflows into a platform’s ecosystem is then to (1) shorten the lag in one or more of the arrows in Figure 10.4 and (2) have many more of these OODA loops autonomously running in parallel. Aligning platform governance with architecture accomplishes the first task by placing app decisions with app developers and platform decisions with platform owners, while relying on platform architecture to decouple and reintegrate their work. Modularized platform architectures also reduceunnecessary coupling among feedback loops within an ecosystem by reducing the interdependencies between apps and the platform. Decentralizing the ecosystem’s governance accomplishes the second task by increasing the platform’s sensory points from few to many app developers, and giving each of them the power to act autonomously and without unnecessary lag. The alignment of platform architecture and ecosystem governance therefore addresses the Humpty Dumpty problem described in Chapter 2.
Three other ideas in Boyd’s theory are noteworthy in a platform market. We return to each of these later in the chapter.
1. Emphasis on what, not how. The emphasis in the OODA doctrine is on decentralized command that uses objective-based control rather than method-driven orders. This is identical to our earlier idea of platform governance where the minimal expectations for outputs from app developers are specified by a platform owner but they are given complete autonomy in how they develop their apps.
2. Continuous immersion in the platform market. Maintaining an accurate grasp of reality requires a continuous cycle of interaction with the environment. This idea is identical to our notion of the need to use emerging information from app developers’, rivals’, and platform owners’ own observations on the competitive environment, rivals, and outside innovations. This idea applies to both the platform in this chapter and to apps in the next chapter.
3. Fast and frequent—not perfect—actions. A lag in adapting to new information and updated forecasts can lead to instability in evolution, just as delay is a killer in dogfights. The key to survival in dogfights is the ability to adapt to change, not perfect adaptation. Speed trumps perfection. While one platform goes through one carefully thought-out loop, if a rival platform can go through a hundred much littler OODA loops, it will be much more likely to win out in evolutionary competition. This mirrors our subsequent emphasis on the need to simply adapt faster than rival platforms, even if it is imperfect and involves occasional missteps in between.
10.2 Orchestrating platform evolution: a preview
Table 10.3 previews and Figure 10.5 summarizes how the design of platform architecture, platform governance, and their alignment can be used by a platform owner as levers to orchestrate the evolution of a platform in the short, medium, and long term.
How Distributed Ownership Can Gridlock Innovation
In 1955, millions of American kids participated in a Klondike land rush. Quaker Oats Company, a cereal manufacturer, bought land in the Yukon Territory of Canada for $1000 and divided it into 21 million parcels of land, each a square inch in size. It then enclosed a mail-in form in boxes of its cereal products—Quaker Puffed Wheat, Quaker Puffed Rice, and Muffets Shredded Wheat—that buyers were asked to mail back to the company. The company in return sent back a deed to one square inch of land in the Klondike. This went on to become one of the most successful marketing campaigns in history. What do you do with a 1-inch piece of land? The land was technically unusable by any one because ownership was spread too thin (Heller, 2008). One kid tried to donate his 3-inch parcel to create the world’s smallest park. The land office of the Yukon currently has an 18-inch-thick file folder of correspondence regarding the promotion. Too much fragmented ownership can wreck markets and firms and dampen rather than boost innovation. The architecture of an ecosystem defines ownership of assets in a platform ecosystem but extracting the potential benefits of fragmented ownership requires aligning with ecosystem governance.
Table 10.3
A Summary of How Platform Design Drives its Evolution
FIGURE 10.5 A summary of the primary drivers of the nine metrics of platform evolution.
10.3 Orchestrating Short-Term platform evolution
10.3.1 Orchestrating platform resilience
The resilience of a platform is its capacity to function acceptably in the event of a failure elsewhere within or outside the ecosystem. In contrast, a platform that breaks many apps due to internal changes in it is brittle (Meadows, 2008, p. 76). A platform’s architecture and how well it is aligned with the control dimension of platform governance are the key drivers of its resilience. What makes a platform’s ecosystem work is not its parts in isolation but the platform’s interactions with apps. The key source of failure arises from the awry interactions of the platform with apps and external services that a platform uses. In complex systems, evolutionary changes in one subsystem can affect other subsystems. Complexity is a function of three things: the number of unique apps in the platform’s ecosystem, the density of connections between these apps and the platform, and the rate of change in the ecosystem as a whole. Such complexity begets more complexity over time. When a platform is connected to other systems such as apps and external services, they can jointly exhibit highly complex behavior due to their interdependence. Dependence of a platform on other systems leads to inflexibility as a small change in one place can have an unpredictable ripple effect cascade through the ecosystem. The larger the ecosystem, the greater such interdependencies (Evans et al., 2006, p. 49). Increasing a platform’s resilience requires (1) modularizing a platform’s interfaces, (2) deliberately introducing some redundancy in its internal design, and (3) increasing the degree to which the platform is internally monolithic.
Modularization of platform interfaces. The greatest complexities arise at the interfaces of the platform within its ecosystem. It is important to remember that platform-to-app boundaries are artificial conceptual simplifications. They are mental castles that serve merely as a conceptual crutch to assist with sense-making (Meadows, 2008, p. 95). Modularization of a platform’s interfaces creates a design optimized for flexibility and resilience rather than efficiency. It also reduces the amount of information about the internal functioning of the platform that any app has to keep track of—or even be aware of—because a platform’s interfaces govern the outputs of app developers. While modularization does not eliminate the connections between the platform and an app, the standardization of interfaces entailed by modularization creates an explicit shared understanding between an app developer and a platform owner of how the two must interact. Therefore, they shape expectations of both the platform owner and app developers (Evans and Schmalensee, 2007, p. 36). App developers can be assured that as long as they conform to the platform’s interface specifications, their apps will readily interoperate with the platform. Similarly, the platform owner has a well-documented implicit contract that as long as the interfaces of the platform remain untouched, changes within the platform will not undermine the functioning of existing apps. Furthermore, modularization decouples the implementation of the platform and individual apps in its ecosystem. This ensures that a maintenance change in the internal design of the platform does not require compensating changes in the apps that interoperate with it. Modularization of a platform’s interfaces therefore improves maintainability without compromising the platform’s capacity to evolve (de Weck et al., 2011, p. 80). This approach creates autonomy within apps and within the platform yet disciplines the interconnections among them. Modularization of a platform’s interfaces therefore improves the reliability and ease with which new functionality can be implemented within a platform, in turn making the entire ecosystem more resilient. This design approach allows the platform owner to incrementally tweak and refine the platform’s internal implementation as frequently as needed without inadvertently undercutting the apps in its ecosystem. In contrast, changes in a platform with undermodularized interfaces can lead to a propagation of errors from the platform to apps and vice versa (MacCormack et al., 2006), reducing a platform’s resilience. Similarly, poorly documented interfaces to the platform can make apps in the ecosystem fragile, with errors propagating from the platform to the rest of the ecosystem in unpredictable ways.
The second architectural technique to improve platform resilience, feasible only occasionally, is to create some degree of redundancy in external services that the platform’s own functioning might depend on. The simplest way to accomplish this is to use public, industry-standard interfaces to external services where possible; they permit swappability of such services (e.g., allowing 3G and WIFI to be used interchangeably for data transport). If the platform is unavoidably dependent on an app in the ecosystem to derive some of its critical functionality, it is useful to preserve some redundancy and swappability of such apps. This ensures that the loss of one critical app will not cripple the ecosystem. This runs counter to the idea of minimizing redundancy to maximize efficiency that is espoused in the design of traditional organizations and of traditional large-scale software systems. A third architectural technique also usable occasionally is to reduce the platform’s internal modularity. As long as internal implementation of the platform is under the platform owner’s control, this internal demodularization reduces the likelihood of internal failures for the same complexity vis-à-vis a more modularized internal architecture. The last two techniques can be combined over time, with the platform owner taking over the inhouse provisioning of external services on which the platform critically depends. Apple did precisely this by integrating cloud storage services into the iOS platform (as iCloud) that it once accessed externally (as iCloud).
Alignment with governance. Modularization of a platform’s interfaces relies on standardizing—explicitly documenting and adhering to simple rules for—the interfaces from the platform to the apps in a platform’s ecosystem. However, standards are like traffic lights on busy streets—they are only useful as a coordinating mechanism if everyone follows them. This is where the role of platform governance comes into the picture. However, governance is not an end in itself in improving platform resilience; rather, it is the alignment of governance with architecture that enhances platform resilience. Power over rules—or setting the rules of the game—is real power in complex systems (Meadows, 2008, p. 158). Such power should be wielded by a platform owner in extreme moderation (remember the Goldilocks principle). It is a delicate balancing act: Imposing too much control can stymie app developers’ freedom to be creative and imposing too little control can hurt the platform ecosystem’s resilience. The platform owner and app developers in self-organizing platform ecosystems must retain the freedom and autonomy to experiment in their own work.
The enforcement of interface specifications requires aligning the governance mechanisms discussed in Chapter 6—specifically the platform decision rights and control dimensions of governance—with its architecture. Modularization of the code used to implement the subsystems in the ecosystems must match the partitioning of responsibility for those subsystems (MacCormack et al., 2006). In this instance, modularization decouples the platform from apps. Such decoupling must also be mirrored in the ecosystem’s governance by partitioning of decisions between the platform owner and app developers.
The greater the modularization of the platform’s interfaces, the more valuable it is for the platform owner to centralize platform implementation decision rights but decentralize most app decision rights to app developers. This partitioning of decision rights creates a system of distributed control and autonomy between the platform owner and app developers. Furthermore, this partitioning of decision rights between a platform owner and app developers must also be complemented by a minimal set of simple, nonnegotiable rules. Greater use of gatekeeping and compliance-oriented metrics by a platform owner can help enforce platform interface standards among app developers. Aligning platform architecture modularization with governance provides cooperative advantage within the ecosystem, which can give it a competitive advantage against rival ecosystems where such alignment is poorer.
However, it is preferable that platform owners rely on peer-to-peer reinforcement—what we called relational control in Chapter 6—where possible. Relational control fosters self-organization by getting everyone in the platform’s ecosystem on the same page, and in turn improves its resilience. If the platform ecosystem is amenable to the use of relational control, it can be used as a less-expensive alternative to metrics-based control. Peer reinforcement provided by relational control can be far more effective than formal metrics, provided the app developers share the platform owner’s values and norms. Greater reliance on relational control, however, requires that app developers be able to self-monitor their own compliance with the platform’s interface standards. This can be accomplished by sharing freely compliance data for individual apps with app developers (e.g., data from testing and integration tools). This allows app developers to self-adjust their own development work, particularly when they appreciate that their own fate is intertwined with that of the platform.
Platform owners need not use other control mechanisms such as process control with the assumption that they need overt control over the implementation of apps. Therefore, modularization of the platform’s interfaces and alignment of governance with the platform’s architecture improves the platform’s resilience in the short term.
In summary, increasing platform resilience requires:
• A modularized platform architecture
• Alignment of governance with the platform’s architecture such that
• Platform implementation decision rights reside with the platform owner but apps decision rights reside with app developers
• Just enough control to ensure compliance with a platform’s interface standards by app developers
10.3.2 Orchestrating platform scalability
Platform scalability is the degree to which a platform’s functional performance and financial viability is size-agnostic. Platform scalability encompasses size agnosticism with respect to two facets: (1) upward and downward changes and (2) apps and end-users (the two sides of the platform). This means that the platform must be able to maintain its desired properties with an increase or decrease in the number of apps and end-users without a corresponding increase in its internal complexity. This is illustrated in Figure 10.6, where all four cells being covered represent a perfectly scalable platform.
FIGURE 10.6 Platform scalability.
Platform scalability is influenced by platform architecture and its alignment with the pricing dimension of governance. While attention to platform architecture improves its capacity to scale, aligning governance with its architecture reduces its need to scale.
10.3.2.1 Platform architecture and platform scalability
A platform can improve its scalability by (1) minimizing the need for unstructured communication between the platform and apps by standardizing platform interfaces and decoupling apps; (2) starting with a minimum viable footprint for the platform, rich in embedded real options; and (3) using tiered pricing and service-level agreements (SLAs) with apps.
Minimizing unstructured communication between the platform and apps is accomplished through the standardization and explicit documentation of the platform’s interfaces. This ensures that all interactions between a platform and apps in its ecosystem use an agreed-upon set of interface standards specified by the platform’s APIs. The emphasis is not on reducing the need for communication but rather the need for communication that is unstructured (i.e., not covered by the platform’s interface standards). A crude indicator of this is the chattiness of the platform’s core APIs. The chattier a platform’s APIs, the less likely it is that apps interoperating with a platform rely on communicating in ways that are not formalized in the APIs. This results in a more flexible platform design that is scalable both upward and downward. As a platform gains more apps, the stability of its latency and responsiveness for every thousand new apps is a simple way to evaluate its scalability. However, no matter how modular a platform’s architecture, architecture always imposes limits to growth. These limits can be relaxed by using a tiered architecture that is neither completely monolithic nor excessively modular, allowing only parts of the platform that need to grow in their capacity to be upgraded without having to grow the entire platform. This allows functions that exhibit high growth in usage by apps and end-users to independently be scaled up. For example, using a tiered architecture for a platform-wide notification system would allow a platform owner to increase the capacity of just the notification function without having to grow the other functions across the platform. Similarly, a platform owner should also encourage tiering of app microarchitectures by app developers. This approach also helps increase a platform’s scalability with respect to both apps and end-users.
The second approach to bolstering a platform’s scalability is to design the platform for a dream audience but provision for the expected load. Recall that the platform’s audience includes its two sides: apps and end-users. Ensuring downward scalability requires that the platform be financially viable even if the number of apps or end-users that adopt it turns out to be fewer than expected. A less downward scalable platform will shift to the negative net revenue region faster as the scale of the end-users or apps shrinks. The point at which the breakeven point occurs can be shifted through thoughtful design, giving a platform greater downward scalability. Platform designers must first grasp the implications of fixed costs and variable costs to build financial scalability into the design of a platform. Fixed costs should be decreased for a platform to have downward financial scalability. This requires starting a platform with a minimum viable footprint (which is often also rich in embedded real options), or what we described as the “must-do” elements of the platform in the discussion on real options thinking in Chapter 8. This ensures downward scalability by reducing fixed costs vis-à-vis variable costs per additional user (on either side). Fixed costs are the costs that a platform owner bears to keep the platform operating independent of the number of users. These are the baseline costs that would be incurred (e.g., initial development costs, services provisioning costs, operating expenses) even if the platform had zero users on either side. These fixed costs are spread over the number of users, which means that the fixed costs per user decline as the number of users grows. Variable costs are the additional costs that increase with an increase in the number of users (e.g., bandwidth costs, end-user support costs, or storage costs). The total costs incurred by the platform owner are fixed costs plus variable costs. The revenue generated by the platform owner depends on the number of platform users. These costs are illustrated in Figures 10.7 and 10.8. Reducing the initial footprint of the platform reduces the fixed costs by shifting the fixed cost line from line L to line S in Figure 10.7. By reducing the fixed costs, the platform owner lowers the minimum number of users or apps needed for the net revenue (difference between revenues and costs) to be positive. An alternative to growth through scaling that can also sometimes be viable is replication of a platform (making a copy of the system) for use in a different application domain (i.e., using the mutation operator).
FIGURE 10.7 Fixed costs plus variable costs are a platform owner’s total costs.
FIGURE 10.8 Both a platform's fixed costs and variable costs per user (or app) usually decline as their numbers increase.
10.3.2.2 Aligning architecture with governance to enhance platform scalability
A complementary way to improve a platform’s upward scalability is to align its governance—specifically the pricing dimension—with its architecture. This tackles the scalability challenge by reducing the need to scale, in contrast with the earlier approach that improves its ability to scale. Aligning governance requires promising service levels to apps in exchange for agreements on tiered quotas on how an app uses a platform. SLAs include error rates, latencies, and other operational performance metrics such as maximum downtime that a platform owner guarantees to app developers along with explicit documentation of remedies for outages, service interruptions, security breaches, and response latencies. These metrics are relatively easy to track due to the ubiquitously connected nature of contemporary software platforms. In exchange, a platform owner can impose quotas to limit API calls from individual apps to the platform or use a tiered pricing structure, particularly if a platform cannot absorb a level of traffic beyond a designed threshold. This naturally segments apps and app developers into segments or tiers with different quota levels. Twitter, for example, permits app developers to check their timelines between 150 and 350 times an hour, depending on the current state of the Twitter platform. The platform owner can often readily track the actual usage data to track the most popular and the least popular API calls to a platform. This creates a natural incentive for app developers to limit the demands that their apps place on the platform, reducing its need to scale. This allows a platform to grow, but in a controlled manner. It also helps maintain the delicate balance between the interests of app developers and the platform owner.
In summary, improving platform scalability requires:
• A modularized platform architecture that begins with a small initial footprint rich in embedded real options
• Using tiered pricing and quotas for the pricing dimension of platform governance
10.3.3 Orchestrating platform composability
Platform composability encompasses the ease with which changes can be made within a platform without breaking its interoperability with apps in its ecosystem. To be high in composability, changes within a platform should not impose integration costs on app developers.
It is important to recognize the ongoing, dynamic nature of systems integration in platform markets. Unlike traditional software systems, different subsystems in a platform ecosystem can evolve at different rates. A single change in the platform can require tweaks to apps to ensure their continued interoperability. Therefore a platform owner can encounter two types of platform-to-apps reintegration costs: (1) from changes that elaborate and extend the platform itself and (2) from new apps and changes to existing apps. Such reintegration costs can be unpredictable in their timing and cumulatively debilitating to a platform’s ecosystem. The imposition of such coordination costs can stunt a platform’s evolutionary potential and wipe out any benefits of intellectual division of labor across a platform ecosystem (Langlois and Garzarelli, 2008).
Platform composability is embedded in its architecture, particularly the modularization of its linkages to the rest of the ecosystem. Modularization decomposes an ecosystem into distinct apps and a platform that are subsequently composed. The decoupled apps rely on explicitly documented interfaces (such as APIs) to interoperate with the platform. A platform’s interfaces are therefore a contract between a platform and apps. Apps are built on top of that contract, which requires that an API and similar interfaces be stable, documented, and predictable. Compatibility with apps is achieved through interface standardization, defined as an explicit agreement to do certain things in a certain way (Farrell and Saloner, 1992). Following the platform’s interface specifications means that the platform owner describes exactly what functionality the platform will offer, how apps should access it, and the technical constraints on the apps’ interactions with the platform (e.g., how often an app is allowed to access an API or specific platform services per minute). This disciplines interactions of apps with a platform exclusively to its interfaces, which tell apps all they need to know to interact with and use the platform’s services. It also hides all internal implementation details about the platform from apps, which rely only on the documented protocols and APIs to communicate and interoperate with a platform. Platform modularization is therefore an important means for coordination of distributed work across a platform’s ecosystem, allowing apps to be developed independently by app developers but interoperate harmoniously with the platform (Arthur, 2009, p. 43; Messerschmitt and Szyperski, 2003, p. 173). Therefore, apps can be assured of composability with a modularized platform simply by complying with its interface specifications. This allows a platform to be changed internally as often as necessary provided its interfaces are left untouched.
Changing existing interfaces violates the premise of modularity. It is important to rigorously maintain separation between internal implementation and interfaces of a platform as it evolves (Kamel, 1987). In contrast, poor modularization messes up composability precisely when it is much more challenging to fix reintegration problems. Flaws in decomposition of functionality between the platform and apps, unrecognized dependencies, and ambiguity in interface specifications show up later only when the independently developed apps are brought together for integration with the platform.
Modularization, however, requires compliance with architectural rules by app developers and by the platform owner (Langlois and Garzarelli, 2008). Governance enforces compliance with architectural rules. As diverse expertise and resources accumulate among app developers in a platform’s ecosystem, it is standardization of a platform’s interfaces that allow this distributed constellation of capabilities to cost-effectively coalesce. Modularization of platform architecture must therefore be aligned with its governance, particularly its decision rights dimension. The more modularized the platform ecosystem, the more decentralized must decision rights be. Paradoxically, the more modularized and decentralized the architecture, the harder it becomes for a platform owner to control, provide direction, and maintain oversight over app developers. Therefore, decision rights decentralization must be granular and deliberate for each of the four types of decision rights in a platform ecosystem, described in Chapter 6.
Each ecosystem participant must be crystal clear about which decisions they are responsible for and how they affect the ecosystem. Both app developers and the platform owner must be clear on what implementation decisions they should and should not be making. Simple rules—not micromanagement—should guide app developers’ work. Clear accountability among app developers and the refrain from micromanagement by a platform owner therefore go hand in hand. This ensures that the technical boundaries of apps vis-à-vis the platform mirror the ecosystem-wide distribution of responsibility for them. Such mirroring-based alignment requires that the more a platform is modularized vis-à-vis its ecosystem, the more platform decision rights reside predominantly with the platform owner.
In platform markets, the platform owner must encourage diversity among apps and let the market determine winners and losers. But some control is still needed to ensure integrity and quality of app developers’ work. The control portfolio used by a platform owner should emphasize principles over rules and policies. The former liberate while the latter constrain app developers. App strategic and implementation decision rights should also reside largely with app developers, provided the platform’s interfaces are sufficiently modularized. This grants them freedom to work as they see fit, knowing in advance how they will be judged.
This match between architecture and governance allows changes to be made within a platform without requiring extensive coordination with app developers in its ecosystem. Such architecture–governance alignment mitigates the Goldilocks problem by giving a platform owner just enough centralized control to achieve integration across the ecosystem and enough autonomy to app developers to pursue their own ideas unfettered by a burdensome set of rules. Any need for extraneous coordination between them is a symptom of insufficient modularization of the platform’s interfaces. Linux and Mozilla’s Firefox are examples of platforms with strong architecture–governance alignment (MacCormack et al., 2006; Tiwana et al., 2010). These are also platforms where informal processes, a shared system of norms and values, and peer monitoring—all relational forms of control—are the predominant control mechanisms.
In summary, improving platform composability requires modularizing the platform’s interfaces and mirroring the allocation of decision rights for the platform and apps across the ecosystem.
10.4 Orchestrating Medium-Term platform evolution
10.4.1 Growing platform stickiness
Platform stickiness refers to the pattern of active use of a platform by end-users and app developers (its two sides). We care more about changes (increases or decreases) in active use over time. The prevalence of the Red Queen effect means that a platform has to deliver more value to keep its stickiness from declining and much more to increase stickiness over time. For a platform to grow stickier over time, both sides—the end-users and app developers—must progressively be better off as a platform ages. The fiercer the rivalry among platforms, the higher is this bar.
10.4.1.1 Growing platform stickiness with end-users
There are three approaches to increasing platform stickiness with end-users: (1) focusing on increasing app developer stickiness knowing that it is highly correlated with end-user stickiness, (2) creating value-driven, noncoercive switching costs to rival platforms, and (3) strategic incompatibility with rival platforms.
1. App developer stickiness correlates with end-user stickiness. The single most effective way to increase end-user platform stickiness is to remember that the same things that increase stickiness with app developers often increase stickiness with end-users. End-users value improvements in functionality and usefulness of a platform, which comes largely from app developer-driven innovations. Create strong incentives and make it easier for app developers to innovate in their own work and you create a virtuous cycle: More users attract more app developers to the platform, increasing the variety of apps available to end-users. This in turn attracts more end-users to a platform, creating a feedback loop that feeds on itself. This is illustrated in Figure 10.9.
However, platforms that grow solely reliant on external innovation stagnate and die. A platform owner must therefore not abdicate responsibility for bolstering a platform’s native functionality for app developers. Instead, app developers’ effort should be complemented by the platform owner’s own efforts at proactively retiring platform features that have run their course and steadily increasing the native capabilities of the platform in ways that end-users value. (Techniques used by app developers to recognize end-users’ latent needs, described in Chapter 11, can also be used by platform owners.)
2. Create end-user lock-in based on value rather than coercion. Lock-in means that an end-user incurs a switching cost associated not just with having to abandon her investment in a platform but from also having to abandon benefits that accumulate from having used a platform. Such costs can be coercive or noncoercive. Coercive lock-in (such as refusal to port data to a rival platform) is rarely sustainable and rival platforms can often devise ways around it. Noncoercive lock-in does not occur by force or binding contracts but by adding compelling value that cannot be replicated outside the ecosystem. The more effective and less breakable lock-ins are noncoercive ones created in three ways: nonportable network effects, personalization, and lowering end-users’ search costs.
(a) Nonportable network effects are specific to a platform and have little value in a rival platform. For example, Blackberry and iOS platforms provide functionality that is available only between users of the same platform. As a user accumulates a peer group of users on the same platform, the value of a platform comes to a large degree from the collaborative activities that an individual end-user can do with her peer network on that platform. For example, a messaging function (such as iMessage in iOS) that allows rich interactions between users of a platform but cannot function in the same way across rival platforms creates a value-adding lock-in. This has often shielded platforms facing intense rivalry and prolonged the useful life of withering platforms. For example, a Skype user with a hundred Skype contacts would find it difficult to convince her entire network to abandon the Skype platform and migrate to a competing platform that offers the same—or even superior—functionality. Similarly, Blackberry’s messenger service created strong network effects among Blackberry OS users, which kept them loyal to the platform even as it was fading from the marketplace. However, sustaining such network effects requires that they remain nonportable to rival platforms. Therefore, the design of a platform that emphasizes strong same-side network effects in its functionality is more likely to increase platform stickiness for end-users.
(b) Personalization is a second technique to increase a platform’s stickiness with end-users. This involves implementing ways to make the platform more useful the more an end-user uses it. Mobile OS platforms, for example, learn and adapt to user behaviors, preferences, and idiosyncrasies (such as learning typing patterns and commonly used words). Similarly, eBay, Amazon, and Netflix learn user interests and preferences and use correlation data to generate product recommendations that a user will increasingly find helpful. You cannot transfer Amazon’s product recommendations to a competing site, nor readily transfer Skype contacts to Google Voice to FaceTime; or Netflix’s deep and fine-grained knowledge of likely user interests to rival services like iTunes, Hulu, or Amazon Video. As a platform owner gains more knowledge of end-users’ preferences and behavior, it must creatively use it to make the platform even more useful and valuable to them. Such personalization creates a powerful incentive to stick with a platform because abandoning it in favor of a rival platform also requires abandoning the value that the platform is able to deliver to that end-user through learning effects. This does not eliminate the threat of platform abandonment, but simply raises the bar for how revolutionary a rival platform must be and how far it must leapfrog the incumbent platform to convince an end-user to jump ship. However, personalization is effective in increasing stickiness only if it is idiosyncratic to a platform (i.e., not portable to a rival platform) and if the end-user truly finds it valuable.
(c) Lowering end-users’ search costs is the third noncoercive technique for increasing platform stickiness. A platform owner must make it easier and lesser expensive for an end-user to find apps that would increase a platform’s functionality that she would perceive as being valuable in her own use of the platform. Increasing the variety and number of apps potentially increases the odds that an end-user can find apps that meet even the most eclectic and idiosyncratic needs at the tail end of long-tail markets. Paradoxically, this also makes it increasingly difficult to find an app in a larger pool. As a platform evolves, the platform owner must work to reduce search costs incurred by end-users in acquiring them. The goal should be to help end-users find apps more efficiently (Evans and Schmalensee, 2007, p. 33). This can be done by designing and then refining tools, methods, and capabilities for filtering, selecting, and aggregating information about apps (e.g., reviews) and app developers in ways that the end-users could not accomplish without the platform.
3. Strategic incompatibility with rival platforms is the third technique to increase platform stickiness for end-users. Platforms owners can choose to make a platform incompatible with a rival platform, one-way compatible (where the focal platform can interact with a rival platform but not the other way around), or compatible both ways (where a rival platform can interact with the focal platform as well) (Farrell and Saloner, 1985). How much should a platform allow its end-users to interact with users of rival platforms? Interoperability with rival platforms is a strategic choice, sometimes desirable and sometimes undesirable from the platform owner’s perspective. This choice should not remain static and can change as a platform progresses through different stages of its lifecycle. Incompatibility is more profitable when end-user needs and preferences are more heterogeneous and the threshold to trigger network effects is relatively low. Incompatibility makes it more difficult for rival platforms to dislodge a platform because a rival platform would not only have to deliver a better price/performance ratio but would also have to rally a critical mass of app developers and end-users around it. Platform owners must tread with caution in even pondering any move away from incompatibility. IBM, which literally created the PC business yet managed to let later copycats drive it out of the very business that it created, should serve as a poignant reminder of the risks of too much compatibility.
Breaking incompatibility barriers imposed by a rival platform is possible through the use of adaptors or middleware that translate or emulate data from one standard to another (Armstrong and Wright, 2007; Rysman, 2009). Although this permits interfacing with rival platforms, it is possible for a platform owner to block such adaptors from accessing the platform’s APIs. They are also usually not very scalable, costly to develop, and the overhead of the translation process often degrades performance and quality (Farrell and Saloner, 1992).
One-way compatibility is more profitable only when a platform owner faces a higher threshold for initiating network effects (i.e., needs a larger critical mass of end-users at the outset). This choice exploits network effects for a platform while denying them to rival platforms (Farrell and Saloner, 1985). Modularization of a platform’s interfaces—by preserving secrecy of a platforms’ internal implementation details—can make it more challenging for rivals to make their own platforms interoperable with it. The only condition under which two-way compatibility is likely to be profitable for all rival platforms is if and only if no platform has a clear technological edge (Rohfls, 2003, p. 197). This usually happens after the emergence of a dominant design, where competition is no longer among platform designs but within designs. Two-way interoperability is therefore likely to emerge when rival platforms are indistinguishably close in their features and when none of them perceives an opportunity to drive rivals out of the market by amassing a proprietary user base. This usually happens in the more mature phases of a platform market and signals a march toward commoditization and a race toward the bottom in terms of profit margins. Agreement on common standards and interlinking of rival platforms is widely seen in this phase. This should serve as a loud signal that the platform market is devolving into a zero-profit industry, as has happened repeatedly in consumer electronics industries including televisions, refrigerators, digital cameras, and personal computers. Surviving this lifecycle phase of a platform market’s evolution requires the platform owner to pay close attention to the three longer-term evolutionary metrics: platform envelopment, durability, and mutation.
FIGURE 10.9 The virtuous loop between end-user stickiness and app-developer stickiness.
Although platform stickiness with end-users is challenging to develop, it is easier to recognize and measure. End-user stickiness of a platform can readily be tracked as the increase or decrease in average hours per session or number of sessions per day per user over time.
10.4.1.2 Growing platform stickiness with app developers
A platform owner cannot just play orchestrator and expect to last very long. It must itself contribute something distinctive with sustaining value to the ecosystem. Stickiness of a platform vis-à-vis its apps is indicated by the direction of the change—increase or decrease—in the API calls made by an app on average as the platform ages. A platform with an increase in API calls per app generally indicates increasing platform stickiness. Recall the two key value propositions that platform must deliver to app developers: (1) the technical foundations to use as the starting point for their own work and (2) market access. Growing platform stickiness with app developers requires that a platform continue to deliver on these promises better than rival platforms. Therefore, a platform owner must focus on making it cheaper, easier, and faster for app developers to develop apps for the platform and grow the prospective pool of end-user app adopters that they can reach through the platform.
10.4.1.2.1 Cheaper, easier, and faster app development
The first mantra to increase app developers’ platform stickiness is to make app developers’ work around the platform cheaper, easier, and more productive. Recall that app developers value a platform for the technical foundations on which they can build their work. The premise was that this would save them the effort of duplicating functionality that does not differentiate their apps and spend the effort saved on developing functionality that better leverages their unique expertise and skills. A platform’s value to app developers therefore lies primarily in the scaffolding that it provides for apps to reach higher than they could without the platform. The closest parallel is the folks who made the most money during America’s Gold Rush: the ones who sold pots, pans, and digging implements to the gold prospectors. The app developers are the prospectors, and the platform owner must provide them tools that they value. App developers therefore value a platform for the reuse of designs and common functionality, sharing of resources, and productivity-enhancing tools. Therefore, expanding the platform’s native capabilities that apps can leverage requires growing the platform’s capabilities and making it easier for apps to leverage its existing capabilities. The platform must evolve gradually on the exterior, but it can evolve rapidly internally. This is only possible if its interfaces are modularized.
All else being equal, consumers are more likely to prefer—and even be willing to pay a premium for—a platform with a greater variety of apps over one with fewer. The higher the cost of development faced by app developers on a platform, the lower the variety of apps that will be produced for that platform. The primary customer of a platform is therefore app developers; delight them and the rest will naturally follow. Therefore, a platform owner must ensure that a variety of apps emerge and sustain on a platform. Without sufficient variety vis-à-vis competing platforms, fewer users will eventually adopt the platform, owing to the lower value they ascribe to it, and trigger a death spiral for the platform. Lowering developers’ costs is rarely a one-shot initiative because app developers also repeatedly incur such costs in updating and evolving their apps. This has a close connection to platform architecture: Platform architectures that enhance platform composability also enhance platform stickiness with app developers.
All else being equal, a platform that more consistently creates new opportunities for its app developers will outpace rival platforms in the value that it delivers to its end-users. A platform owner should therefore keep reducing developers’ app innovation costs and app-to-platform integration costs by enhancing the platform’s development environment. This encompasses the platform’s portfolio of app development tools, debugging tools, test automation and integration tools, best practice guidelines, reference app designs for new app developers to build on, and development processes (Boudreau, 2010; Williamson and De Meyer, 2012). The development environment provided by Apple to iOS app developers—the collection of technical specifications, manuals, and programming tools—is largely credited with the development of its highly successful ecosystem (Burrows, 2011). A platform owner can assess how well it is reducing app developers’ costs by tracking changes in app developer productivity over time. Is it faster and cheaper to develop an app for the platform than it was in the previous year? Has the platform made it easier for the app developers to exploit new technology developments and business opportunities in their own work?
Platform owners can identify opportunities to reduce app developers’ costs by keeping three things in mind: remembering the parallels to the evolution of cities, recognizing opportunities to move elements in and out of the platform core, and recognizing when to maintain and when to sacrifice backward compatibility.
10.4.1.2.2 Evolving the platform core
Recall the parallels between the evolution of cities and the evolution of platform ecosystems in Chapter 5. A platform provides the infrastructure on which apps operate, much like buildings in a city connect to shared city infrastructure (e.g., water, sewers, and electric grids). Much like a city’s infrastructure, a platform serves as a backbone for apps, providing consistency and order. As the residents of a city evolve, so do their needs. This requires a platform owner to retire legacy functionality, expansion with new interfaces and APIs, and recognizing once-unique services and functionality whose use is now widespread among many apps. Like a city with changing resident needs, a platform must also evolve to meet the changing needs of app developers and end-users.
As a platform ages and new generations of technologies emerge outside it, there can be a natural progression of what is feasible. A platform owner cannot sit still and hope that the external innovations will not be disruptive to the platform. A fledgling innovator will put those pieces together, just as Blackberry did after Palm grew too comfortable, and Apple did as Blackberry grew too comfortable. This requires the platform owner to proactively build on external innovations that can be added to the platform that would potentially be of shared value to many of the app developers. This role of evolving the platform itself cannot be left to outsiders, nor does it require consensus from the ecosystem.
Adding new APIs while retiring functionality that has run its course has the effect of shrinking the platform core and expanding the periphery (Figure 10.10).
FIGURE 10.10 Adding APIs and retiring functionality shrinks the platform core and expands its periphery over time.
10.4.1.2.3 Evolving the platform’s boundary
The platform owner’s choice of the platform boundary discussed in the earlier chapters—where the platform ends and its ecosystem begins—is important to remain mindful of as the ecosystem evolves. Boundaries in complex systems cannot remain static (de Weck et al., 2011, p. 99). The platform boundary itself must evolve over time using the simple heuristic described in Chapter 5: Highly reusable functionality used by a lot of apps goes into the platform itself; all else remains outside it (see Figure 10.11). Where change and variability are low, you want to create a stable, reliable, and robust foundation for apps to build on. As long as a platform continues to free app developers from the responsibility of provisioning the supporting infrastructure and building undifferentiating, redundant functionality, a platform is likely to remain valuable to them (Messerschmitt and Szyperski, 2003, p. 204). Therefore, the evolving platform must emphasize genericness with respect to the functionality that it provides to apps in its ecosystem. It is important that the platform continue to provide capabilities that are generic enough to be of value to a large pool of app developers, and that they evolve to support a wide variety of current and future applications. As a platform’s ecosystem evolves, widely shared services must be moved into it and those that are no longer used must be moved out of it.2
FIGURE 10.11 Two pathways for evolving the core of a platform over time.
Platform interfaces have long lifetimes and the burden of their legacy is often inescapable in systems evolution (de Weck et al., 2011, p. 140). This does not mean that an API can never change, just that the changes are in the internal implementation but not to the interfaces. However, the rigid constraint of interface stability can become a challenge as a platform ages. Changes inside a platform are often intended to add new functionality and capabilities made possible by new technologies that might have appeared long after the initial design of a platform. As a platform evolves, elaborating elements added to it often increase its internal complexity and often need different interfaces (Arthur, 2009). The existing platform interfaces might not be able to accommodate such newly added functionality, which a platform owner might want to make accessible to app developers to leverage in their own work. Remember that innovation in platform markets is often combinatorial; a new capability added to a platform delivers more mileage in evolutionary competition when many app developers can build on it.
A platform owner can never tweak existing platform interfaces. In reality, platforms often lag in evolving the infrastructure they offer apps; this imbalance can be a major source of risk to a platform’s long-term prospects. Instead, a platform can introduce new functionality to its ecosystem by adding new interfaces and APIs without touching existing ones. Other alternatives include supporting multiple versions of an API (which is inefficient), adding a mediation layer that can translate between different versions of an API (which is unscalable), or holding off altogether (which stunts evolution). If versioning is used to change an API, it must maintain backward compatibility to preserve the contract with app developers. Adding new platform interfaces in the form of APIs does not require any changes to existing apps, preserving composability. The appeal of extending the functionality that a platform provides apps by adding new APIs therefore explains the proliferation of APIs in platforms over time. (On last count, the iOS platform had about 15,000 APIs.)
10.4.1.2.4 Spotting such opportunities
A platform owner can recognize candidate generic functionality to move into a platform by looking for upstream complements now used by app developers that can be bundled into the platform and made available to all apps. (This has a direct connection to upstream envelopment in the longer term.) Other strategies that a platform owner can use to recognize such opportunities include learning from leading-edge app developers, discovering app developers’ latent needs manifested as frustrations with rival platforms, and anticipating inflections where a niche technology trend takes off and becomes mainstream (using S-curves and chasm models described in Chapter 2).
10.4.1.3 Expanding app developers’ market access
The second approach to increasing a platform’s stickiness with app developers is by improving the findability of apps by end-users. This requires reducing end-users’ app search and discovery costs, discussed earlier, which simultaneously increases platform stickiness with app developers and end-users. Fail to do this well, and one of two outcomes are likely. Either the platform will lose the loyalty of both app developers and end-users. Or, the market will create alternative ways such as Amazon’s creation of its own version of an app discovery marketplace that attempts to fix the gap left by Google in its Android platform. Growing the app developers’ addressable market and improving findability, however, requires that a platform owner largely control platform strategic and implementation decisions. A democratic arrangement involving app developers has its place, but not in such decisions.
10.4.2 Growing platform synergy across the ecosystem
Platform synergy is the degree to which app developers of a platform develop an app specifically for the platform, meaning that the apps integrate with the platform and build on its native capabilities to a greater extent vis-à-vis rival platforms. Platform owners would want apps to grow more platform-specific over time for two reasons. First, greater platform specificity translates into a better end-user experience and greater opportunities for differentiating a platform from rivals. Exploiting the functionality unique to a platform means that small improvements in a platform’s capabilities can have a widespread impact on the level of innovation across its ecosystem. Second, as apps become more dependent on a platform, they become less generic and in turn make a platform less readily interchangeable with a rival platform. This lowers the likelihood of either app developers or end-users defecting to a rival platform. In other words, it can increase stickiness on both sides of a platform.
However, increasing platform synergy is a catch-22 from an app developer’s perspective: While it allows them to better exploit a platform’s capabilities in their work, it can lock them into a platform and make them vulnerable to opportunistic behavior by a platform owner. Managing expectations is key to improving apps’ platform synergy. App developers will invest in a platform based on their expectations of how a platform owner will behave (Evans et al., 2006, p. 254). Platform owners will occasionally engage in downstream vertical envelopment (i.e., integrate the functionality of an app into the platform) either to extend the platform’s native functionality or as a hedge against the failure of app developers to supply that functionality. A platform owner should rarely ever engage in such envelopment because it can signal that the platform owner will change the rules of the game, and in turn discourage an increase in platform synergy. A platform owner must offer compelling reasons to app developers for them to expose themselves to such vulnerability. Three things, all under the platform owner’s control, can give app developers such reasons:
1. A large installed base of end-users. Growing the installed base of end-users provides app developers a larger prospective pool of users for their app. A larger installed base offers greater opportunities for exploiting the platform’s network effects to an app’s advantage. When a platform symbiotically serves as a gateway to access a larger market, app developers are more likely to increase the platform synergy of their apps.
2. Economizing the code developed by app developers. The primary economic value of a platform from the app developers’ perspective is economizing on the amount of code that app developers must write themselves to deliver a working app to the app’s end-users (Evans et al., 2006, p. 58). Therefore, the same things that increase a platform’s stickiness with app developers—easier integration, more productive development, and better app development tools—also encourage an increase in the platform synergy of apps.
3. Differentiated platform capabilities vis-à-vis rival platforms. If a platform offers technical capabilities made available to apps via APIs that rival platforms do not offer, app developers are more likely to increase their apps’ platform synergy. However, such capabilities must pass the resource litmus test: These capabilities must not only be rare, they must also be valuable to app developers.
In summary, improving platform synergy requires attention primarily to platform governance.
10.4.3 Orchestrating platform plasticity
A platform exhibits plasticity when it learns to do new things and gains new capabilities over time. In other words, it can morph to deliver new functionality and meet needs that did not exist at the time of its original creation for its existing and prospective users on both sides. Plasticity is a way to measure the level of innovation that is successfully realized around a platform. To grow in plasticity, a platform needs to be more a sponge than an inventor. This requires speeding the inflow of innovations into the platform, which can be done in three ways: (1) strengthen the ecosystem’s capacity to innovate (via platform modularization) and make them want to out of pure self-interest (via governance, especially pricing), (2) expand the diversity of the pool supplying new ideas to the ecosystem, and (3) recognize what innovations will not occur naturally and take responsibility for them.
10.4.3.1 Catalyzing ecosystem innovation capacity with developers’ self interest
A flexible architecture and dispersion of decision rights across the ecosystem are the two powerful levers for improving platform plasticity. The distribution of subsystems across a platform’s ecosystem means that their ownership is widely dispersed. Too much ownership can create a gridlock by imposing daunting coordination requirements in which everybody loses. A gridlock is a human creation; an artifact of ownership gone awry (Heller, 2008). A preventive measure against gridlock is platform architecture modularization, which allows app developers to work unfettered on their own projects without waiting on changes elsewhere in the ecosystem.
A modularized architecture gives a platform ecosystem an evolutionary advantage. While monolithic designs can only be improved as a whole, modular designs can be improved one subsystem at a time. A monolithic platform simply cannot replicate the innovation potential of a larger, diverse pool of outsiders rallied around a modularized platform with a fire in their belly. Modularizing a platform’s interfaces strengthens a platform’s plasticity by bolstering its ecosystem’s capacity to innovate around a platform in four ways:
• Decouples app evolution from platform evolution. Modularization of a platform decouples the internal implementation of the platform and those of apps by hiding within-subsystem implementation decisions (Pil and Cohen, 2006). This creates technical autonomy within all major subsystems of a platform’s ecosystem; changes inside one do not have a ripple effect nor require changes in the others. In contrast, innovation in a monolithic architecture is system-wide rather than in little subsystem-level chunks. Greater within-platform freedom and a lower need for overt coordination with apps increases its freedom to evolve (Baldwin and Clark, 2000, p. 221). This is why modular systems tend to evolve faster (de Weck et al., 2011, p. 85; Ethiraj and Levinthal, 2004a,b; Simon, 2002). Such technical autonomy enables independence in how the owners of the platform and individual apps implement them and how often they can tweak them. The platform and apps can be internally monolithic yet interoperate solely by complying with the interfaces and APIs. This allows the platform and apps to evolve independent of each other, at a rate that is appropriate to their own specialized domains, market dynamics, and varied end-user needs. This reduction of the need for coordination with anyone else in the ecosystem allows fast, autonomous—almost continuous—market experimentation by app developers (Kamel, 1987; Sanchez and Mahoney, 1996). Similarly, the platform can be tweaked more rapidly and assimilate technology advances outside the ecosystem, unconstrained by app dependencies, and therefore is likely to come out ahead in Red Queen competition. Therefore partitioning the platform through modularization does not just lower complexity but exponentially reduces it. In contrast, a platform with a more monolithic architecture will simply be unable to absorb new capabilities at the same rate. In real options terms, platform modularization therefore creates real options as each app gains independence within the constraints of the platform’s design rules (Gamba and Fusari, 2009).
• Deepens specialization across the ecosystem. The use of decentralized solutions search processes by many diverse designers is a fundamental premise of the theory of modular evolution (Baldwin and Clark, 2000, p. 14). Modularization reduces the need for a platform owner to understand the domains of its app developers, and the need for app developers to know internal details of the platform. The key, as Linus Torvalds puts it, is to keep people from stepping on each others’ toes. This requires minimizing the need for communication, even forbidding it (Langlois and Garzarelli, 2008). Each app developer needs to be concerned with only what the platform does, not how it does its job. This simplification of their respective solution spaces creates a valuable form of mutual ignorance that allows the platform owner and app developers to specialize more deeply in their own domain (Tiwana, 2008a). The platform owner can then treat apps as black boxes, unconcerned with their implementation.
• Reallocates platform owner resources toward platform innovation. Recall that the greatest complexities in platform ecosystems arise at the interface of the platform and apps. Standardization of platform interfaces through modularization eases integration of apps with the platform, lowering platform owners’ recurring and unpredictable app integration costs (Argyres and Bigelow, 2010; Moneverde, 1995). These interfaces provide the glue that holds the platform and its apps together. This in turn frees up resources that a platform owner would need for integrating apps, which can now be reallocated to innovating within the platform. Modularization therefore speeds platform capability enhancement by freeing up more resources for enhancement of native platform functionality and by requiring less time for integrating apps (Kamel, 1987).
• Protects platform secrets. Platform modularization limits how much of the innards of a platform are visible to app developers and rivals without discouraging the emergence of complementary apps. This selective disclosure of proprietary technology safeguards platform innovations by maintaining a layer of secrecy around their implementation, reducing the outflow of innovations from a platform. It also increases a platform owner’s control over the interfaces, which is a subtle but potent form of control through architecture instead of overt power.
Opening up a platform using an architectural modularization strategy often amplifies innovation around the platform by an order of magnitude, provided its governance structure encourages it as well. Amazon Web Services (AWS), Twitter, Netflix, NPR, Facebook, and SalesForce have successfully used this approach through APIs to stimulate external innovation around their platforms. Cloud-based Salesforce.com, for example, opened up its core services to outsiders to augment; external apps based on its API now account for about 75% of the company’s business.
But the plasticity-enhancing potential created by platform modularization requires that platform governance be aligned with its architecture. In particular, the pricing dimension of platform governance should provide strong incentives for app developers to actively engage in innovating around a platform purely out of self-interest. Failing such alignment, app developers’ goals can dominate at the expense of ecosystem interests; this behavior is known as suboptimization in complex systems thinking. Furthermore, allocating app decision rights primarily to app developers in modularized platforms ensures that app-level strategic and operational decisions are rapidly translated into action.
10.4.3.2 Increasing ecosystem diversity increases platform plasticity
An old adage says that the best way to good ideas is to generate a lot of ideas. The best way to generate a lot of ideas around a platform is to have a lot of different people generate them in parallel. A second way to bolster platform plasticity is therefore to increase the diversity and size of the pool of app developers in the platform’s ecosystem (i.e., increasing the inflows of innovations by tapping into ideas from all corners of the ecosystem). The diversity and size of the app developer pool matters more when there is greater heterogeneity in the platform end-users’ needs and greater technology and market volatility (van Schewick, 2012, p. 9). Decentralized innovation by a large and diverse pool of app developers means that a variety of experiments and ideas will be tried, resulting in more innovation inflow into the platform’s ecosystem. The more independent approaches that are experimented with, the greater is the likelihood that one solution will solve a focal open problem particularly well. Decentralized ecosystem governance will therefore generally produce more diverse apps, increasing its odds of producing diverse solutions that meet diverse end-users’ needs, and in turn a more sustainably attractive platform. This requires a platform owner to be tolerant of app developers’ activities at the margins, unusual experiments, and outliers. Such activities can stretch the platform owner’s own understanding of the possibilities for the platform. Platform architecture—by altering the degree to which the platform owner and app developers are independent and overlapping in their responsibilities—influences the composition of app developers that choose to join the ecosystem, their incentives and disincentives, and their ability and constraints to innovate freely.
The key is to ensure that platform modularization is aligned with governance. All three dimensions of governance are important. Decision rights for apps should be sufficiently decentralized for app developers to be able to act on opportunities that they spot; revenue-sharing incentives should be sufficiently motivating vis-à-vis rival platforms for them to bear the risk; and the control portfolio should be lean enough to not get in their way yet ensure that the quality of what goes into the platform’s ecosystem is not degraded. As Figure 10.12 illustrates, the better such alignment, the greater the growth in the diversity and numbers of app developers that are likely to be attracted to a platform.
FIGURE 10.12 Architecture–governance alignment influences who participates in a platform’s ecosystem from the app developer side.
Input control is particularly critical in the early stages of a platform ecosystem’s lifecycle to ensure that the apps that enter the ecosystem increase the perceived value of a platform in end-users’ perceptions. Google used minimal input control in its Android ecosystem, which encouraged a lot of junky apps. Junky, half-baked apps and minimal ports from rival platforms of dubious value and quality can drown out the fewer strong apps by their sheer volume. This substantially increases end-users’ search costs, reducing the long-term prospects of the platform.
10.4.3.3 Recognize the platform innovations that will not naturally occur
Finally, a platform owner must recognize that modularized platforms are good at generating rapid incremental improvements within individual apps in an ecosystem but terrible at producing ecosystem-wide ones. Different architectures will impose different idea implementation costs on app developers. Therefore, different ecosystem architectures will lead to different types of innovation activity emerging as dominant in a platform’s ecosystem over the long term. Recall from Part II of the book that modularized platform ecosystems amplify innovation vis-à-vis monolithic systems by shifting the innovation mode from incremental to modular. In modularized platforms, the dominant mode of innovation will therefore be modular, within-app innovation. This is shown in Figure 10.13. Incremental innovations come from both platform owners and app developers, while radical innovations will almost never occur in the absence of scrapped-and-rebuilt platforms. A platform owner must take responsibility for architectural or ecosystem-wide innovations will not occur naturally in the platform’s ecosystem. This has consequences for a platform’s durability; we subsequently discuss ways in which a platform owner can address this challenge.
FIGURE 10.13 The origins of two classes of innovations in modularized platform ecosystems.
10.5 Orchestrating Long-Term platform evolution
10.5.1 Orchestrating platform envelopment
Envelopment by a platform can span expansion of a platform into the turf of adjacent markets (horizontal envelopment) or adjacent parts of the ecosystem’s value chain (vertical envelopment) (see Figure 10.14).
FIGURE 10.14 Two types of envelopment moves by a platform.
10.5.1.1 Horizontal envelopment
Horizontal envelopment is the most widespread envelopment move through which a platform can swallow the functionality of a product or service—or even a platform—in an adjacent market. A horizontal envelopment move primarily attempts to offer new services to existing customers (Zook and Allen, 2003), as illustrated in Figure 10.15. Horizontal envelopment has two prerequisites. First, there must be a considerable overlap between the platform’s users and the users of the adjacent solution. This allows the enveloping platform to carry over—simply replicate—its existing network of users in the space of the enveloped solution. For new entrants in a platform market, envelopment is therefore a powerful way to circumvent the blocking caused by rivals’ existing network effects. Second, the enveloping platform’s assets should be leverageable in the enveloped solution’s domain. Whether the enveloped solution offers a stronger value proposition by offering better functionality or lower costs, it must be strong enough to convince the target solution’s installed base of users to adopt it. Horizontal envelopment can preemptively prepare a platform for saturation and decline in its core market by providing a segue into a future core business. Your next core business, however, will not introduce itself with fanfare (Zook and Allen, 2003).
FIGURE 10.15 Horizontal envelopment by a platform.
A platform owner can spot opportunities for horizontal envelopment in five ways.
1. Identify adjacent bundling opportunities. Identify standalone products and services that existing end-users of your platform value that could possibly be bundled profitably into the platform.
2. Watch S-curves in adjacent markets. Flat or declining adoption rates usually indicate mature markets with stable products or services. There is little product innovation going on in such markets and the focus has usually shifted to process innovations. These are often targets for envelopment attacks if (a) a platform can offer the same functionality cheaper or offer improved functionality and (b) the user base of the platform and the target market overlaps. The assets of a platform must be leveraged to either reduce costs of delivery or significantly enhance the value proposition of the target solution. For example, the digital camera industry was successfully enveloped by smartphones, which offered somewhat weaker photography capabilities but with better integration with email and social networks that a large proportion of digital camera users also used.
3. Watch for convergence of previous independent streams of technology. Opportunities for horizontal envelopment also arise due to the convergence of previously disparate technology solutions, which allows one platform to expand its functionality to include an adjacent product or service and offer it to end-users as a multiproduct bundle. Technological convergence can therefore help anticipate envelopment attacks from adjacent platforms. Convergence is driven particularly by packetization, discussed in Chapter 1, associated today with the ongoing technological leaps around the Internet of Things and additive manufacturing (3D printing). Every horizontal envelopment opportunity is also potentially an envelopment threat. Watch out for competition from innovators in adjacent markets, who could offer a directly competing product created and distributed with a very different business model. The entrée of open-source Linux projects into the smartphone OS market in 2014 is an example of such a threat to companies such as Apple since the former use open-source and GPL-licensed code for their platforms.
4. Track regulatory changes. Watch for external, regulatory changes in mature industries outside your own industry that alter the rules of competition in those industries. For example, the regulatory change allowing the use of enhanced emergency calling services (E911) in the United States allowed voice-over-IP service providers to directly envelop the residential telephony market.
5. Watch envelopment attacks by rival platforms. Envelopment attacks, no matter how feeble, by rival platforms that your own platform directly competes with can also help identify envelopment targets.
10.5.2 Rebuffing envelopment attacks on a platform
Launching envelopment attacks requires an aligned platform governance structure, particularly decision rights. The foregoing strategies for horizontal envelopment require that a platform’s strategic decision rights reside primarily with the platform owner. The evolutionary metrics described in the preceding sections also require such partitioning of platform decision rights. A platform owner’s alertness to envelopment opportunities is also potentially valuable to app developers because it expands the pool of potential end-users to which they have access. In this sense, envelopment goes horizontal envelopment attacks launched by a platform hand in hand with platform stickiness with app developers. Eighty percent of successful adjacency moves are built on deep insights into end-users’ needs, behaviors, and frustrations (Zook and Allen, 2003). App developers are usually far more tuned into these than a platform owner. Involving app developers in seeking envelopment opportunities can help identify underdeveloped adjacencies, exploit untapped insights into customers, and identify unrecognized market segments. Therefore, platform strategic decision rights should include input from app developers. In other words, they should reside primarily—but not exclusively—with platform owners.
A platform owner is also likely to encounter horizontal envelopment attacks by indirect competitors, who can exploit the same convergence dynamics to foreclose existing markets and overlapping end-users. A platform owner must first decide whether an envelopment attack is a real threat. If the side on which a platform makes its money—either app developers or end-users—perceives that the enveloping platform delivers a better value proposition than your own, then the envelopment threat is real.
How can a platform owner rebuff horizontal envelopment attacks that it encounters? There are three defense mechanisms that a platform owner can use. First, tight control over a platform’s interfaces only protects against existing rivals but does little to deter horizontal envelopment attacks (Farrell and Saloner, 1992). One logical response is to reciprocate with a reverse horizontal envelopment attack if the threat of envelopment is credible. Second, altering the business model used by a platform owner can sometimes rebuff an envelopment attack. For example, a platform owner might shift to an ad-supported business model that it can viably use profitably but the envelopment attacker would not be able to financially capitalize. Third, cross-licensing partnerships and mergers of two vulnerable platforms can give the merged platform greater ability to survive an attack. An example of this is the fusion of Nokia’s Symbian platform and Microsoft’s Windows Mobile platform, which plausibly made them better able jointly to compete with rivals such as Android and iOS.
10.5.2.1 Vertical envelopment
A second type of envelopment move is one where a platform owner expands the scope of a platform to occupy a different link in the platform’s value chain (Zook and Allen, 2003), as illustrated in Figure 10.16. This involves swallowing the functionality provided by a participant in either the upstream or downstream part of the platform value chain. An upstream envelopment move can involve integrating an upstream ingredient provider, either consensually or by brute force. These can be providers of external services that a platform uses, licensed intellectual property that goes into a platform, and suppliers of software components (such as Flash and VPN technology). An example of such a move is Apple integrating cloud storage services into iOS in 2011; these were previously provided by external service providers such as Dropbox. Such envelopment moves typically threaten the bread-and-butter business of the upstream partner and should be attempted only when vertically integrating an upstream ingredient can increase the value and stickiness of a platform both for end-users and app developers significantly beyond the level possible without integrating. In this instance, introduction of iCloud into the platform significantly increased app developers’ stickiness by allowing them to integrate and build on cloud storage capabilities into thousands of apps, thereby reducing app developers’ innovation costs. The service had 300 million users by the end of its first year. Upstream envelopment moves however are often high risk and costly, and opportunities are relatively infrequent.
FIGURE 10.16 Vertical envelopment by a platform.
Downstream envelopment involves assimilation into the platform of a downstream complement—specifically the functionality of an existing app. Opportunities for downstream vertical envelopment are relatively abundant compared to any other envelopment opportunities. However, downstream envelopment is often a challenging dilemma because it puts the platform owner in direct conflict with the interests of its app developers. Such envelopment moves can destroy an existing app developer’s business model overnight (Evans et al., 2006, pp. 53, 254). A platform owner must approach downstream envelopment with kid gloves. As a general principle, a platform owner should credibly signal that it will keep out of its app developers’ niches. Steamrolling app developers is not an effective way to attract and retain them. Intel, for example, assists outside developers of promising applications of its core products and promotes them, but does not dabble directly in their markets. As apps become more specialized and begin addressing smaller niches, it is no longer possible for the platform owner alone to address them. When the long-tail effect kicks with a platform at the center, everyone in a platform’s ecosystem wins. The penalties for paralyzing the long-tail effect usually exceed the short-term financial gains from downstream vertical envelopment by a platform owner. Put another way, because horizontal envelopment can destroy a platform owner’s credibility with app developers and alienate them, the long-term damage to a platform’s ecosystem can often exceed the immediate improvement in a platform’s native functionality. Commitments by a platform owner to prospective app developers must remain credible to be effective (Rysman, 2009). Although platform owners should avoid app developers’ markets, they invade their turf often enough to make many app developers wary.
10.5.2.2 When is downstream envelopment by a platform acceptable?
So, when it is acceptable for a platform owner to initiate a downstream vertical envelopment attack? A platform owner should make its own apps—or envelop vertically downstream—only under three conditions:
1. Strategic functionality. First, when the functionality of the app can strategically differentiate a platform from its rivals and a platform owner wants to foster dramatic improvements by app developers in its functionality. By setting a benchmark for app developers to beat, this can foster intense competition to improve app functionality. This has an effect on ratcheting up performance of app developers (Bradach and Eccles, 1989; Kim et al., 2011). It can engender intense competition from app developers, who can survive only by providing more value to end-users than the platform owner’s own app does. While it is important to provide direction and foster competition among app developers, a platform owner must be careful not to take it so far that there’s no money left on the table. A platform will then fail to attract new app developers and fail to retain existing ones. However, when new functionality previously absent from the platform is introduced as an app, it does not put app developers’ interests in conflict with the platform owners’ interests.
2. Gap-filling functionality. Second, when the app market is unlikely to provide functionality that a platform owner believes is needed by a platform. In this scenario, the platform owner-provided app simply fills a void that might otherwise be left unfilled. An example of this is the development of presentation software (Keynote) by Apple for the iOS platform. When such apps are created by the platform owner from the outset of a platform, it does not have the credibility-damaging effect typical of downstream vertical envelopment. The only other instance in which a platform owner will vertically envelop a downstream app is in retaliation to an app developer attempting to vertically envelop a platform. A recent example of this was the introduction of a mapping app by Apple, intended to replace Google Maps as Google attempted to envelop the iOS platform with its own Android platform. Platform owners must remain cognizant of today’s app evolving into tomorrow’s rival platform.
3. The common good outstrips the few that are penalized. Third, downstream envelopment is more acceptable when the number of app developers that benefit from the move vastly outnumbers those hurt by it. Finally, when a platform's existing end-users significantly benefit from it or it attracts new users to the platform on either side, the upsides of downstream envelopment can outweigh its downsides. This final criterion can be a slippery slope.
10.5.3 Orchestrating platform durability
A platform’s durability refers to its endurance in the marketplace in the face of competition. Recall that we are more interested in changes—increases and decreases—in a platform’s durability rather than its survival or mortality. A platform’s durability is a function of its direct contribution to the platform’s ecosystem, always relative to rival platforms. The platform must contribute resources that pass the litmus test—they must be valuable, rare, inimitable, and nonsubstitutable from the perspective of both sides of the platform, end-users and app developers (Figure 10.17). A platform will endure only if it continues to offer a compelling value proposition to its current and prospective app developers and end-users. Platforms that fail to create a win–win for their app developers wither and die. For a platform to be durable, both sides of the platform must remain better off being part of its ecosystem than outside it (Evans et al., 2006, p. 56). (Recall that indicators of a platform’s durability include changes in the survival rate of apps, the proportion of apps that are updated at least once a year, and the changes in the percentage of platform adopters on both sides who remain active users.) Given that a platform’s primary users are its app developers, we focus primarily on them. Tending to this side of the platform usually accomplishes the same things that a platform owner must do to increase its durability with its end-users.
FIGURE 10.17 Imitation by rival platforms destroys the rarity of valuable platform resources.
A test for the competitive advantage of a platform is the resource litmus test. A platform initially gains traction by contributing capabilities and resources that are valuable to its app developers but rare in rival ecosystems. To sustain its initial advantage, these resources must also be inimitable and nonsubstitutable. But the intrinsic properties of software often make it imitable through replication and reverse engineering, notwithstanding the mild protections of patents and copyrights that are often challenging to enforce in global markets. In a sufficiently competitive market, imitation by rival platforms often replicates valuable functionality and destroys its rarity. Today’s rare capability becomes tomorrow’s norm, as illustrated in Figure 10.17.
That leaves only two viable solutions to enhance a platform’s durability: (1) adding valuable new capabilities faster than rivals can replicate them, giving them temporary rarity, and (2) developing nonsubstitutable assets. As we subsequently explain, accumulating nonsubstitutable resources is not a bulletproof strategy because convergence-enabled envelopment attacks can altogether bypass the need for them.
10.5.4 Consistently contributing valuable resources to the ecosystem
The first step for a platform owner is accepting that any competitive advantage is temporary. No positional advantage is durable, but the ability to evolve is. The hallmark of a durable platform is not solely focusing on doing some things well but rather being good at learning how to do new things that app developers and end-users value. A platform owner must pay attention to six things in evolving a platform’s value proposition in ways that enhance its durability vis-à-vis rival platforms.
10.5.4.1 Many eyes are better than few
A platform's biggest asset in recognizing new ways of adding valuable resources to its ecosystem is to use app developers as its many eyes. Since app developers are likely to be far better tuned to diverse end-user needs, granting them sufficient autonomy by decentralizing governance across the ecosystem can increase the volume and variety of new ideas for a platform to generate new value. Recall that the best way to generate good ideas is to generate lots of them. This autonomy, however, must be coupled with strong win–win propositions for app developers, as dictated by the pricing dimension of governance. A platform owner that remains receptive—not necessarily agreeable—to inputs from app developers is likely to find new ways to keep the platform valuable to its app developers and remain at the center of its ecosystem. Platforms that fail to contribute nonsubstitutable capabilities that app developers’ value and at a pace that at least matches rival platforms will soon be at a competitive disadvantage.
As we enter the era of “big data,” think of signals, not data. The amount of data confronting organizations has increased nearly tenfold in the past decade and is expected to increase a thousandfold in another decade. Managers used to thinking in terms of data points must therefore shift their thinking to data streams. Episodic information processing must be replaced with dynamic information processing. These data streams must be quickly mined for insights, extracting the right signals, and acting on them.
Leveraging app developers as its many eyes increases a platform owner's capacity to decode weak market signals embedded in such data streams and act on them before rivals can. In contrast, platform companies that withered and died—Palm, Blackberry, Nokia—all failed to notice ground shifts in the market, usually caused by fledgling entrants that were too little to even notice. The ability for a platform owner to detect weak signals from the ecosystem’s eyes and ears coupled with the flexibility maintained by investing in real options can endow a platform unrivaled ambidexterity to serve today’s markets but be prepared for tomorrow’s. All of this, however, requires a mindset that is humble, mutually respectful, and open to diversity of divergent opinions and unorthodox viewpoints of app developers. It also requires a culture that encourages members of the ecosystem to experiment rapidly, frequently, and economically with technologies and business models.
10.5.4.2 Coevolving platform governance with aging platform architecture
The second way in which a platform owner can maintain the inflow of new value into a platform is by adapting and coevolving platform governance to mirror an aging platform’s architecture. Even if a platform is codesigned with perfect architecture–governance alignment at the outset, unintentional architectural drifts that accompany aging can cause them to fall out of alignment. Put another way, a platform’s age is a liability to its plasticity. A platform becomes less and less malleable as it ages. This phenomenon, known as code decay, occurs due to the violations of the prescribed design principles and deviations from the intended architecture that accumulate over time, both within the platform and across the ecosystem (Eick et al., 2001). It gets worse over time: As a platform ages, its complexity grows due to undocumented dependencies and workarounds to its interface standards, in turn worsening its plasticity over time. This makes it increasingly challenging to make internal changes to a platform without fracturing the ecosystem. Implementation shortcuts and modular principle violations by the platform owner and app developers can be considered a technical debt that must be paid at some point in the future as a platform evolves. Symptoms of code decay are bloated and excessively complex code, the need for widely dispersed changes (i.e., the span of a code change is not as localized as it used to be for a platform of that level of modularization), and an excessive proliferation of many interfaces that often results from adding new APIs (Baldwin and Clark, 2000, p. 416; Eick et al., 2001). Taken to an extreme, code decay eventually transforms the platform’s ecosystem into a monolithic block. Changes in architecture are then needed to “refactor” the platform to fix these problems. This is often an impossible task in mature platforms with many apps, which will likely break and have to be reimplemented. Changes in platform architecture—even small ones—can then wreck a platform because they often are inseparable from changes in its interfaces. It is a hit or miss bet for a platform owner: Firefox rebuilt Firefox with version 2 with much success and Microsoft rebuilt Windows XP as Windows Vista with little success. In either case, the existing apps on the original platform ceased to function with the rebuilt platform. While effective governance can discourage behaviors that intensify the liability of age, they cannot eliminate the problem.
Instead, this requires the platform owner to coevolve the governance of a platform to mirror the current as-it-really-is architecture rather than keeping it aligned with architecture as it used to be earlier in the platform’s lifecycle. This age-driven architecture–governance “remirroring” is illustrated in Figure 10.18. Since the effect of age is increasing monolithicity of the platform’s architecture, realigning governance primarily requires reducing the degree to which app implementation decision rights are decentralized and increasing the use of formal control in the portfolio used by the platform owner to regulate app developers’ work. A failure to coevolve governance to mirror devolving architectural modularity will otherwise increase the platform owners’ integration costs by unbalancing the integration–autonomy seesaw, described in Chapter 2.
FIGURE 10.18 How ecosystem governance must evolve with platform age to maintain architecture–governance alignment.
Such coevolution of architecture and governance driven by age must also be complemented by consideration of forces exogenous to the platform ecosystem (Figure 10.19).
FIGURE 10.19 Exogenous drivers of architecture–governance coevolution.
10.5.4.3 Expanding the scope of a platform through vertical envelopment
The third way to expand the value of the resources contributed by a platform to ensure its durability is through vertical upstream envelopment, described earlier in our discussion on increasing stickiness. Doing this more aggressively than rival platforms allows the Red Queen effect to be multiplied in favor of the platform because upstream capabilities that are adopted by many app developers raise the bar for what a rival platform must replicate to keep up. iOS adding cloud storage service that apps could build on is an example of such a durability-enhancing envelopment move.
10.5.4.4 Maintain modularity by adding new APIs
Fourth, adding native new functionality that builds on external technology advances using new APIs, as described earlier in this chapter, maintains the benefits of platform modularity without accelerating architectural decay. However, there is a limit to the proliferation of APIs after which the sheer complexity of the platform makes it challenging to attract new app developers.
10.5.4.5 Plug the gap in system-wide innovations that will not naturally occur
The fifth way to expand the value of the resources contributed by a platform is for the platform owner to recognize that ecosystems of modularized platforms will not produce system-wide, non-app-level innovations. A platform owner must take responsibility for pursuing such innovations to ensure its durability, illustrated in Figure 10.13 in our discussion of platform innovation. Examples include new system-wide services that apps can leverage. Paradoxically, the rigidity of frozen platform interfaces that enable rapid innovation at the ecosystem level stymies radical innovation at the platform level. Recall from our discussion on platform plasticity that platform modularization increases the inflow of app-level innovations but forecloses systemic innovation by incapacitating changes to the platform’s interfaces. Platform modularization is therefore good for making lots of little hops but terrible for making large technological leaps. In the long term, this reduces the durability of a platform, particularly when new rivals—unencumbered by legacy interfaces and APIs—are able to exploit systemic advances in new generations of underlying technologies in their own platforms (Brusoni and Prencipe, 2006; Pil and Cohen, 2006). Radical changes in platform architecture are even more unlikely because specialized knowledge is eventually fragmented across members of the ecosystem, making it impossible for the platform owner to possess detailed knowledge of the emergent dependencies across the ecosystem (Baldwin, 2008). An ecosystem’s core competencies then become its core rigidities, as app developers and the platform owner become more deeply focused on the niches where they excel. Managing this tradeoff requires applying the Goldilocks principle in the initial design of the platform so it has an intermediate level of modularization—neither too much nor too little. A related tactic is to ensure that the interface standards are designed to be versatile so their restrictiveness does not retard innovation (Farrell and Saloner, 1992). Unfortunately, determining what is a just-right level for modularity is a tricky question with no straightforward answers.
10.5.4.6 Mutate into markets when a platform’s existing assets are still rare
The final tactic to counter the durability-diminishing effects of replication by rivals is to mutate the platform into horizontally adjacent markets where the platform’s existing assets are still rare and potentially valuable. This was described in depth in the discussion on platform envelopment earlier in this chapter.
10.5.5 Accumulating nonsubstitutable assets
The second approach to improving a platform’s durability is to accumulate nonsubstitutable assets in the platform’s ecosystem. The single hardest to substitute asset is cross-side and same-side network effects created by a platform. As we described earlier, network effects create a value-driven, noncoercive lock-in on both sides and protects a platform. However, we described how new rivals using mutation, envelopment, and carryover can break past network effects that previously protected a platform. The other two nonsubstitutable assets are more of a nuanced mindset that guides platform evolution.
10.5.5.1 The Icarus paradox: the other thing besides taxes that is an absolute certainty
Platforms encounter the “Icarus paradox” as they age: The very reasons that led to its market success hinder its ability to respond to new generations of technology, eventually causing its downfall. As Chuck Palahniuk says in The Fight Club, on a long enough timeline, the survival rate for everyone drops to zero. The core capabilities that are honed over successive generations of a platform can become its core rigidities, largely because architectural change becomes almost impossible once a modular design has taken off and has enlisted a large ecosystem of app developers around it. While there is no recipe for avoiding the Icarus paradox, platform owners can delay it by changing what they focus on as a platform progresses through different stages in its lifecycle. As a platform ages and a dominant design is well established in its core market, the rate of fundamentally new innovations sharply decreases. At this point, the focus must shift toward process innovations. This leaves all platforms following the industry’s dominant design vulnerable to new entrants who enter the market with a fundamentally new dominant design that incumbent platforms cannot readily switch to. Therefore, a platform owner must focus on technological and business model innovations in the pre-dominant design era of the platform’s industry, and focus on innovating in content and substance more than the mechanisms and routines used to orchestrate the ecosystem. However, the focus reverses in the post-dominant design phase to innovating in the platform’s processes as fundamental product innovations become harder. However, process innovations simply delay the inevitable; incumbent platforms almost always fail to make the leap across technological discontinuities.
Another nonsubstitutable asset therefore is the capacity to recognize the role of lifecycle effects and change a platform’s focus to align with its stage in the evolutionary lifecycle. Two key lifecycle attributes discussed in Part I are relevant: emergence of a dominant design and progression along the S-curve. Platform owners must shift expectations for what they focus on accomplishing to be in line with a platform’s current stage in its lifecycle. First, the emergence of an industry-wide dominant design shifts competition from among designs to within variants of the design. When a platform establishes or follows a dominant design, its core technological features are so effectively replicable that they merely become the cost of entry and are no longer a differentiator. At this point, modular innovation is the dominant mode for differentiation. This means that differentiation among platforms is driven primarily by improvements at the app rather than platform level. Second, as a platform moves from the upward trajectory to its peak on the S-curve, radical improvements become progressively harder to make and the rapidity of new innovations levels off. It does not matter how hard a platform owner tries, less improvement occurs per investment dollar. The rate of finding improvements slows exponentially over time as a platform ages; each major advance increases the difficulty of finding the next one. The emphasis should then shift away from fundamental product innovations and more toward process innovations (i.e., doing existing things better). The platform owner’s mindset should enable such process innovations across the ecosystem, or at least not constrain them. To paraphrase an old saying, platform owners must have the serenity to accept the things they cannot change, changes the ones they can, and the wisdom to know the difference. The Icarus paradox is in the category of unchangeable things.
The Origins of the Icarus Paradox
The Icarus paradox is a term coined by Canadian economist Danny Miller for the phenomenon that businesses fail abruptly after enjoying considerable success in the marketplace. Their initial success brings about their own downfall due to subsequent overconfidence and complacency. The term comes from Icarus—the son of the master craftsman Daedalus—in Greek mythology who flew too close to the Sun and melted his own wings, which were made of feathers and wax (Figure 10.20). This, according to the legend, caused him to drown to his death in the sea, which is known in the present day as the Icarian Sea near Samos in Greece.
FIGURE 10.20 The Icarus paradox is named after the legend of Icarus in ancient Greek mythology. Source: Thomas Bulfinch, The Age of Fable, Henry Altemus Company, Philadelphia, 1897, p. 202.
The Icarus paradox eventually brings every successful platform to a fork in the road where either path leads to mortality. The choice is to stick with an obsolete core or to reconstruct the platform from scratch. Sticking with a stagnating platform core can be disastrous but fixing the problem requires a complete overhaul or reconstruction. Core reconstruction is necessary when the platform owner is faced with a generation of technologies or business models that straddles the platform with inherently inferior economics that it cannot shake off or sustain relative to new kids on the block (Zook and Allen, 2003). Successful platforms repeatedly stumble in their attempts to catch up by using a binge-and-purge strategy. Such bet-the-company moves are almost always a loser’s game (Zook and Allen, 2003). Replacing the platform core outright almost always fails because it often requires breaking backward compatibility from the existing generation of the platform, which in turn requires rebuilding apps. Maintaining compatibility between successive generations of a platform—of what economists call vertical compatibility (Rysman, 2009)—is necessary to avoid alienating existing app developers. Examples of such abrupt overhauls that failed include Microsoft’s attempt to radically reinvent its Windows platform using Windows Vista and Zune’s tile-based interface, Palm’s attempt to rebuild PalmOS as WebOS, Nokia’s attempt to reinvent its Symbian platform, Psion’s attempt to do it with its Psion OS, and Blackberry’s attempt with Blackberry 10 OS.
10.5.5.2 Recognize whether a platform is in a winner-takes-all or pie-splitting market
A platform owner must also recognize whether its market is a winner-takes-all market. In other words, whether it is possible for one platform to dominate or whether multiple platforms will coexist in the same market. One platform will dominate only when three conditions are simultaneously met (Eisenmann et al., 2006, 2011):
1. Multihoming costs must be high for both end-users and app developers. When multihoming costs are high only for end-users but low for app developers, multiple rival platforms can coexist. This by itself is a sufficient condition for the coexistence of multiple rival platforms.
2. Cross-side network effects must be positive and strong. When cross-side network effects are positive and strong, a single platform will dominate. End-consumers prefer a platform with many complements, and app developers prefer a platform with many users. This is the case in the mobile computing/smartphone markets, where end-users value the presence of a large number of app developers and vice versa. (Recall that same-side network effects in the absence of cross-side network effects are in one-sided systems (Skype, FaceTime), which are not platforms by our definition—they fail to meet the two-sided requirement.) Recognizing this property of your platform’s market also guides how pricing subsidies should evolve. If you followed penetration pricing to catalyze the creation of network effects (by accelerating critical mass generation, scale economies, or switching costs), should the subsidy be ended or made permanent for one side? Subsidies for early adopters are driven primarily to prime the pump to overcome a cold-start problem typical of network effects. A platform owner might profit more from permanently subsidizing one side if Red Queen competition persists.
3. End-users have low demand for hard-to-copy differentiated features from platforms (i.e., end-users’ needs are relatively homogenous). If the demand for differentiated features is high (i.e., end-user needs are diverse), multiple platforms can coexist.
If even one of these conditions is not met, multiple platforms will coexist and the platform is not in a winner-takes-all market. Rival platforms will remain substitutable in the minds of end-users, which guarantees that fierce competition will persist in the platform’s market. In the absence of a winner-takes-all market, a platform owner is better off specializing in tackling one segment of the broader market where its resources give it an edge over rivals. (Use the resource litmus test to assess this.)
10.5.6 Orchestrating platform mutation
Unlike envelopment, which expands a platform’s functionality, platform mutation creates a distinct derivative platform in a different application domain. Unlike envelopment, mutation does not require an overlap in users across the existing and mutation target market. Figure 10.21 illustrates the key differences between platform mutation and envelopment. The result of platform mutation is a serendipitous spinoff platform that inherits some of the properties of the parent platform but with a different purpose. Mutation is akin to exercising a growth option in real options lingo. Just as species can break out of competitive exclusion by diversifying, platforms can break out of the race to the bottom by diversifying into different markets where their existing assets give them some advantage over the incumbent rivals. A platform owner must first clearly articulate exactly how—using the resource litmus test—its assets can be a distinctive advantage in the target market.
FIGURE 10.21 Differences between platform mutation and platform envelopment.
Unlike envelopment, mutation often requires a break from the platform’s existing business model. Apple is a good example of mutation of a platform into the music industry. Perhaps bigger than the technology innovations that Apple brought to the mobile computing market were the business innovations that it introduced into the music business. Within a few years it transformed a company with zero market share into the world’s largest music retailer. Similarly, Amazon mutated its existing electronic retailing infrastructure into the software business by introducing AWS. In either case, the company leveraged a set of assets that were rare in the targeted industry and coupled it with a disruptive business model. Mutation in Apple’s case involved carryover of its existing end-users into the target market, but Amazon did not use a carryover strategy due to the lack of a distinctive overlap in the customer pools in its existing and mutation target markets.
The need for mutation is often created by fading markets in which a platform currently competes. These are signaled by a decrease in the growth rate of the platform’s core existing market, attrition of customers to rival platforms, and the emergence of commoditization of platforms in the post-dominant design phase of the platform market’s lifecycle. This often creates race-to-the-bottom price wars that make a platform’s industry a zero-profit business. To identify opportunities for mutation, a platform owner must look outside its existing core markets. Historically, in industries ranging from photography, lighting, glass making, and refrigeration, major disruptive competency-destroying innovations have come from industry outsiders, unlike competence-enhancing innovations that are as likely to come from insiders as they are from outsiders. Recall that nascent markets are plagued by a low signal-to-noise ratio and a platform owner can use all the help that it can get from its ecosystem to discern the signal behind a prospective mutation opportunity.
The key enabler for platform mutation is appropriate platform governance, particularly the partitioning of decision rights. The platform owner must centralize platform strategic decision rights to be able to act on mutation opportunities but also decentralize apps decision rights so that its app developers can act as its many outside eyes and ears to sense latent opportunities for the platform to mutate. Fortunately, the governance structures that enhance platform composability and durability are also conducive to platform mutation.
10.6 Lessons learned
• Adaptation drives survival of platforms. Platforms that survive in evolutionary competition are not the strongest, largest, or the cleverest but are the ones that are most adaptive to their environment. Rapid adaptation improves fitness with their changing environment.
• The bathtub theory of innovation. The net difference between innovation inflows that enter a platform's ecosystem and outflows that are copied by rivals is its stock of innovation that can potentially differentiate it. Growing the stock requires increasing the volume of inflows and curbing the outflows.
• The resource litmus test tells us what resources in the stock can competitively differentiate a platform from its rivals. A resource is any tangible asset such as a platform’s capabilities, functionality, user base, apps, and patents as well as its intangible resources. A resource must be valuable and rare to create a competitive advantage and inimitable and nonsubstitutable to sustain it. Few resources will simultaneously meet all these conditions. Therefore most resources create only a temporary advantage. Speed with which new resources are added then becomes the only reliable source of competitive advantage.
• OODA loops in the American military doctrine help accelerate platform evolution. Shortening the lag in each link in the Observe → Orient → Decide → Act loop accelerates evolution. This can be done by modularizing platform architecture to reduce lags in each loop and by using decentralized governance to create many concurrently executed loops.
• Three other ideas from Boyd's theory of dogfights apply to platform owners. These are a platform owner's need to emphasize what over how for app developers, maintaining an accurate grasp of reality through continuous interaction with the platform's competitive environment, and the emphasis on fast and frequent rather than perfect actions.
• Architecture–governance alignment drives evolution. Platform governance must be aligned with platform architecture. They are deeply interwoven and inseparably intertwined because they respectively supply ecosystem-wide motivation and ability to innovate around a platform.
• Orchestrating for resilience, scalability, and composability. In the short term, platform architecture–governance alignment shapes its resilience, scalability, and composability. Each of these properties require attention to different dimensions of platform governance.
• Orchestrating for stickiness, synergy, and plasticity. In the medium term, platform stickiness with both app developers and end-users is influenced by architecture and governance; its synergy with apps primarily by platform governance; and platform plasticity by platform architecture as well as architecture–governance alignment.
• Orchestrating platform envelopment, durability, and mutation. In the long term, envelopment by a platform as well as its capacity to rebuff envelopment attacks is influenced by platform governance, and platform durability as well as mutation by architecture–governance alignment.
In the next chapter, we turn our attention to the evolution of apps. Many of the ideas used in orchestrating platform evolution also apply to apps. We therefore focus primarily on ideas that are distinctive to evolving apps from an app developer’s perspective but apply less to platforms.
References
1. Argyres N, Bigelow L. Innovation, modularity, and vertical deintegration: evidence from the early US auto industry. Organ Sci. 2010;21(4):842–853.
2. Armstrong M, Wright J. Two-sided markets, competitive bottlenecks and exclusive contracts. Econ Theory. 2007;32(2):353–380.
3. Arthur B. The Nature of Technology. New York: Free Press; 2009.
4. Baldwin C. Where do transactions come from? Modularity, transactions, and the boundaries of firms. Ind Corp Change. 2008;17(1):155–195.
5. Baldwin C, Clark K. Design Rules: The Power of Modularity. Cambridge, MA: MIT Press; 2000.
6. Baldwin C, Woodard J. The architecture of platforms: a unified view. In: Gawer A, ed. Platforms, Markets and Innovation. Cheltenham, UK: Edward Elgar; 2009;:19–44.
7. Boudreau K. Open platform strategies and innovation: granting access vs devolving control. Manag Sci. 2010;56(10):1849–1872.
8. Bradach J, Eccles R. Price, authority, and trust: from ideal types to plural forms. Annu Rev Sociol. 1989;15(1):97–118.
9. Brusoni S, Prencipe A. Making design rules: a multidomain perspective. Organ Sci. 2006;17(2):179–189.
10. Burrows P. How apple feeds its army of app makers. BusinessWeek 2011;(June 13–19):39–40.
11. Coff RW. When competitive advantage doesn't lead to performance: the resource-based view and stakeholder bargaining power. Organ Sci. 1999;10(2):119–133.
12. de Weck O, Roos D, Magee C. Engineering Systems. Cambridge, MA: MIT Press; 2011.
13. Eick S, Graves T, Karr A, Marron J, Mockus A. Does code decay? Assessing evidence from change management data. IEEE Trans Softw Eng. 2001;27(1):1–12.
14. Eisenmann T, Parker G, van Alstyne M. Strategies for two-sided markets. Harv Bus Rev. 2006;84(10):1–10.
15. Eisenmann T, Parker G, Van Alstyne M. Platform envelopment. Strateg Manag J. 2011;32(12):1270–1285.
16. Ethiraj S, Levinthal D. Bounded rationality and the search for organizational architecture: an evolutionary perspective on the design of organizations and their evolvability. Adm Sci Q. 2004a;49(3):404–437.
17. Ethiraj S, Levinthal D. Modularity and innovation in complex systems. Manag Sci. 2004b;50(2):159–173.
18. Evans D, Schmalensee R. Catalyst Code. Boston, MA: Harvard Press; 2007.
19. Evans D, Hagiu A, Schmalensee R. Invisible Engines: How Software Platforms Drive Innovation and Transform Industries. Cambridge, MA: MIT Press; 2006.
20. Farrell J, Saloner G. Standardization, compatibility, and innovation. RAND J Econ. 1985;16(1):70–83.
21. Farrell J, Saloner G. Converters, compatibility, and the control of interfaces. J Ind Econ. 1992;XL(March):9–35.
22. Gamba A, Fusari N. Valuing modularity as a real option. Manag Sci. 2009;55(11):1877–1896.
23. Heller M. The Gridlock Economy: How Too Much Ownership Wrecks Markets, Stops Innovation, and Costs Lives. New York: Basic Books; 2008.
24. Iansiti M, Levien R. Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation, and Sustainability. Boston, MA: Harvard Business Press; 2004.
25. Kamel R. Effect of modularity on system evolution. IEEE Softw. 1987;(January):48–54.
26. Kim S, Mcfarland R, Kwon S, Son S, Griffith D. Understanding governance decisions in a partially integrated channel: a contingent alignment framework. J Market Res. 2011;48(3):603–616.
27. Langlois R, Garzarelli G. Of hackers and hairdressers: modularity and the organizational economics of open-source collaboration. Ind Innov. 2008;15(2):125–143.
28. MacCormack A, Rusnak J, Baldwin C. Exploring the structure of complex software designs: an empirical study of open source and proprietary code. Manag Sci. 2006;52(7):1015–1030.
29. Meadows D. Thinking in Systems. White River Junction, VT: Chelsea Green Publishing; 2008.
30. Messerschmitt D, Szyperski C. Software Ecosystem. Cambridge, MA: MIT Press; 2003.
31. Mezias JM, Mezias SJ. Resource partitioning, the founding of specialist firms, and innovation: the American feature film industry, 1912–1929. Organ Sci. 2000;11(3):306–322.
32. Moneverde K. Technical dialog as an incentive for vertical integration in the semiconductor industry. Manag Sci. 1995;41(10):1624–1638.
33. Penrose E. The Theory of the Growth of the Firm. Oxford: Basil Blackwell; 1959.
34. Pil F, Cohen C. Modularity: implications for imitation, innovation, and sustained advantage. Acad Manag Rev. 2006;31(4):995–1011.
35. Rohfls J. Bandwagon Effects in High-Technology Industries. Cambridge, MA: MIT Press; 2003.
36. Rysman M. The economics of two-sided markets. J Econ Perspect. 2009;23(3):125–143.
37. Sanchez R, Mahoney J. Modularity, flexibility, and knowledge management in product organization and design. Strateg Manag J. 1996;17(1):63–76.
38. Shy O. Economics of Network Industries. Cambridge, UK: Cambridge University Press; 2001.
39. Simon H. Near decomposability and the speed of evolution. Ind Corp Change. 2002;11(3):587–599.
40. Tiwana A. Does interfirm modularity complement ignorance? A field study of software outsourcing alliances. Strateg Manag J. 2008a;29(11):1241–1252.
41. Tiwana A. Does technological modularity substitute for control? A study of alliance performance in software outsourcing. Strateg Manag J. 2008b;29(7):769–780.
42. Tiwana A, Konsynski B. Complementarities between organizational IT architecture and governance structure. Inf Syst Res. 2010;21(2):288–304.
43. Tiwana A, Konsynski B, Bush A. Platform evolution: coevolution of architecture, governance, and environmental dynamics. Inf Syst Res. 2010;21(4):675–687.
44. van Schewick B. Internet Architecture and Innovation. Cambridge, MA: MIT Press; 2012.
45. Wernerfelt B. A resource-based view of the firm. Strateg Manag J. 1984;5:171–180.
46. Williamson P, De Meyer A. Ecosystem advantage: how to successfully harness the power of partners. Calif Manag Rev. 2012;55(1):24–46.
47. Zook C, Allen J. Growth outside the core. Harv Bus Rev. 2003;81(December):2–9.
*“To view the full reference list for the book, click here or see page 283.”
1This perspective, called the resource-based theory of competitive advantage (Coff, 1999; Mezias and Mezias, 2000; Wernerfelt, 1984), is based on Edith Penrose’s (1959) work in the 1950s that rose to prominence 40 years later.
2This includes adding new functionality to the platform via new APIs that is now widely used by apps but was not previously. Such stability in the platform enables the rapid evolution of the apps in the platform’s ecosystem, where the rate of change is higher and code reusability is lower. Stability of the platform translates a greater capacity to absorb high variety and experimentation in the apps that augment it.