The complete Level 1 architecture that would be developed from Figure 8.2 would have at least 18 internal processes (counting the 9 value-related processes and at least 9 more supporting processes), plus the associated form, plus interfaces with some accompanying systems. This is already a great deal of complexity.

Why develop more detail at Level 2 in this OPM representation? We want to make sure that Level 1 is reasonably accurate, and we want to make sure the boundaries of internal modules (and internal interfaces) are reasonably placed. These internal boundaries drive the next step: actually distributing the responsibility for design to other groups (internal and suppliers). If the architecture is not well decomposed at Level 1, this distributed effort and subsequent integration will suffer.

The principal question is therefore “Is this the right decomposition at Level 1, or at least a good one?” In Chapter 13, we will discuss the choice of decomposition in detail. The fact is that the real information about how the entities at Level 1 should be clustered or modularized is hidden at Level 2. We need to dive down one more level to see how the details really work, and then make decisions on how Level 1 is best structured.

We therefore employ the hierarchic decomposition (Chapter 3) to develop the Level 2 ­architecture, which is summarized in Question 8a of Table 8.1: “How does the architecture of Level 1 extend to Level 2?”

We will recursively apply the procedure from Table 8.1 to the task of expanding from Level 1 to Level 2, as suggested by Figure 8.3. The central procedure we employ is that each function at Level 1 becomes a statement of functional intent at Level 2, allowing us to recursively employ the analysis structure already developed. We are recursively applying what we called function–goal reasoning above.

For example, if “purchasing tickets” is the process we focus on in the Level 1 view of the air transport service (Figure 8.2), “purchasing tickets” becomes the functional intent at Level 2, and we have to make a choice at Level 2 among many specialized processes to accomplish the intent of purchasing (such as purchasing online) and then to zoom the purchasing process, as will be discussed below.

The intent at Level 2 retains by inheritance the overall intent for the system at Levels 0 and 1. Additionally, we often want to capture intent from operations. For example, how is the ticket purchasing sequenced in the air transport service? Did our operational concept create any intent as to how late the ticket can be purchased before the scheduled departure?

Given an understanding of the intent at Level 2, we can now derive the architecture at Level 2. We will recursively follow the questions of Table 8.1. Starting with Question 5b we identify the expanded operands, attributes, and processes.

We illustrate the development of Level 2 architecture by focusing on the ticket purchase ­process. The Level 1 function (“purchasing tickets”) has now become the Level 2 intent. As shown in Figure 8.4, this has been specialized to an online system, primarily supported by the reservation system. Five internal processes have been identified, as well as three new internal operands (ticket exists as a Level 1 operand). The reservation system has decomposed to three instruments within the system, and three more accompanying instruments are identified outside of the product/system boundary.

If this zooming is applied to each of the 9 value delivery pathway processes of Figure 8.2, then we can produce the 28 internal processes at Level 2 as shown in Table 8.2. Note that 3 of the processes of Figure 8.2 (entertaining, nourishing, and crediting) have been “demoted” to Level 2 process. Such judgments are often made in architecting. Table 8.2 also indicates the 16 states of the 4 major operands. All operands are somehow affected by the internal processes, and some also act as instruments.

Table 8.3 maps the 28 internal processes onto the 22 instruments of form. These relationships appear to be approaching more of a one-to-one correspondence. The notable exceptions are the agents and flight attendants, who, as humans, are adaptable to many roles.

Together, Table 8.2 and Table 8.3 express the architecture at Level 2. The tables do not yet include the supporting systems, interfaces, or external accompanying systems present in the whole product/system.

The procedure to examine architecture at the next level could be recursively applied to derive Level 3. But do we need to do this? Consider the desired outcome. Examining Level 2 has two objectives: to confirm that the higher-level abstractions at Level 1 are reasonable, and to investigate the appropriate ways to cluster or modularize Level 1, as we discuss in Section 8.6.

Consider the complexity. A typical Level 1 model will have about 7 +/– 2 primary value ­processes, as well as non-idealities and supporting processes, and about as many entities of form, for about 20–30 entities in all. A full model at Level 2 might have 50–100 entities, and at Level 3 there would be hundreds. Three levels of hierarchy are hard to develop and too much to comprehend easily. We don’t need to go to Level 3.

In summary, the goal is to produce a model at Level 1 that is robust and well modularized, so that the architecture can be broken up and distributed to others to develop further. As suggested by Figure 8.3, the Level 2 model can be created by recursively applying the procedures to develop the architecture (Table 8.1), focusing successively on all of the internal processes in the initial Level 1 model. The key step is applying function–goal reasoning: We start the analysis of Level 2 by treating each internal function at Level 1 as a goal at Level 2.