The Role of the Architect

Systems Architecture · Chapter 9

Aykut C. Satici

Starting Part 3: Creating System Architecture

• Part 2 examined the system as a whole, including its functions, form, and context
• Following Eberhardt Rechtin, the architect specializes in resolving ambiguity, focusing creativity, and simplifying complexity
• The architect coordinates with the design team, finance, marketing, and manufacturing specialists

Tip

Three principal roles: reduce ambiguity, employ creativity, manage complexity.

• Open by naming the risk this chapter heads off: Part 2’s holism emphasis can be misread as “architect = generalist who knows a little about everything”
• Book pushes back, paraphrasing Eberhardt Rechtin: architect is a genuine specialist: in simplifying complexity, resolving ambiguity, focusing creativity
• Negative definition (useful for “super-manager” misconception): architect is not the design team, not the financial controller, not the marketing executive, not the plant manager: must interact with all, but none is the job
• Closing fragment previews chapter structure: reduce ambiguity / employ creativity / manage complexity. This chapter lays the foundation; creativity gets Ch. 11-12, complexity gets Ch. 13

Discussion: Why is defining the problem itself architectural work?

Suggested answer: Different interpretations of stakeholder needs lead to different concepts. Resolving the intended outcome and scope prevents detailed optimization of a system that solves the wrong problem.

The Three Roles of the Architect

Reduce ambiguity

Define the boundaries, goals, and functions of the system.

Employ creativity

Create the concept.

Manage complexity

Choose a decomposition of the system.

These roles involve information: clarifying what is needed, proposing new solutions, and organizing the details of the architecture.

• Unpack the three roles concretely: previous slide only named them
• Reduce ambiguity = defining boundaries/goals/functions (Ch. 2’s Task 1/Task 2, now for a system that doesn’t exist yet)
• Employ creativity = creating the concept (Ch. 7’s function→form mapping, not yet determined)
• Manage complexity = choosing a decomposition (central topic of Ch. 13, echoes Ch. 3’s decomposition/hierarchy tools)
• Unifying lens: all three are modes of working with information: reduce ambiguity = identify needed info; creativity = add new info; manage complexity = handle the explosion of info once concept is chosen (own slide shortly)

Discussion: Can the architect complete the three roles once, in a fixed order?

Suggested answer: No. New concepts expose ambiguity, and decomposition exposes feasibility issues that may require revised goals or concepts. The roles interact throughout development.

9.2 Ambiguity and the Role of the Architect

Before the Architect Is Engaged

• There has been an “upstream process”: full of ambiguity, issues, opportunities, and needs for the new system
• What are the high-priority needs vs. the “nice to haves”? What regulations apply? How is manufacturing competence aligned with the envisioned product?

The architect clarifies the upstream inputs, defines system boundaries, and establishes concrete goals.

• Set the scene: before the architect is ever engaged, an “upstream process” is already running: loosely-defined issues, opportunities, needs
• Nobody designed or controls this upstream process (returns strongly in Box 9.2): it’s inherently messy
• Flavor of the actual questions the architect walks into: high-priority needs vs. “nice to haves”? Which regulations apply and how? How does manufacturing competence align with the envisioned product?: none come with clean answers
• Architect’s core job at this interface (have students write it down verbatim): drives ambiguity out of the upstream process by creating boundaries and concretizing goals: turns fuzzy into workable/bounded. Thesis for the rest of 9.2

Suggested answer: Determine priority by identifying beneficiaries, constraints, and the consequences of leaving a need unmet, then agree on measurable goals. Establish the relevant regulatory scope with the responsible specialists rather than assuming every rule applies. Compare proposed manufacturing demands with demonstrated organizational and supplier capabilities. These questions require evidence and stakeholder decisions; their answer is not whatever the architect personally prefers. Record unresolved assumptions so they can be tested.

Inputs to Architectural Decisions

• Interpreting corporate and functional strategies, competitive marketing analyses
• Listening to users, beneficiaries, customers, or their representatives
• Considering the competence of the enterprise and its supply chain
• Considering operations and the operational environment of the system
• Infusing technology where appropriate
• Interpreting regulatory and pre-regulatory influences
• Recommending standards, frameworks, and best practice
• Developing goals for the system based on the upstream influences

• The concrete, actionable version of “driving ambiguity out”: this is literally what the architect spends time doing
• Interpreting corporate/functional strategies + competitive marketing analyses → translating business intent into something concrete enough to design against
• Listening to users/beneficiaries/customers → direct human-input side (full treatment in Ch. 11)
• Considering enterprise/supply-chain competence → honesty about what can actually be built, not just what’s ideal
• Considering operations/operational environment → how the system will actually be used/maintained once fielded
• Infusing technology where appropriate → new capability only where it serves goals, not for its own sake
• Interpreting regulatory influences + recommending standards/frameworks → navigating external rules and conventions
• Capstone: developing goals from all these upstream influences: synthesizing everything into a concrete set the design team can work from. Compressed preview of Ch. 10

Discussion: What should happen when two inputs to the architect conflict?

Suggested answer: Make the conflict explicit, identify the stakeholders and evidence behind each input, and resolve priorities or constraints. Silently selecting one hides an architectural assumption.

From Goals to Concept to Complexity

Employing creativity: develop alternative concepts that meet the goals. Compare performance and other criteria, examine tradeoffs, and select a concept with a possible backup. Consider the full lifecycle and potential failure modes.

Managing complexity: develop the selected concept through decomposition, allocation of functions to form, and interface definition. Coordinate subsystems, assess flexibility, and manage changes as the product develops.

• Advances past “reducing ambiguity” into the other two roles, which follow naturally once goals exist
• Once goals are defined: creative task = defining a concept
• Blunt, memorable formulation: a good concept doesn’t ensure success, but a bad one almost certainly dooms the system: concept selection is asymmetric risk
• Concrete tasks: propose multiple concept options (don’t settle for the first idea), identify key metrics/drivers, run highest-level trades, select a concept (+ maybe a backup), think holistically about the full lifecycle, anticipate failure modes
• Pivot: counter-intuitive dynamic: at the moment a concept is chosen, information available is small: but it explodes rapidly right after (external interfaces, first-level design/decomposition, downstream considerations)
• Managing that explosion = the architect’s third role, managing complexity: decompose form/function, allocate functionality to form, define interfaces, configure subsystems, balance flexibility vs. optimality, control product evolution: the toolkit Ch. 13 develops in full

Discussion: How can a concept reveal that a goal needs revision?

Suggested answer: A candidate may show that the specified performance and resources cannot coexist. Revisit assumptions, alternative concepts, and stakeholder priorities before declaring the goal impossible.

Box 9.1 · Principle of the Role of the Architect

“Some single mind must master, else there will be no agreement in anything.”: Abraham Lincoln

“Timing has a whole bunch to do with the outcome of a rain dance.”: Cowboy saying

• The architect resolves ambiguity, focuses concept development, and organizes complexity to help the system deliver value
• Given the ambiguity and complexity in most systems, it’s often desirable to have architecture created by a single individual or a small group
• The architect considers the whole system while concentrating on the decisions most important to its success. The method should suit the problem

• Chapter’s first formally named principle: unpack both quotes, they hit different aspects of the role
• Lincoln quote (“some single mind must master…”) → second bullet: given typical ambiguity/complexity, architecture is often best created by a single individual or small group, not committee: someone must hold the whole picture and make final calls
• Cowboy saying (rain dance timing) → more playful, but real point: judgment and sequencing: when to commit matters as much as the decision itself
• Restate role as a formal principle: resolve ambiguity, focus creativity, simplify complexity → elegant systems that create value/competitive advantage (callback to Boeing/BlackBerry, Ch. 1)
• Methodological close: architect keeps a holistic view but focuses on the few critical issues at any moment (echo of Ch. 2’s Principle of Focus): and doesn’t lock into one fixed method, adopts whatever framework fits

Discussion: Why should an architect resist optimizing each subsystem independently?

Suggested answer: Subsystem choices interact through interfaces and shared resources. The architect must preserve the whole system’s intent and manage compromises that local optimization can miss.

Two Kinds of Ambiguity

Ambiguity is composed of two ideas: fuzziness and uncertainty. In common usage it also connotes incorrect, missing, or conflicting information.

Fuzziness

Occurs when an event or state is subject to multiple interpretations. “Smooth finish” or “good gas mileage” mean different things to different customers: fuzziness is influenced by context.

Uncertainty

Occurs when an event’s outcome is unclear or in doubt. We can articulate the possible states, but not which one will occur: like a coin flip.

• Chapter’s most rigorous contribution: pin down exactly what “ambiguity” means, not a vague catch-all
• Strictly: ambiguity = fuzziness + uncertainty; everyday usage also stretches it to mean incorrect/missing/conflicting info (next slide’s precise notation)
• Fuzziness (more subtle): event/state subject to multiple valid interpretations: category boundaries unclear, not the answer unknown
  • Book’s example: is a color “blue” or “purple”: one fixed wavelength, but the label is fuzzy, observer-dependent
  • Customer requirements: “smooth finish,” “good gas mileage” mean different things to different people; North America vs. Europe have different baselines for “good” gas mileage
• Uncertainty (contrast): event’s outcome unclear/in doubt, but possible states are well-defined: we just don’t know which occurs (coin flip: heads/tails both well-defined, outcome unknown)
• Clean distinction: fuzziness = ambiguity of categories/interpretation; uncertainty = ambiguity of which known outcome occurs

Discussion: How does uncertainty differ from unclear meaning?

Suggested answer: Uncertainty concerns which outcome or parameter value applies. Unclear meaning concerns what is being requested or represented. More simulation may reduce the former while leaving the latter unresolved.

The (X, Y, Z) Shorthand for Compounding Ambiguity

Where X, Y, Z are the true inputs to the system:

• Unknown information (X, __, Z): information is under-determined or unavailable. A known unknown is knowing you lack it (a competitor’s plans); an unknown unknown is not even knowing you lack it (a brand-new competitor appears)
• Conflicting information (X, D, Z and X, B, Z): two or more sources offer opposing indications: the problem is over-determined
• False information (F, Y, Z): you believe you have complete information, but some of it is simply wrong

• Book’s notational device for three additional, compounding forms of ambiguity: useful for diagnosing what kind of informational problem you’re facing
• Setup: true inputs to a system = triple (X, Y, Z), which if known correctly/completely would fully specify the situation
• Unknown information (X, __, Z): one input under-determined/unavailable, a genuine gap, extremely common early in PDP
  • Known unknown: aware of the gap (don’t know if a competitor will launch a rival product): can budget effort to investigate
  • Unknown unknown: don’t even know you’re missing it (a brand-new, unconsidered competitor appears): more dangerous
• Conflicting information: two competing triples (X, D, Z) and (X, B, Z): sources disagree on the middle input, problem is over-determined. Example: one source says regulation will affect the product, another says it won’t
• False information (F, Y, Z): you believe your info is complete, but one piece is silently wrong. Example: told a supplier will be ready by a date, but they have no plan to be
• Why false info is worse than unknown: with an unknown, you know to be cautious; with false info, you proceed with unwarranted confidence

Discussion: Does naming several sources of ambiguity make them independent?

Suggested answer: No. Unclear goals can obscure relevant variables, and uncertain context can alter what goals mean. The shorthand organizes the problem; it is not automatically a quantitative probability model.

Classifying Ambiguity · Try It First

Classify each statement as fuzzy, uncertain, missing, conflicting, or false. More than one category may apply.

1. Will it be a boy or a girl?
2. Produce a low-cost, high-quality product.
3. Every fourth year is a leap year.
4. Please make me a smooth cover for this phone.
5. Make sure we meet your quarterly goals.

• Ask students to commit to a classification before showing the next slide. The book deliberately allows overlapping categories.
• The first statement reflects the book’s illustration of uncertainty and category ambiguity; these labels are not an exhaustive description of human sex or gender.

Classifying Ambiguity · Discuss the Answers

Statement	Classification	Why
Boy or girl?	Uncertain; potentially fuzzy	Outcome unknown; categories may be interpreted differently.
Low cost, high quality	Fuzzy; possibly conflicting and unknown	No thresholds, possible trade-off, feasibility not established.
Every fourth year is a leap year	False	Gregorian century years are exceptions unless divisible by 400.
Smooth phone cover	Fuzzy	“Smooth” lacks an agreed measure or reference.
Meet quarterly goals	Missing; possibly conflicting	Goals or ownership may be unspecified or disputed.

Adapted from the Chapter 9 ambiguity exercise in Crawley, Cameron & Selva (2016).

• Let students explain the reason, not merely recite the labels. “Low cost, high quality” is not inherently contradictory until a feasible trade space is examined.
• The leap-year rule is false without the Gregorian century exception: 1900 was not a leap year; 2000 was.
• Ambiguity in upstream inputs can combine fuzziness, uncertainty, missing information, conflict, and error.

Box 9.2 · Principle of Ambiguity

“The best-laid schemes o’ mice an’ men / Gang aft agley [often go awry]”: Robert Burns

• The early phase of a system design is characterized by great ambiguity: the architect must resolve it to produce (and continuously update) goals for the team
• Development is possible only with the acceptance of uncertainty
• No one designs or rigorously controls the upstream process: there should be no expectation of unambiguity
• Uncertainty can create opportunities; it is not always bad
• Uncertainties should be identified and prioritized so they can be managed

• Robert Burns quote (“best-laid schemes… gang aft agley”): sets the tenor: plans routinely go sideways, architect must operate productively despite that
• Five bullets as a connected argument, not independent facts:
  • Early design phase = great ambiguity; architect’s job to resolve enough to produce and continuously update usable goals: ongoing, not one-time
  • Development is only possible with acceptance of uncertainty: insisting on perfect certainty first is a decision to never start
  • No one designs/controls the upstream process (corrects a misconception): no expectation of unambiguity; waiting for a clean start is a losing strategy
  • Uncertainty can create opportunities, not just risk: an unresolved situation sometimes has room for a better solution than a rigid brief
  • → Prescription: don’t try to eliminate uncertainties (impossible) or ignore them (dangerous): identify and prioritize them so the most consequential get managed deliberately (echo of Ch. 2’s Principle of Focus)

Discussion: How would you reduce ambiguity in ‘make the service convenient’?

Suggested answer: Identify users and situations, then agree on observable outcomes such as access time or required steps. Test whether those measures reflect the intended experience before setting targets.

Deliverables · Intent and Concept

Deliverables are the results of architecting; tasks are the work used to produce them.

Deliverable	What it must contain
Goals	Clear, complete, consistent, and attainable goals (the book uses 80–90% confidence), emphasizing function.
Context	The broader and whole-product setting, including legal requirements and standards.
Concept	A concept for the system and a concept of operations, including contingency and emergency operation.

Condensed from Crawley, Cameron & Selva (2016), “Deliverables of the Architect,” §9.2.

• Goals, context, and concept define what the system is for and the assumptions under which it will operate.
• These are reviewable outputs, not steps on a task list. The confidence range comes from the book; it is not a guarantee of future performance.

Deliverables · Architecture and Execution

Deliverable	What it must contain
Function	At least two levels: primary and secondary external functions; internal process/operand flow; non-idealities; supporting and interface processes; a process to ensure the functional decomposition is followed.
Form	Two levels of form decomposition, function-to-form allocation, and the structure of form.
Interfaces	Details of every external interface and a process for interface control.
Execution	Developmental cost, schedule, and risk estimates, plus design and implementation plans.

Tip

Trace a need through goals, concept, functions, form, and interfaces. Gaps in that chain expose unfinished architectural work.

Condensed from Crawley, Cameron & Selva (2016), “Deliverables of the Architect,” §9.2.

• Primary and secondary functions both matter. The internal flow must include non-idealities, supporting processes, and interface processes, not just the ideal value pathway.
• Form is decomposed to two levels and allocated to function. Interface control must continue as teams develop details.
• Table 8.1 leads to all these deliverables except the project-oriented cost, schedule, risk, and plans.
• OPM can express the architecture precisely; present the information in a form the organization can understand and use.

Discussion: What should a reviewer be able to trace through architectural deliverables?

Suggested answer: Stakeholder needs to goals, goals to the chosen concept, and concept to allocated functions and interfaces. Assumptions and rejected alternatives explain the decisions.

Section 9.2 Summary

• The role of the architect includes reducing ambiguity, employing creativity, and managing complexity
• Architecture sits astride upstream activities (before) and downstream activities (after): ambiguity arises from both
• In practice, ambiguity is a combination of fuzzy, uncertain, missing, conflicting, and incorrect information
• The principal job of the architect at the interface to the upstream (the “fuzzy front end”) is to drive as much of this ambiguity from the system as possible

• Review before Section 9.3: students should recite the three roles from memory
• Architecture sits “astride” upstream and downstream: literally straddling the boundary, ambiguity flowing in from both (upstream: strategy, fuzzy needs; downstream: manufacturing/operational questions)
• Should be comfortable with the ambiguity taxonomy: fuzziness + uncertainty (core ideas), missing/conflicting/incorrect info (practical manifestations, the (X,Y,Z) shorthand)
• Restate the section’s thesis with memorable vocabulary: the upstream interface = the “fuzzy front end” of development (Zhang and Doll): architect’s job there is to drive out as much ambiguity as possible, never “all of it” (Box 9.2)

Discussion: When should unresolved ambiguity be documented rather than guessed away?

Suggested answer: When evidence or stakeholder agreement is still missing. Record its consequences, owner, and a plan to resolve it, especially before decisions that would be costly to reverse.

9.3 The Product Development Process

What Is a PDP?

Nearly every large firm has a product development process (PDP): capturing methodology, terminology, phases, milestones, and tasks/outputs.

• A principal advantage: it’s a tool for reducing ambiguity by defining tasks and responsibilities
• A PDP can leave upstream uncertainty unresolved. Check that its assumptions match the information actually available
• A complete PDP covers the product’s life from initial idea through retirement of the last instance

• Define the object of study: PDP = internal methodology nearly every large firm has: terminology, phases, milestones, tasks/outputs
• Why it matters for an architect: principal advantage is reducing ambiguity by defining tasks/responsibilities: the Section 9.2 role, partially automated by process
• Caution: easy trap: tempting to think a well-defined PDP resolves upstream ambiguity automatically: only partially true. A rigid-looking process with clean gates can create false confidence that strategy/market/needs/tech are well-understood when they’re still deeply ambiguous underneath
• The intended scope extends from the initial idea through retirement. The four examples cover different portions of that lifecycle.

Discussion: Why study a PDP when we want to design a product?

Suggested answer: The development process determines when information arrives, who decides, and when commitments become difficult to change. Architecture must fit and inform that process.

Figure 9.1 · NASA’s PDP

Includes some of the fuzzy front end (feasibility, approval, requirements) and includes operations: since NASA is usually the operator of its own products. Very traceability- and review-heavy, reflecting low-volume, high-cost, high-perceived-risk systems. Source: Crawley, Cameron & Selva (2016), Fig. 9.1.

• First of four practical PDP case studies: comparative frame for all four: what upstream/downstream activities does it include, what does that reveal about priorities?
• NASA’s PDP (8 phases, feasibility → operations): includes some fuzzy front end (feasibility, approval, requirements as early phases); includes operations as an explicit final phase: NASA is usually the long-term operator of its own products
• Conspicuously missing: upstream influences barely represented: just a single feasibility question where you’d expect rich market analysis. NASA’s “market analysis” is really budget decisions, public value, science goals, industrial base: not commercial market research. No explicit separate technology-development process shown
• Heavy stage-gate/review emphasis (SRR, PDR, CDR…) reflects NASA’s reality: low-volume, extremely expensive space systems that can’t be tested in their actual operating environment first, high perceived cost of public (especially human spaceflight) failure
• This traceability-heavy character has been both praised (enabled the celebrated Hubble mirror repair) and criticized (Columbia accident board questioned whether it surfaced known risks in time)

Suggested answer: The displayed process extends from feasibility and requirements through reviews, development, and operations. Its explicit operational endpoint and review structure suggest concern for mission delivery, traceability, and lifecycle accountability. Compare these emphases with manufacturing preparation, customer input, certification, and iteration in the other examples. An omitted activity is not proof that the organization never performs it; the figure is a historical selected view of a process.

Figure 9.2 · Helicopter Inc.’s PDP

Compared to NASA, iteration loops stand out: even in aerospace, iteration is inevitable and not at odds with a stage-gated process. The process centers on FAA certification, itself an instrument of the more important process: sales. Source: Crawley, Cameron & Selva (2016), Fig. 9.2.

• Second case study: “Helicopter Inc.” (masked name): military/civilian helicopters, mostly government revenue, heavily regulated market
• Compared to NASA’s clean, linear-looking process: explicit iteration loops stand out (dashed feedback arrows around detail design, fabrication/code, system testing)
• Key observation: even in a NASA-like aerospace environment, iteration is inevitable and not at odds with an overall stage-gated process: the two coexist
• Process’s real center of gravity = FAA certification: but push one level deeper: certification isn’t the goal, it’s an instrument of the more important process, sales (can’t legally sell/operate without it)
• Open question the book poses: diagram includes product feedback but doesn’t show customers “up front”: does Helicopter Inc. conceive first then test in market, or gather needs first then design? From the diagram alone, customer input is present somewhere, folded into the mission statement, but its exact role/timing isn’t visible

Suggested answer: The diagram alone does not establish when customer needs were gathered or how strongly they shaped the mission statement. Product-feedback arrows show some learning, but cannot tell us whether early concept choices were market-led or technology-led. Ask for the mission-statement inputs, review evidence, and examples of changes caused by customer feedback. Explicit iteration and certification emphasis are observable features; the exact upstream customer process remains an inference to investigate.

Figure 9.3 · Camera Co.’s PDP

• Camera Co.’s PDP explicitly shows upstream processes: strategy, voice of the customer, and R&D: all part of “conceiving”
• Manufacturing process development precedes product development: Camera Co. is a process-driven industry
• Raises a question: does the architect’s role in reducing manufacturing ambiguity matter more than innovation, given a stable customer base?

• Third case study: “Camera Co.” (masked): film/cameras, amateur and professional
• Contrast: explicitly shows upstream activities (business strategy, voice of customer, R&D) all folded into “conceiving”: unlike NASA’s/Helicopter Inc.’s under-represented upstream
• Distinctive feature: manufacturing process development precedes product development: opposite of the default assumption. Camera Co. is a process-driven industry: how it can be manufactured shapes what gets designed
• Discussion questions to pose:
  • Camera Co. is often seen as R&D-driven, yet voice-of-customer notionally precedes R&D/tech stream in this diagram: accurate, or aspirational (nudging a tech-focused company toward customer-driven)?
  • Market competition: distributed/diverse, unlike NASA’s unique-customer government relationship or Helicopter Inc.’s certification-gated market
  • → Open question: given a stable, loyal customer base, is the architect’s role in reducing manufacturing-quality ambiguity more valuable here than driving innovation? No single right answer: the point is reasoning about what a PDP’s structure reveals about org priorities

Suggested answer: The ordering may represent actual practice, an intended reform, or a simplified presentation; the diagram cannot decide which. Evidence would include project histories, decision records, and whether customer findings changed R&D priorities. In a stable market with costly process failures, reducing manufacturing ambiguity can create more near-term value than another feature. A changing market can reverse that priority. Both innovation and manufacturability matter, and a loyal customer base does not guarantee that its needs or competing technologies will remain stable.

Figure 9.4 · An Agile PDP

Agile uses iterative, incremental development, with teams revising requirements and solutions as they learn. The example illustrates a software development process. Source: Crawley, Cameron & Selva (2016), Fig. 9.4.

• Fourth and final case study, Agile, different philosophy, not just another industry’s flavor of stage-gates
• Definition: iterative/incremental development, collaborative teams evolve requirements and solutions together, evolutionary rather than fully-specify-then-execute
• Honest history: origins in rapid prototyping of software for small/medium applications, where iteration is cheap. Emphasizes close interaction among people building working code over heavy upfront docs/negotiation/planning (diagram’s overlapping developer/interaction-designer tracks)
• Honest caveat: beyond software, Agile has been used, with mixed success, to “shake up” far more capital-intensive, longer-lifecycle industries, where its founding assumptions (cheap iteration, low cost of change) may not hold. Be an educated consumer: think critically about in what contexts Agile is appropriate, don’t assume software popularity transfers to aerospace hardware

Discussion: Does iteration eliminate the need for architectural guidance?

Suggested answer: No. Iteration needs shared intent and interface assumptions so increments can combine coherently. Feedback may revise the architecture, but does not replace system-level reasoning.

Comparing the Four PDPs

Are differences between PDPs superficial, or substantial? Some observed differences:

• Existence/number of phases and phase exit criteria
• Existence/number of design reviews, timing for committing capital
• Requirements “enforcement,” degree of customer input/feedback/aftermarket integration
• Degree of explicit/implicit iteration, amount of prototyping
• Internal testing/validation effort, importance of traceability, timing of supplier involvement

Tip

Many factors could drive real differences: hardware vs. software, existing vs. new product, standalone vs. platform, production volume, capital intensity, technology push vs. market pull.

• Step back and synthesize across all four case studies: the analytical move the book wants practiced, not just four admired diagrams
• Central question: are the differences among these four PDPs superficial or substantial?
• Observed differences: number/existence of phases + how rigorously exit criteria enforced; number of formal reviews + when capital commits; how strictly requirements are enforced + customer input/feedback/aftermarket integration; explicit vs. implicit iteration + prototyping amount; internal testing/validation effort, traceability importance, supplier-involvement timing
• Deeper diagnostic question: what factors could drive real differences: hardware vs. software, existing vs. new product, standalone vs. platform, production volume, capital intensity, technology-push vs. market-pull
• Book’s conclusion (next slide builds toward it): despite surface differences, there’s enormous common underlying structure: motivates building a single Generic PDP

Suggested answer: Both kinds of differences occur. Renaming phases or drawing an iteration loop differently can be superficial; changing the evidence required before capital commitment, the timing of supplier input, or the authority to reject a design is substantial. Map each process to common conceiving, designing, implementing, and operating activities, then compare actual decisions, feedback, and deliverables. This preserves the generic structure without pretending that all organizations face the same risks or economics.

Figure 9.5 · The Generic PDP

Four common activity groups: conceiving, designing, implementing, operating: a checklist, not a stage-gate process. The architect’s primary domain sits in “conceive,” but must move relevant downstream information back into the architecting phase. Source: Crawley, Cameron & Selva (2016), Fig. 9.5.

• Payoff of the comparative exercise: anchors the rest of the chapter
• Despite real differences among the four case studies, there’s a large body of common effective practice: codified as the Generic PDP: four activity groups: conceiving, designing, implementing, operating
• Crucial framing (stated at the top, worth repeating): this represents activities, not a sequence of stage-gates: NOT “first conceive, then design, then implement, then operate” in strict linear order (that’s the flawed linear representation the next slide criticizes)
• What’s in each group:
  • Conceiving: strategy, functional strategies, customer needs, segments, competitors, technology, regulation, scope/plan, mission, conceptual design: driven by market needs and tech availability
  • Designing: preliminary/detailed design, requirements definition/elaboration, model development, flow-down, decomposition, interface control: converts concept into the info object defining what’s to be implemented
  • Implementing: sourcing, element creation, integration, testing, positioning, certification: converts design into reality; deliberately bundles software coding + hardware manufacturing + systems integration under one term
  • Operating: sales, distribution, logistics, support, maintenance/repair/overhaul, upgrades, product improvement, platform expansion, retirement
• Visually important: “Primary Domain of the Architect” band sits under conceiving, but a “Downstream influences” arrow feeds back into it: architect must move relevant downstream info back into the conceiving phase, not architect in isolation (developed further in Ch. 10)

Discussion: Are conceiving, designing, implementing, and operating four strict consecutive gates?

Suggested answer: They are activity groups. Information and work can overlap and feed backward; representing them as a rigid sequence can hide necessary learning and coordination.

Figure 9.5 · Read the Generic PDP

The four groups name activities, not consecutive gates.

Activity group	Representative work	Main output
Conceive	Needs, goals, concepts, architecture, plans	A product direction and architectural commitments
Design	Requirements, models, decomposition, interface control	Information defining what to implement
Implement	Sourcing, creating elements, integration, testing	A working product or system
Operate	Delivery, support, maintenance, upgrades, retirement	Value in use and learning for future products

The architect works primarily in conceiving, while design, implementation, and operation send decision-relevant information back upstream.

Readable summary of Crawley, Cameron & Selva (2016), Fig. 9.5 and §9.3.

• Use this view after the book figure so students can read its four groups and the main result of each.
• “Implement” deliberately covers software coding, hardware manufacture, and system integration. Operation includes support and ends in retirement.
• The diagram is not a mandated stage-gate schedule. The reverse arrow carries downstream influences into architecting.

Which Downstream Information Belongs Upstream?

Figure 9.5 sends downstream information back to the architect. The difficult part is deciding which information can change an architectural choice.

Maintenance concern	Architectural question
Worn parts must be accessible	Does a candidate layout allow replacement without dismantling unrelated modules?
Failures must be diagnosable	Does a candidate architecture expose the states, interfaces, or test points needed to locate faults?
Worn parts should be visibly marked	Can this be handled during detailed design, or does it affect the proposed architecture?

Tip

Bring an issue upstream when it distinguishes concepts or changes module boundaries, interfaces, or goals. Record the rest for detailed design.

Worked interpretation of the repairability example in Crawley, Cameron & Selva (2016), §9.3.

• The book notes that constraints are plentiful; deciding which ones meaningfully differentiate architectures is harder.
• Its repairability example includes differently colored, accessible, and easily diagnosed wearing parts. The table turns those into questions for comparing candidate architectures, rather than asserting one universal solution.
• This selection problem returns in Part 4.

Limits of a Linear Process Diagram

A linear process diagram can hide iteration and feedback. It can also suggest that work progresses evenly through stages, or that passing a gate proves design maturity. Check the evidence behind each review decision.

• The Generic PDP is a checklist of activities that appear in complete PDPs, not a mandated sequence
• “Implementing” deliberately includes coding software, manufacturing hardware, and integrating into systems
• “Operating” includes support and release of future product instances: ending in retirement

• Explain the limits of representing design as a linear sequence:
• Three failure modes of linear diagrams:
  • Fail to represent iterations/feedback (the loops explicit in Helicopter Inc.’s PDP)
  • Presume a linear flow of time/effort across stages, when real projects rarely proceed cleanly
  • Most operationally dangerous: can mask a design’s immaturity when gate criteria are compromised: a project can nominally “pass” a gate on paper while the underlying work isn’t ready, with no visual signal
• Restate intended use: the Generic PDP is a checklist of activities in complete PDPs, not a mandated order
• Deliberate word choices: “implementing” bundles software coding + hardware manufacturing + systems integration under one term; “operating” includes ongoing support of existing instances and release of future ones, ending in retirement (“lust to dust”)

Discussion: What problem does a strictly linear PDP picture conceal?

Suggested answer: Downstream learning can change upstream requirements and concepts. A diagram without feedback makes those revisions look exceptional even when they are essential to development.

Section 9.3.1 Summary

• Nearly every large firm has an internal PDP: a tool for reducing ambiguity, but one that can mislead if it presumes more certainty than is actually present
• Comparing PDPs across NASA, Helicopter Inc., Camera Co., and Agile reveals many superficial differences, but real underlying similarities
• The Generic PDP codifies this common practice as four activity groups: conceive, design, implement, operate: deliberately not a stage-gate process

• Review before the Global PDP: the chapter’s final major move
• A PDP clarifies tasks and responsibilities, but it can create false confidence if it treats uncertain inputs as settled.
• Students should name all four case studies and their distinguishing priorities: NASA (traceability/review-heavy, low-volume high-cost high-perceived-risk systems), Helicopter Inc. (iteration loops, certification-as-instrument-of-sales), Camera Co. (manufacturing precedes product development), Agile (iterative/incremental, low cost-of-change)
• Hold onto the Generic PDP, conceive/design/implement/operate, as the unifying, non-sequential checklist underneath all four. Sets up the Global PDP

Discussion: How can different company PDPs be compared fairly?

Suggested answer: Map their activities to common purposes, then compare decisions, evidence, feedback, and commitments. Similar phase names can conceal different practice, and different names can describe similar work.

9.3.2 The Global PDP

Building the Global PDP

• To further support comparison across PDPs, we construct an extended baseline: the Global PDP, in three nested views
• Level 1 centers on the architecture of the product, function and form, as a reflection of product goals, themselves set to respond to market/stakeholder needs
• The architect answers the canonical W Questions: why, what, how, where, when, who, how much

Tip

Quo is the shared Indo-European root of these words across languages: French qui/quoi/quand, Hindi kab/kya/kyon, and the seven circumstances of the ancient Greek rhetorician Hermagoras.

• Chapter’s most ambitious construct: the Global PDP, three progressively broader nested views (this slide = Level 1; next two = Levels 2 and 3)
• Level 1 centers on the product’s architecture: function and form (Ch. 2/4/5 vocabulary): as a reflection of product goals, set in response to market/stakeholder needs
• Architecture (form+function) sits at the literal center of the framework, since it’s what everything else exists to produce
• “W Questions”: why, what, how, where, when, who, how much
• Etymological color: all trace to Indo-European root quo: French (qui/quoi/quand/combien/ou/comment/pourquoi), Hindi (kab/kya/kyon/kitne/kisne/kahan)
• Greek rhetorician Hermagoras: seven circumstances (quis, quid, quando, ubi, cur, quem ad modum, quibus adminiculis) = same who/what/when/where/why/how/by-what-means structure, ~2000 years ago
• Implication: this cross-linguistic, cross-era recurrence signals the question set captures something fundamental about how humans interrogate any situation: an architect needs to understand all of these attributes well

Discussion: Why include the enterprise when modeling the development process?

Suggested answer: Strategy, suppliers, resources, and channels constrain which product concepts can be realized. A product-only view can omit the system that must actually develop and sustain it.

Figure 9.6 · Level 1: The Holistic Framework

Architecture, form and function, sits at the center of the framework. Interactions are two-directional; flow from left to right is not implied. Source: Crawley, Cameron & Selva (2016), Fig. 9.6.

• Direct visual realization of the W Questions: trace across the seven columns:
  • why → need/opportunity: the reason the system is built
  • what → goals/performance: what it accomplishes
  • how → function/interaction: how it acts
  • where → form/structure: the elements (form answers “where” because form exists and has location)
  • when → behavior/dynamics: when things occur
  • who → operator/user
  • how much → cost/expense
• Two callouts head off wrong readings: interactions are two-directional (double-headed arrows); left-to-right column order does not imply flow direction: same non-sequential/checklist framing as the Generic PDP
• Architecture (form=where + function=how) sits at the literal center, both geometrically and conceptually: everything else (need, goals, behavior, users, cost) surrounds and relates back to it

Discussion: What does the holistic view add beyond the product architecture?

Suggested answer: It places the product within the processes and organizations that conceive, develop, and operate it. These relationships expose constraints and feedback that product components alone cannot show.

Figure 9.7 · Level 2: Design and Implementation in Parallel

Moving up a layer: the design process and implementation process each get their own instantiation of the W Questions. The design process has its own form too: notably design tools, which shape and constrain the system form that’s achievable. Source: Crawley, Cameron & Selva (2016), Fig. 9.7.

• Level 2: adds two more full applications of the same seven W Questions: one for the design process, one for the implementation process: running in parallel alongside Level 1’s “conceiving” row (three horizontal rows: Design process / Conceiving the product and operations / Implement process)
• Design tools are part of the design process’s form. A straightedge and a French curve support different shapes, illustrating how tools influence the available design choices.
• Automotive example: many automakers split non-recurring engineering (NRE) design costs evenly across platform variants launched the same year/volume: not part of any technical evaluation, wouldn’t show up in a stage-gate review, but clearly part of the Generic/Global PDP because it materially affects whether a variant can economically deliver value
• Implementation process similarly has its own capabilities/limitations the architect must factor in: existing manufacturing/coding capability constrains what can be built regardless of the paper design
• Practical use: critically evaluate any PDP or new design method against the 21 implicit questions (3 rows × 7 W Questions): few methods answer all 21; the value is seeing which areas a framework is strongest in. Example: Lean began from Toyota Production System studies (manufacturing cost/quality), moved upstream to design-for-lean-manufacturing, and (more controversially) has also been applied to the design process itself: far removed from Lean’s original intent

Discussion: Why coordinate design and implementation planning in parallel?

Suggested answer: Implementation capabilities and constraints can invalidate a design choice. Early coordination reveals tooling, supplier, and integration issues before the design is difficult to change.

Figure 9.7 · Product and Design Questions

Each row of the Global PDP answers the same seven questions. The first four reveal intent, method, and form:

View	Why	What	How	Where
Product	Customer, corporate, societal needs	Product goals	Product function	Product form
Design process	Customer, corporate, societal needs	Design goals	Process methods	Design tools
Implementation	Customer, corporate, societal needs	Implementation goals	Process flow	Implementation tools

Design tools and implementation tools are themselves form. Their capabilities can constrain which product form is achievable.

Condensed from Crawley, Cameron & Selva (2016), Fig. 9.7. Rows summarize the diagram; the causal links run in both directions.

• Compare the three horizontal bands in Figure 9.7 rather than tracing every arrow at once.
• “Why” is the need or upstream commitment motivating each activity; exact influences can cross rows. The figure is a holistic view, not a one-way sequence.

Figure 9.7 · Timing, People, and Cost

The remaining questions expose constraints that a product-only picture can miss:

View	When	Who	How much
Product	Product behavior	Product operator	Operating costs
Design process	Design schedule	Design team	Design costs
Implementation	Implementation schedule	Implementation team	Implementation costs

Tip

Three views × seven questions = 21 checks. A development method may answer some well and leave others implicit.

Condensed from Crawley, Cameron & Selva (2016), Fig. 9.7 and accompanying discussion.

• A design choice may look attractive technically but fail under design-cost policy, schedule, team capability, or implementation costs.
• The book’s automotive example shows how allocating non-recurring engineering costs across platform variants can affect whether a concept delivers value.
• Ask students which of the 21 questions an Agile sprint board answers clearly, and which need another representation.

Figure 9.8 · Level 3: The Enterprise Context

The broadest nested view: the firm’s PDP inside the enterprise boundary (R&D and corporate functions mostly upstream; PR, sales, distribution mostly downstream), plus external actors and attributes: capital, competition, regulation: that affect the enterprise. Source: Crawley, Cameron & Selva (2016), Fig. 9.8.

• Level 3, the broadest view: whole PDP (conceive/design/implement/operate, overlapping ellipses, architecture at the center intersection) placed inside a larger enterprise boundary
• Firm functions positioned by upstream/downstream role: R&D and corporate functions primarily upstream (feed conceiving); PR/sales/distribution primarily downstream (connected to operating); some (human skills, information systems, engineering tools) permeate the whole diagram; others (corporate strategy) play multiple roles at once
• Outside the enterprise boundary: an explicitly incomplete list of external actors/attributes: capital availability, competition intensity, social impact: shown as inputs/outputs crossing the boundary
  • In: global economy, shareholder goals, political inputs, human resources, regulations, customer needs, competition, technology, services, raw material
  • Out: economic impact, profits, political impact, social impact, corporate image, IP, goods, services, technology, pollution
• Purpose of this broadest view (easy to misread as detail-for-its-own-sake): reminds the architect that understanding the PDP’s contents alone isn’t sufficient: must also track issues influencing the firm and its context (Box 9.3 next)

Discussion: Which external actor could force a change in an otherwise sound architecture?

Suggested answer: A supplier unable to deliver a required element is one example. The product’s technical plausibility must be checked against the enterprise and external relationships needed to realize it.

Figure 9.8 · Read the Enterprise Boundary

Figure 9.8 places the PDP inside the producing enterprise. The examples in each column are not one-to-one causal pairs.

Outside: influences entering	Inside: functions and resources	Outside: effects leaving
Customer needs, competition, regulations	Marketing, R&D, legal	Goods, services, intellectual property
Capital, raw materials, technology	Management, skills, information systems, engineering tools	Profits, economic and social impact, pollution

Tip

An architecture can be technically sound and still fail if the enterprise lacks the resources, authority, or channels to create and sustain it.

Selected entities from Crawley, Cameron & Selva (2016), Fig. 9.8; the book’s lists are intentionally incomplete.

• The figure combines the product development process, functions within the enterprise, and influences crossing its boundary.
• R&D and corporate functions are often upstream; sales and distribution are usually downstream. Skills, information systems, and tools permeate the whole process.
• Do not read table rows as exact input-output chains. The purpose is to see what the PDP diagram alone leaves out.

Box 9.3 · Principle of the Stress of Modern Practice

“Things which matter most must never be at the mercy of things which matter least.”: Johann Wolfgang von Goethe

Modern product development: with concurrency, distributed teams, and early supplier engagement: places even more emphasis on having a good architecture:

• Accelerating development via concurrency increases the importance of initial conceptual decisions
• Empowering distributed/non-collocated teams increases the importance of well-coordinated, visible high-level design guidance
• Involving suppliers early increases the importance of an architectural concept and baseline: suppliers can define or defy decomposition

• Close the Global PDP discussion: Goethe quote (“things which matter most must never be at the mercy of things which matter least”) captures the worry: modern pressures can let minor operational details crowd out consequential early architectural decisions
• Each modern trend raises the stakes on getting architecture right, not lowers them (contrary to a naive “efficiency improvement” reading):
  • Concurrency: parallel activities lock in initial conceptual decisions faster, less room to course-correct: getting them right upfront matters more
  • Distributed/non-collocated teams: well-coordinated, visible high-level design guidance matters more: without it, autonomous teams drift out of alignment
  • Early supplier engagement: architectural concept/baseline matters more: suppliers can either define or defy the intended decomposition depending on how clearly it’s communicated
• Overarching message: none of these three practices are inherently bad: but each raises the cost of not having architected well, which is why this principle closes the chapter

Discussion: Why can faster concurrent development increase the importance of early architecture?

Suggested answer: Several teams can commit resources to incompatible assumptions simultaneously. Shared intent and explicit interfaces reduce the risk that speed creates expensive integration rework.

Section 9.3.2 Summary

• The Global PDP is a nested framework used to compare different PDPs on a common baseline, built around the canonical W Questions
• It reveals the architect’s system boundary: largely, but not exclusively, the “conceive” activities
• The purpose of the broadest view is to remind the architect: understanding the contents of the PDP is not sufficient: the firm and its context matter too

• Summary for the whole PDP discussion: students should describe all three nested levels in order: product architecture (center), design/implementation processes in parallel (own W Questions, own form: design tools), whole enterprise context (upstream/downstream functions + external actors)
• Built specifically to give a common baseline for comparing different PDPs (NASA, Helicopter Inc., Camera Co., Agile) fairly, not superficially
• Concrete takeaway: architect’s primary system boundary is largely (not exclusively) the “conceive” activities: with the caveat (Fig. 9.5) that downstream info must still be actively moved back in
• Broadest lesson: understanding PDP contents alone is necessary but not sufficient: firm and context matter too. Transitions into the civil-architecture case study, where “context” is nearly sacred

Discussion: What are the three nested views of the global PDP?

Suggested answer: The product architecture, the design and implementation processes, and the enterprise context. Each adds relationships needed to understand how the product will be created and supported.

Box 9.4: Case Study: Civil Architecture and System Architecture

Where “Architect” Comes From

By Steve Imrich, Architect and Principal at Cambridge Seven Associates

• Civil architecture has an interpretive-interactive-performance aspect that differs from most industrial/product design: buildings inherit complex cultural and symbolic qualities affecting space, materials, and user experience
• Ideally, the “special problems” of a building inform its design: as with helicopters, sailboats, or computers, concept/design/engineering can transcend mere style
• Because buildings are only seen/experienced as part of their site, their special problems always relate to a wider context: time, culture, infrastructure, human behavior, environment, re-interpreted use
• Buildings are rarely mocked up beforehand: a large element of risk, usually associated with the arts

• Closing case study, unusual format: guest contribution by practicing civil architect Steve Imrich (Cambridge Seven Associates): included because the word “architect” is borrowed directly from civil/building architecture, worth hearing from the original field
• Central question to pose: what do civil architecture and system architecture actually share?
• Distinguishing feature #1: buildings carry an interpretive-interactive-performance aspect more pronounced than most product design: inherit complex cultural/symbolic qualities affecting space, materials, user experience beyond pure function
• “Special problems” (recurring phrase): a building’s special problems: particular, non-generic challenges of that site/client/moment: should inform its design
  • Parallel to other fields: helicopters, sailboats, computers successfully resolve their own special problems, where concept+design+engineering transcend mere style: callback to the Principle of Elegance (Ch. 13)
• Two more distinguishing features: buildings are only seen/experienced as part of their site, so special problems always relate to a wide context (time, culture, infrastructure, human behavior, environment, re-interpreted use)
• Buildings are rarely mocked up beforehand: a large element of risk, one the book says is generally associated more with the arts than conventional engineering

Suggested answer: Both fields translate ambiguous needs and context into a unifying concept, allocate function to form, organize interfaces, and balance competing performance, cost, and human-use concerns. Both require judgment about the whole rather than independent optimization of its parts. Civil architecture makes cultural meaning, site, and spatial experience especially visible, but these dimensions also appear in products and services. The shared lesson is integration, not merely borrowing a professional title.

Figure 9.9 · Concept in Civil Architecture

Left: Trulli houses, Alberobello, Italy (a). Right: industrial ductwork, Centre Pompidou, Paris (b). The concept is the departure point for integrating performance and form. Source: Crawley, Cameron & Selva (2016), Fig. 9.9. Photos: (a) Funkyfood London-Paul Williams/Alamy, (b) Francisco Javier Gil/Fotolia.

• Contrasting image pair makes “concept” concrete in civil architecture, extending Ch. 7’s concept vocabulary
• Trulli houses (Alberobello, Italy), conical stone roofs, vs. Centre Pompidou (Paris): exposes structural/mechanical systems on the exterior. Stylistically opposite, same underlying idea: the concept is the departure point for integrating performance and form
• Preview: next slide’s six “design process with attitude” ideas (context, content, concept, circuitry, character, magic): concept is one of two the guest author focuses on most deeply (the other: magic, a few slides later)
• Precise definition: concept = departure point for organization/experience, the unifying idea by which all design decisions get evaluated. Conical roofs responding to climate, or a museum making its mechanical guts a visual statement: either way, one strong organizing idea lets performance and form cohere (same pattern as Ch. 2’s process/operand, instrument/process/operand)

Discussion: What makes a civil-architecture concept more than a building’s shape?

Suggested answer: It integrates intended use, site, movement, and experience with enabling form. A shape without that relationship may be visually distinctive but does not explain the organizing idea.

Six Ideas in “Design Process with Attitude”

• Context: the built environment, cultural norms, and history of the organizations and people the building serves
• Content: the building’s programmatic requirements and functional performance
• Concept: the unifying idea by which all design decisions are evaluated; concept generation succeeds when it integrates and balances the nature of content and context
• Circuitry: the connective tissue between functional components; more than a path from A to B, it creates interest and anticipation
• Character: a building’s material, site, and sense of life beyond the aggregation of parts
• Magic: Imrich’s term for qualities of the user’s experience that create delight or an unexpected appreciation of the building

• Guest author’s vocabulary: “design process with attitude”, deliberately contrasted against a conventional PDP. Define each of the six:
  • Context: the wider setting: adjacent buildings, cultural norms, environmental conditions, history/motivations of the people the building serves
  • Content: what the building is for: programmatic requirements + functional performance (Ch. 5’s function vocabulary, at building scale)
  • Concept: the unifying idea all decisions are evaluated by: succeeds specifically when it integrates and balances content and context together
  • Circuitry: connective tissue between functional components: more than A-to-B; done well, creates interest/anticipation as boundaries and spaces get progressively revealed
  • Character: material choices, site, sense of life beyond the aggregation of parts: related to elegance/emergence themes, applied to how a building feels over time
  • Magic: largely intangible, defined by the user’s experience (not designer/owner intent): fosters delight and joyful appreciation of the unexpected
• Present this six-part framework as different vocabulary from the process/operand, function/form language elsewhere in the course: captures dimensions (character, magic) that purely functional analysis leaves out

Discussion: How could two buildings share content but differ in concept?

Suggested answer: Both may contain reading rooms and collections, while one organizes them around a courtyard and another along a central spine. The functions are similar; their unifying arrangements differ.

Figure 9.10 · Magic in Civil Architecture

Left: Sydney Opera House (a). Right: Golden Gate Bridge (b). Qualities of “Magic” allow structures to become memorable and iconic to a culture. Source: Crawley, Cameron & Selva (2016), Fig. 9.10. Photos: (a) Wim Wiskerke/Alamy, (b) EvanTravels/Fotolia.

• Sydney Opera House and Golden Gate Bridge: maximally recognizable examples of “magic”
• Both are, at bottom, functional infrastructure (performance venues; a vehicular/pedestrian crossing): yet both transcended pure function to become iconic symbols of their cities/countries: exactly the “magic” quality from the previous slide
• Ask students for their own examples (buildings, bridges, everyday products) and push them to articulate why, using the six-part vocabulary, not a vague “it just looks cool.” Sets up the next slide’s deeper development of magic

Suggested answer: Example: a public library organized around a daylight-filled courtyard. Context: neighborhood and climate. Content: reading, study, and gathering needs. Concept: a quiet shared center. Circuitry: paths that connect collections and study spaces. Character: materials, light, and acoustic atmosphere. Magic: a user’s unexpected delight on entering that center. This is an illustrative interpretation, not a claim that every user responds identically. A strong response connects experience to design decisions rather than equating novelty with quality.

On Magic

“Surprise, as all art and architecture, helps us contemplate. Life wears out our ability for surprise. Surprise is the beginning of a true vision of the world.”: Eladio Dieste

• Imrich uses magic to describe elegance and character that emerge from the building as a whole
• People may recognize these qualities in their experience even when they find them difficult to describe
• An unexpected feature can become a familiar and valued part of a building
• These qualities can give a building lasting cultural significance beyond the designer’s original intent

• Eladio Dieste quote: surprise helps us contemplate: valuable because ordinary life, through repetition, wears out our capacity for surprise; a genuine architectural surprise is rare and valuable, “the beginning of a true vision of the world”
• Progressively deeper definition of magic:
  • Magic = emergence of elegance and character at the building level (technical “emergence” sense, Ch. 2): “the sleight of hand”
  • Difficult to define, but immediately recognizable when present: parallel to “you know it when you see it” properties, including elegance itself
  • The unusual circumstance that becomes normalized in good architecture: a moment of surprise leaving wonder/awe, not confusion
  • Lasting cultural significance depends on how people continue to experience and interpret the building.

Discussion: Can ‘magic’ replace the requirement that a building works?

Suggested answer: No. A memorable experience can add value, but the building must still serve its users. Discuss how particular spatial decisions create delight while supporting its functional purpose.

Figure 9.11 · Overlaying Performance and Poetry

A ballerina and a gymnast share athleticism, dynamic patterning, and nuance of expression: yet one is considered “art,” the other “athletic expertise.” An architect’s opportunity and responsibility: to overlay performance and poetry, and understand how those ingredients interact. Source: Crawley, Cameron & Selva (2016), Fig. 9.11. Photos: (a) Cheese78/Fotolia, (b) Gerard Rancinan, Jean Guichard/Sygma/Corbis)

• Closing comparison for the case study: unpack why it’s an apt final image
• Ballerina and gymnast share athleticism, dynamic patterning, nuance of expression: yet one is culturally “art,” the other “athletic expertise”: a distinction of tradition/framing, not objective skill difference
• Parallel to architecture: an architect’s opportunity/responsibility is to overlay performance (function, structural performance) and poetry (magic, character), and understand how they interact: not as separable concerns
• Bridge back to the course: even though most of it focuses on analyzable concepts (form, function, decomposition, interfaces, goals), the actual practice of architecting has genuine room for elegance, character, and magic alongside engineering performance. Summary next returns to the analytical vocabulary

Discussion: Why overlay performance and experiential concerns?

Suggested answer: A concept must satisfy practical use while shaping human experience. Considering both can reveal designs that integrate these aims rather than treating appearance as a late addition.

Chapter 9 Summary

• The architect specializes in resolving ambiguity, focusing creativity, and simplifying complexity
• Ambiguity comes in many forms: fuzziness, uncertainty, and missing, conflicting, or incorrect information: and the architect must recognize and deal with each
• The architect is responsible for producing specific deliverables, central to reducing ambiguity and bridging corporate functions to the design environment
• Product development processes vary across firms and sectors. The Generic and Global PDPs provide a common basis for comparing them
• Architects must discern which segments of a PDP are centrally linked to their role, and stay skilled at interpreting new product development initiatives

Tip

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

• Walk the chapter’s full arc, tied to sections:
  • Opening: architect is not a generalist but a specialist: three roles: resolve ambiguity, employ creativity, manage complexity
  • Section 9.2: ambiguity’s precise forms: fuzziness + uncertainty (core), missing/conflicting/incorrect info ((X,Y,Z) shorthand): plus the architect’s concrete deliverables (goals, context, concept, decomposition, interfaces, cost/schedule/risk)
  • Section 9.3: PDPs as an organizational ambiguity-management tool: four practical PDPs (NASA, Helicopter Inc., Camera Co., Agile), differences sit atop deep common structure: Generic PDP (4 groups) → Global PDP (3 levels, W Questions)
  • Civil-architecture case study: architecting still has room for concept, character, magic
• Closing practical charge: architects must discern which PDP segments are centrally linked to their role, and stay skilled at interpreting new development initiatives (Lean, Agile, Six Sigma, whatever’s next) on their actual merits, not fashion

Discussion: What would you challenge in a clearly detailed answer to an unclear brief?

Suggested answer: First ask whether the intended users, outcomes, and constraints are understood. Detail and polish cannot establish that the chosen problem or concept is appropriate.

Next: Up/Down-stream Influences

Chapter 10 examines the principal upstream and downstream influences on system architecture in detail: including the ABCD Product Case.

• Close by pointing at Chapter 10, which this chapter has been setting up continuously
• We’ve established, in the abstract, that the architect sits astride upstream influences (ambiguity flowing in) and downstream influences (ambiguity flowing back from design/implementation/operations)
• Ch. 10 examines each category specifically and in detail: upstream (corporate strategy, marketing, regulation, technology infusion), downstream (implementation, operations, design-for-X, product evolution): much deeper than this chapter’s compressed “Driving Ambiguity Out” list
• Also introduces the ABCD (Architecture Business Case Decision) framework, for reasoning rigorously about how architectural choices connect to business outcomes: natural next step now that we know the architect’s role and how it fits the PDP