The Influence of Architecture in Engineering Systems
Student 5
Student 6
Student 7
2 October 2009
16.842/16.980/16.899 Fall 2009
1/15
October 2, 2009
Contents
• Definition of Architecture
• Complexity and Emergence
• Flexibility and Modularity
• Discussion
16.842/16.980/16.899 Fall 2009
2/15
October 2, 2009
What is architecture?
• Abstract description of the entities of a system
and the relationship between those entities
• Creates a hierarchy of functions and physical
objects
– Functional Architecture
– Physical Architecture
– Technical Architecture
– Operational Architecture
16.842/16.980/16.899 Fall 2009
3/15
October 2, 2009
Why is architecture important?
• Understand complex systems
• Design complex systems
• Manage complex systems during the operations
phase and extension/upgrade phase
• Allows definition of Standards and Protocols for
long-lived systems
16.842/16.980/16.899 Fall 2009
4/15
October 2, 2009
Properties of Architectures
•
•
•
•
•
Robustness
Adaptability
Flexibility
Safety
Scalability
16.842/16.980/16.899 Fall 2009
5/15
October 2, 2009
Types of Architectures
•
•
•
•
•
Architectures not limited to
physical products
Standards and Protocol
architectures constrain
physical architectures
Organizational
architectures can
encourage or inhibit design
of products
Intellectual Frameworks
impact product
development
Natural architectures of
interest for design
examples
16.842/16.980/16.899 Fall 2009
Source: ESD Architecture Committee, Daniel L. Whitney - chair.
"The Influence of Architecture in Engineering Systems." Monograph,
1st Engineering Systems Symposium, Cambridge, Massachusetts, March 29-31, 2004.
Source: ESD Architecture Committee, Daniel L. Whitney - chair.
"The Influence of Architecture in Engineering Systems." Monograph,
1st Engineering Systems Symposium, Cambridge, Massachusetts, March 29-31, 2004.
6/15
October 2, 2009
Complexity
• The paper focuses on the
importance of system
architecture as a tool for
dealing with complex systems
of complexity
• What is complexity?
– 1. something complex
– 2. the quality or state of being
complex
Simple: Lever
• What does it mean to be
complex?
– 1. composed of two or more
parts
– 2. hard to separate, analyze,
or solve
Complex: Space Shuttle
16.842/16.980/16.899 Fall 2009
7/15
October 2, 2009
Complexity & Cognitive Limits
• We are challenged in thinking about complex systems
because of “cognitive limits”
– Prevents us from thinking of everything
• System architecture thinking is one way of coping with
cognitive limits and designing complex systems
– Hierarchies of architectures, decompositions, mappings, etc.
•
•
•
•
•
•
Screwdriver
(B&D)
Roller Blades
(Bauer)
Inkjet Printer
(HP)
Copy Machine (Xerox)
Automobile (GM)
Airliner
(Boeing)
#levels
~ #parts
3
30
300
2,000
10,000
100,000
1
2
3
4
5
6
Assume 7-tree [Miller
1956]
log(# parts) 
#levels  

log(7)


complex
Source: Ulrich, K.T., Eppinger S.D. , Product Design and Development
Second Edition, McGraw Hill, 2nd edition, 2000, Exhibit 1-3
16.842/16.980/16.899 Fall 2009
simple
8/15
October 2, 2009
Emergence Behavior
• “Complex systems have behaviors and
properties that no subset of their
elements have” -> Emergence
Source: ESD Architecture Committee, Daniel L. Whitney - chair.
"The Influence of Architecture in Engineering Systems." Monograph,
1st Engineering Systems Symposium, Cambridge, Massachusetts, March 29-31, 2004.
16.842/16.980/16.899 Fall 2009
9/15
October 2, 2009
Emergence Management
• System architecture thinking attempts to
predict both beneficial and negative
emergent properties
– Does not try to eliminate emergence
• Beneficial emergent properties give the system
the desired qualities that the parts do not have
by themselves
16.842/16.980/16.899 Fall 2009
10/15
October 2, 2009
Some downstream competencies (aka ilities)
• Flexibility
– System undergoes changes easily (cheaply, quickly)
– Helps enable product families
• Robustness
– Ability to perform under many circumstances (system not affected by environmental
changes or internal changes)
• Adaptability
System
changes?
•
Safety
– Affected by architecture
(example: high redundancy)
– Also extends to other levels
(component reliability, operational
procedures – enterprise as a system?)
•
Environment
changes?
– System changes to perform in new environment
– Often includes humans in system
Yes
No
Yes
Adaptability
Robustness
No
Flexibility
Nominal
case (safety,
scalability)
Scalability
– Staged deployment can mitigate scalability risks
– Examples: satellite constellation, parking garage
16.842/16.980/16.899 Fall 2009
11/15
October 2, 2009
Other downstream competencies
•
•
•
•
•
•
•
•
•
•
•
•
•
Efficiency
Commonality
Changeability
Manufacturability
Repairability
Maintainability
Usability
Evolvability
Heritability
Customizability
Reliability
Sustainability
This is a field of interest . . . No agreed-upon nomenclature/theoretical
system (cf. SEAri “Ility Space” working paper by McManus)
16.842/16.980/16.899 Fall 2009
12/15
October 2, 2009
The modularity-integrality continuum
• Modularity: Few connections
between modules, at specified
interfaces, many connections
within modules
– Example: wings (contain fuel
tanks, attach to engines and to
main body)
• Integrality: Many connections
between elements
– Example: wings (are the main
body, connect to fuel tanks,
passenger systems, landing gear,
engines, etc.
16.842/16.980/16.899 Fall 2009
13/15
October 2, 2009
Relationship between flexibility and modularity
• Flexibility
– System undergoes changes easily (cheaply, quickly)
– Suppose you want to pull off Subsystem A and replace it with Subsystem A1
– Is easier if you can just disconnect and move it (plugs, not cables), and if it’s all
connected together in one place (modular, not integrated)
– Modularity may enable flexibility
• Consequences of flexibility
– Often need to design careful interfaces
– Additional mass, cost, design effort (increasing programmatic cost and risk), and
overall system complexity may result
– Additional capability to reduce future uncertainty may result
•
What if user needs change? Can we switch from Subsystem A1 to Subsystem A2?
– Is this worth it? Computational models may be applicable
• This is an example of an architectural property affecting lifecycle properties
16.842/16.980/16.899 Fall 2009
14/15
October 2, 2009
Discussion points
• What is the difference between designing a new system and designing
one to fit legacy systems, predefined and populated product families,
existing standards of product, interface or process? How much in terms
of functions or ilities is lost when these constraints are applied, what is
gained, and is the gain worth it?
• “Further principles of architecture might emerge over time, but they can
only be viewed as heuristic guidance until they are proven by rigorous
mathematical proofs and physical evidence in actual systems. There is
debate whether such rigor is achievable or necessary in practice. “
– Do principles of architecture need to be proofs? Is it possible?
• Architecture can serve as a guideline for standards (e.g., specifying
interfaces in a modular system). What are some other ways in which
organizational (often human-centric and socially driven) architectures
interact with physical architectures?
– Do you need a flexible organization to build a flexible vehicle?
16.842/16.980/16.899 Fall 2009
15/15
October 2, 2009
Backup
16.842/16.980/16.899 Fall 2009
16/15
October 2, 2009
Building modularity into a system
A B C D E F G H I
A X
1
B
C
D
1
X
1
1
X
1
X
1
E
X
F
1
G
1
H
I
A B C D E F G H I
X
A X
X
B
1
X
1
X
X
C
1X
D
1 1X
1
E
Integrated
system (non­
clustered)
16.842/16.980/16.899 Fall 2009
1
X
1
F
1X
G
1 1X
H
Modular
system
(clustered)
1
1
I
1
X
X
X
X
17/15
October 2, 2009
MIT OpenCourseWare
http://ocw.mit.edu
16.842 Fundamentals of Systems Engineering
Fall 2009
For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.