Very few companies are completely non-modular. Seeking building blocks that are reused and transversally shared across multiple products is a common activity in most businesses to gain scale and efficiency in product development, supply chain, aftermarket operations, and reduce the cost of complexity through the value chain.
However, surprisingly few companies have a systematic and conscious approach. They assume that, despite the ad-hoc approach, they are where they should be.
In this blog, I will guide you through what is called the Product Architecture Maturity Model. It is a cross-functional, reality-based understanding of where you currently stand and where you should aim to be. The Product Architecture Maturity Model is based on the dimensions of scope and time and covers the cross-functional dimensions of market, product development and supply chain.
Scope and Time
Scope refers to the market coverage by one product or platform. A standard product, even if versatile, has a narrow, dedicated market scope. The more possibilities you have for interchanging parts and adding/removing options, the wider the scope. A larger market can be served through more selectable performance values, functions, and features.
Time refers to the profitable lifetime of a product or platform. The situation where a product or platform is not phased out when it should be does not count. Continuing to live with under-critical volumes is not profitable business – it is just expensive life-sustaining activities.
Read more about how to relate to the scope and time dimensions in this post about What Makes a Good Modular System?
Six Levels of Product Architecture Maturity
Based on the two dimensions of scope and time, we at Modular Management have identified six different maturity levels. They are idealized and we understand that, in reality, it is often not this black-and-white. One product, for example, could be a combination of levels II and V. Despite this challenge, the model work great for identifying both current position and desired target state.
Level I – Delivery Project Centric
No real, pre-developed products exist. Each customer order is a uniquely-tailored and customized delivery, with designs and parts that will never be repeated. Some re-use can be achieved by copying previous deliveries. However, since this re-use is largely opportunistic, it is hard to take advantage of the re-use outside of engineering.
Level II – Stand-alone Products
Each product is its own silo with dedicated design. At any given point in time, each product has a predetermined specification, and the bill of material is fixed without any interchangeable parts. Commonality and reuse between different products are low. Products have a short life with high volumes and only undergo small face lifts, no larger improvements. New products are developed frequently, but old products keep on living in parallel.
Level III – Narrow scope, rigid Platforms
Each platform is its own silo with dedicated design. Inside each platform, there is a limited set of choices for customers to fit the specification to their needs, and, in the bill of material, only few parts are interchangeable. Commonality and reuse between different platforms are low. Platforms have a short life with high volumes, and they only undergo small face lifts, no larger improvements. New platforms are developed frequently, but old platforms keep on living in parallel.
Level IV – Medium scope, diverging Platforms
Each platform is targeting a wider market with many more selections for customers and more interchangeable parts in the bill of material. Each platform might also live a long time and be continually updated and improved. But during the life of the platform, developments tend to tear platforms apart, and they diverge into multiple sub-platforms that lack the original interchangeability and commonality between them. Commonality and reuse between different platforms decrease over time.
Level V – Medium scope, diverging Platforms with Transversal Modules
Similar to level IV, but now some key systems or components are shared transversally cross platforms. Often, this originates from a pure “technical necessity” to share the systems or components that are simply too expensive or resource demanding to develop and manufacture so they must be shared transversally.
Level VI – Wide scope, agile Modular Product Architecture
On the highest maturity level, the interchangeability and commonality across a wide range of products is intentional, addressing a very wide market. At the same time, it maximizes the internal synergies and economies of scale in R&D and Supply Chain. When faced with larger developments or facelifts, the entire Module System is updated to maintain the same level of interchangeability and commonality across all products. The divergence into separate “sub-platforms” is avoided. This maturity level puts very high requirements not only on the product architecture, but also on the organization and way-of-working. Governance of the architecture must be strictly controlled across all products.
Test which Level you are in our Online Product Architecture Maturity Model
Platform vs Modular Product Architecture
Products are often grouped together into platforms because they have the same physical size, they address a similar customer application and/or they have a common assembly structure. Platforms are also created for high-end, mid-end, low-end products and the products meeting the needs of different geographical markets. All of this reduces the scope of a platform. A global appliance manufacturer might have 10 or even more platforms for washing machines alone:
- One or several for vertical axis machines
- Several for 40 cm top loaded horizontal axis machines
- Even more for 60 cm, 25” and 27” front loaded horizontal axis machines
Each platform will have its own unique components reducing synergies in R&D and supply chain across all platforms. An improvement to one platform must be redesigned to fit the others. And even if total volumes are high, volume of each specific component is diluted by all the variance across products. In the supply chain, each assembly line is typically dedicated to one platform. When volumes shift over time, some lines are run with over-demand, poor quality (third shift syndrome) and lost orders due to non-availability of products. Other lines are running with poor utilization due to under-demand.
The difference between the Platform approach and the Modular approach can be visualized by the Volkswagen group journey from narrow Platforms to today’s Modular approach.
If you are interested in the topic about Platforms vs Modularity I suggest you check out When the Product Architecture is a System of Modular Systems.
Assessing Current Maturity level
To correctly identify your current Product Architecture Maturity level, it is not enough to examine engineering alone. You need to secure a cross-functional evaluation that covers sales, marketing, R&D, engineering and supply chain. The main parameters per product or platform to examine are:
- Market coverage
- Commonality of parts and designs
- Lifetime (with acceptable profitability)
- New products or platforms per year
- Updates or improvements of existing products or platforms per year
- Volume versus scale in procurement
- Footprint in assembly (dedicated cells, lines… or not)
You can do this assessment qualitatively with interviews and the collection of anecdotical evidence. But you can also do it quantitatively with actual measures for the above parameters that tell you where you are and where you should ideally be.
Defining Appropriate Target State
To define the desired target state, three dimensions should be evaluated:
- Which improvements and benefits you want to achieve
- Which improvements and benefits you can realistically achieve
- Constraints in organizational structure, resources, competence and budget that you are not able to impact.
Customer specific – ability to meet each customer’s unique combination of needs and requirements.
Time-to-Market – time to deploy across all products. Not to first launch which might be faster at the left side for large, non-compatible changes.
Internal complexity and indirect cost are strongly related to each other. The more designs and part numbers you have and the more frequent you change them, the higher internal complexity and indirect cost you will get.
Cross functional work, continuous development, stable products, and economies of scale are all also strongly related. You need enough scale over time (aggregated volume) for components and sub-assemblies to be able to set-up appropriate cross functional teams and efficiently drive continuous improvement. Modularity is enabling the needed scale and stability since Modules are used cross a wider range of the assortment and changes are made only to Modules that need to change – interfaces are protecting the other Modules from changes rippling through the entire design.
Feel free to reach out to me if you have any questions about the content or want to deepen the discussion or take out online survey to figure out how modular you really are.
Principal, Manager & Partner