From Concept to Architecture

Systems Architecture · Chapter 8

Aykut C. Satici

Developing Architecture from Concept

Concept is a notional mapping between form and function: architecture is a comprehensive, detailed one
Architecture requires much more detail than concept. A pump or bubblesort concept fits in one line, while its architecture includes the relationships examined in Chapter 6
This chapter shows the process: concept → Level 1 architecture → Level 2 architecture → modularization

Tip

Running example: an air transportation service. Section 8.4 repeats the process for the home data network.

Chapter 7 introduced concept as a proposed mapping of function to form. This chapter develops that mapping in detail.
Architecture = comprehensive, detailed description of relationships between internal functions and instruments of form: everything Ch.6 built the machinery for
Gap between the two isn’t incremental: orders of magnitude in information content. This chapter’s job: walk that gap
Preview the four-stage process: concept → Level 1 architecture → Level 2 architecture → modularization
Two running examples: air transportation service (carries almost the whole chapter), home data network (Section 8.4, repeats the process on a different system to show it generalizes)
Worth noting: the air-transportation example was a substantial contribution from Peter Davison of MIT

Discussion: Why does synthesis need the same questions used in analysis?

Suggested answer: They provide completeness checks for function, form, interfaces, and operation. In synthesis the answers are proposed and revised rather than inferred from a finished system.

Level 2 Architecture and Modularization

Table 8.1 compiles every question from Chapters 4–7, in the order they’re addressed during synthesis, plus two new ones this chapter answers:

8a. How does the architecture of Level 1 extend to Level 2?

8b. What is a possible modularization of the Level 2 objects?

Table 8.1 = the chapter’s organizing spine: tell students explicitly: nearly every remaining slide answers one specific numbered question from this table, in order
Compiles every question from Ch.4–7:
- 7a: beneficiaries, needs, solution-neutral operand
- 5a–5d: externally delivered function, internal functions, functional architecture, secondary functions
- 4a–4f: system, elements of form, formal structure, accompanying systems, boundaries, use context
- 6a–6g: mapping instruments to processes, non-idealities, supporting functions, interfaces, sequence, parallel threads, clock time
Nice single-slide review of the whole Ch.4–7 arc, useful as a study aid on its own
Two new questions (the callouts): 8a, how does Level 1 extend to Level 2? 8b, what’s a sensible modularization of the Level 2 objects?
Order: Section 8.3 tackles 8a, Section 8.5 tackles 8b; Section 8.2 (next) first builds Level 1 properly by working back through Ch.4–7 questions

Suggested answer: 8a: take each Level 1 function as intent for Level 2, identify its internal processes and operands, decompose enabling form, and map the two with explicit interfaces. 8b: use those Level 2 dependencies to propose coherent groups, then compare them with the trial Level 1 decomposition. In air transportation, a timeline is a useful starting arrangement, but shared personnel, information, and equipment may justify different module boundaries.

Table 8.1 · Define intent and value

Question	What the architect must determine
7a	Beneficiaries, needs, and the solution-neutral operand, state change, and process.
5a	Primary external function: specialized operand, states, process, form abstraction, and candidate concepts.
5b	Principal internal functions, their operands and processes, concept fragments, integrated concept, and operations.
5c	Functional architecture: how internal functions connect into the value pathway and deliver the external function.
5d	Secondary value functions and the internal pathways that produce them.

Condensed from Crawley, Cameron & Selva (2016), Table 8.1.

Table 8.1 · Define form and context

Question	What the architect must determine
4a	What is the system?
4b	What are its principal elements of form?
4c	What is the formal structure?
4d	Which accompanying systems form the whole product system?
4e	Where are the boundaries and interfaces?
4f	What is the use context?

Questions 4a–4f from Crawley, Cameron & Selva (2016), Table 8.1. In the airline example, Figure 8.2 leaves 4c unresolved.

Table 8.1 · Map functions to form

Question	What the architect must determine
6a	How instruments map to internal processes, and how structure supports interaction and emergence.
6b	Non-idealities and the extra operands, processes, and form needed to address them.
6c	Supporting functions and instruments for the value pathway.
6d	Boundary interfaces: exchanged operands, interface processes, and compatible instruments.

Questions 6a–6d from Crawley, Cameron & Selva (2016), Table 8.1. The example identifies security inspection but does not fully define 6d.

Table 8.1 · Describe operation and recurse

Question	What the architect must determine
6e	Sequence of the primary and secondary processes.
6f	Parallel threads of operation.
6g	Clock-time constraints and timing considerations.
8a	How Level 1 architecture extends to Level 2.
8b	A possible modularization of Level 2 objects.

Questions 6e–8b from Crawley, Cameron & Selva (2016), Table 8.1. Questions 8a–8b are new in this chapter.

8.2 Developing the Level 1 Architecture

Expanding Concept to Functional Architecture

First task: identify the value pathway: start with the key internal functions from the integrated concept (Question 5b), and link them from inputs/start points to outputs/end points
Concept: flying a traveler with an airplane. Primary operand: the traveler. Secondary operand: checked baggage
Every process acts on the traveler except purchasing the ticket; the only other operand is the ticket itself: an information object encoding itinerary, status, reservation, and fees

Chapter’s first concrete step: picking up exactly where Ch.7 left off: solution-neutral function = transporting a traveler; concept = flying via airplane
Task now: expand into functional architecture: first move is identifying the value pathway: chain of key internal functions (Question 5b) linked from inputs to outputs
Air travel example (clean, minimal): primary operand = the traveler (state changes all the way through); secondary operand = checked baggage (set aside for now)
Elegant observation: every process acts on the traveler except purchasing the ticket, which acts on the ticket: an information object encoding itinerary, status, reservation, fees
Have students predict the diagram before the next slide: traveler progressing step by step (checked-in →… → checked-out), one small side-branch for the ticket

Discussion: Sketch the passenger pathway before adding secondary services.

Suggested answer: Trace the traveler through departure handling, boarding, transportation, and arrival handling. Represent the ticket as a related information operand rather than assuming every process changes the traveler directly.

Figure 8.1 · Primary Value Delivery

A simple “no-frills” airline: purchasing → check in → loading → transporting → unloading → check out. Source: Crawley, Cameron & Selva (2016), Fig. 8.1.

Example of the previous slide’s reasoning
Left two columns = primary value delivery pathway: purchasing (on the ticket) → check-in, loading, transporting, unloading, check-out (on the traveler): traveler’s state from checked-in at departure to checked-out at arrival
This is a bare-bones, “no-frills” airline: just enough to get a traveler from A to B
Point out what’s to the right of the dashed boundary: accompanying functions (communicating, traveling, parking, navigating, flight controlling, catering) + supporting functions (IT, scheduling, airport support, planning, training, HR): enumerated but not yet wired in
Deliberate: connecting them fully needs Level 2 detail not yet developed (comes back at Question 6c). This figure answers Question 5c: functional architecture and value-pathway connections

Discussion: What could break the value pathway even if the flight itself succeeds?

Suggested answer: A failed check-in, missed connection, or inability to complete arrival handling can prevent the intended journey. Successful component processes do not guarantee successful end-to-end service.

Figure 8.2 · Adding Secondary Value

Nourishing, entertaining, and crediting (a frequent-flyer program) add secondary value: and make the architecture noticeably more complex, since much of the operational detail must now be replicated for baggage too. Source: Crawley, Cameron & Selva (2016), Fig. 8.2.

Directly extends Figure 8.1: put both side by side, ask students to spot what changed
Question 5d in action: what other secondary value-related external functions exist? Here: nourishing and entertaining the traveler, plus crediting (frequent-flyer program)
Important observation (previews complexity themes from Ch.13): adding secondary value doesn’t just add ovals: it makes the architecture noticeably more complex
Checked baggage now needs its own near-parallel path (loading, transporting, unloading), separating at check-in and reuniting at check-out: much of the single-operand detail must be duplicated for a second operand
Not visible from the one-line concept statement: only becomes apparent once you actually build the architecture. The whole reason this chapter exists as a distinct step from Ch.7

Suggested answer: Compared with the primary transportation pathway, the model adds nourishing, entertaining, and crediting the traveler, plus associated inputs, outputs, and enabling resources. Baggage also requires a coordinated path that separates from and later rejoins the passenger journey. Count more than new process symbols: ask what food, information, records, handling resources, and synchronization each addition requires. Secondary value can create substantial integration work even when the primary destination change is unchanged.

Defining the Form: Zigzagging Back

Zigzagging alternates reasoning about function and form. Having identified the internal functions, apply Questions 4a–4f to identify the form
4a. The form is the airline’s employees and equipment, plus leased airport entities directly tied to processing (ticket desks, baggage conveyors): excluding non-airline airport services (parking, arriving by car) and government-run ATC/navigation/security
4b–4c. Figure 8.2 names some Level 1 instruments, but it does not show where they are located or how they connect; the formal structure remains open
4d–4f. Accompanying systems (navigation satellites, ATC towers) are only inferred, not shown; the one explicit interface is federally supplied security inspection at check-in; use context is a single domestic leg with substantial surrounding infrastructure (roads, rental cars) left out of scope

Direct callback to Chapter 3’s zigzagging: point this out explicitly
Functional decomposition pushed as far as useful without pinning down form: time to “zig” into form, Questions 4a–4f
4a: form = airline’s own employees/equipment + leased airport entities tied to processing (ticket desks, baggage conveyors): excludes non-airline airport services (parking, arriving by car) and government-run ATC/navigation/security
Nice concrete instance of “define the boundary, separate from context” (Chapter 2, Task 2) on a real, moderately complex system
4d–4f: book is candid about gaps: accompanying systems (nav satellites, ATC towers) only inferred, not drawn; only explicit interface is federally supplied security inspection at check-in; use context deliberately narrow: single domestic leg, real surrounding infrastructure (roads, rental cars, connections, international/passport control) knowingly out of scope

Discussion: Why return to form after developing the functional pathway?

Suggested answer: Each process needs enabling resources. Mapping back to people, equipment, and information systems exposes unsupported functions and shared-resource dependencies.

Mapping Function to Form

“Zag” back to function: the reservation system is an instrument of virtually every process: the check-in and gate systems only get the traveler checked in and boarded; the flight crew is responsible only for transporting (Question 6a)
Non-idealities (6b): this model doesn’t yet handle a transiting passenger, a hub connection, or international travel with passport control
Supporting functions (6c) are enumerated in Figure 8.2 but not yet connected: nearly every value-related instrument needs personnel who must be trained and supported (HR), and mapping that fully requires Level 2 detail
Boundary interfaces (6d) remain incomplete: federal security inspection is visible, but exchanged operands and interfaces with ATC, navigation, and other providers still need definition

Zag back to function: map form onto the processes that use it (Question 6a)
Pattern revealed: reservation system (holds itinerary, seat, travel-program status) = instrument of virtually every process
Contrast: check-in/gate systems = instruments of narrower processes only; flight crew = scoped to transporting alone
This spread (“instrument of almost everything” to “of exactly one”) is itself useful info about where functional load concentrates
Non-idealities (6b): book is candid: a transiting passenger, hub connection, or international/passport-control itinerary aren’t handled by this model yet
General lesson: any Level 1 architecture is a simplification; good practice = being clear-eyed about which non-idealities were set aside
Supporting functions (6c): the “supporting” ovals in Figs 8.1/8.2 (IT, scheduling, training, HR) are enumerated but not yet wired in
Nearly every value-related instrument involves personnel who need training/HR support: mapping that fully needs detail not visible at Level 1. Exactly the gap Level 2 (next) fills

Discussion: Does every process require its own physical component?

Suggested answer: No. One component may enable several processes and one process may require several components. The allocation should make the necessary interactions and responsibilities explicit.

Sequence and Parallel Threads

Sequence (6e) is inferred directly from how Figure 8.2 is drawn: processes are listed vertically in the order they occur
Parallel threads (6f) are strongly suggested: baggage has almost an entire parallel path to the passenger, separating at check-in and (hopefully) reuniting at check-out
Clock time (6g) requires additional timing information, including flight schedules and deadlines

Continue through Ch.6 questions: timing and concurrency
Sequence (6e): inferred directly from vertical ordering in the diagram: processes listed top to bottom in experienced order; no extra notation needed
Parallel threads (6f): baggage’s near-parallel path pays off here: separates from passenger at check-in, “hopefully” reunites at check-out: strong evidence of real parallel execution, not a single sequential thread
Ask students to name other systems with this same parallel-thread structure
Clock time (6g): explicitly not captured: airlines keep real schedules, but nothing shown so far represents this; would need additional timing diagrams
No single diagram type (OPM included) shows everything: different questions call for different representations (echoes Chapter 3’s “views and projections”)

Suggested answer: An online purchase has parallel physical and informational threads: stock is picked, packed, and shipped while payment and tracking records are processed. These threads synchronize at conditions such as payment authorization before dispatch and delivery confirmation before closing the order. Similarly, passenger and baggage identities must match when their paths rejoin. A diagram’s apparent ordering is not a complete schedule: specify precedence, shared-resource constraints, durations, and synchronization conditions separately.

Figure 8.3 · Reasoning Down Through the Levels

The starting point for Level 1 is the Level 0 information: the solution-neutral function, the concept, and the concept of operations. Source: Crawley, Cameron & Selva (2016), Fig. 8.3.

Trace how the Level 0 information determines the starting point for Level 1 analysis.
Level 0: solution-neutral operand/process (O_SN, P_SN from Ch.7) specialize into the Level 0 concept: object O_0, process P_0, concept of operations OPS_0
Look at the arrows Level 0 → Level 1: the specific function at Level 0 (P_0) becomes, via “informs/decomposes,” the functional intent driving Level 1
Level 1 intent → specialized/zoomed into the Level 1 functional architecture (P_11, P_12, own operands/processes); Level 0 form separately decomposed into Level 1 form
Recursive part: exactly the same pattern repeats one level further: Level 1 functions become Level 2 functional intent, process runs again
This diagram does double duty: summarizes Level 1 just walked through, and previews Section 8.3’s entire recursive structure one level deeper

Discussion: What becomes the intent when we move down one level?

Suggested answer: The chosen higher-level function becomes the lower-level problem to solve. Decompose the relevant processes and enabling form while preserving the higher-level outcome and constraints.

Function-Goal Reasoning

The solution at one level becomes the problem statement at the next.

The Level 0 specific function (the functional half of the concept) becomes the functional intent at Level 1
That intent is specialized and zoomed into the Level 1 functional architecture, operands and internal processes, while Level 0 form is decomposed into Level 1 entities of form and mapped onto them
The rest of Level 1 detail fills in from there: non-idealities, supporting processes and form, interfaces

Explain function-goal reasoning using the relationship between adjacent levels in Figure 8.3.
State exactly: the solution at one level becomes the problem statement at the next. Have students restate it themselves
Slightly paradoxical: you’d think “solving” Level 0 means you’re done: instead that solution turns into the question one level down
The mechanics (the actual recipe): Level 0 specific function → functional intent Level 1 must satisfy → specialized/zoomed into Level 1 functional architecture (operands, processes); Level 0 form separately decomposed into Level 1 form, mapped onto those processes (the zigzag: function → form → function)
Rest of Level 1 (non-idealities, supporting processes/form, interfaces) follows using the same Ch.6 machinery
Connect back to the opening: function-goal reasoning is why concept→Level 1→Level 2 can be applied recursively: same pattern reapplies one level lower each time

Discussion: Explain function-goal reasoning using ticket purchasing.

Suggested answer: Once purchasing a ticket is selected as a service function, lower-level processes must achieve it: determine an itinerary, establish availability, authorize payment, and create a valid ticket record.

Section 8.2 Summary

Level 1 architecture begins from the value pathway: the key internal functions of the integrated concept, linked start to end
Zigzagging alternates function and form: form questions (4a–4f) and function-to-form mapping (6a–6g) round out the picture
Function-goal reasoning governs the whole process: the specific function at one level is the functional intent one level down

Review before moving to Level 2: students should be able to walk through the whole procedure unprompted:
- identify the value pathway from the concept’s key internal functions (Figs 8.1/8.2)
- zigzag into form for Questions 4a–4f (form, accompanying systems, interfaces, use context)
- zag back into function for 6a–6g (mapping form to process, non-idealities, supporting functions, sequence, parallel threads, clock time)
- all governed by function-goal reasoning: the specific function at one level becomes the functional intent one level down
Restate this last point: Section 8.3 (next) leans on it immediately, applying it recursively to go from Level 1 to Level 2

Discussion: How can we check a Level 1 architecture before adding detail?

Suggested answer: Trace the primary value pathway, supporting functions, function-to-form allocation, and interfaces. Check normal and relevant off-nominal operation against the higher-level intent.

8.3 Developing the Level 2 Architecture

Intent and Recursion at Level 2

The complete Level 1 architecture already has 18+ internal processes (9 value-related + supporting) plus their form and interfaces: already a great deal of complexity
The key question: is Level 1 the right decomposition: or at least a good one? We can’t fully judge that without seeing how the details actually work
We recursively apply Table 8.1, one more level down: each function at Level 1 becomes a statement of functional intent at Level 2: the same function–goal reasoning as Figure 8.3, one level lower

Tip

Example: “purchasing tickets” (Level 1) becomes the Level 2 intent, specialized down to purchasing online and beyond.

A complete Level 1 model already contains at least 18 internal processes, including nine value-related processes and their supporting processes, plus form and interfaces.
Motivating question: is this actually the right decomposition: or at least a good one? Honestly, we can’t judge yet
Level 2 relationships provide evidence for deciding how to group entities at Level 1. Chapter 13 returns to this issue.
Mechanism: recursively apply Table 8.1, one level deeper: each Level 1 function becomes Level 2 functional intent (same pattern as Figure 8.3, shifted down)
Worked example for the rest of the section: “purchasing tickets” (Level 1 function) becomes the Level 2 intent, specializes to purchasing online, zoomed further from there

Suggested answer: We cannot justify a Level 1 grouping merely because its labels sound sensible. Examine the Level 2 processes, shared operands, instruments, and interfaces to see which activities are tightly coupled and which can operate independently. If a shared resource crosses many proposed boundaries, revise the grouping or explicitly manage the interface. The aim is sufficient detail to evaluate the decomposition, not an exhaustive model of every lower-level component.

Figure 8.4 · Zooming to Level 2 for Ticket Purchasing

Purchasing specializes into 5 internal processes (linking, learning, reserving, purchasing, amending) and reveals 3 new internal operands and 3 new accompanying instruments: all hidden at Level 1. Source: Crawley, Cameron & Selva (2016), Fig. 8.4.

Concrete demonstration of the recursion, applied to one Level 1 process: purchasing tickets
Specialized into an online-purchasing concept, supported by a reservation system, zoomed to reveal 5 internal processes: linking, learning, reserving, purchasing, amending
What’s new: 5 processes where Level 1 showed 1; 3 new internal operands surface (travel-program status, schedule/routing/price information, and the reservation record); 3 new accompanying instruments outside the boundary (laptop, network, credit card)
None of this was visible at Level 1: “purchasing tickets” was a black box until zoomed in
This is the hidden structure the motivating question pointed at: can’t judge if “purchasing tickets” was well-scoped until you see what’s inside it

Discussion: Why does zooming into ticket purchasing expose new operands?

Suggested answer: The top-level transaction contains itinerary, availability, payment, and ticket information with distinct states. These become explicit when the internal processes are modeled.

Table 8.2 · Operands: ticketing and check-in

Rows 1–12 of Table 8.2. I = instrument, a = affect, c = create. Source: Crawley, Cameron & Selva (2016), Table 8.2.

Table 8.2 · Operands: loading and transport

Rows 13–22 of Table 8.2. The passenger, carry-on bag, checked bag, and itinerary have distinct states and pathways. Source: Crawley, Cameron & Selva (2016), Table 8.2.

Table 8.2 · Operands: unloading and check-out

Rows 23–28 complete Table 8.2: 28 Level 2 processes acting on four major operands in 16 states. Source: Crawley, Cameron & Selva (2016), Table 8.2.

Table 8.3 · Form: ticketing and check-in

Rows 1–12 of Table 8.3 map the same processes to instruments of form. I = instrument; a = affect. Source: Crawley, Cameron & Selva (2016), Table 8.3.

Table 8.3 · Form: loading and transport

Rows 13–22 of Table 8.3 include baggage equipment, flight attendants, flight crew, and aircraft. Source: Crawley, Cameron & Selva (2016), Table 8.3.

Table 8.3 · Form: unloading and check-out

Rows 23–28 complete Table 8.3. Together with Table 8.2, the 28-process × 22-instrument mapping describes the value-related Level 2 architecture. Source: Crawley, Cameron & Selva (2016), Table 8.3.

Reading Tables 8.2 and 8.3 Together

For reserving a ticket, the two tables answer different questions:

Table	What the reserving process uses or changes
8.2 · operands	Passenger and travel-program status are instruments; schedule/price information is used; a reservation is created.
8.3 · form	Schedule database, reservation engine, and computer/network perform the work; the passenger database is affected.

Tip

The process–operand and process–form views must agree: a process that creates a reservation needs information inputs and an instrument able to record it.

Worked row from Crawley, Cameron & Selva (2016), Tables 8.2–8.3.

Do We Need Level 3?

Together, Tables 8.2 and 8.3 are the Level 2 architecture: though still without supporting systems, interfaces, or external accompanying systems
Typical scale: Level 1 ≈ 20–30 entities; Level 2 ≈ 50–100; Level 3 would run into the hundreds

Level 2 detail helps assess the Level 1 abstractions and inform modularization. Develop Level 3 where unresolved questions require it, while keeping each diagram at a manageable level of detail.

Tables 8.2 and 8.3 describe the Level 2 value-related architecture. Supporting systems, interfaces, and external accompanying systems remain outside this representation.
The example limits its scope to the core value-related structure.
Scale rules of thumb: Level 1 ≈ 20–30 entities (recalls Ch.3’s 7±2 per level, compounding), Level 2 ≈ 50–100, Level 3 would run into the hundreds: echoes Ch.3’s simple/medium/complex arithmetic, roughly geometric compounding
Practical conclusion: three levels are hard to develop and too much to comprehend at once: usually don’t need Level 3. Level 2’s purpose: confirm Level 1’s abstractions, inform modularization (Section 8.5): not re-architect one level deeper than necessary

Suggested answer: Descend further when an unresolved dependency, feasibility question, or resource conflict at Level 2 can change the Level 1 architectural decision. Stop when the current abstractions have adequate behavior and interface evidence for the question at hand. Three levels are not forbidden; they are simply costly to develop and difficult to display together. Keep deeper detail in focused views rather than placing everything on one diagram.

Section 8.3 Summary

Level 2 architecture is developed by recursively applying the same procedure: each Level 1 function becomes the Level 2 functional intent
Level 2 identifies additional processes and operands, with their instruments of form
This detail helps validate the Level 1 decomposition and inform modularization (Section 8.5)

Second checkpoint of the chapter: students should explain in their own words how Level 2 gets built: recursively re-applying Table 8.1, each Level 1 function as functional intent one level down (function-goal reasoning again, as previewed in Fig 8.3)
Result on air transportation: 18 → 28 processes (22 form instruments): a dramatic increase in detail
Use Level 2 detail to assess the Level 1 decomposition and choose module boundaries.
Before that: Section 8.4 detours to repeat the process on a different system (home data network) to show the method isn’t specific to air travel

Discussion: When is further decomposition useful?

Suggested answer: When unresolved interfaces, allocation, feasibility, or risk require it. Stop at a level adequate for the architectural decision rather than decomposing simply because more detail is possible.

8.4 Home Data Network Architecture at Level 2

A Second Worked Example

Recall from Chapter 7: solution-neutral function is buying a book; the integrated concept is accessing the Internet via a DSL modem, residential gateway/switch, WiFi access point, and laptop
Figure 8.5 traces an IP packet’s Level 2 architecture, from the laptop until it leaves the house: broken into three layers: Internet, Link, and Physical (mirroring the bottom of the standard Internet protocol suite)

Tip

Layering lets designers examine one part of the network’s operation at a time. Tracing the complete data pathway then requires following the relationships across layers.

Apply the same method to the home data network to compare physical and informational systems.
Recall Ch.7 setup: solution-neutral function = “buying a book” (mundane stand-in for “using the Internet at home”); integrated concept = accessing the Internet via DSL modem, residential gateway/switch, WiFi access point, laptop
Figure 8.5 traces an IP packet’s journey at Level 2 detail, laptop → leaving the house toward the ISP: not a business-process pathway like the airline
Layering: Internet, Link, Physical: mirrors the bottom three layers of the standard Internet protocol suite (application/transport layers omitted, minor role within the home network)
Layering trade-off (fragment): lets a designer reason about one layer at a time (same “abstraction” idea as Ch.2): gives scalability, robustness, flexibility
But makes it harder to trace the data’s continuous end-to-end functional pathway: exactly the harder, “linearized” view the next two figures walk through anyway, because it’s valuable despite cutting against how networks are normally discussed

Discussion: What transfers from the air-travel example to the network example?

Suggested answer: The method: define the value pathway, identify operands and processes, map enabling form, and inspect interfaces. Domain-specific physics and protocols change, but these reasoning steps remain useful.

Figure 8.5a · Laptop to Wireless Access Point

The laptop creates an IP packet, encapsulates it into an 802.11 frame with MAC addressing (via ARP), and broadcasts it over WiFi; the WAP receives, de-encapsulates, and re-encapsulates it as an Ethernet frame toward the switch. Source: Crawley, Cameron & Selva (2016), Fig. 8.5.

First leg of the packet’s journey: walk sequentially, the process-tracing the last slide flagged as valuable
Internet layer: laptop creates an IP packet: source IP (laptop), destination IP (e.g. a server), data payload
Link layer: packet encapsulated into an 802.11 (WiFi) frame, adds MAC addressing
- MAC ≠ IP: MAC = local-area “neighborhood” location, no internet-wide routing
- Source MAC = static property of the NIC; destination MAC = looked up via ARP table (maps destination IP → destination MAC on the local network)
Physical layer: laptop’s antenna modulates bits onto a 2.4-GHz signal, broadcasts
WAP receives, de-encapsulates back to IP packet, reads destination, determines it must go through the residential gateway, re-encapsulates as a new Ethernet frame addressed to the gateway: next leg on the following slide

Discussion: What must be compatible between a laptop and an access point?

Suggested answer: Their communication interfaces and operating assumptions must allow data exchange. Naming two connected devices is insufficient without compatible signaling, protocols, and access arrangements.

Figure 8.5b · Switch to the ISP

The switch error-checks, reads the destination, and forwards the frame to the gateway, which de-encapsulates it, performs NAT (network address translation) to swap the private IP for a public one, and re-encapsulates it as PPPoE: modulated by the DSL modem onto the phone line toward the ISP. Source: Crawley, Cameron & Selva (2016), Fig. 8.5.

Second and final leg inside the house
Ethernet frame → Physical layer → bits over copper cable to the switch
Switch buffers, reads destination MAC to forward, error-checks the transfer, writes back out toward the gateway
Gateway: de-encapsulates to the IP packet, performs NAT (network address translation): swaps laptop’s private IP for the gateway’s public IP
NAT’s two benefits: conserves scarce public IP addresses, and adds security (devices never directly broadcast their address to the Internet)
Re-encapsulated into a PPPoE frame (residential gateway ↔︎ ISP protocol), modulated by the DSL modem onto the phone line → telephone exchange → ISP
Complete journey across three layers and two figures: a concrete demonstration of Level 2 detail on a system entirely different from air transportation

Discussion: Why is the ISP boundary architecturally important?

Suggested answer: It separates responsibilities and technologies while carrying the end-to-end data flow. The architecture must specify what crosses that boundary and what service each side provides.

Section 8.4 Summary

The home network expands to Level 2 the same way: 24 internal processes, following the same recursive function–goal reasoning
Instruments include both physical devices (laptop, switch, antenna) and informational objects (software, data tables like the ARP table)
The Level 2 model, and specifically its layered structure, lets us judge whether the Level 1 model was robust and well-modularized

Close the home-network detour, tie back to the main thread: same expansion process, home network’s Level 2 = 24 internal processes, in a single OPM diagram (Fig 8.5, two parts), same recursive function-goal reasoning as air transportation
Instruments of form here are mixed: physical devices (laptop, switch, antennas) and informational objects (software processes, ARP table)
Reinforces: “form” was never restricted to physical hardware: informational entities are just as legitimately form
Closing point (ties to Section 8.3’s “why Level 2” discussion): this Level 2 model, its layered structure especially, is what lets us judge whether Level 1 was robust and sensibly modularized
Bridge into Section 8.5: with two worked Level 2 examples now in hand, the chapter turns to using Level 2 detail to modularize Level 1

Suggested answer: For the home network, test whether each proposed layer or module has a coherent responsibility, explicit interfaces, and dependencies that match the actual lower-level functions. Physical devices and informational objects can both enable processes. If one presumed module depends on many hidden details of another, the Level 1 abstraction needs revision or stronger interface contracts. A layered drawing is evidence of an organizing idea, not by itself proof of robust modularization.

8.5 Modularizing the System at Level 1

Why Modularize?

We initially organized Level 1 by the timeline of air travel: ticketing, checking in, loading, transporting, unloading, checking out. Is that actually a good decomposition?
Objective: cluster entities that are tightly interconnected: this minimizes interactions across modules and maximizes coherence within them
First choice: cluster by process (via shared operands) or by form (via structure): Box 8.1 covers both

Return to the motivating question from the start of Section 8.3: now finally answerable
Original Level 1 decomposition organized by the timeline (ticketing, checking in, loading, transporting, unloading, checking out): natural, but is it actually good (in the rigorous sense from Ch.3’s decomposition/hierarchy discussion)?
Level 2 detail finally lets us ask this properly
Clustering objective: cluster tightly interconnected entities, minimizing cross-module interactions, maximizing within-module coherence: echoes Ch.3’s modular-vs-integral spectrum
First choice point (Box 8.1, next): cluster by process (shared operands) or by form (structural/spatial relationships)
Rest of this section works the process-based route on air transportation; form-based route is an equally legitimate alternative, not covered in full

Suggested answer: A timeline makes the customer’s journey easy to explain, but consecutive activities do not necessarily belong in the same module. Level 2 analysis may reveal shared agents, records, or equipment that couple nonadjacent activities. Compare process clustering through shared operands with form clustering through structural relationships; assess the resulting interfaces, ownership, and performance. Minimize costly cross-module dependencies while preserving necessary interactions, rather than simply minimizing every connection.

Box 8.1 · Clustering by Interactions

Three tasks: choose the basis for clustering (processes or form), represent that information (as a DSM), and compute the clusters. Replacing the interaction type (create/affect/instrument) with a simple count of connections lets a clustering algorithm rearrange rows and columns into tightly coupled blocks.

Tip

Here, clustering is based on processes, linked through shared operands: two processes that touch many of the same operands are assumed to be tightly coupled.

Unpack the three-step procedure the rest of Section 8.5 executes:
1. choose the clustering basis: process or form
2. represent it as a DSM (design structure matrix / N-squared table, from Ch.2: same tool as the amplifier circuit’s relationship tables)
3. compute the clusters via a systematic algorithm, not eyeballing it
Key simplification: earlier chapters preserved interaction type (I/a/c notation from Table 8.2); for clustering, that’s suppressed to a simple count: is there a connection, and how many shared ones
Trade-off: loses type info, but lets a mechanical algorithm rearrange rows/columns into contiguous tightly-coupled blocks: much harder to automate otherwise
Choice for the worked example (fragment): cluster by process, coupling = shared operands. Sets up Table 8.4’s DSM next

Discussion: Why cluster by interactions rather than merely by names?

Suggested answer: Strongly interacting entities often need close coordination. Grouping them can reduce cross-boundary dependencies, although lifecycle, ownership, and implementation constraints may justify other boundaries.

Table 8.4 · DSM Clustering of Level 2 Processes

The Thebeau algorithm reorders the 28×28 process-interaction matrix so tightly-coupled entities fall into contiguous, shaded blocks along the diagonal: six clusters emerge. Individual cell values aren’t the point here; the block-diagonal pattern is. Source: Crawley, Cameron & Selva (2016), Table 8.4.

How to read this table: individual cell values aren’t the point, the pattern is
28×28 matrix (all 28 Level 2 processes), each cell = count of shared operands between row and column process
Thebeau algorithm (Ronnie Thebeau’s 2001 MIT master’s thesis on system-interface knowledge management): reorders rows/columns so highly-coupled entities sit next to each other
Payoff: shaded block-diagonal pattern, six clusters emerge: groups that interact heavily internally, little across
What matters is the shape of the reordered pattern (clean block-diagonal vs. messy), not individual numbers. Same technique (DSM + clustering) returns in much more depth in Chapter 13: get comfortable reading it now

Discussion: Does moving DSM rows and columns change the system?

Suggested answer: Reordering reveals patterns in the same relationship data. Actual modularization may later change allocation or interfaces, but rearranging the matrix alone changes only its representation.

Table 8.4 · One DSM block up close

The reservation cluster is a 5 × 5 block of shared-operand counts:

Process	Linking	Learning	Reserving	Purchasing	Amending
Linking	2	2	2	2	2
Learning	2	3	3	2	3
Reserving	2	3	4	3	4
Purchasing	2	2	3	4	4
Amending	2	3	4	4	5

Tip

Read a cell as a count, not an interaction type: reserving and amending share four operands. The diagonal counts each process’s own operands.

Reservation block from Crawley, Cameron & Selva (2016), Table 8.4.

Table 8.4 · From operands to clusters

Two Level 2 processes are coupled when they interact with the same operand. The book’s example makes the count concrete:

Process pair	Shared-operand count	Interpretation
Arriving at airport ↔︎ embarking	3	Both touch three of the same operands.
Reserving ↔︎ amending	4	Strong interaction within the reservation block.
Linking ↔︎ transporting	0	No shared operand in this model.

The clustering algorithm reorders the 28 processes to reveal six dense blocks. The architect then compares those blocks with the original time-based Level 1 decomposition.

Counts from Crawley, Cameron & Selva (2016), Table 8.4 and accompanying text.

Six Clusters Emerge

Cluster 1 (reservation): linking, learning, reserving, purchasing, amending
Cluster 2 (ticket): changing, issuing, crediting
Clusters 3–5 (passenger, checked bags, carry-on bags): each follows the same check-in → move → check-out pattern for its respective operand
Cluster 6 (secondary experience): alerting, informing, entertaining, nourishing

Tip

This decomposition groups processes by operand path. The original decomposition grouped them by their place in the travel sequence.

Name the six blocks in human-readable terms: where the abstract clustering turns into architectural insight
Cluster 1 (reservation): linking, learning, reserving, purchasing, amending
Cluster 2 (ticket): changing, issuing, crediting
Clusters 3–5: passenger, checked bags, carry-on bags: strikingly similar structure, each following check-in → move → check-out
Cluster 6 (secondary experience): alerting, informing, entertaining, nourishing
Compare the groups produced by operand-based clustering with those in the original travel sequence. Each organization serves different analytical questions.

Discussion: Do six visible clusters establish a uniquely correct decomposition?

Suggested answer: No. They reflect the relationships represented and the clustering criterion. Check excluded interactions and operational or organizational needs before adopting the groups.

Comparing Decompositions

The clustering isn’t perfect, interactions still cross block boundaries, and clustering doesn’t guarantee a better modularization, just a systematic one
The original, timeline-based decomposition (Figure 8.2) and this operand-based one (Table 8.4) represent two different ways of organizing the same system

If the airline cared about running time, the time-based organization might make more sense. If it cared about end-to-end reliability per passenger or bag, the operand-based clustering looks more appropriate.

Ask students what evidence would justify choosing the algorithmic clustering over the original grouping.
The clustering isn’t perfect even on its own terms: meaningful interactions still cross block boundaries
More fundamentally: a clustering algorithm doesn’t guarantee a better modularization, only a systematic, reproducible one
Central conclusion: timeline-based (Fig 8.2) and operand-based (Table 8.4) decompositions are just two ways of organizing the same system: neither objectively “right”
Resolve via what the architect optimizes for: running time favors the time-based organization; end-to-end reliability per passenger/bag favors the operand-based clustering
Generalizable lesson: modularization isn’t purely mechanical: it’s anchored to the system’s actual goals, echoing Chapter 2’s focus principle (“which entities matter” depends on the question)

Discussion: When would a timeline view be preferable to an interaction-based decomposition?

Suggested answer: For understanding sequence, handoffs, and service progression. Interaction-based grouping can better support resource allocation or organizational coordination. Use the view appropriate to the question.

Section 8.5 Summary

Modularizing Level 1 well requires expanding to Level 2, examining relationships by process or form, and then clustering
Clustering algorithms maximize local interaction and minimize cross-block interaction: better informing internal interfaces and how design work gets distributed
No single decomposition is universally “correct”: the right one depends on what the architect is optimizing for

Section checkpoint before the chapter wrap-up: students should walk through the full recipe: expand to Level 2 (8.3), examine relationships via process or form (Box 8.1), represent as a DSM, apply a clustering algorithm (Thebeau) to surface tightly-coupled blocks
What this buys practically: informs where internal interfaces should sit, and how design work can be distributed across teams/suppliers: loosely-coupled modules need far less cross-team coordination
Central caution, worth carrying forward: no decomposition is universally “correct”: the right one depends on what the architect is optimizing for. Not a limitation of the method: a fundamental feature of architectural decision-making, revisited especially in Part 3

Discussion: What information should accompany a proposed module boundary?

Suggested answer: Its purpose, contained functions and form, external interfaces, and rationale. Explain how the grouping manages strong dependencies and what coordination remains outside it.

Chapter 8 Summary

Concept expands into architecture through a recursive process: Level 0 → Level 1 → Level 2, applying function–goal reasoning at each step
Level 1 architecture starts from the value pathway (Question 5b), then zigzags between function and form to fill in the rest (Questions 4, 5, 6)
Level 2 architecture, developed the same way, has two jobs: validate that Level 1 is a reasonable decomposition, and inform its modularization
This closes Part 2: analysis of form (Ch. 4), function (Ch. 5), form-to-function mapping (Ch. 6), solution-neutral function and concept (Ch. 7), and Level 1/2 architecture (Ch. 8)

Tip

Reference: Crawley, E., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson. Chapter 8.

Final summary: walk the whole arc, this is the capstone of Part 2
Concept and architecture differ by orders of magnitude in information content; closing that gap is recursive (Level 0 → 1 → 2), governed throughout by function-goal reasoning
Two-stage recipe: Level 1 = value pathway (5b) + zigzag through Ch.4–6 questions; Level 2 = the same procedure recursively one level down: validates Level 1’s decomposition, informs modularization (Section 8.5’s DSM clustering)
This chapter closes out Part 2: recap: Ch.4 form, Ch.5 function, Ch.6 architecture as a mapping, Ch.7 solution-neutral function/concept as the bridge to synthesis, Ch.8 completes the bridge: concept → full, validated, modularized architecture. Everything from here builds on this

Discussion: What distinguishes a defensible architecture from a plausible-looking diagram?

Suggested answer: Traceability to intent, complete functional pathways, credible enabling form, and explicit interfaces and assumptions. The diagram is evidence of the reasoning only when those checks support it.

Next: Part 3: Creating System Architecture

Part 3 develops architectures for systems that do not yet exist, beginning with the role of the architect in Chapter 9.