Decomposition is the dividing of an entity into smaller pieces or constituents. It is one of the most powerful tools in our toolset for dealing with complexity. “Divide and conquer” is a fundamental strategy. Break a problem down into smaller problems until each is tractable. It is no coincidence that Julius Caesar’s account of the Gallic Wars opens with the declaration “All Gaul is divided into three parts.” By the time of classical Rome, this approach was understood and widely applied.

As discussed in Section 2.4, sometimes defining decomposition is easy—for example, when the system is made up of distinct elements. Sometimes the system is modular, which suggests decomposition, and sometimes it is integral, where the decomposition can be somewhat arbitrary.

The difficulty with breaking things apart is not in the breaking apart, but in the process of bringing together the decomposed entities to build the whole. This process is often called integration. In the formal domain, we say that form aggregates, and we have to worry about the physical/logical fit between the elements as they are brought together. In the functional domain, we decompose functions into more basic functions, and then, in recombining the entities of function, we encounter emergence: the real challenge.

Let’s begin the analysis of Team XT. Above, we jumped to the conclusion that the right way to decompose the system was based on the distinct elements of form—the members of the team. If the form is not so distinct, or is not yet defined, we are more likely to consider decomposing based on entities of function. This might produce entities tagged with functions (steering mechanism, compressor, sorting routine). Examining Table 3.1, we see that there are several places where focusing on function would yield a different decomposition. For example, the function “Develops requirement documents” is common to both Jose and Vladimir, so an alternative decomposition might have included Jose and Vladimir in one entity. Such a function-based decomposition might have better supported the understanding of emergence.

Hierarchy is another powerful approach that can be used to understand and reason about complexity in systems. Hierarchy is defined as a system in which entities belong to layers or grades, and the layers are ranked one above the other. Hierarchy is very commonly found in social systems. For example, in the military there are grades: generals, colonels, majors, captains, and so on. In large companies there are presidents, executive vice presidents, senior vice presidents, and so on.

Julius Caesar, The Gallic Wars, Translated by W. A. McDevitte and W. S. Bohn.

What causes some grades to be higher in the hierarchy than others? Generally:

• They have more scope: Governors rank above mayors because they have more scope (a state is larger than a city).

• They have more importance or performance: Black belts rank above brown belts ­because they perform to a higher standard and have greater skills.

• Their functions entail more responsibility: Presidents rank above vice presidents ­because they have more responsibility.

Hierarchy is not always obvious. Even close examination of Figure 3.1 and Table 3.1 does not reveal the actual hierarchy in Team XT. This is because the group leaders and managers ­actually work in the delivery of value, rather than simply reviewing the work of others. We need to examine Figure 3.2, which explicitly shows hierarchy, to see that Sue is ranked above Amy, John, and Phil, who themselves are ranked above all others on the extended team. We extracted this information from the last column of structural information in Table 3.1. The hierarchic view presents quite a different impression than the egalitarian view of Figure 3.1; now it is obvious that some team members are somehow more important than others. Note that hierarchy does not imply that anyone on a particular level reports to any specific person on the next level. That ­occurs only in hierarchic decomposition.

Often, decomposition and hierarchy are combined into a multilevel or hierarchic decomposition: a decomposition with more than two levels, as shown in Figure 3.3. Figure 3.3 is cognitively much more satisfying than the undifferentiated second level of Figure 3.2. It appeals to our desire to group things in sets of seven +/– two. [1] Figure 3.3 shows three group leaders reporting to Sue and about four people reporting to each of the group leaders.

The “group” is a useful abstraction suggested by Table 3.1 and Figure 3.2, but it is not a unique way to decompose the team. We could have clustered the team members in several other ways at the level below Sue, including by location, connectivity, or functional relationships. In fact, Figure 3.2 does not imply anything about who is close to or connected to whom (formal relationships) or who exchanges information with whom (functional relationships).

Figure 3.4 a simple system. All four of the systems we examined in Chapter 2 wereMany systems can be represented as simple system: even the solar system had only one level of decomposition, the planets and smaller bodies. In a simple system there are generally no more than seven +/– two elements of form at Level 1. When you get to these elements, they are more or less atomic parts (see the discussion below).

If there are no more than (seven +/– two)2 parts—that is, no more than about 81 entities—a system can be represented by a two-level decomposition diagram of the type shown in Figure 3.3. We call these medium-complexity systems.

A complex system has the same representational diagram as a medium-complexity system (Figure 3.3), but at the second level (down) there are still only abstractions of things below. These are significantly harder to analyze, and more common. For example, if Natasha were ­really just the leader of another organization that is responsible for developing concepts, this would be a complex system.

One rarely sees a single decomposition diagram more than two levels deep. There are two ­reasons why such drawings are not used. First, a three-level diagram could have as many as (seven +/– two)3 elements at the third level, or as many as 729, which is far more than humans can routinely process. Second, when we look down into an organization or system, we find that we know the Level 1 elements well (the “direct reports” in the organization), and we more or less comprehend things on the next level (the direct reports of your direct reports), but beyond that it is more or less a haze.

We will simply refer to Level 0, Level 1 (down), and Level 2 (down) when discussing the decomposition of systems. As we learned in Chapter 2, virtually everything is a system, so the designation of Level 0 as “the system” is somewhat arbitrary and depends on the viewpoint of the architect. There are dozens of words to designate the layers below “the system”; they may be referred to as modules, assemblies, sub-assemblies, functions, racks, online replacement units (ORUs), routines, committees, task forces, units, components, sub-components, parts, segments, sections, chapters, and so on. Unfortunately, there is little consensus about how these terms are applied. One person’s assembly is another person’s component. There are relatively fewer words for the levels above “the system”; people speak of systems of systems, complexes, and collections. If needed, we will call these Level 1 (up) and Level 2 (up).

Our discussion hinges somewhat on how we define the term “atomic part,” which does not have an exact definition. Its meaning derives from the Greek word ἄτομος (atomos), which means indivisible. In mechanical systems, we will stipulate that the atomic parts are those that cannot easily be “taken apart.” A person, a screw, and a processor chip all pass this test. Of course, a processor chip has many internal details that might be architecturally important. How many of what type of transistor or gate are included? How are they connected? Even a simple screw has architecturally important details. Is it a straight head or Phillips head? Yes, this definition is a bit fuzzy, but here is a simple rule: “Call it a part when you can’t take it apart.”

In information systems, the definition of the term “atomic part” is even fuzzier. A useful test is to call something an atomic part when it possesses a semantic meaning (as does a word or an instruction) or when it is a unit of data or information. These words, instructions, or data units would include details, of course. Because all information is an abstraction (as we will discuss in Chapter 4), defining meaningful abstractions of abstractions is necessarily more fuzzy, but here is another simple rule: “Call it a part if it loses meaning when you take it apart.”