Download presentation
Presentation is loading. Please wait.
Published byAugust Craig Modified over 8 years ago
1
Slide 1 © Carliss Y. Baldwin and Kim B. Clark, 2005 The Looming Complexity Catastrophe in Large (and Ultra-Large) Systems Carliss Y. Baldwin Harvard Business School August 15, 2005
2
Slide 2 © Carliss Y. Baldwin and Kim B. Clark, 2005 IT system of a large retailer, 1999 Boxes=Systems; Lines=Standards
3
Slide 3 © Carliss Y. Baldwin and Kim B. Clark, 2005 Another appalling hairball from banking— 3-year plan to do merger integration
4
Slide 4 © Carliss Y. Baldwin and Kim B. Clark, 2005 Goals for an Ultra-Large System Complete interoperability of components (mix-and-match) Seamless upgradability Unlimited extensibility No First or Second Level Hairballs! Internet is good at the First Level but has Second Level Problems (e.g. Windows)
5
Slide 5 © Carliss Y. Baldwin and Kim B. Clark, 2005 To avoid complexity catastrophes in Ultra-Large Systems we need: Tools/techniques to map actual interdependencies in large, changing codebases Formal measures of design option value ex ante and ex post “If you can’t measure it, you can’t manage it.”
6
Slide 6 © Carliss Y. Baldwin and Kim B. Clark, 2005 Complexity = Interdependency There are ex ante architectectural representation languages (UML) –Like architectural drawings But very few code maps –Maps are ex post, updatable, show what’s really there –Like plumber’s/electrician’s diagrams –Example: Rusovan, Lawford, Parnas (2005) critique of Linux was based on ONE sourcefile! Architecture of functionally similar codebases can be very different
7
Slide 7 © Carliss Y. Baldwin and Kim B. Clark, 2005 Mozilla Before RedesignMozilla After Redesign Browsers
8
Slide 8 © Carliss Y. Baldwin and Kim B. Clark, 2005 Word Processors AbiwordOpen Office Word
9
Slide 9 © Carliss Y. Baldwin and Kim B. Clark, 2005 Spreadsheets GnumericOpen Office Calc
10
Slide 10 © Carliss Y. Baldwin and Kim B. Clark, 2005 These architectural differences affect design option value Design options have “technical potential”, denoted Technical potential, , varies –By system –By module –Over time
11
Slide 11 © Carliss Y. Baldwin and Kim B. Clark, 2005 Low Medium Zero High Evidence of Option Value Successive, improving versions are evidence of option values being realized over time—after the fact Designers “see” option values before the fact
12
Slide 12 © Carliss Y. Baldwin and Kim B. Clark, 2005 Measuring Option Value Measure unpredicted residuals from performance data Example: TPC-C is a benchmark for transactions processors –153 submissions from 1/1/01 - 1/25/05 –Use regression to cull out predictable performance: TpmC/CPU = a 0 + a 1 (time) + a 2 (FrEnds/CPU) +
13
Slide 13 © Carliss Y. Baldwin and Kim B. Clark, 2005 Measuring Option Value (cont) TpmC/CPU = 5249 + 15.8(time) + 298( FrEnds/CPU) + StdDev( ) is a proxy for — of Mean TpmC/CPU
14
Slide 14 © Carliss Y. Baldwin and Kim B. Clark, 2005 To avoid complexity catastrophes in ULSs We need to track the evolution of architectures in real systems as they grow. For this we need good maps of real systems at the level of code, And better ways to measure option value ex ante and ex post.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.