We now turn our attention to Question 5a in Table 5.1: “What is the primary externally delivered value-related function?” We can parse this statement into two parts. First, the function must be ­externally delivered; it must cross the boundary of the system and influence something in the context. Second, there is a primary function—the function for which the system was built. The primary externally delivered functions for several example systems are given in Table 5.2.

There are systems that apparently are built only for their form. These are often associated with aesthetics, accomplishment, or collecting—art, trophies, and coins, for example. These elements of form actually have a function: pleasing + the viewer, impressing + others, and satisfying + a need to collect, respectively. If you were not pleased by art, you would not buy it or travel to see it. The function of these kinds of specialized forms is tied to the human reaction to the forms. The form, however, still delivers functions.

Function delivers value when it acts externally to the system. It is important that the function is externally delivered, that it is not only internal to the system. This implies an important rule of systems: Function and value are always delivered at an interface in the system boundary. For example, referring to some of the examples listed in Table 5.2, value is created only when the amplified signals are delivered at the output; only when the team delivers a design; and only when the oxygen is delivered to an organ or tissue.

Built systems have a primary externally delivered function. This is the function for which the system is built, or at least originally was built. If the built system does not deliver this function, it will be a failure. Operational amplifiers are built to amplify; they may also filter high frequencies, but if they do not amplify, they are a failure. Team X is created to deliver a design: if it does not do so, it is a failure.

The reason we focus on primary function is that in modern practice, engineers have an enormous list of requirements and potential features to deliver. Many products are delivered that fail to provide the primary function, providing instead a host of secondary features. Witness the challenges encountered by Apple when the iPhone case interfered with the radio antenna, disabling the primary function. The architect should try to reason about the primary function, before being distracted by other features.

The test to identify the primary value-related function is therefore:

• What is the function that the system was originally built to deliver, before all of the other value-related functions were added? Or,

• Which function, if it failed to materialize, would cause the operator to discard or replace the system?

We will call all the other externally delivered functions secondary functions and will discuss them in Section 5.6.

Systems deliver value when they execute their primary externally delivered function. As indicated in Box 5.4, value is defined as benefit, worth, importance, or utility for some associated cost. Good value can therefore be created by high benefit at modest cost, or by modest benefit at low cost. Note that others sometimes define the term “value” as a synonym of “benefit,” but we will consistently equate value to benefit at cost. A similar definition is found in Lean Enterprise Value [1]: “Value is how various stakeholders find particular worth, utility, benefit, or reward in exchange for their respective contributions to the enterprise.”

If the system is working properly, value will be delivered when the function emerges (Box 5.5), but this is far from certain. Value is subjective and is judged by an observer who is not the ­architect but, rather, is the customer, beneficiary, or user. (The procedure for trying to ensure that systems are designed so that they actually deliver value is the subject of Chapter 11.)

It is critical to identify the value-related operand from among all of the operands on which the system acts. You can identify the value-related operand by asking, “What operand does the system exist to influence: to create, destroy, or affect?” For example, the operational amplifier clearly exists to create the high-amplitude output signal.

We should also consider the attribute of the operand whose change is associated with value, in this case the amplitude (Table 5.2). The system delivers value when the process “amplifying” acts on the operand “signal” in such a way as to change its value-related attribute “amplitude” to the state of “high.” Figure 5.7 shows several ways in which this external function delivery can be diagrammed in OPM.

For Team X, the final design is the value-related operand. The team will undoubtedly produce other outputs: discarded options, analysis, time cards, and the like. But the reason why Team X exists is to produce the final design. When the boss asks, “Is the design complete yet?” it is an indication of the value-related function.

We can now finish answering Question 5a of Table 5.1. Focus on the primary externally ­ delivered function and ask:

• What is the most specific way to describe the operand on which the system acts on the way to delivering value?

• What is the attribute of this operand whose change is associated with the delivery of value, and what is the final state associated with value?

• What is the specific process executed by the system to change the value-related state of this specific operand?

For our pump example, the answers to these questions are as follows: The operand is water, the value-related attribute is pressure (which should be high), and the process is pressurizing. How do we know that the value-related operand is the high-pressure water? The pump can be thought of as consuming low-pressure water and discharging high-pressure water, as shown in Figure 5.8.

We don’t build pumps to consume low-pressure water, but we do build them to produce high-pressure water. Therefore, the high-pressure water is the value-related operand. An alternative representation in OPM is illustrated in Figure 5.9, which shows water as the operand, and the process changing the state associated with the attribute of pressure.

In bubblesort, the sorted array is the value-related operand. Sorted-ness is the attribute, and sorted is the state associated with value. The sorting process can be thought of as consuming the unsorted array and producing the value-related operand: the sorted array. Or the process can be thought of as changing the attribute of sorted-ness for the array from unsorted to sorted.

Often, there are operand objects present that are not directly related to the delivery of value, which we will simply call other operands. For example, in bubblesort, the array length variable that is passed to the procedure is an operand, but it is not the value-related operand. It is simply another operand used in sorting. Low-pressure water and electrical power are other operands of the pump.

Before we leave this section, we will introduce one more simple system, a kitchen that makes sliced bread. The last line of Table 5.2 summarizes the system: The externally delivered value-related operand is sliced bread. Thus bread is the operand, sliced is the value-related state, and making is the process.

In summary:

• The primary externally delivered function of a system emerges when the process acts across a boundary of the system at an interface.

• The benefit of a system is linked to the externally delivered function.

• Benefit materializes as a consequence of a process acting on the value-related ­operand. Analyze the operand, the value-related attribute and its change in state, and the process.