122,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: Wiley Series in Systems Engineering and Management
- Sprache: Englisch
- Veröffentlichungsjahr: 2015
Presents modeling approaches that can be performed in SysML and other modeling languages This book combines the emerging discipline of systems architecting with model-based approaches using SysML. The early chapters of the book provide the fundamentals of systems architecting; discussing what systems architecting entails and how it benefits systems engineering. Model-based systems engineering is then defined, and its capabilities to develop complex systems on time and in a feasible quality are discussed. The remainder of the book covers important topics such as: architecture descriptions; architecture patterns; perspectives, viewpoints, views and their relation to system architecture; the roles of a system architect, their team, and stakeholders; systems architecting processes; agile approaches to systems architecting; variant modeling techniques; architecture frameworks; and architecture assessment. The book's organization allows experts to read the chapters out of sequence. Novices can read the chapters sequentially to gain a systematic introduction to system architecting. Model-Based System Architecture: * Provides comprehensive coverage of the Functional Architecture for Systems (FAS) method created by the authors and based on common MBSE practices * Covers architecture frameworks, including the System of Systems, Zachman Frameworks, TOGAF, and more * Includes a consistent example system, the "Virtual Museum Tour" system, that allows the authors to demonstrate the systems architecting concepts covered in the book Model-Based System Architecture is a comprehensive reference for system architects and systems engineers in technology companies. This book will also serve as a reference to students and researchers interested in functional architectures. Tim Weilkiens is the CEO at the German consultancy oose Innovative Informatik and co-author of the SysML specification. He has introduced model-based systems engineering to a variety of industry sectors. He is author of several books about modeling and the MBSE methodology SYSMOD. Jesko G. Lamm is a Senior Systems Engineer at Bernafon, a Swiss manufacturer for hearing instruments. With Tim Weilkiens, Jesko G. Lamm founded the Functional Architectures working group of the German chapter of INCOSE. Stephan Roth is a coach, consultant, and trainer for systems and software engineering at the German consultancy oose Innovative Informatik. He is a state-certified technical assistant for computer science from Physikalisch-Technische Lehranstalt (PTL) Wedel and a certified systems engineer (GfSE)- Level C. Markus Walker works at Schindler Elevator in the research and development division as elevator system architect. He is an INCOSE Certified Systems Engineering Professional (CSEP) and is engaged in the committee of the Swiss chapter of INCOSE.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 514
Ähnliche
Table of Contents
Cover
Title Page
Wiley Series in Systems Engineering and Management
Copyright
Foreword
Preface
About the Companion Website
Chapter 1: Introduction
Chapter 2: An Example: The Virtual Museum Tour System
Chapter 3: Better Products — The Value of Systems Architecting
3.1 The Share of Systems Architecting in Making Better Products
3.2 The Benefits that can be Achieved
3.3 The Benefits that can be Communicated Inside the Organization
3.4 The Beneficial Elements of Systems Architecting
3.5 Benefits of Model-Based Systems Architecting
Chapter 4: Definition of System Architecture
4.1 What is Architecture? – Discussion of Some Existing Definitions
4.2 Modeling the Definitions of “System” and “System Architecture”
Chapter 5: Model-Based System Architecture
Chapter 6: Architecture Description
6.1 Why Spending Effort to Describe the Architecture?
6.2 The Architecture Description
6.3 How to Get an Architecture Description?
Chapter 7: Architecture Patterns and Principles
7.1 The SYSMOD Zigzag Pattern
7.2 The Base Architecture
7.3 Cohesion and Coupling
7.4 Separation of Definition, Usage and Run-Time
7.5 Separate Stable from unstable parts
7.6 The Ideal System
7.7 View and Model
7.8 Diagram Layout
7.9 System Model Structure
7.10 Heuristics
Chapter 8: Requirements and Use Case Analysis
8.1 Identify and Define Requirements
8.2 Specify The System Context
8.3 Identify Use Cases
8.4 Describe Use Case Flows
8.5 Model the Domain Knowledge
Chapter 9: Perspectives, Viewpoints and Views in System Architecture*
9.1 Overview
9.2 The Functional Perspective
9.3 The Physical Perspective
9.4 The Behavioral Perspective
9.5 The Layered Perspective
9.6 System Deployment Perspective
9.7 Other Perspectives
9.8 Relation to the System Context
9.9 Mapping Different Perspectives and Levels
9.10 Traceability
9.11 Perspectives and Views in Model-Based Systems Architecting
Chapter 10: Typical Architecture Stakeholders
10.1 Overview
10.2 Requirements Engineering
10.3 Verification
10.4 Configuration Management
10.5 Engineering Disciplines
10.6 Project and Product Management
10.7 Development Roadmap Planners
10.8 Production and Distribution
10.9 Suppliers
10.10 Marketing and Brand Management
10.11 Management
Chapter 11: Roles
11.1 Roles
11.2 The System Architect Role
11.3 System Architecture Teams
11.4 System Architecture Stakeholders
11.5 Recruiting System Architecture People
11.6 Talent Development for System Architects
Chapter 12: Processes
12.1 The Systems Architecting Processes
12.2 Change and Configuration Management Processes
12.3 Other Processes Involving the System Architect
Chapter 13: Agile Approaches
13.1 The History of Iterative-Incremental and Agile Development
13.2 System Architects in an Agile Environment
Chapter 14: The FAS Method
14.1 Motivation
14.2 Functional Architectures for Systems
14.3 The FAS Method
14.4 FAS Heuristics
14.5 FAS with SysML
14.6 Modeling Tool Support
14.7 Mapping of a Functional Architecture to a Physical Architecture
14.8 Experiences with the FAS Method
14.9 FAS Workshops
14.10 Nonfunctional Requirements and the Functional Architecture
14.11 Completeness of the Functional Architecture
14.12 Functional Architectures and the Zigzag Pattern
Chapter 15: Product Lines & Variants
15.1 Definitions Variant Modeling
15.2 Variant Modeling with SML
15.3 Other Variant Modeling Techniques
Chapter 16: Architecture Frameworks
16.1 Enterprise Architectures
16.2 System of Systems (SS)
16.3 An overview Of Architecture Frameworks
16.4 The UPDM standard
16.5 What to do when we come in touch with architecture frameworks
16.6 Conclusion
Chapter 17: Cross-Cutting Concerns
17.1 The Game-Winning Nonfunctional Aspects
17.2 Human System Interaction and Human Factors Engineering
17.3 Risk Management
17.4 Trade Studies
17.5 Budgets
Chapter 18: Architecture Assessment
Chapter 19: Making It Work in the Organization
19.1 Overview
19.2 Organizational Structure for Systems Architecting
19.3 Recipes from the Authors' Experience
Chapter 20: Soft Skills
20.1 It's All about Communication
20.2 Personality Types
20.3 Intercultural Collaboration Skills
Chapter 21: Outlook: The World after Product Line Engineering
Appendix A: OMG SysML
A.1 Diagram and Model
A.2 Structure Diagrams
A.3 Behavior Diagrams
A.4 Requirements Diagram
A.5 Extension of SysML with Profiles
A.6 Architecture of the Language
Appendix B: The V-Model
B.1 A Brief History of the V-Model or the Systems Engineering Vee
B.2 A Handy Illustration but No Comprehensive Process Description
B.3 Critical Considerations
B.4 Reading Instruction for a Modern Systems Engineering Vee
Bibliography
Index
Wiley Series in Systems Engineering and Management
End User License Agreement
Pages
xi
xii
xiii
xv
xvi
xvii
xviii
xix
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
75
76
77
78
79
80
81
82
83
84
85
86
87
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
231
232
233
234
235
236
237
238
239
240
241
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
Guide
Cover
Table of Contents
Foreword
Preface
Begin Reading
List of Illustrations
Chapter 2: An Example: The Virtual Museum Tour System
Figure 2.1 One of the robots that was built during the robotics work by J.G. Lamm and E. Solda. © 2007, 2014 Jesko G. Lamm, reproduced with permission.
Figure 2.2 The fictitious museum robot with the purpose of enabling virtual museum tours.
Chapter 3: Better Products — The Value of Systems Architecting
Figure 3.1 Systems architecting plays a major role in breaking down requirements to solutions and in optimizing solutions for example by finding good trade-offs.
Chapter 4: Definition of System Architecture
Figure 4.1 Definition of “System”.
Figure 4.2 Definition of “System Architecture.”
Chapter 5: Model-Based System Architecture
Figure 5.1 System model.
Figure 5.2 Model versus repositories.
Figure 5.3 MDA levels.
Figure 5.4 SYSMOD intensity model.
Chapter 6: Architecture Description
Figure 6.1 Impacts of any kind on a process operated by a stakeholder causes concerns. A concern results in an interest in the system.
Figure 6.2 Architecture descriptions comprise views and viewpoints, architecture decisions, and related rationales. It identifies the system, the system context, stakeholder(s) and their concern(s), and system element(s) as building blocks of the system.
Figure 6.3 Architecture viewpoints comprise visualization kinds, defines architecture languages to be used and frames concerns to govern the creation of architecture views.
Figure 6.4 Architecture views comprise visualizations to address concerns. The creation is governed through architecture viewpoints. Architecture views may aggregate into perspectives.
Figure 6.5 Architecture decision and architecture rationale with their associations.
Figure 6.6 Definition of stereotype ArchitectureDecision as SysML extension with its application and rationale.
Figure 6.7 Headline structure of the Architecture Template 1.0 by the working group on moderately complex systems of Gesellschaft für Systems Engineering, e.V. (German chapter of INCOSE). Reproduced with kind permission from the German and Swiss chapter of INCOSE.
Chapter 7: Architecture Patterns and Principles
Figure 7.1 What and how.
Figure 7.2 The SYSMOD zigzag pattern.
Figure 7.3 Relationship between requirements and architecture kinds.
Figure 7.4 Zigzag pattern in the V-Model.
Figure 7.5 One zigzag pattern level in the model.
Figure 7.6 SysML rationale element to document derive relationship.
Figure 7.7 Definition of extended derive relationship.
Figure 7.8 Example of the extended derive relationship.
Figure 7.9 Model structure and relationships of the zigzag pattern.
Figure 7.10 Strictly separated zigzag levels.
Figure 7.11 Base architecture of the VMT.
Figure 7.12 Relationship of top level requirements to base architecture.
Figure 7.13 Product tree of the VMT base architecture.
Figure 7.14 VMT constraint requirement for base architecture.
Figure 7.15 Cohesion and coupling (Copyright oose Innovative Informatik eG).
Figure 7.16 Definition of a screw with SysML.
Figure 7.17 Usage of a screw with SysML.
Figure 7.18 Runtime setting of the screw with SysML.
Figure 7.19 Internal structure of the screw.
Figure 7.20 Abstract syntax of a use case.
Figure 7.21 Different layout directions.
Figure 7.22 Top level system model structure.
Chapter 8: Requirements and Use Case Analysis
Figure 8.1 (a) and (b) Overview requirements analysis artifacts.
Figure 8.2 Requirements in a SysML model.
Figure 8.3 System context.
Figure 8.4 Extended system context.
Figure 8.5 System use cases, abstract use cases, secondary use cases.
Figure 8.6 Continuous use case “Charge robot battery.”
Figure 8.7 Use case activity “Book a tour.”
Figure 8.8 Example activity diagram
Charge robot battery.
Figure 8.9 Extract of the VMT domain knowledge model.
Chapter 9: Perspectives, Viewpoints and Views in System Architecture*
Figure 9.1 Excerpt from the functional decomposition of the Virtual Museum tour system, presented in an informal way.
Figure 9.2 Excerpt from the functional decomposition of the Virtual Museum Tour system, in SysML.
Figure 9.3 A view from the functional perspective for a functional team working on utilization of robots.
Figure 9.4 Example view on the Virtual Museum Tour system in the logical architecture.
Figure 9.5 An interface view in the logical architecture: details on interfaces are defined by specifying the data flows according to Figure 9.4 in a domain knowledge model whose scope is the logical architecture.
Figure 9.6 Example view on the Virtual Museum Tour system from the physical perspective with focus on communication.
Figure 9.7 Example view on the Virtual Museum Tour system from the physical perspective with focus on installation.
Figure 9.8 An informal view in the layered perspective.
Figure 9.9 Layer-independent domain block “Position” and the derived layer-specific domain blocks.
Figure 9.10 Example view on the Virtual Museum Tour system from the layered perspective.
Figure 9.11 An interface view from the layered perspective: details on interfaces are defined by specifying the port types of ports from Figure 9.10 in a block definition diagram.
Figure 9.12 SysML representation of the layer stacks on different devices, as sketched in Figure 9.8.
Figure 9.13 SysML representation of the layer stacks on different devices, as sketched in Figure 9.8.
Figure 9.14 A view of the system deployment perspective in informal representation.
Figure 9.15 A constraint in the system deployment perspective in informal representation.
Figure 9.16 The constraint from Figure 9.15 in the system deployment perspective in SysML representation.
Figure 9.17 Example view on the Virtual Museum Tour system, taking parts of the system context into account.
Figure 9.18 An informal representation of the verification context.
Figure 9.19 The verification context in SysML Representation.
Figure 9.20 Detailed system architecture and traceability to requirements.
Figure 9.21 Logical-to-product mapping in a communication-focused view.
Figure 9.22 The partially hand-made version of Figure 9.5, as it could have come out of a workshop with stakeholders of the museum robot's higher communication layers.
Chapter 10: Typical Architecture Stakeholders
Figure 10.1 Collaboration between requirements engineering (RE) and systems architecting (SA).
Figure 10.2 Technical dependencies © 2014 Jakob K., reproduced with permission.
Figure 10.3 A fictitious example of predicting architecture work-load over time.
Figure 10.4 Split of concerns between system architect, project manager and product manager.
Figure 10.5 Using workload predictions from Figure 10.3 to support planning based on roadmaps.
Chapter 11: Roles
Figure 11.1 Abstraction skills © 2015 Jakob K., reproduced with permission.
Figure 11.2 Changing profile of a system architect with growing experience, based on the assumption that there has not been any systems engineering career or education upfront.
Chapter 13: Agile Approaches
Figure 13.1 Typical iteration cycle of agile development.
Chapter 14: The FAS Method
Figure 14.1 Functional-to-physical mapping.
Figure 14.2 Domain model for functional architectures.
Figure 14.3 Views on the system functions.
Figure 14.4 Matrix functional grouping.
Figure 14.5 Functional groups with hierarchies.
Figure 14.6 Part of the VMT functional architecture.
Figure 14.7 Example activity tree of the VMT.
Figure 14.8 Hierarchy relationship between functional groups.
Figure 14.9 Namespace containment of functional groups.
Figure 14.10 Traceability between functional blocks and functional groups.
Figure 14.11 Traceability from functional blocks to use case activities.
Figure 14.12 Function structure of the VMT.
Figure 14.13 Example functional architecture of the VMT.
Figure 14.14 Types of the functional block ports.
Figure 14.15 FAS process.
Figure 14.16 Manual and automated steps of the FAS task “Identify Functional Groups”.
Figure 14.17 Manual and automated steps of the FAS task “Model Functional Architecture”.
Figure 14.18 Example use case activity “Book a Tour”
Figure 14.19 Example use case activity “Identify Customer”.
Figure 14.20 Result of automatic creation of function groups.
Figure 14.21 Domain model of architecture landscape.
Figure 14.22 Allocation of functional parts to physical parts.
Figure 14.23 Functional to physical mapping matrix.
Figure 14.24 Example of use case cards.
Figure 14.25 Example of a activity card.
Figure 14.26 Sketch of a functional architecture.
Figure 14.27 Relationship of functional and Nonfunctional requirements.
Figure 14.28 Traceability from functional architecture to nonfunctional requirements.
Figure 14.29 Nonfunctional requirements in the functional architecture.
Figure 14.30 Functional coverage use cases and requirements.
Figure 14.31 Example FAS in the zigzag pattern.
Figure 14.32 Example FAS in the zigzag pattern.
Figure 14.33 Functional decomposition of robot control.
Chapter 15: Product Lines & Variants
Figure 15.1 Domain model for variant modeling.
Figure 15.2 Core and variants.
Figure 15.3 Top-level package structure.
Figure 15.4 SysML feature tree with variants.
Figure 15.5 Relationship between variant and core elements.
Figure 15.6 Variant configuration.
Figure 15.7 Example FODA tree.
Figure 15.8 CVL concept [102].
Figure 15.9 Example OVM.
Chapter 16: Architecture Frameworks
Figure 16.1 The interrelationship between business goals, information architecture and technology environments.
Figure 16.2 The TOGAF
®
Architecture Development Method (ADM).
Chapter 18: Architecture Assessment
Figure 18.1 Overview ATAM [72].
Figure 18.2 VMT objectives.
Figure 18.3 Excerpt from the quality attributes utility tree for the VMT.
Chapter 19: Making It Work in the Organization
Figure 19.1 Examples showing different alternatives for anchoring systems architecting in the organization, where option “(c)” is purely hypothetical.
Figure 19.2 Example showing the rating of how well organizational interfaces are established. The organizational information is freely invented.
Chapter 20: Soft Skills
Figure 20.1 A visualization of the four-sides model.
Figure 20.2 What are the four messages in this communication? © 2015 Jakob K., reproduced with permission.
Figure 20.3 The Allen curve depicts the negative correlation between frequency of communication and spatial distance.
Appendix A: OMG SysML
Figure A.1 SysML diagram types.
Figure A.2 Diagram interchange.
Figure A.3 SysML structure diagram types.
Figure A.4 SysML block.
Figure A.5 Example product tree of the VMT.
Figure A.6 Example domain model of the VMT.
Figure A.7 Activity tree.
Figure A.8 Activity tree with associated blocks.
Figure A.9 Example internal block diagram of the VMT.
Figure A.10 Flow properties and provided/requested features.
Figure A.11 Full and proxy port.
Figure A.12 Behavioral proxy ports in the functional architecture.
Figure A.13 Interface block specialization.
Figure A.14 Definition of a constraint property.
Figure A.15 Example of a parametric diagram.
Figure A.16 Model browser of a modeling tool.
Figure A.17 Example package diagram of the VMT.
Figure A.18 Tree-like notation of nested packages.
Figure A.19 SysML behavior diagram types.
Figure A.20 Example use case diagram.
Figure A.21 Example activity diagram.
Figure A.22 Opaque actions.
Figure A.23 Accept event action and send signal action.
Figure A.24 Example state machine diagram.
Figure A.25 Example sequence diagram.
Figure A.26 Example requirements diagram.
Figure A.27 Example requirements table.
Figure A.28 Example requirements matrix.
Figure A.29 Stereotype weightedSatisfy.
Figure A.30 UML for SysML.
Figure A.31 SysML and UML.
Appendix B: The V-Model
Figure B.1 A basic V-Model.
Figure B.2 V-Model with exemplary named basic development processes.
Figure B.3 V-Model considering discrete levels and numbers of elements.
List of Tables
Chapter 6: Architecture Description
Table 6.1 Explanation of Content of Architecture Description Template for Moderate Complex Systems
Chapter 7: Architecture Patterns and Principles
Table 7.1 Brief Description of Base Architecture Elements of the VMT
Chapter 9: Perspectives, Viewpoints and Views in System Architecture*
Table 9.1 Modular vs. Integral Architectures according to Ulrich [139]
Table 9.2 A Functional-to-Physical Allocation Matrix for Some Sample Elements of the Virtual Museum Tour System
Chapter 10: Typical Architecture Stakeholders
Table 10.1 Close Collaboration between System Architects and Requirements People as a Win–Win Situation
Table 10.2 Close Collaboration between System Architects and Verification People as a Win–Win Situation
Table 10.3 Close Collaboration between System Architects and Configuration Managers as a Win–Win Situation
Table 10.4 Close Collaboration between System Architects and Engineers in the Disciplines as a Win–Win Situation
Table 10.5 Close Collaboration between System Architects and Project Leaders as a Win–Win Situation
Table 10.6 Close Collaboration between System Architects and Roadmap Planners as a Win–Win Situation
Table 10.7 Close Collaboration between System Architects and Production and Distribution People Described as a Win–Win Situation
Table 10.8 Close Collaboration between System Architects and a Supplier's Architects as a Win–Win situation
Table 10.9 Close Collaboration between System Architects and Marketing or Branding People Can Be a Win–Win Situation
Table 10.10 A Good Relationship between System Architects and Management as a Win–Win Situation
Chapter 12: Processes
Table 12.1 Examples of Inputs, Outputs, and Contributors for the Systems Architecting Process
Chapter 14: The FAS Method
Table 14.1 Terminology
Chapter 20: Soft Skills
Table 20.1 The Four Messages in the Communication Depicted in Figure 20.1
Table 20.2 The Eight Psychological Types by C. G. Jung
Chapter 21: Outlook: The World after Product Line Engineering
Table 21.1 Product line engineering versus gaining market leadership with a full-custom product
Model-Based System Architecture
Tim Weilkiens
Jesko G. Lamm
Stephan Roth
Markus Walker
Wiley Series in Systems Engineering and Management
Andrew P. Sage, Founding Editor
A complete list of the titles in this series appears at the end of this volume.
Copyright © 2016 by John Wiley & Sons, Inc. All rights reserved
OMG SysML, OMG Systems Modeling Language, UML, Unified Modeling Language, Model Driven Architecture, MDA, Business Motivation Model, BMM and XMI are trademarks or registered trademarks of the Object Management Group, Inc. in the United States, the European Union and other countries.
Cameo is a registered trademark of No Magic, Inc.
FAS is a registered trademark of oose Innovative Informatik eG in Germany.
SYSMOD is a registered trademark of Tim Weilkiens in Germany.
V-Modell is a registered trademark of Bundesrepublik Deutschland in Germany.
TOGAF® is a trademark of The Open Group.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada.
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, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Weilkiens, Tim.
Model-based system architecture / Tim Weilkiens, Jesko G. Lamm, Stephan Roth, Markus Walker.
pages cm. – (Wiley series in systems engineering and management)
Includes index.
ISBN 978-1-118-89364-7 (hardback)
1. System design. 2. Computer simulation. 3. SysML (Computer science) I. Lamm, Jesko G., 1976- II. Roth, Stephan, 1968- III. Walker, Markus, 1965- IV. Title. TA168.W4338 2016
620′.0042–dc23
2015024774
Foreword
Contrary to popular myth, models are not new to systems engineering. Models are the way engineers analyze both problems and solutions, so systems models are as old as systems engineering itself. With the traditional focus on written specifications as the “source of truth,” models were secondary and descriptive – sometimes reflected as simple sketches, sometimes shown in formal diagrams, partially captured in analysis packages, and often trapped in the mind of the chief engineer. The transformation of systems engineering from document-centric to model-centric practices is not about the introduction of models. It is about making models explicit and moving them to the foreground where they serve as the authoritative tool for design, analysis, communication, and system specification.
Organizations today are investing heavily in representations, standards, methodologies, and technologies to transform the practice of systems engineering through model-driven paradigms. To manage the complexity of today's problems; to keep pace with today's rapidly evolving technologies; to capture the required knowledge regarding the problem, solution, and rationale; to respond effectively to change – all require that systems engineering join the other engineering disciplines in moving beyond document-centric techniques and embracing the power of a model-based foundation. With energy and focus over the last ten years has come notable progress. The industry has advanced in the area of representations with the development of SysML as a standardized set of diagrams to complement traditional systems representations. Numerous books – including a frequently cited guide by Tim Weilkiens – explain the details of using this notation to capture and communicate system designs to improve explicitness and alignment within the systems team. Alongside these representations have emerged countless standards and frameworks to help engineering teams develop high-fidelity models reflecting key systems dimensions.
However, for all the industry discussion regarding SysML, representations, standards, and tools, there remains a great deal of confusion. Understanding SysML notation and drawing SysML diagrams do not equate to doing model-based systems engineering. The use of disjoint models and simulation in systems engineering is also not equivalent to integrated model-based systems engineering.
Effectively moving forward with the transition to model-centric techniques requires that we step back to understand the bigger picture. Diagrams and other representations do not live in isolation but are interrelated and overlapping, communicating key aspects of the system model from specific viewpoints. System architecture and detailed analytical models are not disjoint, nor is there a single grand unified model to capture all dimensions of interest for all systems problems. To move forward, we must embrace the holistic systems perspective and apply it to model-based systems engineering, seeking out the interrelationships and developing a robust toolbox of supporting practices.
In this book, Tim Weilkiens, Jesko Lamm, Stephan Roth, and Markus Walker broaden our vision and expose us to a rich set of perspectives, processes, and methods so that we can develop an effective unified framework for model-based systems architecture. Building upon the existing industry library of textbooks on SysML, this book looks beyond the representation to address models, viewpoints, and views as part of a modern approach addressing requirements, behavior, architecture, and more. It connects to a larger framework of processes, methods, and tools key to enabling model-centric practices. And it looks beyond the technical space to the critical cultural dimensions because the transformation to model-centric techniques is far less a technical challenge than one of organizational change. Addressing the broader framework, Tim, Jesko, Stephan, and Markus bring model-centric practices together to help practitioners develop cohesive system architectures – our one chance in the life of a program to manage complexity, develop resilience, and design in critical concerns such as system security.
There is no doubt that the future of systems engineering is model-based. Document-centric techniques simply are not enough as we grapple with the challenges of today and tomorrow. Those practitioners and organizations who are early adopters in developing a cohesive model-centric framework of processes, methods, and tools will certainly be at a competitive advantage – whether producing products themselves or delivering systems services for others. If, as a profession, we can transform from document-centric to model-based systems engineering and do so with the vision of enabling model-based engineering, we can help transform the larger product lifecycle delivering radical improvements in quality, cost, and time to market for the benefit of all.
David Long President, Vitech Corporation INCOSE President (2014 and 2015)
Preface
Reacting to market needs on time with systems of high quality and marketable costs is a strong competitive advantage. Once a market need has been identified, multiple disciplines are involved in developing a system toward it. They need to collaborate closely and each according to a precise understanding of the own contribution to the system development. Effective communication and the creation of understanding for the whole system of interest are keys for the success. Organizations are facing a more and more dynamic environment, and at the same time, an increasing organizational complexity of distributed teams and stakeholders, and an increasing technical complexity of more heterogeneous relationships between system components and their environment. This context requests an explicit and sustainable system architecture.
Each of the engineering disciplines contributing to system development needs specific views for obtaining the needed insight. System models enable the creation of consistent sets of stakeholder-specific views. People using them gain a fast and comprehensible understanding of the system they are developing, which can help them choose appropriate solutions for fulfilling the market needs. All the views look on the same data baseline. There is no effort to consolidate redundant data or to clarify misunderstandings of inconsistent information and the costs of resulted errors.
A system architect needs to shape the system architecture well for realizing a successful system. Multiple tasks have to be carried out, each using an effective approach. This book provides a toolbox for the architect for his daily challenges. The scope of the book is a model-based environment, either it is already established and running or planned. The book explains how to use the SysML modeling language in obtaining model-based architecture descriptions. Nevertheless, the concepts are independent of SysML and could also be performed with other modeling languages.
This book is about people, models, and better products, based on our belief that model-based systems architecting produces better products by creating communication and insight for people involved in system development. The book presents a collection of methods and approaches which we see as ingredients for getting the system architecture work done successfully. We present model-based system architecting, which we see as a required backbone for excellent systems architecture work together with the stakeholders. We will show that involving the stakeholders means much more than running through a formalized review process.
A fundamental principle in system architecture is simplification. Without simple concepts to be communicated to the stakeholders, the system architect will not be understood and thus will fail. We advise you, dear reader, to adopt the principle of simplification and apply it to the multitude of approaches presented in the book. Feel free to only choose the approaches that are most suitable for your daily work and disregard the others, until you are in a situation where they turn out to be useful. The book is a well-stocked toolbox and not a rigid all-or-nothing process for system architects.
Our experience tells us that each organization will have a different focus area and will need different approaches. This is why we have bundled a variety of approaches we have observed being applied successfully in the industry, in the hope that you will find some pieces of information that are suitable exactly to your current activities. We have selected those approaches that we find easy to apply in daily work and are important for common model-based system architectures. We do not claim to provide a complete set. Every system architect loves to go to a hardware store to extend her toolbox. And from time to time, she has to discard one of her tools when it is no longer appropriate.
The book addresses system architects and their managers as well as engineers who are involved or interested in systems architecting. It is the first comprehensive book that combines the emergent discipline systems architecting with model-based approaches with SysML and puts together puzzle pieces to a complete picture. Highlighted puzzle pieces are
functional architectures and the Functional Architecture for Systems (FAS) method by Lamm and Weilkiens to derive the architecture from common use case analysis.
the integration of the concept of layered architectures from the software discipline in the context of system architectures.
the modeling of system variants.
the whole picture of different architecture kinds like functional, logical, and product architectures and their relationships.
a brief description of SysML and
a summary of the history of the V-model and recent thinking about it in the appendix.
As a typical reader of this book, you may have no time to read all chapters in sequential order. Therefore, we have made the chapters as independent from each other as we could, in order to enable you to read them individually or out of a dedicated sequence when you like inspiration about a certain topic. You can find on-demand reference about particular topics and get inspiration for directly using the presented approaches in your daily business. The topics are demonstrated using a fictitious robot-based solution for virtual museum visits as an example system.
We like to write texts using gender-fair language. On the other hand, we avoid to clutter the flow of reading by using always both genders in the same sentence. Therefore, we have only used one gender where it was not appropriate to use gender-neutral language. Feel free to replace he by she and she by he wherever it is appropriate.
We like to thank the “FAS” and “MkS” working groups of GfSE, the German chapter of INCOSE. The work in these groups has provided us with new ideas that can now be found in this book. We thank NoMagic for their support in working with the Cameo tool family that we used to create the SysML models and diagrams we used in multiple chapters of this book. We also thank Erik Solda for allowing us to use the robot example, Martin Ruch for contributing ideas about the assessment of organizational interfaces and all the colleagues at works, who have influenced our way of thinking, helped us with foreign languages in both reading and writing or recommended literature that is today part of the foundations of this book. We furthermore thank numerous people who provided us with advice after we had shown or explained them little fragments of this book to hear a second opinion.
We like to thank all the supporters of MBSE who believe that MBSE enables the successful development of complex systems. In particular, David Long, who is a great expert of MBSE from the very beginning and has written the foreword.
Finally, we like to thank Brett Kurzman, editor at Wiley, his assistants Alex Castro and Kathleen Pagliaro, and Bhargavi Natarajan for their support.
Tim Weilkiens, Jesko G. Lamm, Stephan Roth, Markus Walker
Contributor Matthias DÄnzer, Bernafon AG February 2015
About the Companion Website
This book is accompanied by a companion website:
www.mbse-architecture.com
The website includes:
High resolution version of all the figures in the book.
Chapter 1Introduction
Model-based system architecture (MBSA) combines the two key technologies: model-based and system architecting. Both are major parts of the future state of systems engineering [57].
Many systems result from an evolutionary development. They are driven by their parts and do not emerge from the architecture. The parts could be anything that in combination are assembled to a man-made technical system. System architecture is exhibited by a complete system. Often system architecture is referred to the architecture from the perspective of a software architecture in combination with the hardware or the architecture of software-intensive systems [20]. We understand system architecture is more holistic and also consider systems without any software. Although systems without any software that are handled with systems engineering processes and model-based system architecture concepts like described in this book are very rare, a system architecture is always present. In today's and future systems engineering, it is crucial to apply explicit system architecting for the success of the system project [57]. Chapter 4 defines the term system architecture within its context.
Studies clearly show that system architecting is critical for the performance and success of the system [34]. This is particularly evident for projects that require significant architectural work or rework. Due to more and more dynamic and complex markets and environments, the system architecture must more and more withstand the changing requirements and requests for radical changes. Chapter 3 lists the benefits of system architecting.
System architecture is about establishing solutions that are checked for feasibility by the corresponding experts, about designing interfaces that are agreed from both sides, and about ensuring that the people who should know the architecture of a system have a common understanding of it. MBSA uses models for enabling the creation of healthy communication around the architecture of the system and for ensuring that the architecture is validated from different points of view. Models are a key tool to be capable of developing complex systems on time and in a feasible quality. Chapter 5 defines the term model and MBSA and discusses the related terms.
Models are more than graphics. There are even models without any graphical representations. Just the graphics is not modeling, but drawing. To create a model you need semantics, which you find in a modeling language. We use the international standard Systems Modeling Language (SysML) as language for the system requirements and architecture models. Appendix A gives an overview about SysML. Although we extensively use SysML in this book, our methods and concepts are independent on SysML and could also be implemented by other modeling languages.
The system architect is the one in charge of shaping the system architecture. This is a big responsibility and a big challenge. The organizations dependent on the system should carefully select the people who are allowed to architect the system—and these people's work results will be tightly monitored by stakeholders everywhere in the organization. Chapter 19 describes how system architecting could be embedded in an organization and Chapter 10 discusses the interfaces to the stakeholders of system architecting. In particular Chapter 8 introduces the adjacent discipline requirements engineering that closely collaborates with the system architecting. The SYSMOD zigzag pattern presented in Chapter 7 shows the relationship between requirements and architecture and clearly demonstrates the need for a close collaboration. Artifacts of the model-based requirements and use case analysis are important inputs for the system architects especially to elaborate a functional architecture using the so-called FAS method.
Chapter 14 is a comprehensive presentation of the Functional Architectures for Systems (FAS) method. Functional architectures are built of functions only and are independent of the physical components that implement the functions. The functional architecture is more stable than a physical architecture that depends on the steadily changing technologies. The architecture principle to separate stable from unstable parts is covered in Chapter 7 about architecture patterns and principles.
Besides the functional architecture we define and discuss further system architecture kinds: the base architecture that fixes the preset technologies and adjusts the scope for innovation, the logical architecture that specifies the technical concepts and principles, and the product architecture that finally specifies the concrete system. All three architecture kinds are physical architectures. The layered architecture is an orthogonal aspect to these architecture kinds and is presented in Chapter 9.
Another orthogonal aspect is the modeling of variants. Variability is increasingly important. The markets are no longer satisfied by commodity products. The market requests customized products that fit to personal demands of the customers. In addition, global markets with different local environments and policies require different configurations of a system. Chapter 15 presents a model-based concept to specify different product configurations.
The architecture concepts are presented with a consistent example system. The “Virtual Museum Tour” system provides virtual visits by driving with camera-equipped robots through a real museum. The system is easy to understand and at the same time is sufficiently complex to demonstrate the system architecting concepts. The system is introduced in Chapter 2.
The system architect who thinks that his job is to make a diagram and save it on a shared network drive will most probably fail. Same for the system architects who think they are the bosses of the development staff and can instruct the other engineers. It is neither an archeological job nor a chief instructor job. System architecting is a collaborative work that requires communication and soft skills. The basics for a good communication is a common language and media to transport the information. Chapter 6 covers the artifacts of the architecture documentations. In Chapter 16, we extend our scope to system of systems and architecture frameworks.
Typically, engineers are focused on the technology challenges of their job. Nowadays, communication and more general soft skills are getting more and more important capabilities. The engineering disciplines are growing together. For instance, that could be seen by the modern discipline mechatronic. And the worldwide mankind is growing together due to the Internet, other communication, and transportation technologies. In consequence, an engineer has an increasing number of communication relationships. She is no longer successful when she only manages her technology tasks. It is also important to collaborate well with team members, stakeholders, communities, and so on. Chapter 20 gives an introduction about soft skills for engineers.
Chapter 2An Example: The Virtual Museum Tour System
We need an example system for the demonstration of various techniques to be presented in this book. The example of our choice is based on robotics work that one of us (Jesko G. Lamm) started doing as a leisure activity during his time at university, together with his fellow student Erik Solda who had the initial idea. During the course of this work, different robots were built. One of them is shown in Figure 2.1. It is the one that inspired the authors of this book in developing a fictitious example system to be presented in the following.
Figure 2.1 One of the robots that was built during the robotics work by J.G. Lamm and E. Solda. © 2007, 2014 Jesko G. Lamm, reproduced with permission.
For this book, we thought of a robot according to Figure 2.2. The robot would drive through a museum. A live video stream from a camera on the robot would be broadcasted. People with access to the live video stream could thus see the exposition, even when the museum is closed.
Figure 2.2 The fictitious museum robot with the purpose of enabling virtual museum tours.
When we had completed the first chapters of this book based on this example system, we noticed that we were not the only ones who had this idea: an organization called “The Workers” actually had this idea prior to us and invented a museum robot system that is called “After Dark”, because it is intended to run during the night when the museum is closed and dark. The Workers' idea of the After Dark system won the so-called “IK Prize”—including a budget that allowed them to actually build the system and offer the first virtual tour through the gallery Tate Britain on August 13, 2014 [74].
The After Dark system came to our attention quite late during the process of writing this book. Therefore, the system we use as an example here is mainly based on our own imagination and may thus be quite different from the After Dark system, for example, regarding its architecture. Still, the After Dark system has become an important source of inspiration after Tate's press release about it [17] had been discovered by one of the authors.
In our fictitious system according to Figure 2.2, one user can log in for controlling the robot via a web application on a computer or a hand-held device, like a smart phone. Multiple users can watch the video stream from the camera via a web application. The camera can zoom and move up and down. Roughly speaking, the system-of-interest is composed of the robot itself together with the infrastructure and remote control software that is needed to operate it. We call this system the “Virtual Museum Tour system (VMT)”. Chapter 9 will provide example architecture descriptions that provide a more precise definition of the system.
A little story may help understanding the capabilities of the example system: Currently, John is controlling a museum robot to drive it through a museum of arts. He has to write a report about modern art as a homework for school, and he has not had time to go to the museum during its opening hours. John types “Andy Warhol” on his smart phone and the robot starts driving to the pop arts division of the museum. Once there, it stops in the middle of a room. John now selects a painting showing a soup can. The robot moves toward the painting and stops in front of it. The camera on the robot now transmits a picture of the painting to John's smart phone. A little notification box on the smart phone displays the title of the painting. John needs to analyze the artist's way of working in more detail. Via commands entered on his smart phone, he moves the camera down. Then he zooms in on a particular area of the painting. Now he can see the necessary details via the video stream on his smart phone. This enables John to complete his homework for school.
Chapter 3Better Products — The Value of Systems Architecting
When driving down to the beach in a nice new car, we may enjoy how well this car grabs the road, and if mentally not yet ready for the beach we might ask ourselves which department in the car company is responsible for the driver's feeling that the car grabs the road. Is it the suspension design unit or the department with all the steering experts? We believe that all these departments alone cannot make us feel that the car grabs the road, because to do so, the car manufacturer has to see the “car as a system, as a collection of things that interact with each other and with the driver and the road” [93]. Systems architecting will ensure that the interactions between components are controlled in a proper way and that components are designed to fit each other.
3.1 The Share of Systems Architecting in Making Better Products
The example of the car that grabs the road was given by J.N. Martin [93]. We extend this example by speculating what would happen if different developers of car components were asked on whose merit is that the car grabs the road. As a reply, maybe the car manufacturer's suspension department and steering experts as well as the tire companies would claim that they are the ones, by making the best possible suspension, steering, tires, and so on, but in contrast to this, consider the following example by Russell L. Ackoff: “Suppose we bring one of each of these [many existing types of automobiles] into a large garage and then employ a number of outstanding automotive engineers to determine which one has the best carburetor. When they have done so, we record the result and ask them to do the same for engines. We continue this process until we have covered all the parts required for an automobile. Then we ask the engineers to remove and assemble these parts. Would we obtain the best possible automobile? Of course not.” ([2], p. 18).
Since systems architecting is concerned with making components fit together instead of making them “the best” each on its own, we believe that systems architecting is an approach that will help an organization think, develop, produce, and maintain better products.
3.2 The Benefits that can be Achieved
When talking of better products, then “better” can have two different meanings:
More satisfying or even more enjoyable for the customer (as shown with the “grabs the road” example).
More profitable for the organization.
Of course the first aspects may lead to the second one because products that are well received by the customer have the potential to become best-sellers and thus to generate profit for the organization.
It cannot be stated in general whether an organization sees it as most beneficial to minimize development cost, production cost or maximize user satisfaction or certain quality measures. In the end, trade studies will determine the optimum trade-offs between these different criteria and probably many more. Systems architecting is the activity that will produce well-founded trade studies, because it is right in between the requirements analysis work and the solution space that is framed by the development of different system elements. Figure 3.1 illustrates this based on the example of system-level trade studies across subsystems. Systems architecting can enable a top-down realization of business goals, requirements, quality criteria, and product strategies into solutions. This is almost independent from whether a completely new system is developed (a very rare case) or whether an existing system needs to evolve further, by architecting increments to an existing solution. The only difference is that constraints from the existing solution will enter trade studies in systems architecting in the latter case, via the expertise from subsystem development.
Figure 3.1 Systems architecting plays a major role in breaking down requirements to solutions and in optimizing solutions for example by finding good trade-offs.
It is via this top-down approach that usability, maintainability, reliability, and so on can be designed into the system and that concepts like design for user experience [51] or design to market [142] can be realized.
3.2.1 Benefit for the Customer
Different kinds of businesses have different customers: while the consumer goods industry targets millions of individual consumers, subcontractors target industries whose suppliers they are. Despite the variety of customers addressed by different industries, we believe that any system developer will increase customer satisfaction with investments into systems architecting.
The good news for industrial customers of subcontractors is as follows: we expect change requests and risk management to work very smoothly on a well-architected system with a proper architecture description in place. For example, we have seen cases in which the impact of a change could be easily analyzed, based on the architecture description, and since the system architecture captures dependencies inside the system we also expect it to help analyzing how uncertainty in one area of the system may lead to risks in other areas. Being able to manage risk based on the knowledge of the system architecture is indeed a potential sales driver, if we believe in one of the conclusions of J.P. Monat's article “Why Customers Buy” [97]: customers' perception of risk seems to be an important factor in the purchasing decision.
The good news for the consumer of mass products is as follows: we expect a properly architected system to have a good chance of working as expected in the market place, because systems architecting can allow for thinking the different modes of operation into it instead of just testing them into it, and well-defined interface descriptions may offer a basis for planning the systematic review or testing of component interactions in order to find flaws. This is particularly interesting with regard to discovering rare cases for which interfaces are not prepared. Well-documented architecture also enables continuous reassessment of quality, for example, by means of reviews and hence is a good basis for preventing flaws introduced by continuous changes during product improvements. This in turn may lower the threshold for continuous changes with the purpose of continuous product improvement.
Last but not least, the properly architected system has a good chance of achieving an attractive cost-benefit ratio, because the organization that developed the system and the production facility producing it could save development and production cost, as it will be explained in the next section.
3.2.2 Benefit for the Organization
Each system exhibits an architecture (ISO/IEC/IEEE 42010:2011 [64]) or in other words, every system development produces system architecture. The question is whether the system architecture evolves implicitly or whether it isexplicitly defined.
The precondition for the benefits to be discussed is an explicit way of system architecting, where system development explicitly involves system architecture processes. In case these are not yet established, there will be an initial investment into architecture work, before the organization can harvest the expected benefits.
Once an organization has established systems architecting as an integral part of system development, it should see the predictability and efficiency of system development increase and it should see cost decrease.
Predictability should be obtained because system architecture supports planning and risk management:
Planning is supported, because the knowledge about the system's architecture enables a completeness check of the work breakdown for the development work and the identification of dependencies between work packages. It is also supported because the order of integration and the needed verification can be planned and optimized according to knowledge about the system architecture.
Risk management is supported for example because the system architecture determines the contribution of subsystems to the system's performance and thus needs to be known for quantifying the influence of risks in subsystem development on the overall risk profile of system development.
Efficiency should be gained, because systems architecting can make system development shorter and even lead to reduced production cost. Shorter development time should be achieved because systems architecting can ensure that subsystem development is based on mature interface specifications, which reduces the risk of failures during system integration. Production cost can be reduced if production is thought into system development right from the start. Only with a system-level approach, one can effectively avoid errors in the assembly line, such as inefficient order of assembly steps. For example, there is a constraint on the order of steps in production, if the system is designed to have all the programming interfaces for production inside the housing, where they are inaccessible once the system is fully assembled. If production engineers can save cost by using the programming interface after the last assembly step, then a redesign of such a system may be triggered. Systems architecting should ensure that manufacturability is thought into the system in early phases of the life-cycle, such that a redesign as described is either not even necessary or happens “on paper” during early concept phases, thus before any money has been invested into engineering the components under redesign.
Cost should decrease, because systems architecting allows to steer system development into a suitable direction right from the start, leading to a focusedinvestment into development efforts. Thinking of Ackhoff's car example from the beginning of this chapter again, one might compute how expensive it can be to build the best possible variant of each part of the car. A very expensive endeavor, particularly because Ackoff's example tells us that the resulting car will be quite poor, meaning that even more cost will arise from making the car as a whole better. Systems Architecting can help reducing cost by ensuring that subsystems are developed and produced
according to the correct specification,
in just the quality that is needed, and not in worse or (even more expensive) better quality.
We also expect systems architecting to reduce cost, because it facilitates communication in and between development teams, spreads knowledge, makes knowledge accessible, and thus ensures that coordination effort stays low. As a result, an investment into system architecting may lead to reduced cost and thus to return of investment, but also to shortened time-to-market (which can again contribute to return-of-investment, e.g., if the battle against competitors is won in terms of being the first on the market with a certain asset). Of course an investment into system architecting is in the first place a driver of cost for organizations not practicing systems architecting yet. New ways of working have to be established via a costly change process. To be able to harvest, it may thus be necessary to accept higher cost in early phases, based on belief in the approach.
Finally, it may simply be more satisfactory for the engineers in an organization to work based on a well-defined systems architecture and spend their brainpower into making it right in the first place than to run after all interactions inside a system, while they are being discovered on the fly. If done right, systems architecting can be fun for all involved stakeholders.
3.3 The Benefits that can be Communicated Inside the Organization
In the struggle for budget and resources, different entities in the organization try to create transparency about their contribution to business success. System architects have a particular challenge in doing so, because their contribution is usually indirect. Architecture descriptions cannot be sold to the customer, unless the organization sells systems engineering consulting. System architects will thus have to convince the organization of their important contribution to making better products.
Earlier, it was mentioned that the suspension department in a car company will claim having a major share in how well the sold cars grab the road. The suspension experts in such a department may be insulted if the organization is told that this was the system architects' merit. Simply saying “System Architects are the ones that care about better products” therefore is probably not the right statement to make.
In our experience, it is the benefits for the organization that will in the end convince others of the value of systems architecting. In this case, it is certainly not sufficient to write these on a big poster or present strategy slides that list these benefits. The positive effect of systems architecting has to be “felt” in different parts of the organization. The best feedback a system architect can get is a testimonial from a key player in engineering, stating for example how well a certain interface definition activity has made different fields of engineering reach a common understanding and a well-functioning interface agreement.
