Appropriating Value in
Modular Systems
Carliss Y. Baldwin
(Joint work with Joachim Henkel, DSMs with Alan
MacCormack, John Rusnak)
Linkopings University
September 17, 2009
Slide 1
© Carliss Y. Baldwin, 2009
Plan of the Talk
υ
υ
Two kinds of industry disruption
What is modularity?
– Seeing modular boundaries
υ
υ
Modularity is a strategic decision
Appropriating value in a modular system
– Drawing the boundaries of intellectual
property
Slide 2
© Carliss Y. Baldwin, 2009
Industry disruption
υ
In 1996, Andy Grove, CEO of Intel, described a verticalto-horizontal transition in the computer industry:
1980-“Vertical Silos”
1995-“Modular Cluster”
Slide 3
© Carliss Y. Baldwin, 2009
“Everyone was surprised…”
Slide 4
© Carliss Y. Baldwin, 2009
Industry Architecture =
Grove’s Layers with Data
υ
Take a sector, and consider the basic SIC / NAISC
codes
– 4 to 6 digit codes to compose the entire “ecosystem” as it
evolves
– Work with industry experts to construct the sectors’ list
υ
Tabulate the results in terms of “verticals” and
“horizontals”
– Objective: see how profit shifts from vertical to horizontal
layers
– …and how much “churn” there is within layers
υ
Map “Top N” Companies each year
Slide 5
© Carliss Y. Baldwin, 2009
What a map looks like… Computers, 1979
Slide 6
© Carliss Y. Baldwin, 2009
Slide 7
© Carliss Y. Baldwin, 2009
Slide 8
© Carliss Y. Baldwin, 2009
Slide 9
© Carliss Y. Baldwin, 2009
Slide 10
© Carliss Y. Baldwin, 2009
Slide 11
© Carliss Y. Baldwin, 2009
Slide 12
© Carliss Y. Baldwin, 2009
Slide 13
© Carliss Y. Baldwin, 2009
Slide 14
© Carliss Y. Baldwin, 2009
Slide 15
© Carliss Y. Baldwin, 2009
Slide 16
© Carliss Y. Baldwin, 2009
Slide 17
© Carliss Y. Baldwin, 2009
Slide 18
© Carliss Y. Baldwin, 2009
Slide 19
© Carliss Y. Baldwin, 2009
Slide 20
© Carliss Y. Baldwin, 2009
Slide 21
© Carliss Y. Baldwin, 2009
Slide 22
© Carliss Y. Baldwin, 2009
Slide 23
© Carliss Y. Baldwin, 2009
Slide 24
© Carliss Y. Baldwin, 2009
Slide 25
© Carliss Y. Baldwin, 2009
Slide 26
© Carliss Y. Baldwin, 2009
Slide 27
© Carliss Y. Baldwin, 2009
Slide 28
© Carliss Y. Baldwin, 2009
Slide 29
© Carliss Y. Baldwin, 2009
Slide 30
© Carliss Y. Baldwin, 2009
Slide 31
© Carliss Y. Baldwin, 2009
The End of the Verticals
Value forced the industry to a new
shape/structure
Does this always happen?
Slide 32
© Carliss Y. Baldwin, 2009
Look at the auto industry—
the “mother” of industrial
theory
Slide 33
© Carliss Y. Baldwin, 2009
In the beginning (1984)
Slide 34
© Carliss Y. Baldwin, 2009
Slide 35
© Carliss Y. Baldwin, 2009
Slide 36
© Carliss Y. Baldwin, 2009
Slide 37
© Carliss Y. Baldwin, 2009
Slide 38
© Carliss Y. Baldwin, 2009
Slide 39
© Carliss Y. Baldwin, 2009
Slide 40
© Carliss Y. Baldwin, 2009
Slide 41
© Carliss Y. Baldwin, 2009
Slide 42
© Carliss Y. Baldwin, 2009
Slide 43
© Carliss Y. Baldwin, 2009
Slide 44
© Carliss Y. Baldwin, 2009
Slide 45
© Carliss Y. Baldwin, 2009
Slide 46
© Carliss Y. Baldwin, 2009
Slide 47
© Carliss Y. Baldwin, 2009
Slide 48
© Carliss Y. Baldwin, 2009
Slide 49
© Carliss Y. Baldwin, 2009
Slide 50
© Carliss Y. Baldwin, 2009
Slide 51
© Carliss Y. Baldwin, 2009
Slide 52
© Carliss Y. Baldwin, 2009
Slide 53
© Carliss Y. Baldwin, 2009
Slide 54
© Carliss Y. Baldwin, 2009
The industry turned over, but
most value stayed in the OEM
layer…
Slide 55
© Carliss Y. Baldwin, 2009
Why such different patterns?
– Computers => new layers
– Autos => drastic turnover within
the OEM layer
Slide 56
© Carliss Y. Baldwin, 2009
Different Modularity
of underlying products and processes
Slide 57
© Carliss Y. Baldwin, 2009
What is modularity?
Slide 58
© Carliss Y. Baldwin, 2009
Non-modular Task Structure—
Design of an Aircraft Engine
Sosa, Eppinger,
Rowles,
Management
Science, 2004
Potential
Flowpath of
Decisions
Slide 59
Within a single
firm—Pratt &
Whitney
8 subsystems,
54 components,
54 teams
© Carliss Y. Baldwin, 2009
Modular Task Structure—
Open Office v1.0
Database
Calc spreadsheet
Presentations,
charts, drawing
Write word processor
Graphics system
Slide 60
© Carliss Y. Baldwin, 2009
What is modularity?
υ
Interdependence within and (relative) independence
between groups of elements in a network of tasks or
decisions
– A network property
– H. Simon (1964): “near-decomposability”
– Achieved through hierarchical design rules=constraints
υ
“Information hiding”
– Outside elements don’t “need to know” very much about
what happens inside a module (Parnas, 1972)
– Consequence of sparseness of dependencies between
modules
Slide 61
© Carliss Y. Baldwin, 2009
Creating Modularity:
DSM of a Laptop Computer Design
Drive
System
. x x
x
x
x
x . x x x
x
x
x
x x . x
x
x x x . x x
x x x
x
x
x
. x
x x x x . x x
x
x
Main
Board
x
x
x
.
x
x
x . x
x
x x . x
x
x
x .
x x
x x x x x x
x
x
x x
x x
x
x
x x
x
LCD
Screen
x
x
x
x
x
x x
x x
x x
. x
x
x . x
x x . x
x .
x
x
x
x
x
x
x
x x
x
x
x . x x
x
x
x
x x . x x x
x
x
x
. x
x
x x x . x x
x x x x
x x x . x
x
x x .
x x
x
x
x
x
x
x
x
x
x
. x
x x
x . x x
x x
x x .
x
x
x x x . x
x
x x
. x
x
x
x . x
x
x
x .
x x
x x x
x x
x
x
Packaging
x x
x
x
x x x
x
x x
x
x
x
x
.
Graphics controller on Main Board or not?
If yes, screen specifications change;
If no, CPU must process more; adopt different interrupt protocols
Slide 62
© Carliss Y. Baldwin, 2009
Eliminating Iterations by Creating a
New Design Rule = Constraint
Design
Rules
.
Main
Board
Graphics Controller - Yes/no
.
x
x
x
x
Drive
System
x
.
x
x
x
x
.
x
x
x x
x
x
x
x
x x
x
x x
x
x
x
x
x x
x
x
x
x
x
. x x
x x x
x
. x
x x . x x
x
x .
x
x . x
x
x x . x x
x
x .
x x x x x x .
x
x x x
x x
x
x x
x x
x
x
x
x
x .
x
x
x x
x
x
x
x
x x x x
x x
x
x
x
x x
x
x x
. x x
. x
x x .
x x x
x
x
x
x
x
x x x
x
x x
Slide 63
x
x
x
x
x
x
x
x x
x x
x
x
. x
x . x
x .
x x
Packaging
x x
x
x
x
LCD
Screen
x
x
x
x
x
x
x x
. x
x .
x
x
x
x
. x
x
x . x x
x x .
x x x .
x x
x
x
x
x
x x
x
x
x x
x
x
x
x
. x
x . x
x .
x x x
x
x
x
.
© Carliss Y. Baldwin, 2009
Modularization via Design Rules
Design
Rules
Drive
System
Main
Board
LCD
Screen
Packaging
System
Testing
& Integration
. x x x x
x . x x
x . x x
x x
. x
x x x
.
x
. x x
x
x . x
x
x
x x .
x
x
x x x
x
x
x
x x
x
x x x x
x x
x
x
x x
x
x
x x
x x
x x
x x
x
x
x x
x
x
x x
x x
x
x
x x
x
x x
x
x
x
x
x
x
x
x
x
x
x
x
x x
x
Design Rules Task Group
x
x x
x
. x x
. x
x x .
Hidden Modules
many Task groups
.
x
x . x
x x . x
x
x .
x x x x
x
x x
x
x
x x
x
x
x
x x
x
x x
. x
x
x . x
x x . x
x .
. x x
x . x
x
.
x x x
x x
x
x
x
x x
x
. x x
x . x
x x .
. x
x
x . x x
x x .
x x x .
x x
x
x
x
x
x x
x
x
x
x
x
x
x
x
x
x
x
Slide 64
x
x
x
x
x
x
x
x
x
x
x
x
x
x x
x
x
x
x
. x
x . x
x .
x x x
x
x
x
x
.
x
x
x
x
x
x
.
x
x
x
x
x
x
x
. x
x . x
x x x
x
x
x
x x
x
System
x x Integration
x
and Testing
. x Task Group
.
© Carliss Y. Baldwin, 2009
Modularity is a strategic decision
Slide 65
© Carliss Y. Baldwin, 2009
Same function, different structure
Mozilla Before Redesign
Change Cost = 17.35%
Mozilla After Redesign
Change Cost = 2.38%
© Alan MacCormack, Johh Rusnak and Carliss Baldwin, 2006
Same function, different
structure
—Linux vs. Open Solaris
Slide 67
© Carliss Y. Baldwin, 2009
Same function, different structure—
Web server platform component
Before Modulariziation
After Modulariziation
No
Dependencies
Slide 68
© Carliss Y. Baldwin, 2009
Consequences of Modularity
υ
Reduces cognitive complexity
υ
Isolates failures and defects
υ
Enables parallel work
υ
Supports high variety and customer upgrades
υ
System can evolve over time without central control
Low transaction costs at module boundaries
– Knowledge management
– Risk management
– Process management
– Product line management
υ
– “thin crossing points” in the network (info hiding)
Get all consequences whether you want
them or not!
Slide 69
© Carliss Y. Baldwin, 2009
Danger for firms—
Pursue one property of
modularity & get the rest whether
you want them or not!
Low transaction costs, decentralized
innovation & evolvability are
especially dangerous!
Slide 70
© Carliss Y. Baldwin, 2009
Strategic challenge: To
appropriate value in a modular
system
Management of Knowledge and
Intellectual Property
Slide 71
© Carliss Y. Baldwin, 2009
Unhappy Story 1—IBM System/360—
New, modular product line
1
1
2
3
4
5
6
2
3
4
5
6
7
8
9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
SLT architecture and standard circuits
Erich Bloch - August 1961
New Processor Line Architectural Ground Rules
SPREAD Task Group - 12/28/61
New Processor Line control, product and programming standards
Corporate Processor Control Group (CPC) - 4/1/62
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
SLT Transistors
SLT Modules
SLT Cards
SLT Boards and Automatic Wiring
Processor
Processor
Processor
Processor
Processor
12345-
Endicott, New York
Hursley, England
Poughkeepsie, New York
Poughkeepsie, New York
Poughkeepsie, New York
Main memories, Corporate Memory Group (1)
Internal memories, CMG
Read-only memories for control, CMG
"Binary-addressed" Random Access Files
Corporate File Group (2)
Tape devices running at 5000+ char/sec
Corporate Tape Group (3)
Time-multiplex system for switching I/O devices
DSD Technical Development Group
Techniques to measure processor performance, system
throughput and software efficiency, Group Staff
A unified Input/output Control Structure (IOCS)
System Software for Configuration I (4)
System Software for Configuration II (4)
System Software for Configuration III (4)
FORTRAN and COBOL compilers
A unified programming language
33
34
35
Announcement and Marketing
Production, Testing and Integration
Shipment, Delivery and Installation
Slide 72
© Carliss Y. Baldwin, 2009
By 1980, 100s of firms made S/360
“plug-compatible” components
Code
Category Definition
3570
3571
3572
3575
3576
3577
3670
3672
3674
3678
7370
Computer and Office Equipment
Electronic Computers
Computer Storage Devices
Computer Terminals
Computer Communication Equipment
Computer Peripheral Devices, n.e.c.
Electronic Components and Accessories
Printed Circuit Boards
Semiconductors and Related Devices
Electronic Connectors
Computer Programming, Data Processing,
and Other Services
Computer Programming Services
Prepackaged Software
Computer Integrated Systems Design
Computer Processing, Data Preparation
and Processing
Computer Leasing
1960
1970
1980
5
1
1
2
1
3
11
2
8
5
2
8
6
5
1
5
7
19
4
15
1
0
0
1
9
2
7
3
26 *
12 *
13 *
16
0
0
41
5
10
108
29 *
7 *
298
* Firms in these subindustries make modules of larger computer systems.
Firms making modules =
34
Percent of total =
83%
95
88%
7371
7372
7373
7374
7377
Slide 73
9
29
36
23
10
12
11
39
10
16
*
*
*
*
*
*
*
*
244
82%
© Carliss Y. Baldwin, 2009
Unhappy story 2—IBM PC—Modular
architecture, everything outsourced
Slide 74
© Carliss Y. Baldwin, 2009
Then …
υ
υ
υ
υ
υ
Compaq and then Phoenix Technologies
reversed engineered the BIOS
Taiwanese manufacturers made clones at
lower cost than IBM made PCs
Intel refused to second-source 386 chip
Microsoft developed Windows indepenently
of IBM
By 1993, IBM had lost control of the
system and was struggling to make money
Slide 75
© Carliss Y. Baldwin, 2009
Happy Story—Valve
and Counterstrike
Slide 76
© Carliss Y. Baldwin, 2009
Source: http://www.cback.de/spiele/bilder/css1.jpg
Source: http://www.gulli.com/fileadmin/news_teaser/counterstrike-screenshot.jpg
Counter-Strike
Valve Software modularized the code of its PC game Half-Life:
core
engine,
proprietary
Valve profits
by selling the
core engine
complementing code,
publicly available,
modifications allowed
Users developed the popular modification
Counter-Strike
Without Counterstrike, much lower demand for
Valve’s product
* Source: For the history of Counter-Strike see Jeppesen, “Profiting from innovative user communities”, 2004
Slide 77
© Carliss Y. Baldwin, 2009
Without the protected core
engine…
No profits for Valve!
Slide 78
© Carliss Y. Baldwin, 2009
What did Valve have to do to
achieve this happy outcome?
This brings us to knowledge flows and
property rights
Slide 79
© Carliss Y. Baldwin, 2009
By means of information hiding,
module boundaries segregate
knowledge and knowledge flows
Knowledge relevant to Module 1
does not interact with knowledge
relevant to Module 2
Slide 80
© Carliss Y. Baldwin, 2009
Conversely…
Knowledge elements relevant to
decisions within a module cannot
be segregated…
Without severely jeopardizing
performance of the product or process
Slide 81
© Carliss Y. Baldwin, 2009
What allows the free exchange of
knowledge within a module?
Property rights!
De jure—Ownership and Licenses
De facto—Possession and Secrecy
Slide 82
© Carliss Y. Baldwin, 2009
What is IP Modularity?
υ
A system is “IP modular” when the structure of
intellectual property rights (IPR) is congruent with
the system’s modular decision-making structure
υ
Knowledge can then flow freely within modules
υ
Because of information hiding, knowledge does not
have to flow freely across modules
Slide 83
© Carliss Y. Baldwin, 2009
Violation of IP Modularity (LaMantia et.
al. 2008)
Licensed-in
code distributed
throughout
codebase
The license was
about to expire
Creating a classic
holdup problem
Slide 85
© Carliss Y. Baldwin, 2009
Redesign to achieve IP modularity
Before Modulariziation
After Modulariziation
No
Dependencies
Licensed
Code
Slide 86
© Carliss Y. Baldwin, 2009
What did the platform firm do?
υ
υ
υ
υ
Create congruence between module and
knowledge boundaries
Achieve IP modularity in the system
(knowledge-ownership compatibility within
modules)
Assert exclusive control of knowledge for
an essential module (the platform)
Prevent exclusive control by others of
knowledge elements for complementary
modules (the licensed code)
Slide 87
© Carliss Y. Baldwin, 2009
Valve’s design exhibited IP
modularity (happy outcome)
υ
υ
υ
The engine’s source code was both
secret and copyrighted (double IP
protection of Bs)
The APIs (As) needed to create a
new game utilizing the engine
were published and licensed for
non-commercial use
The non-commercial use provision
in the license prevented value
appropriation by another
commercial entity (Cs could not
threaten Valve)
Slide 88
IP modular
B
A
B
A
B
B
B
C
A
C
C
C
© Carliss Y. Baldwin, 2009
What did Valve have to do to
achieve this happy outcome?
υ
υ
υ
υ
Create congruence between module and
knowledge boundaries
Achieve IP modularity in the system
(knowledge-ownership compatibility within
modules)
Assert exclusive control of knowledge for
an essential module (the engine)
Prevent exclusive control by others of
knowledge elements for complementary
modules (the game)
Slide 89
© Carliss Y. Baldwin, 2009
All four steps are necessary to
appropriate value in a modular
system
Slide 90
© Carliss Y. Baldwin, 2009
Unhappy story—1
Slide 91
© Carliss Y. Baldwin, 2009
Unhappy story—2
Slide 92
© Carliss Y. Baldwin, 2009
This is work in progress…
Comments and examples most
welcome!
Slide 93
© Carliss Y. Baldwin, 2009
How to conduct strategy in a
modular system
Slide 94
© Carliss Y. Baldwin, 2009
Create a map
Database
Calc spreadsheet
Presentations,
charts, drawing
Write word processor
Graphics system
Slide 95
© Carliss Y. Baldwin, 2009
Identify or choose IP status for each
module and interface
υ
Open Source
– Transparent IP “all the way through”
– Different licenses protect openess of derivative products: BSD vs
GPL
υ
Open Standards=Open Interfaces (Platform architecture)
– Anyone can hook up
– Protect your core/platform
υ
Proprietary licensed
– Need legal protection: patents and/or copyright
– Strong appropriability regime
υ
Proprietary hidden
– Relies on secrecy and tacit knowledge
Slide 96
© Carliss Y. Baldwin, 2009
Color the map according to IP Status
Database
Calc spreadsheet
Presentations,
charts, drawing
Write word processor
Graphics system
Slide 97
© Carliss Y. Baldwin, 2009
Identify dependencies
=> control points
Database
Calc spreadsheet
Vertical lines
indicate
dependencies
Slide 98
Presentations,
charts, drawing
Write word processor
Graphics system
© Carliss Y. Baldwin, 2009
The map indicates both threats
and opportunities
This is strategy in a networked world
Slide 99
© Carliss Y. Baldwin, 2009
Thank you!
Slide 100
© Carliss Y. Baldwin, 2009