5.2 Function in Architecture
Function
Function is what a system does. Function is about activity, in contrast with form, which is about existence. As indicated by Box 5.1, function involves operations, transformations, or actions. Performance (how well a system performs) is an attribute of function.
Just as form has entities of form (objects) and formal relationships among the entities (structure), function has entities of function and functional relationships among the entities (interactions). The function we see on the surface of a system is a result of the emergence that has taken place among these entities of function within the system, and in the whole product system.
Function is vitally important to systems and system architecture. All of the magic of systems and their emergence, and nearly all of the challenge of designing them, is found in the functional domain. Function is therefore a system attribute.
All systems have function, but in built systems, function must be conceived so that the goals of the system are achieved. Because function is less tangible than form, it is expressed in many different ways. In organizations, function is sometimes called tasks, roles, or responsibilities. In the Constitution of the United States, it is called powers. The Constitution lists the functions of the legislature, executive, and judiciary.
Function as Process Plus Operand
In Chapter 2, we found that a function is made up of a process and an operand, leading to the rule function = process + operand. For the house and emergency briefing card examples, we have function = housing + resident and function = instructing + passenger. In order to better understand function, we first need to better understand operands and processes.
Operands
Operands are a type of object (Box 4.2). Some objects in a system are elements of form, and some are operands. In human language, all objects are usually named by nouns.
All objects, including operand objects and objects of form, have the potential for stable unconditional existence for some period of time. However, form is a type of object that must exist before the function, is instrumental in the function, and is designed by the architect and supplied with the system.
On the other hand, an operand is the part of function that represents what is changed by the function—the resident is housed or the passenger is instructed. The more formal definition of the term “operand” is given in Box 5.2. We see that operands are acted upon by the process part of the function. Operands may exist before the function is executed, or they may appear as the function is executed. In general, they will be created, transformed, or consumed by the process.
Interestingly, the operands are not usually supplied by the architect or builder of the system. Instead, they appear at the time of operation, usually from other sources. The resident is not supplied with the house, nor is the passenger supplied with the instruction card. Often, as architects, we do not have much control over the operand. The residents may have unique tastes in buildings, and the passenger may not speak any of the languages used on the instruction card. The operand is almost never shown on a conventional representation of a system.
Processes
In human language, processes are associated with verbs, which are the aspect of our human language that captures actions or transformations. A process is defined in OPM as a pattern of transformation applied to one or more objects (Box 5.3). Processes generally involve the creation or destruction of an operand or a change in an operand. In our examples, we identify housing of the resident, where housing is a process. This process changes a resident from “un-housed” to “housed.” For the aircraft emergency instruction card, the process is the instructing of the passenger. Instructing changes the knowledge of the passenger.
In contrast with objects, a process is transient and dynamic and takes place along a timeline. You cannot take a photograph of process; you need to take a video. No single frame of the video reveals process; it is only when the entire sequence of frames is viewed that process can be comprehended. Imagine a video of a sprinter crossing a finish line. If we look at one frame alone, or at the international symbol for running (Figure 5.1), we can only infer dynamics. Cartoonists have developed a series of tricks to hint at motion within a single frame. Is the person on the left taking the hubcap off or putting it on?
Figure 5.1 Examples of the difficulty of expressing process, which is inherently dynamic, with a static image: Illustration showing hubcap removal, a symbol for running, and a cartoon for running.
(Source: (b) Miguel Angel Salinas Salinas/Shutterstock (c) Screwy/Shutterstock.)
Analytical Representation of Function
In order to proceed further with the analysis of function, we need to develop an explicit analytical representation of process and operands. In the imprecise style of the figures of Chapter 2, we simply drew a round-cornered rectangle and wrote the statement of form, the process, and the operand inside.
OPM has a set of symbols used to represent objects and processes and their interactions (see Figure 5.2). The process is shown by the oval, with a label indicating the name of the process. The operand is shown as a rectangle, because it is an object, with the name of the operand written inside. The function is made up of these two OPM elements, the process and the operand, but does not have a separate OPM symbol.
Figure 5.2 OPM diagram of process + operand yielding function. From top to bottom, these represent the process affecting the operand, consuming the operand, and producing the operand.
In OPM, there are three ways of representing the relationships between an operand and a process, as shown in Figure 5.2. A single-headed arrow running from the process to the operand implies that the process creates the operand, as a factory would create a car, or as a team(let’s call it Team X) develops a design. The car or design did not exist before the process, and after the process, it did.
A single-headed arrow running from the operand to the process implies that the process consumes the operand, as when a factory consumes parts (to make a car), or the lungs consume oxygen from the air in the lungs (in order to transport it to the tissue and organs). Consumption is relatively rare. It implies that the abstraction of the operand no longer exists in the original nature and place after the process executes. Note that in the car factory example, the parts still exist after they leave the factory, but they have become part of another abstraction, called the car.
A double-headed arrow implies that the process affects the operand but does not consume or produce it. The residents were people both before and after moving into the house. The only difference was that their attribute of being housed was changed. The existence of the operand did not change: rather, some attribute of the operand was changed by the process.
OPM reserves the round-headed arrow as the symbol that links the instrument object with the process that it enables. The process then connects, with the appropriate pointed arrow (create, destroy, or affect), to the operand.
We are now in a position to analytically diagram form and function, as illustrated in the canonical model of a system shown in Figure 5.3.
Figure 5.3 OPM representation of the canonical system architecture: The function as a process and an operand that the process affects, and the form as an instrument object.
A more explicit representation of the canonical system is illustrated in Figure 5.4, in which the states of the operand are explicitly shown. This view emphasizes that the operand changes its state through the action of the process enabled by the instrument objects.
Figure 5.4 More explicit OPM representation of the canonical system architecture, showing the value-related states that are changed by the process.
This representation that emphasizes the states of the operand is closer to the way in which SysML expresses function using the state machine diagram. SysML state machine diagrams are made of states (rounded boxes), transitions (arrows), and events/signals (rectangles with an inward or outward triangle). Transitions triggered by events or signals capture the conditions under which the system goes from one state to another.
An example of a typical SysML state machine diagram (from a robot controller) is given in Figure 5.5. Recall that one of the differences between SysML and OPM is that SysML separates description of form and structure from description of function and behavior. Thus the SysML state machine diagram contains only functional information and does not show any relevant objects; note that neither the instruction card nor the air traveler appears on the state machine diagram of Figure 5.6.
Figure 5.5 Example of SysML state machine diagram for a robot.
Figure 5.6 Simple SysML state machine diagram for the instruction card. Note the absence of objects on the diagram (no instruction card, no traveler).
In summary:
Function is the activity, operation, or transformation that causes or contributes to performance.
Function is composed of process and operand. Process is the pure transformation, while the operand is an object acted upon by the process. Processes are generally creation, transformation, and destruction.
The canonical model of a system consists of the operand, the process designed to change it in such a way as to create value, and the instrument object that enables the process.