Monolithic & Modular Design
When designing a system, one of our key architectural considerations will be to decide whether we are building a homogeneous system or a modular system. For example, in the design of the mechanical structure of a new 3D printer, one could take two different approaches. Firstly, deciding to take a monolithic approach, in which case the whole frame would be cast out of plastic. Or one could take a modular approach, using nuts and bolts to clamp sub-components together and combine these subsystems to build the whole mechanical system as a composite of modules. A homogeneous architecture integrates and constrains the sub-components into one overarching system. For example, building my house out of poured mass concrete instead of individual building blocks. The Unibody to Apple’s Mac Book is another example of a homogeneous architecture.
Distributed Design Pattern
Modular design, in contrast, is a systems architecture that distributes the whole system into a set of distinct modules that can be developed independently and then plugged together. Examples of this might be an electronic circuit board made out of autonomous electric components or a house made out of prefabricated modules that plug together. Modularity is a key feature of complex engineered systems (with the Internet again being a paradigm of modular architecture) for a number of reasons.
Firstly, by definition, complex systems are highly interconnected. That is why we model and talk about them as networks. In these highly interconnected systems, the cost of interaction will be very low. This low collaboration cost makes it much easier to unbundle homogeneous systems, distribute them into modules, and then reconnect them into a composite whole through the network. Economic globalization might be an example of this, as the barriers and cost of international trade have dropped. Modular supply chains have emerged where production processes and supply chains become unbundled and distributed due to the ease of interaction through global logistics networks and telecommunications. Secondly, complex systems are composed of autonomous elements, meaning we cannot fully constrain them within one integrated top-down model. Componentization gives each element a degree of autonomy, thus allowing it to adapt.
Designing Modular Systems
So, what do we need to design a modular system? Well, we need at least three things: a module, an interface, and a set of protocols for interconnecting those modules. Firstly, in order to create modules, we need to unbundle our monolithic system. In computer science, this is called separation of concerns. We are trying to capture what makes each component a separate concern, that is to say, autonomous and different from everything else. Looking at a map of the world, we will see it is distributed out into countries. Each of these countries is different in some way and has some degree of autonomy. How we disaggregate the system is very important. If we draw arbitrary lines in the sand without proper respect to the cultural and economic systems that lie behind them, then problems will arise further down the line. The concept of a module is to both define distinct separate functions and also to encapsulate this function, thus abstracting away its internal mechanics from the system at large. This is called black-boxing.
In science and engineering, a black box is a device, system or object that can be viewed in terms of its input, output and transfer characteristics without any knowledge of its internal workings. We define and display these inputs, outputs and functional characteristics with an interface that will tell other modules in the system what this element will do. It is a bit like a person’s profile on LinkedIn. Their profiles are the interface telling you what they do. The interface should also tell you what to give the module and what to expect in return, like when you buy a new car there will be a poster in the window telling you to give it a certain quantity of gas and it will transport you a certain distance. A car, like many things, is a black box, you don’t need to know what goes on inside of it to drive it. Lastly, we need some way of joining these modules together, what we might call coupling them. This coupling may be loose, meaning the modules have a high degree of autonomy, or they may be tightly coupled, meaning they are more constrained by their interaction with other modules and the system. This coupling also requires a set of protocols to define the terms, agreements and common language through which modules interoperate.
The advantages of modular design include: Firstly, it can enable distributed collaboration and problem solving. We may be dealing with a very large complex system that would require nothing less than a genius or a hero to fully grasp and manage. Through modularizing the system, various functions can be more easily distributed across a large team with no team member creating or even understanding the whole system.
Secondly, modules can be endlessly re-used, like Lego bricks. We can combine and recombine them, making it more likely to be a sustainable solution. It should also be much easier to manage and maintain the life-cycle of the system. Individual components showing fatigue can be replaced without having to replace the whole system, and we should be able to do this with minimal downtime.
Thirdly, modular systems are much more versatile, adaptive and can be customized more easily. The modular design employed in the automotive industry makes it easier for car dealers to offer a wide variety of customizations, where they simply “snap in” upgrades, such as a more powerful engine or seasonal tires. Lastly, modular design can be a very important contagion mechanism. Because a cup is a monolithic design, a crack will easily propagate through the structure, rendering the entire system dysfunctional. By designing for autonomy we reduce the dependencies within the system and the modules act as natural buffers to disaster spreading and for maintaining security.
The disadvantages to modular architecture include: Firstly, because everything has been disaggregated, everything will have to go through some network of interactions to take place. Unless the cost of interaction is very low, it will place a very high burden on the system. So if my bank takes 50 dollars for processing every financial translation on my credit card, the system would bankrupt me pretty quickly. Excessive modularization can lead to a fractured system. Say I have 100 people to feed and I go into the store to buy some bananas, but each one is wrapped in a module of plastic with a label. Well, I am going to spend quite a bit of time unwrapping each one and create quite a lot of waste in the process. Unless the protocols and interfaces to the modules are well designed, we can waste a lot of time continuously negotiating contracts between modules. If you had to do your shopping at a local market where you have to barter for everything in a language you don’t understand, your response would likely be to look for a supermarket where you could get everything in one go. When contracts between modules are difficult and costly to negotiate, we will want to reduce the number of interactions, and thus make the system more homogeneous.
Lastly, modular systems may be good for a lot of things but they are not optimized for performance. Typically, a homogeneous design will offer the quickest, easiest solution with the greatest performance, at least in the short run. If you go looking for the cheapest and easiest option for a chair, shovel, wheelbarrow or most consumer goods, it will likely be one homogeneous mass of injection molded plastic. Modular systems architecture may have been around since the building of the Egyptian pyramids but the Internet is showing us that by building a platform with effective protocols that reduce interaction costs, we can use modularization and mass distribution of components as a highly effective way of engineering complex system.