Systems Architecture · Chapter 13
Box 13.1 · Definition: Complexity. Several simple measures: N1 = number of things, N2 = number of types of things, N3 = number of interfaces, N4 = number of types of interfaces.
\[C = N_1 + N_2 + N_3 + N_4\]

A vehicle manufacturer’s attempt to define complexity via part-sharing across a 13-level product hierarchy. The measure was not incorrect — but it was so cumbersome (the decomposition itself was never agreed upon) that it went unused. Source: Crawley, Cameron & Selva (2016), Fig. 13.1.


The pyramid is less complicated than the Taj Mahal, even though both perform the same function — entombing royalty. In civil architecture there are aesthetic reasons for “complicatedness.” Source: Crawley, Cameron & Selva (2016), Fig. 13.2.

The same function is delivered by Figures 13.3 and 13.4, and the inputs/outputs at an electrical layer are identical — but one architecture is far less complicated and more amenable to analysis and modification. Source: Crawley, Cameron & Selva (2016), Fig. 13.3.

Decomposing the network into cables, routers, and racks — and abstracting a bundle of cables into a single “bus” — makes the organization legible without changing what the network does. Source: Crawley, Cameron & Selva (2016), Fig. 13.4.
Tip
Low-level languages (assembly) are hard even for experienced programmers. High-level languages (JAVA, MATLAB) reduce apparent complexity — MATLAB inverts a matrix in one instruction. For some users this investment is merited; for others it costs performance or scalability.


A powered liftgate’s logic: circles are processes, lines are signals. A minimum system (switch + reversing logic) wouldn’t capture the function that prevents opening while the vehicle moves. It’s hard to argue this diagram contains gratuitous functions or forms — but does it also carry gratuitous complexity inherited from legacy architectures? Source: Crawley, Cameron & Selva (2016), Fig. 13.5.

A system’s essential or gratuitous complexity is independent of its apparent complexity. The Concorde’s flight deck is visually overwhelming and required extensive training — high apparent complexity. Given the Concorde’s success, that complexity could be argued essential to delivering its performance with the technology of the era. Source: Crawley, Cameron & Selva (2016), Fig. 13.6.

The smartphone’s touchscreen interface has very low apparent complexity — little or no training to operate — while masking substantial internal hardware complexity. No one would argue the Concorde’s interface should be condensed to a menu, four buttons, and scrolling — but is the phone’s hidden complexity essential, or gratuitous? Source: Crawley, Cameron & Selva (2016), Fig. 13.7.

Five entities, six connections (left). Grouping into two clusters of three and two apparently simplifies the system to one connection (right) — but the decomposition introduces an interface between the groups: the system now has six entities and nine connections (middle)! Reducing apparent complexity can increase actual complexity. Source: Crawley, Cameron & Selva (2016), Fig. 13.8.

iDrive, a cautionary tale. BMW’s first iDrive consolidated dashboard switches under one twist/angle/press controller to reduce apparent complexity — but the menu ended up five levels deep to reach the heater. Reducing apparent complexity of the switches caused a net increase in apparent complexity of the menu.






Conway’s Law (1968): “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
Tip
Alan Perlis: “Wherever there is modularity there is the potential for misunderstanding: hiding information implies a need to check communication.”
| Plane | Guidance |
|---|---|
| Delivered function & emergence | Don’t spread key delivered functions across many elements — it complicates managing emergence. |
| Form & structure | Cluster high-connectivity elements; avoid placing interfaces where connectivity is high. |
| Design latitude & change propagation | Group tightly-coupled designs to maximize latitude and limit change propagation. |
| Changeability & evolution | Place interfaces so modules can combine into platforms and support evolution. |
| Plane | Guidance |
|---|---|
| Integration transparency | Create interfaces that enable easy testing and visibility at the interface. |
| Suppliers | Interface points let suppliers work independently — they can define modularity, or defy it. |
| Openness | Balance third-party innovation/network effects against information-sharing drawbacks. |
| Legacy components | Reuse of legacy components constrains decomposition and challenges interface design. |
| Plane | Guidance |
|---|---|
| Clockspeed of technology change | Let technologies evolving at different rates be changed out asynchronously. |
| Marketing & sales | Enable differentiating features and cosmetic refreshes without architectural change. |
| Operations & interoperability | Delineate operator touch points and wear parts for easy training, maintenance, repair. |
| Plane | Guidance |
|---|---|
| Timing of investment | Modularize to phase development spending across time. |
| Organization | Match the modularization of the system to the organization (Conway’s Law). |
Tip
Reference: Crawley, E., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson. Chapter 13.

The Saturn V, developed by NASA 1962–1968, launched the Apollo Command Service Module, Lunar Module, and crew from Earth’s surface into orbit and toward the Moon. Its solution-neutral function: accelerate a payload by a change in velocity (Delta-ν) in each of three stages. Source: Crawley, Cameron & Selva (2016), Fig. 13.12.
| Stage 1 | Stage 2 | Stage 3 | |
|---|---|---|---|
| Stage 1 | Delta ν1 | ||
| Stage 2 | Delta ν2 | ||
| Stage 3 | Delta ν3 |
| Stage 1 | Stage 2 | Stage 3 | |
|---|---|---|---|
| Stage 1 | TGLA | ||
| Stage 2 | L | TGLA | |
| Stage 3 | L | TGLA |
| Stage 1 | Stage 2 | Stage 3 | |
|---|---|---|---|
| Stage 1 | Boeing | ||
| Stage 2 | North American | ||
| Stage 3 | McDonnell |
T-creating thrust, G-creating guidance torques, L-carrying structural load, A-reacting aerodynamic loads. Source: Crawley, Cameron & Selva (2016), Table 13.1.
| Stage 1 | Stage 2 | Stage 3 | |
|---|---|---|---|
| Stage 1 | Fire 1 | ||
| Stage 2 | Fire 2 | ||
| Stage 3 | Fire 3 |
Tip
The Saturn V was the largest launch vehicle ever built and had a perfect launch record — alignment of decomposition planes, simple interfaces, decentralized testing, and simple integration were major contributors.

Space Station Freedom (SSF), a semi-permanent Earth-orbiting station announced in 1984, was never built — over a decade it underwent design changes and eventually evolved into the International Space Station (1993). Source: Crawley, Cameron & Selva (2016), Fig. 13.13.
| Solar Array | Truss | Modules | |
|---|---|---|---|
| Solar Array | ISM | ISM | ISM |
| Truss | ISM | ISM | ISM |
| Modules | ISM | ISM | ISM |
| Solar Array | Truss | Modules | |
|---|---|---|---|
| Solar Array | PL | PL | P |
| Truss | PL | PLEA | PLE |
| Modules | P | PLE | PLEC |
Left legend: I-international relationships, S-space operations, M-micro-gravity science. Right legend: P-provide power, L-carry structural load, E-conduct experiments, A-attitude control, C-house crew. Source: Crawley, Cameron & Selva (2016), Table 13.2.
| Solar Array | Truss | Modules | |
|---|---|---|---|
| Solar Array | R | R | R |
| Truss | R | RM | RM |
| Modules | R | RM | RMB |
| Solar Array | Truss | Modules | |
|---|---|---|---|
| Solar Array | 1 | 1 | |
| Truss | 1 | 123 | 23 |
| Modules | 23 | 23 |
Left legend: R-Rocketdyne, M-McDonnell Douglas, B-Boeing. Right: entries are Shuttle flight numbers (MB-1, MB-2, MB-3) from the 1987 manifest. Source: Crawley, Cameron & Selva (2016), Table 13.2.
Ten years of SSF development, roughly $10 billion spent, only modest progress. In 1993 the program was dramatically restructured under a single prime contractor (Boeing) and a single NASA center — aligning launch packages with elements and functions with elements.
Having selected a concept and managed the complexity of its architecture, Chapter 14 turns to architecting as an explicit decision-making process — illustrated with a case study of the Apollo mission-mode decision.

← Course Home · Systems Architecture · Chapter 13