Upstream and Downstream Influences on System Architecture

Systems Architecture · Chapter 10

Aykut C. Satici

Beyond the Architect’s Immediate Control

• Chapter 9 established the architect’s role: reduce ambiguity, employ creativity, manage complexity
• Much of that ambiguity comes from upstream influences (strategy, marketing, customers, technology, regulation) and downstream influences (implementation, operations, Design for X, product evolution)
• The architect doesn’t control these: but must understand them well enough to make good decisions

Tip

This chapter surveys the principal upstream and downstream influences, then shows how they combine in an iterative decision framework: the ABCD Product Case.

• Upstream and downstream influences affect architecture even when the architect does not control them. This chapter examines their relationships to architectural decisions, then combines them in the ABCD Product Case.
• Architectural decisions affect the form-function mapping, performance limits, major tradeoffs, and cost. Examples include the number of driven wheels on a car, an aircraft’s tail configuration, and whether an algorithm must operate in real time.
• Detailed design choices, such as seat upholstery, usually have more predictable effects. Identify the decisions with potentially large or emergent consequences early.
• The book uses Kahneman’s observation to question reliance on intuition under high stakes. Later component optimization may not repair an unsuitable architectural choice.

Discussion: Can an architect ignore an influence because it is outside their control?

Suggested answer: No. External influences still affect feasibility and value. Identify their implications, clarify uncertain assumptions with the responsible parties, and adapt the architecture accordingly.

Box 10.1 · Which Decisions Are Architectural?

Architectural decision	Detailed design decision
Driven wheels on a car; tail or no tail on an aircraft; real-time or batch algorithm	Seat fabric or another local finish

Architectural choices set the form–function mapping, performance envelope, major tradeoffs, and often cost. Their consequences can spread through the whole system, so they are expensive to change late.

Adapted from Crawley, Cameron & Selva (2016), Box 10.1.

• An architectural decision creates fundamentally different system concepts; a local detail normally has more predictable effects.
• A seat-material change can affect cost, but is less likely to change the system’s form–function mapping or produce large emergent consequences.
• Identify these decisions early, state their assumptions, and compare alternatives before detailed optimization makes a concept hard to change.

Discussion: Why might component optimization fail to repair a poor architectural choice?

Suggested answer: If the architecture fixes an unsuitable performance envelope or coupling pattern, improving one component cannot remove the system-level constraint.

10.2 Upstream Influence: Corporate Strategy

Corporate and Business Unit Strategy

• Corporate and business unit strategy identifies markets, capabilities, and sources of competitive advantage
• The architect must interpret strategy, often incomplete or ambiguous, into concrete goals for the system
• Strategy rarely specifies architecture directly; it specifies intent, and the architect must translate intent into form and function

• Corporate strategy describes how an enterprise intends to achieve its goals. For a firm, these may concern profitability and competitive position. For a government agency, they concern its mission.
• A useful strategy identifies activities, scope, goals, resource allocation, and planned initiatives. A statement such as growing revenue while maintaining margins provides little guidance by itself.
• Distinguish public annual-report objectives from executive corporate strategy, business-unit strategy, and functional strategies in marketing, R&D, manufacturing, and development. Public statements may omit priorities that would reveal information to competitors.
• The book’s BMW example contrasts continued Formula 1 participation with redirecting investment toward small, efficient urban vehicles. The architect needs to understand how such choices affect the product’s goals.

Discussion: How could a change in company strategy alter an architecture?

Suggested answer: A shift toward service provision can make maintainability, monitoring, and lifecycle cost more valuable. The same technical capability may need a different allocation of ownership and operating responsibility.

10.3 Upstream Influence: Marketing

Figure 10.1 · Marketing as Seen by the Architect

Inbound marketing creates value: identifying customers, segmenting markets, evaluating competition. Outbound marketing delivers value: product, price, communications, distribution. Product development is the bridge between them. Source: Crawley, Cameron & Selva (2016), Fig. 10.1.

• Marketing and engineering may draw different conclusions from sales data, customer feedback, warranty reports, and product tests. The architect helps reconcile these sources.
• The book uses a line from Office Space to introduce this division of responsibilities. Ask how direct communication between engineering and customers could improve the evidence.
• Inbound marketing identifies customers and segments, investigates needs, and evaluates competitors. Outbound marketing concerns the product offering, pricing, communication, and distribution.
• Product development connects the identified opportunity to a deliverable offering. Use Figure 10.1 to trace those relationships.

Discussion: What should marketing contribute beyond a list of desired features?

Suggested answer: Evidence about users, segments, competing offerings, and value. The architect translates that information into goals and alternatives rather than treating every requested feature as mandatory.

Working with Marketing

• Inbound marketing generates the voice of the customer: needs, preferences, willingness to pay: which the architect must translate into solution-neutral function (Ch. 7)
• Outbound marketing determines how the product and its architecture are presented to customers
• The architect and marketing function are natural partners: marketing knows what customers want, the architect determines whether and how it can be delivered

• Market segmentation groups customers with similar needs and responses to an offering. Segment size helps determine where to invest development effort.
• Total addressable market estimates annual sales at full market capture. A business case then needs a defensible penetration estimate, rather than assuming the whole market will buy the product.
• Estimates for complex or unfamiliar products are uncertain. Examine the assumptions and evidence behind market size and expected sales.
• Translate the voice of the customer into solution-neutral functions. Customer preferences and willingness to pay inform the goals, while engineering establishes feasibility and likely cost.
• Outbound marketing also needs a clear explanation of the product’s benefits and distinguishing features. Maintain communication between marketing and the architecture team.

Discussion: How would you respond to a request to match every competitor feature?

Suggested answer: Ask which stakeholder outcome each feature supports and at what cost. Compare concepts against prioritized needs; indiscriminate matching can add complexity without corresponding value.

Sections 10.2–10.3 Summary

• Corporate strategy and marketing are major upstream influences the architect must interpret, not just receive
• Inbound marketing (creating value) and outbound marketing (delivering value) both interact with the architecture: inbound shapes goals, outbound shapes communication
• The architect’s job is translation: converting ambiguous strategic and market intent into concrete, solution-neutral functional goals

Use this as a checkpoint before moving to the next upstream influence. By this point students should be able to state, in their own words, why corporate strategy rarely specifies architecture directly (it specifies intent, at several nested levels: shareholder-report, executive, business-unit, functional: and the architect has to translate that intent). They should also be comfortable with the inbound/outbound marketing distinction, and be able to explain why the architect and marketing are natural partners rather than adversaries, despite the tension the Office Space quote pokes fun at. The unifying theme across both strategy and marketing, worth restating explicitly: the architect’s core job with respect to every upstream influence in this chapter is translation: converting something ambiguous, high-level, and not inherently architectural (a strategy statement, a customer need) into something concrete enough to shape form and function. That’s the same lens we’ll apply next to regulation, then to technology.

Discussion: Why must strategy and marketing be interpreted together?

Suggested answer: Marketing identifies opportunities and needs; strategy shapes which opportunities the enterprise intends and is able to pursue. Architectural goals must reflect both.

10.4 Upstream Influence: Regulation and Pseudo-Regulatory Influences

Regulation: Enabler and Barrier

• Regulation can be both an enabler of competitive advantage and a barrier to entry
• It can preserve an existing architecture well past its useful life: or generate an opportunity for new architectures to disrupt the market
• Example: Tier 4 Final emissions regulations for off-highway trucks upheld stricter standards, forcing firms to update their engine portfolios: but also opened a new competitive axis on fuel efficiency

Tip

Regulation affects architecture two ways: directly (mandatory backup cameras, medical device material rules) and indirectly, through downstream factors like manufacturing location, hiring rate, or addressable markets.

Move to the second upstream influence. Open with the dual-edged framing on the slide, since it’s the section’s central thesis: regulation can act to preserve an existing architecture well past its natural useful life (protecting incumbents who’ve already invested in compliance), or it can generate an opportunity for new architectures to disrupt an otherwise-stable market. The Tier 4 Final emissions example is the book’s own worked case, worth walking through carefully: these regulations imposed essentially held off-highway truck manufacturers to stricter emissions standards, which forced firms to update their entire engine portfolios, a real burden, but simultaneously it reset the competitive playing field and opened up a new axis (fuel efficiency) on which firms could newly differentiate themselves, inviting them to compete on new dimensions after the compliance deadline passed.

The fragment gives students the two distinct pathways by which regulation reaches into architecture, and it’s worth being precise that these are different mechanisms. The direct pathway is the obvious one: a regulation explicitly requires some feature or property of the product itself: mandatory backup cameras on U.S. cars, or regulation on which materials may be used in medical devices. The indirect pathway is subtler and easy to overlook: regulations can shape downstream factors: where manufacturing facilities can be sited, how quickly team members can be hired or fired, which markets a product may legally be sold into: and those downstream constraints feed back and affect the economic viability, and therefore the architecture, of the product just as surely as a direct technical mandate would. A good architect has to be alert to both pathways, not just the visible direct one.

Discussion: How can a constraint also create an opportunity?

Suggested answer: A new requirement may favor a concept or capability the enterprise can deliver well. It restricts the feasible space while potentially changing the value of alternatives within that space.

Figure 10.2 · Regulation and Pseudo-Regulatory Influences

Four categories, each demanding a different level of engagement: regulation (compliance), anticipated regulation (awareness), standards (alignment), liability (compliance with enterprise procedures). Source: Crawley, Cameron & Selva (2016), Fig. 10.2.

Walk through each of the four categories in this figure individually, since each demands a different level of engagement from the architect, and that distinction is the purpose of the diagram. Regulation proper demands straightforward compliance: it’s a matter of law, so compliance is mandatory, and the architect’s job is understanding the regulatory intent well enough to implement it correctly (the book lists five typical regulatory intents worth mentioning as examples: protecting the consumer, as with credit-card payback disclosure rules; setting workplace-safety standards, as with OSHA ventilation requirements; protecting the environment, as with CAFE fuel-economy standards; implementing industrial policy through incentives or disincentives, as with electric-vehicle tax credits; and preventing dissemination of sensitive technology, as with ITAR munitions-data controls).

Anticipated regulation demands only awareness, not yet compliance: proposed rules can often be tracked as they move through the government rulemaking process, and the architect can watch leading global jurisdictions as an indicator of where regulation elsewhere may eventually head (the book’s examples: Switzerland’s stringent noise regulations for domestic appliances, Sweden’s automotive safety rules, and California’s fleet emissions standards, all of which have historically been “leading indicators” later echoed by other jurisdictions).

Standards demand alignment rather than strict compliance, since they’re typically voluntary: though often the price of industry-association membership, adopted as a form of self-regulation intended to stave off stricter external government regulation. Standards can also be a competitive tool: a firm that sets and controls an industry standard (the book cites Intel’s long-running role in setting semiconductor wafer-size transitions) gains real strategic leverage. Finally, liability demands compliance with enterprise procedures: legal risk from product-liability litigation or breach-of-contract claims (the book’s example: Sun Microsystems, owner of Java, suing Microsoft for improperly implementing the Java 1.1 standard) acts as a pseudo-regulatory pressure even without any government rule requiring it directly.

Discussion: Why distinguish legal requirements from industry expectations?

Suggested answer: Their authority and consequences differ. Both may influence adoption, but the model should record which are binding constraints and which are preferences or market conditions.

Sources and Levels of Regulation

• Regulations occur at federal, state, and city/county levels in the U.S., plus international regulations: agencies like the FDA, USDA, FAA, and EPA oversee federal rules
• Pseudo-regulations matter too: standards (voluntary but expected), anticipated regulation (not yet law, but coming), and litigation/liability precedent
• The architect must decide: which elements of regulation are important enough to shape the architecture, and which can be addressed later in detailed design and testing?

Give students the practical, jurisdictional texture behind the four-category figure just covered. Using the United States as the reference case (while noting other major industrialized nations show broadly similar patterns), regulation occurs at multiple nested levels: federal (agencies like the FDA, USDA, FAA, and EPA), state (for instance California’s CARB and various state motor-vehicle safety equipment laws), and city/county (though these tend to be too diffuse and locally variable for a complex system to comprehensively address). Point out a practical wrinkle worth mentioning: regulations aren’t always hard to locate for environments requiring formal certification (aircraft type certificates being the clean example): but in other cases they can be challenging to unearth, and it’s ultimately the architect’s responsibility, often working with the enterprise’s legal function, to be aware of everything relevant.

Close on the key architectural judgment call this section keeps returning to, and worth stating explicitly as the section’s takeaway: not every element of regulation deserves to shape the architecture itself. Some regulatory requirements can perfectly well be addressed later, in detailed design and testing, without touching the fundamental form-function mapping: the architect’s job is discriminating between the two, deciding which regulatory and pseudo-regulatory factors are consequential enough to bake into the architecture now, versus which can be deferred.

Discussion: What belongs in the architecture model when a requirement’s applicability is unresolved?

Suggested answer: An explicit assumption and a dependency on clarification by the responsible specialist. Explore how alternative interpretations affect feasibility before committing to a costly configuration.

Section 10.4 Summary

• Regulation is a two-edged upstream influence: it can protect incumbents or create openings for disruption
• Beyond formal regulation, the architect must track pseudo-regulatory influences: anticipated regulation, standards, and liability exposure
• The key architectural judgment: separate regulatory elements that must shape the architecture from those addressable later, in detailed design

Review before moving to technology. Students should now be comfortable that regulation isn’t purely a compliance headache: it’s a two-edged strategic influence that can lock in incumbents or crack open a market for disruption, exactly like the Tier 4 Final emissions example demonstrated. They should also be able to name and distinguish all four categories from Figure 10.2 (regulation, anticipated regulation, standards, liability) and the different level of engagement each demands, and articulate the core architectural judgment call: deciding which regulatory factors are consequential enough to shape the architecture now, versus deferrable to detailed design later.

Discussion: What is the risk of adding regulatory checks only after concept selection?

Suggested answer: They may invalidate the preferred concept or require major redesign. Relevant constraints should inform exploration early and remain traceable as the design develops.

10.5 Upstream Influence: Technology

Introducing New Technology

• The architect decides whether and how to introduce new technology into the system
• Three questions the architect must answer:

1. Will the technology be ready for infusion? 2. Will it actually create additional value for customers and stakeholders? 3. How will it be effectively transferred into the product or system?

• Evaluate readiness, value, and transfer when considering new technology. A new technology may motivate the product, but it still needs to satisfy the system’s requirements.
• Readiness concerns performance in the intended environment and availability by the integration deadline. Value concerns benefits relative to cost, risk, and alternatives. Transfer concerns how the receiving team will acquire and apply the technology.
• These questions interact. Integration difficulty can change the readiness assessment and the expected benefit.

Suggested answer: Require evidence on all three questions. Readiness: can the technology meet the required operating conditions by the integration deadline? Value: does its system-level benefit justify cost, risk, and supporting changes relative to a credible alternative? Transfer: who will supply the expertise, process control, documentation, and integration support? These checks can proceed iteratively; transfer difficulty can change both readiness and value. Keep a fallback or staged introduction when a promising technology remains uncertain.

Figure 10.3 · Technology Readiness Levels: 1–4

TRL	Evidence of readiness
1	Basic scientific principles observed and reported
2	Possible application or technology concept formulated
3	Analytical and experimental proof of a critical function
4	Components integrated and validated in a laboratory

Early research and laboratory validation. Adapted from the U.S. Department of Defense scale in Crawley, Cameron & Selva (2016), Fig. 10.3.

• TRL 1 concerns reported basic principles. TRL 2 proposes an application without proof that it will work.
• TRL 3 tests a critical function; TRL 4 integrates basic components in a laboratory, still at low fidelity relative to the eventual system.
• A rating describes evidence already obtained, not the date by which the next rating will be reached.

Figure 10.3 · TRL 5–7: Prototype Evidence

TRL	Evidence of readiness
5	Components validated with realistic support in a relevant environment
6	Representative system or subsystem prototype demonstrated in a relevant environment
7	Near-operational system prototype demonstrated in an operational environment

Adapted from Crawley, Cameron & Selva (2016), Fig. 10.3.

• TRL 5 tests integrated components with realistic support; TRL 6 tests a representative system or subsystem prototype.
• TRL 7 requires an operational environment, rather than a simulated one.

Figure 10.3 · TRL 8–9: Qualification and Use

TRL	Evidence of readiness
8	Final system completed and qualified through test and demonstration
9	Final system proven in successful mission operations

Adapted from Crawley, Cameron & Selva (2016), Fig. 10.3.

• A qualified system at TRL 8 still differs from technology proven in operational mission conditions at TRL 9.
• Ask what was actually tested at the reported level. A mature component can still create an immature integrated system, and development may iterate or suffer setbacks.

Discussion: Why is a TRL 6 prototype not yet evidence of TRL 9 readiness?

Suggested answer: Relevant-environment prototype testing does not establish that the completed system is qualified or has succeeded under mission conditions.

Technology Transfer and Know-How

• Technology transfer discussions often jump straight to IP ownership: necessary, but not sufficient
• IP agreements establish rights to use a technology. Teams also need the know-how to apply it reliably
• Experienced developers help transfer know-how, often by working with the receiving product team

Tip

External technology suppliers may have limited knowledge of the intended application or limited resources for development. Plan how the receiving team will acquire the expertise needed to integrate the technology.

• IP ownership or licensing establishes rights to use the technology. Reliable use also requires practical knowledge about production, operating limits, and troubleshooting.
• Experienced developers can transfer this knowledge by working with the receiving team. Internal research staff may move into product development with the technology.
• External suppliers, universities, government laboratories, and acquired firms may provide technology without knowing the intended application or having resources to complete its development.
• Plan training, documentation, joint integration work, and evidence that the receiving team can reproduce the required results.

Suggested answer: Transfer the ability to reproduce reliable results, not only the right to use a design. Pair receiving engineers with experienced developers, document operating windows and failure modes, train staff on representative equipment, and demonstrate repeatable performance at the receiving site. Licensing can establish permission without transferring tacit production and troubleshooting knowledge. Acceptance evidence should show that the receiving team can operate and maintain the technology without indefinite dependence on its inventors.

Section 10.5 Summary

• The architect must judge technology readiness (TRL), value creation, and transfer mechanism before infusing new technology
• Technology development is not linear: setbacks and iteration before final readiness are the norm, despite what a TRL rating might suggest
• Effective transfer includes both IP arrangements and the expertise needed to use the technology reliably

Review before turning from upstream to downstream influences. Students should be able to recite the three-question sequence for technology infusion decisions (readiness, value, transfer), explain the TRL scale’s general shape and its explicit caveat about nonlinear development, and articulate why “know-how” transfer (people) matters more than pure IP ownership. This closes out the upstream half of the chapter: strategy and marketing, regulation, and technology: all three of which the architect has to interpret and translate into concrete architectural goals, without controlling any of them directly. The chapter now pivots to the mirror-image problem: downstream influences, where the architect similarly doesn’t control implementation, operations, or product evolution, but must compress relevant detail from each of them back into decisions made early.

Discussion: What three checks should precede technology infusion?

Suggested answer: Assess readiness for the relevant environment, system-level value relative to alternatives, and the ability to transfer know-how into the receiving organization. Weakness in any one can undermine the expected benefit.

10.6 Downstream Influence: Implementation

Compressing Downstream Detail

• The downstream development of the system is an equally significant source of ambiguity
• Identify downstream constraints that affect architectural choices and consider them early
• We use implementation rather than “manufacturing” to cover both hardware and software: designing software means choosing algorithms/abstractions, data structures, program flow; implementing means writing and testing the actual code

• Downstream influences include implementation, operations, Design for X, and product evolution. Identify the aspects that could change early architectural choices.
• Implementation includes both hardware manufacturing and software coding and testing. Software design includes algorithms, abstractions, data structures, program flow, and pseudocode.
• The architect draws on specialists in manufacturing, coding, and supply-chain management to identify relevant constraints before committing to a concept.

Discussion: Which downstream details deserve attention during concept selection?

Suggested answer: Those likely to affect feasibility, major cost, interfaces, or lifecycle performance. For example, a difficult assembly or maintenance access requirement can change the preferred architecture.

Figure 10.4 · The Flow to Implementation

Conceiving and designing merge with sourcing and supplying at the implementation stage: two flows that must be carefully coordinated by the architect and the implementation team. Source: Crawley, Cameron & Selva (2016), Fig. 10.4.

• Figure 10.4 brings together the conceive/design flow and the source/supply flow at implementation. Coordinate their assumptions, schedules, and interfaces.
• A design must be compatible with available materials, components, production methods, and supplier capabilities. Sourcing decisions can also change the design.
• The architect and implementation team share responsibility for identifying constraints early and resolving mismatches. Include software dependencies and integration arrangements when applying the diagram to informational systems.

Discussion: How can implementation planning change a function-to-form allocation?

Suggested answer: Available supplier capabilities, manufacturing processes, and integration methods may favor a different grouping. The revised allocation must still satisfy the required functions and interfaces.

Section 10.6 Summary

• Implementation covers both coding and manufacturing: the point where design and supply chain flows converge
• The architect’s job is to compress downstream implementation detail into decisions that can be made early, rather than discovering constraints too late
• Coordinating the conceive/design flow with the source/supply flow is a joint responsibility of the architect and the implementation team

Review. Students should be comfortable with why “implementation” replaces “manufacturing” as the vocabulary here (to cover software as naturally as hardware), able to describe the two converging flows in Figure 10.4 (conceive/design vs. source/supply), and able to state the make/buy decision and the “suppliers can define decomposition or defy decomposition” principle as the two central architectural stakes in this section. One more downstream influence beyond a program’s supply-chain dynamics is worth a final mention before moving on: the book notes that the implementation system is large, with many points of coordination: often working from incomplete information, and subject to real lags: so the architect should be prepared to understand these dynamics, because they affect major timing decisions, such as time-to-market for the first product. Next, we move from building the system to operating it once fielded.

Discussion: When is a technically feasible concept not implementable by the enterprise?

Suggested answer: When necessary skills, suppliers, tooling, resources, or schedule are unavailable. Technical feasibility is only one part of the realization problem.

10.7 Downstream Influence: Operations

Table 10.1 · Preparing for Operation

Phase	Air transport	Hybrid car	Refrigerator
Get Ready	Sell tickets; schedule aircraft and staff	Deliver, register, and bring car home	Deliver, install, and transfer ownership
Get Set	Check in travelers; load baggage and catering; plan flight	Fuel, start, adjust seats, load passengers	Cool down, set temperature, load food
Go: primary	Transport travelers	Transport people and cargo	Preserve food
Go: secondary	Feed and entertain travelers	Provide climate control, entertainment, navigation	Provide ice and cold water; freeze food

Condensed examples from Crawley, Cameron & Selva (2016), Table 10.1. “Get Ready” may happen once; “Get Set” prepares each use.

• Operations deliver system value, but require preparation before primary use begins.
• Get Ready includes distribution, ownership, staffing, and installation. Get Set includes the recurring tasks immediately before operation.
• Nominal operation creates primary and secondary value. The latter should not be ignored in architectural tradeoffs.

Table 10.1 · Off-Nominal Operation

Phase	Air transport	Hybrid car	Refrigerator
Go: contingent	Notify travelers of delays and missed connections	Repair a flat tire; prevent a skid or low-speed damage	Permit easy spill cleanup
Go: emergency	Brace and evacuate through slides	Protect occupants in a crash	Prevent entrapment in an abandoned unit
Go: stand-alone	Move an aircraft without passengers	Start or operate selected functions without a driver inside	Not listed in the book’s table

Condensed from Crawley, Cameron & Selva (2016), Table 10.1. The book also gives keeping food cold during a power outage as a stand-alone example in the surrounding text.

• Contingencies are recoverable without sacrificing primary function or causing damage. Emergencies shift attention to saving life and limiting damage.
• Stand-alone operation occurs without a normal supporting system; it is a separate mode, not a severity level.
• The refrigerator entry is “NA” in Table 10.1, although the text provides the power-outage example. Preserve that distinction when discussing the source.

Table 10.1 · Ending, Storing, and Fixing

Phase	Air transport	Hybrid car	Refrigerator
Get Unset	Deplane travelers; unload baggage	Unload passengers and baggage; park	Clean out food
Get Unready	Clean and store aircraft overnight	Clean and store car for an extended period	Uninstall and dispose
Fix	Routine maintenance and upgrades	Regular and event-driven maintenance	Event-driven maintenance and repair

Condensed from Crawley, Cameron & Selva (2016), Table 10.1. Get Unset follows a use cycle; Get Unready prepares for longer storage or retirement.

• Post-use tasks and long-term retirement or storage are different categories; each may require different access, interfaces, and procedures.
• Fix includes inspection, calibration, repair, overhaul, and updating as appropriate to the system.
• Use the full ten-row framework to check a proposed architecture for overlooked operational modes.

Discussion: Which phase might reveal a need for removable connections?

Suggested answer: Get Unready or Fix, depending on whether removal is for retirement, storage, or servicing.

Contingencies, Emergencies, and Stand-Alone Operations

Contingency operations

Off-normal, but recoverable without loss of primary function or personal/property damage. Performance may degrade gracefully: a spill in a refrigerator, a skid, a missed network packet. The architect builds in recovery provisions.

Emergency operations

Off-normal conditions beyond the planned recovery range. Protecting life and limiting property damage take priority over delivering the primary function. The architecture needs provisions for these conditions.

Tip

Stand-alone operations: the system must operate without connection to its normal supporting systems: common during test, but sometimes also in the field (e.g., a refrigerator keeping food cold through a power outage).

• Contingency operations recover from off-normal conditions within the system’s planned capabilities. Examples include cleaning a refrigerator spill, recovering from a skid, or retransmitting a missing packet. Performance may temporarily decrease.
• Emergency operations prioritize life and property when normal recovery is no longer adequate. Identify the transition criteria and the provisions needed for safe response.
• Stand-alone operations occur without some normally available supporting systems. Examples include isolated testing and maintaining refrigeration during a power interruption.
• Define the boundary and operating conditions before classifying an event. The same event may be recoverable in one design and an emergency in another.

Suggested answer: Example requirement for a laptop: maintain a defined essential workload on battery for a specified duration when mains power is unavailable, with a stated initial charge and power profile. The precise duration would come from stakeholder needs, not from this example. Identify which normal support is absent, what reduced service remains, and when safe shutdown is required. Stand-alone operation is a capability or mode; whether it is a contingency or emergency depends on the circumstances and consequences.

Section 10.7 Summary

• Operations include preparation, nominal and off-nominal use, shutdown, storage, and repair
• Table 10.1 gives ten modes across three different systems; the modes can expose architectural requirements before detailed design
• Contingencies permit recovery, emergencies prioritize protection, and stand-alone operation removes normal support

Ask students to apply the framework to a system not shown in Table 10.1. The aim is to surface interfaces, provisions, and responsibilities that primary-value operation alone would hide.

10.8 Downstream Influence: Design for X

Design for X Brings Later Constraints Forward

Design for X (DfX) is a family of guidelines that brings downstream concerns into early architectural decisions.

Guideline	Early question
Design for Manufacturing	Can the chosen form be made and assembled reliably?
Design to Cost	Can the concept meet its cost target across its lifecycle?
Design for Test	Where will tests observe and access critical behavior?
Design for Six Sigma	How will variation affect performance and quality?

Examples from Crawley, Cameron & Selva (2016), §10.8. A circuit-board probe point is one concrete Design for Test provision.

• DfX propagates downstream constraints and considerations upstream while architectural choices can still accommodate them.
• A probe point requires board space and electrical access. Adding it after layout or packaging is fixed can be expensive or impossible.
• DfX guidelines do not all carry equal weight for every system; identify which constraints distinguish the candidate architectures.

Discussion: How could a test requirement alter an architecture?

Suggested answer: It may require accessible modules, measurement ports, isolation points, or software hooks, changing interfaces and packaging.

Figure 10.5 · The Prevalence of “Ilities” Over Time

15 “ilities” tracked by journal mentions since 1884 (log scale): quality and safety dominate early; sustainability, interoperability, and scalability are recent arrivals. Not every “ility” is architecturally distinguishing, and they are not independent of one another. Source: Crawley, Cameron & Selva (2016), Fig. 10.5, after de Weck, Roos & Magee (2011), © MIT Press.

• Figure 10.5 tracks mentions of 15 ilities in journals since 1884, using a logarithmic scale. Interpret it as a history of terminology and research attention.
• Quality and safety appear prominently early in the record. Sustainability, interoperability, and scalability appear later in the period shown.
• These attributes concern how a system performs across operating conditions and its lifecycle. They can influence architecture, but their importance depends on the product and stakeholders.
• The attributes interact. Examine possible conflicts and supporting relationships among reliability, maintainability, flexibility, safety, and other goals. A label alone does not define a measurable requirement.

Discussion: Why do different ‘ilities’ matter at different lifecycle stages?

Suggested answer: Production emphasizes manufacturability; operation and support emphasize reliability and maintainability; later changes emphasize adaptability. Early architecture choices can constrain all of them.

Section 10.8 Summary

• DfX turns manufacturing, cost, test, quality, and other downstream concerns into early design constraints
• The “ilities” name desired system qualities, but each needs a concrete measure and a reason to affect architecture
• Choose the constraints that distinguish candidate concepts; do not assume every “ility” is independent

Distinguish the guideline from the outcome: Design for Test is an activity; testability is a property of the resulting system. Ask which DfX concerns should be checked before committing to an inaccessible or hard-to-produce form.

10.9 Downstream Influence: Product Evolution and Product Families

Box 10.2 · Reusing Legacy Elements

• Legacy elements carry known behavior and often hidden, emergent properties
• Check whether assumptions behind the old architecture still hold in the new system
• Reusing an element in a new context may require substantial integration work and retesting
• Document interfaces and design knowledge so future teams can reuse elements safely

Adapted from Crawley, Cameron & Selva (2016), Box 10.2.

• Starting from a blank slate is rarely possible or desirable. Legacy knowledge can be valuable, but some behavior may be poorly documented.
• Do not equate previously tested with validated in the new context. Recheck loads, interfaces, environment, and failure behavior.
• The book uses a printer-software rewrite and the Space Shuttle to show why legacy choices can be consequential.

Discussion: What would you verify before reusing a control module in another product?

Suggested answer: Its assumptions about inputs, timing, environment, dependencies, and interaction with new components, followed by integration tests in the new context.

Box 10.3 · Plan for Product Evolution

Systems must evolve as needs and technology change. Put the most stable contracts at interfaces so internal elements can change without forcing every other element to change.

• State a master vision for likely variants and upgrades
• Reserve capacity where expected evolution needs it
• Keep the cost of changing an element from spreading across the whole family

Adapted from Crawley, Cameron & Selva (2016), Box 10.3.

• The book’s principle is that a system that cannot evolve risks losing competitive advantage.
• Stable interfaces do not mean frozen functionality; they provide a contract that permits elements on either side to evolve.
• Reserve resources deliberately, such as space, power, bandwidth, or computing headroom, when their future use is plausible.

Discussion: Why should an architect think about the second product variant while designing the first?

Suggested answer: Initial interfaces and shared modules determine whether the next variant can change cheaply or requires system-wide redesign.

Platforming vs. Reuse

Platforming is the intentional sharing of parts and process across or within products.

• Platforms require the architect to invest once in a common part or module, predicting which future models will use it
• Unlike reuse (known performance, known use case), platforming means choosing constraints while living with uncertainty about future applications
• Platforming has become a key strategy for delivering product variety across multiple markets and vertical segments

• Platforming intentionally shares parts and processes across products or variants. It requires investment before all future applications are known.
• Reuse applies an existing solution to a known need. Platforming anticipates a family of needs and chooses shared constraints under uncertainty.
• Shared development and production can support product variety across market segments. Assess whether expected commonality will justify the added investment and restrictions.
• Future variants may require different performance, interfaces, or capacity. Record the assumptions about those variants when choosing the platform.

Discussion: How does platforming differ from reusing one convenient part?

Suggested answer: Platforming deliberately supports a family through planned common architecture and variation. Isolated reuse can save effort without defining or coordinating a product-family strategy.

Figure 10.6 · GE Healthcare’s LOGIQ Product Family

The figure shows eight variants in GE Healthcare’s LOGIQ ultrasound family. Compare the range of products when considering opportunities for shared architecture and components. Source: Crawley, Cameron & Selva (2016), Fig. 10.6. Used with permission of GE Healthcare.

Use this figure as the concrete, practical illustration of a product line/product family: linked groups of products, in the book’s phrasing, such as this GE Healthcare LOGIQ family of ultrasound machines. Point out an important nuance the book is careful about: product families don’t necessarily share underlying components or architecture at all: they can be grouped under similar names and stratified purely for feature-content marketing purposes, entirely separate from any objective like reducing development time that would explicitly require sharing components or architecture. So looking at a marketing family tree like this one doesn’t by itself tell you whether genuine platforming is happening underneath: that’s a separate, deeper architectural question. Ask students, rhetorically, to look at the range shown (from the flagship E9 down to the compact, portable e Ultrasound) and consider: conceiving a product family like this requires the architect to explicitly decide how much variety is demanded (will one machine serve the whole market, or are differentiated offerings required?), and conceiving a family also hints at product evolution (will the whole family launch in parallel, or will it be phased into the market over time?): questions that matter regardless of whether the underlying platforming is extensive or minimal.

Suggested answer: Different user settings can justify different combinations of portability, imaging capability, workflow, serviceability, and cost. A flagship and a portable product need not share all internal components merely because they share branding. Decide the needed variants from segment requirements, then investigate actual reusable architecture and interfaces. Parallel launch may shorten market rollout but require more simultaneous resources; phased launch can enable learning while introducing divergence and compatibility risks. The historical family picture alone cannot establish the best strategy.

Figure 10.7 · Platforming Benefits: Conception and Development

Phase	Potential benefits
Conception	Faster variants; entry into niche markets; easier deployment of new technology through common interfaces; technology risk concentrated in fewer parts
Development	Shared engineering; less repeated testing and commissioning; shared test equipment; reusable or amended certifications

Condensed from Crawley, Cameron & Selva (2016), Fig. 10.7. Benefits depend on actual sharing across variants.

• A platform can reduce the unique work needed for a new variant, allowing a faster response to a newly identified market.
• Common interfaces can simplify technology upgrades; shared tests and certifications can reduce repeated development effort.
• None of these is automatic: verify which parts and approvals can truly be shared.

Figure 10.7 · Platforming Benefits: Production and Operations

Phase	Potential benefits
Production	Shared tooling; learning-curve labor savings; scale economies; volume purchasing; lower safety stock; flexibility in variant output
Operations	Shared sustaining engineering and facilities; transferable operator training; purchasing and inventory savings; shared inspections and compliance work; flexibility in staffing

Condensed from Crawley, Cameron & Selva (2016), Fig. 10.7. Evaluate benefits over the entire product family and lifecycle.

• Shared parts can raise order volume and reduce inventory buffers; shared processes can support switching production volume among variants.
• Operators and maintainers may transfer skills across products if the commonality is real and operationally meaningful.
• Compare family-wide savings with the investment required to create and sustain the platform.

Discussion: When would common branding produce none of these benefits?

Suggested answer: When products share a name but have separate components, interfaces, tooling, test procedures, and support systems.

Figure 10.8 · Platforming Costs: Before Production

Phase	Costs and drawbacks
Conception	Future variants must use shared parts; schedule and brand risk concentrate; variants may cannibalize sales; a sole supplier may raise prices
Development	Designing for several use cases and more flexible test equipment adds cost

Condensed from Crawley, Cameron & Selva (2016), Fig. 10.8.

Figure 10.8 · Platforming Costs: Production and Use

Phase	Costs and drawbacks
Production	Lower-end variants may carry costly higher-end parts; configuration control and production capacity become harder to manage
Operations	A shared part can fail across many variants; performance may fall short of a unique optimized design

Condensed from Crawley, Cameron & Selva (2016), Fig. 10.8.

• Examine platforming costs throughout the lifecycle. Conception can constrain future variants and concentrate schedule, brand, or product-cannibalization risk.
• Development must accommodate multiple use cases and may require more flexible test equipment.
• Production can force smaller products to use components sized for larger ones, while adding configuration-management work.
• In operation, a common-part failure may affect several variants, and shared components may not perform optimally in every application.
• Compare these costs with the savings from shared investment. The decision depends on the expected family, production volumes, and required differences among variants.

Discussion: When can sharing a component make a smaller product worse?

Suggested answer: The shared component may be sized for a higher-end variant, adding mass, cost, or unused capability. Compare family-wide savings with each variant’s performance and differentiation needs.

Section 10.9 Summary

• Platforming is the deliberate, forward-looking sharing of parts and process across a product family: distinct from simple reuse
• Sharing supports product variety, but requires investment and introduces costs and risks throughout the lifecycle
• The architect must weigh the benefit of shared investment against the constraints it locks in for every future variant

Review. Students should be able to state the reuse/platforming distinction precisely (known-vs-predicted performance and use case), describe what a product line or product family is (and that it doesn’t necessarily imply shared architecture), and name at least one cost or drawback of platforming from each of the four phases (conception, development, production, operations). This closes out the downstream half of the chapter: implementation, operations, Design for X, and product evolution: mirroring the upstream half covered earlier (strategy, marketing, regulation, technology). We’ve now surveyed four upstream influences and four downstream influences on the architect’s decisions. The next section shows these don’t operate independently or additively: they interact, in a iterative model the book calls the ABCD Product Case.

Discussion: What evidence would justify investing in a platform?

Suggested answer: Credible demand for the variants, meaningful common requirements, and lifecycle benefits that outweigh development overhead, compromises, and shared risks. Common branding alone is insufficient.

10.10 Combining Influences: The ABCD Product Case

Combining Influences Iteratively

• Upstream and downstream influences interact. Revisit goals and constraints as concept options develop
• Innovation traditionally derives from one of two sources: a new customer need, or a new technology that improves the performance/cost ratio of meeting an existing need
• This is a simplified view: it misses value-chain integration, market expansion strategies, and installed-base service strategies: but it’s a useful anchor

Introduce the chapter’s synthesizing framework. State plainly why a simple additive approach fails, since it’s the section’s opening thesis: having discussed upstream and downstream influences, it’s tempting to think of them as a checklist: tackle each influence in sequence, enumerate its goals and constraints, then sum them all up to produce the concept. The book explicitly rejects this as too linear; it’s not possible to treat these influences that way in reality, because they interact with and constrain each other.

Give students the book’s own simplified starting point for how innovation actually gets triggered, while being honest about its limits. Traditionally, innovation in products and systems is thought to derive from one of two sources: the firm has identified a new customer need, or the firm has identified (or commercialized) a new technology that delivers a higher performance-to-cost ratio in satisfying an existing need. The book’s own example pairing nicely illustrates the two: adding an icemaker to a refrigerator is responding to a customer need using existing, well-understood technology, whereas adding automatic tracking of stored food depends specifically on the development of new RFID (radio-frequency identification) technology: technology-driven, not need-driven, innovation.

Be candid with students, exactly as the book is, that this two-source model is a deliberately simplified perspective on product strategy: it does not express strategies that capture new value in the value chain through backward or forward integration, strategies that leverage home markets against regional or global expansion, or strategies that leverage a firm’s installed base of hardware to deliver high-margin service offerings. Despite this simplification, it’s useful as an anchor around which to organize the highest-level considerations when introducing an architectural innovation into a corporation: which is exactly the role it plays in the ABCD framework diagram on the next slide.

Discussion: Why can’t upstream influences simply be added into one score once?

Suggested answer: They interact: a technology changes cost, which changes the business case and potentially the target market. Iteration is needed to obtain a mutually consistent architecture and business proposition.

Figure 10.9 · The Initial ABCD Framework

Architecture Business Case Decision: two iterative cycles. Technology and customer needs feed in; system architecture sets goals for the business case, which returns solutions back to the architecture. Source: Crawley, Cameron & Selva (2016), Fig. 10.9.

Walk through this diagram slowly, since it’s the conceptual core the rest of the chapter builds on, and its central claim, two circles connected by two arrows going in opposite directions, is easy to glance past without absorbing. On the left, a “System Architecture” cycle; on the right, a “Business Case” cycle; both are fed from outside by the two innovation sources just discussed (technology feeding in from above the left circle, customer needs feeding in from above the right circle). The two circles are connected by two distinct arrows, and it’s the direction of each arrow that carries the real content: “Goals” flows from the System Architecture circle toward the Business Case circle, and “Solutions” flows from the Business Case circle back toward the System Architecture circle.

Spell out exactly what that means in practice, since the diagram alone is abstract: when a customer need has been identified, that need first sets goals for the system architecture: and the architect’s job is to evaluate whether a solution meeting those goals is technically feasible, which in turn helps determine whether the business case actually “closes” (survives financial scrutiny) based on the cost of that solution. When, instead, product innovation derives from a new technology, the direction of the interaction reverses somewhat: the architect must evaluate whether the resulting technical solution actually addresses genuine customer needs, feeding back into the business case from the technology side. Either way, needs-driven or technology-driven, the deep point of this figure is that architecture and business case are not two independent workstreams that get combined at the end; they co-evolve, iterating against each other continuously as the “acronym” ABCD’s name suggests: Architecture, Business Case, Decision.

Discussion: What feedback should flow from architecture to the business case?

Suggested answer: Achievable performance, development and lifecycle costs, schedule, and risks. These can change projected demand, price, investment, and whether the product remains attractive.

The Architect ↔︎ Business Case Interaction

• When product innovation identifies a customer need, that need sets goals for the system architecture: the architect evaluates feasibility and helps determine whether the business case “closes” (survives financial scrutiny) based on solution cost
• When product innovation derives from a new technology, the architect must evaluate whether the resulting solution actually addresses customer needs
• Architecture and the business case develop together, with each informing revisions to the other

Consolidate the two-directional interaction from the previous slide into precise, restatable language, since this is exactly the kind of thing worth being able to explain crisply on an exam or in a design review. Needs-driven path: customer need → goals for system architecture → architect evaluates technical feasibility → informs whether the business case “closes.” Technology-driven path: new technology → candidate solution → architect evaluates whether that solution addresses a real customer need → informs the business case from the other direction. In both directions, notice the architect sits precisely at the hinge point between the technical and the financial: translating goals into feasibility assessments, or translating available solutions into value assessments.

It’s worth flagging, since it recurs throughout the whole chapter’s framing: “closing” is standard business terminology worth defining precisely for students who haven’t encountered it: a business case is said to “close” when the projected revenues are earning sufficient margin to merit the investment. The book draws a deliberate parallel: just as the business case has to close, the technical architecture similarly has to close: meaning the goals are actually met by the proposed technical solutions, the required technology is present or developed, and the architecture can be delivered by the planned supply chain. Both cycles have to close simultaneously, not just the financial one, before you have a viable product proposal.

Suggested answer: Technical closure means a credible integrated solution meets the goals with available or developable technology, suppliers, and implementation resources. Business closure means the projected benefits and revenues justify the full investment and lifecycle costs under stated assumptions. Neither is sufficient alone: a feasible product can be economically unattractive, while a profitable spreadsheet can depend on impossible performance or schedules. Iterate both models and test the assumptions linking price, demand, performance, cost, and delivery.

Figure 10.10 · The Full ABCD Framework

External drivers now flow in on both sides: regulation, standards, competence, and legacy elements shape the architecture cycle; competitive environment, strategy, and channels shape the business case cycle. Platforms and product lines converge on a proceed / do not proceed decision. Source: Crawley, Cameron & Selva (2016), Fig. 10.10.

• Figure 10.10 adds external influences to both cycles of the ABCD framework. Regulation, standards, enterprise capabilities, and legacy elements influence architecture. Competition, strategy, and sales channels influence the business case.
• These influences interact through the proposed product. A technically feasible architecture may not support a viable business case, while an attractive market opportunity may require capabilities the enterprise lacks.
• Platforms and product lines add assumptions about shared investment and future variants. Revise the architecture and business case together until the evidence supports a proceed or do-not-proceed decision.

Discussion: Why do channels belong in a framework about architecture?

Suggested answer: Distribution and service channels impose packaging, support, and variant needs. Conversely, an architecture may enable or obstruct the way the enterprise intends to sell and support it.

Section 10.10 Summary

• The ABCD framework models architecture and business case as two interacting cycles
• Technology and customer needs are the two most common entry points: but the full framework adds regulation, competence, competitive environment, and strategy as further external drivers
• The two cycles converge on a single decision: proceed with the product, or not

Review before the closing case study. Students should be able to draw the ABCD framework’s basic two-circle shape from memory, correctly place “goals” and “solutions” as the two directional arrows connecting the circles, name the six additional influences layered onto the full version (competitive environment and regulation on the architecture side, competence/supply chain and legacy on the architecture side as internal drivers, and competitive environment, strategy, and channels on the business-case side), and explain what it means for both the architecture and the business case to “close” simultaneously at the Decision point. This chapter’s upstream and downstream influences are now unified into this single framework: which sets up the closing case study perfectly, since the B-52/B-2 comparison is a real historical instance of exactly these kinds of influences producing different architectural outcomes for what is, on paper, the same mission.

Discussion: What does reaching a product decision require from both framework cycles?

Suggested answer: A credible technical solution and a credible business case with consistent assumptions. Resolve major disagreements about performance, resources, timing, and value before commitment.

Box 10.4 Case Study: The B-52 and B-2 Bombers

Figure 10.11 · Two Bombers, Two Architectures

• Both aircraft deliver the same primary function, long-range strategic bombing, with different architectures
• The B-52: a conventional tube-and-wing design. The B-2: a flying wing
• What upstream and downstream influences led to such different architectural choices for the same mission?

• The B-52 and B-2 both serve long-range strategic bombing missions, but use different forms: tube-and-wing and flying wing.
• Compare how mission requirements, technology, and lifecycle considerations affect their architectures. Similar primary functions do not imply identical requirements or tradeoffs.
• The following civil-transport examples examine a related downstream issue: how different aircraft architectures accommodate product families.

Suggested answer: Early choices include overall tube-and-wing versus flying-wing configuration, tail arrangement, and exposed versus integrated engine placement. These couple structural, aerodynamic, signature, control, integration, and maintainability considerations and help define the feasible performance envelope. Different mission priorities, available technologies, and development contexts can favor different solutions despite the same broad functional label. Keep the comparison at the chapter’s architectural level: detailed geometry and operating requirements are needed to quantify performance, and a photograph cannot prove which specific tradeoff dominated the historical decision.

Figure 10.12 · Scaling a Product Family

Left: the Airbus A350 tube-and-wing family: a shared wing, stretched or shortened fuselage. Right: a proposed flying-wing civil transport family, scaling by adding center-body sections rather than stretching a tube. Source: Crawley, Cameron & Selva (2016), Fig. 10.12. (Left) © Airbus. (Right) Liebeck (2004), Journal of Aircraft 41(1), by permission of AIAA.

• The civil-transport examples compare ways of changing passenger capacity across a family.
• A tube-and-wing family can share a wing while varying fuselage length. Sizing the common wing for the heaviest variant can leave smaller variants with more wing capacity than they need.
• The proposed flying-wing family adds center-body sections. Its lifting area changes with capacity rather than relying on a separately stretched fuselage.
• Use the figures to examine the consequences of each sharing strategy.

Suggested answer: In the book’s conceptual comparison, a tube-and-wing family changes capacity mainly by altering fuselage length while seeking wing and subsystem commonality. A blended-wing-body proposal adds center-body sections, changing the integrated lifting and volume geometry. Commonality can save development effort while imposing excess capability, mass, or constraints on smaller variants. Treat the illustration as a platforming argument rather than proof that every production A350 variant has identical wings or that scaling requires no aerodynamic, structural, control, or certification changes.

Why the Architectures Scale Differently

• For tube-and-wing aircraft, the wing is sized for the heaviest family member: since wings are expensive to optimize, they’re shared across the family with minor changes
• Net effect: the wing is “overdesigned” for the smallest family member: it can produce more lift than that aircraft needs
• The flying-wing family instead scales by splitting along the centerline and inserting center-body sections: a different scaling mechanism

• In the tube-and-wing example, sharing an expensive wing design reduces repeated development, but smaller aircraft inherit capacity sized for the largest variant.
• Relate this to the production cost of platforming: a lower-capacity product may use higher-capacity components.
• The flying-wing proposal changes the center-body geometry to increase capacity. Compare the associated changes in lifting area and structure.

Discussion: Why does changing capacity affect a blended configuration differently?

Suggested answer: Its load-carrying volume and lifting geometry are tightly integrated. Changing one can alter the other, while a more separated arrangement offers different opportunities for component commonality.

Figure 10.13 · Lift Distribution, Compared

Dark gray shows the lift-producing region on each architecture. For tube-and-wing, the fuselage produces almost no lift: lengthening it to add capacity forces the wing to grow to support the extra weight. For the flying wing, lift scales naturally with the size of the variant. Source: Crawley, Cameron & Selva (2016), Fig. 10.13, after Liebeck (2004).

• Trace the shaded lift-producing regions in both drawings. The tube-and-wing design concentrates lift mainly in the wing, while the flying-wing body’s size also contributes to lifting area.
• Increasing passenger capacity adds weight. The family must provide sufficient lift for each variant.
• Compare how each architecture changes with capacity and which parts can remain common. This illustrates how product-family assumptions influence architectural choices.

Discussion: What should be held constant when comparing lift distributions?

Suggested answer: The comparison’s operating conditions, total lift requirement, geometry assumptions, and normalization. A plotted shape alone cannot establish complete aircraft performance or family economics.

Product Families and Architectural Choice

A downstream consideration, how a family of products needs to scale, can be a first-order driver of architectural choice, just as important as the primary function itself.

• Both architectures deliver the mission function; the B-2’s flying wing also buys low radar cross-section (a different downstream/upstream driver: stealth requirements)
• The civil-aircraft family comparison shows how scaling requirements can favor different forms; the bomber comparison adds distinct mission and technology pressures

• A product-family requirement can influence the initial architecture because different forms accommodate capacity changes differently.
• Stealth provides another influence in the military examples: the B-2’s flying-wing form contributes to its low radar cross-section.
• Keep the product-family illustration distinct from the complete historical explanation of either bomber. Mission requirements, technology, and implementation constraints must also be considered.

Discussion: What is the general lesson beyond the aircraft example?

Suggested answer: Early allocation and coupling choices shape later scalability and reuse. Assess the intended product family before assuming that a successful point design will scale conveniently.

Chapter 10 Summary

• Upstream influences: strategy, marketing, regulation, and technology: shape the goals and constraints the architect must resolve before architecture can begin
• Downstream influences: implementation, operations, Design for X, and product evolution: must be compressed and fed back into decisions made much earlier
• The ABCD Product Case frames architecture and business case as two coupled iterative cycles, converging on a proceed/no-proceed decision
• The aircraft case study illustrates how mission requirements and lifecycle considerations can lead to different architectures

Tip

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

• Review upstream influences from strategy, marketing, regulation, and technology. These help define goals and constraints.
• Review downstream influences from implementation, operations, and product evolution. Bring the relevant details into early decisions.
• The ABCD framework connects architecture and business-case development through iteration.
• Use the aircraft examples to explain why similar primary functions can lead to different architectures under different requirements and constraints.

Discussion: What is one question to ask before freezing a concept?

Suggested answer: Ask whether implementation, operation, evolution, and business assumptions support it. A concept attractive under one narrow metric may fail under the full enterprise and lifecycle context.

Next: Translating Needs into Goals

Chapter 11 returns to Part 3’s synthetic process, examining how the architect converts fuzzy stakeholder needs into concrete, testable goals.

• Chapter 11 develops stakeholder needs into explicit goals. Connect this task to the ambiguous upstream inputs examined here.
• Ask students to identify a need that would require clarification before it could guide an architectural decision.