We defined complexity in Chapter 3 as the property of having many interrelated, interconnected, or interwoven elements and interfaces. Most of the systems that we deal with professionally are complex, hence the growth of system architecture in practice. Complexity is driven into systems by asking more of them: more function, more performance, more robustness, more flexibility. It is also driven into systems by asking them to work together and interconnect—monitoring power demand at a manufacturing site relative to the grid’s capacity,* connecting customer order systems directly to manufacturing sequencing, instant communications among co-workers, and the like.

Underlying this definition of complexity is the idea that complexity scales with the number of entities in the system (a team of 30 people is more complex than a team of 10 people), as well as with their relative connectivity (10 people working together on one task is more complex than 10 people performing identical parallel tasks).

There are many potential definitions of complexity, but none of them has become operationally useful in a broad range of contexts. We present several of these subsequently for comparison, but it is our view that the simplest possible definition is perhaps the most conceptually useful, as shown in Box 13.1.

Our simple measure of complexity has the advantage that it formulates complexity as an absolute and quantifiable system property (once “measure” and “atomic level” are defined). This allows us to compare architectures: If one architecture has more things, more types of things, more connections, and more types of connections than the other, it is objectively more complex.

Many organizations use the word “complexity” but, when asked to define it, produce long, all-encompassing, qualitative, non-operational definitions. For example, the authors worked with a vehicle manufacturer that defined part sharing as a driver of complexity (essentially the number and types of entities). Part sharing was defined with respect to a product hierarchy with 13 levels, itself a nontrivial decomposition, shown in Figure 13.1. The firm then attempted to define the number of entities shared at each level of the hierarchy (part numbers shared across groups, across arrangements, across models, and so on). The net result of this analysis was not an incorrect definition of complexity, but it was so cumbersome (in part because the product decomposition was not universally agreed upon) that the measure went unused. In essence, the measure of complexity was too complex to be operational.

Complexity is an absolute and quantifiable system property, once a definition is agreed upon. Regardless of whether our simple definition or another definition is chosen, we believe that it is valuable to regard complexity as a measurable quantity. Complexity should not be viewed as an outcome of the design process, but rather as a quantity to be managed. Our experience suggests that when complexity is viewed as an intractable topic, it is more likely to be ignored, at the cost of increased complexity!

In addition to having a measure of complexity, in this chapter we discuss several ideas related to complexity: apparent complexity (also known as complicatedness), and essential versus ­gratuitous complexity.

We have asserted that one of the roles of the architect is to manage the evolution of complexity in the system. This is not to say that complexity is a negative property of the system. Complex systems today, such as regional transportation infrastructures and networked communication systems, deliver significantly more value than their simple counterparts, such as bicycles and letter mail. Complexity is an investment that the architect makes, where the payout is the performance of the system. This payout must be weighed against the challenges that complexity brings. Growing complexity is a fact of life.

The problem is that more complex systems are more difficult for humans to understand. In Chapter 3, we introduced the idea of complicated as a measure of our ability to perceive and ­comprehend complexity. Complicated things have high apparent complexity (or ­complicatedness); our human processer is more easily confused, or is less able to make sense of things (Box 13.2 Principle of Apparent Complexity). For example, we might argue that the structure on the left in Figure 13.2 is less complicated than the structure on the right. We can confidently assert that the pyramids were structurally less complicated, but we leave comparing the emergent system aesthetics of the two to the reader’s judgment and taste.

It is important to separate complexity from complicatedness in architecture. Complicated architectures seem intractable or unmanageable. This is why our definition of complicatedness takes into consideration the ability of the human to perceive and understand complexity. Consider Figure 13.3 and Figure 13.4. The same function is delivered in both cases, and the inputs and outputs at an electrical layer are identical, but one architecture is less complicated and more amenable to analysis and modification.

Complicated things have high apparent complexity. What causes apparent complexity? At first glance, complicatedness should scale with complexity; that is, more entities, more connections, and more types of entities and connections should all lead to more complicatedness. Most people would describe the organization of the cables in Figure 13.3 as the key attribute, and the system of Figure 13.4 is less complicated because it is organized. The two figures represent the same physical entities, but even if we scaled up the organized network and scaled down the disorganized network, we might well imagine that the now-larger, more capable organized network would still be less complicated than its disorganized smaller brother. In summary, complexity and complicatedness do not necessarily grow at the same rate in a system, an observation that allows us to hope we can increase complexity while limiting complicatedness.

The word “organized” is a very fuzzy term; for example, telling a junior network engineer to organize the backroom network does not lend itself to a step-by-step process. To unpack this backroom network, we’ll begin by using the tools of Chapter 3, starting with decomposition and abstraction. The network can be decomposed into entities such as cables, routers, and racks. It is easier to see this decomposition in the “organized” figure (Figure 13.4), because the bundling of network cables tells the viewer that they belong to a similar group. Individual cables in the bundle can be treated with the same analysis: A cable can be treated as an instance of a class of entities that share similar functionality. If we introduce the abstraction of a “bus,” represented by a bundle of cables tied together, the network appearance becomes simpler still, because we imagine that the same type of information is flowing along the bus, compared with the necessity of treating each cable separately in the complicated figure.

Is Figure 13.4 at maximum organization? It is hard to say without detailed knowledge of the function of the network. Could we develop a less complicated representation? Absolutely, depending on what information it is important to convey. We could draw a network diagram, but rather than showing point-to-point connectivity for cables, we could draw a layered diagram, with one of the layers being the physical connectivity layer. This representation might provide more information about the functional interaction among components or the higher-level uses of the network, but it abstracts out the detailed mapping of cables. In a sense, it “presumes” that the cables will be routed correctly, which releases the viewer from the burden of figuring it out. Whether this is a good or a bad attribute depends entirely on the use of the diagram or picture.

Consider low-level programming languages such as machine-level languages and assembly. They are hard to work with, even for experienced programmers. To reduce their difficulty, high-level languages like JAVA and MATLAB were developed. Systems become substantially more complex with the introduction of complex new technology such as compilers, interpreters, middleware, and graphical interfaces. These systems are more intuitive and less complicated to use. They present a system image that is vastly less complicated. Imagine inverting a matrix using assembly code; MATLAB does it in one instruction. For some users this investment in complexity is merited, but for others it is unmerited in light of performance compromises or scalability challenges.

Complexity is an absolute property of the system as we have defined it. Furthermore, the architect must invest in complexity in order to deliver more performance and functionality. This seems to beg the question: Is there a minimum complexity required to deliver a certain function and performance? Yes. We call this the essential complexity (Box 13.3).

For example, consider a powered liftgate, available on many hatchbacks and SUVs. At first it might seem that the minimum-complexity system would be a motorized liftgate with (1) a switch that interrupts power to the raising motor and (2) logic to reverse the direction of the motor. However, this simple switch would not capture the functionality of the system in Figure 13.5—namely, the function that prevents a user from opening the liftgate when the vehicle is moving.

Figure 13.5 illustrates the conditions that might be checked after the switch is depressed, before the liftgate is lifted or lowered. The circles illustrate processes, and the lines represent the objects of the system, the signals. The performance of the liftgate system in this SUV is partially measured by the physical liftgate (speed, smoothness of operation, and so on), but it is also partially measured by the safety of the system (for example, breadth of checks) conducted and accuracy of the checks. Although this representation appears complicated, it is hard to argue, upon closer inspection, that this diagram contains any gratuitous functions or forms. Does it represent only the essential complexity of the system, [⁵] as discussed in Box 13.3 Principle of Essential Complexity? Does it appear that this system has inherited previous architectures from legacy systems, and thus bears gratuitous complexity from history?

A system’s level of essential or gratuitous complexity is independent of its apparent complexity. The Concorde’s flight deck, shown in Figure 13.6, is visually overwhelming and requires extensive training to operate. This architecture has high apparent complexity—the complexity of the system is apparent. However, given the success of the Concorde, it could be argued that the complexity was essential to the delivery of performance with the technology of the era.

By contrast, the Smartphone shown in Figure 13.7 has very low apparent complexity, a hallmark of good user interface design for consumer products. It requires little or no training to operate. There is substantial complexity underlying this interface, but that complexity is hidden away. Without further detailed analysis, it is difficult to assess whether the internal systems are at a level of essential complexity or have gone beyond that to include gratuitous complexity. However, no one would argue that the Concorde’s user interface should be condensed into a hierarchic menu, four buttons, and a scrolling function.

We’ve argued loosely that decomposition and abstraction can be used to reduce the apparent complexity of a system, but we’ve also argued that apparent complexity and actual complexity are on independent axes. In fact, apparent complexity and actual complexity can be related. Consider the system shown in Figure 13.8. On the left we have five entities and six connections. If we break the system into two groups of three and two entities, respectively, we can reduce the apparent complexity of the system, as shown on the right-hand side, where we illustrate each group as an entity, and their connectivity with one connection.

However, if we take a look at the middle of Figure 13.8, we can see that something fundamental has occurred. Our decomposition introduces an interface between the two groups: The system now has six entities and nine connections!

In our effort to reduce the apparent complexity of the system, we have increased the complexity of the system above the essential complexity in the original representation. This result has far-reaching implications. It implies that apparent complexity can be reduced, but sometimes at the cost of increasing actual complexity. The architect must decide whether to invest in actual complexity (in order to bring down the apparent complexity), or not to invest, as discussed in Box 13.4 Principle of the 2nd Law.

The history of interface design includes many examples where attempts to reduce the apparent complexity by simplifying interfaces failed. Witness the first generation of BMW’s iDrive. The design intent was to reduce the apparent complexity of switches on the dashboard, consolidating the controls under a single button that could be twisted, angled, and depressed. The system was designed to operate on a menu screen. Users found that the menu was much deeper than desired, [6] forcing them to descend five levels to reach the heater controls! The press quipped, “iDrive? No, you drive, while I fiddle with this controller.” [7] The decrease in apparent complexity of the switches caused an unacceptably complicated menu interface—a net increase in apparent complexity.