Platform Design¶
Core Idea¶
Platform Design is the practice of creating a stable core foundation — a set of standardized interfaces, shared services, reusable components, or computational infrastructure — on which multiple independent variations, applications, or specialized derivative systems can be built without each derivative requiring full system redesign. A platform is characterized by (1) the identification and engineering of a common substrate (hardware, software, organizational processes) that solves problems common to multiple use cases or applications, (2) the specification of explicit interfaces (APIs, physical connectors, data schemas, communication protocols) that allow external developers, vendors, or teams to build specialized applications on top without modifying the platform core, (3) the commitment to platform stability — the core abstractions remain fixed while applications and extensions evolve — which reduces coordination cost and enables parallel development of platform variants, (4) the recognition that the platform controls critical shared resources (processing, memory, storage, network, organizational decision authority) and must balance openness (enabling diverse applications) against control (maintaining platform integrity and quality), and (5) the economic insight that platform design shifts value creation from individual product design to ecosystem orchestration — value accrues not to the single best product but to the platform that attracts the most valuable applications and users. The deeper insight is structural: complex systems rarely succeed as monoliths; instead, they succeed as governed ecosystems where a stable core enables thousands of independent participants to innovate without synchronization. Platform design originated in operating systems (UNIX, Windows, iOS, Android) where the platform abstracts hardware variation and provides core services (file systems, process management, memory allocation, networking) enabling application developers to build without hardware expertise. The principle extended to hardware platforms (automotive, aviation, industrial equipment where a shared chassis or bus architecture enables multiple product variants), business platforms (marketplaces, franchises, supplier ecosystems), and organizational platforms (shared service centers, data platforms, technology infrastructure). The mechanism works because it inverts scalability: instead of central teams building individual products for each market, a platform team builds the foundation and the ecosystem builds the applications, making system complexity scale with ecosystem participation rather than central capacity[1].
How would you explain it like I'm…
Shared Base to Build On
Shared base for many builders
Stable core, many extensions
Structural Signature¶
- The identification of a stable core substrate that solves problems common to multiple applications or use cases [2]
- The specification of explicit, standardized interfaces that abstract the platform internals and enable external development [3]
- The commitment to platform stability: backward compatibility and interface continuity that allows applications to depend on the platform without fear of breaking changes [2]
- The balance between openness (enabling diverse third-party applications) and governance (maintaining platform quality, security, and coherence) [4]
- The ecosystem architecture: mechanisms for application discovery, integration, support, and quality assurance that allow the platform to scale beyond single-vendor control [5]
- The economic model: revenue sharing, licensing, or coordination mechanisms that align incentives between platform provider and application ecosystem [6]
What It Is Not¶
-
Not the same as modularity. A modular system decomposes complexity through encapsulation and clear interfaces; a platform is modular but goes further — it explicitly enables third-party development outside the original system. A monolithic system might have internal modules; a platform has external extensibility as a core design principle.
-
Not the same as a generic infrastructure. A generic library or utility (a JSON parser, a logging framework) can be reused by many applications, but it is not a platform unless it also defines interface contracts and governance for the broader ecosystem. A platform implies ecosystem coordination, not just code reuse.
-
Not a guarantee of ecosystem success. A well-designed platform interface does not guarantee that valuable applications will be built. Success depends on network effects — applications are more valuable when many users adopt them, and users are more likely to adopt a platform with many valuable applications. Chicken-and-egg problems are common: platforms must bootstrap application development before ecosystem value attracts users.
-
Not the same as a standard. A standard (like HTTP or CSV) specifies a format or protocol that any system can implement; a platform is a concrete implementation that also manages the ecosystem. HTTP is a standard; Amazon Web Services is a platform. Many platforms implement standards, but standards do not require the governance and coordination of a platform.
-
Not costless to create or maintain. Designing a stable, extensible interface requires deep understanding of the problem domain and anticipation of future use cases. Maintaining a platform involves continuous investment in backward compatibility, performance, security, and ecosystem support. Many proposed platforms fail because the core team underestimated the effort required.
-
Not universally applicable. Platforms are valuable when there is sufficient diversity of applications or use cases that a common substrate reduces total effort, when the problem space is well-enough understood to define stable interfaces, and when ecosystem coordination is feasible. For bespoke, one-of-a-kind systems, platform design adds overhead with minimal benefit.
Broad Use¶
Operating systems (Windows, macOS, iOS, Android, Linux providing core abstractions for hardware and system services, enabling independent application developers to build without hardware expertise), cloud platforms (Amazon Web Services, Microsoft Azure, Google Cloud Platform providing infrastructure primitives — compute, storage, networking — enabling third-party services and enterprise applications), mobile app ecosystems (Apple's App Store, Google Play Store managing application distribution, quality, security), open-source software ecosystems (GitHub, PyPI, npm as platforms for code sharing, discovery, and dependency management), hardware platforms (automotive platforms with shared chassis and powerplants enabling multiple vehicle models, aircraft platforms with core fuselage enabling variants for cargo, passengers, tanker, commercial roles), franchise and business platforms (McDonald's, Subway providing brand, supply-chain, operating procedures enabling franchisees to operate without full system redesign), data and analytics platforms (Salesforce CRM, Slack, HubSpot providing shared customer data and workflow infrastructure enabling plugins and integrations), institutional platforms (e-commerce marketplaces like eBay and Amazon connecting buyers and sellers, financial marketplaces providing trading infrastructure), and organizational platforms (shared service centers, data warehouses, technology stacks enabling business units to innovate without building infrastructure).
Clarity¶
Naming platform design explicitly signals the commitment to ecosystem orchestration and interface stability. The alternative — designing each application independently — requires parallel expertise and creates fragmentation: users must learn different interfaces, data cannot easily move between applications, and each application development cycle requires infrastructure work. An explicit platform commitment makes visible what is being promised about interface stability and who controls that commitment. This clarity prevents a common failure: promising platform stability while frequently breaking interfaces, or providing interfaces so generic that they require significant customization per application, eliminating the efficiency that platforms provide.
Manages Complexity¶
A single organization attempting to build every application for every use case faces unbounded complexity: how many user interfaces should be supported, how many data formats, how many integration patterns. Platform design partitions this complexity: the platform team focuses on core abstractions, performance, security, and ecosystem support; application teams focus on solving specific user problems. This allows organizations to scale application development without proportional scaling of central coordination. Complexity is managed through interface contracts: the platform specifies "provide data as JSON with these fields" and applications can be developed in parallel without knowing how other applications are structured. As the ecosystem grows, total system complexity exceeds what any single team could manage, but the platform boundaries keep individual teams' cognitive load bounded.
Abstract Reasoning¶
The architect asks: What is the common substrate across the applications we intend to support? What varies between applications, and what should be stable? If we extract the common substrate and specify its interface, what applications could be built on top? Are the interfaces we define sufficient to enable diverse applications, or are they so specific to current applications that they will not accommodate future innovation? What governance is needed to balance ecosystem growth against platform quality and security? What are the incentive structures that would encourage developers to build on our platform rather than competing platforms? The architect then specifies: What are the core capabilities the platform provides (computation, storage, networking, authentication)? What are the interfaces (REST APIs, SDK signatures, plugin architecture)? What are the stability commitments (backward compatibility, deprecation policies)? What quality standards must applications meet to be included in the ecosystem? What support does the platform provide (documentation, debugging tools, performance monitoring)? After the platform is specified, the architect verifies: Can an external team build a substantial application using only the public interfaces, without accessing internal platform code? If the platform team changes an internal implementation detail, how many applications break? Can applications from different vendors coexist and interoperate through the platform?
Knowledge Transfer¶
| Domain | Platform core | Interface specification | Ecosystem concern | Value mechanism |
|---|---|---|---|---|
| Operating system | Hardware abstraction, memory management, process scheduling | System calls, device driver APIs | Application compatibility, hardware vendor support | Hardware vendor reach; application developer reach |
| Cloud infrastructure | Virtualization, storage, networking, identity | REST APIs, CLI, SDKs | Service reliability, cost predictability, vendor lock-in | User adoption; service breadth; performance |
| Mobile app store | Device OS, distribution network, payment processing | App packaging, permissions model, in-app purchase APIs | App quality and security, user acquisition | Developer reach; consumer reach; transaction volume |
| Marketplace | Search, ranking, payment, logistics | Seller APIs, customer data access, fulfillment integration | Fraud prevention, seller support, customer satisfaction | Seller base growth; transaction volume; customer trust |
| Automotive | Chassis, electrical system, engine mounts | CAN bus protocols, physical attachment points | Supply chain alignment, vehicle safety, variant testing | OEM efficiency; supplier reach; variant count |
| Franchise | Brand, supply chain, operational procedures | Store format, menu, staff training | Quality consistency, franchisee profitability, brand protection | Franchisee network growth; brand equity |
Transfer principle: across domains, the same analytical structure applies — identify the common substrate, specify interfaces that enable specialization without requiring platform redesign, maintain stability through governance, align incentives between platform provider and ecosystem. An operating-system architect optimizing system-call interfaces, an e-commerce platform manager evaluating third-party seller quality, and an automotive OEM managing supplier requirements are performing the same platform design analysis under different variable names.
Examples¶
Formal/abstract¶
Baldwin and Clark (2000) in Design Rules: The Power of Modularity and extending to Platform Leadership (Cusumano and Gawer, 2002) establish that platforms are modular systems with governance. A platform defines a set of design rules — the interfaces, protocols, and standards that participants must follow — and a technical core — the stable foundation that coordinates the system. The design rules allow specialization and innovation at the periphery (applications, services, variants) without requiring central innovation and without coupling peripheral innovations. Each innovation at the periphery can be evaluated on its own merits and integrated or discarded independently. Gawer (2014) extends this to industry platforms — examples including semiconductor instruction-set architectures (x86, ARM), mobile operating systems, cloud infrastructure services, and industry standards bodies (automotive supply-chain standards, telecommunications protocols). Industry platforms are distinguished by governance structures that extend beyond a single firm: multiple firms participate in and benefit from the platform, creating complex incentive alignment. Boudreau (2010) analyzes openness — how much of the platform source code or design rules are visible to external developers, how easily can external developers build complementary applications, what are the barriers to entry. A closed platform (Apple iOS) restricts developer access but maintains tight quality control. An open platform (Android, Windows) attracts more developers but risks ecosystem fragmentation. Tiwana, Konsynski, and Bush (2010) identify platform architecture as a key variable — is the ecosystem tightly coupled (all applications depend on a central coordinator) or loosely coupled (applications can specialize and ignore each other), and how does coupling affect ecosystem innovation and stability. These treatments establish that platform design is a governance and economic problem, not just a technical one: the interfaces are easy; managing incentives and ecosystem evolution is hard[7].
Mapped back: This instantiates the signature directly — identification of common substrate and design rules (Baldwin-Clark design rules, Gawer industry platforms, D35-032), explicit interface specification enabling specialization (D35-033: the APIs and standards that allow peripheral innovation), platform stability and governance (D35-034: backward compatibility, design-rule enforcement), openness versus control (D35-035: Boudreau's analysis of closed and open platforms), ecosystem architecture (D35-036: Tiwana's coupling analysis, Gawer's governance structures), and value mechanisms (D35-037: Baldwin-Clark on value distribution, Cusumano-Gawer on platform leadership).
Applied/industry¶
A semiconductor OEM designs a new mobile processor that they intend to license to multiple device manufacturers (smartphone makers, tablet makers, IoT device makers). Rather than designing a unique instruction-set architecture for each manufacturer, the OEM defines a platform: a stable instruction set (the interface) and a standardized physical layout (core size, power requirements, thermal characteristics, pin-out). Device manufacturers can now specialize: one focuses on thin-and-light phones with efficient power management, another focuses on high-performance gaming devices, another on rugged industrial IoT. Each manufacturer can design their product without the processor OEM's involvement, and the processor OEM can update internal manufacturing and microarchitecture without requiring manufacturers to redesign their devices. However, this requires the OEM to make hard decisions: which instruction extensions does the platform support? (Adding extensions enables sophisticated applications but increases design complexity and testing burden.) How long will the instruction set remain stable? (Too long and the platform becomes obsolete; too short and manufacturers cannot commit to multi-year products.) How much control does the OEM maintain over instruction set evolution? (Tight control enables coherence but limits community innovation; loose control through an open standards body enables broader participation but reduces differentiation.) The platform's success depends not on the technical elegance of the instruction set but on ecosystem alignment: does the software industry (compilers, operating systems, applications) embrace the instruction set? Are device manufacturers willing to commit to the platform? Can the OEM maintain platform stability while still innovating competitively? A platform that becomes dominant (x86, ARM) shapes an entire industry; a platform that fails to attract ecosystem participation (Itanium, despite being technically advanced) becomes irrelevant regardless of technical merit. The OEM's platform team focuses on interface documentation, backward compatibility, adoption tooling, and ecosystem coordination — work that is invisible to the end user but essential to platform success[8].
Mapped back: Shows platform design as an industrial governance discipline — identification of common substrate (instruction set, physical interface, D35-032), explicit interface specification (instruction-set architecture, pin-out, D35-033), stability commitment through long-term roadmaps (D35-034), balance between openness and control through instruction-set governance (D35-035), ecosystem architecture (support for tooling, standards bodies, D35-036), and economic alignment (licensing model, device manufacturer profitability, D35-037).
Structural Tensions¶
-
T1: Platform stability versus innovation. Platform stability requires backward compatibility — applications built for version N should continue to work in version N+1. However, maintaining backward compatibility constrains innovation: new language features, performance improvements, or security enhancements that require interface changes are blocked by compatibility commitments. The tension is between the application ecosystem's need for stable foundations (apps that stop working are liabilities) and the platform team's need to evolve. A common failure is either ossifying the platform (compatibility at the cost of progress, platform becomes stale relative to competitors) or breaking compatibility too frequently (applications constantly break, ecosystem loses confidence in the platform)[9]*.
-
T2: Platform breadth versus depth of specialization. A broader platform (supporting more use cases, more application types, more interfaces) attracts a larger ecosystem. However, breadth increases platform complexity, makes it harder to maintain interface simplicity, and can lead to a platform that does nothing particularly well. A narrower platform (optimized for specific use cases) is simpler to understand and maintain but attracts a smaller ecosystem. The tension is between capturing ecosystem value (breadth) and maintainability (depth). A common failure is attempting platform breadth too early (before use cases are well-understood, platform becomes bloated) or staying too narrow (platform cannot attract sufficient ecosystem to achieve network effects)[10]*.
-
T3: Openness versus governance and quality control. An open platform (allowing any developer to build applications, no approval process) maximizes participation and innovation. However, open platforms often suffer from fragmentation (incompatible applications), security vulnerabilities (malicious or careless developers), and quality variability (applications that harm platform reputation). A tightly governed platform (curated applications, high approval bar) maintains quality and security but reduces participation and slower innovation. The tension is between ecosystem growth (openness) and ecosystem health (governance). A common failure is either allowing platform fragmentation that confuses users and reduces coherence, or maintaining approval processes so stringent that developers abandon the platform for competitors with lower barriers[4]*.
-
T4: Platform control and lock-in versus developer independence. A platform provider that controls core resources (computing, storage, payment processing) gains leverage over the ecosystem. Applications become dependent on the platform; users become locked into the ecosystem; switching costs are high. The platform provider can extract value but at risk of antitrust challenges and developer resentment. Excessive platform control can trigger regulatory intervention (Android antitrust cases, Apple App Store regulatory scrutiny) or competitive threats (developers migrate to platforms with fairer terms). The tension is between platform provider profit (control) and ecosystem sustainability (independence). A common failure is exploiting ecosystem lock-in until antitrust intervention or competitive disruption forces change[11]*.
-
T5: Ecosystem scaling and coordination overhead. A small ecosystem (few applications, few users) is easy to coordinate: the platform team can know most developers personally, can adjust interfaces as needs become clear. A large ecosystem (thousands of applications, millions of users) requires formal processes: deprecation policies, staged rollouts, change notifications, backward-compatibility testing. Coordination overhead grows with ecosystem size, and at some point, the overhead can become constraining (difficult to make any change without breaking something, painful to retire obsolete features). The tension is between the efficiency of a tight ecosystem and the scale of a loose one. A common failure is either not investing in coordination processes and losing ecosystem confidence as changes become chaotic, or over-engineering coordination processes such that the platform becomes brittle and conservative[12]*.
-
T6: Platform revenue model and ecosystem fairness. A platform provider must capture some value from the ecosystem to sustain development. Revenue models include licensing (charge per application or per user), take rates (charge a percentage of application revenue), advertising (monetize user attention), or upselling (provide free platform, charge for premium services). However, revenue models can seem unfair to application developers: if the platform takes a large percentage, developers have less incentive to build valuable applications. If the platform is free but the provider has other revenue streams (advertising, data), applications compete for users on an uneven playing field. The tension is between platform sustainability (capturing sufficient value) and ecosystem fairness (developers earn sufficient value to justify investment). A common failure is extracting so much value from the ecosystem that developers abandon it, or pricing so low that the platform cannot sustain development and quality declines[6]*.
Structural–Framed Character¶
Platform Design is a hybrid on the structural–framed spectrum, leaning structural with only a light frame. Part of it is a bare pattern that means the same thing anywhere — a stable shared core with standardized interfaces on which many derivatives can be built — and part of it is a vocabulary and set of design priorities inherited from engineering practice.
The structural pattern carries readily across fields: identifying a common substrate that solves problems shared by many applications, exposing it through explicit interfaces, and letting independent variations build on top is the same move whether the platform is a software framework, a shared automotive chassis, or an organization's common set of internal services. What keeps it from the pure pole is a modest amount of design-discipline framing — notions of reuse, abstraction of internals, and avoiding full redesign for each derivative carry a built-in sense of good engineering, and the prime's origin is a deliberate human practice rather than a purely formal relation. Still, the central idea can be described largely without invoking institutions, and using it is mostly a matter of recognizing the shared-core-plus-interfaces structure already at work. The light evaluative frame nudges it just structural-ward of center.
Substrate Independence¶
Platform Design is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its signature — a stable core, standardized interfaces, modularity, and a surrounding ecosystem — is substrate-agnostic and spans hardware platforms in engineering, OS and framework platforms in software, two-sided markets in economics, and organizational design. The transfer within technology is explicit, anchored by semiconductor and software platform examples, and the reach into economic and organizational platforms is real rather than metaphorical. Its abstraction and breadth are both strong; what keeps it from the very top is that the most concrete examples cluster in technology while the broader reaches are sketched more lightly.
- Composite substrate independence — 4 / 5
- Domain breadth — 4 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 3 / 5
Relationships to Other Primes¶
Parents (2) — more general patterns this builds on
-
Platform Design is part of Interface
Platform design builds a stable core foundation by engineering explicit interfaces — APIs, physical connectors, data schemas, communication protocols — that let independent applications connect to and reuse the core without modifying it. These interfaces are the platform's defining structural feature: they specify what is exposed and what is hidden, what crosses and what is guaranteed on each side. The interface prime supplies the asymmetric-visibility and structured-protocol component on which the entire platform pattern is built.
-
Platform Design presupposes Modularity
Platform design creates a stable core foundation on which independent derivative applications are built without redesigning the core, with explicit interfaces letting external builders add specialized layers. This architecture is constituted by modularity: discrete components with well-defined boundaries, stable interfaces that decouple platform from applications, and low coupling between core and derivatives. Modularity supplies exactly this decomposition principle. Platform design presupposes it as the structural pattern that makes a stable core with interchangeable derivatives possible at all, so the platform discipline is modularity in a particular configuration.
Path to root: Platform Design → Modularity
Neighborhood in Abstraction Space¶
Platform Design sits in a sparse region of abstraction space (77th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.
Family — Modularity, Architecture & System Design (19 primes)
Nearest neighbors
- Formal vs. Informal Structures — 0.77
- Interoperability — 0.77
- Design Patterns — 0.77
- Modularity — 0.76
- Interface — 0.76
Computed from structural-signature embeddings · 2026-05-29
Not to Be Confused With¶
Platform Design is distinct from Design Prototyping, though both concern system architecture and feasibility. Design Prototyping is fundamentally about learning through iterative testing—the designer builds candidate solutions, tests them against requirements, gathers data about what works and what fails, and revises the design based on that feedback loop. Prototyping prioritizes rapid iteration and empirical validation of design concepts before committing to full implementation. Platform Design, by contrast, is about long-term governance and extensibility—the architect specifies a stable core, locks down interfaces, and then steps back to enable others to innovate on top of the platform. Prototyping says "let's experiment and learn"; platform design says "let's commit to this architecture and prevent breaking changes." A software team might prototype a new API design (testing it with a small set of developers, revising based on feedback) and then platform-ize the successful design (committing to backward compatibility, investing in documentation, recruiting ecosystem developers). Prototyping enables learning; platform design enables scale. The prototype might be thrown away or heavily refactored; the platform must remain coherent for years despite evolution.
Platform Design is also distinct from User-Centered Design, despite both involving stakeholder needs. User-Centered Design focuses on understanding and optimizing for the end user—the person who directly interacts with the system. It asks: What tasks does the user perform? What are their pain points? How can we simplify their workflows? Platform Design, by contrast, must optimize for multiple participant groups simultaneously—not just end users, but also developers, service providers, administrators, and complementary product makers. A user-centered design of a smartphone optimizes for the consumer who holds the phone and launches apps; platform design of iOS optimizes for app developers building on the OS, device manufacturers integrating the OS into hardware, and enterprise administrators managing device fleets—as well as end users. User-centered design can afford to focus narrowly on one stakeholder; platform design must balance competing stakeholder interests. A platform that optimizes solely for end-user experience (say, completely open, no quality control) may fail because developers abandon it; a platform that optimizes only for developer convenience may create a confusing, incoherent experience for end users. Platform design is fundamentally multi-stakeholder and multi-party; user-centered design is fundamentally single-party (even when considering "user research").
Platform Design is further distinct from Design for Implementation, the practice of ensuring a design is feasible to build with available resources, constraints, and technology. Design for Implementation asks: Can we build this with our current team, budget, and technology stack? Are there architectural choices that would reduce implementation cost or risk? Design for Implementation optimizes for feasibility and resource efficiency. Platform Design optimizes for openness and third-party extensibility. A system designed for implementation might use a closed, tightly integrated architecture (easier to build, easier to maintain, lower internal coordination cost). A system designed as a platform requires explicit boundaries, public APIs, versioning strategies, and ecosystem support—all overhead that makes implementation harder but enables third-party participation. A startup building for its immediate needs would choose Design for Implementation (tight coupling, proprietary internals, minimal documentation). A company intending to attract an ecosystem of developers would choose Platform Design (loose coupling, public contracts, extensive documentation, deprecation policies). These are opposite directions: one minimizes internal complexity and implementation cost; the other accepts internal complexity to enable external development.
Solution Archetypes¶
Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.
Built directly on this prime (2)
Also a related prime in 3 archetypes
Notes¶
Platform Design is grounded in systems engineering, modularity theory, organizational economics, and the study of technology ecosystems. The formalization as an explicit design principle originates with the study of software platforms (operating systems, application frameworks) and extends to hardware platforms, business platforms, and institutional platforms. The principle interfaces with Modularity (platforms are modular systems with explicit boundaries) and with Interface Specification (platforms depend on stable, well-documented interfaces). The concept increasingly intersects with Network Effects (the value of a platform depends on the number and quality of applications and users, creating feedback loops that can either accelerate adoption or trigger collapse), with governance theory (platforms require decision structures and incentive alignment across autonomous participants), and with antitrust economics (platforms that dominate markets attract regulatory scrutiny). The practice evolves from proprietary platforms (tightly controlled by vendors) toward multi-stakeholder platforms (governed by consortia, open standards bodies, or community processes).
References¶
[1] Cusumano, M. A., & Gawer, A. (2002). Platform Leadership: How Intel, Microsoft, and Cisco Drive Industry Innovation. Harvard Business School Press. ↩
[2] Baldwin, C. Y., & Clark, K. B. (2000). Design Rules: The Power of Modularity (Vol. 1). MIT Press. ↩
[3] Ulrich, K. T. (1995). "The role of product architecture in the manufacturing firm." Research Policy, 24(3), 419–440. [^fischer-grötschel-2013]: Fischer, C., Grötschel, M., & Kramer, F. (2013). Practice in Operations Research: Successes and Challenges in Discrete Optimization. Springer. ↩
[4] Boudreau, K. J. (2010). "Open platform strategies and innovation: Granting access vs. devolving control." Management Science, 56(10), 1849–1872. ↩
[5] Tiwana, A., Konsynski, B., & Bush, A. A. (2010). "Platform evolution: Coevolution of platform architecture, governance, and environmental dynamics." Information Systems Research, 21(4), 675–687. ↩
[6] Eisenmann, T., Parker, G., & Van Alstyne, M. W. (2006). "Strategies for two-sided markets." Harvard Business Review, 84(10), 92–101. ↩
[7] Gawer, A. (Ed.). (2014). Platforms, Markets and Innovation. Edward Elgar Publishing. ↩
[8] Grindley, P., & Teece, D. J. (1997). "Managing intellectual capital: Licensing and cross-licensing in semiconductors and electronics." California Management Review, 39(2), 8–41. ↩
[9] West, J. (2003). How open is open enough? Melding proprietary and open source platform strategies. Research Policy, 32(7), 1259–1285. Analyzes the political economy of interface ownership: platform vendors balance appropriability (proprietary control) against adoption (openness), showing that interface control is a strategic and contested resource. ↩
[10] Simon, H. A. (1962). The architecture of complexity. Proceedings of the American Philosophical Society, 106(6), 467–482. Develops near-decomposability and hierarchic/modular structure as the means by which complex systems contain interaction (overhead) costs: decomposing an oversized whole into loosely coupled subsystems with sparse inter-module links caps the superlinear overhead term, the abstract basis for the decomposition remedy across firms, software, and biology. ↩
[11] Katz, M. L., & Shapiro, C. (1985). Network externalities, competition, and compatibility. The American Economic Review, 75(3), 424–440. Formal model of demand-side network effects: value to each user rises with installed base, with implications for compatibility, standards competition, and winner-take-most concentration; the canonical reference for network_effect as a sibling specialization of increasing returns. ↩
[12] Hyysalo, S. (2010). Health Technology Development and Use: From Practice-Bound Imagination to Evolving Impacts. Routledge. ↩
[13] Fricke, E., & Schulz, A. P. (2005). "Design for changeability (DFC): A systematic approach to estimating the costs of product changes." In Proceedings of the 1st CIRP International Seminar on Assembly Systems (pp. 373–383).
[14] Ross, A. M., Rhodes, D. H., & Hastings, D. E. (2008). "Defining changeability: Researching dynamic system architectures." In INCOSE Insight (Vol. 11, No. 1).
[15] Allen, T. J. (1990). "Organizational structures, communication, and group innovation." In Research, Development, and Technological Innovation (pp. 189–207). Springer.
[16] Ellen MacArthur Foundation. (2013). Towards the Circular Economy (Vol. 1). Ellen MacArthur Foundation.
[17] Saleh, J. H., Mark, G., & Jordan, N. C. (2009). "Flexibility: a multi-disciplinary literature review and a proposed definition." Journal of Engineering Design, 20(2), 189–205.
[18] Suh, N. P. (1990). The Principles of Design. Oxford University Press.
[19] Thomke, S. H., & Bell, D. E. (2001). "Sequential testing in product development." Management Science, 47(2), 308–323.
[20] McIlroy, M. D. (1968). "Mass produced software components." In Software Engineering: Report of a Conference Sponsored by the NATO Science Committee (pp. 138–155). NATO Science Committee.
[21] Henderson, R. M., & Clark, K. B. (1990). "Architectural innovation: The reconfiguration of existing product technologies and the failure of established firms." Administrative Science Quarterly, 35(1), 9–30.