discuss systems
DESCRIPTION
Discuss systems, systems thinking, products, the PDP and the role of the architect.TRANSCRIPT
1Massachusetts Institute of Technology © Ed Crawley 2002
From Value to Architecture
Ed Crawley
Aeronautics and Astronautics
Engineering Systems
MIT
2Massachusetts Institute of Technology © Ed Crawley 2002
Today’s Topics
• Objectives• Analysis of architecture• A useful tool • Synthesis of architecture
3Massachusetts Institute of Technology © Ed Crawley 2002
Learning Objectives0) Be able to apply the principles, processes and tools of system
architecting to structure and lead the early, conceptual PDP phase
1) Discuss systems, systems thinking, products, the PDP and the role of the architect
2) Critique and create architecture, and deliver the deliverables
3) Drive ambiguity out of the upstream process
4) Create the concept
5) Manage the evolution of complexity
6) Critically evaluate current modes of architecture
7) Develop the principles of architecting
This is a course in how to think, not what to think
4Massachusetts Institute of Technology © Ed Crawley 2002
Process for Critical Thinking
• Opportunity, challenge, or reference example identified
• Thinker develops an approach option
• Thinker identifies other options, then analyzes and criticizes the options vs. each other and the “developed” approach
• Synthesized, context-appropriate “best” option is defined
5Massachusetts Institute of Technology © Ed Crawley 2002
The Role of the Architect
• Defines the boundaries, goals, and functions
• Creates the Concept
• Allocates functionality and defines interfaces and abstractions
The architect is not a generalist, but a specialist in simplifying complexity, resolving ambiguity and focusing creativity
6Massachusetts Institute of Technology © Ed Crawley 2002
Four Basic Tensions inProduct/System Development
Benefit
Schedule Risk
Cost
Value is Benefit at Cost
7Massachusetts Institute of Technology © Ed Crawley 2002
The Architect Creates Good Architecture
• Satisfies customer needs• Incorporates appropriate technology• Meets strategic business goals• Meets or exceeds present and future regulations
Is operable, maintainable, sustainable, reliable Can be evolved/modified as appropriate
Can be designed and implemented by envisioned team Can be implemented with existing/planned capabilities
AND IS ELEGANT
8Massachusetts Institute of Technology © Ed Crawley 2002
Deliverables of the Architect• A clear, complete, consistent and attainable (with 80%-
90%confidence) set of goals (with emphasis on functional goals)
• A functional description of the system, with at least two layers of decomposition
• A concept for the system• A design for the form of the system, with at least two layers
of decomposition• A notion of the timing, operator attributes, and the
implementation and operation plans• A document or process which ensures functional
decomposition is followed, and the form at interfaces is controlled
9Massachusetts Institute of Technology © Ed Crawley 2002
Architecture - 6 Views
Principles
Methods & Tools
ThemesCasesFrameworksRoles &Definitions
10Massachusetts Institute of Technology © Ed Crawley 2002
Analysis of Architecture
• Form, function and concept - the architecture
• Upstream influences• Downstream influences
11Massachusetts Institute of Technology © Ed Crawley 2002
A Definition• Architecture
– The embodiment of concept, and the allocation of
physical/informational function (process) to
elements of form (objects) and definition of
structural interfaces among the objects
• Consists of:– Function– Related by Concept– To Form
Form
Fu
nc
tio
n
Concept
12Massachusetts Institute of Technology © Ed Crawley 2002
Architecture – Form
Suspension bridge
Cable-stayed bridge
13Massachusetts Institute of Technology © Ed Crawley 2002
Product Attribute - Function
• Function is the activity, operations, transformations that create or contribute to performance
• Function is a system attribute, created by the architect
• Function is associated with form, and emerges as form is assembled
• Function can stated in solution neutral form, as a verb plus noun, and with a limited syntax
• Externally delivered function is linked to value of a product
14Massachusetts Institute of Technology © Ed Crawley 2002
Function is Associate with Form
• Change voltage proportional to current
• Change voltage proportional to charge
• React translation forces
• Carry moment and shear
15Massachusetts Institute of Technology © Ed Crawley 2002
Concept - the Mapping of Form to Function
• A system vision which maps form to function and embodies working principles
• Is in solution-specific vocabulary - it is the solution• Is created by the architect• Must allow for the execution of all functions• Specifies the vector of design parameters, which, when
selected, will establish the design
• Is an abstraction of form, or form is a specification of
concept FormF
un
cti
on
Concept
16Massachusetts Institute of Technology © Ed Crawley 2002
Dominant Upstream Influence on Architecture
Regulation
Corporate,MarketingStrategy
Customers
CompetitiveEnvironment
Technology
Architecture
Need Goals
Downstream Strategies,
Competence
Form
Fu
nc
tio
n
Concept
17Massachusetts Institute of Technology © Ed Crawley 2002
Product Attribute - Need
• Need is defined as:– an overall desire or want– a necessity– a wish for something which is lacking
• Can also include opportunities to fill unexpressed needs• Exists in the mind of the beneficiary (outside the
enterprise)• Expressed often in fuzzy or general (i.e. ambiguous)
terms• Is interpreted (in part) by the architect
18Massachusetts Institute of Technology © Ed Crawley 2002
Product Attribute - Goals• Goal is defined as
– what it accomplishes, its performance– what the designer hopes to achieve or obtain
• Expressed in the precise terms of Product Development• Will include goals derived from user Needs (goals from
beneficiaries) i.e. the external functional goals• Will also include goals from corporate strategy,
regulations, competitive analysis, etc.• Embodied in a statement of goals (requirements ?)• Is defined (in part) by the architect• Exist within, and under the control of the enterprise, and
are traded against other attributes
19Massachusetts Institute of Technology © Ed Crawley 2002
Framework for Downstream Influences
Implementation
Evolution
Operations
Architecture
Design
Operational sequence and dynamic behavior
Operator (training, etc.)
Operational cost
Form
Fu
nc
tio
n
Concept
20Massachusetts Institute of Technology © Ed Crawley 2002
Product Attribute - Timing• When the system operates, the time sequence of events• Has two important aspects
– Operational sequence– Dynamic behavior
• Operations sequence is the total set of steps or processes that the system undergoes, inclusive of the primary process for which it is intended– Including set up, take down, stand alone, contingency and
emergency operations
• Dynamic behavior is the detailed timing of steps, their sequence, start time, duration, overlap, etc.
21Massachusetts Institute of Technology © Ed Crawley 2002
Overall Operational Sequence
Waiting in storage
Retrieving, connecting, powering-up,
setting up, initializing
Loading, preparing
Process only ops.
Contingency ops.
Emergency ops.
Archiving, unloading
Terminating, disconnecting,depowering, storing
Inspecting, repairing, calibrating, updating,
maintaining
Executing Primary Process
OPERATING
Store
Get ready
Get set
Go
Get unset
Get unready
Fix
22Massachusetts Institute of Technology © Ed Crawley 2002
Product Attribute - Operator• Who will use/execute the system• Necessary for products with human
agents/operators/supervisors [which ones don’t?]– most important for human-in-loop (e.g. aircraft,
bicycle)– important for direct human operation (e.g. lathe,
wheelchair, calculator)– for other products, can be considered part of
interface/constraints (e.g. human factors design, industrial design)
• Because of the unique issues of human performance and safety, it is useful to keep separate as an additional attribute
23Massachusetts Institute of Technology © Ed Crawley 2002
Product Attribute - Operations Cost
• Operations Cost is a product attribute• How much it will cost to operate the system• This is the recurring operational related costs
– Operator and other personnel– Training– Maintenance and (nominal) upgrades– Consumables– Indirect operating costs (insurance, etc.)
24Massachusetts Institute of Technology © Ed Crawley 2002
Holistic Framework for Attributes of the Product and its Operations
globalwhy
thesystemis built
needopportunity
globalwhat
thesystem
accomplishes
goalsperformance
globalhow
thesystem
acts
functionprocess
globalwhere
theelements
are
formstructure
globalwhen
thingsoccur
timingdynamics
globalwho
doesthem
operatoruser
globalhow much
doesit cost
costexpense
25Massachusetts Institute of Technology © Ed Crawley 2002
Other Downstream Processes
• The system must be designed, so it must be architected in such a way that design can proceed smoothly and efficiently
• The system must be implemented, so it must be architected for manufacturability, coding, integration, test, and verification
• The system may evolve and be updated, so it must be architected with a view towards these changes - Evolution is really just a recursive pass through conception, design and implementation
• Each has its own who, what, where, when, ...
26Massachusetts Institute of Technology © Ed Crawley 2002
Qualitative PDP - CDIO
Impl.Schedule
Impl.Team
Impl.Tools
ProcessFlow
Impl.Goals
CustomerCorporateSocietal Needs
DesignSchedule
ProcessMethods
DesignGoals
NRECosts
ProductOperator
ProductGoal
OperatingCosts
Impl.Costs
ProductForm
Product Function
DesignTools
DesignTeam
Product Timing
Conceiving
Designing
Operating
Implementing
27Massachusetts Institute of Technology © Ed Crawley 2002
Business Strategy
Functional Strategy
Customer Needs
Competitors Program
plan Business
case
Generic PDP
Conceive
Mission Conceptual
Design
Goals Function Concepts Regulation Technology Platform plan Supplier plan Architecture Commitment
Requirements definition
Model development
Requirements flowdown
Detail decomposition
Interface control
Design
Preliminary
Design
Detailed
Design
Design elaboration
Goal verification
Failure & contingency analysis
Validated design
Implement
Element
Creation
Integration,
System Test
Operate
Life Cycle
Support
Evolution
Sourcing Implementation
ramp-up Element
implementation Element testing Element
refinement
Product integration
Product testing
System testing
Refinement Certification Market
positioning Delivery
Sales, Distribution
Operations Logistics Customer
support Maintenance,
repair, overhaul
Upgrades
Product improve-ment
Family expansion
Retirement
Envision Design Develop Deploy
28Massachusetts Institute of Technology © Ed Crawley 2002
A Tool - Object Process Modeling• Object: that which has the potential of
stable, unconditional existence for some positive duration of time. Objects have states.
• Form is the sum of objects • Process: the pattern of
transformation applied to one or more objects. Processes change states.
• Function emerges from processes• All links between objects and
processes have precise semantics
Objects
Processes
29Massachusetts Institute of Technology © Ed Crawley 2002
Process and its Links
• A process is associated with a verb and stateless• There are a family of about 5 types of links from
process to object• A process changes the states of its operand(s)
through input and output links
• Transporting changes person from here to there.
Input link Output link
30Massachusetts Institute of Technology © Ed Crawley 2002
Summary Object-Process Links
• P affects O (affectee)
• P yields O (Resultee)
• P consumes O (Consumee)
• P changes O (from state A to B).
• P is handled by O (agent)
• P requires O (Instrument)
31Massachusetts Institute of Technology © Ed Crawley 2002
Emergence
• A process can be zoomed into sub-processes• A process emerges from sub-processes• The process and sub-processes are not linked in any
explicit manner, as the object decomposes into parts• Emergence is a powerful feature of systems - parts
and sub-processes can come together to cause a process to emerge
• Emergence sometimes yields the anticipated processes, sometimes does not yield the anticipated process and sometimes unanticipated processes
32Massachusetts Institute of Technology © Ed Crawley 2002
Synthesis of Products
• Parallel processes: Architecture & Business Case
• Tracing value to architecture• Ambiguity, creativity and complexity• Conclusions
33Massachusetts Institute of Technology © Ed Crawley 2002
Parallel Cycles
• The parallel cycles end when:- The technical architecture “closes”- The business case “closes”
• The outputs are products with value to customer and profits with value to share holder, while providing appropriate value to society and workforce.
34Massachusetts Institute of Technology © Ed Crawley 2002
Intent
• An Intent is– What the purpose is– What someone hopes to achieve or obtain
• Is always defined by someone• Useful to create a special symbol for this information
object - supposed to remind you of an arrow - where you are going
Intent
35Massachusetts Institute of Technology © Ed Crawley 2002
Function - A Formal Definition
• Previous Definition: the …transformation…that contribute to performance…the actions…for which a thing exists
• Function is intent plus process
Intent
Process
36Massachusetts Institute of Technology © Ed Crawley 2002
Value - Formal DefinitionsValue is delivered when the primary external process(es)
acts on the operand in such a way that the needs of the beneficiary are satisfied at a desirable cost.
Delivering Primary Process
Operand
Intent on process
Has
Beneficiary
Needs
ProductObject
Interpreting &Incorporating
Value Delivery
Value Identification
Value: “how various stakeholders find particular worth, utility, benefit, or reward in exchange for their respective contributions to the enterprise” Murman, et al. LEV p178
Value Proposition
37Massachusetts Institute of Technology © Ed Crawley 2002
Product Systems and Value• Products include Goods,
which are objects which implicitly execute a process
• Products include Services, which are processes enabled by implicit objects
• In both cases, the value to the primary beneficiary is in the process, not the object
Products
Services
ImplicitProcess
Goods
ImplicitObjects
38Massachusetts Institute of Technology © Ed Crawley 2002
Whole Product System
• The whole system is the array of objects necessary to deliver the externally delivered process to the operand(s).
39Massachusetts Institute of Technology © Ed Crawley 2002
Value to Intent • Start by examining the
operand associated with value
• Next identify the attribute of the operand whose change is associated with value
• Next define the transformation of the attribute associated with value, in solution neutral form
This will reduce ambiguity and lead you to a value focused, solution neutral statement of intent on process
40Massachusetts Institute of Technology © Ed Crawley 2002
Concept
• Concept: a system vision, which embodies working principles, a mapping from function to form
• Choose from among the system operating processing that specialize to the desired solution neutral, value related process
• Specialize the related generic concept to the product form
This is the exercise of creativity
Concept
Five primary functions. McGee, deWeck
41Massachusetts Institute of Technology © Ed Crawley 2002
Capturing Intent
• Once the system is modeled or built, the “attribute transforming” process and “concept” object vanish
• The “attribute transforming” can be captured as an intent object
• The concept usually remains implicit, represented by the operating process and concept specialization
42Massachusetts Institute of Technology © Ed Crawley 2002
Decomposition of Function and Form
• Identify form of the whole product system
• Zoom the processes of function
• Decompose the form of the product object
• Establish the object process links
43Massachusetts Institute of Technology © Ed Crawley 2002
Form and Function - Cooler• The whole product includes
the ice, food, supporting surface, heat load, light and operator
• Chilling zooms to the stated processes (using process precedence framework)
• Cooler decomposes to box and top
• Map objects to processes to determine object-process architecture
Establishing the complexity of the object-process architecture
44Massachusetts Institute of Technology © Ed Crawley 2002
Structure of Form - Cooler
• Examine the interactions implied by the decomposition of form
Establishing the complexity of the object-object architecture
45Massachusetts Institute of Technology © Ed Crawley 2002
Form and Function - Refrigerator• More one to one
correspondence of objects and processes
• Note the whole product elements suppressed:– Food– Support
structure– Heat load– Operator
46Massachusetts Institute of Technology © Ed Crawley 2002
Structure of Form - Refrigerator
Considerably more object - object complexity
47Massachusetts Institute of Technology © Ed Crawley 2002
So Why Refrigerators and not Coolers?
• Refrigerators have significantly more complexity than coolers
• Refrigerators have more functions, performance and robustness than coolers.
Principle: underlying and long enduring fundamentals that are always (or almost always) valid.
Is a principle lurking here?
Massachusetts Institute of Technology © Ed Crawley 2002
Robust Functionality Drives Essential Complexity
• Essential complexity is that which is essential to deliver functionality before gratuitous complexity slips in
• Functionality drives complexity in any given concept
• But “Functionality” is often defined as a surrogate for a much broader set of functions which the product will actually be use for.
• Therefore, it is the (often implicit) robust functionality which drives essential complexity
A Principle
49Massachusetts Institute of Technology © Ed Crawley 2002
Conclusions
• Architecture requires consideration of form and function, related through concept
• Value derives from function• Starting with the operand, its transformation
identifies concepts which deliver value• Concepts elaborate into architectures which have
form-function and structural complexity• Essential complexity is accepted to deliver robust
functionality