A system is complex if it has many interrelated, interconnected, or interwoven entities and relationships (Box 3.1). The fuzziness of the word “many” in this definition is deliberate for now.

Complexity is driven into systems by “asking more” of them: more function, more performance, more robustness, and more flexibility. It is also driven into systems by asking systems to work together and interconnect—your car with the traffic control system, your house with the Internet, and so on.

Complex systems require a great deal of information to specify and describe. Therefore, some measures of complexity are based on the information content of the description of the system. Other measures of complexity take the approach of trying to categorize what the system does; this is a function-based approach to complexity.

An idea closely related to complex is complicated. The definition of complicated takes into consideration the finite ability of the human to perceive and understand complexity. The systems of Chapter 2 are not complicated. We can understand them reasonably well after a few minutes of study. Complicated things have high apparent complexity. They are complicated because they stretch or overwhelm our ability to understand them.

Dealing with complexity is not new. In fact, by the time of classical Rome, complex systems were routinely built (such as large water delivery networks). However, over the last century, systems and the context in which they operate have become more complex (compare the telephone of 1900 and 2000). This increasing complexity has strained our ability to comprehend systems.

Our job as architects is to train our minds to understand complex systems so that they do not ­appear to be complicated to us. We should seek to build architectures that do not appear complicated to all the others who have to work on the system—designers, builders, operators, and so on.

The task of good architecture design can be summarized as follows: Build systems of the necessary level of complexity that are not complicated!

In this chapter, we will analyze the case of Team XT, which is an extended (XT) version of the Team X system introduced in Chapter 2. The team’s role is still to produce a design. All of the entities and relations of Team X are still valid, but more detail is considered. We have chosen to continue with the example of a more complex organization because many readers can easily relate to the example, and because the lessons of system thinking are readily applicable to organizations.

Imagine that we walk into a room at a company and are introduced to Team XT. We begin to apply the methods of Chapter 2—first by asking, “What is the system?” In this case, the system is still the group of people and process responsible for developing the design. Next, what is the form? In this case, the form is the sum of the people. The function is what the system does, its activity or transformation. Here it is to develop a design. We have completed Task 1 of System Thinking (Box 2.3).

If the entities of form of Team XT are the people, then determining the function for each ­member of the team requires careful observation, extensive experience, or interviews with the ­individuals. The resulting function of each of the members is listed in the third column of Table 3.1. Each of these functions has an operand and a process. As discussed in Chapter 2, we think ­holistically (Box 2.5) to identify all of the entities that might be important, and then we draw the boundary (Box 2.6) to focus on the designers and design processes. This makes the Marketing and Operations functions part of the context external to Team XT, as indicated by the dashed line in Table 3.1. Now we have completed Task 2 of System Thinking (Box 2.4).

Task 3 of System Thinking is to identify the relationships among the entities in the system and at the boundaries. In Table 3.1 we have identified the principal functional interactions among the Team XT participants, both within the team itself and across the boundaries to Marketing and to Operations. The fourth column shows the interaction, and the fifth column shows the person at the other end of the interaction. These are also shown in Figure 3.1.

The formal structure is shown in the last three columns of Table 3.1. Geographically, some of the team members are located in Cambridge, while the rest are in Moscow. There are several software tools and associated databases that help connect the team members. These are connection relationships. Finally, there is a reporting structure; these are human relationships that do not by themselves imply any interaction. The various kinds of formal relationships are discussed in more detail in Chapter 4.

Task 4 of System Thinking, identifying the emergent properties, will become more evident as we develop and apply the tools for thinking about more complex systems in the sections that follow.