From Value to Architecture

1
From Value to Architecture

• Ed Crawley
• Aeronautics and Astronautics
• Engineering Systems
• MIT

2
Todays Topics

• Objectives
• Analysis of architecture
• A useful tool
• Synthesis of architecture

3
Learning Objectives

• 0) 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

4
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

5
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
6
Four Basic Tensions inProduct/System Development
Value is Benefit at Cost
7
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

8
Deliverables of the Architect

• A clear, complete, consistent and attainable
  (with 80-90confidence) 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

9
Architecture - 6 Views
10
Analysis of Architecture

• Form, function and concept - the architecture
• Upstream influences
• Downstream influences

11
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
Function
Concept
12
Architecture Form
Suspension bridge
Cable-stayed bridge
13
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

14
Function is Associate with Form

• Change voltage proportional to current
• Change voltage proportional to charge
• React translation forces
• Carry moment and shear

15
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

16
Dominant Upstream Influence on Architecture
Regulation
Corporate, Marketing Strategy
Architecture
Need
Goals
Customers
Competitive Environment
Downstream Strategies, Competence
Technology
17
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

18
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

19
Framework for Downstream Influences
Implementation
Architecture
Operator (training, etc.)
Operational sequence and dynamic behavior
Operations
Operational cost
Evolution
Design
20
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.

21
Overall Operational Sequence
Waiting in storage
Store Get ready Get set Go Get unset Get
unready Fix
Retrieving, connecting, powering-up, setting
up, initializing
Loading, preparing
OPERATING
Process only ops.
Executing Primary Process
Contingency ops.
Emergency ops.
Archiving, unloading
Terminating, disconnecting, depowering, storing
Inspecting, repairing, calibrating, updating,
maintaining
22
Product Attribute - Operator

• Who will use/execute the system
• Necessary for products with human
  agents/operators/supervisors which ones dont?
• 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

23
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.)

24
Holistic Framework for Attributes of the Product
and its Operations
global where the elements are form structure
global how much does it cost cost expense
global why the system is built need opportunity
global what the system accomplishes goals perfo
rmance
global how the system acts function process
global when things occur timing dynamics
global who does them operator user
25
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, ...

26
Qualitative PDP - CDIO
Designing
Design Schedule
NRE Costs
Process Methods
Design Goals
Design Tools
Design Team
Conceiving
Operating Costs
Product Function
Product Timing
Customer Corporate Societal Needs
Product Operator
Product Goal
Product Form
Operating
Impl. Team
Impl. Tools
Impl. Goals
Impl. Schedule
Process Flow
Impl. Costs
Implementing
27
Generic PDP
Conceive
Design
Implement
Operate
Mission
Conceptual Design
Preliminary Design
Detailed Design
Element Creation
Integration, System Test
Life Cycle Support
Evolution

• Product improve-ment
• Family expansion
• Retirement

• Business Strategy
• Functional Strategy
• Customer Needs
• Competitors
• Program plan
• Business case

• Goals
• Function
• Concepts
• Regulation
• Technology
• Platform plan
• Supplier plan
• Architecture
• Commitment

• Requirements definition
• Model development
• Requirements flowdown
• Detail decomposition
• Interface control

• Design elaboration
• Goal verification
• Failure contingency analysis
• Validated design

• 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

Deploy
Design
Envision
Develop
28
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
29
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.

30
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)

31
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

32
Synthesis of Products

• Parallel processes Architecture Business
  Case
• Tracing value to architecture
• Ambiguity, creativity and complexity
• Conclusions

33
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.

34
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

35
Function - A Formal Definition

• Previous Definition the transformationthat
  contribute to performancethe actionsfor which a
  thing exists
• Function is intent plus process

Intent
Process
36
Value - Formal Definitions

• Value 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.

Operand
Delivering Primary Process
Value Delivery
Has
Intent on process
Interpreting Incorporating
Value Proposition
Value Identification
Product Object
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
37
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

38
Whole Product System

• The whole system is the array of objects
  necessary to deliver the externally delivered
  process to the operand(s).

39
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
40
Concept
This is the exercise of creativity

• 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

Five primary functions. McGee, deWeck
Concept
41
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

42
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

43
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
44
Structure of Form - Cooler

• Examine the interactions implied by the
  decomposition of form

Establishing the complexity of the object-object
architecture
45
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

46
Structure of Form - Refrigerator
Considerably more object - object complexity
47
So Why Refrigerators and not Coolers?

• Refrigerators have significantly more complexity
  than coolers
• Refrigerators have more functions, performance
  and robustness than coolers.

Is a principle lurking here?
Principle underlying and long enduring
fundamentals that are always (or almost always)
valid.
48
Robust Functionality Drives Essential Complexity
A Principle

• 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

49
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