TIM WEILKIENS is Executive Board Member of Oose, a German engineering consultancy, and a co-author of the SysML specification.JESKO G. LAMM is a Senior Systems Engineer in the European hearing healthcare industry.STEPHAN ROTH is a coach, consultant, and trainer for systems and software engineering at oose. He is a certified systems engineer (GfSE)®- Level C.MARKUS WALKER is Elevator System Architect in the CTO Division at Schindler Elevator. He is an INCOSE Certified Systems Engineering Professional (CSEP).

• Foreword xvPreface xviiAbout the Companion Website xxi1 Introduction 12 An Example: The Scalable Observation and Rescue System 53 Better Products – The Value of Systems Architecting 93.1 The Share of Systems Architecting in Making Better Products 93.2 Benefits that can be Achieved 103.2.1 Benefit for the Customer 103.2.2 Benefit for the Organization 123.3 Benefits that can be Communicated Inside the Organization 143.4 Beneficial Elements of Systems Architecting 153.5 Benefits of Model-Based Systems Architecting 164 Systems, Systems of Systems, and Cyber-Physical Systems 174.1 Definition of “System” 174.1.1 System Elements 194.1.2 System Context 204.1.3 System Characteristics 214.1.4 Purpose 224.1.5 System Evolution 234.2 Definition of “System of Systems” 234.3 Definition of “Cyber-Physical System” 264.4 Composition of a “Cyber-Physical System of Systems” 275 Definition of System Architecture 315.1 What Is Architecture? – Discussion of Some Existing Definitions 315.2 Relations Between Concepts of “System,” “Architecture,” and “Architecture Description” 335.3 Definition of “Architecture” 355.3.1 Interactions 365.3.2 Principles 375.3.3 Architecture Decisions 375.4 Functional and Physical Architecture 375.5 Taxonomy of Physical Architectures 395.5.1 Logical Architecture 405.5.2 Product Architecture 415.5.3 Base Architecture 415.6 Architecture Landscape for Systems 415.6.1 System Architecture 425.6.2 System Design 435.6.3 Discipline-Specific Architecture and Design 446 Model-Based Systems Architecting 457 Model Governance 517.1 Overview 517.2 Model Governance in Practice 528 Architecture Description 578.1 Architecture Descriptions for Stakeholders 588.2 Definition of “Architecture Description” 608.2.1 Architecture Viewpoints 628.2.2 Architecture Views 658.2.3 Architecture Decisions 678.2.4 Architecture Rationales 698.3 How to Get Architecture Descriptions? 698.3.1 Model-Based Vision 698.3.2 Forms and Templates 719 Architecture Patterns and Principles 759.1 The SYSMOD Zigzag Pattern 769.2 The Base Architecture 829.3 Cohesion and Coupling 859.4 Separation of Definition, Usage, and Run-Time 879.5 Separate Stable from Unstable Parts 899.6 The Ideal System 899.7 View and Model 909.8 Diagram Layout 929.9 System Model Structure 939.10 System Architecture Principles 959.11 Heuristics 959.11.1 Heuristics as a Tool for the System Architect 959.11.2 Simplify, Simplify, Simplify: Strength and Pitfall 9710 Model-Based Requirements Engineering and Use Case Analysis 9910.1 Requirement and Use Case Definitions 9910.2 Model-Based Requirements and Use Case Analysis from the MBSA Viewpoint 10210.2.1 Identify and Define Requirements 10310.2.2 Specify the System Context 10410.2.3 Identify Use Cases 10510.2.4 Describe Use Case Flows 10910.2.5 Model the Domain Knowledge 11010.3 The SAMS Method 11210.3.1 SAMS Method Definitions 11310.3.2 SAMS Method 11410.4 Use Cases 2.0 11711 Perspectives, Viewpoints and Views in System Architecture 11911.1 Introduction 11911.2 The Functional Perspective 12111.2.1 SysML Modeling of Functional Blocks 12311.2.2 Architecture Views for the System Architect 12411.2.3 Different Architecture Views for the Stakeholders of Different Functions 12411.3 The Physical Perspective 12511.3.1 Logical Architecture Example 12611.3.2 Product Architecture Example 12711.4 The Behavioral Perspective 13011.5 The Layered Perspective 13011.5.1 The Layered Approach 13011.5.2 The Layered Perspective in Systems Architecting 13211.5.3 Relation to the Domain Knowledge Model 13411.5.4 Architecting the Layers 13611.5.5 SysML Modeling of Layers 13611.6 System Deployment Perspective 14211.7 Other Perspectives 14411.8 Relation to the System Context 14611.8.1 Validity of the System Boundary 14611.8.2 Using the System Context as a Part of the Stakeholder-Specific Views 14611.8.3 Special System Context View for Verification 14711.9 Mapping Different System Elements Across Different Levels 14811.9.1 Functional-to-Physical Perspective Mapping 14911.9.2 Mapping More Perspectives 15311.9.3 Mapping Different Levels 15311.10 Traceability 15511.11 Perspectives and Architecture Views in Model-based Systems Architecting 15511.11.1 Creating Different Architecture Views in a Model-Based Approach 15511.11.2 Using SysML for Working with Different Perspectives and Architecture Views 15711.11.3 The Importance of Architecture Viewpoints in Model-Based Systems Architecting 15912 Typical Architecture Stakeholders 16112.1 Overview 16112.2 Requirements Engineering 16212.3 Verification 16312.4 Configuration Management 16612.5 Engineering and Information Technology Disciplines 16712.6 Project and Product Management 17112.7 Risk Managers 17412.8 Development Roadmap Planners 17412.9 Production and Distribution 17712.10 Suppliers 17812.11 Marketing and Brand Management 17812.12 Management 18013 Roles 18513.1 Roles 18513.2 The System Architect Role 18613.2.1 Objective 18613.2.2 Responsibilities 18613.2.3 Tasks 18713.2.4 Competences 18813.2.5 Required Skills of a System Architect 18813.2.6 Required Skills for Model-Based Systems Architecting 19013.3 System Architecture Teams 19013.4 System Architecture Stakeholders 19213.5 Recruiting System Architecture People 19213.6 Talent Development for System Architects 19414 Processes 19914.1 Systems Architecting Processes 19914.1.1 Overview 19914.1.2 Example of Generic Process Steps 20114.1.3 Example of Concrete Process Steps 20214.1.4 Validation, Review, and Approval in a Model-Based Environment 20314.2 Design Definition Process 20714.3 Change and Configuration Management Processes 20714.4 Other Processes Involving the System Architect 20715 Tools for the Architect 20916 Agile Approaches 21316.1 The History of Iterative–Incremental Approaches 21416.1.1 Project Mercury (NASA, 1958) 21416.1.2 The New New Product Development Game (1986) 21516.1.3 Boehm’s Spiral Model (1988) 21616.1.4 Lean (1945 Onwards) 21716.1.5 Dynamic Systems Development Method (DSDM, 1994) 21916.1.6 Scrum (1995) 22016.2 The Manifesto for Agile Software Development (2001) 22116.3 Agile Principles in Systems Engineering 22316.3.1 Facilitate Face-to-Face Communication 22316.3.2 Create a State of Confidence 22416.3.3 Build Transdisciplinary and Self-Organized Teams 22516.3.4 Create a Learning Organization 22516.3.5 Design, but No Big Design (Up-Front) 22616.3.6 Reduce Dependencies 22716.3.7 Foster a Positive Error Culture 22816.4 Scaling Agile 22816.5 System Architects in an Agile Environment 23017 The FAS Method 23317.1 Motivation 23417.2 Functional Architectures for Systems 23617.3 How the FAS Method Works 23917.4 FAS Heuristics 24217.5 FAS with SysML 24417.5.1 Identifying Functional Groups 24417.5.2 Modeling the Function Structure 24617.5.3 Modeling the Functional Architecture 24917.6 SysML Modeling Tool Support 25017.6.1 Create Initial Functional Groups 25117.6.2 Changing and Adding Functional Groups 25417.6.3 Creating Functional Blocks and their Interfaces 25417.7 Mapping of a Functional Architecture to a Physical Architecture 25417.8 Experiences with the FAS Method 25617.9 FAS Workshops 25817.10 Quality Requirements and the Functional Architecture 25917.11 Functional Architectures and the Zigzag Pattern 26217.12 CPS-FAS for Cyber-physical Systems 26318 Product Lines and Variants 26918.1 Definitions Variant Modeling 27018.2 Variant Modeling with SysML 27118.3 Other Variant Modeling Techniques 27619 Architecture Frameworks 27919.1 Enterprise Architectures 28019.2 Characteristics of System of Systems (SoS) 28219.2.1 Emergence 28319.3 An Overview of Architecture Frameworks 28519.3.1 Zachman FrameworkTM 28519.3.2 The TOGAF® Standard 28619.3.3 Federal Enterprise Architecture Framework (FEAF) 28819.3.4 Department of Defense Architecture Framework (DoDAF) 28919.3.5 Ministry of Defense Architecture Framework (MODAF) 29019.3.6 NATO Architecture Framework (NAF) 29119.3.7 TRAK 29219.3.8 European Space Agency Architectural Framework (ESA-AF) 29319.3.9 OMG Unified Architecture Framework® (UAF®) 29519.4 System Architecture Framework (SAF) 296Together with Michael Leute 29619.4.1 SAF and Enterprise Frameworks 29619.4.2 SAF Ontology 29819.5 What to Do When We Come in Touch With Architecture Frameworks 29820 Cross-cutting Concerns 30120.1 The Game-Winning Nonfunctional Aspects 30120.2 Human System Interaction and Human Factors Engineering 30320.3 Risk Management 30420.4 Trade Studies 30520.5 Budgets 30621 Architecture Assessment 30722 Making It Work in the Organization 31322.1 Overview 31322.2 Organizational Structure for Systems Architecting 31422.3 Recipes from the Authors’ Experience 31822.3.1 Be Humble 31922.3.2 Appraise the Stakeholders 31922.3.3 Care About Organizational Interfaces 31922.3.4 Show that it Was Always There 32122.3.5 Lead by Good Example 32122.3.6 Collect Success Stories and Share them When Appropriate 32222.3.7 Acknowledge that Infections Beat Dictated Rollout 32322.3.8 Assign the System Architect Role to Yourself 32422.3.9 Be a Leader 32423 Soft Skills 32723.1 It’s All About Communication 32823.1.1 Losses in Communication 32923.1.2 The Anatomy of a Message 33023.1.3 Factors Influencing Communication 33323.1.3.1 The Language 33323.1.3.2 The Media Used 33323.1.3.3 Spatial Distance 33323.1.3.4 Various Connotations of Words 33523.1.4 The Usage of Communication Aids and Tools 33523.2 Personality Types 33823.2.1 Psychological Types by C. G. Jung 33823.2.2 The 4MAT System by Bernice McCarthy 34023.3 Team Dynamics 34123.4 Diversity and Psychological Safety 34223.4.1 Project Aristotle (Google) 34223.4.2 Elements of Psychological Safety 34323.5 Intercultural Collaboration Skills 34424 Outlook: The World After Artificial Intelligence 347Appendix A OMG Systems Modeling Language 349A.1 Architecture of the Language 350A.2 Diagram and Model 352A.3 Structure Diagrams 353A.3.1 Block Definition Diagram 354A.3.2 Internal Block Diagram 357A.3.3 Parametric Diagram 361A.3.4 Package Diagram 362A.4 Behavior Diagrams 363A.4.1 Use Case Diagram 364A.4.2 Activity Diagram 366A.4.3 State Machine Diagram 369A.4.4 Sequence Diagram 371A.5 Requirements Diagram 372A.6 Extension of SysML with Profiles 374A.7 Next-Generation Modeling Language SysML v2 376Appendix B The V-Model 381B.1 A Brief History of the V-Model or the Systems Engineering Vee 381B.2 A Handy Illustration but No Comprehensive Process Description 383B.3 Critical Considerations 385B.3.1 The V-Model as Process Description 386B.3.2 The V-Model Does Not Impose a Waterfall Process 386B.3.3 The V-Model Accommodates Iterations 387B.3.4 The V-Model Permits Incremental Development 387B.3.5 The V-Model and Concurrent Engineering 388B.3.6 The V-Model Accommodates Change 388B.3.7 The V-Model Permits Early Verification Planning 388B.3.8 The V-Model Shows Where to Prevent Dissatisfaction 388B.4 Reading Instruction for a Modern Systems Engineering Vee 389B.4.1 The Vertical Dimension 389B.4.2 The Horizontal Dimension 389B.4.3 The Left Side 389B.4.4 The Right Side 390B.4.5 The Levels 390B.4.6 Life Cycle Processes 390B.4.7 The Third Dimension 390Appendix C Glossary 391C.1 Heritage of the Term “Glossary” 391C.2 Terms with Specific Meaning 393References 399Index 417