Design Rules: How Modularity Affects the Value of Complex Engineering Systems Carliss Y. Baldwin Harvard Business School International Conference on Complex

Design Rules:How Modularity Affects the Value of Complex Engineering Systems

Carliss Y. BaldwinHarvard Business School

International Conference on Complex Systems (ICCS 2004)Quincy, MassachusettsMay 20, 2004

Slide 2 © Carliss Y. Baldwin and Kim B. Clark, 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


This is an emergent modular cluster

5054

5862

6670

7478

8286

9094

9802

737773747373

7372 ex Microsoft

Microsoft

737173703678

3674 ex Intel

Intel3672367035773576357535723571

3570 ex IBM

IBM

0

100

200

300

400

500

600

700

800

$ billion


SIC Codes in the DatabaseSICCode Category Definition Start Date (1)

3570 Computer and Office Equipment 19603670 Electronic Components and Accessories 19603674 Semiconductors and Related Devices 19603577 Computer Peripheral Devices, n.e.c. 19623678 Electronic Connectors 19657374 Computer Processing, Data Preparation and Processing 19683571 Electronic Computers 19703575 Computer Terminals 19707373 Computer Integrated Systems Design 19703572 Computer Storage Devices 19717372 Prepackaged Software (2) 19733576 Computer Communication Equipment 19743672 Printed Circuit Boards 19747370 Computer Programming, Data Processing, and Other

Services1974

7371 Computer Programming Services 19747377 Computer Leasing 1974

(1) Start date is the first year in which six or more are present in the category.(2) This category had six firms in 1971, dipped to five in 1972, and back to

six in 1973.


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”


The Bright Side of Modularity

0

100

200

300

400

500

600

700

800

900

1000

50 55 60 65 70 75 80 85 90 95


The Dark Side …

0

500

1000

1500

2000

2500

3000

3500

4000

4500

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

$ billion


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


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


Three Consequences

More risk is valuable Seemingly redundant efforts are value-

increasing (up to a point) Modularity creates more options


Modularity Creates Design Options

System Before Modularization System after Modularization

System DesignOption Rules

Option Option

Option Option

Option Option

OptionSplit options, decentralize decisions,fragment control Evolution

Design Options are ValuableHow 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?


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.”


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?

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

The Basic Framework of our Model of Modular Design Process

Stages Stage 1 Stage 2 Stage 3

TimeLine

Create Implement Test,

Task Task Integrate,

Structure & Structure Evaluate

Design Rules for Modules System

What Actually Happens

Actions Choose Carry out Test results &

operators tasks Exercise options

Events Splitting "The Wheel Spins" Economic

Substituting value is revealed;

Augmenting Best outcomes

Excluding are selected

Inverting

Porting

Mathematical Representation

Benefits A payoff in An outcome is drawn The value corresponding

the form of from the distribution to the outcome of the

a random of the random variable. random variable

variable is is revealed; where

chosen. options exist, the best

outcomes are selected.

X X → X ( , 0)max X

Costs Cost of Cost of Cost of

designing implementing testing and

task task integration

structure structure

Basis of Highest Highest Highest

Choice Net Option Net Option Value Value given

Value given task structure outcomes and tests



The Value of Splitting and Substitution

5

9

13

17

2125

1

7

13

19

25

0

5

10

15

20

25

30

Value

No. of ModulesNo. of Experiments


When and if it arrives…

Modularity in design is

compelling, surprising and dangerous…


5055

60

65

70

75

80

85

90

95

0

20

40

60

80

100

120

140

160

180

YearSIC Code or Company

Dangerous for whom?


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”


Entry into Computer Industry1960, 1970, 1980

Code Category Definition 1960 1970 1980

3570 Computer and Office Equipment 5 2 93571 Electronic Computers 1 8 293572 Computer Storage Devices 1 6 36 *3575 Computer Terminals 2 5 23 *3576 Computer Communication Equipment 1 1 10 *3577 Computer Peripheral Devices, n.e.c. 3 5 12 *3670 Electronic Components and Accessories 11 7 11 *3672 Printed Circuit Boards 2 19 39 *3674 Semiconductors and Related Devices 8 4 10 *3678 Electronic Connectors 5 15 16 *7370 Computer Programming, Data Processing,

and Other Services 1 9 26 *7371 Computer Programming Services 0 2 12 *7372 Prepackaged Software 0 7 13 *7373 Computer Integrated Systems Design 1 3 167374 Computer Processing, Data Preparation

and Processing 0 5 29 *7377 Computer Leasing 0 10 7 *

41 108 298

* Firms in these subindustries make modules of larger computer systems. Firms making modules = 34 95 244Percent of total = 83% 88% 82%

Mapping the Modular Structure of a Complex Engineering System

We can “see” a system’s modular structure via a Design Structure Matrix (DSM) Map


. x x x x xx . x x x x x x x x x

Drive x x . x x xSystem x x x . x x x x x x x x

x x . xx x x x . x x x

x x x . x xx x x . x x x x

x x x . x x x x xMain x x x . x x xBoard x x x x x x x x . x x x x x

x x x x x . x xx x x x x x . x x x

x x x . x

x x x . x x xx x x x . x x x x

LCD x x x . x xScreen x x x x . x x x

x x x x x x x . x x xx x x . x

x x x x . x x x xx x x . x x x x

x x x x x . x x xPackaging x x x x . x x

x x x x x . x xx 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

Design Structure Matrix Map of a Laptop Computer


Design Structure Matrix Map of a Modular System

. x x x xx . x x

Design x . x x Design Rules Task GroupRules x x . x

x x x .x . x x x

x x . x x xDrive x x x x . xSystem x x x x x . x x Hidden Modules

x x x . x many Task groupsx x x x .

x . x xx x x x x . x x

x x . x x x xMain x x x x x . x xBoard x x x x x x x . x x

x x x x x . xx x x x x x . x

x x x x x .x x . x x x

x x x . x x xLCD x x x . xScreen x x x x x . x x

x x x x x . xx x x x x x .

x x . x x x xx x x . x x x x

x x x . x x xPack- x x x x x x . x xaging x x x . x x

x x x x x . x xx x x x x .

x x x x x x .x x x x x x . x x x x

System x x x x x x x x . x x System Testing x x x x x x x x x . x x x Integration& Integ- x x x x x x x x x x x x and Testingration x x x x x x x x . x Task Group

x x x x x x x x x x x .

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 ViewGlobal 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."


Six Modular Operators

System I Global Design Rules Module F System II Design RulesDesign Rules

System Module C System I F-1 System IIIntegration Module F Module F& Testing D-E Design Rules Translator F-2 Translator System II Modules ...

Module GModule A F-3Design Rules Module D Module E Architectural

Module

A-1 A-2 A-3

Splitting Substitution Exclusion Augmenting Inversion Porting

We started with a generic two-level modular design structure, as shown in Figure 5-3, but with six modules (A, B, C, D, E, F) instead of four. (To displaythe 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 Split into three sub-modules.Three different Substitutes were developed for Module B.Module C was Excluded.A new Module G was created to Augment the system.Common elements of Modules D and E wereInverted. Subsystem design rules and an architectural module were developed to allow the inversion.Module F was Ported.First it was split; then its "interior" modules were grouped within a shell; then translator modules were developed.

The ending system is a three-level system, with two modular subsystems performing the functions of Modules A, D and E in the old system.In addition to the standard hidden modules, there are three kinds of special modules, which are indicated by heavy black borders and shaded interiors:

System Integration & Testing ModuleArchitectural ModuleTranslator Module(s)

Module BModule B

The Costs of Modularity


. x x x x xx . x x x x x x x x x

Drive x x . x x xSystem x x x . x x x x x x x x

x x . xx x x x . x x x

x x x . x xx x x . x x x x

x x x . x x x x xMain x x x . x x xBoard x x x x x x x x . x x x x x

x x x x x . x xx x x x x x . x x x

x x x . x

x x x . x x xx x x x . x x x x

LCD x x x . x xScreen x x x x . x x x

x x x x x x x . x x xx x x . x

x x x x . x x x xx x x . x x x x

x x x x x . x x xPackaging x x x x . x x

x x x x x . x xx 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

Every important cross-module interdependency must be addressed via a design rule.

This is costly

Costs eat up the option value

Modularization may not pay


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


Thus each module has its own “value profile”

-50%

-40%

-30%

-20%

-10%

0%

10%

20%

30%

40%

50%

0 5 10 15 20 25

No. of Experiments

Net Option Value as a percentage of the

Benchmark Process

Small;Hidden

Large;Hidden

Small;VisibleLarge;

Visible


Value Profiles for a Workstation System

1

5

9

13

17

21

25

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

No. of Experiments

Sun Microsystems Workstation circa 1992

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!


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!


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



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



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



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



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

“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!

Documents

Design Rules: How Modularity Affects the Value of Complex Engineering Systems Carliss Y. Baldwin Harvard Business School International Conference on Complex