Henkel: IP Modularity

1,135 views

Published on

Joachim Henkel provides an overview of the concept of IP Modularity introduced in his article with Carliss Baldwin and Willy Shih. These three authors claim that firms seeking to take advantage of distributed innovation and outsourcing can bridge the tension between value creation and value capture by modifying the modular structure of their technical systems.

Henkel, J., Baldwin, C. Y., & Shih, W. (2013). IP Modularity: Profiting from innovation by aligning product architecture with intellectual property. California Management Review, 55(4), 65.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,135
On SlideShare
0
From Embeds
0
Number of Embeds
146
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Henkel: IP Modularity

  1. 1. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 1 IP Modularity: Profiting from Innovation by Aligning Product Architecture with Intellectual Property Joachim Henkel1, Carliss Y. Baldwin2, Willy Shih2 1Technische Universität München 2Harvard Business School PDW "Intellectual Property Management and Innovation Appropriability: Towards a New Research Agenda" AoM, 10 August, 2013
  2. 2. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 2 “Every action we take will be done with an eye toward striking this more subtle balance between proprietary and open.“
  3. 3. Technische Universität München Selective openness – Modular architecture • Balance between proprietary and open: selective openness • Selectivity is facilitated by a modular architecture • Modularity to accommodate selective IP treatment: “IP Modularity” IP Modularity • Henkel, Baldwin, Shih 3 vs.
  4. 4. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 4 Example: M-Systems • Seller of embedded flash memory • With open source driver, could have tapped a larger market (Linux) • But: flash management software needed to remain proprietary Sources: http://www.sandisk.com/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=3494; http://linuxdevices.com/news/NS9657944693.html; Kaplan (2006), http://www.linuxdevices.com/articles/AT2185129745.html (figures modified) HOST FLASH MEMORY Driver, incl. Flash Mgmt. SW had to be kept proprietary
  5. 5. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 5 M-Systems’ Solution • In 2006, re-modularized the flash management software: • Now: “thin” driver open, flash management software protected: Sources: http://www.sandisk.com/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=3494; http://linuxdevices.com/news/NS9657944693.html; Kaplan (2006), http://www.linuxdevices.com/articles/AT2185129745.html (figures modified) HOST FLASH MEMORY Thin driver Flash Mgmt. SW could be made open source Driver, incl. Flash Mgmt. SW Thin driver Flash Mgmt. SW
  6. 6. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 6 Existing theory can not explain M-System’s move It was not the aim to… • improve internal functioning • distribute/simplify R&D or production • enable re-use of components • simplify maintenance • satisfy heterogeneous needs • keep flexibility for need changes engineering use HOST FLASH Driver, incl. Flash Mgmt. SW HOST FLASH MEMORY Thin driver Flash Mgmt. SW FLASH MEMORY
  7. 7. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 7 Rationale: IP modularity Kaplan (M-Systems): • “The second generation EFD introduced a new architecture […] • With sensitive IP now embedded in the storage device, flash vendors no longer need to worry about exposing competitive secrets.” Source: Kaplan (2006), http://www.linuxdevices.com/articles/AT2185129745.html
  8. 8. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 8 “IP modularity” is about managing… intellectual property rights and a system’s modular structure in conjunction, such as to reconcile distributed value creation and value appropriation
  9. 9. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 9 Two Types of IP Modularity IP Modularity can relate to… • … the focal innovator’s own IP. Example: M-Systems • … external IP. Example: braking system
  10. 10. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 10 IP Modularity with External IP: Braking System • Car stability system, developed by major car maker • Builds upon a supplier’s braking system • OEM supplies its stability system to the supplier, who then supplies the combined system back to the OEM • To keep the OEM’s technology proprietary from other customers of the supplier, the system was redesigned • Interviewee: “So, as the vehicle develops, as the technology develops, sometimes we need to re-segment both hardware and software modules, or the modularity of the system, based more on the commercial needs of, say, protecting an in-house algorithm, than on just the most efficient design.” OEM A: stability system supplier: braking system
  11. 11. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 11 Braking System and Stability System OEM A: stability system supplier: braking system supplier integrates delivered to other OEMs delivered to OEM A
  12. 12. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 12 • An artifact is “IP modular” when the modular structure imposed by intellectual property rights (IP rights) coincides with its design structure – Comprises formal IP (patents, copyright, contracts) and informal IP (secrecy, lead time, …) • IP-wise, which elements… – shall (own IP) or must (external IP) be treated identically / differently? – will make differential treatment desirable or necessary in the future? What is IP Modularity?
  13. 13. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 13 IP Modularity: Categories TYPE OF IP MODULA- RITY own IP: IP status of modules can be specified external IP: IP status of modules externally given FUTURE NEEDS AND OBLIGATIONS W.R.T. IP certain uncertain
  14. 14. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 14 Own IP / Certain TYPE OF IP MODULA- RITY own IP: IP status of modules can be specified external IP: IP status of modules externally given specification of IP status of own artifact FUTURE NEEDS AND OBLIGATIONS W.R.T. IP certain uncertain Cases in the paper: M-Systems, IBM 360, IBM PC, SMaL, F101 engine, APIs, inkjet printers, Intel vs. AMD
  15. 15. Technische Universität München When IP Modularity implies an integral design Inkjet printers • Two main modules: cartridge, printer itself • Question: where to put the printhead? • Integration with printer: lower cost • But: HP, Canon integrated printhead with cartridge • Rationale: cartridge linked to revenues, but weak IP; Integration extended the printhead’s stronger IP to cartridge  Modular architecture determined by IP IP Modularity • Henkel, Baldwin, Shih 15 Source of figure: HP
  16. 16. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 22 Conclusions • IP must be taken into account when devising product architecture – applies to products, but also to processes and organizations – also informs the established theory of modularity • IP modularity allows… – to resolve conflicts between value co-creation and value capture – to avoid hold-up arising from incoming IP • IP modularity is increasingly important – open and semi-open innovation processes matter more – IP increasingly important • IP modularity is an issue for strategy – affecting value appropriation and business models – being of a long-term nature Thank you
  17. 17. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 23 Comments welcome Prof. Dr. Joachim Henkel Technische Universität München Arcisstr. 21 D – 80333 Munich henkel@wi.tum.de http://www.wi.tum.de/tim +49 - 89 - 289 25741
  18. 18. Technische Universität München BACKUP IP Modularity • Henkel, Baldwin, Shih 24
  19. 19. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 25 But: Modularity can also pose risks for value capture Examples: • IBM System/360 • IBM PC
  20. 20. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 26 Unhappy outcomes (1) IBM System/360 • Modularize the technical system • Identify the possibility for external value creation • Assert exclusive control of knowledge elements for an essential module • Prevent exclusive control by others of knowledge elements for comple- mentary modules
  21. 21. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 27 Unhappy outcomes (2) IBM PC • Modularize the technical system • Identify the possibility for external value creation • Assert exclusive control of knowledge elements for an essential module • Prevent exclusive control by others of knowledge elements for comple- mentary modules
  22. 22. Technische Universität München Illustration (1) IP Modularity • Henkel, Baldwin, Shih 28 B B B B A A A (a) B B B B A A A (b) B B B B A A A (a) B B B B A A A (b) Note: Elements A, B have distinct IP status Systems with integral (a) and IP-modular (b) structure
  23. 23. Technische Universität München Illustration (2) IP Modularity • Henkel, Baldwin, Shih 29 Note: Elements A, B have distinct IP status Systems with modular (a) and IP-modular (b) structure B B B B A A (a) A B B B B B A A (b) A B A A B B B B A A (a) A B B B B B A A (b) A B A A
  24. 24. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 30 “IP incompatibility” • A: OSS code under the GPL • B: from commercial supplier; license forbids disclosing the source code • C: developed in-house; right to read, but not to modify, shall be granted • Elements in the same component can not be separated and treated differently! A B B A C CC B AB C B not IP modular Strong IP incompatibility in all components, in particular those containing A and B IP modular A B B A C CC B AB C B Components can be treated in distinct ways; they are “IP Modules”
  25. 25. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 31 How modularity enhances value creation (1/2) Cognitive • Facilitates understanding of complex artifacts • E.g., Simon (1969), Parnas (1972), Aoki (2001) Organizational • Enables division of labor (intra/inter firm, for R&D/production) • Intra firm: e.g., Brooks (von Hippel (1990), Sanchez and Mahoney (1996), Baldwin and Clark (2000), Chesbrough and Kusunoki (2001), Takeishi (2002), Puranam and Jacobides (2005), Brusoni and Prencipe (2006), Hoetker (2006), Colfer (2007) • Inter firm: e.g., Langlois and Robertson (1992), Baldwin and Clark (1997), Sturgeon (2002), Langlois (2003), and Staudenmayer et al. (2005), Baldwin (2007), Ethiraj (2007), Ethiraj et al. (2007)
  26. 26. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 32 How modularity enhances value creation (2/2) Functional • Improves internal functioning, enables re-use of components, simplifies maintenance • E.g., Parnas (1972), Henderson and Clark (1990), Garud and Kumaraswamy (1995), Ulrich (1995), Baldwin and Clark (2000), Langlois (2002), MacCormack and Iansiti (2004) Use • Satisfies heterogeneous demand, increases flexibility, allows selective upgrades • E.g., von Hippel and Finkelstein (1979), Baldwin and Clark (2000), Schilling (2000)
  27. 27. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 33 Consequences of Modularity • Modularity allows for distributed value creation – open innovation, outsourced production etc. • BUT: modularity may have undesired consequences (IBM 360, PC); the focal firm may lose control and hence fail to appropriate value • Strategic challenge: To appropriate value in a modular system • IP Modularity helps to avoid such loss of control, reconciling distributed value creation and value capture • It is obtained by managing architecture – module boundaries – and IP status of modules jointly
  28. 28. Technische Universität München IP Modularity • Henkel, Baldwin, Shih 34 Scope conditions for argument • Complex products and processes – Many components • Components are complementary – Functional system needs several components – Some components are essential, some are not • Designers have some degree of choice in dividing up components and defining module boundaries – Architectural freedom
  29. 29. Technische Universität München Summaries of Findings: Own IP / Certain • Potential for value co-creation in the ecosystem. Whenever the potential for value co-creation exists in the surrounding ecosystem, distributing own IP into relatively unprotected “open” modules and highly protected “closed” modules will be advantageous. • Distributed co-creators. The more distributed, numerous, and anonymous the co-creators of value, the more advantageous it is to establish an IP modular system made up of unprotected open modules and protected closed modules. • Customization. The greater and more varied the need for customer adaptations, the more advantageous the more advantageous it is to establish an IP modular system made up of unprotected open modules and protected closed modules. • Avoiding IP leakage. When the focal firm must rely on opportunistic suppliers and/or employees and its IP is not strongly appropriable, distributing own IP into discrete, non-overlapping modules with little or no stand-alone value and allocating responsibility for each module to a different supplier or business unit will be advantageous. IP Modularity • Henkel, Baldwin, Shih 35
  30. 30. Technische Universität München Summaries of Findings: External IP / Certain • Avoid compromising own IP through integration with external IP. When distributed value creation requires linking the components under the focal firm’s own IP with components under external IP such that the bundle is beyond the firm’s control, an IP-modular architecture helps avoid compromising the firm’s own IP. • Holdup risk. IP modularity with external IP is advantageous when the focal firm faces the risk of holdup from IP suppliers. The module boundaries should go between the firm’s own IP and the external IP. • Distributed ownership of external IP. IP modularity with external IP is advantageous when the focal firm obtains IP on different terms from diverse sources. Module boundaries should be placed to ensure IP-compatibility within modules and to minimize the costs of renegotiation. In particular, it should be possible to change the IP status of a module without renegotiating numerous IP licenses. • Establishing control of external open IP through integration with own IP. Integrating an “open” component under external IP with an own component under strong appropriability into one module may allow to establish control of the open component. IP Modularity • Henkel, Baldwin, Shih 36
  31. 31. Technische Universität München Summaries of Findings: Uncertain • Uncertainty and Own IP. An “overly modular” product or process architecture creates options to capture value in the future by selectively adapting the IP status of individual modules. Such options for IP modularity of own IP are more valuable in the presence of high market or technological uncertainty. • Inadvertent infringement. A product or process architecture characterized by IP modularity is a partial defense against unanticipated external IP claims, because it gives the firm options to “design around” the claims without redesigning the whole system. IP Modularity • Henkel, Baldwin, Shih 37

×