We have now decomposed both examples to Level 2, but we have not yet asked whether we chose the correct decompositions at Level 1. We expanded the Level 1 representation in order to examine the relationships among the entities at Level 2. These relationships should inform the ­modularization or clustering at Level 1. This process is captured by Question 8b “What is a possible modularization of the Level 2 objects?”

In the air transportation service example, we initially presented the Level 1 processes ­according to the major events that happen along the timeline of air travel: ticketing, checking in, loading, transporting, unloading, checking out. How do we know this is a good way to decompose an air transportation service?

Our objective is to cluster entities of the architecture that are tightly interconnected. [1] This enables us to minimize interactions across modules and maximize internal coherence within modules. In order to examine how the Level 2 entities cluster, we first need to decide how we will cluster (Box 8.1). In this example, we use a process-centric clustering, with relationships based on operand interactions. Our assumption is that if two processes share a large number of operands, they are tightly coupled. The nature of the interaction is suppressed, and the only information left is the number of interactions. For example, it is easy to see in Table 8.4 that the “arriving at airport” process interacts with four different operands and that three of these operands are shared with “embarking.”

We then cluster the processes using the Thebeau algorithm. [3] Table 8.4 shows the PP_operand matrix for the air transportation service architecture, grouping Level 2 processes into clusters.

Now, rather than processes being organized according to the original “function timeline,” the architecture is grouped more functionally. The first cluster, which might be called the Level 1 reservation process, deals with the creation and amendment of the reservation. The second cluster, closely related to the first, includes processes that affect the ticket.

The next three clusters contain processes that control the path of the passenger, of checked bags and of carry-on bags, respectively. All three of these groups follow a similar pattern of checking in, moving, and checking out, as they move from the departure location to the arrival location. Finally, the sixth cluster contains the secondary value processes that are aimed at the passenger’s travel experience.

This clustering is not perfect—there are interactions among the blocks—but this will be the result for any clustering. By performing this clustering analysis, we are not saying that this Level 1 modularization (according to shared operands) is better than the first attempt in Figure 8.2, which was based on a progression of time. The two different decompositions simply represent two ways in which the airline service provider might be organized. If running time were important, you might focus on the time-based organization. If you were thinking of end-to-end system reliability, the second might be more appropriate.

In summary:

• In order to modularize the system well at Level 1, it is necessary to expand to Level 2, examine the relationships based on processes or form, and then cluster to create a new Level 1 decomposition.

• Clustering algorithms can arrange the entities into an order that maximizes the local interaction and minimizes the interactions between blocks. The resulting clustering might be better than the original one, and it better informs the architect about how to decompose the system, define internal interfaces, and then distribute the task of more detailed design.