The following content is provided under a Creative
Commons license.
Your support will help MIT OpenCourseWare
continue to offer high-quality educational resources for free.
To make a donation or to view additional materials
from hundreds of MIT courses, visit MIT OpenCourseWare
at ocw.mit.edu.
OLIVIER DE WECK: All right.
So let's see.
Mr. Sticky.
Let's see, EPFL.
Who picked Mr. Sticky?
Anybody?
AUDIENCE: Yeah.
So the definition is a cylindrical container
containing a date covered with a [? basic ?] substance that
can be deployed in order to attract and capture insects.
OLIVIER DE WECK: Good.
I'm glad you added the last part because I
was worried that you weren't going
to talk about the function.
So it's good.
I think it's good.
You started describing the form, and then you
explained what the function is at the end.
So that's good.
Anybody else do Mr. Sticky here?
Yeah.
Do you want to share?
AUDIENCE: So we said it was a portable canister
deployable, fly-attracting sticky tape,
fly-catching mechanism.
OLIVIER DE WECK: All right.
Yeah, I think you've got the right elements.
I think it needs to flow a little better,
but you've got the right ingredients there.
What about the i3.
Anybody?
Yeah, go ahead.
Justice.
AUDIENCE: You said it was an efficiency
and urban-optimized transport vehicle made by BMW.
OLIVIER DE WECK: Say that again?
AUDIENCE: Can you turn on the mic, please?
AUDIENCE: Does yours work?
OLIVIER DE WECK: Do it again.
AUDIENCE: We said it was an efficiency
and urban-optimized transport vehicle made by BMW.
OLIVIER DE WECK: Urban-optimized transport vehicle.
I think it's good.
I think you're missing the effect
that it's an all-electric, the fact that it's fundamentally
an electric vehicle.
I think it's key to the i3.
Because you have you have other urban--
like the smart car.
And so architecturally, distinguishing feature
is definitely the electric drive.
So I think it's good, but I think
you're just missing a little bit on the technology there.
What about i3 and EPFL?
Anybody do the i3?
AUDIENCE: Nobody.
OLIVIER DE WECK: Nobody.
Anybody else here?
Yeah, Veronica.
AUDIENCE: Thank you.
Sorry.
A transportation system responsible for moving people
and products with an enclosed metal frame
equipped with various safety devices
using electrically-powered control and locomotion
subsystems.
OLIVIER DE WECK: OK.
That's pretty good.
There's a lot there.
I would throw a question.
A concept you defined could almost apply to a Tramway
as well.
If this was like a streetcar, don't you
think it would apply to that as well?
So I think the fact that it's a personal vehicle,
I think it's important.
So the key in this is, describe the concept using few words
precisely, but to set it apart from neighboring concepts.
What about Rolex Center?
AUDIENCE: Yeah.
It's a single-layer building with multiple straw
used as a library for people to meet and study.
OLIVIER DE WECK: A single-story building using multiple--
AUDIENCE: --floors.
OLIVIER DE WECK: Floors.
Oh, yeah.
So that's right.
AUDIENCE: You have one layer.
However, it has this wave shape and therefore, you
have something akin to two floors.
So the library is one something like the upper floor
and the meeting areas, the noisy areas on the lower floors.
So you can connect both, but the noise
doesn't connect that easily.
OLIVIER DE WECK: Yeah.
No, that's very good, and I think that's the architectural.
And then the library is there.
That's for sure?
But isn't there a lot of other things or services
provided in that building beyond the library?
AUDIENCE: Yeah, you have a bank, a cafeteria, student services.
But you could encompass it in a meeting area.
You meet and you do some stuff like eating, going to the bank.
OLIVIER DE WECK: Right.
AUDIENCE: I think we missed some functions.
OLIVIER DE WECK: Yeah.
So I like your definition, but I think
by pointing out the library, you're
missing the other functions.
And my understanding is that the reason this was built
was to put two things.
One, is it's a focal point for the community at EPFL.
We have a student center here at MIT.
People go there to do their banking, their eating,
their meeting, and so forth.
So in that sense, it's pretty similar,
but I think the Rolex Center is such an iconic building
that it also serve a kind of a prestige function,
to put the institution on the map in terms
of it's a statement.
It's not just a utilitarian building.
Whereas, I would argue our MIT student center,
it has very similar functions to the Rolex Center,
but I wouldn't call it an iconic building.
It doesn't have that wow factor.
Would you guys agree with that?
Yeah.
Maybe it did when it was initially built.
I'm not sure, but very good.
So we could spend a lot of time on these, but really crisply
refining and thinking about the concept is very, very important
So let me very quickly go through the refrigerator case
study to show how do we transition from concept
to design.
So the first thing you do is understand where is the value--
the stakeholders and the stakeholder
analysis and the requirements definition.
And so in order to do that, you ask the question, first
of all, value identification.
Where is the value?
And so you understand that then who is the beneficiary?
That's a stakeholder.
The stakeholder has needs.
I'm using OPM here to describe this.
And then this is a funny thing here.
The needs have these little bumps.
This is meant to indicate a cloud.
This is not standard OPM nomenclature.
Just point that out.
So this means that the needs are somewhat vaporous.
They're not very well defined.
And then you interpret and incorporate some of the needs
into goals, which become requirements.
And so the goals then are an instrument
of the primary delivery value delivering process, which
is your value proposition.
To then actually deliver that value
you need to design the product, the product system, the product
object, and understand the operand, the thing that
is being operated on or transformed
by the primary value delivery process.
That's a very abstract, high-level way
to think about where's the value in the system.
But fundamentally, this is part of the reducing ambiguity work
that you do as a system architect,
as a system engineer.
And there is a recipe for doing this.
So first you start examining the operand associated with value.
What's really the thing that generates
the value that the user, the beneficiaries care about.
Next you say, this is the attribute link.
What attributes of the upper are changing or being
affected associated with value?
And so the attribute-transforming process
is where the value is generated.
So for food, I think we briefly talked about this before.
Usually people will say, when you think about a refrigerator,
keep the food cold.
But if you step back and think about it
in a more abstract way, it's really
about preserving food or reducing
the spoilage rate of the food.
So the refrigerator effectively becomes a food
spoilage rate reduction device.
and I know that sounds terrible, but that
is really what it's about.
So when once you think that way, you
can really start being creative and focus your creativity.
So here we have the food, and our goal
is to reduce its spoilage rate.
And then you can ask, well, how can we do this?
What are all the different ways of reducing
the spoilage rate of the food?
So from among the system operating processes,
we then specialize and pick a particular one for our concept.
So beside chilling or keeping the food cold,
we could irradiate the food.
We could we dry the food.
What are some other ways that we can reduce the spoilage rate?
So irradiating, drying, chilling.
Sam?
AUDIENCE: Preserving.
OLIVIER DE WECK: Preserving.
So you add chemicals essentially.
EPFL, how else can we do it?
Spoilage rate reduction?
AUDIENCE: Using chemicals?
OLIVIER DE WECK: Yeah.
So that's chemical.
That's right.
What else?
Keep going.
Because food is pretty essential for humans,
this is actually one of the areas
where humans have been very creative.
There's a lot of ways to do this.
So keep going.
AUDIENCE: Yeah, for example, for conserving grapes,
maybe you do wine, which is a process
to conserve this wonderful [INAUDIBLE]..
OLIVIER DE WECK: Yeah.
Please keep some wine for us too, please.
AUDIENCE: Beer is the same.
OLIVIER DE WECK: Yeah.
So marinating it, vacuum packing, smoking,
on and on and on.
My favorite is actually eating it.
What do bears do?
How do bears conserve food?
AUDIENCE: Fat.
OLIVIER DE WECK: Fat.
Right?
So bears, they actually consume it and then
transform it into fat, into a different storage form,
store it inside their bodies, and then
as they hibernate, that energy, that food
is being gradually consumed.
That's a very different way, but it's essentially
the same function.
So that's the key idea is start thinking in this abstract way,
and all of a sudden all these other possibilities
become possible.
And that's really the cool part about design and creativity.
But eventually, you have to pick a particular concept.
So the chilling part is not enough.
That's the function.
And then you say, well, we need a chiller.
In order to chill, we need a chiller,
and there are different types of chillers,
like a cooler or refrigerator.
And it's the combination of this specific way you're
going to operate the system.
The element of form and then the specialized element of form,
in this case the cooler, that combination
is what we call concept.
So once we have that, we can start managing complexity,
decomposing function and form, so our system operating process
gets decomposed into the primary supporting processes
like interfacing, powering, controlling.
And then our system object, you can decompose it
into different elements, supporting systems,
the operand, the operator, and so forth.
And then we can start connecting them.
So let's look at for chilling the food,
let's look at a cooler and a refrigerator
in terms of this decomposition.
So here's a picture of a very simple cooler
that you would take out on a picnic.
It has the chilling function, and then
the sub-functions when we zoom in are holding the food,
exchanging the heat between the food and the environment,
reducing the heat load, interfacing, connecting,
powering, regulating the temperature, et cetera.
And then on the form side, the cooler
itself is very simple structurally.
It just has a bottom, a box with a bottom and a top.
And then we have the ice, the food supporting
the surface, the external heat load, ambient light,
and the operator.
What's surprising here is when you map the two,
there's a surprising amount of complexity.
It's not a very clear one-to-one mapping.
Let's just look at the ice.
So here's the ice, and you can just follow these links to see
what functions, sub-functions does the ice support--
exchanging heat, powering, and regulating temperature.
So exchanging heat means, essentially,
the ice itself acts as a heat exchanger.
Just the surface of the ice is where
the heat exchange happens.
So what forms can you put ice into a cooler?
What are the different shapes of ice
that you could put into a cooler?
AUDIENCE: Like an ice pack.
OLIVIER DE WECK: You could put ice pack
or you could put a block or chips.
And if you put the same quantity of ice,
but you put a block of ice, you put little chips,
what will be the difference?
Will there be a difference?
Surface area, right?
So the speed at which the ice will
melt for the same given external temperature
is going to be different.
So there's an attribute of the ice, which is essentially
its quantity, but also it's form that will influence the--
but that's the heat exchanger function.
The powering function is pretty clear.
That's essentially the energy storage right there.
And then the third one is regulation.
How does that work?
How does the ice provide a thermal regulation
in the cooler?
Physics 101.
Yeah?
Go ahead.
AUDIENCE: [INAUDIBLE]
OLIVIER DE WECK: Right.
So as long as you have any ice left in the cooler,
what will be the temperature inside?
Not opening and closing, but if you
keep it closed, what will be the temperature in the cooler?
AUDIENCE: 0 Celsius.
OLIVIER DE WECK: 0 Celsius.
As long as you have ice left, this
is the phase transformation, you're at that point.
As soon as the ice is all melting,
the temperature will rise.
So the phase transformation of the ice from solid to liquid
is what, in fact, is the regulation
mechanism inside the cooler.
So even though you think of a cooler
as being something super simple and trivial,
once you start listing its internal functions
and how the top, the bottom the ice itself,
how they interact and support those functions,
it's pretty complex.
And you can go very detailed here,
even for something very simple like a cooler.
One question and then we'll talk about the refrigerator
and how it's different in a minute.
One question I often get is what's
the difference between system architecting and system design?
Isn't that the same thing?
And I think they're somewhat different.
They're overlapping, but there's a distinction.
So architecture selects the concept, the decomposition,
mapping of function to form.
And architecture essentially establishes
the vector of design variables.
What are the key design variables and operating
parameters of the system?
Design, then, given that, selects the actual values
for those design variables, and then you can optimize.
So if we look at the example of the cooler here,
we have our cooler with the box in the bottom and then the ice,
and we can decompose the attributes of that.
So the box with bottom has length with height.
It has a wall thickness.
It has a type of material.
The top has thickness and material,
and the ice, like we just talked about,
has quantity, surface area, and maybe initial water content.
And those are the operating parameters,
and on the upper right, those are the design variables.
So when you are making a material choice,
we're going to use PVC.
We're going to have a 2.1-inch thick wall.
We're going to use this much insulation.
This will be the aspect ratio of the cooler.
It's going to have wheels maybe, so we can pull it easily.
Those are essentially design decisions.
You're instantiating that concept.
But the fact that it has a bottom and a top
and it's hinged and it uses this phase
transition as the regulation mechanism,
that's conceptual design.
That's system architecture, and you need to do both.
But they're not quite the same.
Is that pretty clear?
That's a very important distinction.
So let's look at the form function
mapping for refrigerators.
So this is actually a big difference
between the US and Switzerland.
People in the US, we like to have big refrigerators,
big gallon of milk, and refrigerators in Switzerland
are much smaller.
I'm not sure why.
Maybe you go shopping more often,
but it's definitely one of the big differences.
But here we have essentially the decomposition
of the refrigerator.
So we have racks.
We have the air.
We have-- I guess freon is banned now,
so we should use some other.
This is a refrigerant, a working fluid, the insulation,
the feet and rollers, the frame, the electric motor, sensors,
controller doors, lights.
And then we have those functions, essentially,
the same functions we had for the cooler, holding the food,
exchanging the heat, powering, regulating.
But the difference is that we have much more
of a one-to-one mapping.
So in the refrigerator, each of these elements
supports, essentially, one of the primary sub-functions.
So the form function mapping in the refrigerator
is actually much simpler.
It's a much simpler form function
mapping than the cooler.
And you say, well, I thought a refrigerator is much more
complex.
How can that be?
Well, the real complexity comes in when you
look at the form form mapping.
So this is then the decomposition
of the refrigerator in terms of all the elements of form
and then how they relate to each other.
And I'm not showing here all the sub-processes,
but you can see that the mapping and the relationships
are much more complex than in the case of the cooler.
So to wrap up on this piece, when we do a conceptual design
or system architecture, you have two major activities.
One is concept generation.
So take the requirements and think creatively
about how these requirements could be fulfilled.
So that means understanding the operand,
the attribute of the operand that you're trying to affect--
it could be multiple here--
the intent attribute-- this means the required,
desired state--
what is the system operating process,
and what is your major element of form.
So that's generating this and specializing that.
That's concept generation, finding systems
that do the right thing.
And then once you have several concepts,
you've got to select among them, which
we'll talk about next week.
That's our topic next week is concept selection.
So finding systems that do the right thing
and do it well, deliver value, and comply with regulations,
standards, and so forth.
So there's going to be consumables involved,
side effects, like noise, waste heat, pollution.
The operator, how skilled does the operator has to be
or how autonomous is the system.
What is the reliability, safety, cost, the quantity.
All those things are describing the concept
and its instantiation in more detail
and will help you do concept selection.
Do you do you see the difference?
Concept generation is take the requirements
and come up with the fundamental form function mapping of how
the requirements can be met.
Then you instantiate that in terms of designs
and then you can evaluate those and compare concepts
using other criteria like consumables,
quantity, how skilled does the operator have to be, et cetera.
So those are fundamentally different activities.
So let me summarize on system architecture
and then talk about the NASA approach and then creativity.
So architecture requires consideration
of both function and form related through concept.
It's about starting with the operand.
What is the thing that the beneficiary, the stakeholder
cares about, and how do we transform that?
Concept then elaborate these into architectures
that have form function and structural complexity.
And then the goodness of an architecture
is really a pretty complex concept
where we have multiple objectives to satisfy,
including performance, resource utilization, cost, operability,
safety, capacity, and so forth.
And we'll defer that to next week.
So let me briefly talk about the NASA approach to this
and then talk about some methods and tools
for concept generation.
So the NASA approach is basically
described in the system engineering
handbook in the SE engine as step 3
called logical decomposition.
And so the logical decomposition process,
as described in the NASA standard,
is used to improve the understanding
of the technical requirements and the relationship
among those, transforming that initial set of requirements
into a decomposition.
So the idea that we need to partition the system
and then derive lower-level technical requirements based
on that lower-level definition, and that's what's
called architecting.
Getting back to our high-level system design process,
this is, again, that diagram that we've looked
at several times already.
You can see the red box is where this happened.
So we started with mission authority, stakeholder
expectation, and then defining those high-level requirements.
Level 0, level 1 requirements, but then you get stuck.
You get stuck because you have to make some decisions
before you can go to lower level requirements definition.
And that's what's known here as functional and logical
decomposition.
Once you've decided on a composition
and you can carry several compositions with you
for a while, then you can do the lower-level trade studies,
derive and allocate lower-level requirements refine
your CONOPS, and so forth.
And then do functional and performance analysis
to see whether you have enough detail.
Is it workable?
Is it safe?
Is it reliable?
And if yes, then you can select that as a baseline, if not,
you might have to go back to the red box, which means
that architecture didn't work.
We have to look for a different decomposition
or different architecture.
And if that doesn't work after multiple iterations here,
you might have to go back and change the requirements,
because you come to the conclusion
that the requirements are not really achievable.
So some examples here of decomposition models,
here's a timing diagram.
On the right side, you have a state diagram,
the different states that the system can be in.
So you can see this relates very strongly to the system modeling
languages that we talked about.
So you use the system modeling languages
to decompose and define the system in more detail.
And we really talked about much of this already.
And in terms of the logical decomposition flow diagram,
you start with your basic high-level requirements
and measures of performance.
You essentially do your decomposition.
And then on the right side, you come out with the lower-level
derived technical requirements, logical decomposition models,
which would be essentially a description
of your different subsystems and the logical decomposition
work products, which are essentially lower-level
definitions of what these subsystems look like.
And then you can go off and do the detailed design and then
the testing verification and so forth.
So it's essentially focused on decomposition,
which is an important part of architecting,
but it's not the only thing you do.
So let me talk about methods and tools for concept generation.
So I'm going to start with this.
This is another really fun thing we do in the system design
and management program, which is a full-year program,
is the we call it the creativity workshop.
So what are different ways of stimulating or organizing
creativity.
And what I'm showing you here is--
that's essentially a mind map of how to think
about the creativity space.
So I'll briefly go through this, and then we'll
look at a couple of examples.
So one idea is that creativity is better
if it's a group process, that people stimulate each other.
And so this whole group up there is called group dynamics.
These are all different methods for stimulating creativity
using groups of people.
And some of these are authors that have written
and methods, so de Bono, Six Hats, powwows, mind boggling,
workouts, creativity workouts, these
are all different variations of group dynamic processes.
The one that I'll talk about in some more detail
is brainstorming.
This is probably the best known.
What's not so much known about brainstorming
is that there's a right way to do it.
On the upper right branch, creativity
and system architecture, this is just
describing the importance of it, the three themes we talked
about-- creativity, ambiguity, complexity,
different types of innovation, radical innovation, modular,
or incremental innovation, and so forth, and the high leverage
that it has.
The next branch are called models of creativity.
What that essentially means, and I'll
give you one example here, which is Leonardo da Vinci,
is understanding people that universally
are claimed as having been very creative thinkers.
Why were they creative?
What was their recipe for success?
Below that, we have structured processes,
which are essentially trying to organize the creativity, which
seems like an oxymoron, but there are actually
ways to have a structured process
to stimulate concept generation.
And we'll talk about very briefly mind mapping and then
morphological matrices.
And then we have this whole area here,
which I'm going to mention, but we're not
going to do as part of the class, which is stimulants.
So this is the idea that somehow people
are more creative when their brain, when you put
yourself into some other state.
So bio-inspired design would be you go in nature,
or you read books about seashells and animals and you
really try to understand from nature--
and bio-inspired design is a very important field
of research now.
It's pretty serious.
So you put yourself in nature and be
inspired by what you see.
Random inputs, provocations, challenges, and then things
like alcohol, and even drugs.
So a lot of the music that was done in the hippie age
in the '60s, I mean, a lot of these artists
were consuming large amounts of drugs and alcohol.
And there's a big discussion on is this fundamentally
why they were creative.
So I'm not advocating that.
I'm just I'm just telling you that there
is this idea that you can stimulate creativity
in these different ways.
So let's talk about mind mapping.
So this is an example of a mind map that I really liked.
This is from several years ago.
This is from a student that took the system architecture class.
And so the idea of a mind map is that you look inside yourself
and you try to put down on a map different ideas and concepts.
So in the core of it, you have the key focal point
of the mind map.
In this case, it's system architecture,
and then you have these branches coming off.
So the class itself, the skills, the concepts, the themes,
and then it almost looks like a neural network.
You branch off into the sub ideas and sub concept.
And in order to really make it memorable,
you draw it by hand even though there
is software for doing this.
But I really like this, drawing it by hand the old style.
And then you add icons and symbols and colors
to really make this sticky and memorable.
So you can look at that.
I really like this example.
And it probably takes a couple of hours
to do a really good mind map like this.
But the idea is that by doing this,
you're going to develop your ideas and concepts.
And there's books about mind mapping.
I mean, it's a whole industry almost.
Brainstorming.
So by the way, who has done brainstorming
and organized brainstorming?
Who's been part of a brainstorming exercise?
Do you want to describe it, how that worked?
Make sure you use the mic.
AUDIENCE: So we started with our problem,
and if I remember it right, it was to redesign a coffee mug.
OLIVIER DE WECK: This was for a class?
AUDIENCE: Yes.
And then basically, for the first part, any idea could go.
And the only role was you couldn't
criticize anyone else's idea.
So he basically tried to come up with as much as we could,
wrote as much as we could on the board,
things along those lines.
And then once we had all of our ideas down
and some people built off of other ones and then it was oh,
but we can also add this.
And then we started to look at well,
we can't really believe that.
This is going to be way too expensive
and started down selecting from there.
OLIVIER DE WECK: Did you take a break between the two parts?
AUDIENCE: Yeah.
OLIVIER DE WECK: So yeah, you described it very well.
So the key idea is there's some rules for how
to properly do brainstorming, and some of them
are listed here.
And then I have another on the next chart,
there's sort of a step by step.
So it's really try to remove creativity barriers,
stimulate each other.
There's an ideal group size, and it says 5 to 10 here,
but I should probably revise this to be--
what do you think?
7 plus minus 2.
If you try to do brainstorming session with 30 people
in the room, it's too big.
It's not going to be that productive.
So use of intuition, associations.
What's important is that you have
a clear idea of why you're doing the brainstorming session.
So there's some solution neutral question,
like how can we improve a coffee mug.
What did you come up with, by the way, at the end?
Did you have a result?
AUDIENCE: I think it was we were going
to redesign the handle so it would be more ergonomic.
But, yeah.
OLIVIER DE WECK: So what can be done too, how can we improve.
There's got to be a driving question for the brainstorming
session.
Actually, the first time this was described
was by AF Osborn in this book in 1957.
There's why is brainstorming useful.
We can talk about that.
A lot of it has to do with this group dynamics.
How to organize and host a brainstorming session.
I'll talk about that next.
And then there's this killer sentences you should never
say during a brainstorming.
Some of these are pretty funny.
And then what do you do with the results.
How do you actually then take the brainstorming results
and use them for further refining or down-selecting
concepts.
So here's a six-step process for doing a brainstorming session.
So you send out invitations a few days ahead of time.
And the idea is that people can think about this question
so that when they come to the brainstorming session,
their brain is preloaded with ideas.
That's the idea.
You don't just pull people in like five minutes earlier.
The idea is give a few days, not weeks,
but a few days of warning so that people
can think about this and come to the brainstorming session ready
and charged to share their ideas.
7 plus or minus 2 participants.
There should be a facilitator.
This is somebody who is helping to moderate.
Participants take turns expressing thoughts,
suggestions, ideas.
You should take notes.
So for example, these big whiteboards are great for that,
with idea paint, the whole wall.
That's great.
Or you can do flip charts.
You can do different ways of capturing these ideas.
And then I think you mentioned this.
It's called the principle of delayed judgment.
So you're not allowed to criticize
or particularly praise.
So you could, for example say, oh,
this is the best idea we've had so far in this session.
Even though it's praise, it actually implicitly is
criticism of the other ideas.
So avoid that.
Avoid the killer phrases.
And then the idea there is produce a large amount
and diversity of ideas.
And then at some point, maybe 30 to 60 minutes, you end.
Brainstorming session that last four hours,
the first hour is probably really good
and then the second hour OK, and then the rest
is everybody is kind of shot and, there's not
a lot of new ideas coming.
Creativity killer sentences.
I highlighted a few.
This will never work.
We don't even need to talk about this.
Everybody does it this way.
I've already studied this problem for years.
Don't worry, I know I'm right, and et cetera.
How long have you been with this company?
Anyway, so that's the idea.
All right Leonardo.
Who's been to Italy or tour in France,
or who's seen one of the exhibits
know where his notebooks are on display?
AUDIENCE: [INAUDIBLE]
OLIVIER DE WECK: Yeah.
What about EPFL?
Have you guys seen these wandering exhibits
about Leonardo's work and his notebooks?
Anybody had a chance to see that?
Go ahead.
AUDIENCE: Yeah.
Actually, he do a lot of sketch, and he [INAUDIBLE] the fact
that sketching is more important than writing.
OLIVIER DE WECK: Yeah.
That's right.
So really, he didn't build a lot of his ideas.
So that's one of the-- did he actually then.
But he was a head of his time in many ways.
So he's really been identified as an exceptional individual.
So here's a book called How to Think Like Leonardo, Seven
Steps to Genius.
And I'm not a big fan of these popular books,
but this one is pretty interesting
because what's been extracted from this
is the seven da Vincian principles of creativity.
And they're here in Italian.
I'm just going to go through them very quickly.
So curiosita, lifelong quest for learning.
Dimostratzione, testing your knowledge through experience,
trying things out.
Sensazione, continual refinement of the senses.
Sfumato, which is essentially also a style of painting,
like the Mona Lisa is painted in sfumato style.
Mastering ambiguity, paradox, uncertainty.
Arte/Scienza is the whole brain thinking, left-right brain.
Corporalita, balance of body and mind, so a healthy mind
and a healthy body.
And then connessione is interesting.
That gets close to system architecture, which
is the appreciation of patterns, relationships, connections,
and systems.
So the idea is that, this from Leonardo,
his work, his way of thinking, these seven principles
have been extracted.
And then you can say, well, which of these
do I feel really resonate with me?
All right.
So we have only a few minutes left.
Let's move to some of the structured processes
for creativity.
So the first one I want to mention
is this is probably the simplest and the one that's
used the most.
This is known as a morphological matrix.
So the idea there is that you try
to define what are the key features, factors, or decisions
that you have to make when you define
a concept or an architecture.
So the key decisions are the rows.
Let's say there's n key decisions.
There are factors in the rows.
And then for each row you think about what
are the number of possible alternatives for doing this.
And then you enumerate all possible combinations.
So an example here would be here's
our morphological matrix.
And then one possible concept here would be A2, B1, C3.
That's our concept here.
And then you can see that for a full-factorial enumeration,
you would have 27 architectures that you could generate.
So the number of architectures here
is 27, based on this morphological matrix.
And I find this to be very, very helpful.
When the table gets too big, very quickly
because of this being a product, this can really explode on you.
It can be very large.
And the big challenge with this, of course,
is if you have many factors, you could generate many infeasible
architectures.
Not all these combinations are actually feasible.
So the question then is, how do you prevent that,
and that's where so-called architecture enumeration comes
in.
And I'm not going to go in a lot of detail here.
But the idea is that through creativity, expert knowledge,
and analysis you're going to define your components, which
are essentially the rows in the morphological matrix.
But you're also going to establish rules that tell you
which combinations are actually valid combinations
and which ones are not.
And that, in fact, is [? Narek's ?] PhD
topic is, how do you increase the number
of physics-based rules rather than just empirical rules.
Because if you think about it.
If you apply rules that are just based on current practice,
then you're just going to recreate
concepts and architectures we already have.
You won't really come up with something fundamentally new
because you've constrained the combinations
to what people do now.
So the real challenge here is, between generating
all possible combinations, many of which
are infeasible and only the ones that we currently have,
there's a middle ground there.
So that's architecture enumeration,
and there's different ways of doing this
at different layers of abstraction.
So here's an example of airplanes,
different configurations of airplanes.
If you think about the tail of airplanes,
we have the traditional tail with a lower stabilizer.
We have T tails.
We have we have V tails.
I mean, there's like 12 different tail geometries here.
And you could think of this for the wings, for the fuselage,
for the engine locations, very quickly,
you can generate thousands or even millions of architectures.
But at that higher abstraction layer, it's just a single tail.
So how do you combine these using compositional rules?
That's architecture enumeration.
So here's also an example from [? Narek's ?] work.
So at an engine, a turbo prop engine
at a high level of abstraction, that's
basically a propeller, an intake, a core,
and a core nozzle.
And then to break that concept in further detail, the core
itself gets shown at a lower level of detail.
And you can see that inside the core,
you have, in this case, a single compressor, a burner, and then
a turbine that drives the compressor.
And so one of the advances in engines
has been from World War II to go from single-stage to two-stage,
thee-stage engines, and so forth.
So the complexity has been going up,
but you can actually generate through architectural
enumeration, essentially, all architectures
that have been built and that are known
and have been certified through a organized architecture
enumeration process.
Some of this can be done in Excel,
for example, where you essentially
list your components.
This is your library of components.
And then on a different sheet, you
define all the different rules that
allow you to combine different number of instances
of these components into architectures.
And we'll post some information on this
if you want to try this out for your concepts.
So let me summarize.
So system architecture is definitely very abstract,
but it's also, potentially, the most influential activity
that we do in system architecting.
The concept is mapping function to form.
We typically, in the conceptual design,
don't do all the details.
We just go down two levels of abstraction.
So not all the details are defined.
The NASA approach specify or is really
focused on this idea of logical decomposition, which
is very important, but it's not the only thing
we do in system architecture.
And then the really cool part, the exciting part
in concept generation is the one that it's really
a creative activity.
And when you look at the set of creativity techniques,
you can think of group dynamics like the brainstorming.
That's used very heavily, but you
have to do it the right way.
If you organize a brainstorming session,
and there's some wiggle room, but if you violate
some fundamental principles of brainstorming,
you're not going to get the full benefit.
Models.
So thinking about really creative individuals
and what drove them, what were their principles,
and try to emulate some of that.
And then the structured processes,
which include mind maps, morphological matrices,
and then architecture enumeration.
So when you look at assignment A3, which is now
out there, that's really what it is about,
is you've done the stakeholder analysis and initial CONOPS,
you have a requirements set.
So now be unchained, and within the constraints
that are set by the competition, come up
with different concepts.
And in the homework, what I ask you to do in A3
is try out at least two different techniques,
a structured one and an unstructured one
and then compare the results.
And this will be due in two weeks.