System Architecture as a Decision-Making Process

Systems Architecture · Chapter 14

Aykut C. Satici

Architecture as a system of decisions

• Chapters 11–13 connected stakeholder needs, concepts, and decomposition.
• A decision model sits between needs and the resulting architecture.
• Its entities are decisions; its relationships are constraints and shared effects on metrics.
• Ten binary decisions already admit \(2^{10}=1{,}024\) combinations.

Computation helps explore alternatives and provides evidence for the architect’s decisions.

• Ask: “What decisions would change the architecture of a campus delivery system?” Expect vehicle type, depot arrangement, and allocation of delivery functions. Contrast these with choosing a paint color.
• Reconnect to Chapter 13: we now manage the apparent complexity of the decision problem, not only the physical product. The decision model is itself a system.
• The chapter emphasizes the leverage of the first few architectural decisions over performance and cost. The power-of-two count is a size illustration, not evidence that all combinations are feasible.
• Humans contribute framing, creativity, holism, and judgment; computers help enumerate, check, calculate, and display.

Discussion: Which campus-delivery choices would change the architecture?

Suggested answer: Vehicle type, depot arrangement, loading, and handoff can change function allocation and interfaces. Paint color normally does not under the stated delivery goals, unless an additional requirement makes it consequential.

Source: Crawley, Cameron & Selva (2016), §14.1, pp. 325–326.

Learning Objectives

By the end of this chapter, you should be able to:

1. Formulate decisions, alternatives, constraints, and metrics using Apollo.
2. Distinguish decision-making phases from decision-support layers.
3. Use morphological matrices, DSMs, and decision trees.
4. Evaluate alternatives under uncertainty and explain the tools’ limits.

Topics: Apollo, decision support, modeling tools, and architectural challenges.

• Explain that the deck is a complete chapter treatment and can be split after the four decision-support layers if needed.
• Students should be able to construct and critique a small model, not memorize historical spacecraft details.
• Opening diagnostic: ask whether “low cost” is a decision, alternative, constraint, or metric. It is a goal; cost is a metric, and a specified cost ceiling can be a constraint.
• Keep that distinction visible during the Apollo example.

Source: Crawley, Cameron & Selva (2016), §§14.1–14.7.

14.1 The Apollo architecture problem

Start with the mission purpose. Ask students to propose ways of getting a crew to the lunar surface and home before showing the mission-mode choices. Source: §14.1, pp. 325–326.

Apollo: purpose and mission modes

Goal: land a person on the Moon and return safely to Earth within the 1960s.

Mission mode	Earth-orbit rendezvous (EOR)	Lunar-orbit rendezvous (LOR)
Direct	No	No
EOR	Yes	No
LOR	No	Yes
EOR + LOR	Yes	Yes

Rendezvous and docking: vehicles meet and connect so crew or equipment can transfer.

• Define orbit, rendezvous, and docking before discussing tradeoffs. Meeting is not yet docking: docking adds the physical connection needed for transfer.
• In the direct mission mode, the spacecraft travels to the Moon, lands, ascends, and returns; the model has no separate lunar module.
• Important vocabulary: “direct mission mode” means neither EOR nor LOR. It does not require every individual launch/arrival/departure maneuver to take the alternative named “direct.”
• The book identifies June 1962 as the decisive LOR selection and 1969 as the successful landing. Present this as the chapter’s historical account.

Discussion: Does entering Earth orbit necessarily mean using EOR?

Suggested answer: No. EOR requires rendezvous between vehicles in Earth orbit. A single vehicle can enter orbit without rendezvous, so an orbital maneuver and the EOR mission mode are distinct choices.

Source: Crawley, Cameron & Selva (2016), §14.1, pp. 325–326; Fig. 14.1.

Effects of Mission Mode

Mode	Architectural benefit	Architectural burden
Direct	Fewer vehicle types to develop	Take return hardware down to the Moon and back up
EOR	Assemble near Earth; easier retreat after failure	Rendezvous and docking operations
LOR	Leave Earth-return hardware and propellant in lunar orbit	Specialized lander and remote rendezvous

LOR assigns lunar landing and Earth return to different vehicles.

• Ask: “Why carry an Earth-entry heat shield to the lunar surface if it will only be used back at Earth?” This makes the mass benefit of separating functions concrete.
• Explain the OPM connection verbally: the crew is an operand whose location changes; landing and returning are processes; the lander and return vehicle are instruments. LOR changes the mapping of those functions to form.
• EOR’s near-Earth assembly has a recovery advantage; that alone does not prove an EOR architecture has the best total success probability. Several operations contribute to the metric.
• Selecting LOR created a stable family of acceptable designs for engineers to refine; it did not specify every dimension or component.

Discussion: Why avoid taking an Earth-entry heat shield to the lunar surface?

Suggested answer: It serves a later Earth-return function and adds mass to lunar descent and ascent. Separating vehicles can avoid carrying it through those maneuvers, at the cost of extra interfaces and rendezvous operations.

Source: Crawley, Cameron & Selva (2016), §§14.1–14.2, pp. 325–327.

14.2 Formulating the Apollo decision problem

The next task is to translate a mission into an explicit model. Revisit the four nouns: decisions, alternatives, constraints, and metrics. Source: §14.2, pp. 326–331.

Three heuristics for choosing decisions

1. Bound the architectural space. Include plausible ways to meet the goal within scope and schedule.
2. Choose decisions that affect the metrics. Test whether the evaluated outcomes change.
3. Keep decisions architectural. Include choices that alter form, function, or their mapping.

Refine the model iteratively: an apparently irrelevant decision may expose a missing metric.

• Boundary example: the study considers small crews and EOR/LOR; Mars expeditions and large lunar settlements exceed its immediate scope.
• Influence example: crew size and propellant affect mass and success probability. An uninformative decision may be removed, but first ask whether the metric set omits the value it provides.
• Architecture example: LOR changes the vehicles and the functions allocated to each. Fuel affects engine and tank requirements indirectly. The authors omit launch-site location in this model; do not generalize that it can never be architectural.
• Ask: “If passenger capacity has no effect on our delivery-system score, should we delete the capacity decision or fix our score?” There is no automatic answer; inspect the stakeholder needs.

Discussion: If capacity does not affect the score, should we remove that decision?

Suggested answer: First check whether the metric set captures stakeholder needs. Capacity may be irrelevant within the fixed scope, or its apparent irrelevance may expose an omitted benefit or constraint.

Source: Crawley, Cameron & Selva (2016), §14.2, pp. 326–327.

Five mission-mode decisions

Decision	Alternatives	Question
EOR	no / yes	Dock in Earth orbit?
earthLaunch	orbit / direct	Enter Earth orbit or depart directly?
LOR	no / yes	Dock in lunar orbit?
moonArrival	orbit / direct	Enter lunar orbit or descend directly?
moonDeparture	orbit / direct	Enter lunar orbit or return directly?

One selection from each row specifies the maneuver pattern.

• Trace the order of travel: Earth departure, lunar arrival, lunar departure, and Earth return. EOR and LOR describe operations at orbital meeting points.
• These are the first five rows of Figure 14.1. Keep the exact identifiers so students can compare the slides to the source tables.
• Ask whether choosing LOR=yes leaves moonArrival and moonDeparture free. It does not; the forthcoming constraints force both to orbit.
• This table represents alternatives but does not yet say which combinations are compatible.

Discussion: Does choosing LOR leave lunar arrival and departure unconstrained?

Suggested answer: No. In this model, LOR requires orbital arrival and departure. The individual decision domains list possibilities; the logical rules determine which combinations are allowed.

Source: Crawley, Cameron & Selva (2016), Fig. 14.1, pp. 327–328.

Four crew and propellant decisions

Decision	Alternatives
cmCrew	2 or 3 people in the Command Module
lmCrew	0, 1, 2, or 3 people in the Lunar Module
smFuel	cryogenic / storable
lmFuel	NA / cryogenic / storable

• Cryogenic: LOX/LH₂; higher performance in this model.
• Storable: hypergolic propellant; higher reliability in this model.
• 0 / NA represent an absent lunar module.

• Spell out Command Module (CM), Lunar Module (LM), and Service Module (SM). The service module supports the command module with propulsion and other services.
• The framing discussion considers landing one to three people. The actual decision table uses two or three CM crew, while a separate LM can carry one to three. These are different counts.
• LOX/LH2 means liquid oxygen/liquid hydrogen; hypergolic propellants ignite on contact. Limit the performance/reliability comparison to the chapter’s retrospective assumptions.
• With no lunar module, lmCrew=0 does not mean nobody lands: the direct-mode vehicle carries the crew to the surface. The mission goal is still satisfied.

Discussion: Why distinguish CM crew from LM crew?

Suggested answer: They describe different vehicle occupancies. A separate lunar module can carry a subset of the command-module crew, but cannot require more people than the mission provides.

Source: Crawley, Cameron & Selva (2016), Fig. 14.1 and §14.2, p. 328.

Where the mission decisions occur

Source: Crawley, Cameron & Selva (2016), Fig. 14.1, p. 328. The figure locates the five maneuver decisions from the preceding table; crew and fuel decisions complete the nine-row matrix.

• Trace one path from Earth to Moon and back. At each labeled location, ask which alternative the vehicle takes.
• The diagram locates decisions; it does not by itself authorize every combination. Apply Table 14.1’s constraints next.
• The caption in the printed book refers to logical constraints in Figure 14.2, but those constraints appear in Table 14.1.

Discussion: Where does the LOR decision change the mission path?

Suggested answer: It changes whether vehicles meet and dock in lunar orbit. In this model, LOR also requires orbital lunar arrival and departure and a lunar module.

Source: Crawley, Cameron & Selva (2016), Fig. 14.1 and Table 14.1, pp. 328–329.

Logical constraints: maneuvers

ID	Rule	Physical meaning
a	EOR = yes ⇒ earthLaunch = orbit	Earth docking needs an Earth orbit
b	LOR = yes ⇒ moonArrival = orbit	Arrive in lunar orbit to support LOR
c	LOR = yes ⇒ moonDeparture = orbit	Ascend to lunar orbit for rendezvous

An implication is one-way: earthLaunch = orbit does not require EOR = yes.

• Translate each implication into a rejected combination. For example, EOR=yes with earthLaunch=direct fails constraint a.
• Ask for a counterexample to the converse: one vehicle can enter Earth orbit without meeting another vehicle there.
• This distinction prevents students from over-pruning the search space.
• The chapter contains apparent labeling errors: the prose on p. 337 says earthLaunch=yes, although its alternatives are orbit/direct; Figs. 14.4 and 14.5 label a direct lunar departure under LOR=yes. Use Table 14.1 as the consistent rule: LOR requires orbital departure. The tree examples in this lecture follow that rule.

Discussion: Give a counterexample to ‘Earth orbit implies EOR.’

Suggested answer: A single spacecraft can enter Earth orbit and later depart without meeting another spacecraft. EOR implies the orbital maneuver in this model, but the converse does not follow.

Source: Crawley, Cameron & Selva (2016), Table 14.1, p. 329; compare Figs. 14.4–14.5.

Logical constraints: crew and vehicle existence

ID	Rule
d	lmCrew ≤ cmCrew
e	No LOR ⇒ lmCrew = 0; LOR ⇒ lmCrew > 0
f	No LOR ⇒ lmFuel = NA; LOR ⇒ lmFuel ≠ NA

LOR couples the mission maneuvers, existence of the lunar module, its crew, and its fuel.

Check: can LOR=yes, cmCrew=2, lmCrew=3 be feasible?

• Expected answer: no, it violates constraint d. We cannot manufacture another astronaut at the Moon.
• Constraints e and f encode the modeling convention that a separate LM exists exactly when LOR is selected. This is a boundary of this model, not a universal statement about all imaginable lunar systems.
• Ask students to repair the assignment in two ways: reduce lmCrew to one or two, or increase cmCrew to three, while satisfying the other constraints.
• The constraints capture expert knowledge and prevent nonsensical combinations from acquiring apparently attractive scores.

Discussion: How can an assignment with two CM crew and three LM crew be repaired?

Suggested answer: Reduce LM crew to one or two, or increase CM crew to three. The repaired assignment must also satisfy the mission-mode and vehicle-existence rules.

Source: Crawley, Cameron & Selva (2016), Table 14.1 and §14.2, p. 329.

Feasibility and reasonableness

• Logical constraint: a combination violates the model’s physical or operational rules.
• Reasonableness constraint: a combination is possible but judged undesirable.
• Example: two partner nations each develop a redundant lunar lander; potentially wasteful, but not logically impossible.

Discussion: when might redundancy justify what initially looks wasteful?

• Invite answers such as resilience, independent access, or different mission roles. The book’s example assumes duplication without a compensating benefit.
• Emphasize that a reasonableness rule embeds a judgment. Record its rationale and revisit it when goals change.
• If all undesirable alternatives are excluded before scoring, the model can conceal a meaningful tradeoff. Ask whether a cost penalty would be more informative than a hard exclusion.
• Distinguish such a judgment from the crew-count constraint, which is a logical consistency requirement in the stated model.

Discussion: When is a penalty more informative than excluding a candidate?

Suggested answer: When the candidate is feasible but unattractive on a tradable concern. A penalty or explicit metric preserves the tradeoff; a hard constraint is appropriate for a required condition.

Source: Crawley, Cameron & Selva (2016), §14.2, p. 329.

How large is the Apollo search space?

Before constraints:

\[2^5\times2\times4\times2\times3=1{,}536\]

After all six logical constraints: 108 feasible assignments.

Branch	Count
No LOR	\(3\times4\times2\times2=48\)
LOR	\(3\times5\times2\times2=60\)

Classroom enumeration from the chapter’s decisions and constraints.

• This is a derived classroom calculation, not a total quoted by the chapter. Walk through the factors rather than ask students to memorize 108.
• Three valid (earthLaunch,EOR) pairs: (orbit,no), (orbit,yes), (direct,no).
• No LOR: four lunar arrival/departure combinations, two CM crew choices, and two SM fuels give 48; LM crew/fuel are fixed to 0/NA.
• LOR: both lunar maneuvers are fixed to orbit; five feasible (cmCrew,lmCrew) pairs are (2,1), (2,2), (3,1), (3,2), (3,3). Two SM fuels and two LM fuels give 60.
• Ask why naive multiplication fails after constraints: alternatives are coupled. Count assignments, not necessarily distinct metric points; several assignments can have equal scores.

Discussion: Why can’t we multiply option counts to obtain the feasible count directly?

Suggested answer: That product counts all assignments before coupled constraints. Apply the rules and remove invalid combinations; also distinguish distinct assignments from distinct physical architectures or metric points.

Source: Crawley, Cameron & Selva (2016), Fig. 14.1 and Table 14.1; classroom enumeration.

Apollo evaluation metrics

The case is iso-performance: every feasible architecture meets the basic lunar-landing goal.

Metric	Desired direction	Interpretation
Initial mass to low Earth orbit (IMLEO)	Lower	Proxy for cost
Probability of mission success	Higher	Proxy for operational risk

Mass is calculated using the rocket equation and historical parameters; success uses operation-level factors.

• Iso-performance means equivalent at the level of the minimum mission objective, not identical scientific return, crew capability, or comfort.
• IMLEO is a mass measure, not a complete dollar-cost estimate. Different development programs could cost differently even at the same mass.
• The chapter does not include developmental risk as an explicit axis in this particular plot; it notes that performance, cost, and development/operation risk commonly appear in architecture evaluation.
• Ask what could be missing: schedule, scientific return, abort options, or development effort. A good plot still inherits its modeling boundary.

Discussion: What might a mass-versus-success plot omit?

Suggested answer: Schedule, scientific return, abort capability, and development effort are possible omissions. Whether they matter depends on the agreed goals; a two-axis plot does not make them disappear.

Source: Crawley, Cameron & Selva (2016), §14.2, p. 329.

Why mission mode changes mass

The rocket equation relates a maneuver to its mass ratio:

\[\Delta v=I_{sp}g_0\ln\!\left(\frac{m_0}{m_f}\right)\]

• \(m_0\): mass before the burn; \(m_f\): mass after the burn.
• \(I_{sp}\): specific impulse; \(g_0\): standard gravitational acceleration.
• Extra payload requires extra propellant, which earlier stages must also carry.
• LOR avoids landing and relaunching the hardware reserved for Earth return.

• This equation makes explicit the rocket-equation relationship named by the chapter; it is an explanatory addition, not a reconstruction of the authors’ full IMLEO simulation.
• Explain delta-v as the maneuver’s required velocity change, including the appropriate trajectory/model assumptions. Students do not need orbital-mechanics details here.
• The logarithm hides strong mass growth: solving for m0 gives mf times exp(delta-v/(Isp*g0)). Carrying more final mass multiplies through earlier maneuvers.
• A full architecture evaluation needs trajectories, staging, inert masses, propellant properties, and burn assignments. Do not imply this one equation alone reproduces Figure 14.2.

Discussion: Why can a small payload-mass reduction have a larger launch-mass effect?

Suggested answer: Payload must be accelerated along with the propellant and supporting structure needed for later maneuvers. Removing mass from a downstream stage can reduce upstream propulsion demands as well.

Source: Crawley, Cameron & Selva (2016), §§14.2 and 14.5, pp. 329, 338–340.

Success factors: maneuver choices

Decision	Alternative	Success factor
EOR	no / yes	0.98 / 0.95
Earth launch	orbit / direct	0.99 / 0.90
LOR	no / yes	1.00 / 0.95
Moon arrival	orbit / direct	0.99 / 0.95
Moon departure	orbit / direct	0.90 / 0.90

These are the chapter’s retrospective model inputs, not measured Apollo flight frequencies.

• The prose groups operational risk into high, medium, low, and very low, associated with success factors 0.90, 0.95, 0.98, and 0.99. Table 14.2 additionally uses neutral factors of 1 and repeated-operation products.
• Higher values here mean higher success, not higher risk. Be explicit because the table labels its rows “risk.”
• The authors base the factors on early-1960s documents and interviews with decision makers. They are simplifying assessments.
• EOR=no still receives 0.98. Do not silently substitute 1 because it seems more intuitive; the point is to expose and question the chosen model.

Discussion: Can we read a maneuver’s success factor as a measured overall mission reliability?

Suggested answer: No. It is an input to the chapter’s simplified model. Overall scoring combines the factors under stated assumptions and should not be confused with observed historical reliability.

Source: Crawley, Cameron & Selva (2016), Table 14.2, p. 330; §14.2, p. 329.

Success factors: crew and fuel choices

Decision	Alternatives and factors
CM crew	2: 1; 3: 1
LM crew	0: 1; 1: 0.90; 2: 1; 3: 1
SM fuel	cryogenic: \(0.95^{n_{burns}}\); storable: 1
LM fuel	NA: 1; cryogenic: 0.9025; storable: 1

\[P(\text{mission success})=\prod_i p_i\]

A factor of 1 means no additional penalty in this model.

• One lunar-module crew member incurs a penalty; two or three do not. This is a model assumption about solo operations, not a universal numerical law about teamwork.
• The LM cryogenic factor is 0.95 squared = 0.9025. The SM cryogenic exponent depends on the architecture’s burn count, so it is not a universal fixed number.
• A product of unconditional probabilities requires independence; alternatively, a product of appropriately conditioned stage-success probabilities follows the chain rule. The chapter’s simplified factor model should not be mistaken for proof of real operational independence.
• Metrics also couple decisions: changing one success factor changes the product associated with every combination of the other decisions. Discuss common-cause failures that a naive product could miss.

Discussion: What could invalidate multiplying separate success factors?

Suggested answer: Dependence or common-cause failures can make the product inappropriate unless the factors are correctly conditioned. Identify what each factor means and which independence assumptions the calculation uses.

Source: Crawley, Cameron & Selva (2016), Table 14.2 and §14.2, pp. 329–330.

Worked example: the Apollo-like assignment

EOR=no, earthLaunch=orbit, LOR=yes, both lunar maneuvers orbit, 3 CM crew, 2 LM crew, both fuels storable.

\[P_s=0.98(0.99)(0.95)(0.99)(0.90)(1)(1)(1)(1)\] \[P_s\approx0.8212\]

Changing only the LM crew to one gives \(0.8212\times0.90\approx0.7391\).

Calculated from Table 14.2; these are model scores, not observed mission reliability.

• Ask students to check all six constraints before multiplying: EOR=no is compatible with Earth orbit; LOR=yes requires lunar orbit on arrival/departure, positive LM crew and a real fuel; 2≤3.
• Assign one student to read the decision values and another to supply the table factors. The bookkeeping matters more than the arithmetic.
• Point 3 in the book matches the actual Apollo configuration qualitatively. The source plot places it at roughly 0.74, whereas directly multiplying the printed Table 14.2 factors for this assignment gives 0.8212. The chapter does not provide enough computational detail to reconcile this discrepancy. Keep the worked table calculation separate from the published plot; do not claim to reproduce its point coordinates.
• The one-person variant reduces the factor by 10 percent, or about 8.21 percentage points of modeled mission success. This distinction is a useful numerical check.

Discussion: What does reducing LM crew to one do in the worked factor model?

Suggested answer: It multiplies 0.8212 by 0.90, giving about 0.7391: a 10% relative decrease, or about 8.21 percentage points. Check feasibility before evaluating the score.

Source: Crawley, Cameron & Selva (2016), Table 14.2 and Fig. 14.2, pp. 330–331; classroom calculation.

The Apollo tradespace

Source: Crawley, Cameron & Selva (2016), Fig. 14.2, p. 331. Published plot; each point is a feasible assignment. Lower and farther right is preferable. U marks the hypothetical ideal.

• Read the axes first: IMLEO is in pounds on the original figure; success probability increases to the right. Therefore the preferred direction is down and right.
• Explain U: zero mass and certain success are an imaginary benchmark, not an achievable design. Distance to U is not automatically a valid preference rule because axes have different units and scales.
• The dashed set shows architectures for which improving one objective requires a tradeoff with the other. Chapter 15 develops this reasoning more fully.
• Ask whether the highest-success point must be selected. Expected answer: not without a judgment about the added mass, cost proxy, and omitted concerns.
• Use this as the published result, not a plot regenerated from the simplified factor table; the preceding notes explain their numerical mismatch.

Discussion: Must the point with highest modeled success be selected?

Suggested answer: No. It may require substantially more mass or perform poorly on omitted goals. The tradespace reveals tradeoffs; stakeholder preferences and model confidence inform selection.

Source: Crawley, Cameron & Selva (2016), Fig. 14.2, p. 331.

Interpreting the highlighted architectures

Points	Configuration	Tradeoff
1–2	Direct missions; 3 or 2 crew	High modeled success; very high mass
3	Apollo-like LOR; 3 CM / 2 LM; storable fuels	Compromise between mass and risk
4–7	Other LOR assignments	Intermediate combinations
8	2 CM / 1 LM; cryogenic propellants	Minimum mass; resembles the Soviet proposal

The computation recovers recognizable historical choices without making the final value judgment.

• The chapter associates the direct-mode proposals with von Braun, LOR with Houbolt, and point 8 with the Soviet lunar architecture. Phrase these as the source’s retrospective comparisons.
• Do not invent detailed decision vectors for points 4–7: the chapter does not list them.
• Emphasize the role of evaluation: it exposes the mass-risk compromise, but the eventual preference still depends on the stakeholders and assumptions.
• Ask students which additional evidence they would request before deciding among points 2, 3, and 8. Encourage questions about schedule, abort behavior, and uncertainty rather than only “which is closest to U?”

Discussion: What evidence would help choose among the highlighted candidates?

Suggested answer: Compare schedule feasibility, abort behavior, development demands, and uncertainty in the modeled scores. Investigate whether the apparent performance differences are large enough to support the decision.

Source: Crawley, Cameron & Selva (2016), §14.2, pp. 330–331.

14.3 Decisions and decision support

Shift from Apollo to the general decision process. The key distinction is between forming and evaluating alternatives and actually selecting one. Source: §14.3, pp. 331–333.

What is a decision?

A decision is a purposeful selection among mutually exclusive alternatives.

• There is an issue with more than one possible course of action.
• Selecting an alternative separates the remaining solution space from rejected options.
• The selection is made to achieve an expected benefit.

Decision support helps a person reason about that choice.

• The chapter’s etymological discussion emphasizes cutting or separating; use the image of pruning a space of possibilities rather than treating a decision as merely expressing a preference.
• “Mutually exclusive” applies within a particular decision. EOR and LOR can both be yes because they are separate decisions, not alternatives in the same binary decision.
• Ask students to turn “we care about reliability” into a decision statement. An example is selecting single versus redundant sensing; reliability is then an evaluation metric.
• Decision making is goal-directed behavior in the presence of options, culminating in one or more selections.

Discussion: Turn ‘we care about reliability’ into a decision statement.

Suggested answer: ‘Choose single or redundant sensing’ identifies alternatives. Reliability is then a metric used to compare them; it is not itself the architectural choice.

Source: Crawley, Cameron & Selva (2016), §14.3, pp. 331–332.

Simon’s four phases

Phase	Main activity	Apollo illustration
Intelligence	Identify the situation requiring a decision	Interpret the mission need and deadline
Design	Invent, develop, and analyze alternatives	Formulate and evaluate mission modes
Choice	Select a course of action	Commit to LOR
Review	Assess past choices	Compare outcomes with expectations

Much effort goes into Intelligence and Design, before the selection itself.

• These are phases of the overall decision process, not the four layers of software that come next.
• Simon reports substantial effort in Intelligence, even more in Design, and smaller shares in Choice and Review. Do not make up universal percentages.
• Undergraduates often equate design with drawing a final object; here Design includes developing and analyzing possible courses of action.
• Ask: “Which phase is missing when a team immediately votes among the first two ideas?” Typically the framing and deliberate development of alternatives; review may also be neglected.

Discussion: What is missing when a team immediately votes on its first two ideas?

Suggested answer: It may skip understanding the problem and deliberately developing alternatives. A useful process also reviews the result and revisits the framing when new evidence appears.

Source: Crawley, Cameron & Selva (2016), §14.3, p. 332.

Programmed and non-programmed decisions

Programmed	Non-programmed
Repeated or well-defined problem	Novel or weakly structured problem
An established procedure is available	Creativity, judgment, and heuristics are central
Models and objectives are well specified	Models or goals may be imprecise
Controller tuning; routine factory planning	New product strategy; a new mission mode

Programmed does not mean easy or inexpensive. These are ends of a spectrum.

• Figure 14.3 places engineering design toward operations research and system architecting toward management science; the separation is a tendency, not a professional boundary.
• The source includes tipping a waiter, optimal control gains, and national aircraft routing as programmed examples. Aircraft routing can be computationally very demanding despite having a defined method.
• Other non-programmed examples include human Mars mission modes and national policy decisions. Avoid expanding into a political discussion; the distinction is the absence of a prepared solution procedure.
• Ask students to classify choosing an aircraft size. It can lie between the poles: some equations exist, but market framing and program context can remain uncertain.

Discussion: Is choosing aircraft size always a programmed decision?

Suggested answer: No. Established calculations may support part of it, while market needs, context, and program goals remain unfamiliar. Decisions can combine programmed and non-programmed aspects.

Source: Crawley, Cameron & Selva (2016), Fig. 14.3 and §14.3, pp. 332–333.

The decision spectrum in Figure 14.3

• Read the continuum rather than classifying every problem into two rigid bins. Aircraft size appears near the middle.
• The figure associates engineering design more with established operations-research methods and system architecting more with management-science problems. These are tendencies, not exclusive domains.
• Return to the preceding table for legible definitions. A known procedure can still be expensive or difficult to execute.

Discussion: Why is aircraft size placed near the middle?

Suggested answer: Established calculations inform the choice, while market needs and the larger program can remain uncertain.

Source: Crawley, Cameron & Selva (2016), Fig. 14.3 and §14.3, pp. 332–333.

Developing methods for unfamiliar decisions

• A previously non-programmed decision can become more systematic.
• Alexander’s pattern language records reusable triples:
  • Context: where the pattern applies.
  • Problem: what must be resolved.
  • Solution: a reusable architectural response.
• Decision support makes exploration more rigorous while leaving room to revise the framing.

• The chapter suggests “not-yet-programmed” as a useful way of thinking about some non-programmed decisions.
• Classroom analogy: a quiet study space next to a noisy corridor is a context; acoustic disturbance is the problem; a buffer space is a possible reusable response. Label it as an illustrative pattern, not a quoted Alexander pattern.
• Reuse does not make a pattern universally correct. Ask what changes in context would invalidate the proposed solution.
• Bridge to later chapters: patterns return in Chapter 16. Here the purpose is to see why systematic support can help without eliminating creativity.

Discussion: When could reusing a previous decision method mislead us?

Suggested answer: When the context, available alternatives, goals, or governing assumptions have changed. Reuse the method only after checking which parts of the earlier problem still apply.

Source: Crawley, Cameron & Selva (2016), §14.3, p. 333.

14.4 Four tasks of decision support

Place all four layers inside Simon’s Design Activity. Keep the phases and layers distinct on the board. Source: §14.4, pp. 333–334.

Four layers within the Design Activity

Layer	Question	Apollo example
Representing	What are the decisions and alternatives?	Nine-row morphological matrix
Structuring	How are decisions connected and ordered?	LOR constraints; decision DSM
Simulating	Which assignments work, and how well?	Feasibility, mass, and success calculations
Viewing	How can people interpret the results?	Apollo tradespace plot

These support Design; selecting the architecture belongs to Choice.

• Give students a quick sorting exercise: listing two fuels is representing; linking LOR to LM fuel is structuring; multiplying success factors is simulating; plotting the results is viewing.
• Representation must be understandable by people and also encodable for computation. OPM is one available representation for function, form, and decision problems.
• Structuring includes decision order and connectivity. Simulation includes enforcing constraints as well as calculating outcomes; methods range from simple equations to discrete-event simulation.
• Viewing communicates results from both structuring and simulation. A useful display should support questions, not simply decorate an answer.
• The book mentions commercial DSS packages as examples, not as required course tools. No particular software package is necessary to apply these layers.

Discussion: Classify listing fuels, linking LOR to fuel, scoring success, and plotting results.

Suggested answer: They are representing, structuring, simulating, and viewing, respectively. Each answers a different question, and conclusions should remain traceable across the layers.

Source: Crawley, Cameron & Selva (2016), §14.4, pp. 333–334.

14.5 Basic decision-support tools

Revisit tools already encountered in earlier chapters: OPM, morphological matrices, and DSMs. Then introduce decision trees. Source: §14.5, pp. 334–340.

Morphological matrices and OPM

• A morphological matrix lists each decision with its alternatives.
• Choose one alternative per row; choices need not share a column.
• The combinations are represented implicitly.
• OPM connects choices to objects, processes, and function-to-form mappings.

Evaluating an architecture also requires feasibility rules, metrics, and a model of stakeholder preferences.

• Credit Zwicky’s morphological approach, which sought to study the space of configurations. Recall Chapter 7’s concept-selection examples and function/form specialization.
• Use the Apollo rows: EOR=no, LOR=yes, cmCrew=2, lmCrew=2 is a partial assignment selecting alternatives in different columns. Complete the remaining rows before calling it a full architecture.
• The morphological matrix is easy to build and understand, but by itself lacks constraints, metrics, and evaluation results. Do not imply columns are bundled designs.
• OPM retains the functional meaning that a decision table can hide. Ask what changes in the objects and processes when the LM is absent. We use OPM for this connection; the other tools here model choices and their relationships.

Discussion: What changes in the functional model when there is no separate LM?

Suggested answer: The required lunar landing and ascent functions still need enabling form, but they are allocated differently. Remove the absent object and revise the processes and interfaces that depended on it.

Source: Crawley, Cameron & Selva (2016), §14.5, pp. 334–335; Fig. 14.1.

A decision DSM

A Design Structure Matrix is an \(N\times N\) table with the same decisions on both axes.

• An entry records a connection between two decisions.
• The connection may be a logical rule, a reasonableness rule, or a shared metric effect.
• A blank means no connection of the type currently represented.
• The DSM lists decisions and relationships, but not their alternatives.

• Recall product DSMs from Chapter 4. The mathematical form is familiar; the entities have changed from product parts to architectural decisions.
• Steward introduced the DSM term in 1981; the chapter notes applications in product design, organizations, and project management.
• Ask: “If the constraint DSM has a blank, can the decisions still interact through mass?” Yes. Always specify what relationship a matrix represents.
• A binary mark reveals that a relationship exists, not its exact equation, sign, strength, or causal direction. Keep the constraint definitions alongside the DSM.

Discussion: Does a blank in a constraint DSM prove two decisions are independent?

Suggested answer: No. It means no direct relationship of the represented type. They may interact through a performance metric, an indirect path, or a relationship omitted from that matrix.

Source: Crawley, Cameron & Selva (2016), §14.5, p. 335.

Apollo DSM: logical constraints

Decision	1	2	3	4	5	6	7	8	9
1 EOR	–	a
2 earthLaunch	a	–
3 LOR			–	b	c		e		f
4 moonArrival			b	–
5 moonDeparture			c		–
6 cmCrew						–	d
7 lmCrew			e			d	–
8 smFuel								–
9 lmFuel			f						–

Letters refer to constraints a–f. LOR has four direct neighbors.

• Reconstructed from Table 14.3 with the LM fuel identifier normalized to lmFuel; the printed table uses imFuel in places.
• Have students find constraint d at the intersection of cmCrew and lmCrew. Then find all the entries in the LOR row.
• The table is symmetric because it records involvement in a shared constraint, not a directed causal implication. The underlying rules can still be one-way.
• smFuel has no logical-constraint neighbors here. It is not irrelevant: it affects metrics.
• Ask whether CM crew is connected to LOR: not directly in this matrix, but there is a path through LM crew. Direct adjacency and indirect dependence differ.

Discussion: Can CM crew and LOR be related without a direct DSM mark?

Suggested answer: Yes. A path through LM crew links them in the modeled constraint structure. Distinguish direct adjacency from indirect dependence when interpreting the matrix.

Source: Crawley, Cameron & Selva (2016), Table 14.3, p. 336; Table 14.1, p. 329.

Table 14.4: decisions linked by mass

Decision	1	2	3	4	5	6	7	8	9
1 EOR
2 earthLaunch
3 LOR						I	I	I	I
4 moonArrival
5 moonDeparture
6 cmCrew				I			I	I	I
7 lmCrew				I				I	I
8 smFuel				I			I		I
9 lmFuel				I			I	I

I marks a connection through the IMLEO metric. The marks reproduce the printed table; several reciprocal cells do not match.

• This is a cell-for-cell rendering of Table 14.4, with its printed imFuel identifier normalized to lmFuel as in Figure 14.1.
• The printed table is asymmetric: LOR’s row marks columns 6–9, while the reciprocal marks in rows 6–9 appear in column 4 (moonArrival). That is inconsistent with a bilateral DSM. Show the discrepancy rather than silently treating those column-4 marks as established physical dependencies.
• The surrounding discussion identifies the intended coupled group as LOR, crew, and fuel. Mass depends jointly on which vehicles exist, crew-dependent size, and propulsion choices.
• Blank maneuver rows here do not prove that maneuvers never affect mass. This particular DSM is a coarse depiction of the metric model.

Discussion: How can decisions interact through mass without sharing a logical constraint?

Suggested answer: A fuel choice can change the mass consequences of a crew or mission-mode choice while all combinations remain logically valid. Feasibility coupling and metric coupling are different relationships.

Source: Crawley, Cameron & Selva (2016), Table 14.4 and accompanying discussion, pp. 335–336.

Table 14.5: sorted constraint DSM

Decision	1	2	3	4	5	6	7	9	8
1 EOR	–	a
2 earthLaunch	a	–
3 LOR			–	b	c		e	f
4 moonArrival			b	–
5 moonDeparture			c		–
6 cmCrew						–	d
7 lmCrew			e			d	–
9 lmFuel			f					–
8 smFuel									–

Reordering Table 14.3 places the Earth pair and connected lunar decisions together. It does not remove a constraint.

• This reproduces Table 14.5 with imFuel normalized to lmFuel. Only the row and column order changes from Table 14.3; all six logical constraints remain.
• The chapter mentions partitioning procedures and clustering algorithms, with further clustering detail in Appendix B. Students need the purpose here, not a new algorithm implementation.
• These blocks are connected sets in this particular constraint graph, not equally dense cliques. Decisions within a coupled block should be coordinated or revisited together rather than frozen independently.
• If matrix order represents decision order, the DSM can support timing; it does not by itself prove an optimal sequence.
• Point back to Table 14.4: adding metric connections brings smFuel into the coordinated group. The prose around Table 14.5 discusses fuel couplings more broadly than the displayed constraint-only matrix.

Discussion: What does DSM clustering suggest for organizing a trade study?

Suggested answer: Strongly coupled decisions should be examined together. Check which relationship types the matrix includes before treating separated groups as suitable for independent study.

Source: Crawley, Cameron & Selva (2016), Tables 14.3 and 14.5, pp. 336–337.

Decision-tree vocabulary

Node	Meaning	Who controls the branch?
Decision (square)	Select an alternative	Decision maker
Chance (circle)	Realize an uncertain outcome	Not the decision maker
Leaf (terminal node)	Complete path and its outcome	No further branch

• Without chance nodes: a complete path specifies an architecture.
• With chance nodes: a complete path specifies an architecture and a scenario.

• The book uses triangles for leaves; terminal shapes are a drawing convention. Our editable tree examples label terminal nodes explicitly.
• Make the control distinction tangible: choosing a fuel is controllable; the future outcome of an uncertain operation is not.
• If a tree includes only five of Apollo’s nine decisions, its leaves specify mission modes, not fully specified nine-decision architectures.
• A tree explicitly enumerates paths, unlike a morphological matrix’s implicit combinations. This clarity has a size cost.

Discussion: How do a decision node and a chance node differ?

Suggested answer: The decision maker chooses an alternative at a decision node. A chance node represents an uncertain outcome; evaluation must use the available information and scenario probabilities.

Source: Crawley, Cameron & Selva (2016), §14.5, pp. 337–339; Figs. 14.4–14.5.

Figure 14.4: Apollo mission-mode tree

Source: Crawley, Cameron & Selva (2016), Fig. 14.4, p. 338. The three LOR=yes paths are printed with Direct lunar departure; Table 14.1 requires Orbit.

• Use the complete tree to show why explicit enumeration rapidly consumes space. Each of the three feasible Earth-operation prefixes reaches the same five-pattern lunar subtree.
• The figure is reproduced as printed. Its three LOR=yes → moonDeparture=Direct labels contradict constraint c in Table 14.1. Read those terminal labels as Orbit when evaluating valid architectures.
• The printed tree also uses earthDeparture where Figure 14.1 uses earthLaunch. The two refer to the same first mission-mode choice here.
• The following fragment and table give a readable, corrected way to trace the branches.

Discussion: How many valid mission-mode paths does the corrected tree contain?

Suggested answer: Three valid Earth-operation prefixes each lead to five valid lunar patterns, giving 15 paths. This counts mission modes, not full crew-and-fuel assignments.

Source: Crawley, Cameron & Selva (2016), Fig. 14.4 and Table 14.1, pp. 329, 338.

A pruned Apollo decision tree

%%{init: {"themeVariables": {"fontSize": "24px"}}}%%
flowchart LR
  A[earthLaunch] -->|orbit| B[EOR]
  A -->|direct| C[EOR]
  B -->|no| D[Lunar choices]
  B -->|yes| E[Lunar choices]
  C -->|no| F[Lunar choices]

The branch earthLaunch=direct, EOR=yes is absent because it violates constraint a.

Three valid Earth-operation prefixes remain.

• This is a fragment adapting the logic of Figure 14.4, not the whole nine-decision tree. Each endpoint continues into lunar decisions.
• Ask how many prefixes would exist without the constraint: four. Pruning one leaves three.
• The tree’s decision order is a representation choice. Different orderings can encode the same feasible set, though some reveal constraints earlier and are easier to inspect.
• The source figure labels the first decision earthDeparture; we use earthLaunch consistently with Figure 14.1. No chance nodes appear here.

Discussion: Why does the first Apollo tree lose one of four possible prefixes?

Suggested answer: EOR=yes with direct Earth launch violates the model’s implication. Pruning removes that invalid prefix and all of its downstream extensions.

Source: Crawley, Cameron & Selva (2016), Fig. 14.4 and Table 14.1, pp. 329, 338; adapted fragment.

Completing the lunar branches

For each valid Earth-operation prefix:

Moon arrival	LOR	Allowed Moon departure	Leaves
orbit	yes	orbit	1
orbit	no	orbit or direct	2
direct	no	orbit or direct	2

\(3\) Earth prefixes \(\times\ 5\) lunar patterns \(=\mathbf{15}\) mission modes.

Add the crew and fuel decisions to obtain complete architectures.

• Ask students which missing row is forbidden: moonArrival=direct with LOR=yes violates constraint b.
• Constraint c gives orbital departure whenever LOR=yes. This corrects the “Direct” branch label in the printed Figures 14.4 and 14.5.
• The total of fifteen mission-mode leaves agrees with the discussion on p. 340. Do not confuse it with 108 full feasible assignments after crew and fuel choices.
• Give one minute for students to sketch the five-leaf lunar subtree. This is easier to read than projecting the full fifteen-leaf tree at small scale.

Discussion: Why is LOR=yes with direct lunar arrival absent?

Suggested answer: It violates the orbital-arrival requirement associated with LOR. The fifteen mission-mode leaves count only that part of the decision model, not all crew and fuel assignments.

Source: Crawley, Cameron & Selva (2016), Fig. 14.4, pp. 337–338; Table 14.1, p. 329; p. 340.

Evaluating a path through a tree

• A separable metric can accumulate along a path.
• Apollo’s success-factor model uses a product of contributions.
• IMLEO involves nonlinear interactions and typically needs the complete assignment.
• Evaluating every leaf can become impractical as decisions and scenarios multiply.

The number of paths and the cost of evaluating each one determine the computational effort.

• Multiplication of factors is analogous to accumulating a running score, although burn counts and conditional assumptions must still be supplied correctly.
• Contrast with mass: the effect of a propellant choice depends on vehicle size and mission maneuvers, so a fixed independent “fuel mass score” is insufficient.
• Ask students to count twenty binary decisions: over a million assignments even before adding scenarios. Trees can become too large despite a short decision list.
• General methods may evaluate selected branches or cache repeated computations, but the chapter’s basic tree approach should not be confused with a scalable solution to every architecture problem.

Discussion: How many assignments do twenty independent binary decisions create?

Suggested answer: There are 2^20 = 1,048,576 before constraints or scenarios. A short list of decisions can therefore produce a tree too large for convenient explicit inspection.

Source: Crawley, Cameron & Selva (2016), §14.5, pp. 337–339.

Combining metrics into utility

A stakeholder preference model can combine normalized metric utilities:

\[U(a)=w\,u_M(M(a))+(1-w)\,u_P(P_s(a))\]

• \(a\): architecture; \(0\leq w\leq1\): mass-utility weight.
• \(u_M\) rewards lower mass; \(u_P\) rewards higher success.
• Utility functions and weights express preferences, not physical laws.

Normalize mass and success probability and define stakeholder preferences before combining them.

• This rewrites the chapter’s example with distinct symbols for architecture, mass, success, and utility to avoid overloading u.
• Multi-attribute utility theory provides a framework for eliciting component utilities and weights. An additive model requires suitable preference assumptions; a weighted sum is not automatically justified.
• Ask what increasing w does: it increases the relative contribution of mass utility, but its effect depends on the utility scales and shapes.
• Retain the two-axis tradespace during discussion so students can see what a single score compresses. Subjective preferences should remain traceable.

Discussion: What does increasing the mass-utility weight do?

Suggested answer: It increases mass utility’s relative contribution to the combined score, with an effect that depends on normalization and utility shape. It does not change the architectures’ physical performance.

Source: Crawley, Cameron & Selva (2016), §14.5, p. 339.

Figure 14.5: risk scenarios on Apollo branches

Source: Crawley, Cameron & Selva (2016), Fig. 14.5, p. 340. The printed LOR=yes → Direct branch conflicts with Table 14.1; a feasible LOR path departs through lunar orbit.

• Read the squares as controllable decisions and circles as uncertain risk-factor states. Each triangular leaf gives a metric value for one architecture and one scenario.
• The book uses symbolic R values and p rather than numerical payoffs. The next slide supplies a separate classroom calculation to practice rollback.
• The figure repeats the LOR=yes → Direct inconsistency from Figure 14.4. Constraint c requires lunar orbital departure for LOR. Use the diagram to understand chance nodes, not to override the feasibility model.
• At each chance node, combine the optimistic and pessimistic results with probabilities p and 1−p. Then compare feasible decision branches.

Discussion: Why can we not simply choose the leaf with the best risk value?

Suggested answer: A leaf includes an uncertain outcome the architect cannot select. Evaluate each decision across its possible outcomes before choosing.

Source: Crawley, Cameron & Selva (2016), Fig. 14.5 and Table 14.1, pp. 329, 339–340.

Uncertainty adds scenarios

%%{init: {"themeVariables": {"fontSize": "24px"}}}%%
flowchart LR
  A[Choose architecture] -->|A| B((Scenario))
  A -->|B| C((Scenario))
  B -->|optimistic: 0.5| D[Leaf: utility 90]
  B -->|pessimistic: 0.5| E[Leaf: utility 30]
  C -->|optimistic: 0.5| F[Leaf: utility 70]
  C -->|pessimistic: 0.5| G[Leaf: utility 60]

Classroom utilities and probabilities, not Apollo measurements.

You can choose A or B; you cannot choose the optimistic outcome.

• This numerical teaching example instantiates the chance-node idea in Figure 14.5 without using the source’s inconsistent lunar-departure label.
• Ask: “Why not choose the leaf with utility 90?” Because the leaf includes an outcome we cannot control.
• At each chance node, outgoing probabilities sum to one. Equal scenario probabilities are an illustrative assumption, not a default for real uncertainty.
• The decision precedes the scenario here. If information becomes available before a later decision, the tree must represent that timing and the resulting contingent policy correctly.

Discussion: Why can’t we simply choose the leaf with utility 90?

Suggested answer: That leaf includes a favorable outcome outside the decision maker’s control. Compare the alternatives across their possible outcomes rather than selecting the scenario as though it were an action.

Source: Crawley, Cameron & Selva (2016), §14.5, pp. 339–340; Fig. 14.5; classroom example.

Rollback: expectation, then choice

At chance nodes: compute expected utility.

\[EU(A)=0.5(90)+0.5(30)=60\] \[EU(B)=0.5(70)+0.5(60)=65\]

At the decision node: select the larger expected utility → B.

Repeat backward through the tree. For a cost or loss metric, minimize instead.

• Let students compute both expectations before discussing the choice. B wins in expectation despite A having the best individual outcome.
• These are already utility values. Maximizing expected utility is not the same as maximizing raw expected money or minimizing every kind of risk; utility encodes the preferences.
• In a tree with chance nodes interleaved among decisions, rollback can produce a policy conditional on observed information. Do not let a decision depend on an outcome that has not yet been observed.
• The source describes rolling back from Moon departure to LOR and earlier choices, averaging at chance nodes and optimizing at decision nodes.

Discussion: Which alternative wins with equally likely scenarios?

Suggested answer: EU(A)=60 and EU(B)=65, so B wins under the given utility model. Compute expectations at chance nodes, then choose at decision nodes using the correct information order.

Source: Crawley, Cameron & Selva (2016), §14.5, p. 339; classroom calculation.

Sensitivity to the scenario probability

Let \(p\) be the optimistic-scenario probability for both architectures.

\[EU(A)=90p+30(1-p)=30+60p\] \[EU(B)=70p+60(1-p)=60+10p\]

The preference changes at \(p=0.60\):

• \(p<0.60\): choose B.
• \(p>0.60\): choose A.
• \(p=0.60\): equal expected utilities.

• This is a classroom extension of the previous example. Derive 30+60p=60+10p, then 50p=30.
• Ask whether a decision is convincing if plausible probabilities range from 0.4 to 0.8. The preferred alternative changes within that range; better information or a robustness argument would matter.
• The same p is an explicit simplification. The book notes that different chance nodes can have different probabilities.
• Distinguish a probability of an optimistic scenario from the mission-success probability conditioned on that scenario. They are not interchangeable quantities.

Discussion: What if the optimistic probability could plausibly lie between 0.4 and 0.8?

Suggested answer: The preferred alternative changes at p=0.60, so that range crosses the decision threshold. Better probability evidence or a stated robustness preference could materially affect the choice.

Source: Crawley, Cameron & Selva (2016), §14.5, pp. 339–340; classroom sensitivity example.

Where basic decision trees struggle

• Size: decisions and uncertain outcomes multiply the leaves.
• Evaluation effort: estimating each architecture’s outcome under each scenario may require expensive simulation.
• Dependence: one uncertain parameter can affect many decisions and metrics.
• Information structure: choices must use only information available at that point.

Example: an uncertain propellant-to-structure mass ratio changes IMLEO across multiple mission modes.

• The chapter’s mass-ratio example is a hidden, uncontrollable parameter whose effect passes through the nonlinear mass model, not a simple local risk multiplier.
• The authors discuss collapsing all fifteen mission modes into one decision as a way to express the dependency, at the expense of losing the original decision structure.
• Clarify the scope of the book’s independence criticism: simple independent-factor evaluation is restrictive. General decision trees can represent conditional probabilities and dependent results by expanding the histories, but this can be unwieldy. Dependence is not mathematically forbidden in every tree.
• Decision networks relax the tree topology and allow more general connections, as the chapter’s footnote notes. Markov decision processes are mentioned but not developed; architecture coupling can prevent the required decomposition assumptions.
• Ask which tool could expose a hidden shared dependency before constructing a huge tree: a decision DSM is one useful start.

Discussion: Which tool can reveal shared dependencies before building a large tree?

Suggested answer: A decision DSM can expose coupled choices. It does not replace scenario evaluation, but it helps structure the problem and identify where a simple tree may obscure dependence.

Source: Crawley, Cameron & Selva (2016), §14.5, pp. 339–340 and footnote.

What each tool contributes

Tool	Represents	Structures	Simulates / evaluates
Morphological matrix	Decisions and alternatives	No explicit coupling	No
Decision DSM	Decisions and relationships	Coupling and clusters	No
Decision tree	Explicit paths and scenarios	Order and pruning	Some path evaluation and rollback

Viewing evaluated tradespaces requires an appropriate results display.

• These are capabilities of the basic forms, not claims about every software implementation that incorporates them.
• A matrix or tree is visible, but the chapter’s viewing layer means presenting decision-support information derived from structuring and simulation, such as the evaluated tradespace.
• Ask students to assemble a workflow rather than pick a single winning tool: list choices, record couplings, check/evaluate assignments, and inspect results.
• OPM remains useful for representing the functional and physical meaning of the options, especially when students need to explain what an architectural decision changes.

Discussion: How would you combine the chapter’s tools in one workflow?

Suggested answer: List alternatives in a decision representation, use a DSM to expose coupling, generate feasible assignments, evaluate outcomes, and inspect the tradespace or appropriate decision tree. Iterate when the model proves incomplete.

Source: Crawley, Cameron & Selva (2016), §§14.4–14.5, pp. 333–340; §14.7, p. 342.

14.6 What architecture decision support needs

Box 14.1 has six properties. Treat them as reasons to adapt the modeling approach, not excuses to avoid analysis. Source: §14.6 and Box 14.1, pp. 340–342.

Breadth, uncertainty, and ambiguity

1. Breadth versus depth

Explore many different architectures at low fidelity before refining a few designs in detail.

2. Uncertainty and ambiguity

• Uncertainty: outcomes are not known, for example future operational events.
• Ambiguity: a statement or category is fuzzy, for example “easy to maintain.”
• More Monte Carlo samples cannot resolve an undefined requirement.

• These are the first two properties in Box 14.1. A deep model of only one architecture can miss a superior family; a very broad model may miss engineering detail. Model fidelity is a deliberate tradeoff.
• Ask students to classify “the sensor may fail” versus “the product should be intuitive.” The former can motivate an uncertainty model; the latter needs clarification of meaning and evaluation.
• The chapter argues that early ambiguity can make standard probabilistic techniques inadequate or impractical. It does not say Monte Carlo is never useful in architecture.
• Interval analysis and fuzzy sets are examples mentioned in the chapter’s references for cases where precise probabilistic descriptions are not justified. The first action may simply be to clarify stakeholder language.

Discussion: Classify ‘the sensor may fail’ and ‘the product should be intuitive.’

Suggested answer: The first can motivate an uncertainty model. The second requires clarification of the desired experience and how it will be evaluated. More simulation alone does not resolve unclear meaning.

Source: Crawley, Cameron & Selva (2016), Box 14.1, p. 341; reference [28], p. 344.

Variable types and subjective value

3. Variable type

Type	Example
Categorical	Cryogenic or storable propulsion
Discrete integer	Number of crew members
Continuous	A tank dimension

4. Subjectivity: stakeholder value may require elicited utilities, expert judgment, and an explanation of the assessment.

• Architectural choices are often categorical, sometimes discrete, and rarely continuous in the chapter’s characterization. Detailed design has a stronger emphasis on continuous variables.
• Encoding cryogenic as 0 and storable as 1 does not make their numerical difference a meaningful physical distance. Do not interpolate to “fuel 0.4.”
• Subjectivity is not the same as arbitrariness: record whose judgment was used, the evidence, and how an alternative score was produced.
• Multi-attribute utility theory and fuzzy sets are approaches the book mentions. Ask how two stakeholders could agree on mass but disagree on the architecture’s value.

Discussion: Can stakeholders agree on mass and disagree on value?

Suggested answer: Yes. They may value cost, reliability, convenience, or risk differently. Physical metric agreement does not establish common preferences or a unique utility function.

Source: Crawley, Cameron & Selva (2016), Box 14.1, p. 341; references [29]–[30], p. 344.

Objective functions, coupling, and emergence

5. Objective-function form

Low-fidelity architecture models mix equations, lookup tables, and if–then rules to handle diverse alternatives and subjective metrics.

6. Coupling and emergence

Even a few strongly connected decisions can create many combinations and system-level effects.

Choosing the locally best alternative in each row need not produce the best system.

• Explain the three reasons for rule-based metrics given in the box: different architecture types need different evaluation logic; low fidelity motivates heuristics; subjective judgments may be expressed as rules.
• Ask why choosing the lightest individual component is not sufficient. Interfaces, support equipment, and operations can reverse the system-level result.
• The box cautions that strong coupling can defeat methods that rely on separability or a useful Markov structure. This is a reason to examine assumptions, not to declare all dynamic programming impossible.
• Reconnect to emergence in earlier chapters: system value is produced by the interaction of selections, not only the independent quality of the selected parts.

Discussion: Why doesn’t choosing each lightest component guarantee the lightest system?

Suggested answer: Component choices affect interfaces, supporting structure, power, and operation. Additional integration resources can outweigh local savings, so evaluate the assembled architecture.

Source: Crawley, Cameron & Selva (2016), Box 14.1, p. 341.

An interactive architecture-support process

• Let the architect revise boundaries, alternatives, metrics, and assumptions.
• Use knowledge-based rules to encode and explain expert reasoning.
• Preserve traceability from a score back to its evidence and judgments.
• Use computation to reveal options and tradeoffs worth investigating.

The chapter points to Object Process Networks, Architecture Decision Graphs, and VASSAR as specialized approaches.

• Architectural DSSs tend to be more interactive and less automatic because their models are provisional and their values partly subjective.
• At the level of the chapter’s references: Object Process Networks emphasize synthesis/evaluation and simulation; Architecture Decision Graphs emphasize structuring; VASSAR uses rules for architecture value assessment and supports structuring/simulation.
• Object Process Networks are a related meta-language, not simply another name for the OPM notation used in this course. No additional notation is required here.
• Ask what explanation a student would want if a tool rejected their preferred architecture. A useful answer identifies the exact constraint, assumption, or utility judgment rather than displaying an unexplained score.

Discussion: What explanation should a support tool give when rejecting a candidate?

Suggested answer: Identify the violated constraint or the assumptions and preference judgments behind its low score. A useful explanation lets the architect audit and, when justified, revise the model.

Source: Crawley, Cameron & Selva (2016), §14.6, p. 342; reference [31], p. 344.

14.7 Synthesis and practice

Consolidate the chapter with a small formulation exercise and an exit ticket. These activities apply the chapter’s methods to an undergraduate-scale problem. Source: §14.7, p. 342.

Class activity: a campus delivery system

Goal: deliver small parcels between campus buildings.

Decision	Alternatives
Vehicle	Ground robot / aerial drone
Loading	Manual / automated
Handoff	Staffed desk / secure locker

In pairs: propose two constraints, two metrics, and one OPM function-to-form statement. Mark a decision coupling in a DSM.

• Allow about five minutes plus discussion. This is an original classroom exercise, not a book case study.
• Define scope together: parcels, routes, and users must be specified before declaring an architecture feasible. Invite students to state additional assumptions rather than silently invent capabilities.
• A valid OPM-oriented answer identifies an operand and a process that changes its state or location, plus the instrument enabling that process.
• Encourage one logical compatibility rule and one policy or reasonableness rule. The rules depend on the assumed campus system; they are not universal truths about robots or drones.
• Ask teams to say which DSS layer each part of their answer belongs to.

Discussion: Give a complete possible answer for the campus-delivery exercise.

Suggested answer: Assume automated loading requires a compatible ground robot, and unstaffed handoff requires a locker. Compare delivery time and cost per parcel. In OPM terms, Transporting changes Parcel location using Vehicle; vehicle and loading choices are coupled.

Source: Crawley, Cameron & Selva (2016), §§14.2, 14.4–14.6; classroom application.

Activity discussion: one possible model

• Assume the automated loader only mates with the ground robot: automated ⇒ ground.
• Assume unstaffed handoff requires a secure locker: a policy constraint.
• Metrics: delivery time and cost per parcel; track successful delivery as well.
• OPM statement: Transporting changes a Parcel from origin to destination, using a Vehicle as instrument.
• Coupling: vehicle and loading interact through compatibility and delivery time.

• Accept alternative answers with explicit, consistent assumptions. The proposed loader compatibility is a hardware assumption of this toy case, not an inherent prohibition on automated drone loading.
• Explain that “unstaffed” is contextual here; if staffing becomes a decision, add it explicitly rather than hide it in a rule. The staffed desk / secure locker alternatives already carry an assumed operating concept.
• Evaluate the quality of the formulation: clear variable domains, testable constraints, meaningful metrics, and traceable assumptions.
• Ask how the model changes if the campus buys a drone-compatible loader. The constraint changes, so previously excluded combinations must be reconsidered.
• In the OPM statement, the parcel is transformed in location; the vehicle enables the process and is not consumed. Keep object, process, state, and instrument roles distinct.

Discussion: What changes if a compatible automated drone loader becomes available?

Suggested answer: Revise the compatibility rule and reconsider previously excluded combinations. Retain other constraints and re-evaluate performance; a new feasible option is not automatically the preferred one.

Source: Crawley, Cameron & Selva (2016), §§14.2, 14.4–14.6; classroom application.

Chapter 14 Summary

• Formulate an architecture as interconnected decisions, bounded by goals.
• Keep alternatives, feasibility rules, outcome metrics, and preferences explicit.
• Combine representing, structuring, simulating, and viewing.
• Match each tool to the problem’s coupling, scale, uncertainty, and ambiguity.
• Record the evidence and judgments behind each assessment so others can examine the reasoning.

Next: Chapter 15 uses tradespaces to learn about architectural tradeoffs and decision structure.

• Return to the opening learning objectives and ask students for one Apollo example of each layer.
• The chapter’s central claim is not that every architecture choice should be fully automated. A useful decision model helps people understand and explore alternatives.
• Revisit the two numerical levels: 15 feasible mission-mode patterns versus 108 full assignments in our enumeration. This is a useful final check on what each representation includes.
• Preview Chapter 15’s emphasis on learning from a tradespace; Chapter 16 will develop architecture choice and optimization more fully.

Discussion: Give one Apollo example for each decision-support layer.

Suggested answer: Represent fuels as alternatives; structure the LOR and lunar-maneuver dependency; simulate mass and modeled success; view the resulting tradespace. Each layer should retain links to the assumptions that produced it.

Source: Crawley, Cameron & Selva (2016), §14.7, p. 342.

Exit ticket

1. Why can two feasible decisions become infeasible when combined?
2. What information does a blank cell in a constraint DSM provide? Which conclusions would require additional information?
3. Why is the best leaf not necessarily the best architecture when chance nodes exist?
4. Give an example of ambiguity that cannot be fixed by increasing simulation fidelity.

• Expected answer 1: constraints link decisions; EOR=yes with earthLaunch=direct is the Apollo example.
• Expected answer 2: no direct connection of the represented constraint type; other metric couplings and indirect paths may still exist.
• Expected answer 3: a leaf includes an uncontrollable scenario. Average utility at chance nodes, then choose at decision nodes using the correct information order.
• Expected answer 4: an undefined goal such as “easy to maintain.” More detailed simulation cannot supply the missing stakeholder meaning.
• Use responses to decide whether to begin Chapter 15 with more formulation practice or proceed to tradeoff analysis.

Source: Crawley, Cameron & Selva (2016), §§14.2–14.7; classroom review.

Reference and further reading

Crawley, E., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson. Chapter 14, pp. 325–344.

Foundations cited in the chapter:

• Simon: decision-making phases and programmed decisions.
• Zwicky and Steward: morphological analysis and DSMs.
• Keeney and Raiffa: decisions with multiple objectives.

Slide-specific source locations and teaching discussion points appear in the speaker notes.

• The lecture covers all seven sections of Chapter 14, including its worked Apollo case, basic tools, six architectural properties, and summary.
• Further reading as listed in the chapter: Simon, The New Science of Management Decision (1960); Zwicky, Discovery, Invention, Research through the Morphological Approach (1969); Steward, “The Design Structure System” (1981); Keeney and Raiffa, Decisions with Multiple Objectives (1976).
• The numerical enumeration, explicit rocket equation, expected-utility activity, sensitivity calculation, and campus exercise are teaching additions. Source plots and the chapter’s factor model are distinguished where their numerical results do not align.
• For teaching, press S in Reveal.js to open the speaker view. The notes include prompts and expected answers, so students need only the projected material.

Source: Crawley, Cameron & Selva (2016), Chapter 14 and references [16], [22], [24], [26], pp. 325–344.