Platform Ecosystems: Aligning Architecture, Governance, and Strategy (2014)
Glossary
App An add-on software subsystem or service that connects to the platform to add functionality. Also referred to as a module, extension, plug-in, or add-on. Apps are downstream complements for platforms; platforms are functionally more desirable when there are a wide variety of complements available to them.
App microarchitecture A description of how an app interacts, communicates, and interoperates with the platform. This does not have a 1:1 mapping with platform architecture because platform architecture is for apps as envisioned by a platform owner; app architecture is the same architecture as realized in the implementation of an individual app by its developer.
App microarchitecture, client-based Where presentation logic, application logic, and data access logic are placed on the client side but data storage logic is placed on the server side.
App microarchitecture, client–server Where the four functional elements of an app between clients and servers are evenly split.
App microarchitecture, cloud Where all four functional elements of an app—presentation logic, application logic, data access logic, and data storage logic—reside on the server side; the client device is a “dumb” terminal that only accepts user inputs and display outputs.
App microarchitecture, internal Where a description of how the functional elements—presentation logic, application logic, data access logic, and data storage logic—are distributed between a client and a server connected by the Internet. The five common app microarchitectures are (1) standalone, (2) cloud, (3) client-based, (4) client–server, and (5) peer-to-peer. Also known as network architecture.
App microarchitecture, peer-to-peer Where each device simultaneously acts as a client and as a server.
App microarchitecture, standalone Where all four functional elements—presentation logic, application logic, data access logic, and data storage logic—are placed on the client device and nothing resides on the server side.
Application logic Functional elements of an app where the core distinctive work that makes it valuable to its end-users is performed.
Application programming interface (API) An interface designed to accept a broad class of apps in ways that allow app developers to use the platform’s capabilities without having to concern themselves with how those capabilities are implemented in the platform.
Architectural resilience One malfunctioning app cannot cause the entire ecosystem to malfunction; usually ensured through loosely coupling apps with a platform.
Architectural simplicity When the architecture of a platform is simple enough to be comprehensible by one person at a high level of abstraction.
Architecture A conceptual blueprint that describes how the ecosystem is partitioned into a relatively stable platform and a complementary set of apps that are encouraged to vary, as well as the design rules binding on both.
Augment (evolutionary operator) The addition of a new subsystem to the ecosystem, adding new functionality. The notation for it used in this book is +.
Bathtub model of platform evolution The net difference between innovation inflows and outflows can potentially differentiate it from rival ecosystems. 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.
Chicken-or-egg problem The dilemma that neither side will find a two-sided technology solution with potential network effects attractive enough to join without a large presence of the other side.
Coevolution Simultaneously adjusting architecture and governance of a platform or app to maintain alignment between them.
Competitive durability The degree to which the adopters of a technology solution continue to regularly use it long after its initial adoption.
Complements Two products are complements when one increases the attractiveness of the other; think of cookies and milk or a laptop and a Web browser.
Complex system A system comprised of a number of smaller subsystems whose interactions and interdependencies are difficult to predict. A system’s complexity is is a function of the number of unique subsystems present in it.
Complexity, behavioral When a platform ecosystem’s aggregate behavior is difficult to predict or control.
Complexity, structural When the interconnections between parts of a platform ecosystem are difficult to describe.
Composability Changes can be made with ease within a platform or app without compromising its reintegration with the ecosystem. This can be measured as integration effort by person-hours per change.
Control mechanism The method that platform owners use to implement and enforce rules that reward desirable behavior, punish bad behavior, and promulgate standards of behavior among app developers. Its goal is to ensure coordination between the platform owner and app developers.
Control portfolio The combination of gatekeeping, process, metrics, and relational control mechanisms used by a platform owner over an app developer.
Data access logic Functional elements of an app focused on accessing and retrieving data that an app uses.
Data storage logic Functional elements of an app focused on storing data that an app uses.
Decision rights Who—the platform owner or app developer—makes what decisions. Can be exclusively with the platform owner (which represents centralization) or with an app developer (which represents decentralization), and shared anywhere in between.
Diffusion curve A description of whether a technology solution is in the stage of having attracted the geeks, early majority, early adopters, late majority, or laggards to its user base.
Divide-and-conquer strategy Divvying a platform ecosystem into manageable components—the platform and its many apps—that can be developed independently and subsequently brought together. This is primarily done using a modular architecture.
Dominant design A technology solution that implicitly or explicitly becomes the gold standard among competing designs that defines the design attributes that are widely accepted as meeting users’ needs.
Durability A platform or app’s endurance over time in a competitive marketplace. Can be measured as the change in the percentage of its initial adopters who remain active users.
Ecosystem The collection of the platform and the apps specific to it.
Emergence The properties of a platform that arise spontaneously as its participants pursue their own interests based on their own expertise but adapt to what other ecosystem participants are doing.
Envelop (evolutionary operator) The addition of the functionality of an adjacent solution with a shared user base to the original ecosystem, swallowing the target’s functionality. This is a special case of the augment operator. The notation for it used in this book is +e.
Envelopment Swallowing of a platform or app of the functionality of a solution in an adjacent market with overlapping users. This can be measured as the count of successful envelopment moves made or envelopment attacks rebuffed.
Envelopment, horizontal The most widespread envelopment move through which a platform or app swallows the functionality of a product or service—or even a platform—in an adjacent market.
Envelopment, vertical An envelopment move by a platform or app into adjacent parts of the ecosystem’s value chain.
Evolvability The capacity of a platform or app to efficiently change as new requirements, needs, and possibilities emerge.
Fixed costs Baseline costs incurred (e.g., initial development costs, services provisioning costs, operating expenses) even if the platform had zero users on either side. Fixed costs are spread over the number of users, so fixed costs per user decline as the number of users grows.
Gatekeeping control A platform owner uses predefined criteria for judging what apps and app developers are allowed into a platform’s ecosystem. The platform owner sets this criteria, not just for what is allowed in but also who is allowed in.
Gears of evolution Architecture and strategy are the two gears of a platform’s evolutionary motor that must interlock and align. Realizing the potential of thoughtfully designed architectures requires ensuring that a platform is governed to take advantage of its architecture. The two can be perfect in isolation but will underdeliver on their potential if one does not align well with the other.
Goldilocks rule The idea that humans gravitate toward the middle over the two extreme choices given any three ordered choices.
Good architecture, properties Simplicity, resilience, maintainability, and evolvability.
Governance Who decides what in a platform’s ecosystem. This encompasses partitioning of decision-making authority between platform owners and app developers, control mechanisms, and pricing and pie-sharing structures.
Humpty Dumpty problem When separating an app from the platform makes it difficult to reintegrate them.
Icarus paradox The very reasons that led to a platform’s market success eventually hinder its ability to respond to new generations of technology, eventually causing their downfall.
Implementation decision rights Specify how a party (app developer or platform owner) should implement the objectives specified by strategic decision rights. Such technical execution decisions pertain to the choice of features, functionality, design, user interface, and implementation details. They apply to both platforms and apps.
Interface standardization The degree to which an app communicates, interoperates, and exchanges data with the platform using explicitly defined interfaces, protocols, and rules that are not allowed to change.
Interfaces Specifications that describe how the platform and apps interact and exchange information.
Invert (evolutionary operator) The addition of the functionality widely used by other interacting systems to the original ecosystem. Invert potentially demodularizes by converting a modular pair of systems into a monolithic system. This is a special case of the augment operator. The notation for it used in this book is +i.
Leapfrogging Embracing a disruptive technology solution and using it as the foundation for the firm’s market offering in lieu of an incumbent solution in the decline phase of its S-curve.
License, perpetual A one-time payment by an end-user that grants nonexpiring rights to use the app. The license can either be an individual license (the buyer can use the app on a limited or unlimited number of instantiations of the platform), a machine license (which allows use only on a particular machine for which it was purchased), or a floating license (which allows the user to use it on any one machine at a time).
License, subscription-based Allows the user to use an app for the duration of an active subscription period, during which it usually includes all future updates to the app.
License, usage-based A utility-oriented licensing model that charges the user based on actual usage using some direct measure, such as number of times used or number of hours used.
Lock-in The ways in which a platform can make it more desirable for existing adopters to stay and not leave for a rival.
Long-tail strategy Going after small, niche markets with highly specialized and uncommon needs than mainstream, mass-market customers that would be economically unfeasible for mass market–oriented companies to economically serve. Think of this book versus a Stephen King horror bestseller and which one a bookstore in an airport would likely carry.
Maintainability To cost-effectively make any changes within the platform without inadvertently breaking apps that depend on it. Conversely, changes in an app should not require parallel tweaking in the platform. Designing for maintainability also increases a platform’s composability.
Market volatility Not knowing how potential end-users will respond to a project, how fast they will adopt it, and whether rival platforms or apps will quickly replicate to match the features and capabilities introduced by the project. Market volatility also arises from attempting to target a market where the needs of end-users (and also of app developers in the case of platforms) are diverse.
Metrics-based control A platform owner rewards or penalizes app developers based on the degree to which the outcomes of their work achieves prespecified and objectively measurable performance targets predefined by the platform owner.
Mirroring hypothesis The organizational structure of a platform’s ecosystem must mirror its architecture.
Modular operators The five discrete operations that can be performed on a platform or an app, and within the ecosystem to evolve it. Think of them as the alphabet—or baby steps—to precisely describe evolutionary paths in platform ecosystems.
Modularity The degree to which the platform and apps can be designed, implemented, operated, and altered independent of each other.
Modularization Achieved in a platform ecosystem by decoupling a platform from apps and codifying the interface specifications for how an app interacts with a platform. Its two core functions are partitioning and systems integration.
Multihoming When a participant on either side—an end-user or an app developer—participates in more than one platform ecosystem
Multisidedness The need to attract at least two distinct mutually attracted groups (such as app developers and end-users) who can potentially interact more efficiently through a platform than without it.
Mutate (evolutionary operator) The replication of a system to create a distinct derivative system intended for use in a different application domain. The notation used in this book is ≈.
Mutation The unanticipated, serendipitous creation of a spinoff platform or app that inherits some of the properties of the parent system but with a different purpose.
Network effects A property of a technology solution where every additional user makes it more valuable to every other user on the same side (same-side network effects) or the other side (cross-side network effects).
Packetization The ability to digitize “something”—an activity, a process, a product, or service—that was previously not digitized. Anything that can be digitized can be broken into Internet data “packets” and transported instantaneously and at near-zero cost across large distances.
Partitioning The decomposition of a platform ecosystem such that each subsystem within it is relatively autonomous from others.
Penguin problem When potential adopters of a platform with potentially strong network effects stall in adopting it because they are unsure whether others will adopt it as well.
Plasticity The degree to which a platform or app can deliver functionality that it was not originally designed to deliver to its primary existing and prospective users. This can be measured as the average count of major features added to it per release over its lifetime.
Platform The extensible codebase of a software-based system that provides core functionality shared by apps that interoperate with it, and the interfaces through which they interoperate.
Platform ecosystem See Ecosystem.
Platform lifecycle 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 the prospective user base that has already adopted it.
Platform owner The lead firm primarily responsible for the platform; sometimes also called an ecosystem’s keystone firm or economic catalyst.
Platform synergy The degree to which an app is designed specifically for a particular platform. This can be measured as change in the number of functions called by the app to APIs unique to a platform as an app ages.
Port (evolutionary operator) Replicating the functionality of an app to allow it to function on a platform different from which it was originally implemented. This is a special case of the mutate operator. The notation used in this book is ≈p.
Presentation logic The functional elements of an app where almost all of the interaction—for example, receiving inputs and presenting the application’s output—with the end-user occurs.
Process control A platform owner rewards or penalizes app developers based on the degree to which they follow prescribed development methods and procedures that it believes will lead to outcomes desirable from a platform owner’s perspective.
Real option The right to do something along a project’s evolutionary trajectory—grow, scale, switch ingredients, stage expansion, or kill a project—without the obligation to do it. Many of the six types of real options can realistically be embedded in a project.
Real options thinking A way of thinking that disciplines how platform and app projects can be structured to protect against potential losses while preserving potential gains. It is an approach to position for the upside by hedging against possible futures.
Red Queen effect The increased pressure to adapt faster just to survive is driven by an increase in the evolutionary pace of rival technology solutions.
Relational control A platform owner relies on shared culture, similar set of values, and shared norms to shape their behaviors.
Resilience The capacity of a platform or app to function acceptably in the event of a failure elsewhere within or outside the ecosystem. This can be measured as the recovery time of a platform or app after a failure outside it.
Resource Tangible assets such as a platform’s capabilities, functionality, user base, complementing apps, and patents as well as intangible assets such as brand recognition and reputation.
Resource litmus test A resource can help (1) create a competitive advantage if it is valuable and rare and (2) sustain a competitive advantage if it is inimitable and nonsubstitutable.
Risk transfer in platforms Unlike traditional product development where a company must bear most innovation risk, the costs and risks of developing new platform-specific innovations shift from the platform owner to the app developers.
Scalability The degree to which the functional performance and financial viability of a platform or app is size-agnostic. This can be measured as the increase in its latency, responsiveness, or error rates per additional 1,000 users or as direction of the shift in its financial breakeven point per 1,000 fewer users.
S-curve A technology’s lifecycle that describes its progression from introduction, ascent, maturity, and decline phases.
Search costs The costs incurred by customers prior to transacting making a purchase, largely from having to decide who to buy from.
Seesaw problem The challenge of managing the delicate balance between app developers’ autonomy to freely innovate and ensuring that apps seamlessly interoperate with the platform.
Software embedding Making a business process or activity into software.
Split (evolutionary operator) The subdivision of a monolithic system into two smaller subsystems; modularizes monolithic systems. The notation for it used in this book is ≠.
Stickiness The “eyeball time” between a platform or app and its primary users. This can be measured as the change in hours per end-user session over time, the count of end-user sessions per week over time, or in API calls made by an app on average as the platform ages (platform-level only).
Strategic decision rights Decision rights that specify what a party (app developer or platform owner) should accomplish. They apply to both platforms and apps.
Substitute (evolutionary operator) The substitution of one subsystem in the ecosystem with another. The notation used in this book is ↕.
Subtract (evolutionary operator) The removal of a subsystem from the ecosystem. The notation for it used in this book is —.
Systems integration costs The effort required by an app developer to manage the dependencies among a platform and apps in an ecosystem. These include costs of integrating an app with the platform and of integrating an app with other potentially interacting apps in the ecosystem.
Technical volatility Immaturity of technology, unpredictability of how it will evolve, the need for integrating a system with other existing systems within and outside a platform ecosystem, and a platform project’s sheer complexity.
Tipping The point at which a critical mass of adopters makes positive network effects take off.
Transaction costs The costs incurred by customers during the purchase process.
Ubiquity The property of being present everywhere; refers specifically to Internet-based data networks in this book.
Valuable ignorance When, in doing their own work, app developers need not know how a platform does what it does nor need to understand the intricacies of the platform-native functionalities on which their app draws.
Value chain of ecosystems A platform ecosystem can also be divided into its upstream and downstream parts of a value chain. The upstream part is what goes into producing the platform itself (e.g., component and hardware suppliers, software licensors, manufacturing partners, network connectivity providers). The downstream part includes platform complement producers (primarily app developers), end-users who adopt it, and other intermediaries between the platform owner and end-users.
Variable costs The additional costs besides fixed costs that increase with the number of users (e.g., bandwidth costs, end-user support costs, or storage costs). See also Fixed costs.