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.
