Solution-Neutral Function and Concepts

Systems Architecture · Chapter 7

Aykut C. Satici

Reverse and Forward Engineering

Chapters 4–6 pursued reverse engineering: the system already exists, so we analyzed its form, function, and architecture
The pump and bubblesort examples kept the systems small enough to follow each analytical step
This chapter shifts to forward engineering: two new ideas, solution-neutral function and concept, plus two higher-complexity systems: an air transportation service and a home data network

Tip

Table 7.1 amends the Chapter 5 questions and adds a new one (7a): collating everything into a method for synthesis, not just analysis.

Chapters 4–6 analyzed existing systems. This chapter begins developing alternatives from a statement of need.
Simple examples let students learn the methods before applying them to larger systems.
Now two things at once: shift to forward engineering (nothing built yet, work toward a design), plus two new tools: solution-neutral function and concept
Two new running examples, chosen for realistic complexity: air transportation service (architecting applies to services, not just products) and home data network (“a microcosm of global information networking”)
Fragment previews Table 7.1: Chapter 5’s questions, amended, plus new Question 7a: one coherent method now supporting synthesis, not just analysis

Discussion: How does forward engineering differ from reverse engineering?

Suggested answer: Reverse engineering infers intent, function, and structure from an existing system. Forward engineering starts with a need and develops candidate concepts and architectures; several solutions may meet the same intent.

Box 7.1 · Principle of Solution-Neutral Function

“We cannot solve our problems with the same thinking we used when we created them.”: Albert Einstein

Poor system specifications frequently contain clues about an intended solution, function, or form: and those clues narrow the architect’s options before exploration even begins
Use solution-neutral functions where possible, and use the hierarchy of solution-neutral statements to scope how broad an exploration should be

First named principle: connect the Einstein quote to something concrete: specs that smuggle in a solution disguised as a requirement
Happens constantly, often invisibly: “add a corkscrew to the kitchen drawer inventory” already silently decided the solution before anyone asked the actual need (getting the cork out, or more broadly, accessing the wine)
Such a clue narrows exploration before it starts, foreclosing whole classes of alternatives (gas pressure, suction: next couple slides)
Prescription (have students repeat it back): state functions solution-neutrally: what, never how: and use the hierarchy of solution-neutral statements to scope how broad an exploration should be
Sets up the rest of the chapter as a rigorous methodology for exactly this

Discussion: Rewrite ‘install a bigger pump’ without choosing the solution.

Suggested answer: ‘Keep basement water below an agreed level during specified inflows’ states an outcome. Pumping, drainage, or preventing ingress can then be compared within the project’s allowed scope.

Figure 7.1 · Concepts for Removing a Wine Bottle Cork

A corkscrew opens a wine bottle. But can we name other concepts for the same job?
We describe concepts as an operand-process-instrument set: cork (operand) pushing (process) injected gas (instrument)
Pulling alone is insufficient to describe a concept: “cork pulling with a screw” is a corkscrew

Source: Crawley, Cameron & Selva (2016), Fig. 7.1.

Chapter’s running worked example: simple, everyone has physical intuition, why the book leads with it
Everyone defaults to “corkscrew”: push further: how do you describe a corkscrew generally? Uses a screw to pull. Is pulling the only way?
Get creative: glue a tab and pull (no screw); create suction around the cork (a pressure-difference concept); pressurize air inside the bottle, pushing the cork out; wine steward’s fork-like device that shears the cork’s sides off
Diagram = structured operand-process-instrument: operand always cork; process varies (pushing/shearing/pulling); each process has its own instruments (gas for pushing; fork/tube for shearing; suction/screw for pulling)
“Pulling” alone doesn’t specify a concept: need the instrument too. “Cork pulling with a screw” = corkscrew; pulling with suction is an entirely different concept sharing the same process

Suggested answer: Pulling is one mechanism, not the only way to access the contents. A screw can grip a cork for extraction; another conceptual route uses a pressure difference to push it outward. Broader intent also admits different closures or packaging. The architectural lesson is to distinguish the operand (cork), process (moving/removing it), and enabling form before generating alternatives. Do not equate an injected-gas mechanism with suction: pressure inside the bottle and reduced pressure outside are different concepts.

Solution-Neutral Function in a Hierarchy

Drawing Figure 7.1 is itself a form of structured creativity (Ch. 12): pulling led us to think about pushing, which we might otherwise have missed
Solution-neutral function exists in a hierarchy: translating the cork generalizes to removing the cork, which generalizes to opening the bottle, up to accessing the wine

Tip

The breadth of concepts we generate depends heavily on the functional intent we pose: the more solution-neutral the expression, the broader the set of concepts.

Meta-lesson from the previous slide: laying out Figure 7.1 systematically (rather than jumping to “corkscrew”) is itself a technique: formalized later (Ch. 12) as structured creativity
Starting from “pulling” and asking “what else could do this?” is precisely what surfaced “pushing” (gas): nobody proposes that spontaneously
Structuring the concept space, even informally, surfaces options unstructured brainstorming misses
Second big idea: solution-neutral function forms a genuine hierarchy, not one fixed abstraction level: “translating the cork” → “removing the cork” → “opening the bottle” → “accessing the wine”; each step up trades specificity for breadth
Rule of thumb for the rest of the course: the more solution-neutral (higher up the hierarchy) the stated intent, the broader the resulting concept space: and the more work to explore it fully

Suggested answer: At the “pull the cork” level, alternatives mostly change the gripping or pulling instrument. At “remove the cork,” pushing becomes possible; at “access the wine,” closure and packaging alternatives may enter the space. Each upward step removes an assumed means while preserving a broader purpose. The useful level is the one that exposes meaningful alternatives while retaining the actual constraints of the task.

Figure 7.2 · A Hierarchy of Broader Concepts

Where to stop is a matter of practicality: with a wine bottle already on the table, concepts above “wine accessing” make no sense. Source: Crawley, Cameron & Selva (2016), Fig. 7.2.

Walk top to bottom: illustrating the relationship described on the previous slide
Top: “accessing the wine” (most solution-neutral) → specializes down to “opening” the bottle, or “removing” the cork by “destroying” it (drilling, burning, melting: a different branch from “translating” the cork intact, which leads back to the corkscrew)
“Opening” further specializes into “breaching” the cork or “breaching” the bottle itself
Follow “translating” all the way down → lands exactly at “pushing/shearing/pulling” from Figure 7.1: this diagram extends the previous one upward
Practicality: the architect always decides where in the hierarchy to stop: no formula, a judgment call. Wine bottle already on the table? Absurd to consider concepts above “wine accessing” (e.g. “beverage acquiring”): the actual problem context constrains how far up is worth exploring

Suggested answer: With an existing bottle and a request to serve its contents, preserve that boundary and focus on accessing this wine. Redesigning beverage distribution is outside the immediate problem. If instead the task is to design a new wine-delivery product, packaging and closure choices become legitimate. Stop broadening when the next level changes an agreed need or fixed context rather than offering another way to meet it.

Table 7.1 · Questions for Defining Concept

Question	Produces
7a. Who are the beneficiaries? What is the solution-neutral operand and its value-related attribute/process?	A solution-neutral framing of the desired function
5a. What is the value-related operand-process-form? What is the concept? What other concepts satisfy the same function?	The operand-process-form construct defining the system
5b. What are the internal functions? What are the concept fragments and integrated concept?	The internal processes/operands, first- and second-level

The chapter’s organizing scaffold: same numbering as Chapter 5’s question-based method (5a, 5b), amended with bracketed material, plus new Question 7a
Signals this chapter builds directly on Ch. 5-6, refining the same questions to now support forward, synthetic design work, not just backward analysis
7a (new, comes first): identify beneficiaries, derive solution-neutral operand + value-related attribute/process: the solution-neutral framing just practiced with wine-bottle
5a (amended): what’s the value-related operand-process-form? This is where concept gets defined: next major topic
5b (amended): internal functions, concept fragments, integrated concept: becomes Section 7.4
Treat this table as a running index: everything ahead answers one of these three questions in turn

Suggested answer: Example: a traveler benefits from reaching a destination. 7a: the operand is the traveler, the valued attribute is location, and the intent is transporting between specified places under time and cost constraints. 5a: flying the traveler using an aircraft is one concept; rolling using a train is another. 5b: expand the chosen service into fragments such as reserving, boarding, transporting, and disembarking, with the necessary instruments and operand exchanges. Keep these distinct from merely listing aircraft parts.

7.2 Identifying the Solution-Neutral Function

Deriving a Solution-Neutral Statement

The procedure (Question 7a):

Consider the beneficiary
Identify their need
Identify the solution-neutral operand that, acted upon, yields the benefit
Identify the operand’s attribute

Identify other relevant attributes of the operand
Define the solution-neutral process that changes the benefit-related attribute
Identify relevant attributes of that process

Tip

Two new examples: an air transportation service (beneficiary: the traveler) and a home data network (beneficiary: the surfer).

Concrete step-by-step procedure for Question 7a: an ordered checklist students can follow on future projects:
- Consider who the beneficiary is (specific stakeholder, not abstract “the system”)
- Identify their need in plain language
- Crucial move: identify the solution-neutral operand: the thing that, acted upon, delivers the benefit (still abstract, not specific yet)
- Identify the operand’s benefit-related attribute: the property whose change delivers value
- Optionally, other relevant attributes of the operand
- Define the solution-neutral process that changes that attribute (still abstract)
- Optionally, attributes of that process
Two flagship worked examples for the rest of the lecture: air transportation service (beneficiary: traveler), home data network (beneficiary: surfer). Table 7.2 next works this exact procedure for both

Discussion: What must a solution-neutral statement identify?

Suggested answer: Identify the beneficiary, the operand and valued attribute to change, the process, and relevant conditions. Avoid naming an instrument unless it is a fixed constraint.

Table 7.2 · Formulating the Solution-Neutral Intent

Question	Transportation Service	Home Network
Beneficiary?	Traveler	Surfer
Need?	“Visit a client in another city”	“Buy a cool book”
Solution-neutral operand?	Traveler	Book
Benefit-related attribute?	Location	Ownership
Other operand attributes?	Alone with light luggage	Consistent with tastes
Solution-neutral process?	Changing (transporting)	Buying
Attributes of process?	Safely and on demand	Online

Walk both columns carefully: pause on why the operand choice takes real thought, not obvious at first glance
Transportation: beneficiary = traveler, need = “visit a client in another city” (conceptually rich: going, spending time, returning). Solution-neutral operand = the traveler themselves (not “trip” or “distance”). Benefit-related attribute = location. Other attributes: alone, light luggage. Process = “changing”/“transporting,” attributes: safely, on demand
Full statement (have students say aloud): “safely and on demand transporting to a new location a traveler with light luggage”, nothing says how, still entirely solution-neutral
Home network: beneficiary = surfer, need = “buy a cool book.” Operand = the book; attribute = ownership; other attribute = consistent with tastes. Process = buying, attribute = online
Combined: “buying online a book that the buyer likes”: again no how yet
These two statements become the functional intent driving both worked examples for the rest of the chapter

Discussion: Why is the traveler, rather than the airplane, the operand of the transport service?

Suggested answer: The traveler undergoes the valued location change. The airplane enables that process and is therefore an instrument in this view; it can be an operand in a maintenance process.

Recording Functional Intent

An operating system does not necessarily reveal why its designers chose it. Record the intended benefit and the assumptions behind the design so that later teams can assess them.

In summary: the functional intent for a system should be stated as a solution-neutral function: an operand and a process (with their attributes) linked to value, containing no reference to solution.

Sobering, practical point: easy to underestimate until seen: once a system operates, its intent becomes invisible
Can’t look at a room of running servers and read off why they exist. Can’t look at a plane in flight and recover the stakeholder need
Book’s observation: intent is normally handled casually in real orgs: hallway conversations (“I thought we were building a retro-inspired minivan”), loose concept art, rarely written down rigorously
Record intent explicitly. Reconstructing it from the finished system may be difficult or impossible.
Core rule, worth writing down verbatim: functional intent = solution-neutral function: operand + process + attributes, linked to value, no reference to solution

Discussion: Why should intent remain documented after a system begins operating?

Suggested answer: Intent is not an additional physical action: the realized system executes processes. Intent remains essential for assessing whether those processes deliver the outcome stakeholders wanted.

7.3 Concept

The Notion of Concept

Concept connects a solution-neutral function to a proposed architecture
Concept is the transition point from solution-neutral to solution-specific
It must allow value-related functions to be executed, enabled by form; it establishes the vocabulary for the solution; it implicitly sets design parameters and the level of technology

Motivate why this section exists: a clean solution-neutral statement (Section 7.2) is necessary, but it’s still an enormous leap to a full detailed architecture (Ch. 6/8): too large to jump in one step
Concept bridges that gap: not strictly necessary logically, but enormously useful practically as a tractable intermediate stopping point
Three defining properties:
- Transition point where thinking shifts from solution-neutral to solution-specific
- Must allow the value-related function to be executed, enabled by some (still abstracted) form
- Establishes vocabulary for the rest of the design process; implicitly sets design parameters and level of technology
We’ll see the vocabulary-setting effect concretely on “Concept, Concretely” coming up

Discussion: Is ‘an airplane’ a complete transportation concept?

Suggested answer: It names form but leaves the operand and process implicit. ‘Flying a traveler using an airplane’ expresses how the chosen form enables the intended function.

Box 7.2 · Definition of Concept

Concept is a product or system vision, idea, notion, or mental image that maps function to form. It embodies a sense of how the system will function and an abstraction of the system form: a simplification of the architecture that allows for high-level reasoning.

Concept is a proposed mapping between form and function.

Explain how the definition relates a proposed form to the function it enables.
A concept describes the proposed solution at a level that supports early reasoning. Detailed specifications follow later.
It’s a mapping of function to form: same kind of mapping full architecture eventually captures, just coarser resolution
Embodies a sense of function and an abstraction of form → a simplification of the full architecture, tractable enough to reason about at a high level
Ontological distinction (pause on this): concept is not an attribute of the system (not a “thing it has,” like mass or color): it’s a notional mapping connecting the form attribute and the function attribute. Lives at the level of how we’re choosing to relate them, not as a standalone property

Discussion: Can two concepts share a process but use different instruments?

Suggested answer: Yes: pulling a cork with a screw or another gripping device preserves the process while changing the enabling form. Compare the resulting feasibility and performance.

Figure 7.3 · Concept and Architecture

Concept and architecture both map function to form: concept does it in a general way, architecture in elaborate detail. If you have a concept, it guides the architecture; if you have an architecture, concept rationalizes it. Source: Crawley, Cameron & Selva (2016), Fig. 7.3.

Two panels, direct visual statement: left = concept, a coarse general arrow in a simple form-vs-function grid; right = architecture, same grid but filled with a dense fine-grained matrix: elaborate, high-resolution version of the same mapping
Two-way relationship, both useful in practice:
- Forward (synthesis): concept as a guide, constraining how you build out the full architecture: most of this chapter and the next
- Backward (analysis, Ch. 4-6’s practice): concept rationalizes an existing architecture: compresses overwhelming detail into one comprehensible high-level story
Both directions matter; good architects move fluidly between them

Discussion: What must be added before a concept becomes an architecture?

Suggested answer: Specify internal functions, their allocation to form, relationships, interfaces, and operational arrangements. A concept supplies the central approach but does not resolve all those choices.

Pump and Sorting Concepts

Tip

Pump: solution-neutral function is “moving fluid.” The concept is water (specific operand), pressurizing (specific process), using a centrifugal pump (specific instrument of form).

Tip

Bubblesort is literally the name of a concept: array (specific operand: entries), sequentially exchanging (specific process), using bubblesort (specific instrument).

Naming the specific instrument (centrifugal pump, bubblesort) immediately establishes a vocabulary, sets design parameters, and implies a level of technology

Ground the abstract definition in the two examples students know cold from Ch. 4-6: makes “concept sets vocabulary” concrete, not just asserted
Pump: solution-neutral function = “moving fluid” (says nothing about what fluid or how). Concept specializes: operand → water, process → pressurizing, instrument → centrifugal pump
Naming “centrifugal pump” supplies, for free: a technical vocabulary (motor, housing, impeller), concrete design parameters (impeller speed, pressure rise), and an implied level of technology (above buckets, below jet-engine turbomachinery)
Bubblesort makes the point even sharper: the name is literally the concept. Solution-neutral function = “sorting the array” → specific operand (array entries), process (sequentially exchanging), instrument (the bubblesort algorithm itself)
Just saying “bubblesort” conjures a complete vocabulary, mechanism, and instrument set (down to the code). Contrast with how little is pinned down before the concept is chosen: choosing a concept commits an enormous amount of information all at once

Discussion: Why is a familiar product name sometimes a poor concept description?

Suggested answer: It can hide assumptions about the function and user. State the operand, process, and instrument explicitly so students can distinguish alternative means of delivering the same benefit.

Figure 7.4 · Template for Deriving Concept

Five key ideas (thick borders): solution-neutral operand, specific operand, specific system operating, generic concept form, specific system form. Intent → Function → Form. Source: Crawley, Cameron & Selva (2016), Fig. 7.4.

Three-column structure, left to right: formalizes everything so far into a repeatable procedure
Intent (left): solution-neutral operand, sitting outside the dashed “Concept” boundary: the precursor, not itself part of the concept
Function (middle): specific operand + specific operating process: where the solution-neutral operand gets specialized (specialization-triangle relationship, echoes OPM notation from Ch. 3)
Form (right): specific instrument of form, connected to the process it enables
Five highlighted shapes to name from memory: solution-neutral operand, specific operand, specific system operating, generic concept form, specific system form
Reconnect to examples: pump: “moving fluid” → water (operand) → pressurizing (operating) → centrifugal pump (form). Bubblesort: array (solution-neutral) → array entries → sequentially exchanging → bubblesort (form, not quicksort)
This is the operational procedure to use whenever deriving a concept from solution-neutral intent in project work

Discussion: Where does the first commitment to a particular solution enter the template?

Suggested answer: Specializing the function and selecting its enabling form introduce commitments. Track them explicitly so an assumed technology does not masquerade as the original need.

Table 7.3 · Five Systems, Solution-Neutral to Concept

Solution-Neutral Operand	Solution-Neutral Process	Specific Operand	Specific Process	Specific Instrument
Fluid	Moving	Water	Pressurizing	Centrifugal pump
Array	Sorting	Array entries	Sequentially exchanging	Bubblesort
Cork	Translating	Cork	Pulling	Screw
Traveler	Transporting	Traveler	Flying	Airplane
Book	Buying	Internet	Accessing	Home DSL connection

There is no single relationship between solution-neutral and specific operand/process: specializing to concept requires creativity, not automation.

Comparative capstone: same template applied across all five running examples from Ch. 4-7, side by side
Quick pattern reinforcement: fluid/moving → water/pressurizing (centrifugal pump); array/sorting → array-entries/sequentially-exchanging (bubblesort); cork/translating → cork/pulling (screw); traveler/transporting → traveler/flying (airplane); book/buying → internet/accessing (home DSL)
Key teaching point (side-caption, dwell on it): no single consistent relationship between solution-neutral and specific operand. Sometimes identical (cork stays cork), sometimes totally different (book → internet)
Foreshadows Box 7.3’s catalog of specialization patterns. Lesson: specializing to concept is not mechanical: requires real creativity and judgment, no shortcut formula

Discussion: What makes the five examples comparable despite their different domains?

Suggested answer: Each can be described through an operand, a process changing it, and enabling form. The common structure supports reasoning; it does not imply identical performance models.

Box 7.3 · Specializing Function to Concept

A few of the patterns the specific operand can take, relative to the solution-neutral operand:

Completely different operand and process: entertaining a person by watching a DVD
Same process, different operand: choosing a leader by choosing the president
Part of the solution-neutral operand: opening the bottle by removing the cork
A type of the solution-neutral operand: moving fluid by pressurizing water
An attribute of the solution-neutral operand: amplifying a signal by increasing signal voltage

Tip

Similar patterns apply to specializing the process: e.g., transporting a traveler by flying a traveler.

Cashes out the previous slide’s observation: catalog of the patterns that can occur, so students have a checklist rather than specializing haphazardly
Completely different: entertaining a person → watching a DVD (neither word appears in the original)
Same process, different operand: choosing a leader → choosing the president
Part of the solution-neutral operand: opening the bottle → removing the cork (cork is part of the bottle)
A type of the solution-neutral operand: moving fluid → pressurizing water (water is a type of fluid: the class/specialization relationship from Ch. 3, now applied to concepts)
An attribute of the solution-neutral operand: amplifying a signal → increasing signal voltage
Same variety of patterns recurs when specializing the process instead, holding operand fixed: transporting a traveler → flying a traveler (“traveler” unchanged, only the verb changes)
Encourage students, in their own project work, to check their concept against this catalog: which pattern does it follow, and would a different pattern reveal concepts they hadn’t considered?

Suggested answer: For “open a bottle by removing its cork,” the specific operand is a part of the broader operand. A different specialization can focus on an attribute: change the closure’s attachment state, admitting a threaded cap when packaging redesign is allowed. For “move fluid by pressurizing water,” water specializes the fluid type. A strong student answer identifies the relationship and shows how another pattern changes the available concepts without silently changing a fixed requirement.

Table 7.4 · From Solution-Neutral to Concept

Question	Transportation Service	Home Network
Specific operand?	Traveler	Internet
Benefit-related attribute?	Location	Access
Other operand attributes?	Alone with light luggage	High-speed connection
Specific process?	Flying	Gaining (accessing)
Attributes of process?	In less than 2 hours	Reliably
Generic concept form?	“Flyer”	“Accesser”
Specific form?	Airplane	Home DSL connection
Attributes of form?	Commercial	Inexpensive

Direct continuation of Table 7.2 (which stopped at solution-neutral function): push both examples through the Figure 7.4 template to a fully specified concept
Transportation: specific operand stays “traveler” (“same as solution-neutral” pattern), attribute “location,” other attributes “alone, light luggage.” Process specializes to “flying,” attribute “in less than 2 hours.” Generic “dummy form” placeholder “Flyer” → specific form “airplane,” attribute “commercial”
Plain language: “a single traveler with light luggage, flying in less than two hours, using a commercial airplane”
Home network: specific operand jumps “book” → “internet” (“completely different operand” pattern). Attribute “access,” other attribute “high-speed connection.” Process “gaining”/“accessing,” attribute “reliably.” Dummy placeholder “Accesser” → specific form “home DSL connection,” attribute “inexpensive”
Plain language: “reliably accessing a high-speed internet connection using an inexpensive home DSL network”
Have students say both sentences aloud: reads almost like natural language (Chomsky noun-verb-noun parallel from Ch. 2)

Discussion: Does a commercial airplane concept settle the complete journey?

Suggested answer: No. It selects a transport mechanism but leaves access, ticketing, boarding, transfers, and arrival arrangements. Those processes must be integrated to satisfy the traveler’s broader need.

Naming Concepts

No simple convention exists: rationally, concepts are named operand + process + instrument, as in light + emitting + diode
Short names often leave part of the concept implicit. “Mower” names an instrument through its process, without specifying the mechanism
Sometimes a concept is named for an attribute: “wireless” described two entirely different concepts, a century apart

Tip

Develop several alternatives before comparing and selecting concepts (Ch. 11).

Honest, practical note: no single simple naming convention: but rationally, systematic naming = operand + process + instrument
LED = the book’s cleanest real example: light (operand) + emitting (process) + diode (instrument), all three legible in the name
A concept name may omit its operand or mechanism. “Mower” suggests an instrument that mows, while “grass” alone names only an operand.
“Wireless” story: same word named two completely different concepts a century apart: early 1900s = radio broadcasting (literally no wires), early 2000s = local data networking (Wi-Fi)
Generate alternative concepts before applying the selection criteria developed in Chapter 11.

Discussion: What should a useful concept name communicate?

Suggested answer: Enough of the process and enabling form to distinguish the candidate, without implying unsupported detail. A concise name should be backed by a precise concept statement.

Table 7.5 · Naming Concepts (1 of 2)

Naming pattern	Operand	Process	Instrument	Familiar name
Operand–process–instrument	Light	Emitting	Diode	Light-emitting diode
Operand–process–instrument	Data	Storage	Warehouse	Data warehouse
Operand–process	Lawn	Mow	implied “-er”	Lawn mower
Operand–process	Hair	Dry	implied “-er”	Hair dryer
Operand–instrument	Cork	implied removing	Screw	Corkscrew
Operand–instrument	Fire	implied burning	Place	Fireplace
Operand–instrument	Hat	implied storing	Rack	Hat rack

Read across: a short name may hide the process or instrument. Recover all three before comparing concepts.

Adapted from Table 7.5. “Implied” entries correspond to the parenthesized words or suffix in the book.

Table 7.5 · Naming Concepts (2 of 2)

Naming pattern	Operand	Process	Instrument	Familiar name
Operand–instrument	Suit	implied carrying	Case	Suitcase
Process–instrument	implied food	Dining	Room	Dining room
Process–instrument	implied stuff	Carrying	Case	Carrying case
Process	implied TV	Control	implied “-er”	TV controller
Process	implied image	Project	implied “-er”	Projector
Instrument	implied head	implied covering	Hat	Hat
Instrument	implied food	implied serving	Table	Table
Instrument	implied person	implied carrying	Bicycle	Bicycle

A name is a shorthand for a concept. State its operand, process, and instrument when the shorthand could conceal a design choice.

Adapted from Table 7.5. The familiar-name column expands the book’s examples for classroom reading.

Figure 7.5 · A Tree of Concept Options

An operand layer, a process layer, and an instrumental form layer. Fewer operand options than process options, and fewer process options than form options: a decision tree. Source: Crawley, Cameron & Selva (2016), Fig. 7.5.

General template for organizing concept alternatives: next several slides apply it to each running example
Three layers: operand (top), process (middle, several operating options can branch off one operand), instrumental form (bottom, several form options can branch off each process)
Predictable tree shape: fewer operand options than process options, fewer process options than form options: tree widens going down (many physical/technological ways to implement a given operating principle, fewer fundamentally different operating principles per operand)
Connects back to Section 7.1’s wine-cork example (pushing/shearing/pulling generated deliberately, not jumping to corkscrew): this tree is the general-purpose tool for that same structured alternative-generation, applied next to pump, bubblesort, transportation, home network

Discussion: Does a concept tree prove that every possibility has been considered?

Suggested answer: No. Its branches reflect the chosen scope and classification. Challenge omitted mechanisms and mixed abstraction levels, then document what was deliberately excluded.

Figure 7.6 · Pump Concept Options

Seven non-exhaustive concept options for moving fluid: from pressurizing with a centrifugal pump, to blowing air with a fan. Source: Crawley, Cameron & Selva (2016), Fig. 7.6.

Apply the decision-tree template to the pump: from “fluid”/“moving,” branches by specific operand: water vs. air
Water: pressurizing (centrifugal or axial-flow pump), accelerating (a different centrifugal pump, or jet ejector), displacing (rotary or reciprocating displacement pump)
Air: blowing (fan)
Seven distinct concept options total, explicitly non-exhaustive
Notice: centrifugal pump appears twice (under pressurizing and accelerating): same instrument, two different operating principles. Instrument, process, operand are three separable choices, not one bundled decision
Concept space for “moving fluid” is much richer than the default answer (“get a pump”) without structured exploration

Discussion: If we choose a different pumping mechanism, what still has to remain fixed for a fair comparison?

Suggested answer: The required fluid movement and relevant conditions, such as flow, pressure change, and fluid properties. Comparing mechanisms under different requirements confuses solution quality with problem changes.

Figure 7.7 · Bubblesort Concept Options

Three principles of operation for sorting an array: sequentially exchanging, inserting, displacing: each with specific algorithms. Source: Crawley, Cameron & Selva (2016), Fig. 7.7.

Same template applied to sorting: “array”/“sorting,” array entries as the operand throughout, three operating principles:
- Sequentially exchanging: bubblesort, or cocktail sort
- Inserting: insertion sort, or shell sort
- Displacing: partitioning algorithm, notably quicksort
Satisfying for students with programming background: sorting algorithms they know, now organized as principles + instruments
Quicksort (often taught as just “a fast algorithm”) sits under a different operating principle than bubblesort/insertion sort: reinforces the pump lesson: concept options aren’t just different implementations of the same idea, some represent fundamentally different operating principles the architect must recognize before comparing fairly

Discussion: Is sorting the same concept as bubblesort?

Suggested answer: Sorting states a broader function. Bubblesort specializes the process through repeated comparison and exchange; other algorithms can meet the sorting intent with different performance tradeoffs.

Figure 7.8 · Transportation Concept Options

Flying, rolling, and floating: each linked to common instruments. Traveler is the only likely operand; transporting is a long-standing human endeavor. Source: Crawley, Cameron & Selva (2016), Fig. 7.8.

Template applied to the transportation service: scaling up practical complexity from pump/sorting
Specific operand barely branches (traveler is really the only sensible one): process branches into three long-standing strategies: flying (airplane, helicopter), rolling (car, train), floating (boat, e.g. sailboat)
Unlike pump/sorting (modern, narrow engineering problems), transporting is “a long-standing human endeavor”: millennia of technologies; the book limits the tree to these three for tractability, not exhaustiveness
Ask students what’s missing (walking, tunneling, space travel): reinforces that “non-exhaustive” is a real constraint the architect must accept

Suggested answer: Walking is a clear omitted concept for transporting a traveler over an appropriate distance. A moving walkway supplies another mechanism. Tunneling usually changes the route or infrastructure rather than defining the movement process itself: a train in a tunnel still rolls. Space travel matters only if the destination and constraints make it relevant. Add branches at comparable abstraction levels and test their feasibility; a concept tree is a structured aid, not proof of exhaustive coverage.

Figure 7.9 · Home Network Concept Options

With online book buying already specified, this example compares methods of accessing the internet. Source: Crawley, Cameron & Selva (2016), Fig. 7.9.

Template applied to the home network: useful contrast: this tree is narrower, ask students to articulate why
Operand (“Internet”) and process (“accessing”) barely branch: no way around needing internet access to buy a book online. Only the instrument branches: home DSL, home cable, mobile broadband, public WiFi, work cable
The scope of the stated function affects the available alternatives. Here, online buying fixes the basic approach, leaving the access method open.

Suggested answer: The framing has already committed to accessing online information, so much of the operand and process choice is fixed. The remaining branches chiefly concern access infrastructure. If the underlying need is reading a book, borrowing a printed copy becomes possible, but it lies above this narrow intent in the hierarchy. The small option set reflects earlier commitments and the modeled context, not a general lack of creativity in networking.

Broader Concepts and Hierarchy

The concept-option analysis looked “downward” toward increasing detail: but we can also look “upward” toward increasingly general intent
Why move fluid? Maybe to dry a basement. Why dry a basement? Maybe to improve living conditions
There is hierarchy in functional intent, just as there is hierarchy in built systems

The specific function at one level becomes the solution-neutral functional intent at the next level down.

Pivot: echoes the wine-bottle “upward vs. downward” move (Figures 7.1-7.2), now generalized to all four examples
Figures 7.5-7.9 explored downward. Upward questions: why move fluid? Maybe to dry a basement. Why dry a basement? Maybe to improve living conditions
Just as built systems have hierarchy (Ch. 3), functional intent has hierarchy too: no reason the level you first stated is the “true” one, it’s just wherever the conversation started
The specific function at one level becomes the solution-neutral intent at the next level down: a precise, recursive relationship
Means the Section 7.2/7.3 procedure chains downward through as many levels as useful, each level’s output concept becoming the next level’s input. Next two slides (7.10, 7.11) show this chaining worked out for both examples

Suggested answer: Moving fluid may serve the intent of removing basement water; that in turn may serve maintaining a usable living space. At the broader level, preventing water entry or changing drainage can compete with pumping. Once pumping is selected, moving the specified fluid becomes the intent for a lower-level subsystem. State which level is fixed before evaluating alternatives so a preventive measure is not mistakenly compared with a pump against an incompatible specification.

Figure 7.10 · A Hierarchy Leading to Flying the Traveler

Closing a deal, by learning client preferences, by meeting the client, by traveling, by flying. At every level there are alternatives: a teleconference instead of a visit, a train instead of a flight. Source: Crawley, Cameron & Selva (2016), Fig. 7.10.

Worked demonstration of the recursive relationship, top to bottom: “closing a deal” (ultimate reason) → “learning client preferences” → “meeting the client” → “traveling” → “flying” (matches Table 7.4)
Practically useful part (side-caption): at every level, real alternatives exist that a narrower fixed-level analysis would never surface
Instead of meeting to learn preferences: study published materials, attend a conference. Instead of traveling at all: a tele-meeting, skipping “traveling” entirely. Instead of flying: drive or train
No single objectively “right” level to start at: but understanding intent’s hierarchy going up reveals entirely different solution categories (teleconference instead of any physical travel)

Discussion: Why look above ‘flying the traveler’ in the hierarchy?

Suggested answer: The underlying need may be reaching a destination, which admits rail or other concepts. Flying becomes fixed only after a justified selection or explicit constraint.

Figure 7.11 · A Hierarchy Leading to Home Internet Access

Entertainment → reading books → buying books → buying online → accessing the network. Understanding this hierarchy might surface new options, like selling electronic books. Source: Crawley, Cameron & Selva (2016), Fig. 7.11.

Second hierarchy, equal treatment: “entertaining” (broadest) → “reading” (sibling alternatives: listening, viewing) → “buying” a book (sibling: borrowing) → “buying online” (sibling: physical store, call center) → “accessing” the network (chapter’s working level)
Moving up the hierarchy can reveal options such as selling electronic books, which the narrower home-network question leaves out.
Selling ebooks doesn’t require buying (traditional sense) or the same home network connection: emerges only by stepping back up to “reading” and re-asking “what other ways could this need be met?”
Good closer for the whole first half of the chapter: stating things solution-neutrally and understanding intent’s full hierarchy isn’t pedantry: it’s a concrete tool for finding otherwise-invisible business/design opportunities

Suggested answer: Reading can be enabled by buying or borrowing, and buying need not occur online. Digital reading can change the delivery medium and access arrangement, while offline reading can occur after content has been obtained. These alternatives are visible when reasoning upward from the home-network implementation to the beneficiary’s purpose. An ebook does not inherently eliminate network access or purchase; it changes which transactions and infrastructure the selected service requires.

Section 7.3 Summary

Concept is a system vision that maps function to form; it sets the solution vocabulary and design parameters, and rationalizes the architecture
Concept is derived by specializing the solution-neutral operand and process to a specific operand, process, and abstraction of form
There is no naming convention, and no single relationship between solution-neutral and specific: concept generation requires creativity
Concepts sit in a hierarchy: understanding it one or two levels up is very useful for the architect

Review before Section 7.4: students should be comfortable with:
- The formal definition of concept and why it’s a useful intermediate step
- Walking the Figure 7.4 template on a system of their choosing
- No single fixed specialization pattern (Box 7.3): requires creative judgment, not mechanical rules
- Concepts form a hierarchy: looking one or two levels up can surface categorically different options (Figures 7.10, 7.11)
Closes Section 7.3’s “what a concept is and how to derive one.” Next: what happens when a concept’s process is rich enough to unpack into several internal sub-processes?

Suggested answer: A rich concept is expanded into internal process–operand–instrument fragments, then integrated by connecting their shared operands and checking that the chain delivers the external function. An air-travel service, for example, needs coordinated booking, passenger handling, transport, and arrival activities. This expansion exposes interfaces, shared resources, and operating conditions that the top-level phrase “flying a traveler” leaves implicit.

7.4 Integrated Concepts

Rich Concepts and Concept Fragments

A concept’s process is often rich in meaning, and can be “unpacked” into several internal functions: visiting a client implies going there, spending time, and returning
An integrated concept is made of smaller concept fragments, one per internal process, combined recursively using the same concept-development procedure

Tip

Transporting has at least three important internal processes: lifting (overcoming gravity), propelling (overcoming drag), and guiding. Without all three, transporting doesn’t work.

Section 7.4’s central new idea: recall “visiting a client” was called “conceptually rich” (going, spending time, returning). That richness is what this section formalizes
A concept’s process can be unpacked into several distinct internal functions that must all happen for it to work
Define precisely: an integrated concept is built from smaller concept fragments, one per unpacked internal process: each developed with the same operand-process-instrument procedure, applied recursively (callback to Ch. 3’s recursion)
Primary worked example: “transporting” has at least three necessary internal processes: lifting (overcoming gravity), propelling (overcoming drag), guiding
Emphasize “necessary”: without all three, transporting doesn’t work as a concept (can’t have a vehicle that overcomes gravity/drag with no way to steer). Sets up the morphological-matrix analysis next

Discussion: Why is a list of fragments insufficient to define an integrated concept?

Suggested answer: Fragments must exchange compatible operands and collectively complete the intended function. A booking method and a transport method are not a service until their information and operating assumptions align.

The Morphological Matrix

For a car, lifting, propelling, and guiding are all done by wheels: a car is wheels-wheels-wheels
A train differs only in guiding: wheels-wheels-ground
A morphological matrix organizes instrument choices for each internal process and helps form integrated concepts (Ch. 14)

“Wheels-wheels-wheels”: memorable shorthand for compressing a vehicle’s whole architecture into three words
Car: lifting, propelling, guiding all done by the wheels: lift (support weight), propel (friction + engine), guide (steering)
Train differs in exactly one process: lifting/propelling still wheels, but guiding = rail/ground itself (rails constrain the path, no active steering) → wheels-wheels-ground
Striking: cars and trains feel like completely different vehicle categories but differ conceptually in exactly one instrument choice out of three
Morphological matrix: one row per internal process, one column per instrument choice per row: combine systematically to enumerate integrated concepts, not by ad hoc guessing
(Flag: full treatment comes in Ch. 14: this slide introduces the method)

Discussion: Can we combine any one entry from each morphological-matrix row?

Suggested answer: That generates candidates, not guaranteed solutions. Check compatibility, missing supporting functions, shared resources, and whether the combination satisfies the original intent.

Table 7.6 · Morphological Matrix for Transporting

Each column is an integrated concept. Aircraft and gliders differ only in propulsion; airships and submarines are conceptually identical, differing only in operating medium. Source: Crawley, Cameron & Selva (2016), Table 7.6.

Table structure: three rows (lifting, propelling, guiding), each with several instrument options (wheels, propeller, wings, hull for lifting; wheels, propeller, jet, gravity for propelling; wheels, propeller, rudder, “ground” for guiding). Eleven columns = eleven integrated vehicle concepts (car, train, jet aircraft, propeller aircraft, helicopter, airship, glider, boat, submarine, jet boat, hydrofoil), each an X-pattern across the rows
Two illuminating comparisons (side-caption):
- Aircraft and gliders: same lifting (wings), same guiding (rudder), differ in exactly one row: propelling (propeller vs. gravity). A glider = “an aircraft with the propulsion instrument removed”
- Airships and submarines: conceptually identical across all three processes, differing only in operating medium (air vs. water): most people would never draw this comparison, but the underlying morphology matches
Exactly the kind of unexpected structural insight a systematic morphological matrix surfaces that ad hoc brainstorming misses

Discussion: Give one reason a transport combination from the matrix could fail.

Suggested answer: An arrival arrangement may assume a station that the chosen transport mode never uses. The selected fragments must connect through compatible locations, information, and operating conditions.

Table 7.6 · Read Two Vehicle Concepts

Internal process	Car	Train	Propeller aircraft	Glider
Lifting	Wheels	Wheels	Wings	Wings
Propelling	Wheels	Wheels	Propeller	Gravity
Guiding	Wheels	Ground / rail	Rudder	Rudder

Car → train: the guiding instrument changes; lifting and propelling still use wheels.
Propeller aircraft → glider: lifting and guiding stay the same; propulsion changes.

Each column is one integrated concept assembled from a choice for every required process. Check that the choices can operate together.

Worked reading of four columns in Table 7.6. “Ground / rail” explains the book’s “ground” entry for the train.

Integrating the Home Data Network

The home network has five key internal processes: connecting the local network to the ISP; modulating the ISP carrier signal; managing data on the local network; connecting user devices; interacting with the user
Combining one instrument per process (with some flexibility: a residential gateway and a separate WAP can both manage the network) yields an integrated concept

Same methodology, second example, equal depth: “accessing” unpacks into five internal processes: have students explain each:
- Connecting the local network to the ISP (the “last mile”)
- Modulating the ISP’s carrier signal (a modem’s job)
- Managing data on the local network (a gateway/router’s job)
- Connecting user devices (WiFi, Ethernet)
- Interacting with the user (laptop, phone, etc.)
Useful nuance beyond car/train: real integrated concepts have more flexibility than exactly one instrument per process: a single device might combine rows (gateway doing modulation and management), or a function might split across devices (gateway and a separate WAP both managing data)
A device may serve several processes, or several devices may serve one process. Account for these relationships when interpreting the matrix.

Discussion: Why can one home-network box perform several listed functions?

Suggested answer: A gateway may combine modulation, routing, and local connectivity. Functional decomposition identifies needed processes; physical packaging need not assign one separate device to every process.

Table 7.7 · Connect and Modulate

Internal process	General form	Specific instrument alternatives
Connect local network to ISP	Physical connection	Fiber; coaxial cable; phone line (dial-up)
Connect local network to ISP	Radio connection	Mobile broadband; satellite
Modulate ISP carrier signal	Embedded modem	Embedded mobile broadband modem; embedded dial-up modem
Modulate ISP carrier signal	External modem	DSL modem; cable modem; fiber modem; external mobile broadband modem; satellite modem and antenna

First two concept fragments: choose a way to reach the ISP, then a compatible way to modulate that carrier. Table 7.8 adds DSL over the phone line, which this book list omits.

Table 7.7, first two functions. The book repeats coaxial cable in the physical-connection list; it is shown once here.

Table 7.7 · Manage the Local Network

General form	Specific instrument alternatives
Single-function hardware	None; wireless access point (WAP); residential gateway; switch; tethering device (hotspot)
Multi-function hardware	Residential gateway + switch; switch + WAP; modem + residential gateway; modem + residential gateway + switch; modem + residential gateway + switch + WAP

Third concept fragment: decide where local data are managed. Several functions can be packaged in one box, and one function can use several boxes.

Table 7.7, “Managing data on local network.” A plus sign denotes combined functions, not a new physical connection by itself.

Table 7.7 · Connect Devices and Reach Users

Internal process	General form	Specific instrument alternatives
Connect user devices to local network	Homogeneous	None; WiFi; USB; Bluetooth; Ethernet
Connect user devices to local network	Hybrid	WiFi + Ethernet; WiFi + USB
Interact with user	User device	Smartphone; television; laptop; home server; VOIP phone; desktop; printer

Final two fragments: choose compatible local links and the devices through which users receive the service. An integrated concept may serve several devices at once.

Table 7.7, final two functions. All distinct device and link alternatives from the book are retained.

From Table 7.7 to Figure 7.12

Required process	Selected form in Concept 1
Connect to ISP	DSL over the phone line
Modulate carrier	Dedicated DSL modem
Manage local data	Residential gateway + switch; separate WAP
Connect user devices	WiFi for laptop and phone; Ethernet for desktop and printer
Interact with user	Laptop, phone, desktop, printer

These choices form the Concept 1 path in Figure 7.12. Trace data from a user device to the ISP and back; a missing or incompatible fragment breaks the service.

Worked integration of Table 7.7 using Figure 7.12 and Table 7.8, Concept 1.

Figure 7.12 · An Integrated Concept for the Home Network

A DSL modem plus a box combining a residential gateway and Ethernet switch, with both WiFi and Ethernet connections to user devices. Source: Crawley, Cameron & Selva (2016), Fig. 7.12.

One concrete, fully-specified integrated concept: trace the signal path left to right
ISP side (broadband remote access server, DSLAM at the exchange) → phone line → DSL modem in the home → integrated box (residential gateway + Ethernet switch) → wired Ethernet to desktop PC and printer; separate WAP gives WiFi to laptop and cell phone
This is “Integrated Concept 1” from the upcoming Table 7.8: DSL (connect to ISP), dedicated DSL modem (modulate), gateway+switch+WAP (manage data), WiFi+Ethernet (connect devices), laptop/phone/desktop/printer (user interaction)
Good template for students’ own diagrams: much more concrete/buildable than earlier purely functional OPM diagrams, because every box is a specific instrument, not a solution-neutral placeholder

Discussion: What would you trace to check that the home-network concept is complete?

Suggested answer: Follow the user’s data through local access, network management, and the ISP connection, then trace the return path. Check the required conversions, connections, and supporting resources.

Table 7.8 · Upstream Choices

Function	Concept 1: DSL	Concept 2: Cable	Concept 3: Mobile
Connect local network to ISP	DSL	Coaxial cable	Mobile broadband
Modulate ISP carrier	Dedicated DSL modem	Cable modem in an integrated box	Embedded mobile broadband modem
Manage local data	Integrated gateway + switch; WAP connected by Ethernet	Integrated cable modem + gateway + Ethernet switch	Integrated modem + cell phone as tether

All three address the same internal functions with different instruments. Compare how each upstream choice constrains the rest of the network.

Table 7.8, first three rows. Descriptions retain the book’s combined-device and WAP details.

Table 7.8 · Local Access and Users

Function	Concept 1: DSL	Concept 2: Cable	Concept 3: Mobile
Connect user devices	WiFi: laptop and phone; Ethernet: desktop and printer	Local cable: TV; Ethernet: desktop, printer, and VOIP phone	WiFi
Interact with user	Laptop, phone, desktop, printer	VOIP phone, TV, desktop, printer	Laptop

Concept 2 uses Ethernet for the VOIP phone in the book’s matrix. Check that every user device has a compatible path through the selected network.

Table 7.8, final two rows. “Local cable” refers to the TV connection in the book’s Concept 2.

Section 7.4 Summary

Rich concepts often unfold into a set of internal processes that must all be executed: choosing a specific operand, process, and instrument for each defines a concept fragment
The architect explores and recombines concept fragments to build desirable integrated concepts
The morphological matrix organizes this combinatorics: one column per integrated concept, one row per fragment choice

Review before the final section: students should be able to:
- Identify a rich concept’s necessary internal processes (transporting → lifting/propelling/guiding; accessing → five home-network processes)
- Define a concept fragment (specific operand-process-instrument choice for one internal process)
- Explain how fragments recombine into an integrated concept (“wheels-wheels-wheels”)
- Use a morphological matrix to compare alternatives systematically
Concept tells us what form and function are: but not yet how the system behaves moment to moment once operating. That’s Section 7.5: concept of operations

Discussion: What is the main check after assembling concept fragments?

Suggested answer: Verify that the connected fragments deliver the end-to-end function under the required conditions. Resolve incompatible interfaces and missing processes before treating the combination as a viable candidate.

7.5 Concepts of Operations and Services

Concept of Operations (“ConOps”)

Function is a somewhat static view of what a system can do; operation is the sequence of things leading to delivery of the primary function: what the system actually does (Ch. 6)
The concept of operations sketches out how the system will operate: who operates it, when, and coordinated with what else
The relationship between concept and architecture is the same as between concept of operations and a detailed operations sequence

Final major topic: recall Ch. 6’s distinction: function = static “what it can do,” operation = actual sequence of events delivering that function, unfolding in time
Function: the system can pressurize water. Operation: the actual step-by-step sequence, given operator, given conditions
ConOps (standard industry term, give it explicitly) = a sketch of how the system will operate: who operates it, when, coordinated with what else
Elegant parallel: concept-of-operations: detailed operations sequence:: concept: full detailed architecture (Ch. 6/8): coarse high-level sketch guiding (and later rationalized by) an elaborate detailed version

Discussion: What does a ConOps add to a static list of functions?

Suggested answer: It explains who uses the system, in what sequence and conditions, with what supporting resources. Include relevant off-nominal behavior as well as the normal service.

Service vs. Good

If the enterprise transfers the instrument, it is a good (an aircraft manufacturer sells airplanes). If it transfers the function, it is a service (an airline sells transportation).

From the aircraft’s own conops, the aircraft is the operand: it’s loaded, flown, maintained. From the perspective of the service, the aircraft is the instrument: it transports the traveler.

Useful business distinction ConOps helps clarify precisely: what gets transferred to the customer?
Transfer the instrument → good (Boeing sells the physical airplane). Transfer the function → service (an airline sells transportation, keeping the airplane)
Subtle, important perspective shift (take it slowly): from the aircraft’s own ConOps, the aircraft is the operand (loaded, flown, maintained). From the service’s perspective, that same aircraft becomes the instrument (transports the traveler, who’s now the operand)
Same physical object, two entirely different roles depending on whose ConOps you’re examining: worked out visually side by side next slide

Suggested answer: In a sale of an aircraft, the customer receives the instrument and assumes responsibilities associated with owning it. In an airline service, the customer receives transportation while the provider retains the aircraft and organizes operation. The same aircraft can be an instrument of transporting a passenger and an operand of maintaining or repositioning the aircraft. Classification follows the transaction, process, and viewpoint; a product offering can combine goods and services.

Figure 7.13 · Two ConOps, Side by Side

Left: the concept of operations of the aircraft itself (scheduling, loading, taxi/takeoff, climb/cruise, approach/landing, unloading, maintaining). Right: the concept of the service of air transportation, seen from the traveler’s side (purchasing, check-in, loading, transporting, unloading, check-out). Source: Crawley, Cameron & Selva (2016), Fig. 7.13.

Example of the role-swap: walk both sides
Left (aircraft’s own ConOps): scheduling, flight planning, loading, taxi/takeoff → climb/cruise → approach/landing (all inside “transporting”), unloading, maintaining. Passengers/baggage appear only as things loaded/unloaded: essentially cargo from the aircraft’s own point of view
Right (the service, traveler’s side): plan trip + purchase ticket → check in (baggage) → is loaded (same event as left) → is transported (same process as left) → unloaded on arrival → check out
Crucial modeling insight: taxi/takeoff/climb/landing detail matters hugely to the aircraft’s own ConOps, but is nearly irrelevant to the traveler’s service experience: same underlying process, two very different levels of relevant detail depending on whose ConOps you’re viewing

Discussion: Why do the two ConOps give different prominence to the same aircraft?

Suggested answer: The passenger-service view emphasizes transportation outcomes; the aircraft-operation view emphasizes handling and operating the aircraft. Their details differ because the focal operand and purpose differ.

A Service Is a System

A service can be architected the same way as a system: it is simply more process-focused than a product
The concept of operations contains information vital to understanding the system architecture: it’s much easier to predict how a system delivers value once you know how it operates

Tip

The traveler’s service experience and the aircraft’s operation require different descriptions. Taxi and takeoff details matter more to the aircraft’s operating sequence than to the traveler’s booking and arrival activities.

Section’s central conclusion: is a service the same kind of thing as a physical system (pump, algorithm, network)? Yes: a service can be architected with exactly the same tools; the only difference is emphasis, more process-focused than a product, but entities/form/function/emergence (Ch. 2-3) still apply fully
Why ConOps earns its own section: it contains information vital to understanding architecture that pure function statements don’t capture: knowing how a system operates makes it much easier to predict how it delivers value
Restate the perspective-dependence lesson: same aircraft, hugely important details in its own ConOps, nearly irrelevant in the service’s ConOps built on top of it: neither view is more “correct,” it depends whose operational perspective you’re taking

Suggested answer: Yes. An airline service has entities such as personnel, aircraft, information systems, and travelers; processes and relationships coordinate them to deliver transportation. Its architecture must allocate functions, specify interfaces, and include supporting activities just as a hardware system does. The traveler cares about completing the journey, while the aircraft operator needs detailed taxi, takeoff, maintenance, and contingency behavior. The views differ in emphasis but must describe a compatible operation.

Section 7.5 Summary

The concept of operations defines, at a conceptual level, how the system actually operates when it delivers value
Concepts of operations can be defined both for the system itself, and for any service built upon it

Chapter 7 Summary

This chapter transitioned from simple to more complex systems, and from purely analytical to the beginning of a synthetic approach to architecture
The synthetic process begins with the stakeholder’s need, expressed as a solution-neutral function: then specializes the operand, process, and instrument to define a concept
For almost any solution-neutral function there are many possible concepts; the architect creatively develops, sorts, and selects among them
Rich concepts unfold into concept fragments, recombined into an integrated concept: and a concept of operations describes how it all actually runs

Tip

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

Retrace the full arc, in order: one coherent procedure, not a loose collection of topics
Pivot: reverse engineering (Ch. 4-6) → forward engineering (this chapter); new running examples (transportation, home network) replace pump/bubblesort
Review the sequence: identify the stakeholder need, express a solution-neutral function, then generate concepts by selecting specific operands, processes, and instruments.
Rich concept → unpack into concept fragments → recombine into an integrated concept (Section 7.4), morphological matrix for organizing the combinatorics
Concept of operations (Section 7.5) fills in the operational dimension: not just what the system is, but how it runs delivering value: also clarifies the good vs. service distinction

Discussion: What would you ask a team that presents a component list as its concept?

Suggested answer: Ask whose need it meets, what operand changes, and how those components enable the process. Then ask for an alternative concept satisfying the same solution-neutral intent.

Next: System Architecture (Synthesis)

Chapter 8 builds on the selected concept and concept of operations to develop the full architecture of the system: completing the move from analysis to synthesis.