| ||||
The computer age began some six decades ago with general-purpose machines with Star Wars-like names such as ENIAC and EDVAC. They were powered by vacuum tubes, big enough to fill an entire room, and developed by mathematicians under the auspices of what was then known as the War Department.
By 1960, electronic data processing as well as information storage and retrieval had made a lasting impression in both the private and the public sectors, and discoveries and improvements in areas such as circuit design and solid-state electronics promised better performance at decreasing costs.
But a potentially serious drawback threatened to stand in the way of further progress. As HBS Dean Kim Clark, and his colleague, Professor Carliss Baldwin, write in their new book, Design Rules: The Power of Modularity, Volume I (The MIT Press),"The support of older applications and systems was becoming a problem of nightmarish proportions [because of] the growing complexity of the systems and the interdependent structure of their designs. Each new computer system had to be designed from the ground up, and only new systems could take advantage of new technologies.
"The solution to this dilemma came from IBM in the early 1960s with the introduction of the System/360, the first modular family of computer systems." And it was modularity, Baldwin and Clark explain, that made all the difference. "Under this approach, different parts of the computer could be designed by separate, specialized groups working independently of one another. The 'modules' could then be connected and (in theory at least) would function seamlessly, as long as they conformed to a predetermined set of design rules."
In addition, module designs could be improved after the fact without redesigning the whole system. In effect, each module was free to evolve along its own trajectory. By accommodating unforeseen, after-the-fact improvements, the modular approach unleashed value for the system as a whole.
At the request of Working Knowledge, Dean Clark, an expert in technology and operations management, and Professor Baldwin, an authority on finance, recently sat down for a discussion of their work.
Kim Clark: We write in the book about a design becoming "truly modular." Let me begin by clarifying how we define that. A truly modular design has a clear architecture, clean interfaces, and a set of well-specified functional "tests" of each module's performance. All systems built out of System/360 modules worked together as one and could run the same software. Furthermore, new modules could be added to the system and old ones upgraded without rewriting code or disrupting operations.
Carliss Baldwin: A bookshelf and books provide a low-tech example. A bookshelf is designed to be between 12 and 24 inches in height and have a flat bottom and sides. That is a simple architecture with three flat interfaces. The books—or, if you will, the modules—fit into that space. What's important, however, is that many different books can be arranged on the shelf in a number of ways—alphabetically, by author, by topic, or whatever. The fact that many modules can be arranged in a number of ways is characteristic of a truly modular system. In Design Rules, we emphasize that such modularity does not happen by accident; it has to be designed into the system. You have to invest in the architecture and interfaces among modules and test performance at the modular level. The whole system has to work, as do the individual parts in relation to each other. This is what the design rules specify.
KC: In disk drives, for instance, the addressing scheme, the size of the data path [the wires on which the data flow], the number of pins [connectors between the disk drive and the computer], and the signal attached to each pin, along with certain software commands such as "read" are examples of design rules. Disk drive designers must obey these rules if their drives are to function in a given computer system.
CB: As long as the rules are obeyed, disk drive designers can vary many of the other aspects of the design. We call the things that can vary "the hidden design parameters," because they don't have to be seen by the designers of other parts of the system. For example, by incorporating new technologies and ideas into the hidden parameters, designers can create better, faster, smaller, more efficient disk drives that will work in the larger system. So, not only are design rules critical, they have to be communicated and adhered to throughout the design process—from the initial concept stage until the design is complete and ready to be produced.
KC: This is what we mean by the "power of modularity." Working within a given set of design rules, module designers still have a lot of choices. Their alternative designs will normally display different performance characteristics that customers care about. In a modular system, those alternatives can be mixed and matched. The system, as a whole, will work with one device or module—that is cheaper than another, that is faster than another, and so on.
CB: Again, think of the analogy of various kinds of books on a shelf.
KC: What's important is that it is possible to seek the "best of the best" combination through mixing and matching. This kind of choice is the equivalent of holding a lot of options on each module within a computer system—an option on the disk drives, the software, the CPU.
CB: These "options on modules" are like financial options. As we show in the book, you can use financial analysis to begin to quantify the value of these choices. This is what we refer to as "options embedded in the design." Any design, modular or not, has an option embedded in it. At minimum, you can accept the design of any system or reject it. Modular designs, however, are unique in having many options, because the modular structure makes it easy and cost-effective to experiment and incorporate the results of the experimentation into the system.
KB: So a modular design with, say, ten modules might justify ten or more trial designs per module. The module designers can experiment with those alternatives and test them, choosing the one that delivers the best combination of features such as speed, size, and cost.
CB: But there's a danger in this paradise if you're a modular system designer. Anyone who knows the design rules can create a module that works within your system—something we refer to as "decentralization." It happened to IBM with its disk drives and other peripherals in the early 1970s, after the truly modular design of the System/360.
KC: Disk drive designers left IBM in droves and founded their own firms to design and manufacture drives that would "plug into" System/360 and thus compete with IBM products. This was a seminal event in the growth of Silicon Valley.
CB: The effects of the ensuing competition on modules were better designs and lower prices. Customers were eager to buy the new plug-compatible, non-IBM components. This demand, in turn, attracted venture capitalists, who created a financial conduit between large institutional investors and fledgling firms.
KB: And that in turn triggered more departures from established companies, more module designs, more experimentation, and more investment. This dynamic began in the mid-1970s and continues to this day. And it is hardly limited to disk drives.
CB: Ultimately, though, the power of modularity does not lie simply in the creation of financial option value and the ensuing impact on competition. Modularity also helps simplify complex systems and divvy up complex tasks so that individuals and companies can focus their efforts productively on a manageable set of objectives. The design rules ensure that the results of this division of labor can be reassembled into a functioning, improved—and improvable—whole. What's more, the value of both the parts and the whole continually increases. All this is at the heart of an industry that has reached remarkable levels of innovation and growth in a relatively short period of time.