Modular Architecture

Design shared modules across product variants: pay variety only where customers pay for it.

Time1 h
FormatSmall group
StageGenerate

Modular Architecture: what it is and why it works

Modular architecture divides a product into modules with clear, stable interfaces, so that variants can be built by combining modules instead of designing each one from scratch. The team maps the product architecture, identifies what varies by customer or option and what stays stable, and deliberately concentrates variation in a small number of modules. The remaining modules form a common platform that is frozen and shared across variants. Module owners and interface rules keep the architecture intact over time.

When every variant is designed as a special, engineering hours, part numbers, test procedures and production complexity grow with each order. A modular architecture lets the business offer variety where customers value it while keeping most of the product common, which increases volume per part, shortens lead times and simplifies testing. The approach is well established in product development literature, notably in Ulrich and Eppinger's work on product architecture, and in platform practice across many industries. Commonality has a cost: some platform parts may be oversized for the smallest variants, and that giveaway should be weighed consciously. Modular architecture extends standardization from single parts to whole modules and is a strong lever against complexity cost.

What you need

The current product range and variant history, including which options customers actually order
The product architecture: main functions, subsystems and their interfaces
Order data showing the frequency of each option or configuration
Cost and engineering hours per variant
Manufacturing and test process information

What you get

A module map with defined interfaces
A split between stable platform modules and variant modules
An estimate of the cost effects: fewer variants, more volume per part, simpler testing
Module ownership and interface rules

When to use it

When every variant is a special build and the factory juggles daily.

How to do it, step by step

Map the product architecture into modules with clear interfaces.
Identify what varies per customer or per option and what stays stable.
Push variation into a few modules and freeze the platform.
Estimate the cost effect: fewer variants, more volume per part, simpler tests.
Define the module ownership and interface rules.

Worked example: Reverse osmosis units from 10 to 200 gpm

Illustrative scenario — figures are realistic but not from a real company.

A manufacturer of packaged reverse osmosis units for industrial water treatment offered capacities from 10 to 200 gallons per minute. Almost every order was engineered individually, taking about 180 engineering hours and a lead time of 16 weeks.

The team mapped the unit into six modules: pretreatment, high-pressure pump, membrane rack, cleaning system, controls and frame.
Order history showed that variation came mainly from capacity, which affects the number of membrane vessels and pump size, and from feed water quality, which affects pretreatment. Controls, cleaning systems and frames differed between orders largely by habit.
The team designed a common frame family in three sizes, a single controls platform configured by software, and one cleaning module for the whole range. Variation was concentrated in the membrane rack and pretreatment modules.
They estimated the effects: fewer unique parts, more volume per part, standard wiring and simpler factory testing. Some frames would be larger than strictly necessary for the smallest units, adding cost there.
Each module was assigned an owner, and interface rules for flanges, electrical connectors and control signals were documented.

Result. Engineering hours per order fell to about 60, lead time dropped to around 10 weeks, and average unit cost decreased by roughly 8 percent despite the oversizing at the low end. The team learned that interface discipline mattered as much as the module design itself.

Open it in the FieldKit Design to Cost app → Get the Design to Cost template pack — join the waitlist

Common pitfalls and how to avoid them

Defining modules along organizational lines rather than functional ones.Base module boundaries on functions and interfaces, not on department structure.
Leaving interfaces loosely defined, so modules gradually become specific again.Document interface rules and require approval for any interface change.
Ignoring the cost of commonality in low-end variants.Estimate the giveaway and price variants consciously, or add a smaller platform size if it pays.
Allowing special requests to bypass the platform.Handle special requests within variant modules or as priced exceptions with explicit approval.

Frequently asked questions

What is the difference between modular design and a product platform?

Modular design divides a product into modules with defined interfaces. A product platform is a set of common elements, often modules, shared across several products or variants. A platform typically relies on modularity, but the focus is on commonality across a family rather than on the structure of a single product.

What are the downsides of modular architecture?

Modules can add cost through interfaces, such as additional connectors or flanges, and through oversizing when a common module must serve the whole range. Architecture work also requires upfront effort, and poorly defined interfaces can erode benefits. These costs are usually outweighed when variety is high, but they should be estimated rather than ignored.

How many modules should a product have?

Enough to separate what varies from what stays stable, and few enough that interfaces remain manageable. Many industrial products work well with roughly five to ten main modules. Let order data and function boundaries guide the choice rather than aiming for a specific number.

Origin

Modular product architecture — Ulrich & Eppinger, "Product Design and Development"; platform practice.

Used in these playbooks

Complexity pruning quarter 1 quarter

One quarter to cut what variety costs: measure complexity, standardize parts, modularize the platform and delete the functions nobody misses.

Related methods

More in “Generate”

Produce reduction ideas from functions, design rules and process rethink.