Library
The Innovator's Solution: Creating and Sustaining Successful Growth · 5 of 11
The Innovator's Solution: Creating and Sustaining Successful Growth
Entrepreneurship HIGH

Integration vs. Modularity — When to Own the Architecture

The Innovator's Solution: Creating and Sustaining Successful Growth Clayton M. Christensen & Michael E. Raynor
integration modularity not-good-enough core-competence outsourcing specifiability architecture

Key Principle

Whether to integrate or modularize is determined by circumstance, not by fixed notions of core competence. The causal chain: when a product is not good enough, interdependent (integrated) architectures win because engineers must optimize across component boundaries. When a product overshoots — becomes more than good enough — the basis of competition shifts, modular architectures emerge, and specialists disrupt integrated incumbents. The "core competence" framework is backward-looking and static; the circumstance-based question "Is the product not good enough?" is predictive and dynamic. (Chapter 5)

Why This Matters

The most consequential make-vs-buy decisions in business history have been decided by this mechanism — and decided wrong by managers using attribute-based thinking. IBM outsourced its PC microprocessor to Intel and its OS to Microsoft because component supply historically yielded subsistence profits. The circumstance-based question would have flagged those subsystems as future profit centers because they were not yet good enough. The same error recurs whenever firms use past profitability to predict future strategic importance. Modular interfaces require three preconditions — specifiability, verifiability, and predictability — and when these are unmet, outsourcing produces catastrophic coordination failures.

Good Examples

  • NTT DoCoMo's i-mode: In the early wireless data market (not good enough), DoCoMo succeeded with a fully integrated approach — controlling handsets, network, billing, and content standards. Western carriers that partnered across these interfaces produced massive losses because the interdependencies couldn't be managed across organizational boundaries. "It's not DoCoMo that makes the difference. It's employing the right strategy in the right circumstances that makes the difference." (Chapter 5)
  • IBM's 2.5-inch drives vs. 3.5-inch drives: IBM's integrated 2.5-inch drives (not good enough, notebook market) earned 40% margins and 80% share. IBM's 3.5-inch desktop drives (modular, more than good enough) captured less than 3% unit volume. Same company, different circumstances, opposite outcomes. (Chapter 6)
  • Specifiability/verifiability/predictability as diagnostic: When both parties can specify which attributes matter, measure compliance, and predict that there are no hidden interdependencies, a modular interface is viable. When engineers are pushing nonstandard designs to close performance gaps, these conditions are unmet and integration is required. (Chapter 5)

Counterpoints

  • IBM outsourcing to Intel and Microsoft: IBM treated microprocessors and operating systems as non-core commodities based on historical margins. The circumstance-based lens would have revealed these were not-good-enough subsystems where proprietary profits would accumulate. This single decision transferred hundreds of billions in future value to suppliers. (Chapter 5)
  • CLEC failures in DSL: Competitive local exchange carriers tried modular partnerships to deliver DSL service in an interdependent, not-good-enough market. The result was massive losses because partners couldn't resolve unpredictable interdependencies across organizational boundaries. (Chapter 5)
  • GM and Ford spinning off Delphi and Visteon: Both automakers divested the stage where the money was going (components becoming not good enough) to stay where the money had been (assembly becoming commoditized). They repeated IBM's mistake in reverse — outsourcing their future profit centers. (Chapter 6)

Key Quotes

"The problem with the core-competence/not-your-core-competence categorization is that what might seem to be a noncore activity today might become an absolutely critical competence to have mastered in a proprietary way in the future, and vice versa." — Christensen & Raynor, Chapter 5

"It's not DoCoMo that makes the difference. It's employing the right strategy in the right circumstances that makes the difference." — Christensen & Raynor, Chapter 5

"The bedrock principle bears repeating: The companies that are positioned at a spot in a value chain where performance is not yet good enough will capture the profit." — Christensen & Raynor, Chapter 6

Rules of Thumb

  • Ask "Is the product not good enough?" before making any integration/outsourcing decision. If yes, integrate. If the product overshoots, modularize.
  • Never use historical profitability of a value-chain stage to predict its future strategic importance. Circumstances shift.
  • Before outsourcing, confirm all three preconditions: specifiability (both sides know what matters), verifiability (both sides can measure it), predictability (no hidden cross-boundary interdependencies).
  • Watch for the profit-migration pattern: as one stage commoditizes, the adjacent not-good-enough stage de-commoditizes and captures attractive margins.
  • Replace "What are our core competencies?" with "Where in the value chain is performance not yet good enough, and do we need to own that interface?"

Related References