NFRS Seminar - Aspect-oriented software development
Download
Report
Transcript NFRS Seminar - Aspect-oriented software development
The Power of Modularity:
The Financial Consequences of
Computer and Code Architecture
Carliss Y. Baldwin
Harvard Business School
AOSD 06
March 22, 2006
Slide 1
© Carliss Y. Baldwin 2006
Unmanageable Designs—What
They Are and their Financial
Consequences
Carliss Y. Baldwin
Harvard Business School
AOSD 06
March 22, 2006
Slide 2
© Carliss Y. Baldwin 2006
Three Points to begin
Large,
complex, evolving designs
– Are a fact of modern life
– Need design architectures—
» “Description of the entities in a system and their relationships”
» Way of assigning work (Parnas)
Designs
create value
– Value operates like a force in the economy
– We fight to create it and to keep it—using strategy
Design Architecture
and Strategy
– How can you create and capture value in a large,
complex evolving set of designs?
– Subject of this talk
Slide 3
© Carliss Y. Baldwin 2006
In the economy, value acts
like a force
Value = money or the promise of money
Consider the computer industry…
Slide 4
© Carliss Y. Baldwin 2006
The changing structure of the
computer industry
Andy Grove described a vertical-to-horizontal transition in
the computer industry:
1980-“Vertical Silos”
1995-“Modular Cluster”
Slide 5
© Carliss Y. Baldwin 2006
Andy’s Movie
Stack View in 1980
Services
Systems Integration
Top 10 Public
Companies in
US Computer
Industry
Area reflects
Market Value
in Constant
US $
Slide 6
Applications Layer
Middleware Layer
Operating Systems
Hardware
IBM
S
P
E
R
R
Y
D CVC
U H E
N P C
S
Y
XRC
S
AMP
Components
TI
Intel
© Carliss Y. Baldwin 2006
Andy’s Movie
Stack View in 1995
IBM
S
P
E
R
R
Y
D CVC
U H E
N P C
S
Y
XRC
S
AMP
TI
Services
Systems Integration
First Data
EDS
Oracle
Intel
Top 10 Public
Companies in
US Computer
Industry
Area reflects
Market Value
in Constant
US $
Slide 7
I
Applications Layer B MSFT
Middleware Layer M
Operating Systems
Hardware: Printers
Hardware: Servers
Hardware: Routers
Components
CA
HP
IBM
Cisco
Intel
Micron
© Carliss Y. Baldwin 2006
Andy’s Movie—the Sequel
Stack View in 2002
IBM
S
P
E
R
R
Y
D CVC
U H E
N P C
S
Y
XRC
S
AMP
TI
Intel
Top 10 Public
Companies in
US Computer
Industry
Area reflects
Market Value
in Constant
US $
Slide 8
Services
First Data
Services
First Data
ADP EDS
Systems Integration
Systems Integration
I
CA
Applications Layer B MSFT
Applications
Layer IBM
Middleware
Layer M
Operating Systems
Middleware
Layer Printers
Hardware:
Hardware: Servers
Operating
Systems Routers
Hardware:
Components
Hardware: Printers
HP
Hardware: PCs
Dell
Hardware: Servers
IBM
Hardware: Routers
Cisco
Components
Intel
Oracle
Oracle
MSFT
HP
IBM
Cisco
Intel
Micron
TI
© Carliss Y. Baldwin 2006
Turbulence in the Stack
Departures from Top 10:
Xerox (~ bankrupt)
DEC (bought)
Sperry (bought)
Unisys (marginal)
AMP (bought)
Computervision (LBO)
Sic Transit Gloria Mundi
Slide 9
Arrivals to Top 10:
Microsoft
Cisco
Oracle
Dell
ADP
First Data
… Sic Transit
© Carliss Y. Baldwin 2006
Contrast to the Auto Industry
2003
Honda
FORD
Dana
Tenneco
Eaton
Other
Powertrain
Af termarket
AUGAT (electronics)
Interior
TRW
Top 10 Public
Companies in
US Auto
Industry
Area reflects
Market Value
in Constant
US $
Slide 10
Toyota
Nissan
Daimler
Chrysler
Honda
GM
Ford
VW
Others
Toyota
General Motors
Chrysler
1982
Magna
Johnson Controls
Eaton
Other Multiple
Electrical/Electronics
Other Interior
Other Misc.
Other Chassis/Powertrain
Value stayed in one layer!
© Carliss Y. Baldwin 2006
Two patterns
“Manageable”
designs = auto industry
“Unmanageable” designs = computer
industry
What makes computer designs so
unmanageable?
This was the question Kim Clark and I set out to
answer in 1987.
Slide 11
© Carliss Y. Baldwin 2006
After studying the history of computer
designs and correlating their changes
with value changes
We concluded that modularity
was part of the answer…
Slide 12
© Carliss Y. Baldwin 2006
Modularity is
The
degree to which a set of designs (or
tasks) is partitioned into components, called
modules, that are
highly dependent within a module, nearly
independent across modules
A property of architecture, somewhat under
the architect’s control
Slide 13
© Carliss Y. Baldwin 2006
Modularity in computers—
IBM System/360
First
modular computer design architecture
(1962-1967)
– Proof of concept in hardware and application
software
– Proof of option value in market response and
product line evolution
– System software was NOT modularizable
» Fred Brooks, “The Mythical Man Month”
» Limits of modularity
Slide 14
© Carliss Y. Baldwin 2006
Strategically—IBM wanted to be the sole
source of all of System/360’s Modules
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
SLT
SLT
SLT
Transistors
Modules
Cards
Boards and Automatic Wiring
Processor 1 - Endicott, N ew Y ork
Processor 2 - Hursley , England
Processor 3 - Poughkeepsie, New Y ork
Processor 4 - Poughkeepsie, New Y ork
Processor 5 - Poughkeepsie, New Y ork
Main memories, Corporate Memory Group (1)
Internal memories, C MG
Read-only memories f or control, CMG
"Binary -addressed" Random Access Files
Corporate File Group (2)
Tape dev ices running at 5000+ char/sec
Corporate Tape Group (3)
Time-multiplex sy stem f or switching I/O dev ices
DSD Technical Dev elopment Group
Techniques to measure processor perf ormance, sy stem
throughput and sof tware ef f iciency , Group Staf f
A unif ied Input/output Control Structure (IOCS)
Sy stem Sof tware f or Conf iguration I (4)
Sy stem Sof tware f or Conf iguration II (4)
Sy stem Sof tware f or Conf iguration III (4)
FORTRAN and COBOL compilers
A unif ied programming language
33
34
35
Announcement and Marketing
Production, Testing and Integration
Shipment, D eliv ery and Installation
Slide 15
© Carliss Y. Baldwin 2006
By 1980, 100s of firms made S/360
“plug-compatible” components
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 16
© Carliss Y. Baldwin 2006
Modularity and Option Value
Interact
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
Slide 17
Jose labs —> Silicon Valley
© Carliss Y. Baldwin 2006
Modularity in computers, cont.
Bell and Newell, Computer Structures (1971)
– General principles of modular design for hardware
– Basis of PDP-11 design—another ORMDA
Thompson and Ritchie, Unix and C (1971-1973)
– Modular design of operating system software (contra
Brooks Law)
Parnas (1972) abstract data structures, info hiding
– Object-oriented programming, C++, Java
Mead and Conway, Intro to VLSI Systems (1980)
– Principles of modular design for large-scale chips
Slide 18
© Carliss Y. Baldwin 2006
Modularity in computers (cont.)
IBM PC (1983)
–
–
–
–
–
–
Slide 19
DEC PDP-11 minimalist strategy (exclude and invite)
+ Intel 8088 chip
+ DOS system software
+ IBM manufacturing
+ Lotus 1-2-3
A modular design architecture with a mass market
© Carliss Y. Baldwin 2006
Creating a modular architecture
Slide 20
© Carliss Y. Baldwin 2006
Design Structure Matrix Map of a Laptop Computer
Dri ve
Sys tem
. x x
x
x
x
x . x x x
x
x
x
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 x
x x
x
L CD
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
P ack ag in g
x x
x
x
x
x
x x x
x
x x
x
x
x
x
x
x
. x
x x
x . x x
x x
x x .
x
x
x x x . x
x
x x
. x
x
x
x . x
x
x
x .
x x
x x x
x
x
x
x
.
G raphics contro ll er o n Mai n B o a rd o r no t?
If y es , s creen sp ecificati on s ch ang e;
If n o, CPU mu s t p ro ces s mo re; ad op t di fferent in terrup t prot oco ls
Slide 21
© Carliss Y. Baldwin 2006
Every important cross-module interdependency must
be addressed via a design rule.
Dri ve
Sys tem
. x x
x
x
x
x . x x x
x
x
x
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 x
x x
x
L CD
Screen
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 .
Modularization
may not pay
x
x x
x
x
x
x
x x
P ack ag in g
x x
x
x
x
x
x x x
x
x x
x
x
x
x
x
x
. x
x x
x . x x
x x
x x .
x
x
x x x . x
x
x x
. x
x
x
x . x
x
x
x .
x x
x x x
x
x
x
x
.
G raphics contro ll er o n Mai n B o a rd o r no t?
If y es , s creen sp ecificati on s ch ang e;
If n o, CPU mu s t p ro ces s mo re; ad op t di fferent in terrup t prot oco ls
Slide 22
© Carliss Y. Baldwin 2006
Design Structure Matrix of a Modular Laptop
Computer
Design
Rule s
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
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
Boa rd
LCD
Scre e n
P ac ka ging
System
Testing
& I nte gra tion
x x
x
x
x x
x
x
x x
x x
x x
x x
x
x
x x
x
x
x x
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 23
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 2006
Measuring modularity
Slide 24
© Carliss Y. Baldwin 2006
Comparison of different software systems with DSM tools
Mozilla just after becoming open source
Coord. Cost = 30,537,703
Change Cost = 17.35%
Linux of similar size
Coord. Cost = 15,814,993
Change Cost = 6.65%
© Alan MacCormack, Johh Rusnak and Carliss Baldwin, 2006
Conway’s Law: Different organizations deliver different architectures
Mozilla just after becoming open source
One Firm,
Tight-knit
Team, RAD
methods
Coord. Cost = 30,537,703
Change Cost = 17.35%
Linux of similar size
Distributed
Open Source
Development
Coord. Cost = 15,814,993
Change Cost = 6.65%
© Alan MacCormack, Johh Rusnak and Carliss Baldwin, 2006
Refactoring for modularity
Mozilla Before Redesign
Change Cost = 17.35%
Mozilla After Redesign
Change Cost = 2.38%
© Alan MacCormack, Johh Rusnak and Carliss Baldwin, 2006
What about Aspects?
Slide 28
© Carliss Y. Baldwin 2006
Creating an Aspect Module
Design Rules = APIs only
Cross-cutting
concern
APIs
Design Rules = APIs and XPIs
APIs
XPIs
A
A
B
B
C
Imagine 100s of A’s and B’s!
Slide 29
Modular Operator “Inversion”
© Carliss Y. Baldwin 2006
What is the Aspect worth?
If
no change ever, Aspect is worthless
Reasons to change the Aspect sub-blocks
– Achieve consistency
– Better approaches
– Changes in policy
Option
value = the value of an unforeseen
change
Slide 30
© Carliss Y. Baldwin 2006
An Option is
The
right but not the obligation to take an
action
– Action = Use a new design
– If new is better than old, use new;
– Otherwise, keep the old.
Slide 31
© Carliss Y. Baldwin 2006
An Aspect changes the “Net Option
Value” (NOV) of the codebase
Without Aspect:
Net Option Value (NOV) =
Change Benefit – 100 Change Costs
With Aspect:
Net Option Value (NOV) =
Change Benefit – 1 Change Cost
If Change Benefit > 100 Change Costs
NOV = 99 Change Costs
As Change Benefit decreases, NOV goes down:
If Change Benefit= 0, NOV = 0
Slide 32
© Carliss Y. Baldwin 2006
To justify an Aspect (to your CFO)
You need to argue:
– Change Benefit is high
» consistency, better approaches, policy
– Difference in Change Costs is high
» “99 changes vs. 1”
– Cost of refactoring is low
» “You are going to have to refactor anyway, so do it right… .”
The
NOV approach attempts to quantify the
elements of this argument
– Option value resides in “Change Benefit”
– This is the bleeding edge of our science
Slide 33
© Carliss Y. Baldwin 2006
What is this elusive property that
gives rise to option value?
Where does it arise?
Can we measure it?
Slide 34
© Carliss Y. Baldwin 2006
Measuring Option Potential
Successive, improving versions are evidence of option
potential being realized over time—after the fact
Designers see option potential before the fact
What do they see?
Global Design Rules v.1
Version 1.0
Version 1.2
Version 1.5
Version 1.8
s = Low
Slide 35
Medium
Zero
High
© Carliss Y. Baldwin 2006
Major challenge in research and
practice right now
Science may not be able to deliver
tools to measure ex ante option
potential reliably
But ex ante estimates are what’s
needed
Slide 36
© Carliss Y. Baldwin 2006
s /Option potential is like dark matter
in the universe
Scientists
can measure its effects but we
can’t measure “it”
“Wizards” can perceive s /option potential
– But wizards don’t talk to scientists!
we lack ways to measure s /option
value scientifically
Thus
– It is a “research frontier”
Slide 37
© Carliss Y. Baldwin 2006
s /Option potential at work—
Matlab programming contest
Slide 38
© Carliss Y. Baldwin 2006
s /Option potential at work—
Transaction Processors and CPUs
1 0 ,0 0 0 ,0 0 0
1 ,0 0 0 ,0 0 0
Ke y
Pfis te r
TPC-C v.3
TPC-C v.5
Spe c CPU 95
Spe c CPU 2000
tpmC and Spec CInt
1 0 0 ,0 0 0
Architectural
experimentation
1 0 ,0 0 0
1 ,0 0 0
100
Component
experimentation
10
1
D ec - 9 1
D ec - 9 3
D ec - 9 5
D ec - 9 7
D ec - 9 9
D ec - 0 1
D ec - 0 3
Syst em A vailabilit y Dat e
Slide 39
© Carliss Y. Baldwin 2006
D ec - 0 5
Sources of s /option value
Physics—
– Moore’s Law (dynamics of miniaturization) applies to
MOSFET circuits and systems (Mead and Conway)
– Power and heat systems vs. logic systems (Dan Whitney)
User
innovation
– Users’ discovery of their own needs
– “Killer apps”
Architecture
– Experimenting with different relationships among
components
Slide 40
© Carliss Y. Baldwin 2006
But you might not want to tell
your CFO that …
High
option value makes designs
unmanageable …
Call
Slide 41
your venture capitalist, instead!
© Carliss Y. Baldwin 2006
High option potential induces entry
=> industry structure change
Autos
Computers
Services
Systems Integration
First Data
EDS
Oracle
Toyota
Daimler
Chrysler
Honda
GM
Ford
VW
Others
Nissan
Magna
Johnson Controls
Eaton
Other Multiple
Electrical/Electronics
Other Interior
Other Misc.
Other Chassis/Powertrain
I
Applications Layer B MSFT
Middleware Layer M
Operating Systems
Hardware: Printers
Hardware: Servers
Hardware: Routers
Components
CA
HP
IBM
Cisco
Intel
Micron
Slide 42
© Carliss Y. Baldwin 2006
High s’s are what make designs
unmanageable
“Unmanageable”
= Cannot be confined in a single
company or supply chain
There
are modular design architectures that are
very manageable
– Example: Toyota Production System (TPS)
System/360 had had low s /option potential,
IBM would be like Toyota
If
It would be a different world…
Slide 43
© Carliss Y. Baldwin 2006
Recapping the argument
Designs
create value
– Value operates like a force in the economy
– Changes the structure of industries
Designs
have architectures
– Modularity and s /Option value are the key economic
properties of a design architecture
– Modularity + High s /Option value => Unmanageable
» Why computers are not like autos
» Why IBM is not Toyota
We have NOT talked about—
How do you capture value in a modular, high-s
design?
Slide 44
© Carliss Y. Baldwin 2006
How can you capture value?
Architectural/Technological
question:
– Where/when does modularization stop?
Business/Strategic
question:
– How do you make money in a modular, high-s
world?
Slide 45
© Carliss Y. Baldwin 2006
Where does modularization stop?
Strojwas (2005)
Semiconductor
Industry
Top 10 Firms:
1994 and 2004
Slide 46
© Carliss Y. Baldwin 2006
How do you make money in a
high-s world?
Old
paradigm
– “Plunge in”
– “Get lucky”
– “Watch out for Microsoft”
– “Get bought by HP”
Slide 47
© Carliss Y. Baldwin 2006
How do you make money in a
high-s world?
A new
paradigm…
– Expect a cluster
– Use M&A to be the “lead firm” in some slice(s)
of the stack
– Use design architecture to reduce your
“footprint” in each slice => high ROIC
– Use open source methods to clone your
complementor’s products => price and
innovation discipline
Slide 48
© Carliss Y. Baldwin 2006
Our research strategy—Look for
Stable
patterns of behavior involving
several actors operating within a consistent
framework of ex ante incentives and ex post
rewards
==>
Equilibria of linked games with selfconfirming beliefs (Game theory)
Slide 49
© Carliss Y. Baldwin 2006
How a “stable pattern” works
Anticipation
of $$$ (visions of IPOs)
Lots of investment
Lots of design searches
Best designs “win”
Fast design evolution => innovation
Lots of real $$$ (an actual IPO)
“Rational expectations equilibrium”
Slide 50
© Carliss Y. Baldwin 2006
Three Stable Patterns
“Blind”
Competition
– PCs in the early 1980s
High
ROIC on a Small Footprint
– Sun vs. Apollo
– Dell vs. Compaq (and HP and …)
Lead
Firm Competition
– Monopoly—MSFT
– Mergers & Acquisitions—Cisco, Intel …
Slide 51
© Carliss Y. Baldwin 2006
“Blind” Competition
All Ze ros (1, 0, 0)
x A
B x
Ve nture s do be s t
Fighte rs do be s t
Ze ros do be s t
ESS (1/8, 3/8, 4/8)
)
0.0
0.1 0, 0) 0.2
All Ve nture
s (1,
Slide 52
0.3
0.4
0.5
0.6
0.7
0.8
0.9
All
Fighte 1.0
rs (1, 0, 0)
© Carliss Y. Baldwin 2006
“Blind” Competition
Slide 53
© Carliss Y. Baldwin 2006
“Footprint” Competition—Apollo
1
1
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
36
37
38
39
40
41
42
2
3
O
O
x
x
x
x
x
x
x
x
x
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 36 37 38 39 40 41 42
Processor chip—CPU
Outsourced—Motorola 680x0
Floating Point Accelerator
Outsourced
O
Memory chips DRAMs, ROM
Outsourced—Commodity
O
Storage—Disk Driv es
Outsourced
O
Storage—Tape Driv e
Outsourced
O
Printed circuit boards
Outsourced—Commodity
O
Display Monitor
Outsourced
O
Key board, Cabinet, Fans
Outsourced
x
x
x
x
x
x
x
x
x
x
x
x
x
Inhouse
Design
x
x
x
x
x
x
x
x
x
x
x
x
x
OS
Network
x
x
x
x
x
x
x
x
x
x
x
x
Key:
x= transf er of material or inf ormation f rom column
task to row task;
T= transaction: sale of good by column owner to row
owner;
O= outsourced task blocks;
D= downstream or complementary task blocks;
highly interdependent task blocks with many iterations
and high within-block mundane transaction costs;
Apollo's f ootprint (tasks perf ormed inhouse).
Aegis proprietary
Operating Sy stem
DOMAIN proprietary
Network Architecture
x
Hardware Design
DN series = 3-4 boards incl.
IO and Display controllers,
Power supply
Purchase Components
Hardware
T
T
T
T
T
T
T
T
T
T
T
T
Keeps
Design
Control
Slide 54
T
T
T
T
Component Test
Kits
Board stuf f and Solder
Test Boards
Board Assembly
Sy stem Assembly
Sy stem Test
Quality Assurance
Consolidate and Ship
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Inhouse
Manufacturing
x
x
x
x
x
x
x
D
Many Sof tware Applications
D
D
x
x
x
x
x
x
x
x
x
x
x
x
T
Many OEMs T
T
D
D
D
© Carliss Y. Baldwin 2006
Then Sun came along…
Apollo Computer
Aegis proprietary
Operating Sy stem
Inhouse
Design
OS
DOMAIN proprietary
Network Architecture
Network
Hardware Design
DN series = 3-4 boards incl.
IO and Display controllers,
Power supply
Purchase Components
Hardware
Component Test
Kits
Board stuf f and Solder
Test Boards
Board Assembly
Sy stem Assembly
Sy stem Test
Quality Assurance
Consolidate and Ship
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Inhouse
Manufacturing
x
x
x
x
x
And did even less!
How?
Slide 55
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x x
T
T T
T
Component Test
Kits
Board stuf f and Solder
Test Boards
Board Assembly
Sy stem Assembly
Sy stem Test
Quality Assurance
Consolidate and Ship
Customize Unix
Proprietary MMU
Internal bus
Single Board Lay out
Purchase Components
Inhouse
Design
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
O
T
x
Manufacturing
O
T
x
x
x
x
x
© Carliss Y. Baldwin 2006
Then Sun came along…
Apollo Computer
Aegis proprietary
Operating Sy stem
Inhouse
Design
OS
Hardware Design
DN series = 3-4 boards incl.
IO and Display controllers,
Power supply
Purchase Components
Hardware
Component Test
Kits
Board stuf f and Solder
Test Boards
Board Assembly
Sy stem Assembly
Sy stem Test
Quality Assurance
Consolidate and Ship
Design Architecture for high
performance with a small
footprint
DOMAIN proprietary
Network Architecture
Network
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Public Standards for
outsourcing
Inhouse
Manufacturing
x
x
x
x
x
x
x
x
x
x
And did even less!
How?
Slide 56
x
x
x
x
x
x
x
x
x
x
x
x
x x
T
T T
T
Component Test
Kits
Board stuf f and Solder
Test Boards
Board Assembly
Sy stem Assembly
Sy stem Test
Quality Assurance
Consolidate and Ship
Customize Unix
Proprietary MMU
Internal bus
Single Board Lay out
Purchase Components
Inhouse
Design
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
O
T
x
Manufacturing
O
T
x
x
x
x
x
© Carliss Y. Baldwin 2006
Result: ROIC advantage to Sun
Average over 16 Quarters:
Apollo
Computer
Sun
Microsystems
29%
24%
57%
15%
13%
31%
Low is good
Low is good
Low is good
Profitability
Net Income/Sales
0%
6%
High is good
ROIC
ROIC (excl Cash, Annualized)
2%
20%
High is good
Invested Capital Ratios (Annualized)
Net Working Capital/ Sales (%)
Ending Net PPE / Sales (%)
Inv ested Capital/Sales (%)
Sun used its ROIC advantage to drive Apollo out
of the market
Apollo was acquired by HP in 1989
Slide 57
© Carliss Y. Baldwin 2006
Compaq vs. Dell
Dell
did to Compaq what Sun did to Apollo …
Dell
created an equally good machine, and
Used design architecture to reduce its footprint in
production, logistics and distribution costs
– Negative Net Working Capital
– Direct sales, no dealers
Result
Slide 58
= Higher ROIC
© Carliss Y. Baldwin 2006
Higher ROIC always wins!
1997
Invested Capital Ratios (Annualized)
Net Working Capital/ Sales (%)
Ending Net PPE / Sales (%)
Inv ested Capital/Sales (%)
Profitability
Net Income/Sales
ROIC
ROIC (excl Cash, Annualized)
Compaq
Computer
Dell
Computer
-2%
8%
8%
-5%
3%
-2%
Low is good
Low is good
Low is good
8%
7%
High is good
101%
-287%
!!!
Dell started cutting prices; Compaq struggled, but in
the end had to exit.
Compaq was acquired by HP in 2002
Slide 59
© Carliss Y. Baldwin 2006
Competition and Beliefs
“Blind”
competitors
– don’t know others exist
“Footprint”
competitors
– Don’t expect to influence others—just compete
“Lead
firms”
– Must influence the beliefs of their competitors
– FUD — “Fear, uncertainty and doubt”
– Others cannot be blind!
Slide 60
© Carliss Y. Baldwin 2006
“Lead Firm” Competition
Monopolist needs to deter all potential entrants
with threats of price war
– Very fragile equilibrium
– Potentially expensive to create “enough” FUD
M&A Lead Firm does not try to deter all entry in
the design space
– Expects to buy most successful entrants ex post
– More robust equilibrium
– Maybe more advantageous, when you count the cost of
FUD
Slide 61
© Carliss Y. Baldwin 2006
Thank you!
Slide 62
© Carliss Y. Baldwin 2006