Design for Lifecycle Adaptability¶
Core Idea¶
Design for Lifecycle Adaptability is the engineering practice of intentionally structuring a system, product, or process such that it can be modified, updated, reconfigured, repurposed, or deconstructed at different stages of its operational life without excessive cost, complexity, or compromise to core function. This is characterized by (1) the anticipation during design of how the system might evolve — what requirements might change, what components might need upgrade or replacement, what performance characteristics might shift — and the deliberate embedding of adaptability mechanisms (modular interfaces, redundancy, excess capacity, staged assembly) to accommodate foreseen evolution, (2) the separation of change-prone elements (user interfaces, algorithm parameters, feature sets, component versions) from stable core elements (fundamental architectures, load-bearing structures, critical protocols) such that changes to the former do not require redesign of the latter, (3) the recognition that every system has a lifecycle — it is born (design, manufacture, deployment), evolves (maintenance, upgrades, extensions, configuration), and dies (decommissioning, recycling, repurposing) — and that adaptability decisions made during design profoundly affect the cost and feasibility of evolution and end-of-life stages, (4) the commitment to ease of partial change: a well-adapted system can be modified piecemeal (replace one component, upgrade one subsystem) without requiring wholesale redesign or downtime, and (5) the understanding that adaptability reduces waste — systems designed for easy reconfiguration or upgrading are used longer, their components are reused or recycled rather than discarded, and the total lifecycle cost and environmental impact are reduced. The deeper insight is temporal: static design (optimize for current requirements, assume future requirements unknown) is brittle; adaptive design (anticipate categories of change, build flexibility in) is resilient. Design for Lifecycle Adaptability originated in mechanical engineering (design of machinery for easy maintenance and upgrade), manufacturing systems (production lines that can be reconfigured for different products), and architecture (buildings designed for renovation or conversion). The principle formalized through design-for-disassembly (Ulrich, 1995, focusing on end-of-life disassembly for reuse and recycling), design-for-changeability frameworks (Fricke and Schulz, 2005), and epoch-era analysis (Ross, Rhodes, and Hastings, 2008) which model how systems evolve through discrete change epochs. The mechanism works because anticipating change during design is vastly cheaper than retrofitting adaptability after deployment; systems designed with adaptability built in can evolve gracefully, whereas systems designed for static conditions become increasingly costly to modify as they age[1].
How would you explain it like I'm…
Build it to change later
Designing things to be changed
Designing for future change
Structural Signature¶
- The anticipation of change scenarios during design: identification of what elements are likely to change (requirements, technologies, regulations) and what elements should remain stable [2]
- The separation of change-prone from stable elements through modular partitioning, clear interfaces, and bounded coupling [1]
- The design of adaptability mechanisms: redundancy, excess capacity, staged implementation, or reconfigurability that enable evolution without redesign [3]
- The emphasis on ease of partial modification: change to one element should not require downstream redesign cascades [4]
- The attention to assembly and disassembly sequences: components designed to be assembled and reassembled with minimal cost or specialized equipment [5]
- The assessment of lifecycle cost and environmental impact: designing for reuse and recycling, not just operational efficiency [6]
What It Is Not¶
-
Not the same as modularity. Modularity is about decomposition for understanding and management; lifecycle adaptability is about designing that decomposition such that modules can be swapped, upgraded, or removed during operation. A modular system need not be adaptable; an adaptable system must be modular.
-
Not the same as flexibility. Flexibility (a system that can handle variable inputs or operating conditions) is a design goal; adaptability (a system that can be modified over time) is different. A flexible control system (one that can handle multiple input patterns) is not necessarily adaptable (it may be impossible to upgrade its components). Conversely, a system designed for easy upgrade may have less flexibility (less ability to handle unexpected conditions).
-
Not the same as fault tolerance. Fault tolerance (a system that continues to function despite component failures) is about resilience to sudden unexpected events. Adaptability is about planned, foreseen evolution. A fault-tolerant system remains functional when a component fails; an adaptable system can replace components before failure or incorporate new capabilities.
-
Not a guarantee of infinite lifetime. Designing for adaptability extends useful life and reduces costs, but nothing is truly indefinite. Eventually, new requirements become so different from the original design that adaptation is infeasible, and replacement or complete redesign becomes necessary.
-
Not costless. Designing for lifecycle adaptability requires upfront investment — additional design analysis, modular architecture (often more expensive than monolithic), and preparation for future change. For systems with short lifespans or well-understood static requirements, this overhead may exceed benefit. Adaptability is an investment whose returns accrue over the system's full lifecycle.
-
Not about over-engineering. Adaptability does not mean designing with unlimited excess capacity or preparing for every conceivable change. It means identifying likely changes (based on domain experience and forecasts) and designing to accommodate those specific categories of change while accepting that unforeseen changes will require redesign.
Broad Use¶
Automotive design (chassis and platform architectures designed to accommodate multiple vehicle models, engine generations, and regulatory variations; modular powerplant designs enabling rapid replacement or upgrade), aircraft design (fuselage and systems designed for mid-life upgrades of avionics, engines, and seating without major structural changes), computer and electronics manufacturing (processor sockets enabling CPU upgrades, memory slots for RAM expansion, modular power supplies, standardized interfaces enabling component replacement), information systems (microservices architectures enabling independent service updates, API versioning enabling backward compatibility, database schemas designed for schema evolution), buildings and real estate (modular construction enabling reconfiguration of internal spaces, system separation enabling independent upgrade of electrical, HVAC, plumbing systems), software applications (plugin architectures enabling feature additions without core code changes, configuration files enabling customization without recompilation), manufacturing and production (reconfigurable assembly lines enabling tooling changes for different products, modular jigs and fixtures), organizational processes (decoupled workflows enabling changes to one process without affecting others, staged implementation of process changes), and policy and regulation (modular legal codes enabling repeal or amendment of specific sections without toppling the entire system, sunset clauses enabling phase-out or renewal without permanent commitment).
Clarity¶
Naming Design for Lifecycle Adaptability explicitly signals the commitment to evolution and long-term thinking. The alternative — designing solely for current requirements — leads to brittle systems that become increasingly costly to modify over time. An explicit adaptability commitment makes visible the lifecycle thinking: stakeholders recognize that requirements will evolve, that the system will outlive some of its original design assumptions, and that planning for change is part of good design. This clarity prevents a common failure: designing beautiful systems that solve today's problems perfectly but become expensive to modify when requirements evolve, leading to wasteful replacement rather than graceful adaptation.
Manages Complexity¶
Adaptability manages complexity by distributing change over the system's lifetime. Rather than making a single perfect design upfront (which requires anticipating all possible futures), adaptable design makes a good-enough design with hooks and mechanisms for improvement. Early versions of the system address core needs; later versions address evolved needs without discarding earlier investments. Complexity of individual change is reduced (each adaptation is a bounded, localized modification) even as the total system evolves to greater sophistication. Lifecycle thinking also reduces the complexity of decommissioning: systems designed for disassembly can be recycled or repurposed rather than discarded whole, reducing waste and hidden costs.
Abstract Reasoning¶
The designer asks: What are the likely sources of change in this system over its intended lifetime? Will requirements evolve (new features, new users, new use cases)? Will technologies change (available materials, manufacturing techniques, regulatory standards)? Will operating conditions shift (load, duration, environment)? Rather than designing to a single point (current requirements, current technology), the designer identifies categories of change and designs mechanisms to accommodate them. For each category, the designer asks: If this change occurs, what is the cost of adaptation? Can we design now to reduce that future cost? The designer then specifies: Which elements will remain stable (foundational architecture, core protocol, primary structure)? Which elements are expected to change (specific components, material choices, feature parameters)? How are stable and change-prone elements separated? What redundancy or excess capacity is built in? Can components be replaced independently or must a cascade of changes propagate? After the design is specified, the designer verifies: If we upgrade one component, how many other components must be changed? Can we test the upgraded component independently? How long does the modification take? Can the system continue operating during modification (staged implementation) or must it be shut down?
Knowledge Transfer¶
| Domain | Stable core | Change-prone elements | Adaptation mechanism | Lifecycle benefit |
|---|---|---|---|---|
| Automotive | Platform, chassis geometry | Engine, transmission, electronics, trim | Modular engine/transmission mounts, standardized interfaces | Product variants from one platform; mid-life facelifts |
| Aircraft | Fuselage structure, systems layout | Avionics, engines, seats, interior | Modular bay architecture, standardized electrical/data buses | Avionics upgrades without major rework; engine swaps between variants |
| Electronics | Circuit board layout, power delivery | Processors, memory, storage, peripherals | Standardized sockets, connectors, form factors | Easy CPU/RAM upgrades; component replacement without rework |
| Software | Core algorithms, API contracts | Feature implementations, configuration parameters | Plugin architecture, configuration files, versioning | New features without core changes; adaptation to new environments |
| Buildings | Structural frame, utility routing | Interior layout, systems (HVAC, electrical, plumbing) | Modular mechanical and electrical systems, independent routing | Reconfiguration for new tenants; system upgrades without structural work |
| Manufacturing | Production sequence, station layout | Equipment, tooling, fixtures | Modular fixtures, standardized material handling | Production line reconfiguration for new products |
Transfer principle: across domains, the same analytical structure applies — identify what must remain stable for the system to function, anticipate what will change, separate them through design, and build mechanisms for change. An automotive engineer designing a platform for multiple models, a software architect designing for feature evolution, and a facilities manager designing a building for reconfiguration are performing the same adaptability analysis under different variable names.
Examples¶
Formal/abstract¶
Ulrich (1995) in "The Role of Product Architecture in the Manufacturing Firm" establishes that product architecture — how a product is partitioned into components and how those components are integrated — fundamentally determines what changes are possible and how costly they are. A modular architecture (components with standard interfaces, loosely coupled) enables independent evolution: one component can be improved or replaced without redesigning adjacent components. An integral architecture (tight coupling, custom interfaces, many interdependencies) means that improving one component often requires redesigning several others. Ulrich argues that manufacturing firms with modular product architectures can introduce product variants faster and at lower cost than firms with integral architectures. Fricke and Schulz (2005) in "Design for Changeability (DFC): A Systematic Approach to Estimating the Costs of Product Changes" formalize change-cost estimation: for each potential change, analyze what components are affected, what integration and testing is required, what is the schedule impact. Design-for-Changeability means identifying high-probability, high-impact changes and designing to reduce their cost. Ross, Rhodes, and Hastings (2008) in "Architecting for Evolution" introduce epoch-era analysis: systems evolve not continuously but in epochs of relative stability interrupted by eras of significant change. By analyzing past epochs in similar systems, designers can anticipate future change patterns and design accordingly. For example, a satellite platform designed for a 15-year mission might anticipate that 5 years in, communication standards will evolve, requiring electronics upgrades. Building upgrade capability into the design now costs extra upfront but avoids catastrophic obsolescence mid-mission. Allen (1990) on modular adaptability in systems engineering emphasizes that adaptability requires both design modularity (independent components) and change protocols (well-defined ways to integrate new components or versions without regression). Without change protocols, modular systems can become unmanageable as the number of component combinations grows combinatorially[1].
Mapped back: This instantiates the signature directly — anticipation of change through architecture analysis (Ulrich on architectural impact, Fricke-Schulz on change-cost estimation, D35-047), separation of stable core from change-prone elements (modular architecture enabling independent evolution, D35-048), design of adaptability mechanisms (Fricke-Schulz identifying high-impact changes, Ross-Rhodes-Hastings epoch-era analysis predicting change patterns, D35-049), emphasis on ease of partial modification (modular architecture reducing change propagation, D35-050), attention to assembly/disassembly (component integration protocols, D35-051), and lifecycle thinking (Ulrich on manufacturing cost and time-to-market over product lifetime, D35-052).
Applied/industry¶
A manufacturing company designs a production line for assembling consumer electronics. The initial requirements specify production of one model at a rate of 5,000 units per month. Traditional design would optimize the line exclusively for that specific model: specialized fixtures, custom material-handling equipment, minimal buffering between stations. However, the company anticipates that over the line's 10-year lifetime, product designs will evolve (new models, new form factors), production volumes will fluctuate, and manufacturing locations might change. To design for lifecycle adaptability, the engineers partition the production sequence into stable core (test procedures, quality protocols, statistical process control) and change-prone elements (specific equipment, fixtures, component-specific handling, assembly sequence). They design modular fixtures that can be reconfigured to handle multiple form factors, implement buffering between stations to reduce coupling, and establish standardized material-handling protocols so equipment can be swapped. The line includes excess capacity (stations sized for 7,000 units/month even though initial demand is 5,000) to accommodate future product variants with heavier components. Five years in, product designers introduce a new model with different dimensions. Retrofitting the traditional line would require redesigning most fixtures and significant downtime. Retrofitting the adaptable line requires reconfiguring fixtures (2 weeks, cost $50K), updating the assembly sequence (1 week), and baseline-testing the new product (2 weeks). Total cost and downtime are acceptable; the line continues to serve the company for another 5 years. At end-of-life, the modular fixtures and equipment are sold as used manufacturing assets, recovered at 30% of original cost; the monolithic custom-built equipment would have been scrap. The adaptable design cost 15% more upfront but avoided $500K in retrofit costs and generated $200K in salvage value, a clear lifecycle return on investment[3].
Mapped back: Shows lifecycle adaptability as an industrial economics discipline — anticipation of form-factor and volume evolution (D35-047), separation of stable production protocols from change-prone equipment and fixtures (D35-048), design of modular fixtures and standard material handling (adaptability mechanisms, D35-049), emphasis on ease of partial modification without full line redesign (D35-050), standardized assembly and disassembly for fixture reconfiguration (D35-051), and lifecycle cost analysis including retrofit, downtime, and end-of-life salvage (D35-052).
Structural Tensions¶
-
T1: Designing for anticipated change versus designing for unknown futures. Design-for-adaptability requires anticipating what will change; but anticipation is imperfect. Resources invested in accommodating likely changes (e.g., modular architecture for component upgrades) may be wasted if the changes don't materialize. Conversely, failing to design for a change that does occur is expensive. The tension is between over-designing for unlikely futures (wasted capability) and under-designing for likely changes (expensive retrofits). A common failure is either investing heavily in adaptability mechanisms that are never used, or assuming changes are unpredictable and designing for static requirements, only to be surprised by expensive mid-life modifications[2]*.
-
T2: Adaptability and initial design simplicity. A system designed solely for current requirements can be simpler and cheaper to design and build initially. Designing for adaptability adds complexity upfront: additional modularity, interfaces, redundancy, and contingency planning. This complexity increases initial cost and may reduce initial performance. The tension is between time-to-market and cost-to-build (favor simplicity) versus lifecycle cost and evolvability (favor adaptability). A common failure is optimizing the initial design at the cost of future adaptability, realizing too late that evolution is expensive, or over-designing for adaptability that is not needed during the system's actual lifecycle[7]*.
-
T3: Modular design and performance optimization. Modular design often requires standardized interfaces and separation of concerns that reduce optimization opportunities. A custom-integrated design (tight coupling) can optimize globally: tuning one component affects another, allowing peak performance. A modular design must optimize each module independently, often yielding lower peak performance. A monolithic heat-sink design might exceed modular thermal management; tightly coupled control algorithms might outperform loosely coupled ones. The tension is between peak performance (integral design) and adaptability (modular design). A common failure is either sacrificing necessary adaptability for marginal performance gains, or building modular systems so loosely coupled that performance suffers unacceptably[8]*.
-
T4: Planned adaptability and unexpected change. Design-for-adaptability plans for expected changes (e.g., "we'll need to upgrade this component in 5 years"). But unexpected changes (new regulations, material shortages, completely new requirements) often occur outside the planned adaptability mechanisms. A system designed for expected upgrades may not be adaptable to unexpected evolution. The tension is between over-investing in adaptation mechanisms (many of which are never used) and under-investing (new unexpected changes are expensive to accommodate). A common failure is discovering that the system's anticipated evolution path was wrong, and the adaptability investments don't help with the actual changes needed[9]*.
-
T5: Staged implementation and system integration. Lifecycle adaptability often involves staged implementation (replace component A, then component B, then component C over time, rather than replacing the entire system at once). However, staged implementation can create version-mismatches and integration problems: component A expects version 2 interfaces, component C is still version 1, integration testing becomes complex. The tension is between the cost-savings of staged adaptation (no need to redesign the entire system at once) and the complexity of managing component version combinations. A common failure is either requiring complete system upgrades (losing the benefit of staged adaptation) to avoid version-mismatch complexity, or implementing staged upgrades with insufficient version management, creating fragile mixed-version systems[10]*.
-
T6: Designing for disassembly and structural integrity. End-of-life disassembly and recycling benefit from modular design, easily separated components, and minimal bonding. However, bonding (welding, adhesives, permanent fastening) often provides superior structural integrity and performance compared to modular connections (bolts, snap-fits, modular interfaces). A car welded throughout is stronger and lighter than one with bolted modular subassemblies. The tension is between ease of disassembly and recycling (modularity) and structural performance (integral design). A common failure is either designing for perfect disassembly at the cost of mid-life performance, or optimizing structural performance and discovering that end-of-life disassembly is so costly that modular components are abandoned as waste[6]*.
Structural–Framed Character¶
Design for Lifecycle Adaptability is a hybrid on the structural–framed spectrum. Part of it is a bare pattern that means the same thing in any field — separating the parts of a system likely to change from the parts meant to stay stable — and part of it is a frame, a vocabulary and set of assumptions inherited from engineering design. The frame is substantial, though a structural core is present.
The structural core is an anticipation-and-separation relation: foresee which elements will need to change over a system's life, then partition the design so change-prone elements can be modified, upgraded, or removed without disturbing the stable core. That decoupling logic is general. But the prime carries an engineering frame — requirements, technologies, regulations, modularity, reconfiguration and deconstruction costs — and a normative commitment that designing for future change is a virtue worth paying for up front. Applied to product platforms, building systems, or evolving software architectures, it imports that lifecycle-and-modularity vocabulary. Because the structural separation principle is wrapped in a thick engineering frame, it sits past the middle toward the framed side.
Substrate Independence¶
Design for Lifecycle Adaptability is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its structural signature — anticipate change, separate the change-prone from the stable, and build in adaptability mechanisms — is genuinely transferable. Examples cross manufacturing and software, and a practitioner in governance or evolutionary biology would readily recognize the same modular-separation and loose-coupling logic at work. It spans engineering design, product development, organizational systems, and institutional design; what keeps it just below the top is that its concrete demonstrations cluster in engineering and software rather than blanketing every substrate.
- Composite substrate independence — 4 / 5
- Domain breadth — 4 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 4 / 5
Relationships to Other Primes¶
Parents (2) — more general patterns this builds on
-
Design for Lifecycle Adaptability presupposes, typical Modularity
Design for lifecycle adaptability deliberately structures systems so they can be modified, upgraded, or repurposed across operational life without excessive cost. The practical mechanism is typically modular structure: changes are absorbed by replacing or reconfiguring discrete modules without rippling through the whole. Modularity supplies the decomposition into independently revisable components with stable interfaces. Lifecycle adaptability rides on this organization to keep modification cost bounded, though some adaptability strategies use redundancy or parameterization without strict modularity, so the dependence is typical rather than strict.
-
Design for Lifecycle Adaptability is a decomposition of Adaptation
Design for lifecycle adaptability is the engineered, anticipatory particularization of adaptation: rather than a system changing in response to sustained environmental change after the fact, the designer pre-embeds modular interfaces, redundancy, excess capacity, and reconfiguration paths so that future modification is supported. Where adaptation names the modification of a system to fit new conditions generally, the design-for-adaptability variant fixes the timing — the adaptive capacity is engineered in upfront, before the conditions that will exercise it are known.
Path to root: Design for Lifecycle Adaptability → Modularity
Neighborhood in Abstraction Space¶
Design for Lifecycle Adaptability sits in a moderately populated region (59th percentile for distinctiveness): it has near-neighbors but no dense thicket of synonyms.
Family — Modularity, Architecture & System Design (19 primes)
Nearest neighbors
- Design for Implementation — 0.80
- Divergence-Convergence in the Design Process — 0.79
- Adaptation — 0.78
- Design Patterns — 0.78
- Reverse Engineering — 0.78
Computed from structural-signature embeddings · 2026-05-29
Not to Be Confused With¶
Design for Lifecycle Adaptability must be distinguished from Design for Implementation, which addresses the constraint-driven path to immediate production for current requirements. Design for Implementation asks: "How do we build this system cost-effectively with today's technologies and constraints?" Design for Lifecycle Adaptability asks: "How do we build this system so it can evolve, be modified, and adapt over its entire lifetime?" Design for Implementation optimizes for present conditions—choosing the cheapest manufacturing process, simplest assembly, tightest tolerances achievable with current machinery. Design for Lifecycle Adaptability intentionally introduces slack—modular architecture, standardized interfaces, excess capacity, anticipatory redundancy—before use, to enable future modifications. Design for Implementation might specify a welded structure; Design for Lifecycle Adaptability designs bolted or modular connections. Design for Implementation minimizes initial cost and production complexity; Design for Lifecycle Adaptability invests upfront to reduce lifecycle costs and enable evolution.
Nor is Design for Lifecycle Adaptability identical to Adaptation itself. Adaptation is the actual dynamic adjustment a system makes in response to changed conditions, new requirements, or environmental pressure. A business adapts its strategy to market shifts; an organism adapts its behavior to seasonal change; a system adapts its performance parameters when constraints change. Adaptability, by contrast, is the capacity or readiness to adapt—it is built into the system during design. A bird is born with the adaptability (wing structure, metabolic flexibility) that enables seasonal migration; the actual migration is the adaptation. A software architecture is built with plugin design (adaptability) that enables adding new features without rewriting core code; adding the features is the adaptation. Adaptability is preparatory; adaptation is the act itself. Many systems adapt continuously without being designed for adaptability (through painful retrofitting or full replacement). Systems designed for adaptability adapt more gracefully, cheaply, and safely.
Design for Lifecycle Adaptability is also structurally distinct from Modularity, though modularity is often a key technique for achieving adaptability. Modularity is a specific structural pattern—decomposing a complex system into relatively independent, substitutable units (modules) with clear interfaces. Modularity supports understanding, independent development, reuse, and testing. Design for Lifecycle Adaptability is a broader design orientation that asks: "How will this system need to evolve? What should remain stable? What should change easily?" Adaptability employs modularity as a tool, but also uses other techniques: over-design and excess capacity (build extra margin so the system can handle unforeseen load changes), redundancy (multiple paths so one can be modified without system failure), loose coupling (reduce dependencies so changes propagate minimally), and staged implementation (ability to upgrade incrementally rather than all-at-once). A system can be modular but not adaptable (modular components tightly coupled, all upgrades require redesign), or adaptable without traditional modularity (a monolithic system designed with staged upgrade capabilities and margin for evolution). Modularity is one tactic; adaptability is the strategic design commitment.
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 (1)
Also a related prime in 3 archetypes
Notes¶
Design for Lifecycle Adaptability is grounded in systems engineering, product architecture, manufacturing engineering, and environmental sustainability. The formalization as an explicit design principle originated with the study of how product modularity affects manufacturing flexibility and lifecycle cost (Ulrich, Clark, Baldwin), evolved through design-for-disassembly and circular-economy thinking, and continues through digital and organizational systems. The principle interfaces with Modularity (adaptable systems require modular structures) and with Margin of Safety (excess capacity enables adaptation without performance loss). The concept increasingly intersects with sustainability (designing for disassembly and reuse reduces waste), with regulatory compliance (designing for regulatory evolution), and with technology forecasting (anticipating what technologies and standards will change). The practice is evolving from reactive maintenance (fix things when they break) toward proactive adaptation (design systems that gracefully evolve).
References¶
[1] 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. ↩
[2] Ross, A. M., Rhodes, D. H., & Hastings, D. E. (2008). "Defining changeability: Researching dynamic system architectures." In INCOSE Insight (Vol. 11, No. 1). ↩
[3] 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). ↩
[4] Baldwin, C. Y., & Clark, K. B. (2000). Design Rules: The Power of Modularity (Vol. 1). MIT Press. ↩
[5] Allen, T. J. (1990). "Organizational structures, communication, and group innovation." In Research, Development, and Technological Innovation (pp. 189–207). Springer. ↩
[6] Ellen MacArthur Foundation. (2013). Towards the Circular Economy: Economic and Business Rationale for an Accelerated Transition (Vol. 1). Ellen MacArthur Foundation. Canonical reference framing material-flow closure (every output of one process is an input to another, with minimal external resource extraction and waste output) as the central engineering principle of circular-economy design. ↩
[7] 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. ↩
[8] Suh, N. P. (1990). The Principles of Design. Oxford University Press. ↩
[9] 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. ↩
[10] Thomke, S. H., & Bell, D. E. (2001). "Sequential testing in product development." Management Science, 47(2), 308–323. ↩
[11] 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.
[12] 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.
[13] Cusumano, M. A., & Gawer, A. (2002). Platform Leadership: How Intel, Microsoft, and Cisco Drive Industry Innovation. Harvard Business School Press.
[14] Gawer, A. (Ed.). (2014). Platforms, Markets and Innovation. Edward Elgar Publishing.
[15] Boudreau, K. J. (2010). "Open platform strategies and innovation: Granting access vs. devolving control." Management Science, 56(10), 1849–1872.
[16] 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.
[17] Hyysalo, S. (2010). Health Technology Development and Use: From Practice-Bound Imagination to Evolving Impacts. Routledge.
[18] West, J. (2003). "How open is open enough? Melding proprietary and open source platform strategies." Research Policy, 32(7), 1259–1285.
[19] Grindley, P., & Teece, D. J. (1997). "Managing intellectual capital: Licensing and cross-licensing in semiconductors and electronics." California Management Review, 39(2), 8–41.
[20] Katz, M. L., & Shapiro, C. (1985). "Network externalities, competition, and compatibility." The American Economic Review, 75(3), 424–440.
[21] Eisenmann, T., Parker, G., & Van Alstyne, M. W. (2006). "Strategies for two-sided markets." Harvard Business Review, 84(10), 92–101.