Transcript NFRS Seminar - Harvard Business School
Designs and Design Architecture: The Missing Link between “Knowledge” and “the Economy”
Carliss Y. Baldwin Harvard Business School Conference on Networks of Knowledge Brussels, Belgium, EU June 7, 2004 Slide 1 © Carliss Y. Baldwin and Kim B. Clark, 2004
First Example—
Vertical-to-Horizontal Transitions, Modular Clusters, Ecosystems Slide 2 © Carliss Y. Baldwin and Kim B. Clark, 2004
Modularity creates financial forces that can change the structure of an industry
In 1995, Andy Grove described a vertical-to horizontal transition in the computer industry:
“Vertical Silos”
Slide 3
“Modular Cluster”
© Carliss Y. Baldwin and Kim B. Clark, 2004
The Computer Cluster, 1996
180 160 140 120 20 0 60 40 100 80 50 53 56 59 62 65 68 71 74 77 80 83 86 89 92 95 Slide 4 © Carliss Y. Baldwin and Kim B. Clark, 2004
The Computer Cluster, updated to 2002
800 700 600 500 400 300 200 100 0 50 54 58 62 66 70 74 78 82 86 90 94 98 02 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 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
What Causes V-to-H Transition?
Look to the underlying designs Designs and their Architecture “lie between” Knowledge and the Economy Knowledge Design Architecture Designs Economy Slide 8 © Carliss Y. Baldwin and Kim B. Clark, 2004
What Causes V-to-H Transition?
Look to the underlying designs Designs and their Architecture “lie between” Knowledge and the Economy Knowledge Design Architecture Designs Economy Modular, “option-rich” design architectures precede and enable modular clusters Slide 9 © Carliss Y. Baldwin and Kim B. Clark, 2004
Modularity
Module = a set of tasks – separable from others; – with additive incremental value –
Unit of design substitution
– No. of modules = j
Global Design Rules
Slide 10
Module A Module B Module C Module D
© 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 11 © Carliss Y. Baldwin and Kim B. Clark, 2004
Option Value
Design process is a search under uncertainty
Design substitution is
optional
Versions
are evidence of option values being realized over time
Global Design Rules v.1
Version 1.2
Version 1.5
Version 1.0
Version 1.8
Slide 12 © Carliss Y. Baldwin and Kim B. Clark, 2004
Modularity and Option Values are “architectural properties” because
(1) They are observable in early and incomplete systems; and (2) They affect the way the system evolves , ie., changes over time Slide 13 © Carliss Y. Baldwin and Kim B. Clark, 2004
Modularizations with
s Significant Modular, Option-Rich Design Architectures IBM System/360 DEC PDP 11; VAX Apple 2 IBM PC Sun 2; 3; Java VM RISC to-end) 50 53 Internet Protocols (end 62 65 68 71 74 77 80 83 Unix and C; Linux 86 89 92 95 HTML; XML Slide 14 180 160 140 120 20 0 60 40 100 80 © Carliss Y. Baldwin and Kim B. Clark, 2004
Second Example—
Voluntary Collective Development (Open Source Development) Slide 15 © Carliss Y. Baldwin and Kim B. Clark, 2004
Open Source is—
Slide 16
Social Movement Free Software New System of Property Rights GNU GPL Many Software Development Processes— One Method?
Complementary Institutional Structure(s) A Bunch of Organizations + Governance Structures
© Carliss Y. Baldwin and Kim B. Clark, 2004
Software Development Processes Are Design Processes
Slide 17
Social Movement Free Software New System of Property Rights GNU GPL A Bunch of Organizations + Governance Structures Many Software Development Processes — One Method?
Design Processes
© Carliss Y. Baldwin and Kim B. Clark, 2004
What Causes Voluntary Collective Development?
Look to the underlying designs Designs and their Architecture “lie between” Knowledge and the Economy Knowledge Design Architecture Designs Economy Modular, “option-rich” design architectures
precede and enable
voluntary collective development Slide 18 © Carliss Y. Baldwin and Kim B. Clark, 2004
Design Architecture and Voluntary Collective Development
Cooking dinner (Rival good: lot size = 12 portions) – One big stew = Not modular, no option value » A cook has no incentive to join with other cooks – Meat, salad, dessert = Modular, j=3 » Three cooks have incentives to get together – Two different stew recipes = Option value, s » Two cooks, pick the best recipe after the fact > 0 – Three courses, two recipes per course = Modules with option value » Six cooks will voluntarily
join up, cook, and feed each other
»
May feed an additional 6-18 people (free riders)
Collective Church recipe book (Non-rival good) – Contributions = #courses x #recipes per course Slide 19 © Carliss Y. Baldwin and Kim B. Clark, 2004
The Two Linked Games
Work (write code, patch, etc.) /* bitmap.c contains the code that handles the inode and block bitmaps */ #include
Conclusions: A Voluntary, Collective Design Process Requires— For existence: – Designer-users – Non-rivalrous goods –
A design architecture with modules and/or options
– Communication speeds matching the design interval for one module – Methods of SYSTEM INTEGRATION AND TESTING (omitted here—see DR1 and Bessen) For efficiency: – Ways to know who’s working on what – Ways to know which module design is better or best (Module-level testing—see DR1, contrast to Bessen) For robustness (to solve the Prisoners’ Dilemma game): – Rewards for communication – Iteration with an indeterminate horizon (not strict repetition) Slide 21 © Carliss Y. Baldwin and Kim B. Clark, 2004
Modular Clusters
Slide 22 © Carliss Y. Baldwin and Kim B. Clark, 2004
When and if it arrives…
Modularity in design, coupled with high option value is
compelling, surprising and dangerous…
Dangerous for whom?
Slide 23 © Carliss Y. Baldwin and Kim B. Clark, 2004
IBM System/360
The first modular computer design IBM did not understand the option value had created it 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 24 © Carliss Y. Baldwin and Kim B. Clark, 2004
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 25 © 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 26 © Carliss Y. Baldwin and Kim B. Clark, 2004
Modular Clusters are Turbulent
The value created moves around with the high s options In the Computers Cluster: value has moved a lot!
Because s s were so high (Moore’s Law, Amdahl’s Law, User Learning, …) Slide 27 © Carliss Y. Baldwin and Kim B. Clark, 2004
Concentration of Value — 1980
T he Computer Cluster in 1980 Market Values in Constant $
80 70 60 50 40 30 20 10 0 IBM AD 35 R 70 s e x IBM 35 71 35 72 35 75 35 76 35 77 36 70 36 72 36 In te 74 l e x In te l 36 78 73 70 73 71 Mi cro so ft 73 72 e x Mi cro so ft 73 73 73 74 73 77 Slide 28 IBM ADRs 3570 ex IBM 3571 3572 3575 3576 3577 3670 3672 Intel 3674 ex Intel 3678 7370 7371 Microsoft 7372 ex Microsoft 7373 7374 7377 © Carliss Y. Baldwin and Kim B. Clark, 2004
Dispersion of Value — 1996
T he Computer Cluster in 1996 M arket Values in Constant $
80 60 40 20 180 160 140 120 100 0 IBM AD 35 R 70 s e x IBM 35 71 35 72 35 75 35 76 35 77 36 70 36 72 36 In te 74 l e x In te l 36 78 73 70 73 71 Mi cro so ft 73 72 e x Mi cro so ft 73 73 73 74 73 77 Slide 29 IBM ADRs 3570 ex IBM 3571 3572 3575 3576 3577 3670 3672 Intel 3674 ex Intel 3678 7370 7371 Microsoft 7372 ex Microsoft 7373 7374 7377 © Carliss Y. Baldwin and Kim B. Clark, 2004
Reconcentration of Value — 2002
T he Computer Cluster in 2002 Market Values in Constant $
300 250 200 150 100 50 0 IBM AD 35 R 70 s e x IBM 35 71 35 72 35 75 35 76 35 77 36 70 36 72 36 In te 74 l e x In te l 36 78 73 70 73 71 Mi cro so ft 73 72 e x Mi cro so ft 73 73 73 74 73 77 IBM ADRs 3570 ex IBM 3571 3572 3575 3576 3577 3670 3672 Intel 3674 ex Intel 3678 7370 7371 Microsoft 7372 ex Microsoft 7373 7374 7377 Slide 30 © Carliss Y. Baldwin and Kim B. Clark, 2004
Two Questions:
Is the Modular Cluster form of industrial organization a healthy and sustainable form?
– Pricing holds the key – If firms kill each other in product markets, consolidation will occur
Are some types of clusters healthier than others?
Slide 31 © Carliss Y. Baldwin and Kim B. Clark, 2004
What is a healthy cluster?
In terms of system prices?
– High, medium, low In terms of aggregate profits?
– High, medium, low In terms of the distribution of value, concentration of power in layers?
– Is the Wintel platform cluster a healthy form of cluster?
In terms of accessibility through open standards?
Slide 32 © 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 – Locating Functionality in the Design Structure of Large Systems – Estimating the Technical Potential of Modules » Tracking the evolution of versions and functionalities in large systems Slide 33 © 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/Predictors of Mergers & Acquisitions – Mortgage Banking – Electronics Slide 34 © 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. “near modular” design and task structures – Pricing and profitability of firms in “symmetric” and “asymmetric” modular clusters Slide 35 © 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 36 © 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 design 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 37 © Carliss Y. Baldwin and Kim B. Clark, 2004
Slide 38
Thank you!
© Carliss Y. Baldwin and Kim B. Clark, 2004
Primer on Modularity and Design Architecture
Slide 39 © 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 Slide 40 © Carliss Y. Baldwin and Kim B. Clark, 2004
Design Structure Matrix Map of a Laptop Computer
Drive System Main Board LCD Screen 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 x x x x .
x x x x x x x x x .
x x x x x x x x .
x x x .
x x x x x x x x x x x x x x x .
x x x x .
x x x x x x x x .
x x x x x x x x x .
x .
x x x x x .
x x x .
x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x .
x x x x .
x x x x x x .
x x x x x x x x .
x x x .
x 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 41 © Carliss Y. Baldwin and Kim B. Clark, 2004
Design Structure Matrix Map of a Modular System
Design Rules Drive System Main Board LCD Screen Pack aging System Testing & Integ ration
. 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 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x .
x .
x x x .
x x x x x x x x x .
x x x x .
x x x x .
x x x x x x x x x .
x 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 Sys tem x x x .
x x x Inte gration x x x x x x and Tes ting x x x x x x x .
.
x Tas k Group
Slide 42 © 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 Tests , that provide Module Encapsulation and Information Hiding .
Slide 43 © Carliss Y. Baldwin and Kim B. Clark, 2004
Mapping Modular Structures over Time
“Modular Design Evolution” (MDE) John Holland’s theory of
CAS
Slide 44 © Carliss Y. Baldwin and Kim B. Clark, 2004
Design Hierarchy View
Global Design Rules Module A Module B Module C Module D System Integration & Testing
The system comprises four "hidden" modules and a "System Integration and Testing" stage. From the standpoint of the designers of A B, C, and D (the hidden modules), system 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. Obviously, the converse is not true: the integrators and testers have 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. Over time, as knowledge accumulates, more testing will occur within the modules, and the amount of information passed to the integrators will decrease. The special, time-dependent role of integration and testing is noted by the heavy black border around and gray shading within the "module." Slide 45 © Carliss Y. Baldwin and Kim B. Clark, 2004
Six Modular Operators
System I Global Design Rules Module F Design Rules System II Design Rules System Integration & Testing Module A Design Rules Module C D-E Design Rules Module G Module D Module E Architectural Module System I Module F Translator F-1 F-2 F-3 System II Module F Translator A-1 A-2 A-3 Splitting Substitution Exclusion Augmenting Inversion Porting
We started with a generic two-level modular design struc ture, as shown in Figure 5-3, but with six modules (A, B, C, D, E, F) instead of four. (To display the porting operator, we moved the "System Integration & Testing Module" to the left-hand side of the figure.) We then applied each operator to a different set of modules .
Module A was Three different Module C was
Split
into three sub-modules.
Substitutes Excluded.
A new Module G was c reated to were developed for Module B.
Augment
the system.
Common elements of Modules D and E were Module F was
Ported.
Inverted.
Subs ystem design rules and an architectural module were developed to allow the inversion.
Firs t it was split; then its "interior" modules were grouped within a shell; then translator modules were developed.
The ending s ystem is a three-level sys tem, with two
modular subsystems
performing the func tions of Modules A, D and E in the old system.
In addition to the standard hidden modules, there are three kinds of spec ial modules, whic h are indic ated by heavy blac k borders and shaded interiors: System Integration & Testing Module Architectural Module Translator Module(s )
System II Modules ...
Slide 46 © Carliss Y. Baldwin and Kim B. Clark, 2004
The Costs of Modularity
Slide 47 © Carliss Y. Baldwin and Kim B. Clark, 2004
Every important cross-module interdependency must be addressed via a design rule.
Drive System Main Board LCD Screen 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 x x x x .
x x x x x x x x x .
x x x x x x x x .
x x x .
x x x x x x x x x x x x x x x .
x x x x .
x x x x x x x x .
x x x x x x x x x .
x .
x x x x x .
x x x .
x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x .
x x x x .
x x x x x x .
x x x x x x x x .
x x x .
x 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
This is costly Costs eat up the option value Modularization may not pay
Slide 48 © Carliss Y. Baldwin and Kim B. Clark, 2004
Costs of Experiments vary by module
Size
large large small small
Visibility
hidden visible hidden visible
Examples
disk drive; large application program microprocessor; operating system cache memory; small application program instruction set; internal bus Slide 49 © Carliss Y. Baldwin and Kim B. Clark, 2004
Thus each module has its own “value profile”
Large; Hidden
50% 40% 30% 20% 10% 0% -10% 0 -20% -30% -40% -50% 5
Large; Visible
10 15
Small; Hidden Small; Visible
20
No. of Experiments
25 Slide 50 © Carliss Y. Baldwin and Kim B. Clark, 2004
Value Profiles for a Workstation System
Sun Microsystems Workstation circa 1992
Slide 51 © 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.”
Slide 52 © Carliss Y. Baldwin and Kim B. Clark, 2004
Just remember—
“Compelling, surprising, dangerous…”
Slide 53 © Carliss Y. Baldwin and Kim B. Clark, 2004