System architecture strategy and product development for complex systems global edition

System Architecture Global edition System Architecture Crawley Cameron Selva This is a special edition of an established title widely used by colleges and universities throughout the world Pearson published this exclusive edition for the benefit of students outside the United States and Canada If you purchased this book within the United States or Canada, you should be aware that it has been imported without the approval of the Publisher or Author Strategy and Product Development for Complex Systems For these Global Editions, the editorial team at Pearson has collaborated with educators across the world to address a wide range of subjects and requirements, equipping students with the best possible learning tools This Global Edition preserves the cutting-edge approach and pedagogy of the original, but also features alterations, customization, and adaptation from the North American version Global edition Global edition Strategy and Product Development for Complex Systems Edward Crawley   Bruce Cameron   Daniel Selva Foreword by Norman R Augustine Pearson Global Edition Crawley_fullcover.indd 11/7/15 6:31 PM SyStem Architecture Strategy and Product Development for Complex Systems Global Edition Edward Crawley Bruce Cameron Daniel Selva Boston Columbus Indianapolis New York San Francisco Hoboken Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montréal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Vice President and Editorial Director, ECS: Marcia J Horton Executive Editor: Holly Stark Senior Acquisitions Editor, Global Editions: Priyanka Ahuja Field Marketing Manager: Demetrius Hall Senior Product Marketing Manager: Bram van Kempen Marketing Assistant: Jon Bryant Senior Managing Editor: Scott Disanno Global HE Director of Vendor Sourcing and Procurement: Diane Hynes Director of Operations: Nick Sklitsis Operations Specialist: Maura Zaldivar-Garcia Senior Manufacturing Controller, Global Editions: Trudy Kimber Cover Designer: Lumina Datamatics Production Project Manager: Rose Kernan Project Editor, Global Editions: K.K Neelakantan Program Manager: Erin Ault Manager, Rights and Permissions: Rachel Youdelman Media Production Manager, Global Editions: Vikram Kumar Associate Project Manager, Rights and Permissions: Timothy Nicholls Full-Service Project Management: George Jacob, Integra Cover Image: © Boskalis Pearson Education Limited Edinburgh Gate Harlow Essex CM20 2JE England and Associated Companies throughout the world Visit us on the World Wide Web at: www.pearsonglobaleditions.com © Pearson Education Limited 2016 The rights of Edward Crawley, Bruce Cameron, and Daniel Selva to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988 Authorized adaptation from the United States edition, entitled System Architecture: Strategy and Product Development for Complex Systems, 1st edition, ISBN 978-0-13-397534-5, by Edward Crawley, Bruce Cameron, and Daniel Selva published by Pearson Education © 2016 All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior written permission of the publisher or a license permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, Saffron House, 6–10 Kirby Street, London EC1N 8TS All trademarks used herein are the property of their respective owners The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library 10 ISBN 10: 1-292-11084-8 ISBN 13: 978-1-292-11084-4 Typeset in 10/12, Times LT Sts by Integra Printed in Slovakia by Neografia CoNTeNTS Contents Foreword Preface Acknowledgments 11 About the Authors 12 Part System thinking chapter 15 introduction to System Architecture 16 Architecture of complex Systems 16 the Advantages of Good Architecture 16 Learning Objectives 19 Organization of the text 20 References chapter 21 System thinking 22 2.1 introduction 22 2.2 Systems and emergence 22 2.3 task 1: identify the System, its Form, and its Function 27 2.4 task 2: identify entities of a System, their Form, and their Function 31 2.5 task 3: identify the relationships among the entities 40 2.6 task 4: emergence 42 2.7 Summary 47 References chapter 48 thinking about complex Systems 49 3.1 introduction 49 3.2 complexity in Systems 49 3.3 Decomposition of Systems 53 3.4 Special Logical relationships 57 3.5 reasoning through complex Systems 58 3.6 Architecture representation tools: SysmL and OPm 3.7 Summary 62 References Part 64 analysis of System architecture 65 chapter Form 67 4.1 introduction 67 4.2 Form in Architecture 67 4.3 Analysis of Form in Architecture 72 4.4 Analysis of Formal relationships in Architecture 4.5 Formal context 89 4.6 Form in Software Systems 91 77 59 CoNTeNTS 4.7 Summary 96 References chapter 96 Function 97 5.1 introduction 97 5.2 Function in Architecture 97 5.3 Analysis of external Function and Value 103 5.4 Analysis of internal Function 108 5.5 Analysis of Functional interactions and Functional Architecture 112 5.6 Secondary Value-related external and internal Functions 122 5.7 Summary 123 References chapter 123 System Architecture 124 6.1 introduction 124 6.2 System Architecture: Form and Function 125 6.3 Non-idealities, Supporting Layers, and interfaces in System Architecture 135 6.4 Operational Behavior 139 6.5 reasoning about Architecture using representations 143 6.6 Summary 150 References chapter 150 Solution-Neutral Function and concepts 151 7.1 introduction 151 7.2 identifying the Solution-Neutral Function 154 7.3 concept 156 7.4 integrated concepts 166 7.5 concepts of Operations and Services 171 7.6 Summary 172 References chapter 173 From concept to Architecture 174 8.1 introduction 174 8.2 Developing the Level Architecture 176 8.3 Developing the Level Architecture 180 8.4 home Data Network Architecture at Level 184 8.5 modularizing the System at Level 187 8.6 Summary 189 References Part 190 Creating System architecture chapter 191 the role of the Architect 192 9.1 introduction 192 CoNTeNTS 9.2 Ambiguity and the role of the Architect 192 9.3 the Product Development Process 198 9.4 Summary 206 References chapter 10 210 upstream and Downstream influences on System Architecture 211 10.1 introduction 211 10.2 upstream influence: corporate Strategy 212 10.3 upstream influence: marketing 215 10.4 upstream influence: regulation and Pseudo-regulatory influences 218 10.5 upstream influence: technology infusion 220 10.6 Downstream influence: implementation—coding, manufacturing, and Supply chain management 221 10.7 Downstream influence: Operations 224 10.8 Downstream influence: Design for X 226 10.9 Downstream influence: Product and System evolution, and Product Families 228 10.10 the Product case: Architecture Business case Decision (ABcD) 231 10.11 Summary 235 References chapter 11 238 translating Needs into Goals 240 11.1 introduction 240 11.2 identifying Beneficiaries and Stakeholders 11.3 characterizing Needs 250 11.4 interpreting Needs as Goals 258 11.5 Prioritizing Goals 264 11.6 Summary 267 References chapter 12 241 273 Applying creativity to Generating a concept 276 12.1 introduction 276 12.2 Applying creativity to concept 277 12.3 Develop the concepts 282 12.4 expand the concepts and Develop the concept Fragments 283 12.5 evolve and refine the integrated concepts 288 12.6 Select a Few integrated concepts for Further Development 12.7 Summary 293 References chapter 13 298 Decomposition as a tool for managing complexity 13.1 introduction 300 300 291 CoNTeNTS 13.2 understanding complexity 300 13.3 managing complexity 309 13.4 Summary 317 References Part 322 architecture as Decisions 323 chapter 14 System Architecture as a Decision-making Process 325 14.1 introduction 325 14.2 Formulating the Apollo Architecture Decision Problem 326 14.3 Decisions and Decision Support 331 14.4 Four main tasks of Decision Support Systems 333 14.5 Basic Decision Support tools 334 14.6 Decision Support for System Architecture 340 14.7 Summary 342 References chapter 15 342 reasoning about Architectural tradespaces 345 15.1 introduction 345 15.2 tradespace Basics 346 15.3 the Pareto Frontier 348 15.4 Structure of the tradespace 355 15.5 Sensitivity Analysis 359 15.6 Organizing Architectural Decisions 364 15.7 Summary 370 References chapter 16 371 Formulating and Solving System Architecture Optimization Problems 373 16.1 introduction 373 16.2 Formulating a System Architecture Optimization Problem 375 16.3 NeOSS example: An earth Observing Satellite System for NASA 377 16.4 Patterns in System Architecting Decisions 379 16.5 Formulating a Large-scale System Architecture Problem 403 16.6 Solving System Architecture Optimization Problems 408 16.7 Summary 416 References Appendices 420 Chapter Problems Index 462 435 416 CoNTeNTS Foreword Norman R Augustine A particularly promising trend that has been taking place in healthcare is the marriage of biomedical research with engineering practices A friend of mine, an engineer, recently described to me a meeting that took place at one of America’s most prestigious universities between the faculties of the engineering department and the cardiology department exploring just such opportunities Having decided to focus on constructing a practicable mechanical human heart, the head of cardiology began his presentation with a description of the properties of the human heart Almost immediately an engineer interrupted, asking “Does it have to be in your chest? Could it be, say, in your thigh where it would be easier to reach?” No one in the room had ever considered that possibility Nonetheless, the presentation continued Soon another interruption occurred; this time it was another engineer asking, “Instead of just one heart could you have three or four small hearts integrated in a distributed system?” No one had thought of that either System Architecture, so insightfully presented in this book by three of the field’s most highly regarded leaders, is about asking—and—answering just such questions In my own career I have encountered system architecture questions in fields ranging from engineering to business to government When established practices of the field of system architecture are applied, far superior outcomes seem to result Applying such practices has not always been the case Early in my career I recall asking various of my colleagues who were working “together” on a guided missile program why they had chosen a particular design approach for their specific element of the product One replied, “Because it is the lowest weight.” Another assured me that his part would have the lowest radar cross-section Still another answered because her component would be less costly And yet another had focused on minimizing volume And so it went What was missing? The answer is a system architect This shortcoming is too often encountered, usually in more subtle ways Consider the case of the Near-Sonic Transport aircraft that was in the early stages of development a few years ago A marketing survey had indicated that airline passengers want to get to their destinations faster To an aerodynamicist (my own early field), if one wishes to avoid the penalties of supersonic flight, that translates into more closely approaching Mach One, creeping up on the drag curve into a regime wherein fuel consumption abruptly increases This was, in fact, the underlying concept of the Near-Sonic Transport But when viewed from a system architecture perspective, the appropriate question is not how to fly faster; rather, it is how to minimize the time to get from one’s home, to the airport, check-in, pass through security, board the aircraft, fly, collect baggage and travel to one’s final destination Placed in this context, an even more fundamental question arises: “How much will a passenger pay to save five or ten minutes of flying time?” The answer turns out to be, “not much”—and the Near-Sonic Transport aircraft thus met its early, and deserved, demise There are clearly better Norman R Augustine has served in industry as chairman and CEO of Lockheed Martin Corporation, in government as Under Secretary of the Army, in academia as a member of the engineering faculty of Princeton University and as a trustee of MIT, Princeton, and Johns Hopkins and as a regent of the University System of Maryland’s 12 institutions ForeworD opportunities in which to invest if one’s objective is to help passengers reach their destinations more rapidly The failing in this case was to not recognize that one was dealing with a problem of system architecture not simply a problem of aerodynamics and aircraft design My own definition of a “system” evolved over years of experience It is “two or more elements that interact with one another.” The authors of this book wisely add that the resultant functionality must exceed the sum of functionalities of the individual elements Thus simple in concept, the complexity of most real-world systems is enormous In fact, the equation describing the number of possible states a system of several elements (that interact in the simplest of all manners) has been aptly named, “The Monster!” And when a system includes humans, as many systems do, the challenge of system architecting becomes all the more immense due to the presence of unpredictability But these are the kind of systems that one encounters, and are the kind of systems that the authors show how to deconstruct and address One such system that I had the occasion to analyze concerned provisioning the (human occupied) U.S station at the Earth’s South Pole Setting the specific objective of the evaluation in itself required care as is often the case Was it to minimize expected cost? Or to minimize worst-case cost in the face of uncertainty, say, due to weather? Or perhaps to minimize “regret”— that is, when supplies are not delivered at all? Or ? In the case of this particular system there are a number of elements that must interface with one-another: cargo ships, ice breakers, aircraft of various types, ice piers for off-loading, storage facilities, traverse vehicles, communications and, underlying all decisions, was the ever-present danger of single-point failure modes creeping into the architecture In the business world one of the more complex problems faced in my career was whether— and how—all or major parts of seventeen different companies could be combined to create the Lockheed Martin Corporation Each of the “elements” had its strengths and its weaknesses; each involved large numbers of humans, each with their own goals, capabilities, and limitations; and critical to the decision, the whole had to have significantly greater functionality than the sum of the parts If the latter were not the case, there would be no reason to pay the financial premium that is implicit in most mergers and acquisitions Sadly, in engaging complex questions of this type there is no simple mathematical formula that will reveal the “right” answer However, the discipline of systems thinking proves to be an invaluable tool in assessing exposure, opportunities, parametric sensitivities, and more In the above case, most people judge that the answer came out “right”—which, incidentally, contrasts with nearly 80 percent of similar undertakings One of the authors of this book and I, along with a group of colleagues, had the occasion to propose to the President of the United States a human spaceflight plan for America for the next few decades In this instance perhaps the most difficult challenge was to define a useful mission, as opposed to the (non-trivial) task of defining an appropriate hardware configuration Fortunately, such issues are amenable to solution through system thinking As the authors point out in the material that follows, the process of establishing the architecture of systems is both a science and an art But, as is so elegantly portrayed herein, there is a Darwinian phenomenon wherein systems embodying the mistakes of the past not survive; whereas those that embody sound architectures generally survive—and even prosper That, of course, is what architecting complex systems is all about Preface9 CoNTeNTS We wrote this book to capture a powerful idea The idea of the “architecture of a system” is growing in recognition It appears in diverse fields including the architecture of a power grid or the architecture of a mobile payment system It connotes the DNA of the system, and the basis for competitive advantage There are over 100,000 professionals with the title system architect today, and many more practicing the role of the architect under different titles Powerful ideas often have nebulous boundaries We observed that many of our co-workers, clients, students had a shared recognition of system architecture issues, but used the term in very different scopes The term is often used to differentiate between existing systems, as in “the architecture of these two mountain bikes is different.” What exactly constitutes the architecture of a system is often a subject of great debate In some fields, the term is used for a singular decision that differentiates two types of systems at a high level, as in “packet-switched architecture” vs “circuit-switched architecture.” In other fields, the term is used to describe a whole implementation, save for some smaller details, as in “our software as a service architecture.” Our goal was to capture the power of the idea of architecture, and to sharpen the boundaries Much of the power of idea originates with the potential to trade among several architectures early, to look downstream and identify which constraints and opportunities will be central to value It isn’t possible to trade among early ideas if the architecture encompasses all details, nor is it a meaningful exercise if important drivers of value are missing We wrote this book to build on the idea that the architect is a specialist, not a generalist, as proposed by Eberhardt Rechtin Our intent is to showcase the analysis and methodologies of system architecture, and to develop the ‘science’ of system architecture This text is less prescriptive in places than the discipline of product design, as the systems tackled are more complex Where the product development community has a stronger focus on design, our focus centers more on emergence—the magic of functions coming together to produce a coherent whole We’ve imbued this book with our past experience We’ve been fortunate to be involved in the early development of a number of complex systems in communications, transportation, mobile advertising, finance, robotics, and medical devices, ranging in complexity from farm equipment to the International Space Station Additionally, we have included case studies from the experience of other system architects, in disciplines ranging from hybrid cars to commercial aircraft Our intent was that this book can only advance system architecture if it works from challenges faced by system architects today We wrote this book for two core audiences—professional architects and engineering students System architecture as an idea grew out of practitioners’ wisdom and attempts to codify the challenges of developing new architecture One core audience is senior professionals who are faced with architectural decisions The field encompasses a variety of professionals in senior technical and managerial roles in technical industries—software, electronics, industrial goods, aerospace, automotive, and consumer goods This book is also focused on engineering students as a core audience This text grew out of the graduate course we have taught at MIT for the past 15 years, where we’ve been fortunate to educate many leaders in the private sector and government The lens of architecture helps us understand how a system operates today, but moreover, we believe that it is a necessary competency to learn in the management of technical organizations www.downloadslide.net Index complex systems, 55–57 complexity managed with, 300–394 concept fragments from, 283–285 defined, 32, 53 distinct system elements, 33 entities into form and function, 32 form, 71, 314–315 function, 314–315 function expansion from, 283–285 hierarchic, 54–55 integral system elements, 33 medium-complexity systems, 55, 75–77 modular system elements, 33 modularity and, 312–316 multi-level, 55–56, 75 objects from form, 71 one-level, 55–56, 72 potential planes for, 315–316 principle of, 310 principle of elegance, 314 Saturn V launch vehicle, 317–319 simple systems, 55, 72–75 Space Station Freedom (SSF), 319–322 sub-problems from, 406–408 system into entities, 33 system processes of, 53–57, 451–452 two-level, 55 Degree of connectivity, 364–365 Deliverables of the architect, 197–198 Department of Defense Architecture Framework (DoDAF), 59 Deployment, PERMUTING Pattern and, 398–399 Design activity, 332 Design for X (DfX), 226–228 Design Structure Matrix (DSM) architectural tradespaces and, 364 bubblesort software structure, 94, 95 connectivity formal relationships, 87–88, 95 decision-making process and, 335–337 formal relationships, 84–85, 94 function interaction notation, 120 projecting operands onto processes using, 119 467 Design team abstractions in, 37 complex design development, 50–53 evolution of system thinking of, 35 form and function identification, 28, 30 hierarchic decomposition of, 54–55 principle value-related internal functions, 108–109 system boundaries of, 39 value-related operand of, 106 Detriment of needs, 250 Diagrams activity, 60 block definition, 60, 61, 84 decomposition of form, 71–77 formal relationships, 82–84 function representation, 100–103 graphical representation, 70–77, 81–82 internal block, 60, 61, 84 legend for SysML graphical elements, 83 Object Process Methodology (OPM), 61–62, 70–77, 81–82, 100–101 object representation, 70–71 package, 60, 61 parametric, 60, 61 requirement, 60, 61 sequence, 60 state machine, 60, 102–103 structure representation, 82–84 Systems Modeling Language (SysML), 60–61, 82–84, 102–103 Unified Modeling Language (UML), 59–60 Distinct system entities, 33 Distributed (decentralized) architecture style, 395–396, 413 Domain-specific heuristics, 415 Dominance, Pareto frontier and, 348–349 Dominant architecture, 296–297 DOWN-SELECTING Pattern, 381, 384–387 Downstream influences, 221–231 Design for X (DfX), 226–228 implementation, 221–224 Legacy elements, 228–229 operations, 224–226 platforming, 230–231, 232–233 www.downloadslide.net 468 Index Downstream influences (continued) principle of product evolution, 230 principle of reuse of Legacy elements, 228 product and system evolution, 228–231 product lines (families), 229–230 reuse, 228–229 systems attributes (ilities) as, 227–228 Duality, 92–93 Dynamic behavior, 142 E Elegance (architect systems), principle of, 314 Emergence, 22–27, 42–47 attributes of operation, 25–26 coupling of architectural variables and, 341 defined, 24 entity combination for, 32 experiments for, 45 formal relationships and, 42–46 functional interactions and, 117–118 functional relationships and, 42–46 functions, 24–25 importance of, 42–47 modeling for, 45 performance, 25 precedent of, 45 predicting, 45–46 principle of, 26 system failure and, 44–45 systems and, 22–27 unanticipated and undesirable (emergency), 26–27 values, 27 Emergency (undesirable emergence), 26–27 Emergency operations, 226 Emergent behavior, 458 Enterprise goals, corporate strategy, 214 Enterprise product development process (PDP), 198–202 Entities, 23, 31–42 abstractions and, 37–38 decomposition into form and function, 32 defined, 23 distinct, 33 external interface, 39, 42–43 focus on importance of, 35–37 form of, 31–32 function of, 32 holistic thinking about, 33–35 identification of, 31–40 integral, 33 modular, 33 relationships among, 40–42 system decomposition into, 33 system boundaries and, 32–33, 38–40, 42 Essential complexity, 305–309 Exchange, 246–248, 251–252 stakeholder relationships and, 246–248 system formation from, 251–252 value delivery from, 246–248, 251–252 Executive corporate strategy, 213 Expansion ballooning concepts, 277–278, 293–294 concepts to architecture, 176–177 creativity and, 283–285, 294–295 functions, 283–285 Experiments, emergence prediction by, 45 Exploitation functions, 413 Exploration functions, 413 External function, 103–107, 121–122 primary value-related, 103–105 secondary value-related, 121–122 value-related operands, 104–107 External interface, 39, 42–43 F Flying wing aircraft architecture, 236–238 Focus, 35–37 importance of for entities, 35–37 principle of, 36 Form, 27–32, 67–96 See also Formal context; Formal relationships aggregation, 32 analysis of in architecture, 72–77 architecture and, 67–71 canonical system characteristic of, 31 decomposition, 71, 314–315 defined, 27, 68 www.downloadslide.net Index entities and, 31–32, 33 features of function and, 123 identification of, 27–29, 30 implementation of, 67 Level architecture and, 177–179 mapping, 32, 125–135, 178–179 Object Process Methodology (OPM) for, 70–77 objects as, 70–71 operation of, 67 projection onto, 146–149 relationships among entities, 40–42 representation of, 68–71 software system analysis and, 91–96 system architecture and, 124–135, 137–139, 146–149 system attribute of, 68 system interfaces in, 137–139 zigzagging, 177–178 Form-to-function mapping, 288–289 Form-to-process mapping, 131–132 Formal context, 89–91 accompanying systems, 89 architecture analysis using, 89–91 system boundary, 89, 90 use context, 90–91 whole product system, 89–90 Formal relationships, 40–43, 46–47, 77–89 analysis of in architecture, 77–89 connections, 78, 80 connectivity, 85–88, 95 defined, 40, 77 Design Structure Matrix (DSM) representation, 84–85, 87–88, 94, 95 diagrams for, 82–84 emergence and, 46–47 entity interactions, 40–42 external interfaces, 42–43 graphical representation, 81–82 identification of other types of, 88–89 mapping and, 132–135 N-squared table representation, 40, 43, 84 Object Process Methodology (OPM) representation, 81–82, 86–87 469 software system analysis, 93–94 spatial/topological relationships, 78–81 structural representation, 82–84, 94 structure as, 77–78, 132–135 Systems Modeling Language (SysML) representation, 83–84 tables for, 84–85, 94, 95 Forward engineering, 151 See also Concept; Solution-neutral functions Front-loaded (greedy) system deployment, 399 Full-factorial enumeration, 408–409 Function, 24–25, 29–30, 97–123 See also Functional interactions; Functional relationships analytical representation of, 100–103 architecture and, 97–103 architectural decisions and objectivity of, 341 benefit of delivery, 105 canonical system characteristics of, 31 defined, 24, 97 decomposition, 314–315 emergent, 24–25 entities, 32 expansion of, 283–285 external, 103–107, 121–122 features of form and, 123 form mapping into, 178–179 identification of, 29–30 internal, 108–112, 121–122 Level architecture, 178–179 mapping, 125–135 Object Process Methodology (OPM), 100–101 operands, 29, 31, 98–103 primary value-related, 104–105 process, 29, 31, 98–103 process operand (PO) array, 110–111, 113, 116 relationships among entities, 40–42 secondary value-related, 121–122 standard blueprints for, 109 system architecture and, 124–135, 136–142 system interfaces in, 137–139 www.downloadslide.net 470 Index Function (continued) Systems Modeling Language (SysML), 102–103 value-related, 103–107, 108, 121–122 zooming, 32 Functional architecture, 112–113, 118–121 See also Functional interactions Functional intent, 153, 155, 160, 163, 167 Functional interactions, 112–121 emergence, 117–118 functional architecture and, 112–113, 118–121 identifying, 113–116 mapping and, 132–134 Object Process Methodology (OPM), 114, 115, 118 process operand (PO) array, 113, 116 projecting operands onto processes, 119 software system analysis, 118–121 value pathway, 116–117 zooming, 117, 118 Functional relationships, 42–46 defined, 40 emergence and, 46–47 entity interactions, 40–42 external interfaces, 42–43 N-squared table representation, 40, 43 Functional strategies, 213–214 Function–goal reasoning, 179 Function-to-form mapping, 178–179 Fuzziness, 195 Fuzzy Pareto frontier, 352–354, 366 G Generic product development process (PDP), 202–203 Genetic algorithms, 414–416 Global product development process (PDP), 203–206 Goals, 240–275 attainable, 259, 266–267 beneficiaries, 241–246 complete, 259, 260 consistent, 259, 266–267 criteria for, 259–261, 268 critical, 264–266 defined, 259 desirable, 264–266 humanly solvable, 259, 260–264 important, 264–266 interpreting needs as, 258–264 IT architecture requirements, 270–271 needs-to-goals framework, 241 principle of ambiguity and goals, 266 principle of balance, 258 principle of the beginning, 243 principle of the system problem statement, 261 prioritizing, 264–267 representative, 259, 270 stakeholders in IT architecture, 268–273 stakeholders, 241–257 system problem statement (SPS), 261–264 translating needs into, 240–275 Goods, 30 Granularity (abstractions) for stakeholder identification, 243 Graphical representation, see Diagrams; Object Process Methodology (OPM) Grouping stakeholders, 248–250 Guidance, navigation and control (GNC) system, 349–352 H Heuristics, 409–416 algorithms, 409–415 architecture optimization and, 373–416 crossover points, 414–415 decisions using, 326–327 deterministic architecture and, 412–413 domain-specific, 415 genetic algorithms, 414–416 initial population generation and completion, 412–413 mutation, 415 optimization problems and, 379–416 population-based algorithms, 411–412, 413 search efficiency, 413 Hierarchic decomposition, 54–56 www.downloadslide.net Index Hierarchy complex systems, 53–55, 75 complexity and, 302 concept tree, 163, 165–166 elements of form, 75 intents and concepts, 165–166 principle of “2 down, up,” 312 solution-neutral functions, 153–154, 163, 165–166 Holism, principle of, 34 Holistic thinking, 33–35 architect view of, 192, 203–204, 205 entity identification using, 33–35 known-unknowns, 34 product development process (PDP) framework, 203–204, 205 unknown-unknowns, 34 Home data network architecture, 184–187 Human relationships, 88 Humanly solvable goals, 259, 260–264 defined, 259 difficulty interpreting, 260 principle of the system problem statement, 261 system problem statement (SPS), 261–264 To-By-Using framework for, 261–263 I “ilities” (systems attributes), 27, 227–228 Implementation, 221–224 defined, 223 downstream influences on, 221–224 Inbound marketing, 215, 216–217 Incremental system deployment, 399 Inference algorithm, 455 Influences on system architecture downstream influences, 221–231 principle of architectural decisions, 211 product case for, 231, 233–235 upstream influences, 212–221 Initiatives and action plans, corporate strategy, 215 Integral system entities, 33 Integrated concepts, 166–170, 288–293 concept fragments for, 167–168 creativity applied to, 288–293 471 evolution and refinement of, 288–291 flexibility of, 168 form-to-function mapping of, 288–289 morphological matrix for, 167–170 selection of for further development, 291–293 Integrated 3D models, 59–62 Intelligence activity, 332 Intent, 153–158 concept development and, 157–158 defined, 154 functional, 153, 155, 160, 163, 167 Level architecture, 180 regulatory, 219 solution-neutral functions, 153–156 specialization of solution neutral functions using, 157–158 Interferences, 387 Interferences as rules, 457–459 Internal block diagram (SysML), 60, 61, 84 Internal function, 108–112, 121–122 identification of, 108–109 predicting emergence of, 110 process-operand (PO) array for, 110–111 standard blueprints of processes, 109 principle value-related, 108 secondary value-related, 121–122 International Council on System Engineering (INCOSE), 59 IP packet, 186 IT architecture, 268–273 goal requirements, 270–271 mappings for, 271–272 Olympic system challenge, 268–269 reliability through redundancy, 272–273 stakeholders and, 268–273 system boundary of, 269–270 utility applications, 271–272 K Kano analysis, 250–251, 256 Knowledge-based systems, 454–455 Known-unknowns, holistic thinking and, 34 www.downloadslide.net 472 Index L Layers of system architecture, 136 Legacy elements, 228–229 Level architecture, 176–179 clustering, 187–189 concept expanded to architecture, 176–177 development of, 176–179 form defined for, 177–178 mapping function to form, 178–179 modularizing the system, 187–189 zigzagging, 177–178 Level architecture, 180–184 development of, 180–184 home data network architecture at, 184–187 intent and, 180 processes and relationships, 181–182 recursion for, 180–181 zooming to, 181 Liability, regulation and, 220 Logical relationships, 57–58 M Main effect, 365–366, 449 Management architect role for, 192, 193 choosing a decomposition, 310–312 complexity, 192, 193, 300–322 decomposition and, 309–316 modularity and decomposition, 312–316 potential planes for decomposition, 315–316 Many-to-many mapping, 129–131 Mapping, 32, 125–135 ASSIGNING Pattern and, 390–391 combined operand and instrument object, 128–129 enabling function and performance, 134 form, 32, 125–135 formal structure and, 132–135 form-to-function, 288–289 form-to-process, 131–132 function, 125–135 functional interactions from, 132–134 function-to-form, 178–179 integrated concepts, 288–289 IT architecture and, 271–272 Level architecture, 178–179 many-to-many, 129–131 no instrument, 128–129 one-to-many, 129–130 one-to-one, 129 system architecture and, 125–135 system optimization problem and, 390–391 Market penetration, 217 Market sizing, 217 Marketing, 215–217 architectural competition, 294–296 corporate strategy and, 214 inbound, 215, 216–217 outbound, 215–216, 217 product differentiation and, 294–296 upstream influences on, 215–217 Matrix representation adjacency matrix, 399–400 architectural tradespaces, 364 concept fragments, 167–168 concept selection, 291–293 CONNECTING Pattern, 399–400 connectivity formal relationships, 87–88, 95 decision-making process and, 335–337 Design Structure Matrix (DSM), 84–85, 87–88, 335–337, 364 formal relationships, 84–85, 94 morphological matrix, 167–170, 335 Pugh matrix, 291–293 Media access control (MAC), 186 Medium-complexity systems, 55, 75–77 Membership, 88 Mesh architecture style, 402–403 Meta-heuristic optimization algorithms, 410–412 Metrics architectural tradespaces, 346–347, 365–366 architecture model constraints and, 328–329 decision impact on, 365–366 www.downloadslide.net Index decision-making process, 328–329, 340–342 main effect, 365–366 Pareto ranking, 355 properties of architectural decisions and, 340–342 sensitivity of decisions to, 365–366, 449–450 Mission and scope, corporate strategy, 214 Model input parameter values, 362 Modeling, emergence prediction by, 45 Modeling breadth versus depth, 341 Modular system entities, 33 Modularity and decomposition, 312–316 Modularizing the system, 187–189 Monolithic (centralized) architecture style, 395–396, 413 Monovalent architecture, 283 Monte Carlo analysis, 362–363 Morphological matrix, 167–170, 335 Multi-level decomposition, 55–56, 75 Multivalent architecture, 283 Mutation, 415 N N-squared table representation, 40, 43, 84 Naming conventions, concepts, 161 NASA Earth Observing Satellite System (NEOSS), 377–379 National Polar-Orbiting Environmental Satellite System (NPOESS), 18–19 Needs, 240–275 beneficiaries, 244–246 characterizing, 250–258 defined, 244 exchange for stakeholder value delivery, 246–248 interpreted as goals, 258–264 Kano analysis, 250–251, 256 principle of balance, 258 prioritizing, 254–258 stakeholder system classification of, 274 stakeholders, 244–248 transformative architecture and, 240 translating into goals, 240–275 Needs-to-goals framework, 241 473 Network address translation (NAT), 186 Networks, home data architecture, 184–187 No instrument mapping, 128–129 Non-idealities in value pathway, 135–136 Non-programmed decisions, 333 O Object Management Group (OMG), 59 Object Process Methodology (OPM) analysis of form, 72–77 approach of, 59 connectivity formal relationships, 86–87 decomposition of form, 71–77 diagram representations, 61–62, 70–71 formal relationships, 81–82 function representation, 100–101 functional interactions, 114, 115, 118 graphical representations, 81–82 object relationships, 61–62 object representation, 61 value-related operands, 106–107 Objective functions, architectural decisions and, 341 Objects, 70–71, 145–146 attributes of, 70 decomposition of form into, 71 defined, 70 form representation as, 70–71 projection onto, 145–146 states, 70 system representation of, 145–146 One-level decomposition, 55–56, 72 One-to-many mapping, 129–130 One-to-one mapping, 129 Operand, 29, 99 analytical representation of, 100–103 attribute, 105–106 canonical system characteristic of, 31 classes of interactions, 149 defined, 29, 99 external function analysis and, 104–107 function as process and, 98–103 projecting onto processes, 119 value-related, 104–107 Operational behavior, 139–142 www.downloadslide.net 474 Index Operations attributes of, 25–26 commissioning, 224–226 concept of (conops), 171–172 contingencies, 226 cost, 142 decommissioning, 224–226 defined, 224 downstream influences on, 224–226 emergency, 226 sequence of, 141 stand-alone, 226 Operator, 140, 242 Optimization problems, 373–419 algorithms for, 409–415 architectural, 373, 375–378 combinatorial, 459–461 constraints, 377 decomposition into sub-problems, 406–408 deterministic architecture and, 412–413 exploitation functions for, 413 exploration functions for, 413 full-factorial enumeration for, 408–409 genetic algorithms for, 414–416 heuristics for, 409–416 initial population for, 412–413 large-scale system problem formulation, 403–408 meta-heuristic optimization algorithms, 410–412 NASA Earth Observing Satellite System (NEOSS), 377–379 patterns for, 379–408 population-based algorithms, 411–412, 413 search algorithms for, 410–412 solving, 408–416 system architect decisions and, 379–403 system architecture task and pattern relationships, 403–408 tasks for, 373–374, 403–408 value functions, 376 Organization, complexity and, 305 Outbound marketing, 215–216, 217 Ownership, 88 P Package diagram (SysML), 60, 61 Parametric diagram (SysML), 60, 61 Pareto frontier, 348–355, 366 architectural tradespaces and, 348–355, 366 dominance and, 348–349 fuzzy frontier, 352–354, 366 guidance, navigation and control (GNC) system, 349–352 mechanics of, 355 mining data on, 353–354 Utopia point for plots, 351 Pareto ranking, 355 PARTITIONING Pattern, 381, 393–397 Patterns, 379–408 adjacency matrix for, 399–400 applications of, 380–381 architectural tradespace and, 400 ASSIGNING, 381, 388–392 bus architecture style, 402–403 channelized architecture style, 391–392, 413 concept of in architecture, 379–380 CONNECTING, 399–403 cross-strapping architecture style, 391–392, 413 DECISION-OPTION, 381–384 distributed (decentralized) architecture style, 395–396, 413 DOWN-SELECTING, 381, 384–387 front-loaded (greedy) system deployment, 399 incremental system deployment, 399 interactions between system elements, 387 mapping with, 390–391 mesh architecture style, 402–403 monolithic (centralized) architecture style, 395–396, 413 optimization problems and, 379–403 overlap between, 405, 406 PARTITIONING, 381, 393–397 PERMUTING, 381, 397–399 ring architecture style, 402–403 star (hub and spoke) architecture style, 402–403 www.downloadslide.net Index sub-problems and, 406–408 system architectural decisions and, 379–403 system architecture task relationships to, 403–408 tree architecture style, 402–403 Peer-to-peer protocol over Ethernet (PPPoE), 186 Penalties for architectural tradespaces, 359–361 Performance, 25 PERMUTING Pattern, 381, 397–399 Planes for decomposition (potential), 315–316 Platforming, defined, 230 Platforms, 230–231, 232–233, 236–238 architecture and, 230–231, 236–238 B-52 versus B-2 bomber architecture and, 236–238 benefits of, 232 cost sharing and, 231 costs and drawbacks, 233 downstream influences on, 230–231 product development complexity and, 231 Point designs, 347–348 Population-based algorithms, 411–412, 413 Precedent, emergence prediction by, 45 Primary function, 103 Primary value-related external function, 103–105 Principles ambiguity, 196 ambiguity and goals, 266 apparent complexity, 306 architectural decisions, 211 balance, 258 beginning (stakeholder identification), 243 benefit of delivery, 105 coupling and organization of architectural decisions, 368 creativity, 281 decomposition, 310 dualism, 92 elegance (architectural systems), 314 emergence, 26 essential complexity, 306–309 475 focus, 36 holism, 34 product evolution, 230 reuse of Legacy elements, 228 robustness of architectures, 363 role of the architect, 194 2nd law (complexity), 309 solution-neutral function, 153 stress of modern practice, 206 system problem statement, 261 “2 down, up,” (hierarchic systems), 312 value and architecture, 125 Probability distribution, 362–363 Problem stakeholders, 242 Procedural programs, 456–457 Process, 29, 99 analytical representation of, 100–103 canonical system characteristic of, 31 defined, 29, 99 function as operand and, 98–103 Level architecture relationships and, 181–182 projecting operands onto, 119 Process-form (PF) array, 144 Process operand (PO) array, 110–111 creation from OPM diagrams, 113 functional interactions, 113, 116 internal function identification, 110–111 Product, defined, 23 Product case combining influences, 231, 233–235 See also Architecture Business Case Decision (ABCD) Product development process (PDP), 198–206 enterprise, 198–202 Generic, 202–203 Global, 203–206 holistic framework for, 203–204, 205 principle of stress of modern practice, 206 Product evolution, 228–231 architectural competition, 294–298 downstream influences on, 228–231 principle of, 230 Product lines (families), 229–230 Programmed decisions, 332–333 www.downloadslide.net 476 Index Projected system representation, 144–149 classes of operand interactions, 149 form, 146–149 objects, 145–146 value stream objects, 146, 147, 148 Projections, 59 Pseudo-regulation, 220 Pseudocode, 91–92 Pugh matrix, 291–293 Q Quadrants for architectural tradespace decisions, 366–367 R Recursion, 57–58 Recursion for level architecture, 180–181 Regulation, 218–220 anticipated, 220 compliance with, 219 liability and, 220 pseudo-regulation, 220 regulatory intent, 219 sources of, 218–219 standards and, 220 upstream influences on, 218–220 Regulatory intent, 219 Reliability through redundancy, 272–273 Representative goals, 259, 270 Representing layer, decision support systems (DSS), 333–334 Requirement diagram (SysML), 60, 61 Resource allocation decisions, corporate strategy, 214 Reuse, 228–229 Reuse of Legacy elements, principle of, 228 Reverse engineering, 66 See also Form; Function Review activity, 332 Ring architecture style, 402–403 Robustness of sensitivity analysis results, 360–363 Rule-based systems, 454–459 attribute–value pairs for, 455 constraints and, 457 declarative enumeration and, 456–457 emergent behavior and, 458 inference algorithm for, 455 interferences, 457–459 knowledge-based systems and, 454–455 procedural programs, 456–457 synergies, 457–459 system architecture applications, 454–459 S Saturn V launch vehicle decomposition, 317–319 Scenarios, sensitivity analysis and, 359–360 Schemata, 387, 415 Search algorithms, 410–412 2nd law (complexity), principle of, 309 Segmentation of markets, 217 Sensitivity analysis, 359–363 penalties, 359–361 probability distribution, 362–363 robustness of results, 360–363 scenarios, 359–360 Sensitivity of decision to metrics, 365–366, 449–450 Sequence, 88, 93, 141 Sequence diagram (SysML), 60 Sequencing decisions, 368–370 Services, 30, 171–172 Shareholder annual report strategy, 212–213 Simple systems, 55, 72–75 Simplified system representation, 143–144 Simulating layer, decision support systems (DSS), 334 Software system analysis, 91–96 boundaries and, 94–95 connectivity structural relationships, 94, 95 duality and, 92–93 external value-related operands, 110 formal entities and relationships, 93–94 functional architecture in, 118–121 internal functions, 111 object of form for, 91–92 principle of dualism, 92 pseudocode for, 91–92 sequence and, 93 system architecture of, 132, 133 use context for, 95 www.downloadslide.net Index Solar system abstractions in, 37 form and function identification, 29, 30 Solution-neutral functions, 151–173 concept and, 151–152 defined, 153 functional intent and, 153 hierarchy of, 153–154, 163, 165–166 identification of, 154–156 intent of, 154–156 principle of, 153 specialization of, 157–159 Space Station Freedom (SSF) decomposition, 319–322 Spatial relationships, 78 Spatial/topological relationships, 78–81, 132 Specialization relationships, 57 Stakeholder maps, 252, 253, 254 Stakeholders, 217, 241–258 beneficial stakeholders, 242 beneficiaries and, 241–246 bounds for identification, 243 charitable stakeholders, 242 dimensions of needs, 250–251 distinguishing beneficiaries from, 241–242 exchange and relationships of, 246–248, 251–252 granularity (abstractions) for identification, 243 grouping, 248–250 identifying needs of, 244–246 IT architecture and, 268–273 marketing and needs of, 217 operator and, 242 principle of balance, 258 principle of the beginning, 243 prioritizing needs, 254–258 problem stakeholders, 242 value delivery of, 246–248, 251–252 Stand-alone operations, 226 Standard blueprints of internal processes, 109 Standards, regulation and, 220 Star (hub and spoke) architecture style, 402–403 477 State machine diagram (SysML), 60, 102–103 States of objects, 70 Strategy, see Corporate strategy Stratification, tradespace analysis and, 357–358 Stress of modern practice, principle of, 206 Structure, 77 See also Formal relationships Structured creativity, 279–280 Structuring layer, decision support systems (DSS), 334 Subjectivity, architectural decisions and, 341 Sub-problems, optimization problems decomposed into, 406–408 Supply availability, 250 Supporting layers, 136–137 Synergies as rules, 457–459 System, defined, 23 System architecture, 124–150, 174–190, 211–239 civil architecture versus, 207–210 complexity of, 49–50, 300–302 clustering, 187–189, 450–454 concept in, 174–190 decision support for, 340–342 defined, 124 downstream influences, 221–231 form in, 124–135, 137–139, 146–149 formal structure and, 124–125 front-loaded (greedy) deployment, 399 functional architecture and, 124–125 functions in, 124–135, 136–142 home data network architecture, 184–187 incremental deployment, 399 influences on, 211–239 knowledge-based systems, 454–455 Level development, 176–179 Level development, 180–184 mapping, 125–135 modularizing the system, 187–189 non-idealities, 135–136 objects, projection onto, 145–146 operational behavior, 139–142 www.downloadslide.net 478 Index System architecture (continued) optimization problems for, 373–419 patterns in, 379–403 PERMUTING pattern and, 399 principle of architectural decisions, 211 principle of elegance, 314 principle of value and architecture, 125 product case for, 231–235 questions for defining a system, 68, 98, 126, 152, 175 rule-based systems, 454–459 supporting layers, 136–137 system interfaces, 137–139 system representations, 143–150 upstream influences, 212–221 System evolution, 228–231 System failure, emergence and, 44–45 System interfaces, 137–139 System problem statement (SPS), 261–264 System representations, 143–150 architectural tradespaces, 345–372 form, 146–149 objects, 145–146 process-form (PF) array for, 144 projected, 144–149 simplified, 143–144 System thinking, 22–48 canonical characteristics, 31 concept of, 22 emergence and, 22–27, 42–47 entities of a system, 23, 31–42 essential features of, 47 evolution of, 35 form of system, 27–32 function of system, 24–25, 29–30 product versus, 23 relationships among entities, 40–42 system failure and, 44–45 tasks for identification, 22 Systems attributes (ilities), downstream influences of, 227–228 Systems Modeling Language (SysML), 59–61, 62, 83–84 architectural view representation, 59–61 diagrams, 60–61, 82–84 formal (structural) representation, 82–84 function representation, 102–103 legend for graphical elements, 83 state machine diagrams, 102–103 Unified Modeling Language (UML) and, 59–60 T Tables for formal relationships, 84–85, 94, 95 Tabu search, 415 Tasks, system thinking identification, 22 Technology infusion, 220–221 Technology Readiness Level (TRL), 221, 222 To-By-Using framework, 261–263 Top-down/bottom-up reasoning, 58 Topology, 78 Tradespaces, see Architectural tradespaces Transformational grammar, 31 Tree architecture style, 402–403 Tube-and-wing aircraft architecture, 236–238 “2 down, up” (hierarchical systems), principle of, 312 Two-level decomposition, 55 U Uncertainty, 195 Unified Modeling Language (UML), 59–60 Unknown information, 195 Unknown-unknowns, holistic thinking and, 34 Unstructured creativity, 277–278 Upstream influences, 212–221 corporate strategy, 212–215 marketing, 215–217 regulation, 218–220 technology infusion, 220–221 Upstream process, 192–193 Urgency of needs, 250 Use case diagram (SysML), 60 Use context, 90–91, 95 www.downloadslide.net Index Utility applications, IT architecture, 271–272 Utopia point, 351 V Value attribute–value pairs, 455 benefit at cost as, 27 defined, 66, 105 model input parameters, 362 Value and architecture, principle of, 125 Value delivery exchange as, 246–248, 251–252 indirect, 246, 251–252 stakeholder relationships and, 246–248 stakeholder maps for, 251–252 Value flow, 252–254 Value functions, 376 Value loop, 253, 256 Value pathway, 116–117 functional interactions and, 116–117 non-idealities in, 135–136 479 Value-related function, 103–107, 108, 121–122 external, 104–105 internal, 108 operands, 104–107 OPM diagrams for, 106–107 primary, 103–105 principle of benefit delivery, 105 secondary, 121–122 Value stream objects, 146, 147, 148 Variable types, architectural decisions and, 341 Viewing layer, decision support systems (DSS), 334 Views, 59 W W questions, 203–204 Whole product system, 89–90 Winter Olympics scenario, see IT architecture Wireless access point (WAP), 186 Z Zigzagging, 58–59, 177–178 Zooming functions, 32, 117, 118, 181 www.downloadslide.net Principles of System Architecture Principle of Emergence (26) As the entities of a system are brought together, their interaction will cause function, behavior, performance, and other intrinsic properties to emerge Principle of Holism (34) Every system operates as a part of one large system or several larger systems, and each is itself composed of smaller systems Principle of Focus (36) The number of identifiable issues that will influence a system at any point is beyond one’s ability to understand One must identify the most critical and consequential issues, and focus on them Principle of Dualism (92) All built systems inherently and simultaneously exist in the physical domain and the informational domain Principle of Benefit Delivery (105) Good architectures deliver benefit, first and foremost, built on the primary externally delivered function of the systems by focusing on the emergence of functions, and their delivery across the system boundary at an interface Principle of Value and Architecture (125) Value is benefit at cost Architecture is function enabled by form There is a very close relationship between these two statements, because benefit is delivered by function, and form is associated with cost Principle of Solution-Neutral Function (153) Poor system specifications frequently contain clues about an intended solution, function, or form, and these clues may lead the architect to a narrower set of potential options Principle of the Role of the Architect (194) The role of the architect is to resolve ambiguity, focus creativity, and simplify complexity Principle of Ambiguity (196) The early phase of a system design is characterized by great ambiguity The architect must resolve this ambiguity to produce (and continuously update) goals for the architect’s team Principle of the Stress of Modern Practice (206) Modern product development process, with concurrency, distributed teams, and supplier engagement, places even more emphasis on having a good architecture Principle of Architectural Decisions (211) Separate architectural decisions from other decisions, and take the time to carefully decide them up front, because they will be very expensive to change later on Principle of Reuse of Legacy Elements (228) Understand the legacy system and its emergent properties thoroughly, and include the necessary elements in the new architecture Principle of Product Evolution (230) Systems will evolve or lose competitive advantage When architecting, define the interfaces as the more stable parts of the system so that the elements can evolve www.downloadslide.net Principle of the Beginning (243)  The list of stakeholders (internal and external to the enterprise) that are included in the early stages of product definition will have an outsized impact on the architecture Principle of Balance (258)  Many factors influence and act on the conception, design, implementation, and operation of a system One must find a balance among the factors that satisfies the most important stakeholders Principle of the System Problem Statement (261)  The statement of the problem defines the high-level goal and establishes the boundaries of the system Challenge and refine the statement until you are satisfied that it is correct Principle of Ambiguity and Goals (266)  The architect must resolve this ambiguity to produce (and continuously update) a small set of representative, complete and consistent, challenging yet attainable, and humanly solvable goals Principle of Creativity (281)  Creativity in architecture is the process of resolving tensions in the pursuit of good architecture Principle of Apparent Complexity (303)  Create decomposition, abstraction, and hierarchy to keep the apparent complexity within the range of human understanding Principle of Essential Complexity (306)  Functionality drives essential complexity Describe the required functionality carefully, and then choose a concept that produces low complexity Principle of the 2nd Law (309)  The actual complexity of the system always exceeds the essential complexity Try to keep the actual complexity close to the essential complexity Principle of Decomposition (310)  Decomposition is an active choice made by the architect The decomposition affects how performance is measured, how the organization should be set up, and the potential for supplier value capture Principle of “2 Down, Up” (312)  The goodness of a decomposition at Level cannot be evaluated until the next level down has been populated and the relationships identified (Level 2) Principle of Elegance (314)  Elegance is appreciated internally by the architect when a system has a concept with low essential complexity and a decomposition that aligns many of the planes of decomposition simultaneously Principle of Robustness of Architectures (363)  Good architectures can respond to change by being robust (capable of dealing with variations in the environment) or by being adaptable (able to adapt to changes in the environment) Principle of Coupling and Organization of Architectural Decisions (368)  The sequence of architectural decisions can be chosen by considering the sensitivity of the metrics to the decisions and the degree of connectivity of decisions ... United States edition, entitled System Architecture: Strategy and Product Development for Complex Systems, 1st edition, ISBN 978-0-13-397534-5, by Edward Crawley, Bruce Cameron, and Daniel Selva.. .SyStem Architecture Strategy and Product Development for Complex Systems Global Edition Edward Crawley Bruce Cameron Daniel Selva Boston... about complex Systems 49 3.1 introduction 49 3.2 complexity in Systems 49 3.3 Decomposition of Systems 53 3.4 Special Logical relationships 57 3.5 reasoning through complex Systems 58 3.6 Architecture