Our first task in expanding from concept to architecture is to identify the value pathway that delivers the primary value. This is done by starting with the key internal functions identified in the integrated concepts (Question 5b) and linking them together from inputs or start points to outputs or end points.

The solution-neutral function of the air transportation service (transporting a traveler) and concept (flying a traveler with an airplane) have been identified. The left two columns of Figure 8.1 show the primary value delivery pathway, created by linking the key internal functions from Chapter 7. This figure identifies the primary operand as the traveler and leaves the checked baggage as a secondary value operand to be discussed below. Interestingly, all of the processes act on the traveler except the purchasing of the ticket. The state of the traveler progresses from checked-in in the departure city to checked-out in the arrival city. The only other operand is the ticket, which is essentially the information object that encodes itinerary, traveler status, reservation, and fees. This functional architecture represents a simple “no frills” airline that just gets the traveler from A to B. This figure responds to Question 5c.

In contrast to this fairly simple functional architecture, Figure 8.2 adds secondary value ­delivery: transportation of checked baggage, the provision of entertainment and food on board, and the involvement of a frequent-traveler incentive program. This answers Question 5d and makes the architecture noticeably more complex. For example, many of the operations for the traveler must now be replicated for the baggage.

As introduced in Chapter 3, zigzagging is the idea that we reason in one domain as long as is practical and then switch to the other. For example, we can only decompose the function transporting so far before it becomes necessary to specify something about the form part of the concept, in order to understand what further functions are required.

We have gone about as far as we can go in the functional domain, so it is time to “zig” into the form domain and begin to address Questions 4a through 4f.

Question 4a asks us to define the abstraction of the form that constitutes the system. The answers within the dashed line in Figure 8.2 are the employees and equipment of the airline, as well as the leased entities of the airport that are directly associated with processing passengers and baggage (such as baggage conveyers and ticket desks). Excluded from the form of the system are the non-airline services of an airport (such as arriving by car and parking) and the air traffic control, navigation, and security services provided by the government.

The form at Level 1 decomposition is depicted in Figure 8.2 (which shows only the instruments of the value delivery processes). The structure of form (where it is located and how the form is connected) is not shown. We have answered part of Question 4b and deferred answering Question 4c.

Next we can “zag” back to the functional domain and examine the system architecture that results from mapping the function to form. At Level 1, this is shown by the links between form and process in Figure 8.2. The reservation system, which contains the itinerary, seat assignment, and travel program status, is an instrument of virtually all of the processes. The check-in system and gate system get the traveler checked in and on board. The flight crew are only responsible for transporting. These observations answer Question 6a.

If this architecture begins to look complicated, consider for a moment the non-idealities of a more realistic transportation service (Question 6b). The traveler transiting the airport and waiting at gates has not been included in the model. We have also not considered making a connection in a hub airport on the way from the departure area to the arrival area, or traveling internationally, with passport control.

The supporting functions (Question 6c) are enumerated in Figure 8.2 but are not shown as connected to the value-related instruments. This is because a deeper understanding of the mapping needs to be made at Level 2, and because the mapping would be very dense. For example, nearly all supporting instruments involve personnel who need to be trained and supported by human resource (HR) processes.

The sequence of operations (Question 6e) can be inferred from the way Figure 8.2 is drawn: Processes are vertically listed in the order in which they occur. The passenger purchases a ticket, checks in, is loaded onto the aircraft, and so on. There is a strong suggestion that there are ­parallel threads or strings of operations (Question 6f). For example, along with the operations on the passenger, there is almost an entire parallel path for processing the checked baggage, which separates from the passenger at check-in and is (we hope) reunited with the passenger at check-out. Also, the passenger is fed and entertained while being transported. We know from experience that clock time is important (Question 6g)—there are actual schedules that aircraft keep—but this information is not shown in Figure 8.2 and would be captured in additional diagrams.

In summary, the tasks of developing the Level 1 architecture are presented in Table 8.1. The starting point is the Level 0 information: the solution-neutral function (O_sn and P_sn), the solution-specific concept (O₀, P₀, and F₀), and the concept of operations (OPS₀), as shown in Figure 8.3.

In order to develop the Level 1 architecture, the specific function at Level 0 (the functional part of the concept) becomes the functional intent at Level 1. This is a key point: The solution at one level becomes the problem statement at the next level. We call this function–goal reasoning. The intent at Level 1 also inherits other aspects of the Level 0 intent.

This Level 1 functional intent is next specialized and zoomed to form the functional architecture at Level 1: the operands (including the external operand O₀) and the internal processes at Level 1 (P₁₁ and P₁₂). The Level 0 form is next decomposed to define the Level 1 entities of form and mapped to the Level 1 internal function. This is also informed by the Ops Concept (OPS₀) at Level 0. Finally, the remaining detail of the architecture at Level 1 is filled in: non-idealities in function, supporting processes and form, interfaces, and so on.