In one line: Architecture is how a product’s functions are assigned to physical chunks and how those chunks interface. Chosen early, it shapes cost, variety, upgradeability and how the team itself is organized.
Core idea
Every product has two descriptions: functional elements (what it does) and physical elements (the parts that do it). Architecture is the scheme that maps one onto the other and defines how the physical chunks connect [1]. The key distinction is between two types:
| Modular | Integral | |
|---|---|---|
| Function-to-chunk mapping | roughly one-to-one | many functions share chunks; chunks share functions |
| Interfaces | well defined, often standardized | complex, tightly coupled |
| Strengths | variety, upgrades, parallel development, reuse, easier service | peak performance, compactness, low cost at high volume |
| Typical example | desktop PC, rack-mounted electronics | high-performance engine block, a smartphone’s main board |
Modular architectures come in flavors: slot (each interface is different), bus (chunks share a common interface) and sectional (chunks connect to each other through identical interfaces).
How it works
- Create a schematic of the product’s functional and physical elements.
- Cluster the elements into chunks, considering geometric integration, function sharing, supplier capabilities, similarity of technology, the likely locus of change, accommodating variety, enabling standardization, and portability of interfaces.
- Create a rough geometric layout to check that the chunks physically fit.
- Identify fundamental and incidental interactions between chunks: the ones designed in, and the side effects such as heat, vibration and electromagnetic coupling.
- Develop the detailed interface specifications that let teams work in parallel.
Why it matters strategically: architecture enables (or blocks) product change, product variety, component standardization, product performance, manufacturability and how product development is managed. Teams often end up organized around the chunks, so architecture shapes the organization too.
In practice
A common exercise is to take a familiar product (not an Apple product, which is too easy an example of integral design) and ask whether it is modular or integral, and why its designers chose that. In electronics, the same system often mixes both: modular at the box level, so that subsystems can be swapped or upgraded, and integral at the chip or board level, where every millimeter and milliwatt counts. For any project, it is worth asking which architectural decision you made earliest, and which one you will be living with longest.
Questions to ask yourself
- Is my product modular, integral, or mixed, and was that a deliberate choice?
- Which interface in our system causes the most integration pain?
- Where will future change most likely happen, and does our architecture make that change easy?
Connections
- Downstream: Design for Manufacturing, Trade-off Analysis. Upstream: Concept Generation, Product Planning (platforms).
- The systems view: Systems Engineering.
- Capabilities exercised: Vision, Decision Making, Connecting Across Disciplines.