Once the concept has been selected and the architect begins to define the full function-to-form mapping, the scope and information content of the development project can grow exponentially. Resources for each subsystem are added to the project during the design phase, marketing can begin shaping the message for the product, manufacturing begins to plan in earnest, and so on. In Section 3.2 we introduced complexity as an measure of a system, but now we focus on how to manage complexity.

We will argue that the most important task in this phase is the architect’s management of complexity. Development programs that appear complicated are very difficult to conduct systems analysis on, whether that systems analysis is thermal modeling of a spacecraft (a classic systems analysis), evaluating the handling of a sports car, or optimizing the computation time for new software. It is the architect’s responsibility to produce system descriptions that the relevant departments, functions, and stakeholders are able to comprehend and contribute to.

A central theme of this chapter is that complexity exists and is inherently neither good nor bad. We must consider it an investment to be made to reach system goals.

In Section 13.2, we introduce some of the attributes of complexity, to help the architect understand where complexity investments are merited. In the next section, we focus on decomposition as a key lever available to the architect in managing complexity. The chapter concludes with a case study on complexity and decomposition in the Saturn V and Space Station Freedom projects.