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 book, Design Rules: The Power of Modularity, Volume I (MIT Press: 2000), "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.

	The analogy of books on a bookshelf

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.