Designing Modular Systems

Jun 15

It seems that every time a new product architecture is being considered, modularity comes up. Often it quickly fuels designer's fever dreams of a world united under one all-powerful system, until cost, complexity and the realisation that a specialist product is often better optimised for any one of the given use cases brings things back to reality. Clearly the potential benefits of a modular product system are exciting, but designing a practical product system that meets the performance and cost targets of all the potential applications is very hard. Even Google gets it wrong, their modular phone Project Ara had a huge amount of excitement around it and was cancelled after 3 years of development. So how do you leverage the benefits of modularity when designing successful product systems?

This is a process I have been through many times working with 'Internet of Things' connected consumer products at Dyson and OPPO and in startups trying to maximise the impact of their R&D spend and I hope I can share some of the lessons I have learned here.

The first challenge is to define modularity as it encompasses so many different approaches to system design. Wikipedia defines a modular system as one where a system is sub-divided into modules which "can be independently created, modified, replaced or exchanged" [1]. What is left open to interpretation in this definition is whether these modules can be configured by the customer or only the manufacturer, or even whether the modules need to be usefully functional to the customer when used in isolation.

To illustrate the importance of these questions of scale, consider the different products you could use to build a home or do some computing.

The brick is often considered the smallest standardised module in the first modular product system. It is low cost, allows maximum customisation and is widely applicable to homes, walls and roads, but you need a trained brick layer to put them up for you and an individual brick doesn't provide much value if you are looking for somewhere to live. The brick, like the transistor, is a module that can only be really be used by the manufacturer. At the other end of the spectrum, a pop up tent is a monolithic product with no modules and could not be used to make a road or a long term home, but it is very well optimised to the specific use case of a temporary home for one night. In this specific application bricks just can't compete in practice, even though they could in theory. A MacBook Pro is another interesting example, because while Apple actively discourage you opening and upgrading, repairing or customising it through their design, it is still applicable to a very wide verity of computing tasks and is smaller, lighter, and often cheaper than an equivalent desktop PC which follows modular design principles. Both these examples highlight the risk of believing the hype about a modular system's 'potential'; theoretical potential needs to be demonstrated practice.

The realities of detail design for each specific application often mean fully modular systems get put aside while a hybrid architecture of some sort is moved forward with. To better understand why, the different modular product systems will be compared. Let's take the definition of modularity to be a product system that can be sub-divided into physical modules, each of which can perform a useful function for the customer in isolation, that can be combined to provide additional value that is greater than the sum of their parts. Each module is standardised and can be independently created, modified, replaced, or exchanged with other modules and between products. The product's modules can be configured and re-configured by the customer.

With this definition it is clear that all modular systems inherently incorporate the advantages of standardisation [2], as many monolithic products do. These can therefore be removed from the comparison of different approaches to modularity.

Benefits of Standardisation

Economies of scale reducing cost
Reducued waste
Ease of repair and maintenance
Decrease in operational overhead from SKU reduction
Consistent quality & performance characteristics

Approaches to modularity can be categorised in terms of the size of their sub-systems, which is directly related to the degrees of freedom the system provides. Looking at the two extremes on this spectrum, each has advantages and disadvantages.

Benifits of Small Modular Sub-Systems

+

Break down complexity
Long-term maintenance is easier
Facilitates reuse of design elements
Updates can be made to sub-systems faster and more frequently
Customisations do not affect the whole system
Each module is low cost

-

Systems with lots of modules might be more expensive
Significant design effort up front to understand all applications/combinations
Introduces duplication to keep Sub-Systems functional in isolation
Onus on customer to design and assemble their own final product
Greater logistics overhead to design, build, sell and maintain a greater number of sub-systems

Benefits of Monolithic Products

-

Updates can only be made by releasing a new product generation
Limited applicability to other applications
Customisations require ground-up redesign
Can be over specified with many unnecessary features when trying to serve more than one application
Maintenance is more challenging

+

Can be developed faster
Better optimised for any given application
Simple to understand and easy to use
No duplication, can be cheaper

Modular Design Principles

As with all design problems, any real world solution needs to balance a number of requirements and so a compromise between these two extremes is usually required. To select the best sub-system size, the guiding metric must be the value provided to the customer. Each application that the modular system is intended to address must therefore be considered in detail, you cannot design modular systems for applications you dont know about. General advice for the design of modular systems can be offered as a number of principles:

Forget about nebulous 'potential' of modularity and select specific applications your modular product system is trying to address and understand your customers needs in each case. Use a venn diagram to check there really are enough synergies that one product system can really meet all these requirements.
Try and figure out every combination of sub-modules that will actually be used by customers in these applications and don't try to make the sub-modules more granular than this. This will help avoid duplication of components and unnecessary design effort. Using a common base module will also help [3].
Ensure each module can perform a complete function useful to the user.
Use system design principles to ensure the modules are going to work together well and result in value that is greater than the sum of the parts. Draw a network map of modules, set the inputs and outputs of each module and show how key elements like power and data move through the system. Remember to map each possible configuration. These interconnections drive both the complexity of the system and it's flexibility.