Model-Based System Architecture

AN UP-TO-DATE EXPLORATION OF THE NEWEST STANDARDS AND BEST PRACTICES IN SYSTEM ARCHITECTING

In the newly revised Second Edition of Model-Based System Architecture, a team of expert engineers deliver a detailed and authoritative review of the practice of system architecture in organizations that use models to support the systems engineering process. In the book, readers will find introductions to the fundamentals of architecting systems and using models to assist the architecting process.

The latest edition offers refreshed content based on ISO 15288:2015 and a renewed focus on the role of the system architect. New chapters on systems-of-systems, and cyber-physical systems, and system architect tools offer guidance to practicing professionals on how to apply the presented concepts in the real-world.

In addition to the latest definitions of the architecture governance and evaluation processes described in ISO 42020 and 42030, the book provides:

• A thorough introduction to the value of systems architecting, definitions of system architecture, and model-based system architecture
• Comprehensive explorations of model governance, architecture descriptions, patterns, and principles, and the roles of typical architecture stakeholders
• Practical discussions of Agile approaches to systems architecture, the FAS Method, and architecture frameworks
• In-depth examinations of systems architecting work and necessary soft skills for systems architects
• Modeling of system architectures with SysML including a brief overview of SysML v1 and an outlook to SysML v2

Perfect for system architects and system engineers, Model-Based System Architecture will also earn a place in the libraries of students and researchers studying functional architectures.

Tim Weilkiens is Executive Bord member of oose, a German engineering consultancy, and a co-author of the SysML specification.

Jesko 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 xv

Preface xvii

About the Companion Website xxi

1 Introduction 1

2 An Example: The Scalable Observation and Rescue System 5

3 Better Products – The Value of Systems Architecting 9

3.1 The Share of Systems Architecting in Making Better Products 9

3.2 Benefits that can be Achieved 10

3.2.1 Benefit for the Customer 10

3.2.2 Benefit for the Organization 12

3.3 Benefits that can be Communicated Inside the Organization 14

3.4 Beneficial Elements of Systems Architecting 15

3.5 Benefits of Model-Based Systems Architecting 16

4 Systems, Systems of Systems, and Cyber-Physical Systems 17

4.1 Definition of “System” 17

4.1.1 System Elements 19

4.1.2 System Context 20

4.1.3 System Characteristics 21

4.1.4 Purpose 22

4.1.5 System Evolution 23

4.2 Definition of “System of Systems” 23

4.3 Definition of “Cyber-Physical System” 26

4.4 Composition of a “Cyber-Physical System of Systems” 27

5 Definition of System Architecture 31

5.1 What Is Architecture? – Discussion of Some Existing Definitions 31

5.2 Relations Between Concepts of “System,” “Architecture,” and “Architecture Description” 33

5.3 Definition of “Architecture” 35

5.3.1 Interactions 36

5.3.2 Principles 37

5.3.3 Architecture Decisions 37

5.4 Functional and Physical Architecture 37

5.5 Taxonomy of Physical Architectures 39

5.5.1 Logical Architecture 40

5.5.2 Product Architecture 41

5.5.3 Base Architecture 41

5.6 Architecture Landscape for Systems 41

5.6.1 System Architecture 42

5.6.2 System Design 43

5.6.3 Discipline-Specific Architecture and Design 44

6 Model-Based Systems Architecting 45

7 Model Governance 51

7.1 Overview 51

7.2 Model Governance in Practice 52

8 Architecture Description 57

8.1 Architecture Descriptions for Stakeholders 58

8.2 Definition of “Architecture Description” 60

8.2.1 Architecture Viewpoints 62

8.2.2 Architecture Views 65

8.2.3 Architecture Decisions 67

8.2.4 Architecture Rationales 69

8.3 How to Get Architecture Descriptions? 69

8.3.1 Model-Based Vision 69

8.3.2 Forms and Templates 71

9 Architecture Patterns and Principles 75

9.1 The SYSMOD Zigzag Pattern 76

9.2 The Base Architecture 82

9.3 Cohesion and Coupling 85

9.4 Separation of Definition, Usage, and Run-Time 87

9.5 Separate Stable from Unstable Parts 89

9.6 The Ideal System 89

9.7 View and Model 90

9.8 Diagram Layout 92

9.9 System Model Structure 93

9.10 System Architecture Principles 95

9.11 Heuristics 95

9.11.1 Heuristics as a Tool for the System Architect 95

9.11.2 Simplify, Simplify, Simplify: Strength and Pitfall 97

10 Model-Based Requirements Engineering and Use Case Analysis 99

10.1 Requirement and Use Case Definitions 99

10.2 Model-Based Requirements and Use Case Analysis from the MBSA Viewpoint 102

10.2.1 Identify and Define Requirements 103

10.2.2 Specify the System Context 104

10.2.3 Identify Use Cases 105

10.2.4 Describe Use Case Flows 109

10.2.5 Model the Domain Knowledge 110

10.3 The SAMS Method 112

10.3.1 SAMS Method Definitions 113

10.3.2 SAMS Method 114

10.4 Use Cases 2.0 117

11 Perspectives, Viewpoints and Views in System Architecture 119

11.1 Introduction 119

11.2 The Functional Perspective 121

11.2.1 SysML Modeling of Functional Blocks 123

11.2.2 Architecture Views for the System Architect 124

11.2.3 Different Architecture Views for the Stakeholders of Different Functions 124

11.3 The Physical Perspective 125

11.3.1 Logical Architecture Example 126

11.3.2 Product Architecture Example 127

11.4 The Behavioral Perspective 130

11.5 The Layered Perspective 130

11.5.1 The Layered Approach 130

11.5.2 The Layered Perspective in Systems Architecting 132

11.5.3 Relation to the Domain Knowledge Model 134

11.5.4 Architecting the Layers 136

11.5.5 SysML Modeling of Layers 136

11.6 System Deployment Perspective 142

11.7 Other Perspectives 144

11.8 Relation to the System Context 146

11.8.1 Validity of the System Boundary 146

11.8.2 Using the System Context as a Part of the Stakeholder-Specific Views 146

11.8.3 Special System Context View for Verification 147

11.9 Mapping Different System Elements Across Different Levels 148

11.9.1 Functional-to-Physical Perspective Mapping 149

11.9.2 Mapping More Perspectives 153

11.9.3 Mapping Different Levels 153

11.10 Traceability 155

11.11 Perspectives and Architecture Views in Model-based Systems Architecting 155

11.11.1 Creating Different Architecture Views in a Model-Based Approach 155

11.11.2 Using SysML for Working with Different Perspectives and Architecture Views 157

11.11.3 The Importance of Architecture Viewpoints in Model-Based Systems Architecting 159

12 Typical Architecture Stakeholders 161

12.1 Overview 161

12.2 Requirements Engineering 162

12.3 Verification 163

12.4 Configuration Management 166

12.5 Engineering and Information Technology Disciplines 167

12.6 Project and Product Management 171

12.7 Risk Managers 174

12.8 Development Roadmap Planners 174

12.9 Production and Distribution 177

12.10 Suppliers 178

12.11 Marketing and Brand Management 178

12.12 Management 180

13 Roles 185

13.1 Roles 185

13.2 The System Architect Role 186

13.2.1 Objective 186

13.2.2 Responsibilities 186

13.2.3 Tasks 187

13.2.4 Competences 188

13.2.5 Required Skills of a System Architect 188

13.2.6 Required Skills for Model-Based Systems Architecting 190

13.3 System Architecture Teams 190

13.4 System Architecture Stakeholders 192

13.5 Recruiting System Architecture People 192

13.6 Talent Development for System Architects 194

14 Processes 199

14.1 Systems Architecting Processes 199

14.1.1 Overview 199

14.1.2 Example of Generic Process Steps 201

14.1.3 Example of Concrete Process Steps 202

14.1.4 Validation, Review, and Approval in a Model-Based Environment 203

14.2 Design Definition Process 207

14.3 Change and Configuration Management Processes 207

14.4 Other Processes Involving the System Architect 207

15 Tools for the Architect 209

16 Agile Approaches 213

16.1 The History of Iterative–Incremental Approaches 214

16.1.1 Project Mercury (NASA, 1958) 214

16.1.2 The New New Product Development Game (1986) 215

16.1.3 Boehm’s Spiral Model (1988) 216

16.1.4 Lean (1945 Onwards) 217

16.1.5 Dynamic Systems Development Method (DSDM, 1994) 219

16.1.6 Scrum (1995) 220

16.2 The Manifesto for Agile Software Development (2001) 221

16.3 Agile Principles in Systems Engineering 223

16.3.1 Facilitate Face-to-Face Communication 223

16.3.2 Create a State of Confidence 224

16.3.3 Build Transdisciplinary and Self-Organized Teams 225

16.3.4 Create a Learning Organization 225

16.3.5 Design, but No Big Design (Up-Front) 226

16.3.6 Reduce Dependencies 227

16.3.7 Foster a Positive Error Culture 228

16.4 Scaling Agile 228

16.5 System Architects in an Agile Environment 230

17 The FAS Method 233

17.1 Motivation 234

17.2 Functional Architectures for Systems 236

17.3 How the FAS Method Works 239

17.4 FAS Heuristics 242

17.5 FAS with SysML 244

17.5.1 Identifying Functional Groups 244

17.5.2 Modeling the Function Structure 246

17.5.3 Modeling the Functional Architecture 249

17.6 SysML Modeling Tool Support 250

17.6.1 Create Initial Functional Groups 251

17.6.2 Changing and Adding Functional Groups 254

17.6.3 Creating Functional Blocks and their Interfaces 254

17.7 Mapping of a Functional Architecture to a Physical Architecture 254

17.8 Experiences with the FAS Method 256

17.9 FAS Workshops 258

17.10 Quality Requirements and the Functional Architecture 259

17.11 Functional Architectures and the Zigzag Pattern 262

17.12 CPS-FAS for Cyber-physical Systems 263

18 Product Lines and Variants 269

18.1 Definitions Variant Modeling 270

18.2 Variant Modeling with SysML 271

18.3 Other Variant Modeling Techniques 276

19 Architecture Frameworks 279

19.1 Enterprise Architectures 280

19.2 Characteristics of System of Systems (SoS) 282

19.2.1 Emergence 283

19.3 An Overview of Architecture Frameworks 285

19.3.1 Zachman FrameworkTM 285

19.3.2 The TOGAF® Standard 286

19.3.3 Federal Enterprise Architecture Framework (FEAF) 288

19.3.4 Department of Defense Architecture Framework (DoDAF) 289

19.3.5 Ministry of Defense Architecture Framework (MODAF) 290

19.3.6 NATO Architecture Framework (NAF) 291

19.3.7 TRAK 292

19.3.8 European Space Agency Architectural Framework (ESA-AF) 293

19.3.9 OMG Unified Architecture Framework® (UAF®) 295

19.4 System Architecture Framework (SAF) 296

Together with Michael Leute 296

19.4.1 SAF and Enterprise Frameworks 296

19.4.2 SAF Ontology 298

19.5 What to Do When We Come in Touch With Architecture Frameworks 298

20 Cross-cutting Concerns 301

20.1 The Game-Winning Nonfunctional Aspects 301

20.2 Human System Interaction and Human Factors Engineering 303

20.3 Risk Management 304

20.4 Trade Studies 305

20.5 Budgets 306

21 Architecture Assessment 307

22 Making It Work in the Organization 313

22.1 Overview 313

22.2 Organizational Structure for Systems Architecting 314

22.3 Recipes from the Authors’ Experience 318

22.3.1 Be Humble 319

22.3.2 Appraise the Stakeholders 319

22.3.3 Care About Organizational Interfaces 319

22.3.4 Show that it Was Always There 321

22.3.5 Lead by Good Example 321

22.3.6 Collect Success Stories and Share them When Appropriate 322

22.3.7 Acknowledge that Infections Beat Dictated Rollout 323

22.3.8 Assign the System Architect Role to Yourself 324

22.3.9 Be a Leader 324

23 Soft Skills 327

23.1 It’s All About Communication 328

23.1.1 Losses in Communication 329

23.1.2 The Anatomy of a Message 330

23.1.3 Factors Influencing Communication 333

23.1.3.1 The Language 333

23.1.3.2 The Media Used 333

23.1.3.3 Spatial Distance 333

23.1.3.4 Various Connotations of Words 335

23.1.4 The Usage of Communication Aids and Tools 335

23.2 Personality Types 338

23.2.1 Psychological Types by C. G. Jung 338

23.2.2 The 4MAT System by Bernice McCarthy 340

23.3 Team Dynamics 341

23.4 Diversity and Psychological Safety 342

23.4.1 Project Aristotle (Google) 342

23.4.2 Elements of Psychological Safety 343

23.5 Intercultural Collaboration Skills 344

24 Outlook: The World After Artificial Intelligence 347

Appendix A OMG Systems Modeling Language 349

A.1 Architecture of the Language 350

A.2 Diagram and Model 352

A.3 Structure Diagrams 353

A.3.1 Block Definition Diagram 354

A.3.2 Internal Block Diagram 357

A.3.3 Parametric Diagram 361

A.3.4 Package Diagram 362

A.4 Behavior Diagrams 363

A.4.1 Use Case Diagram 364

A.4.2 Activity Diagram 366

A.4.3 State Machine Diagram 369

A.4.4 Sequence Diagram 371

A.5 Requirements Diagram 372

A.6 Extension of SysML with Profiles 374

A.7 Next-Generation Modeling Language SysML v2 376

Appendix B The V-Model 381

B.1 A Brief History of the V-Model or the Systems Engineering Vee 381

B.2 A Handy Illustration but No Comprehensive Process Description 383

B.3 Critical Considerations 385

B.3.1 The V-Model as Process Description 386

B.3.2 The V-Model Does Not Impose a Waterfall Process 386

B.3.3 The V-Model Accommodates Iterations 387

B.3.4 The V-Model Permits Incremental Development 387

B.3.5 The V-Model and Concurrent Engineering 388

B.3.6 The V-Model Accommodates Change 388

B.3.7 The V-Model Permits Early Verification Planning 388

B.3.8 The V-Model Shows Where to Prevent Dissatisfaction 388

B.4 Reading Instruction for a Modern Systems Engineering Vee 389

B.4.1 The Vertical Dimension 389

B.4.2 The Horizontal Dimension 389

B.4.3 The Left Side 389

B.4.4 The Right Side 390

B.4.5 The Levels 390

B.4.6 Life Cycle Processes 390

B.4.7 The Third Dimension 390

Appendix C Glossary 391

C.1 Heritage of the Term “Glossary” 391

C.2 Terms with Specific Meaning 393

References 399

Index 417

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.