A number of my colleagues don't believe you can teach design, or at least that teaching design is hard to do. I not only disagree, but feel that if we're to help students prepare to be influential, we have to teach design. Good programmers are also good designers, many are good architects. But for the most part, they've picked that up as an implicit part of their education. Explicitly people taught them the nuts and bolts of programming.
Consequently, I'm always on the hunt for books that I think future CTOs and CIOs ought to read. I found a spectacular example over Christmas break: Design Rules, Vol. 1: The Power of Modularity by Carliss Y. Baldwin and Kim B. Clark. This book is a must read for anyone who is or aspires to be an architect, CTO, or CIO.
Baldwin and Clark were at Harvard Business School when this book was written (Clark is now President of BYU-Idaho). The book is a great mixture of design, business, and technology that, in my mind, strikes right at the center of what a CTO ought to be concerned with: how architecture, specifically modularity, affects the value of products. Some finance and business background is helpful, but not an absolute must--I'd use this book in an upper division CS class with no business prereqs, for example.
The book is about the power and value of modularity in general, but Baldwin and Clark use the computer industry as an example. Most of us are so used to modularity in the computer industry that we take it as a fore-ordained imperative, but Baldwin and Clark show how modularity was imperfectly understood and executed in early computer systems and how IBM, with the creation of the System/360 completely changed the computer industry forever.
In the early 60's IBM invested $20B in 1999 dollars to create System/360. That's right--they invested $20B before they ever sold anything in a scheme that was quite risky. They had to issue more stock to maintain a positive cash position during the development period. The investment paid off handsomely, earning IBM approximately $170B in 1999 dollars as a result.
My first reaction was "what company today would have the resources and guts to invest $20B in a new, speculative technology product line?" But as I read, I realized that's precisely the point: they don't have to. IBM's investment changed the nature of the industry so completely that modularization is the name of the game. Thousands of individual companies invest similar amounts in new ventures in aggregate, but no one company has to because of modularization. Not only is the investment spread out because of the architecture of computing systems, so is the risk.
Web 1.0 is a great example. Because of the architecture of the Internet and specifically HTTP, URLs, and HTML, thousands of companies tried their hands building modules to fit in that architecture. These experiments represented billions of dollars in investment. Some paid off and some didn't. Rather than one or two firms trying to guess what people want and then investing everything in an all or nothing project, the modular architecture more or less assured that a decentralized market could run thousands of experiments. The result is the Web we use today. It's modular architecture allows it to continue to evolve in a piecemeal fashion.
Design Rules does an excellent job of making this all explicit in ways and at levels that CS students seldom see. This book isn't a book on software architecture. This is a book that tells you the power of architecture when it's done right and quantitatively shows the value of modularity.
