We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJaxon Willard
Modified over 2 years ago
Massachusetts Institute of Technology © Ed Crawley 2002 1 From Value to Architecture Ed Crawley Aeronautics and Astronautics Engineering Systems MIT
Massachusetts Institute of Technology © Ed Crawley 2002 2 Today’s Topics Objectives Analysis of architecture A useful tool Synthesis of architecture
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 6 Four Basic Tensions in Product/System Development Benefit ScheduleRisk Cost Value is Benefit at Cost
Massachusetts Institute of Technology © Ed Crawley 2002 7 The Architect Creates Good Architecture Satisfies customer needs Incorporates appropriate technology Meets strategic business goals Meets or exceeds present and future regulations HIs operable, maintainable, sustainable, reliable HCan be evolved/modified as appropriate Can be designed and implemented by envisioned team Can be implemented with existing/planned capabilities AND IS ELEGANT
Massachusetts Institute of Technology © Ed Crawley 2002 8 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
Massachusetts Institute of Technology © Ed Crawley 2002 9 Architecture - 6 Views Principles Methods & Tools ThemesCasesFrameworks Roles & Definitions
Massachusetts Institute of Technology © Ed Crawley 2002 10 Analysis of Architecture Form, function and concept - the architecture Upstream influences Downstream influences
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 12 Architecture – Form Suspension bridge Cable-stayed bridge
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 14 Function is Associate with Form Change voltage proportional to current Change voltage proportional to charge React translation forces Carry moment and shear
Massachusetts Institute of Technology © Ed Crawley 2002 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 Form Function Concept
Massachusetts Institute of Technology © Ed Crawley 2002 16 Dominant Upstream Influence on Architecture Regulation Corporate, Marketing Strategy Customers Competitive Environment Technology Architecture NeedGoals Downstream Strategies, Competence Form Function Concept
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 19 Framework for Downstream Influences Implementation Evolution Operations Architecture Design Operational sequence and dynamic behavior Operator (training, etc.) Operational cost Form Function Concept
Massachusetts Institute of Technology © Ed Crawley 2002 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.
Massachusetts Institute of Technology © Ed Crawley 2002 21 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
Massachusetts Institute of Technology © Ed Crawley 2002 22 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
Massachusetts Institute of Technology © Ed Crawley 2002 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.)
Massachusetts Institute of Technology © Ed Crawley 2002 24 Holistic Framework for Attributes of the Product and its Operations global why the system is built need opportunity global what the system accomplishes goals performance global how the system acts function process global where the elements are form structure global when things occur timing dynamics global who does them operator user global how much does it cost cost expense
Massachusetts Institute of Technology © Ed Crawley 2002 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,...
Massachusetts Institute of Technology © Ed Crawley 2002 26 Qualitative PDP - CDIO Impl. Schedule Impl. Team Impl. Tools Process Flow Impl. Goals Customer Corporate Societal Needs Design Schedule Process Methods Design Goals NRE Costs Product Operator Product Goal Operating Costs Impl. Costs Product Form Product Function Design Tools Design Team Product Timing Conceiving Designing Operating Implementing
Massachusetts Institute of Technology © Ed Crawley 2002 27 Business Strategy Functional Strategy Customer Needs Competitors Program plan Business case Generic PDP Conceive MissionConceptual 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 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. Input link Output link
Massachusetts Institute of Technology © Ed Crawley 2002 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)
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 32 Synthesis of Products Parallel processes: Architecture & Business Case Tracing value to architecture Ambiguity, creativity and complexity Conclusions
Massachusetts Institute of Technology © Ed Crawley 2002 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.
Massachusetts Institute of Technology © Ed Crawley 2002 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 Intent
Massachusetts Institute of Technology © Ed Crawley 2002 35 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
Massachusetts Institute of Technology © Ed Crawley 2002 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. Delivering Primary Process Operand Intent on process Has Beneficiary Needs Product Object 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
Massachusetts Institute of Technology © Ed Crawley 2002 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 Products Services Implicit Process Goods Implicit Objects
Massachusetts Institute of Technology © Ed Crawley 2002 38 Whole Product System The whole system is the array of objects necessary to deliver the externally delivered process to the operand(s).
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 40 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 44 Structure of Form - Cooler Examine the interactions implied by the decompositio n of form Establishing the complexity of the object-object architecture
Massachusetts Institute of Technology © Ed Crawley 2002 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
Massachusetts Institute of Technology © Ed Crawley 2002 46 Structure of Form - Refrigerator Considerably more object - object complexity
Massachusetts Institute of Technology © Ed Crawley 2002 47 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
Massachusetts Institute of Technology © Ed Crawley 2002 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
Chapter 5 – Enterprise Analysis
The Software Product Life Cycle. Views of the Software Product Life Cycle Management Software engineering Engineering design Architectural design.
ICAO State Safety Programme (SSP) Implementation Course
Time for a BREAK! You have 45 Minutes.
Alter – Information Systems 4th e d. © 2002 Prentice Hall 1 Moving Towards E-Business As Usual.
Development of renewable energy sources in Germany in 2011
Leadership & Management
Chapter 7 System Models.
Legacy Systems Older software systems that remain vital to an organisation.
Systems Architectures System Integration & Architecture.
2011年上半年 我院团学工作活动图片展播 2011年8月28日.
1 Phase III: Planning Action Developing Improvement Plans.
1 Click here to End Presentation Software: Installation and Updates Internet Download CD release NACIS Updates.
Part Three Markets and Consumer Behavior
1 Introduction to Transportation Systems. 2 PART I: CONTEXT, CONCEPTS AND CHARACTERIZATI ON.
PP Test Review Sections 6-1 to 6-6
Red Tag Date 13/12/11 5S.
Programming Language Concepts
Week 2 The Object-Oriented Approach to Requirements
Target Costing If you cannot find the time to do it right, how will you find the time to do it over?
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Lecture 6: Software Design (Part I)
Essential Cell Biology
Table 12.1: Cash Flows to a Cash and Carry Trading Strategy.
Management: Arab World Edition Robbins, Coulter, Sidani, Jamali
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 12 View Design and Integration.
System Requirement Specification and System Planning.
1 Introducing the Specifications of the Metro Ethernet Forum MEF 19 Abstract Test Suite for UNI Type 1 February 2008.
Peterson’s Practice AP Exam
EIS Bridge Tool and Staging Tables September 1, 2009 Instructor: Way Poteat Slide: 1.
Introduction When you choose a restaurant for a meal, are you concerned with: The price of the meal How long you have to wait to be seated The quality.
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 4 Computing Platforms.
Objectives To introduce software project management and to describe its distinctive characteristics To discuss project planning and the planning process.
1 Chapter 12 File Management Patricia Roy Manatee Community College, Venice, FL ©2008, Prentice Hall Operating Systems: Internals and Design Principles,
Copyright © 2012, Elsevier Inc. All rights Reserved. 1 Chapter 7 Modeling Structure with Blocks.
Testing Workflow Purpose
Processes and Operating Systems
1 Hyades Command Routing Message flow and data translation.
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
Organization Theory and Health Services Management
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Project Cycle Management and Statistics
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Copyright I/O International, 2013 Visit us at: A Feature Within from Item Class User Friendly Maintenance Copyright.
© 2017 SlidePlayer.com Inc. All rights reserved.