In Part I we ended with the question “How big should the blocks be?” Just like with LEGO, there are pros and cons to large and small blocks. We also read that one large, monolithic block is nice and simple, but has its limitations in the number of variants.

Two laws of LEGO apply:

LEGO’s 1st Law states: the more blocks, the more variants you can build.

LEGO’s 2nd Law states: the bigger the blocks, the faster you can build.

It can be divided into modules in various ways. Top-down, or bottom-up. To understand this, one must view the product, the installation or machine as an assembly of separate parts.

In the most extreme top-down approach, one sees the whole motorcycle as one module (like the Part I company). In the most extreme bottom-up approach, each separate part is seen as one module.

To get an idea of how modular the product actually is, I use the modularity index. Very simply the number of modules divided by the total number of parts, expressed as a percentage.

Imagine that the motorcycle in our example is made up of 1000 separate parts. But we ‘keep it simple’ and distinguish 20 modules. The modularity index is then 20/1000 x 100% = 2%.

With a low index you have few, but more complex modules: after all, each module contains a relatively large number of parts.

With a high index you have many, but simple modules: each module contains only a limited number of parts. The complexity then lies in the mutual cohesion and dependencies. There are undoubtedly smart minds who can calculate for you how many combinations are possible with 1, 20, 100 or 1000 building blocks.

Large blocks hide a lot of complexity. That makes it tempting to stick to a rough modular layout. Life is complicated enough. Leave that to the R&D and engineering departments …

This denial of complexity comes back on your plate somewhere, downstream in the value chain.

There are also smart people who say “I make one big ‘smart’ block with all kinds of options so that I can realize all variants very quickly.” Especially popular in the software discipline. Sound like a good idea? Yes … at first, but not later. And that has to do with manageability. We will talk about that in Part III.

To keep it simple, I have limited myself to physical, tangible parts so far. Most companies that build modular only focussed on the mechanical parts. As a result their Bill of Materials (the parts list that is central in their ERP system) has become modular. In this way, they mainly achieve logistical benefits.

It is apparently assumed that the options that a customer chooses, and the product variants that result from them, can be traced back to physical parts. Often without the electrical parts, let alone parts that are not tangible. At a time when software is increasingly gaining a share in the ‘customer value’, this is of course no longer the case.

You read a lot about the increasing complexity of products. Especially because people are starting to realise the above. A Bill of Materials is still rather straight forward, compared to modular or non-modular structures in software. In addition, all those different structures appear to be interconnected and have dependencies (“Yeah dude!”). It will drive you crazy! But indeed, it can no longer be denied.

However many or few modules you have, your product is more complex than you thought!

In part three, we’re going to talk about managing complexity.