The Role of the Architect

Systems Architecture · Chapter 9

Aykut C. Satici

Starting Part 3: Creating System Architecture

Part 2 was about holism — the architect must manage a huge number of considerations
This can be misread as “the architect is a generalist.” Not so: to paraphrase Eberhardt Rechtin, the architect is a specialist in simplifying complexity, resolving ambiguity, and focusing creativity
The architect is not the design team, the financial controller, the marketing executive, or the plant manager

Tip

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

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 three roles all center on information: reducing ambiguity by identifying necessary, consistent, important information; adding new information through creativity; and managing the explosion of information in the final architecture.

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 drives ambiguity out of the upstream process. The architect is responsible for creating boundaries and concretizing goals.

Driving Ambiguity Out: The Architect’s Inputs

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

From Goals to Concept to Complexity

Employing creativity: once goals are defined, there’s a creative task — defining a concept. A good concept doesn’t ensure success, but a bad concept almost certainly dooms a system to failure. Tasks include proposing concept options, identifying key metrics and drivers, conducting highest-level trades, selecting a concept (and perhaps a backup), thinking holistically about the full lifecycle, and anticipating failure modes.

Managing complexity: once a concept is chosen, information explodes rapidly — external interfaces, first-level design, decomposition, downstream considerations. The architect manages this by decomposing form and function, allocating functionality to form, defining interfaces, configuring subsystems, balancing flexibility vs. optimality, and controlling product evolution.

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

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 role of the architect is to resolve ambiguity, focus creativity, and simplify complexity — creating elegant systems that create value and competitive advantage
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 maintains a holistic view but always focuses on the small number of issues critical to the design, and adopts different frameworks and paradigms as appropriate — not a single fixed method

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

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 genuinely 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

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 — genuinely 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

Classifying Ambiguity — A Quick Drill

Will it be a boy or a girl? (Uncertain, Fuzzy)
Produce a low-cost, high-quality product. (Conflicting, Fuzzy, Unknown)
Every fourth year is a leap year. (False)
Please make me a smooth cover for this phone. (Fuzzy)
Make sure we meet your quarterly goals. (Unknown, Conflicting)

Tip

Ambiguity is almost always present in the upstream influences — segmented roughly by corporate function: strategy, marketing, customers, manufacturing, operations, R&D, regulations, standards.

Active practice, not a read-off — cover the classifications, have students attempt each before revealing
“Boy or girl?” → uncertain (two well-defined outcomes, don’t know which); also fuzzy in the book’s fuller discussion
“Low-cost, high-quality product” → three kinds at once: conflicting (cost vs. quality pull against each other), fuzzy (“low”/“high” are interpretive), unknown (may not know achievable levels)
“Every fourth year is a leap year” → false info dressed as fact — actual rule excludes century years not divisible by 400 (1900 wasn’t a leap year, 2000 was)
“Smooth cover for this phone” → clean, pure fuzziness (echoes “smooth finish” earlier)
“Meet your quarterly goals” → unknown (may not know exactly what’s required) + conflicting (stakeholders may disagree on what “meeting the goals” means)
→ Generalizes: ambiguity is almost always present in upstream influences, segmentable by corporate function — strategy, marketing, customers, manufacturing, operations, R&D, regulations, standards. Previews the next slide and sets up Ch. 10

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)

Deliverables of the Architect

Deliverables are different from tasks — they are the end result, not the procedure by which it’s achieved.

A clear, complete, consistent, attainable (80–90% confidence) set of goals, emphasizing functional goals
A description of the broader context, including the whole product context
A concept for the system, and a concept of operations including contingency/emergency operations
A functional description with at least two layers of decomposition
The decomposition of form to two levels of detail, and the structure at this level
Details of all external interfaces and a process for interface control
A notion of developmental cost, schedule, risk, and design/implementation plans

Crisp distinction first: deliverable = the end result; task = the procedure to get there. This slide lists deliverables, not a to-do list
Walk through each, tied to prior material:
- Clear/complete/consistent/attainable goals — book gives 80-90% confidence target, emphasizes functional goals (Ch. 2)
- Description of broader/whole-product context — Ch. 2’s Task 2, now at product-wide scale
- A concept (Ch. 7) and a concept of operations, including contingency/emergency ops
- Functional description, ≥2 layers of decomposition — recalls “2 Down, 1 Up” (Ch. 13 formalizes)
- Decomposition of form to 2 levels + structure — formal-domain counterpart
- External interface details + an actual control process, not one-time documentation
- Cost/schedule/risk notion + design/implementation plans
Table 8.1 (previous chapter) leads to all of these except the last (a project summary instead)
→ Ongoing challenge: representing deliverables in a form the org can absorb is part of the job — OPM/SysML don’t always fit an org’s culture; effective architecting means finding what actually lands with your audience

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

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
But it’s easy to be lulled into thinking the PDP resolves upstream ambiguity automatically — this is only partially true. A PDP can do the architect a disservice if it presumes more certainty than is actually present
We seek a PDP that is “birth to death” and “lust to dust” — capturing everything from first envisioning a product to retiring 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
→ Ambitious target scope: “birth to death” and “lust to dust” — first envisioning through retirement of the last instance. Most real PDPs fall short; the four case studies (NASA, Helicopter Inc., Camera Co., Agile) each cover a different partial slice

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 real-world 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)

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

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

Figure 9.4 · An Agile PDP

Agile emphasizes iterative, incremental development — collaborative teams evolve requirements and solutions evolutionarily. Originated in rapid prototyping of software for small/medium applications; since extended (with mixed success) to capital-intensive, longer-lifecycle industries. Source: Crawley, Cameron & Selva (2016), Fig. 9.4.

Fourth and final case study — Agile — genuinely 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

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

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)

Linear Representations Are Flawed

Studies have shown that linear representations of the design process are deeply flawed — they fail to represent iterations and feedback, presume a linear flow of time and effort across stages, and can mask a design’s immaturity when gate criteria are compromised.

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

Why the Generic PDP was drawn this way: studies have shown linear design-process representations are deeply flawed (genuine research finding, not editorial opinion)
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”)

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

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

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

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)
Subtle key point: the design process is itself a system with its own form — notably design tools. A straightedge vs. a French curve produces different renderings, hence different achievable system forms — the tools used to design meaningfully constrain what’s achievable
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

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)

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

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

Closing checkpoint 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 genuinely 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

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

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)

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 — the largely intangible quality defined by the user’s experience; magic fosters delight and joyful appreciation of the unexpected

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 genuinely different vocabulary from the process/operand, function/form language elsewhere in the course — captures dimensions (character, magic) that purely functional analysis leaves out

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.

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

Magic is the emergence of elegance and character at the building level — the sleight of hand
It is difficult to define, but when something is magical, it’s immediately recognizable
Magic is the unusual circumstance that becomes normalized in good architecture — that moment of surprise that leaves a person in wonder and awe
Real magic makes architecture symbolic and iconic in a sustained manner — it reaches beyond the original intent, communicating viscerally with users

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
- → Real, lasting magic (not passing novelty) makes architecture symbolic/iconic in a sustained way — reaches beyond original designer intent, communicates viscerally with users regardless of whether they know that intent

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

Chapter 9 Summary

The architect is not a generalist, but a specialist 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 differ superficially across firms and sectors, but share deep common structure — codified here as the Generic and Global PDPs
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 real-world 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

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 depth: 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