NFRS Seminar - Harvard Business School

Download Report

Transcript NFRS Seminar - Harvard Business School

Design Rules:
How Modularity Affects the Value of
Complex Engineering Systems
Carliss Y. Baldwin
Harvard Business School
International Conference on Complex Systems (ICCS 2004)
Quincy, Massachusetts
May 20, 2004
Three Points
 Modularity
in Design is a financial force
– that can change the structure of an industry.
 Value
and Cost of Modularity
– it can increase financial value,
– but it is NOT free.
 Implications
for Organizations and Firms
 Open Questions/Applications
Slide 2
© Carliss Y. Baldwin and Kim B. Clark, 2004
This is an emergent modular
cluster
800
700
600
$ billion
500
400
300
200
100
66
70
74
78
82
86
90
98
02
7377
7373
7374
58
7372 ex Microsoft
7371
62
Microsoft
3678
7370
Intel
3674 ex Intel
3672
3577
3670
3575
3576
3571
3572
IBM
Slide 3
3570 ex IBM
0
94
54
50
© Carliss Y. Baldwin and Kim B. Clark, 2004
SIC Codes in the Database
SIC
Code
3570
3670
3674
3577
3678
7374
3571
3575
7373
3572
7372
3576
3672
7370
7371
7377
(1)
(2)
Slide 4
Category Definition
Start Date (1)
Computer and Of f ice Equipment
Electronic Components and Accessories
Semiconductors and Related D ev ices
Computer Peripheral Dev ices, n.e.c.
Electronic Connectors
Computer Processing, Data Preparation and Processing
Electronic Computers
Computer Terminals
Computer Integrated Sy stems Design
Computer Storage Dev ices
Prepackaged Sof tware (2)
Computer Communication Equipment
Printed Circuit Boards
Computer Programming, Data Processing, and Other
Serv ices
Computer Programming Serv ices
Computer Leasing
1960
1960
1960
1962
1965
1968
1970
1970
1970
1971
1973
1974
1974
1974
1974
1974
Start date is the f irst y ear in which six or more are present in the category .
This category had six f irms in 1971, dipped to f iv e in 1972, and back to
six in 1973.
© Carliss Y. Baldwin and Kim B. Clark, 2004
Virtues of Modularity
 1st
Virtue: decentralizes knowledge and
distributes action
– Makes more complexity manageable
– Enables parallel work
 2nd
Virtue: tolerates uncertainty
– “Welcomes experimentation”
– —> Creates Options
– Property of “evolvability”
Slide 5
© Carliss Y. Baldwin and Kim B. Clark, 2004
The Bright Side of Modularity
Slide 6
© Carliss Y. Baldwin and Kim B. Clark, 2004
The Dark Side …
4500
4000
3500
3000
$ billion
2500
2000
1500
1000
500
0
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02
Slide 7
© Carliss Y. Baldwin and Kim B. Clark, 2004
Types of Modularity
 Modular
in Design
– Modern computers
– Eclectic Furniture (not “modular” furniture)
– Recipes in a cookbook
 Modular
in Production
– Engines and Chassis
– Hardware and software
– NOT chips, NOT a cookbook
 Modular
in Use
– “Modular” furniture, bedding
– Suits and ties
– Recipes in a cookbook
Slide 8
© Carliss Y. Baldwin and Kim B. Clark, 2004
Designs are Options
 Option
= “right but not the obligation”
 A new design confers
– “the ability but not the necessity” to use it
– Hence it is an “real” option
Slide 9
© Carliss Y. Baldwin and Kim B. Clark, 2004
Three Consequences
 More
risk is valuable
 Seemingly redundant efforts are valueincreasing (up to a point)
 Modularity creates more options
Slide 10
© Carliss Y. Baldwin and Kim B. Clark, 2004
Modularity Creates Design Options
System after Modularization
System Before Modul arizati on
Design
Rules
System
Option
Option
Option
Option
Option
Split options,
decentralize decisions,
fragment control
Evolution
Slide 11
Option
Option
Option
© Carliss Y. Baldwin and Kim B. Clark, 2004
Design Options are Valuable
How Valuable?
Ask a financial economist…
What is the value of…
 Splitting
a design into J modular building
blocks…and
 Running multiple experiments (K of them)
on each of the modules… and
 Choosing the “best of breed” of each
module… and
 Combining the best modules to arrive at the
system?
Slide 13
© Carliss Y. Baldwin and Kim B. Clark, 2004
Robert C. Merton
 “Theory
of Rational Option Pricing”,
– Written for— MIT PhD thesis, 1971;
– Published in— Bell Journal of Economics and
Management Science, 1973;
– Awarded— Nobel Prize in Economics, 1997
 “A
portfolio of options is worth more than
the option on a portfolio.”
Slide 14
© Carliss Y. Baldwin and Kim B. Clark, 2004
What is the value of…




Splitting a design into J
modular building
blocks…and
Running multiple
experiments (K of them)
on each of the modules…
and
Choosing the “best of
breed” of each module…
and
Combining the best
modules to arrive at the
system?
Slide 15


Going from one big
indivisible block to many
smaller building blocks
And trying out a number
of designs on each small
block

Where each design is a
(little) option

That gets recombined
with others in a (large)
portfolio
© Carliss Y. Baldwin and Kim B. Clark, 2004
Th e Ba si c Fr am ewor k of ou r Mod e l of Mod u l ar De si gn P roc e ss
S ta ge s
S ta ge 1
S ta ge 2
S ta ge 3
Tim e
L in e
Cre a te
Tas k
Str uc ture &
I mpl em ent
Tas k
Str uc ture
Tes t,
I nt egra t e,
Eva lua te
De si gn Rule s
f or Modul es
Sys te m
What Ac tuall y H appens
A c ti on s
Choose
opera tor s
E ven t s
S pl it ting
S ubs tit ut ing
Augmenting
E xc lud ing
Car r y out
ta s ks
T es t result s &
E xer cis e opt ions
" T h e W h eel Sp ins"
E conomi c
val ue i s r eveal ed ;
B es t outc om es
a re s elec ted
Inver ti ng
Por ti ng
Mathe matic al Repres e ntati on
Be n efi ts
Cos ts
Ba si s of
Ch oic e
Slide 11
A pa yoff in
the form of
a ra nd om
var ia ble is
c hosen.
An out come is d ra w n
fr om the d is tri but ion
of t he r and om var ia bl e.
X
X
Cos t of
Cos t of
Cos t of
d es igning
ta s k
s tructure
impl ement ing
ta s k
s tructure
test ing a nd
integra ti on
Highes t
Net Opti on
V a lue
Highes t
Net Opti on V a lue
given t as k st ruct ur e
Highes t
V a lue gi ven
out comes a nd test s

X
T he va lue c orr es pond ing
to t he outcome of t he
r and om va r ia bl e
is r evea l ed ; w here
opt ions exi st , the best
out comes a r e s el ec ted .
ma x ( X, 0)
© Carliss Y. Baldwin and Kim B. Clark, 2001
The Value of Splitting and Substitution
30
25
20
15
Value
10
5
0
25
21
17
25
13
19
No. of Experiments
9
13
No. of Modules
5
7
1
Slide 17
© Carliss Y. Baldwin and Kim B. Clark, 2004
When and if it arrives…
Modularity in design is
compelling, surprising and
dangerous…
Slide 18
© Carliss Y. Baldwin and Kim B. Clark, 2004
Dangerous for whom?
Slide 19
© Carliss Y. Baldwin and Kim B. Clark, 2004
IBM System/360
 The
first modular computer design
 IBM did not understand the option value it
had created
 Did not increase its inhouse product R&D
 Result: Many engineers left
– to join “plug-compatible peripheral” companies
 San
Jose labs —> Silicon Valley
“Compelling, surprising, dangerous”
Slide 20
© Carliss Y. Baldwin and Kim B. Clark, 2004
Entry into Computer Industry
1960, 1970, 1980
Cod e Categ ory Definiti on
3570
3571
3572
3575
3576
3577
3670
3672
3674
3678
7370
7371
7372
7373
7374
7377
Computer and Of f ice Equipment
Electronic Comput ers
Computer Storage Dev ices
Computer Terminals
Computer Communication Equipment
Computer Peripheral Dev ices, n.e.c.
Electronic Components and Accessories
Printed Circuit Boards
Semiconductors and Related Dev ices
Electronic Connectors
Computer Programming, Data Processing,
and Other Serv ices
Computer Programming Serv ices
Prepackaged Sof tware
Computer Integrated Sy stems 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
9
29
36
23
10
12
11
39
10
16
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 comput er sy stems.
Firms making modules =
34
95
244
Percent of total =
83%
88%
82%
Slide 21
© Carliss Y. Baldwin and Kim B. Clark, 2004
Mapping the Modular Structure
of a Complex Engineering
System
We can “see” a system’s modular
structure via a
Design Structure Matrix (DSM) Map
Design Structure Matrix Map of a Laptop Computer
Dri ve
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
Ma in
B oa r d
x
x
x .
x .
x
x x
x
x
x x
x x x x
x
x
x x
x
x
x
x
x
. x x
x .
x x .
x x x
x x
x x
x
L CD
Scr een
x
x
x
x
x
x x
x x
x
x
. x
x . x
x .
x
x
x
x
x
x
x x
x
x
x . x x
x
x
x
x x . x x x
x
x
x
. x
x
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
x
x
x
x
. x
x x
x . x x
x x
x x .
x
x
x x x . x
x
x x
. x
x
x
x . x
x
x
x .
x x
x x x
x
x
x
x
.
Gra p hics controller on Main Boa rd or not?
If yes, scr een speci fica tions change;
If no, CPU must pr ocess mor e; a dopt d i ffer ent i nter rupt pr otocols
Slide 23
© Carliss Y. Baldwin and Kim B. Clark, 2004
Design Structure Matrix Map of a Modular System
Design
Rules
Driv e
Syst em
. 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
.
x
x
x x
x
x x
x
. x x
. x
x x .
x
x x x x
Main
Board
LCD
Screen
Pac kaging
Syst em
Testing
& Int egration
x x
x
x
x x
x
x
x x
x x
x x
x x
x
x
x x
x
x
x x
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 24
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
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
.
x
x
x
x
x
x
x
.
x
x
x
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 Integrat ion
and Testing
x Task Group
.
© Carliss Y. Baldwin and Kim B. Clark, 2004
A “modularization” (splitting) of a
complex design goes from Map A to
Map B
Via Design Rules, which specify
 Architecture, Interfaces and Module
Tests, that provide
 Encapsulation and Information Hiding.

Mapping Modular Structures
over Time
 “Modular
Design Evolution”
(MDE)
 John Holland’s theory of CAS
Design Hierarchy View
Global Design Rules
Module A
Module B
Module C
Module D
System
Integration
& Testing
The sy stem comprises f our "hidden" modules and a "Sy stem Integration and Testing"
stage. From the standpoint of the designers of A B, C, and D (the hidden modules),
sy stem integration and testing is simply another module: they do not need to know the
details of what goes on in that phase as long as they adhere to the global design rules.
Obv iously , the conv erse is not true: the integrators and testers hav e to know something
about the hidden modules in order to do their work. How much they need to know depends
on the completeness of the design rules. Ov er time, as knowledge accumulates, more
testing will occur within the modules, and the amount of inf ormation passed to the
integrators will decrease. The special, time-dependent role of integration and testing
is noted by the heav y black border around and gray shading within the "module."
Slide 27
© Carliss Y. Baldwin and Kim B. Clark, 2004
Six Modular Operators
System I Gl obal Desi gn Rul es
System
Integr ation
& Testing
Modul e F
Desi gn Rul es
Modul e C
Modul
Modulee B
B
D-E Design Rules
System I
Modul e F
Transl ator
F-1
F-2
System II Desi gn Rul es
System II
Modul e F
Transl ator
System II Modul es . ..
Modul e G
Modul e A
Desi gn Rul es
A-1
A-2
Splitti ng
F-3
Modul e D
Modul e E
Architectur al
Modul e
A-3
Substi tuti on
Excl usion
Augmenti ng
Inversion
Porting
We s tart ed with a generic two-lev el modular des ign st ruc ture, as s hown in Figure 5-3, but wit h six modules (A, B, C, D, E, F) ins tead of f our. (To dis play
the porting operat or, we mov ed the "Sy s tem I nt egration & Tes ting Module" to t he lef t-hand side of the f igure. ) We then applied eac h operat or to a
dif f erent s et of modules .
Module A was Split
into t hree sub-modules .
Three dif f erent Substi tutes
were dev eloped f or Module B.
Module C was Excl uded.
A new Module G was c reat ed t oAugment the s y st em.
Common elements of Modules D and E wereInverted. Subs y st em des ign rules and an arc hitec tural module were dev eloped to allow t he inv ers ion.
Module F was Ported. Firs t it was split ; then its "interior" modules were grouped wit hin a shell; then trans lator modules were dev eloped.
The ending s y s tem is a three-lev el s y s tem, with t wo
modular subsystems
perf orming t he f unc t ions of Modules A, D and E in the old s y s tem.
In addition t o the st andard hidden modules , there are three k inds of s pec ial modules , which are indic ated by heav y blac k borders and s haded int eriors :
Sy st em Integration & Test ing Module
Arc hitec tural Module
Trans lator Module(s )
Slide 28
© Carliss Y. Baldwin and Kim B. Clark, 2004
The Costs of Modularity
Every important cross-module interdependency must
be addressed via a design rule.
Dri ve
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
Ma in
B oa r d
x
x
x .
x .
x
x x
x
x
x x
x x x x
x
x
x x
x
x
x
x
x
. x x
x .
x x .
x x x
x x
x x
x
L CD
Scr een
x
x
x
x
x
x x
x x
x
x
. x
x . x
x .
This is costly
x
x
x
x
x
x
x x
x
x . x x
x
x
x
x x . x x x
x
x
x
. x
x
x x x . x x
x x x x
x x x . x
x
x x .
Costs eat up the
option value
x
x x
x
x
x
x
x x
Packaging
x x
x
x
x
x
x x x
x
x x
Modularization
may not pay
x
x
x
x
x
x
. x
x x
x . x x
x x
x x .
x
x
x x x . x
x
x x
. x
x
x
x . x
x
x
x .
x x
x x x
x
x
x
x
.
Gra p hics controller on Main Boa rd or not?
If yes, scr een speci fica tions change;
If no, CPU must pr ocess mor e; a dopt d i ffer ent i nter rupt pr otocols
Slide 30
© Carliss Y. Baldwin and Kim B. Clark, 2004
Costs of Experiments vary by module
Size
Visibility
Examples
large
hidden
disk drive; large application program
large
visible
microprocessor; operating system
small
hidden
cache memory; small application program
small
visible
instruction set; internal bus
Slide 31
© Carliss Y. Baldwin and Kim B. Clark, 2004
Thus each module has its own “value
profile”
Large;
Hidden
Net Option Value as a percentage of the
Benchmark Process
50%
Small;
Hidden
40%
30%
20%
10%
0%
0
5
10
15
20
25
-10%
-20%
-30%
-40%
Small;
Visible
Large;
Visible
-50%
No. of Experiments
Slide 32
© Carliss Y. Baldwin and Kim B. Clark, 2004
Value Profiles for a Workstation System
Sun
Microsystems
Workstation
circa 1992
Slide 33
© Carliss Y. Baldwin and Kim B. Clark, 2004
The Perils of Modularity
IBM Personal Computer
 Highly
modular architecture
 IBM outsourced hardware and software
 Controlled one high-level chip (BIOS) and the
manufacturing process
Then
 Compaq reverse-engineered the BIOS chip
 Taiwanese lowered manufacturing costs
By 1990 IBM was seeking to exit the
unprofitable PC marketplace!
Slide 35
© Carliss Y. Baldwin and Kim B. Clark, 2004
Compaq vs. Dell
 Dell
did to Compaq what Compaq did to IBM…
 Dell
created an equally good machine, and
 Used process modularity to reduce its production,
logistics and distribution costs and increase ROIC
– Negative Net Working Capital
– Direct sales, no dealers
By 1990 Compaq was seeking to exit the
unprofitable PC marketplace!
Slide 36
© Carliss Y. Baldwin and Kim B. Clark, 2004
Applications/Extensions
 Science
of Design
– Mapping DSMs of Large Systems
» Calculating Coordination Cost and Change Cost
– Formalizing Design Structure using Predicate
Logic
– Valuing Functions and Functionalities;
– Mapping to Functions to Designs Structures
– Estimating the Technical Potential of Modules
and tracking the evolution of versions and
functionalities in large systems
Slide 37
© Carliss Y. Baldwin and Kim B. Clark, 2004
Applications/Extensions
 Empirical
Studies of Modular Clusters
– Pricing and profitability of large clusters
– Tracking Evolution, Design Dependencies, and
Economic Value in Supply Networks—Video
games and Software
– Modular Operators as Correlates of Mergers &
Acquisitions
– Mortgage Banking
– Electronics
Slide 38
© Carliss Y. Baldwin and Kim B. Clark, 2004
Applications/Extensions
 Computational
Experiments
– Impact of local, voluntary mechanisms, eg,
bargaining on network formation and efficiency
– Innovation and imitation in modular vs. “nearmodular” design and task structures
– Pricing and profitability of firms in “symmetric”
and “asymmetric” modular clusters
Slide 39
© Carliss Y. Baldwin and Kim B. Clark, 2004
Applications/Extensions
 Management
studies/Strategy
– Comparing Knowledge Spans to Task Structures
– The architecture of self-organizing projects
» Game theoretic structures of open source projects
» Tools and methods of coordination in open source
projects
– Competitive strategies for firms in clusters
» Managing footprints for maximum ROIC
» Design of a design monopoly
Slide 40
© Carliss Y. Baldwin and Kim B. Clark, 2004
Applications/Extensions
 Public
policy/Design of institutions
– Impact of intellectual property rights and M&A on
entry into design competitions
– Impact of tournaments on design effort
– Epistemic problems in estimating value
» What are sufficient beliefs and how are they supported?
» Where do we get valid estimates of “technical
potential”?
» Bubbles and crashes
Slide 41
© Carliss Y. Baldwin and Kim B. Clark, 2004
“Modularity-in-design is not
good or bad. It is important and it
is costly. And dangerous to
ignore.”
Just remember—
“Compelling, surprising,
dangerous…”
Thank you!