Platform Ecosystems: Aligning Architecture, Governance, and Strategy (2014)

Part I. The Rise of Platforms

Chapter 2. Core Concepts and Principles

Abstract

This chapter introduces some core concepts and principles that we will subsequently use as a foundation for delving into platform architectures, governance, and evolution. Among the core concepts we first describe the notion of platform lifecycles, with three facets to characterize where a platform is in its lifecycle. The strategies for orchestrating the evolution of a platform ecosystem from a platform owner’s perspective and the app developers’ approach for managing their own work vary markedly depending on the platform’s stage in its lifecycle. We then describe the notions of multi-sidedness, network effects, multihoming, tipping, lock-in, and envelopment that will help us grasp how software platform ecosystems begin and evolve. We also briefly introduce the concepts of architecture and governance. We then describe nine principles guiding the initial development and subsequent evolution of platform ecosystems. The intent is to have a shared vocabulary.

Keywords

platform architecture; governance; evolution; red queen effect; dynamics; business ecosystems

Now, here, you see, it takes all the running you can do, to keep in the same place.

Red Queen to Alice in Lewis Carroll's Through the Looking-Glass

In This Chapter

• Core concepts

• Understanding platform lifecycles using dominant designs, S-curves, and diffusion curves

• Platform properties: multisidedness, network effects, multihoming, architecture, and governance

• Platform dynamics: tipping, lock-in, competitive durability, and envelopment

• Guiding principles

• Platform startup principles: the chicken-or-egg problem and the penguin problem

• Platform design principles: the seesaw problem, the Humpty Dumpty problem, and the mirroring principle

• Platform evolution principles: the Red Queen effect, emergence, the Goldilocks rule, and coevolution

2.1 Introduction

As a foundation for delving into platform architectures, governance, and evolution, this chapter introduces some core concepts and principles that we will subsequently build on. Among the core concepts, we first describe the notion of platform lifecycles with three facets to characterize where a platform is in its lifecycle. The strategies for orchestrating the evolution of a platform ecosystem from a platform owner’s perspective and the app developers’ approach for managing their own work varies markedly depending on the platform’s stage in its lifecycle. We then describe the notions of multisidedness, network effects, multihoming, tipping, lock-in, and envelopment that will help us grasp how software platform ecosystems begin and evolve. We also briefly introduce the concepts of architecture and governance that are the focus of the subsequent section of this book. We then describe nine principles guiding the initial development and subsequent evolution of platform ecosystems. The intent is for us to have a shared vocabulary that can serve as a foundation for the subsequent chapters of this book.

2.2 Core concepts

Platform ecosystems build on several fundamental ideas that must be grasped to understand how they are designed and how they evolved. These ideas make platform-centric businesses substantively different from most conventional business models and also from much of traditional software development. These foundational concepts are central to appreciating the ideas developed in the rest of the book. Because many of these concepts apply to platforms, apps, and ecosystems, we generically refer to all three in this chapter as technology solutions.

Table 2.1 briefly summarizes these concepts and identifies whether each of them is directly relevant to the platform, its apps, and the ecosystem as a whole.

Table 2.1

Core Concepts and Where They Directly Apply in Software Ecosystems

The first set of core concepts relate to the platform lifecycle, which is a multifaceted characterization of whether a technology solution is in its pre- or post-dominant design stage; its current stage along the S-curve; and the proportion of prospective users that have already adopted it (the diffusion curve). The next set includes the notion of multisidedness, which is a central property of a technology solution for it to qualify as a proper platform; the notion of network effects of various kinds that give most of the invincible properties such as lock-in that dominant platforms appear to possess; and the challenges associated with adopters who simultaneously commit to multiple rival platforms (multihoming). Finally, we briefly describe the notion of competitive durability and envelopment, and also provide a layperson’s introduction to the concepts of architecture and governance that the subsequent section of this book explores in depth.

2.2.1 The platform lifecycle

The lifecycle of most technology innovations has three parts: the emergence of the ideal technology solution itself, its progression along a technology maturity curve, and its penetration in its pool of prospective end-users. These lifecycle characterizations apply both to platforms and apps, so we generically refer to both as technology solutions in describing platform lifecycles. Figure 2.1 illustrates these three dimensions.

FIGURE 2.1 The three dimensions of the platform lifecycle.

2.2.1.1 Emergence of a dominant design

The emergence of the technology solution itself goes through two distinct phases, the shift between which is marked by the emergence of a so-called dominant design (Anderson and Tushman, 1990; Utterback, 1996). Figure 2.2 illustrates this. When a technology solution first emerges, multiple firms will enter the fray with competing alternative designs. In the early phases of a platform market, a variety of firms experiment with different types of features, capabilities, and designs to assess the market’s response. The predominant design phase is therefore marked by mass entry of competitors and multiple competing solutions to address the same market needs. As these competing designs continue to improve, at some point one design will eventually become widely accepted—implicitly or explicitly—as the winning standard. This happens when both customers and producers eventually arrive at some consensus about the optimal solution attributes that best meets customers’ needs out of all competing designs. This then becomes the industry’s dominant design and is usually associated with mass exit of competitors—a shakeout—from the market or switching over to the dominant design. The dominant design does not mean that every competitor will use the same technology per se but that it defines the expected norms for meeting users’ needs. The dominant design is often not necessarily the technologically superior solution. It also invariably involves compromises because it is designed to appeal to a broad range of users.

FIGURE 2.2 Pre- and post-dominant design phases in a software platform.

An example of the emergence of a dominant design in the smartphone platform market is the iPhone. Its design characteristics increasingly define industry norms for competing in that market: a touch-based interface, a baseline set of internal functions (email, browser, text messaging), the pocket-size form factor, software upgradability, and a virtual keyboard. Until a dominant design emerges, there is little consensus on the definition of an ideal solution for the same market and this remains the focus of competition among rival designs.

After a dominant design emerges, the few surviving competitors increasingly model their own solutions on the dominant design and compete by making incremental improvements on it. The emergence of iOS as the dominant design in 2010 led Google’s Android and Blackberry’s platforms to begin following Apple’s lead in their own competing platforms. The basis of competition shifted away from trying dramatically different approaches to meeting customer needs and instead on trying to improve on each other’s designs. However, these were simply variants of the same dominant design. In the post-emergence phase of the platform’s lifecycle, the focus also increasingly shifts toward price-based competition. The same dynamics have repeatedly occurred in the markets for almost every new category of applications for these platforms as they progressed from their inception to going mainstream. However, even after a dominant design emerges, many rival systems (platforms or apps) can persist without one clear winner. But they usually share strong commonalities with the dominant design. This can lead to legal problems that are particularly acute in software platforms vis-à-vis other technology industries, as dominant designs often define key elements of user interfaces’ look and feel and human–machine interactions that intellectual property laws cannot yet fully contend with. The majority of a platform’s adopters arrive after the emergence of a dominant design, where the technology adoption curve dramatically takes off.

The Rule of One

Why do platform industries settle on one dominant design instead of continuing to offer a variety of solutions? The primary reason is that many platform industries exhibit increasing returns to adoption (i.e., the more a technology is adopted, the more valuable it becomes). The more a dominant design is used, the more they are improved. Another reason is that as a dominant design is more widely adopted, more specialized complements (such as apps) emerge that are designed specifically to work with that dominant design. This results in a self-reinforcing feedback loop that makes the dominant design increasingly more dominant independent of whether the competing designs are technologically superior or inferior.

2.2.1.2 S-curves and leapfrogging

We can also analyze the phase of a technology solution’s lifecycle based on whether it is in (1) the introductory stage, which immediately follows its development and R&D stages; (2) the ascent stage, where it had reached breakeven and is beginning to gather steam; (3) the maturity stage; or (4) the decline phase, where it is becoming less useful than it used to be. This trajectory resembles an S-shaped curve (hence the term S-curve; Figure 2.3).

FIGURE 2.3 S-curves in the technology lifecycle.

As a technology solution crosses the mature phase and enters the decline phase, the focus of competition shifts from product innovation to process innovation (see Figure 2.4) (Adner and Levinthal, 2001). In other words, instead of trying to improve the solution itself, competitors shift their attention to improving how it is produced and how it is delivered. Participants in platform markets must remember what causes the decline phase to set in and what can be done about it. It is usually because of a competing technology solution that at least does what the preceding technology solution did, but better or cheaper.

FIGURE 2.4 Process innovation replaces product innovation as a technology solution matures.

The death march of most technology solutions begins at the outset of the decline phase of the S-curve. The ideal choice for the incumbent technology—and for those who depend on it for their bread-and-butter—is to “leapfrog” to the next S-curve. This means embracing the disruptive technology solution and using it as the foundation over the incumbent technology solution for its product or service offering in the marketplace. Most firms that attempt it fail miserably. Their entire businesses are based on the outgoing technology, and they have usually invested sweat and tears into honing their business models and capabilities around it. It is therefore difficult for incumbents to rationalize walking away from it and switching to what might appear to be a fledgling technology solution with uncertain prospects.

Think of how Kodak first responded when its chemical photography business was threatened by digital photography; Remington typewriters when word processors were first introduced; traditional book publishers when e-books first emerged; the Pony Express when the telegraph was invented; and Canon’s successful digital cameras when smartphones threatened the business. Perhaps recalling the story of Minnesota’s flourishing ice harvesting industry (see the sidebar and Figure 2.5) will help you remember the point that this, unfortunately, is a mistake that gets repeated, forgotten, and repeated over and over again. Figure 2.5 illustrates how the ice harvesting industry reacted in the 1800s to the emergence of the refrigerator. The pattern can readily be applied to many recent replacement technology solutions such as e-books vis-à-vis books, digital music distribution vis-à-vis CDs, and voice-over-Internet vis-à-vis telephones. The first reaction from the incumbent firm is to ignore the potentially threatening alternative technology, then to dismiss it as irrelevant and low quality, then ferociously engage in process innovation to deliver the existing technology more cost effectively, then to price cut aggressively, and finally to give up (Figure 2.6).

The Parable of the Minnesota Ice Harvesting Industry

Waseca, Minnesota, was flourishing in 1809. Three in four residents were prosperous ice harvesters. This town, like many others in Minnesota, Wisconsin, and New England, had a burgeoning industry harvesting blocks of ice from deep frozen lakes to ship not just to meat-packing plants and breweries in New Orleans but also to customers in China, South America, and Western Europe. A milestone was when a hundred tons of ice survived a 16,000-mile journey to Calcutta, India. By 1900, the ice harvesters could barely whet the global appetite for ice, which had an annual market for 10 million tons in the United States alone.

By 1928, the entire industry vanished without a trace. The culprit was Apalachicola, Florida-based physician John Gorrie’s 1850 invention, an artificial gas-compression ice machine that blended together a neglected 1834 British patent for artificial vaporization and a technique developed 2 years earlier by Ferdinand Carre for processing water into ice using ammonia. As the disruptive threat of an artificial ice machine loomed larger, the ice harvesters did precisely what the US auto industry tried after 1991 and the US airline industry after 2001: They systematically attempted to improve what they did best. Better ice-cutting saws, better-insulated storage sheds, more efficient distribution, and lower prices. But squeezing more efficiency out of a leapfrogged business model mattered little.

The death knell of the Waseca ice harvester was not someone who could do it better, but differently. Neither was it a breakthrough innovation. Instead, it was a novel assemblage of existing technologies that simply rendered the traditional business model irrelevant. Parallels can easily be drawn in many flourishing industries today. Some react like the ice harvesters but far too many are too dismissive of individual emerging technologies. But miss the forest for the trees, and it’s hard to be prepared when you don’t know what you’re watching out for. The lesson for managers from the parable of the ice harvesters is to continuously connect the dots even when there aren’t enough dots yet; imagine possible assemblages of existing and emerging technologies, no matter how far-fetched.

To keep from becoming the next ice harvester parable, managers must fear most someone who pieces together seemingly unrelated innovations to introduce a different way to satisfy existing market needs, not someone who just does it better, faster, or cheaper. The fatal disruptive threat is rarely a single innovation or technology but a novel reconfiguration of existing technologies that entirely circumvents the industry’s dominant business model. Rather than letting their fears of cannibalizing existing business overpower the need to actively seek and invest in real options on even absurdly peripheral innovations, managers must constantly imagine ways to cannibalize it. When business is good, humble managers must not forget the ice harvesters. The ones that are condemned to repeat history are the ones that forget it.

FIGURE 2.5 Ice harvesters, circa 1889. Source: Sketch by Joseph Becker in Frank Leslie's illustrated newspaper, March 16, 1889, p. 96; reproduced from the Library of Congress wood engraving LC-USZ62-104051. Digitized by Library of Congress at www.loc.gov/pictures/item/91787147.

FIGURE 2.6 How incumbent technology solutions react to potential replacement technologies.

However, it is possible to make the leap using “real options” thinking before the next S-curve fully takes shape. (Chapter 8 focuses on real options theory.) Leaping from one S-curve to the next requires embedding different types of real options in architectures, envelopment of adjacent markets, shifting focal target markets, and using the six modular operators. This requires thinking of architecture in software platforms and their governance. These tools are described in detail in Part IV of this book, where the termleapfrogging is used to refer to this idea of jumping across successive S-curves.

2.2.1.3 The technology diffusion curve on the end-user side

The adoption lifecycle of a technology solution by its end-users can be described using Rogers’s (1995) diffusion curve, just as dominant designs and S-curves describe lifecycles on the supplier side. As Figure 2.7 illustrates, the diffusion of a technology solution begins with a very small minority that adopts it for technology’s sake more than its widespread utility. These are the geeks and influencers who get it off the ground. The geeks are followed by a wave of early adopters, who add up to about a sixth of the total potential user base. This is where the technology innovation hits what Geoffrey Moore calls “the chasm.” Only after this chasm is crossed does the first big wave of early adopters and then the next big wave of late adopters arrive. At this point, 85% of the potential adopters are on board. The last sixth of the eventual user base are the laggards. Since platforms have at least two distinct groups of adopters, this model can be used to describe adoption of a platform both by end-users and by app developers. In managing the evolution of a technology lifecycle, different evolutionary properties should be the focus of attention, depending on which of the five phases of the diffusion curve a technology solution is in. Similarly, the emphasis of governance also must shift to match a technology solution’s progression along the diffusion curve. The diffusion curve will therefore resurface when we subsequently delve into governance and evolution.

FIGURE 2.7 The technology diffusion lifecycle on the end-user side.

2.2.2 Multisidedness

A key property of platforms is their multisidedness, where each “side” refers to a distinct group of stakeholders that the platform brings together. For example, the iOS platform brings together app developers (one side) and end users (the other side). These two sides would ordinarily face much higher costs in finding and transacting with each other without the platform than with it. The platform creates value by facilitating participants on one side finding those on the other side, or mediating their interactions. Figure 2.8illustrates this. In theory, both sides can find and trade with each other directly and without the platform, and this must be costlier for a platform to be viable. The platform is therefore valuable to either side when interacting. Like platforms, apps can also evolve into standalone platforms or platforms within another platform (nested platforms) by evolving them to become multisided.

FIGURE 2.8 Two sides in a multisided platform.

Multisided markets have long existed outside of the technology industries.

Table 2.1 provides examples of such markets, where a firm acts as a market-maker that facilitates interactions between two distinct groups that need each other but would find it costlier to find and then transact with each other. A software platform can act as a market-maker between two such sides, but brings unique capabilities and opportunities that rarely exist outside of software-based platform markets. A software platform is multisided if two or more distinct types of participant groups use the platform to directlyinteract with each other. These distinct groups want to interact with each other but need the platform to be able to. Most multisided platforms are two-sided. For example, app developers and end-users are the two sides in iOS’s app store platform. Similarly, third-party sellers and customers directly interact with each other on Amazon, and buyers and sellers on eBay.

It is important not to confuse one-sided services with multisided ones; we do not even consider one-sided platforms as true platforms. Rather, they are services that have the potential to evolve into a multisided platform. For example, the file-sharing service Dropbox primarily has one distinct participant group, its end-users. They do not directly interact with another distinct participant group on the other side, just with other users of Dropbox. In contrast, two distinct groups of participants exist in day-to-day two-sided networks such as credit cards (cardholders and merchants), video gaming (gamers and game producers), and movie theaters (studios and moviegoers). Three-sided platforms are also becoming more prevalent. (See Table 2.2 for examples outside the software industry.) For example, Apple increasingly connects three distinct types of groups with the free apps distributed in the iOS App Store: end-users, app developers, and advertisers. Multisidedness is therefore a critical requirement for the more sophisticated platform dynamics to arise.

How Many Sides to Begin With?

A difficult question that a startup platform usually faces is how many sides it should try to attract at the outset and which side it should subsidize to reach critical mass. Although it might appear on first glance that attracting as many sides as possible is a good strategy, upstart platform owners must be cautious for two reasons. First, attempting to attract many sides at the same time can spread the platform owner thin and keep it from dedicating enough resources to solve the chicken-or-egg problem of getting both sides onboard. It is easier to solve that problem by starting with fewer sides, usually just one. (The various strategies for doing this are discussed in Chapter 4.) Second, it can accidentally trigger negative network effects instead of positive ones, or a deadly mix of both where the negative network effects overwhelm the positive ones.

Table 2.2

Examples of Multisided Market Makers Outside the Software Industry

2.2.3 Network effects

Network effects refer to the degree to which every additional user of a platform or app makes it more valuable to every other existing user. Economists call these network externalities (Katz and Shapiro, 1994; Saloner and Shepard, 1995) or Metcalfe's law. Consider the very first user of Facebook. The value of Facebook to her was zero since there was no other user to network with. The second user increased the value of Facebook to the first user. The millionth user dramatically increased the value of Facebook to herself and to every other user before her. This means that the value of adding another user to a platform dramatically increases its potential value to every other user. The logic is simple: Every additional user dramatically increases the number of other users that he or she can interact with. For example, Facebook’s billion users make it much more attractive for the next user after them to join Facebook, illustrated in Figure 2.9. The value of the system increases almost exponentially rather than linearly (as the square of the number of users or number of users times their logarithm, depending on which version of Metcalfe's law one considers); thus each additional user potentially increases the value of the system to other users dramatically rather than gradually (Figure 2.10). Once such network effects are triggered, the platform can enter a self-reinforcing cycle. While network effects create high barriers to entry into platform markets, they also create a hard-to-assail position once they are in place.

FIGURE 2.9 Networks effects leverage the number of users that any user can communicate with.

FIGURE 2.10 Network effects exponentially increase the platform’s value.

Although network effects in commonplace usage of the concept refer to positive network effects, there are two more nuanced properties of network effects: direction and sidedness. Direction can be positive or negative. Unlike the positive network effects just described, a negative network effect exists when every additional user of a system makes it less valuable to other users. Think of a highway: Every additional driver on the highway potentially makes it more difficult for other drivers to navigate speedily through the traffic, thus decreasing its appeal to existing drivers. Similarly, every additional user on a cable Internet network in your neighborhood potentially reduces the bandwidth available to you, reducing its value from your perspective. It is possible for a platform to simultaneously exhibit negative and positive network effects after it reaches a threshold user base. Ensuring that the net of these is still positive requires careful attention to architecture (Chapter 5) much before this conflict is noticeably manifested.

The second property of network effects is whether they are same-side or cross-side (see Figure 2.11). Same-side network effects arise when adding an additional participant (e.g., end-user) to one side of the platform changes its value to all other participants on the same side. For example, adding an additional Skype user increases its value to other Skype users (a positive same-side network effect); adding another driver to a busy highway decreases its appeal to other users (a negative, same-side network effect). Cross-sidenetwork effects arise when adding an additional participant (e.g., end-user) to one side of the platform increases or decreases its value to all other participants on the other side. For example, the more people buy iPads, the more developers want to write apps for iPads. This is a positive cross-side network effect.

FIGURE 2.11 Same-side versus cross-side network effects.

Each combination of direction and sidedness of network effects can put a platform in one of four cells in Figure 2.12. As we will see in subsequent chapters, the nature and direction of network effects has a lot to do with the underlying architecture of the platform and the way in which it is governed. In other words, network effects can thoughtfully be designed into a platform, and this has powerful strategic consequences as a platform evolves. Architecture and governance can be mutually reinforcing or mutually destructive. Together, their effects—both good and bad—can exceed the sum of their parts. A well-designed platform should deliberately harness this interaction in the evolution of its ecosystem.

FIGURE 2.12 Four types of network effects in platforms.

Network effects of a second kind arise when the demand for one platform complement with strong network effects increases the demand for the platform itself. Independent of whether the positive network effects are same-side or cross-side at the platform level or even at the app level, the platform stands to gain from them. For example, the presence on a platform of a popular app with strong network effects (e.g., Skype) increases the demand for the platform as well (e.g., iOS devices).

2.2.4 Multihoming

The simplest example of multihoming is likely in your wallet. You likely have more than one credit card, perhaps an American Express and a Visa. Yet you likely use one predominantly and keep the other as a backup. In this example, you are multihoming across two rival platforms. Multihoming in platforms refers to when a platform participant on either side participates in more than one platform ecosystem (Armstrong, 2006; Armstrong and Wright, 2007). An app developer who simultaneously develops her app for Android and iOS is multihoming on those platforms. An end-user who owns both a Blackberry and an iPhone is similarly multihoming on these platforms. An adopter can multihome in ownership, usage, or both. The software industry has historically relied on exclusivity contracts and intentional incompatibility to coerce developers to single-home. However, intense market competition, particularly in platform markets where a clear winner is yet to emerge, increases the likelihood that developers will multihome. It is also a rational approach because they can place their bets on multiple competing platforms and avoid the downsides of being stranded on a losing platform. For end-users, the ongoing costs of establishing and maintaining multiple platform affiliations is usually a deterrent to multihoming. The higher these costs, the lower the likelihood that an app developer or end-user will multihome. Platform owners can discourage multihoming by decreasing the costs of homing on their platform vis-à-vis rival platforms. The costs of multihoming are therefore distinct from switching costs associated with platform lock-ins. How can platform owners cope with the reality of multihoming yet differentiate their platform from its rivals? When should a platform owner or app developer aggressively deter multihoming and when should he or she encourage it? The answer lies in how platform governance is matched with platform lifecycles, which we discuss in detail in Chapter 6.

2.2.5 Tipping

Network effects kick in only after a minimum number of users have adopted the technology solution. This minimum number of adopters after which network effects are manifested is known as the platform’s critical mass or tipping point. Once a platform reaches this critical mass, network effects become noticeable and a potentially self-reinforcing positive feedback loop. For new platforms, reaching this critical mass with the first distinct side of adopters is perhaps the biggest hurdle that platform owners face. For existing platforms, harnessing them to nudge the platform’s evolutionary trajectory is the key challenge. Therefore a platform requires vastly different strategies before and after it reaches a tipping point.

2.2.6 Lock-in

Achieving critical mass introduces a different set of challenges for platforms: Competing platforms now know for sure that there is viable market. A successful platform is therefore likely to face intense competition both from copycat platforms as well as truly differentiated platforms. While this competition increases the variety of alternatives available to consumers and is usually good for consumers, it can often create conditions of a zero profit industry for platform owners and app developers. Severe price competition means that pricing of rival platforms can devolve into a race to the bottom. The challenge then is retaining both users and app developers who might be tempted to switch to a competing platform. The ways in which a platform can make it more desirable for existing users to stay put and not jump ship to a rival platform broadly refers to lock-in. Lock-in can occur both in consumer-grade platforms (e.g., iOS, Android) and in enterprise-grade platforms (e.g., SAP, Peoplesoft).

Lock-in can either be coercive or value-driven. Although lock-in often carries a negative connotation, evoking images of a powerful platform owner making it costly or impossible for existing users to switch to a competing platform (e.g., Monteverde and Teece, 1982), that heavy-handed approach eventually fails. Coercive lock-in, as we subsequently describe, is potentially breakable (using technologies such as middleware, adapters, and protocol translators). This approach relies on creating high switching costs: Costs associated with terminating the existing use of a technology solution to migrate to a rival one. An alternative way of creating lock-in is by making the platform increasingly more valuable to its users so that the choice to switch to a competing platform simply becomes unappealing vis-à-vis staying with the incumbent platform. The strategies for creating such platform lock-ins are potentially more bountiful in software-based platforms relative to nonsoftware platforms. The effective strategies for value-driven lock-in that platform owners can use over end-users and over app developers also vary based on the stage of the platform’s lifecycle, as we describe in Part IV of this book.

2.2.7 Competitive durability

A technology solution is competitively durable when its adopters continue to use it long after the initial adoption (Tiwana et al., 2010). For example, the majority of apps see intensive usage after their initial adoption but eventually decline in their usage. In contrast, a competitively durable app continues to be regularly used. Usage (e.g., hours per week), nonabandonment (a stable or increasing usage pattern after initial adoption), and the ratio of regular users to adopters are proxies for competitive durability at the app level. Maintaining competitive durability usually requires making a technology solution sticky by strengthening network effects or aggressively adding functionality that its users value.

2.2.8 Envelopment

When a platform begins to offer the functionality of another platform in an adjacent market in addition to its existing bundle of functionality, it is said to have enveloped—or swallowed—the latter (Eisenmann et al., 2006). Figure 2.13 illustrates envelopment. For example, the iOS platform successfully added gaming functionality to its platform, effectively swallowing the functionality of hand-held gaming platforms such as Nintendo DS and Sony’s Playstation Vita. Similarly, by adding digital photography capabilities, smartphones have enveloped the adjacent digital camera market. Envelopment is usually viable when the two adjacent platforms have a considerable overlap in their user bases, and when the enveloping platform offers a bundle of functionality that is perceived as being a better value proposition by end-users of the enveloped platform. We subsequently describe strategies for how a platform facing a threat of envelopment can respond. Envelopment is a distinct concept from convergence; envelopment latter occurs at the platform or app level and convergence former across industries.

FIGURE 2.13 Envelopment of one platform (B) by a platform (A) in an adjacent market.

2.2.9 Architecture

Architecture is the conceptual blueprint that describes the structure of a technology solution. Architecture describes the components of a complex system, what they do, and how they interact (van Schewick, 2012, p. 21). This high-level description specifies the components of a system, the externally visible properties of these components, and the relationships among them (Sanchez, 1995; van Schewick, 2012, p. 21). The architecture of a platform or an app is therefore a high-level description of its building blocks and how they are related to each other, not a working implementation. Broadly, architectures can vary between the two extremes of being perfectly modular (plug-and-play) and perfectly monolithic. Most architectures fall somewhere along this continuum.

Architectures are a defining property of individual apps and how they interact with other apps and the platform (Tiwana et al., 2010). They are also a defining property of the platform itself. The architectural properties of the apps in a platform’s ecosystem and of the platform aggregate to describe the overall architecture of a platform’s ecosystem. Most architectural decisions by ecosystem participants are therefore made at the app and platform level rather than the ecosystem level. Architecture imprints the evolution of a platform ecosystem because it defines how innovation work is partitioned among the app developers and the platform owner and also how their outputs are reintegrated into a coherent whole. Architectures therefore reduce complexity that any ecosystem participant must contend with, and allows them to benefit from valuable ignorance of each other’s work without compromising ecosystem-wide integration. The evolvable architectures that this book emphasizes are Lego-like modular architectures. Architectures are largely technical decisions with enormous strategic consequences. Their technical nature and strategic implications make them especially messy for technologists and managers because they span both realms, of which one is usually outside the domain of expertise of either type of individuals. Architectural choices are also largely irreversible in practice, and the constraints imposed by them become apparent long after such choices have been made. Technical architectures are inseparably intertwined with governance of the platform ecosystems, which is often also described as its business architecture.

2.2.10 Governance

Governance broadly refers to who decides what in a platform’s ecosystem. This encompasses three facets: (1) how decision rights are divvied up between the platform owner and app developers, (2) what types of formal and informal control mechanisms are used by the platform owner (e.g., gatekeeping, performance metrics, processes that app developers are expected to follow, and informal clannish pressure), and (3) pricing structures, including decisions about which side gets subsidized. (Chapter 6 focuses on governance.) Governance impacts the evolutionary dynamics in platform ecosystems, and the competitive advantage generated by governance choices can strengthen or diminish with the choice of architecture for the platform (Chapter 10) and for apps (Chapter 11).

2.3 Guiding principles

Nine guiding principles underpin the emergence and evolution of platform ecosystems. The first four are related to the initial development of platform ecosystems. These include the idea that a platform ecosystem must evolve at least as rapidly as its rivals in order to survive (the Red Queen effect); it must simultaneously attract two distinct groups to the platform but neither will join unless a critical mass exists on the other side (the chicken-or-egg problem); uncertainty about whether other users on either side will adopt a platform can stall initial adoption altogether (the penguin problem); and the majority of innovations in such platforms cannot be planned but instead spontaneously emerge from relentless pursuit of selfish interests by various ecosystem participants (emergence). The next set of principles relate to how a platform ecosystem can be orchestrated to evolve. These include the idea that a platform owner must strike a delicate balance between autonomy granted to app developers and the integration of their work with the platform (theseesaw problem); the platform ecosystem must be designed so its parts can be separated for independent development and then seamlessly reintegrated (the Humpty Dumpty problem). However, this requires the organizational structure of the platform’s ecosystem to mirror its architecture down to the app level (the mirroring principle); and its governance and architecture must be codesigned and coevolved (coevolution). The final principle is to always offer a set of three ordered choices at the app level, with the expectation that the majority of users will gravitate toward the middle choice that appears “just right” (the Goldilocks rule). These guiding principles are summarized in Table 2.3 and described next.

Table 2.3

Summary of the Nine Guiding Principles in Platform Markets

2.3.1 The Red Queen effect

The Red Queen effect, referring to the increased pressure to adapt faster just to survive, is driven by an increase in the evolutionary pace of rival technology solutions (Barnett and Hansen, 1996). It is an evolutionary idea to explain the coevolution of competing platforms and the demise of ones that do not adapt fast enough relative to rivals. It is based on the anecdote in Lewis Carroll’s Through the Looking-Glass, where two characters (Alice and the Red Queen; Figure 2.14) were constantly running yet remaining in the same place relative to each other. In platform markets, this means that in order to survive, a technology solution must evolve faster just to match the rate at which competing solutions are evolving. If the pace of adaptation of one competing solution increases, it puts much greater pressure for its rivals to increase their pace of adaption just to remain in the game. The consequence of the Red Queen effect is that the harder a rival platform tries to get ahead of the dominant platform, the further behind it appears to fall. It is easy to miss the nuance that the bar itself is rising. Intensification of a rival platform’s efforts to get ahead of others leads to intensification of effort by rivals, gradually raising the bar for them all. (This behavior is also called escalation in systems thinking; Meadows, 2008, p. 124.)

FIGURE 2.14 Alice (middle) and the Red Queen (left). Source: Charles Sylvester, Journeys Through Bookland, Bellows-Reeve Company, Chicago, 1909.

2.3.2 The chicken-or-egg problem

A platform cannot attract app developers unless it has a large base of end-users, and a large base of users is unlikely to join unless a platform has a large variety of apps available that end-users perceive as valuable. Neither side will join the platform without the other. This dilemma that neither side will find a platform or app with network effects potentially attractive enough to join without a large presence of the other side is the chicken-or-egg problem (Caillaud and Jullien, 2003). Consider why either side will find it more attractive only after a large adopter base has formed on the other side of a platform. End-users derive a large part of their value of a platform from the apps that they can use on it. This means that the absence of available apps will decrease the perceived attractiveness of a platform. The reason app developers are going to perceive a platform as valuable only if it has a large installed base of end-users is simple: An app has large upfront fixed costs but low variable costs. Producing the first copy can be a costly endeavor, but making additional copies is almost costless. Therefore, app developers can realize considerable economies of scale only if they can reach a large number of adopters/users. Not addressing the chicken-or-egg problem is guaranteed to break a platform even before it has a chance of taking off.

2.3.3 The penguin problem

The “penguin problem” arises when a new platform is introduced that has strong potential for network effects, but no end-users adopt it because they are unsure whether others will adopt it as well (Farrell and Saloner, 1986). Early adopters who buy into the promise of strong network effects might be stuck with a dud investment if a critical mass of other users does not follow. This waiting game can potentially stall a critical mass of users from adopting an otherwise promising platform. The metaphor is based on a group of hungry penguins waiting for each other to dive into waters where they know they can find food, but are unsure about whether there is also a predator lurking. The lingering doubt in a penguin’s mind is whether jumping in for food is worth becoming someone else’s food! This excessive inertia is also the flip side of excess momentum, where some early users adopting a new platform lead a disproportionately large number of others to adopt the same platform. Economists also call this the “bandwagon effect” (Rohfls, 2003, p. 195). The penguin problem is partly why a superior platform that cannot break the adoption inertia barrier often loses out to an inferior platform that does overcome the problem. The penguin problem is particularly acute when the prospective user base for a new platform is the installed base for an existing—perhaps inferior—platform (Farrell and Saloner, 1986). It is less acute for a new platform that needs to attract new users but does have a potentially rivalrous older technology solution that it indirectly competes with. Overcoming the penguin problem requires careful attention to governance, particularly which side the platform owner subsidizes in pricing to break the logjam. A second approach that we discuss subsequently is one of strategically vacillating between compatibility and incompatibility with potentially rival solutions (platforms, apps, or ecosystems) over different phases of their lifecycle.

2.3.4 Emergence

Emergence is a self-organizing, ecosystem-wide order that arises not from the imposition of a master plan by the platform owner but from the actions of interdependent app developers and platform owners who are selfishly pursuing their own interests based on their own expertise but continuously adapting to feedback based on what the others in the ecosystem are doing (Dougherty and Dunne, 2011). Emergent properties of a technology solution are those that arise spontaneously in response to the aggregate behavior of apps within the ecosystem or are triggered by technological or regulatory changes in the environment (as described in Part IV of this book). Emergent innovations that advance the platform ecosystem will not arise unless emergence is enabled and shaped effectively by platform owners (Dougherty and Dunne, 2011). Because emergence cannot be predicted and planned, the best the platform owner can do is to not quash it. Platform owners can shape emergence primarily by providing a guiding vision and by facilitating coordination (which is messier than it appears on first glance), but then getting out of the way. In other words, the big picture goals for “what” app developers should accomplish can be set to some degree by the platform owner, but not how they are accomplished.

2.3.5 The seesaw problem

The biggest strength of a platform ecosystem—its diversity—can also be the root of chaos. Apps must seamlessly integrate and interoperate with the platform, but the very things conducive to app–platform integration can also be intrusive to the autonomy of app developers in ways that discourage emergent innovation around the platform. Too much autonomy can compromise integration; overemphasis on integration can compromise app developers’ autonomy (see Figure 2.15). The key challenge for platform owners is therefore to manage the delicate tension between developer autonomy on one hand and ecosystem-wide integration on the other. A platform that thrives will neither be like a democracy nor a centrally planned regime. Instead, it must be like a benevolent dictatorship, as Chapter 6 elaborates. Managing this delicate balance between autonomy and integration is what we refer to as the seesaw problem. The seesaw problem can be managed by aligning architecture and governance at the app level.

FIGURE 2.15 The platform owner must manage the delicate balance between app developers’ autonomy and app–platform integration.

2.3.6 The Humpty Dumpty problem

The Humpty Dumpty problem is one where separating an app from its platform in order to upgrade can make it difficult to put them back together again. The term originates from the eighteenth-century riddle of Humpty Dumpty, who broke after a fall and no one could figure out how to put him together again (Figure 2.16).

FIGURE 2.16 The Humpty Dumpty problem originates in the fable of the character who broke and no one could put him back together again. Source: The Editorial Board of the University Society, Boys and Girls Bookshelf, The University Society, New York, 1920.

Subsystems within complex software systems composed of many such subsystems often have intricate dependencies among each other (Simon, 1962). This means that a change in one app can potentially have a ripple effect on the platform or other apps. Similarly, a small change in the platform can have a ripple effect that can break previously functioning apps (Tiwana et al., 2010). This is like a domino effect—a chain reaction—where one change in a part of the ecosystem can cause other elements of it to behave unpredictably in ways that cannot be anticipated. The sole responsibility of managing the Humpty Dumpty problem lies in software architecture (Chapter 5), both at the platform level and at the app level.

A well-designed platform ecosystem should ideally be like a set of Lego blocks. Lego blocks come in all shapes and sizes, with just one thing in common: their connection points (see Figure 2.17). As long as a Lego block obeys the size and placement of the connection points between blocks, its shape and size do not matter and each individual block can be assured that it will fit with just about any imaginable mix of other Lego blocks. This allows complex structures to be composed from simple collections of Lego blocks. In software platforms, the aspiration to be Lego-like means that it should be possible for an app developer to:

• Readily separate an app from the platform

• Independently update, revise, refine, and extend the app without needing to directly interact with the platform owner or other app developers

• Readily plug the revised app back into the platform and be confident that it will interoperate

FIGURE 2.17 The Humpty Dumpty problem is solved through Lego-like software platform architectures.

By the same token, it should be possible for the platform owner to make any changes internal to the platform without having to ask, interact, or coordinate with app developers. Lego-like architectures are what we call modular architectures, which is the focus ofChapter 5.

2.3.7 The mirroring principle

The mirroring principle is an idea used to align governance and architecture in modular complex systems. The crux of the mirroring principle is that the organizational structure of a platform’s ecosystem must mirror its architecture (Hoetker, 2006; Sanchez and Mahoney, 1996). This means that the way in which a platform is governed and the way in which it is architected must be mirror images of each other in order to be mutually reinforcing. If apps are loosely coupled with the platform, their developers must have considerable autonomy from the platform owner. If they are tightly integrated with the platform, the platform owner and app developers should be tightly integrated in their work as well. Figure 2.18 illustrates the idea. We develop this idea in depth in Chapters 10and 11, after we delve into architecture and governance in Chapters 5 and 6.

FIGURE 2.18 The mirroring principle.

2.3.8 Coevolution

The viable governance strategies for platform ecosystems are bounded by their architecture, and the evolvability of architectures can be accentuated or attenuated by how they are governed. If the two are codesigned, they can be mutually reinforcing in ways that exceed the evolutionary advantages that either an evolvable architecture or good governance can provide in isolation (Tiwana and Konsynski, 2010). This book therefore emphasizes the importance of aligning the technical architecture of a technology solution with its governance. The subsequent chapters develop the idea that architecture and governance work as two gears of the motor of ecosystem evolution, which must be aligned with each other (Figure 2.19).

FIGURE 2.19 Architecture and governance are the two gears of evolution of a platform ecosystem.

However, such alignment is not a one-time activity. Rather, as the competitive environment of a technology solution changes, its user base expands or contracts, or emerging technology innovations require tweaking either architecture or governance, the other also needs to be adapted to maintain their initial alignment. Our premise is that the architectures of complex systems influence and are influenced by the economic systems in which complex systems are designed, evolved, and consumed. We refer to this notion of evolving architecture and governance of a technology together as coevolution (Tiwana et al., 2010). Parts III and IV of this book delve into the evolutionary consequences of such coevolution of architecture and governance for platforms and their apps.

2.3.9 The Goldilocks rule

The Goldilocks rule is the idea that given any three ordered choices, humans will gravitate toward the middle over the two extreme choices. (The Goldilocks label originates from the 1837 fairy tale (Figure 2.20) by Robert Southey in which the central character Goldilocks enters the home of three bears. Feeling sleepy, she rejects one bed because it was too big, a second one because it was too small, and chooses the third one because it was “just right.”)

FIGURE 2.20 Goldilocks and the Three Bears is a lesson in how we gravitate toward the middle choice, which we often view as “just right.” Source: Arthur Mee and Holland Thompson, The Book of Knowledge, The Grolier Society, New York, 1912.

Starbucks, for example, offers three choices for most drink sizes with the expectation that customers will (and often do) pick the middle one. The two extremes are perceived either too small or too big, with the middle one “just right.” The two extreme choices in this ordered set of three choices therefore serve primarily to nudge a customer toward the intended middle choice. If the middle option is priced to generate the highest profit, the anchoring effect of the other two extreme options can be sufficiently strong in nudging customers toward the middle, which can be priced to sell at a lower profit margin yet generate the highest aggregate revenue and profits. The bottom line is to be able to use this strategy to sell a greater volume of the middle option. As a corollary, offering more than three versions is suboptimal because choice clutter creates confusion. There are therefore diminishing returns in offering too much choice (Evans and Schmalensee, 2007, p. 33). This rule can be used to version apps and platforms. For example, instead of offering a free version and a paid version of an app, an app developer might generate higher aggregate margins by offering three versions using a variety of versioning criteria, described in detail in Chapter 11.

2.4 Lessons learned

Software platform ecosystems must be orchestrated rather than managed. This is because their strength is the diversity of external innovators; but their work must also be integrated with the platform if the advantages of this diversity are to be realized in practice. Some of the underlying principles and concepts are unusual enough both for managers and for software developers that it is important for us to be on the same page about what they mean throughout the book. We generically used the term technology solution to refer to both platforms and apps because many of the ideas apply to both, and some to the entire ecosystem (Table 2.1). A brief summary of the core ideas described in this chapter appears below.

• Strategies that are appropriate for managing platforms and apps vary with where they are in the evolutionary lifecycle. The lifecycle of a technology solution is a three-dimensional property that encompasses whether it is in the pre- or post-dominant design stage, where it falls in the technology maturity trajectory (the S-curve), and what proportion of the total prospective user base has already adopted it.

• Software platforms have intrinsically different properties compared to other types of platforms. Their multisidedness offers fertile opportunities to create both same-side and cross-side network effects, lock-ins that can be both coercive and value-driven, and the prospects of swallowing adjacent platforms as well as the dangers of being swallowed by one.

• Architectures of technology solutions provide the blueprint for mass coordination. The conventional coordination and control mechanisms that work well in conventional organizations and supply chains are prohibitively costly and implausible to use in large ecosystems. Architecture instead provides the blueprint for both partitioning innovation work across the many participants in a platform ecosystem and for integrating it.

• Governance can amplify or diminish the advantages of good architecture. Governance and architecture must be codesigned and coevolved because they act as the two gears of a platform’s evolutionary motor. A misfit between the two can lead to evolutionary penalties and the eventual demise of a previously successful technology solution.

• Evolutionary pace of a platform is relative to its rivals. A platform must evolve at least as rapidly as its rivals to remain viable (the Red Queen effect).

• Emergent innovation can only be facilitated, not planned by a platform owner. Most innovations around platforms are emergent in the sense that they spontaneously arise from the selfish pursuit of self-interest by individual ecosystem participants. A platform owner must make the ecosystem conducive to such emergent innovation to fully realize the potential of platform ecosystems.

• New platforms must overcome the chicken-or-egg problem and the penguin problem to get off the ground. The multisided nature of platforms makes it unattractive for either side to join unless there is a critical mass on the other side. App developers, for example, will find a platform attractive only if it has a large pool of prospective users; users will find a platform attractive only if there is a large variety of apps to complement the platform. Uncertainty about whether others will join the platform ecosystem can stall initial adoption, creating the penguin problem. Governance tuned to different phases of a platform’s lifecycle (Figure 2.1) can help overcome these startup problems.

• Platforms must be designed to overcome three problems that can impede their evolution. First, platform owners must balance the need to grant sufficient autonomy to app developers to innovate freely without compromising integration of their work into the platform’s ecosystem (the seesaw problem). Second, apps must be separable from the platform to freely evolve, but it must also be easy to subsequently reintegrate them with the platform (the Humpty Dumpty problem). Third, how innovation work is organized should mirror the architecture of the platform and the “microarchitecture” (see Chapter 5) of individual apps (the mirroring principle).

In the next chapter, we describe how platform businesses differ from product and service businesses, how these differences catapult most managers and technologists out of their comfort zone, and the five necessary changes in managers’ mindsets and assumptions in platform markets.

References

1. Adner R, Levinthal D. Demand heterogeneity and technology evolution: implications for product and process innovation. Manag Sci. 2001;47(5):611–628.

2. Anderson P, Tushman M. Technological discontinuities and dominant designs: a cyclical model of technological change. Adm Sci Q. 1990;35:604–633.

3. Armstrong M. Competition in two-sided markets. RAND J Econ. 2006;37(3):668–691.

4. Armstrong M, Wright J. Two-sided markets, competitive bottlenecks and exclusive contracts. Econ Theory. 2007;32(2):353–380.

5. Barnett W, Hansen M. The Red Queen in organizational evolution. Strateg Manag J. 1996;17(1):139–157.

6. Caillaud B, Jullien B. Chicken and egg: competition among intermediation service providers. RAND J Econ. 2003;34(2):309–328.

7. Dougherty D, Dunne D. Organizing ecologies of complex innovation. Organ Sci. 2011;22(5):1214–1223.

8. Eisenmann T, Parker G, van Alstyne M. Strategies for two-sided markets. Harv Bus Rev. 2006;84(10):1–10.

9. Evans D, Schmalensee R. Catalyst Code. Boston, MA: Harvard Press; 2007.

10. Farrell J, Saloner G. Installed base and compatibility: innovation, product preannouncement, and predation. Am Econ Rev. 1986;76:940–955.

11. Hoetker G. Do modular products lead to modular organizations? Strateg Manag J. 2006;27(6):501–518.

12. Katz M, Shapiro C. Systems competition and network effects. J Econ Perspect. 1994;8(2):93–115.

13. Meadows D. Thinking in Systems. White River Junction, VT: Chelsea Green Publishing; 2008.

14. Monteverde K, Teece D. Supplier switching costs and vertical integration in the automobile industry. Bell J Econ. 1982;13(1):206–213.

15. Rogers E. Diffusion of Innovations. fourth ed. New York: Free Press; 1995.

16. Rohfls J. Bandwagon Effects in High-Technology Industries. Cambridge, MA: MIT Press; 2003.

17. Saloner G, Shepard A. Adoption of technologies with network effects: an empirical examination of the adoption of automated teller machines. RAND J Econ. 1995;26(3):479–501.

18. Sanchez R. Strategic flexibility in product competition. Strateg Manag J. 1995;16:135–159.

19. Sanchez R, Mahoney J. Modularity, flexibility, and knowledge management in product organization and design. Strateg Manag J. 1996;17(1):63–76.

20. Simon H. The architecture of complexity. Proc Am Philos Soc. 1962;106(6):467–482.

21. Tiwana A, Konsynski B. Complementarities between organizational IT architecture and governance structure. Inf Syst Res. 2010;21(2):288–304.

22. Tiwana A, Konsynski B, Bush A. Platform evolution: coevolution of architecture, governance, and environmental dynamics. Inf Syst Res. 2010;21(4):675–687.

23. Utterback J. Mastering the Dynamics of Innovation. Boston, MA: Harvard Press; 1996.

24. van Schewick B. Internet Architecture and Innovation. Cambridge, MA: MIT Press; 2012.