In 1891 Ole Kirk Christiansen, was born as the 10th child of an impoverished family in Jutland, Denmark. Ole turned to work in a factory at the age of 14, transitioned to woodwork, and eventually graduated to be a master carpenter by the age of 20. But, he was no ordinary carpenter.
He had big ambition that was matched by his appetite to take on hard work, and a singular focus to build a company that would go on to become one of the most lasting brands in the world today, enduring the great depression, his wife’s untimely death, 2 fires that razed down his factories.
There are 400 billion Lego Blocks, 63 blocks per person today
Lego is one of the lasting toy brands in the world today
Yes, I was talking about the founding father of Lego blocks. The reason why I bring up Lego in this article is that they are a quintessential modular system that anyone of us can easily relate to as the chances are pretty high that we would have played growing up with a Lego system.
Understanding about how they broke the barriers that existed in their period to create a unique experience using modular design, that has withstood the test of time, could lend us important lessons in our own world to create a successful ecosystem. In digging in and learning about their history, there are few key monumental events that contributed to the success and popularity of their modular design. They are highlighted below:
Stud and Tube invention – Enhanced alignment between blocks,
ABS Plastic – A sturdier and stable material for predictable and lasting assembling,
System of play delivery of product – A new and unique experience to kids,
Growth propelled by licensing technology – Breaking the foreign market barrier
As we can see, it took 4 kinds of innovation – product, material, product delivery, and business that helped breaking the 4 barriers of modularity in this toy ecosystem.
Now applying that framework in our server technology world, defining in modules or blocks that connect to build a system is very effective if done right. However, understanding the barriers that exist today is key to building a lasting and successful ecosystem of these blocks as we saw in the Lego case study. The first issue that gets pointed out with modular approach vs a monolithic approach is the cost associated with connecting the different building blocks. Let us dig a little deeper and look at some of the key barriers to modularize:
- Cost : If the cost of connecting the blocks together are high in order to achieve flexibility, then there is trade off that needs to be considered whether there is enough number of configuration variations that warrants that flexibility in the first place.
- Requirements paralysis : The other key item to watch out for is the Kitchen sink effect. Since we now have modules and there are any number of ways the modules can be connected to provide different product configurations, the right architecture will be able to draw the line appropriately to keep the final configurations closer to reality that drives business value. Without this overarching principle, a modular approach could devolve into a sandbox, still useful, but only for conceptual modeling, but not to be a real product.
- Integration paralysis : Integration is another area that needs to be careful in a modular concept. Due to the availability of modules it again goes back to the principle of defining clearly the extent of the different product offerings that will come under scope and how they needs to be tested when they are connected together. A traditional approach of integration methodology applied to a modular approach will lead to an unending time in validation which defeats the purpose of creating the modular concept in the first place.
- Quality : Just with every good idea, if not implemented properly, it could actually lead to an adverse effect that it was originally going to solve. For example, in the case of modular concept, if applied correctly in a good architecture that defines the bounds of the design matched well with the needs of the business, then quality can actually go up since the same modules get reused. However, if done wrongly then it could lead to the connection of multiple new options not tested for their use case intent, which actually dents the quality of the product.
So there you have it – the 4 main barriers to modularity are Cost, Concise Requirements, Concise Integration, Quality control.
Once we judge that there is enough value to confront and devise different approaches to overcome these barriers, then the next questions that arise is
- Hardware : When it comes to hardware there are 3 layers starting from the schematics to PCB (Printed Circuit Board) to PCA (Printed Circuit Assembly). The levels of complexity to modularizing and thereby sharing increases as we move from schematics to PCB to PCA as the same set of schematics could be built in different shapes to fit into different chassis.
- Firmware : Firmware can also be modularized into 2 gross sections – The core firmware and the configurable firmware that provides the ability to customize the features and attributes based on customer preferences and use case scenarios. Within both the core and customizable firmware it is also essential to build and architect modules for all features that can be easily ported and benefit significantly from sharing verification testing.
- Mechanical : What defines the mechanical like we had earlier looked at is the type of rack infrastructure namely 19″ EIA, 21″ OCP, or 21″ OCS. Depending on the 3, there are different kinds of chassis. Within the chassis, there are provisions to fit IO slots, 3.5″/2.5″ Hard drive slots, M.2 slots, power supply slots, fan cages and such. A good modular design of the chassis could allow for sharing the chassis parts to be reconfigured and built to meet all the 3 infrastructure needs.
- Commodities : Most of the components or commodities like the CPU, Memory, Hardware, Storage controller, Network Controller, FPGA controller, GPU, hard drives, Flash drives that connect to the server are already modular and are shared across the different infrastructures. There are instances where a customer would like a specific firmware that gets loaded to enable a particular feature that might make the components different but in most cases the form and fit are the same.
There you have it – The 4 elements of Modularity are Hardware, Firmware, Mechanical, and Commodities.
As always, it would be great if you can share some of your thoughts, your own experience, and insights on the barriers and key elements to modularity. We are keen to know whether the tenets that we are considering for a modular platform are relevant to you and if so, in what ways? We would love to hear your feedback in the comments section below.
In the next blog we will see our design philosophy to determine the architectural line on how modularity can be achieved optimally.