Another way to analyze and understand systems is by taking increasingly broader or more holistic views of the system and its context. This is an application of the Principle of Holism (see Box 2.5). We will see that it is useful to take two increasingly holistic views of a system, which we will call the whole product system and the use context.

Expanding outward from the product/system, the first level of context we encounter includes the other objects that are not part of the product/system but are essential for the system to deliver value. We call these the accompanying systems. The sum of the product/system and the accompanying systems is called the whole product system. The product/system is separated from the accompanying systems by the system boundary (Section 2.4).

What are the accompanying systems and therefore the whole product/system (Question 4d of Table 4.1)? It is vital for the architect to understand and model the accompanying systems, because they may play an important role in emergence. They must be present, connected, and working for the product/system to deliver value. There must be well-defined interfaces to these systems at the system boundary, whose existence is described by the answer to Question 4e.

The procedure for addressing Questions 4d and 4e of Table 4.1 is to look holistically at the objects of form that are near the system or are connected to it and ask, “Are these essential to the delivery of product/system value?” If so, then the abstractions of form are created for the elements of the accompanying systems, and the formal structure between the system and the accompanying systems is identified.

Applying this procedure to the pump in Figure 4.5, we can reason that at a minimum, there must be elements that transport fluid to and away from the pump: the inflow and outflow hoses. The entire assembly must be structurally supported by a pump support, and the motor must be powered and controlled. The pump whole product system, including these four accompanying systems, is shown in Figure 4.17. Most often there is an operator involved in delivering value, and it is good practice to include the operator in diagrams such as Figure 4.17 to remind the architect of the importance of considering human interactions with the system.

The dashed line is the boundary that surrounds the product/system. It is good practice to draw the product/system boundary clearly, to reduce ambiguity and explicitly identify interfaces.

No structural information is shown in the decomposition view of Figure 4.17. This is best presented in diagrams like the connectivity structure in Figure 4.18. Now one can clearly see the connection between the principal objects of form of the pump and the accompanying systems, and the interfaces at the system boundary.

Expanding one more step outward, we find the next level of context, the use context. The whole product system fits within this use context, which includes the other objects that are normally present when the whole product system operates but are not necessary for it to deliver value.

The use context is important because it informs the function of the product/system. It gives place to the whole product system, and it gives us information on the environment in which the system operates and informs design. In analysis, the architect may have to speculate on the use context, because it is rarely documented in system descriptions. The procedure for answering Question 4f of Table 4.1 is to ask, “What elements of context that are not already in the whole product system form our understanding of use and design?”

Applying this idea to the centrifugal pump, we will have to speculate, because the drawings we have available do not contain any hint about use context. We can guess that the pump might be an industrial sump pump for salt water removal or part of a home dishwasher. The system might have different requirements based on these use contexts.

The need for a clear understanding of the whole product system, informed by the use context, is driven by the accountability and responsibility of the architect. Even though the architect is responsible only for the product/system, it is inevitable that the architect will be held accountable for the function of the whole product system. If it does not work, the architect will likely be accountable regardless. Just as it is important for an architect to understand about two levels down in decomposition, it is important for him or her to understand about two levels out in ­context—the whole product system and the use context.

Imagine that the inflow hose for our pump is supplied by a third party. If the hose does not connect well to the expensive new pump, it is much more likely that the pump supplier will be held accountable for the bad interface than the hose supplier.

In summary:

• The whole product system consists of the product/system and the accompanying ­systems that are necessary to deliver value (Question 4d of Table 4.1).

• The system boundary runs between the system and the accompanying systems, and each crossing of the boundary indicates an interface that should be controlled (Question 4e of Table 4.1).

• The use context includes the objects that are normally present when the whole product ­system operates but are not essential for the delivery of value (Question 4f of Table 4.1). Use context establishes place, informs function, and influences design.