System Architecture Design and Platform Development Strategies

Tobias Münch
System Architecture
Design and Platform
Development
Strategies
An Introduction to Electronic Systems
Development in the Age of AI, Agile
Development, and Organizational
Change
System Architecture Design and Platform
Development Strategies
Tobias Münch
System Architecture Design

and Platform Development
Strategies
An Introduction to Electronic Systems
Development in the Age of AI, Agile
Development, and Organizational Change
Tobias Münch
Copenhagen, Denmark
ISBN 978-3-030-97694-1 ISBN 978-3-030-97695-8 (eBook)

https://doi.org/10.1007/978-3-030-97695-8
© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature
Switzerland AG 2022
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether
the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of
illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and
transmission or information storage and retrieval, electronic adaptation, computer software, or by similar
or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book
are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, expressed or implied, with respect to the material contained herein or for any
errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.
This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Acknowledgments
I would like to thank many people, as without them, the book would not be what it
turned out to be. So, here we go:
First of all, I would like to thank my wife, who has patiently watched the book
grow over the past years. She supported me with the initial thought and simultane-
ously challenged me with key questions. She was also crucial when it came to the
design concept of the illustrations. Last but not least, she had my back when I was
doing weekend, evening, and night shifts writing and revising the book alongside
my day job. Thank you love!
Special thanks go to Matthias Klötgen for the great discussions around system
architecture and systems engineering as well as for reviewing the entire book and
providing insightful comments. The same thanks go to Carlo Belardi for his thoughts
and for reviewing the book.
In addition, I would like to thank the various teams within the industry who I had
the pleasure of managing and working with over the years. Thank you for develop-
ing my impulses, thoughts, and projects further. Furthermore, thank you for think-
ing outside the box with me – you made it fun and were the reason for me always
striving to do better.
Thanks also to my peers within the industry. You relentlessly tossed around ideas
with me and challenged my approaches, enabling them to become even better.
Moreover, thank you to the mentors who I have had during my professional
career – you have given me great opportunities to grow professionally and person-
ally within a company context. Thanks also go especially to my coaches who have
functioned as brilliant sparring partners within my professional career.
Furthermore, I wish to thank Springer Nature, who had the patience to postpone
the deadline twice; thank you Scribbr and Ben for doing an amazing job of proof-
reading – quick and thorough; thank you Fiverr and oionin for helping to create the
illustrations.
v
vi Acknowledgments
And now for a little bit of cheesiness at the end: thank you to my son and my
daughter for giving me a great reason to teach and pass on my knowledge, and thank
you to my parents for having raised me in an environment of passion, creativity, and
belief in making a difference in the world.
And finally, thank you Bezzera for providing the perfect golden shot of Italian
Espresso every morning.
Contents
1 Introduction�� 1
1.1 Personal Excursion�� 2
1.2 Who Should Read This Book?�� 3
Part I System Architecture Design

2 System Architecture Design�� 7
2.1 Definition�� 7
2.2 Introduction to Systems Engineering�� 9
2.3 Electronic Systems Development �� 11
2.4 Preparation�� 12
2.4.1 Requirements�� 12
2.4.2 Team Structure�� 20
2.4.3 Product Life Cycle�� 25
2.4.4 Effort Estimation�� 30
2.4.5 Project Management �� 33
2.4.6 Task Force �� 33
2.4.7 Processes �� 34
2.5 Execution�� 41
2.5.1 System Architecture�� 41
2.5.2 Work Products and Documentation�� 70
2.5.3 Presentations �� 71
2.6 Example and Summary �� 72
2.6.1 Step 1: Preparation Phase�� 73
2.6.2 Step 2: Execution Phase�� 77
2.6.3 Step 3: Closing Phase �� 78
2.6.4 Summary �� 79
vii
viii Contents
Part II Platform Development Strategies

3 Platform Development Strategies �� 83
3.1 Definition�� 83
3.2 Why Platforms?�� 85
3.3 Business Aspects�� 87
3.3.1 Initial Overhead, Payback, and Life Cycle �� 87
3.3.2 Time to Market�� 101
3.3.3 Commercial Platforms�� 102
3.4 Technical Aspects�� 103
3.4.1 Key Components and Reference Systems�� 103
3.4.2 Platform Requirements �� 105
3.4.3 Reuse of Components �� 106
3.4.4 Strategy and Innovation�� 110
3.4.5 Software�� 112
3.4.6 Hardware�� 127
3.4.7 Quality and Stability �� 131
3.4.8 Central Storage�� 132
3.4.9 Support and Training�� 133
3.4.10 Technology Releases and Platform Development�� 134
3.4.11 Product Development and Platform Releases�� 135
3.4.12 Supplier Management �� 137
3.5 Organizational Aspects �� 138
3.5.1 Platform Development Organization�� 138
3.5.2 Timing and Team Size�� 141
3.5.3 Platform Project Management�� 143
3.6 Why Platforms Fail �� 144
3.6.1 Triangle of Platform Failure �� 145
3.6.2 Management Failure �� 146
3.6.3 Engineering Failure�� 146
3.7 Summary and Platform Development Cookbook �� 147
Part III AI, Agile, and Organizations

4 AI, Agile, and Organizations�� 155
4.1 Machine Learning and Artificial Intelligence �� 155
4.1.1 Machine Learning �� 155
4.1.2 Artificial Intelligence�� 156
4.1.3 Impact on System Architecture�� 157
4.1.4 Impact on Platform Development �� 159
4.2 Agile Development �� 160
4.2.1 Waterfall vs. Agile�� 161
4.2.2 Scrum�� 163
4.2.3 Agile Development for Large Projects �� 165
4.2.4 Scrum in a Waterfall Environment�� 166
Contents ix
4.2.5 Kanban�� 168

4.2.6 Agile Development Methods�� 170
4.2.7 Continuous Integration and Automation�� 172
4.2.8 User Stories�� 173
4.2.9 Effort Estimations �� 173
4.2.10 Impact on System Architecture and Platform
Development �� 174
4.3 Organizational Change�� 176
4.3.1 Industry 4.0 �� 177
4.3.2 Management 4.0�� 179
4.3.3 Impact on System Architecture and Platform
Development �� 182
Summary�� 185
Literature�� 189
Index�� 191
List of Figures
Fig. 2.1 A house as a system�� 8

Fig. 2.2 Systems engineering �� 9
Fig. 2.3 Space shuttle �� 10
Fig. 2.4 V model�� 11
Fig. 2.5 Knowledge libraries�� 14
Fig. 2.6 Requirements statistics�� 18
Fig. 2.7 Requirements tracking�� 19
Fig. 2.8 Architecture organization chart�� 21
Fig. 2.9 RFQ process diagram�� 28
Fig. 2.10 All product phases�� 31
Fig. 2.11 Automotive SPICE groups. (Copy from [5])�� 36
Fig. 2.12 Automotive SPICE: additional topics and plug-in concept�� 37
Fig. 2.13 System architecture work flow�� 41
Fig. 2.14 System topology diagram �� 43
Fig. 2.15 Hierarchy of elements �� 45
Fig. 2.16 Network topologies�� 50
Fig. 2.17 I2S interface�� 52
Fig. 2.18 Software message example �� 53
Fig. 2.19 Diagram of system elements�� 56
Fig. 2.20 Hardware block diagram�� 57
Fig. 2.21 High-level software block diagram�� 63
Fig. 2.22 Application-based software diagram�� 63
Fig. 2.23 UML diagram�� 64
Fig. 2.24 Variants and scaling�� 65
Fig. 2.25 Distributed systems �� 66
Fig. 2.26 Timing behavior diagram�� 68
xi
xii List of Figures
Fig. 3.1 Platform on three pillars as solid ground�� 84

Fig. 3.2 Sequential development�� 88
Fig. 3.3 Sequential development profit�� 90
Fig. 3.4 Parallel development�� 91
Fig. 3.5 Parallel development effort �� 92
Fig. 3.6 Platform development �� 93
Fig. 3.7 Platform development effort �� 97
Fig. 3.8 Profit increase based on the reuse factor�� 98
Fig. 3.9 Frozen platform release�� 100
Fig. 3.10 Continuous development with releases�� 101
Fig. 3.11 Open-source platform development�� 101
Fig. 3.12 Essential platform parts�� 104
Fig. 3.13 Four principles of platform development�� 106
Fig. 3.14 Reuse vs. effort �� 110
Fig. 3.15 Horizontal and vertical lines within software architecture �� 114
Fig. 3.16 Modularity�� 117
Fig. 3.17 Scalability �� 118
Fig. 3.18 Portability through abstraction layers �� 119
Fig. 3.19 Configuration of software modules�� 120
Fig. 3.20 Unit tests �� 123
Fig. 3.21 Integration tests�� 123
Fig. 3.22 Integration on reference systems�� 124
Fig. 3.23 System tests�� 125
Fig. 3.24 Platform in the pilot project�� 132
Fig. 3.25 Central storage�� 133
Fig. 3.26 Platform development interfaces�� 135
Fig. 3.27 Platform mindset�� 138
Fig. 3.28 Triangle of platform failure�� 146
Fig. 4.1 Waterfall flow�� 161
Fig. 4.2 Complexity diagram�� 167
Fig. 1 System architecture and platform development overview�� 187
List of Tables
Table 2.1 Requirements table �� 17

Table 2.3 RASIC chart �� 22
Table 2.2 Team availability table�� 22
Table 2.4 List of open issues�� 25
Table 2.5 Features and their resource needs�� 44
Table 2.6 Cross-project comparison matrix �� 46
Table 2.7 CPU and memory needs per project�� 47
Table 2.8 Processor family comparison matrix�� 55
xiii
About the Author
Tobias Münch studied telecommunication electronics at the Technical University

of Darmstadt, Germany. After finishing his diploma, he started his professional
career in the automotive industry, where he worked on several innovative predevel-
opment systems and products as a DSP engineer.He quickly moved on to work as
system architect and chief engineer for head units and amplifiers – including as the
lead of RFIs/RFQs – for several major car manufacturers in Europe, North America,
and Asia. Throughout his career, he has applied agile development methods across
the span of predevelopment, platform development, and product development
projects.Münch has always had structural, societal, and technical change in mind to
create technology and system development solutions that anticipate the future and
have long-term validity for B2B and eventually B2C customers. As Director of
Technology Development and Software Development, he managed several horizon-
tal and vertical international teams through changes in the automotive industry,
which was becoming increasingly driven by software, connectivity, and consumer
electronics. Furthermore, he was requested to share his knowledge and insights in
several company internal university courses and at industry-wide conferences.
Münch decided to move into the consumer industry to apply his automotive knowl-
edge regarding software, connectivity, and embedded systems and become more
experienced in other industries. He currently holds the position of Head of Audio
and Embedded Platforms.
xv
Chapter 1
Introduction
Today’s electronic systems range from small devices like simple Bluetooth speakers
to highly complex systems like satellites or spaceships. Systems are becoming
increasingly sophisticated, processors are getting faster, and sensors are being
increasingly introduced into our daily lives. It seems as though everybody is talking
about artificial intelligence, autonomous cars, and the Internet of Things. Systems
are increasingly connected, becoming larger systems such as smart cities and intel-
ligent networks.
How are those electronic systems developed? How can people organize them-
selves to create something like a spaceship and ensure that it does not fall from the
sky when launched? How can people get together and develop something like a car
navigation system, which today must integrate several subsystems such as a tele-
phone, hi-fi system, personal computer, music player, cloud connectivity, and driver
assistance? It sometimes appears to be a miracle how a development and fully
implemented feature set reach the end and products are released and sold. It is a
common practice that, for example, some car manufacturers create tens of thou-
sands of requirements to describe their next-generation navigation system in a car.
These requirements are handed over to suppliers, who are asked for a quote in the
course of a few weeks. How can a company handle that? How can it read and under-
stand all of those requirements? How can it ensure that the system it is offering
works if it is not yet developed? How can the company ensure that its offer of a
certain price will have a sufficient margin for earning money? How can it ensure
that the business case it forecasts during the offering phase will still hold at the end
once the system has been developed and can be shipped?
Other car manufacturers might hand some block diagrams over and ask for a full
system and price. How can a company ensure that what it is offering is really what
the manufacturer wants? Alternatively, if a company wishes to develop a new elec-
tronic system out of its own initiative, how should it begin? What must be consid-
ered from a technical point of view? How should the company manage the
complexity? How can it ensure that the price and architecture are superior to those
© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 1

T. Münch, System Architecture Design and Platform Development Strategies,
https://doi.org/10.1007/978-3-030-97695-8_1
2 1 Introduction
of its competitors, or at least that they target the desired market segment? How is it
possible to handle such complex systems? Furthermore, what role does agile devel-
opment play here? Last but not least, what does this mean for the system architec-
ture and platform development of such electronic systems?
During my career in the automotive industry, I learned a great deal about the
design of various system architectures as well as how to improve efficiency and
quality in the development using platform development strategies. After all these
years, I am convinced that there is no other way to develop complex systems and
stay competitive over a long period of time than to use a very solid system architec-
ture design process in combination with a platform development strategy. This is the
fundament for answering all of the aforementioned questions. In this book, I aim to
describe the necessary details along with my personal findings and some real-world
examples.
1.1 Personal Excursion
My first job in the industry already involved designing a full system. It was a small
system and pure predevelopment; however, because of the size of the project, it was
nearly a one-man show and I had to do everything on my own. I created the full
software on a DSP,1 and with the help of a colleague, I also created the software for
the microcontroller. I checked the hardware design and measured several clocks and
data pins on the hardware board. Then, I searched the Internet to find a supplier to
produce a housing with a nice front plate. Next, I bought connectors and soldered
everything together. Last but not least, I connected the whole device with another
off-the-shelf product and took care of the communication protocol and bandwidth
among other things. The second generation of that device, still a predevelopment
prototype some months later, had three self-designed DSP main boards and a com-
plex tuning tool on a PC connected via TCP/IP.2 I contracted an external supplier to
work on several software work packages for me. This, over these months, I learned
what it means to be responsible for the whole system, from idea and requirements
to the final end. I also learned what it means to ship to several departments, includ-
ing the user guide. Furthermore, I learned important things about digital hardware
design, mechanics, housing, supplier management, documentation, and tests.
Moreover, I of course learned about software in all kind of flavors, such as C code
on the microcontroller and DSP, C# on PC, optimized assembly routines for the core
algorithm, different frameworks, and TCP/IP stacks. I also made several decisions
in evaluating the pros and cons of Ethernet or USB among others. Because I saw
this as a training phase where I worked on a great project with passion and a fun
1
A DSP is a Digital Signal Processor. It is optimized to do digital signal processing, which is also
called DSP.
2
TCP means Transmission Control Protocol and IP means internet protocol. Both are fundamental
network protocols.
1.2 Who Should Read This Book? 3
attitude, it was quite easy to jump into more sophisticated and serious system archi-
tectures in automotive head units. Basically, it was the same as before, but much
more complex and sophisticated. I worked on several products for European, North
American, and Asian car manufacturers and quickly got used to it. I climbed the
ladder until finally leading a team of system architects for a certain area of the
company.
In parallel, I always had students and worked on innovative topics with them.
This is how I came to machine learning and artificial intelligence. Back in those
days, we didn’t make too much noise about it. It was just another way of doing
signal processing, using feature extraction, classification, and neural networks to
train and learn certain things in audio applications. Today, AI is one of the most
important buzzwords in the industry. Companies who want to be on the cutting edge
of technology must have activities in this area.
In addition, on the platform development side, I was in the lucky position of
always working in platform development departments with excellent people around
me, such as engineers who always wanted to create implementations that could be
reused. They didn’t want to develop or explain the same functionality repeatedly.
This really helped to drive a platform development approach with proper documen-
tation! At the end, I always saw great structures up and running where organization
and development were highly optimized with maximum possible reuse.
Unfortunately, nothing lasts forever – management and technology change, key
engineers leave, and budget cuts occur, not to mention politics – all of which can
damage the platform development approach.
1.2 Who Should Read This Book?
My main motivation for writing this book was to get everything that I discussed
with colleagues and that I told the engineers on various training courses written
down. The courses were about system architecture and platform development. A
wide range of people usually attended those events, such as software engineers,
hardware engineers, and system engineers, in addition to requirements engineers
and sales people among others. This book covers a wide range of topics and could
be of interest to all of the aforementioned people. Anybody working in electronics
product development at an architecture level might find this book useful and find
certain aspects to complete his or her picture of developing systems efficiently. If
somebody is new in the business or wants to step up from being a software or hard-
ware architect to become a system architect, then he or she may find this book use-
ful to obtain the full picture and a good understanding. This book is also for
managers leading architecture and development departments, or for directors set-
ting up a whole engineering department. My aim is to help them to create the ideal
structure in their company and to ensure the development is as efficient as possi-
ble – and this, of course, will result in a cost-optimized approach: Make more with
less money! However, it is not only the cost factor that I wish to mention here. There
4 1 Introduction
is nothing more annoying for managers and especially engineers than when things
are not running smoothly and efficiently – so let’s make it smooth and efficient and
have more fun at work!
That’s enough about my career, experience, and philosophical thoughts. Now,
let’s look into system architecture design and platform development strategies in
more detail and see what fundamental principles we can find.
The first part of this book covers the system architecture design aspect. You will
read a great deal about the why, how, what, and when.
The second part concerns platform development. You will learn about why and
how to develop with platform thinking in mind and what consequences this will have.
The third part covers some special topics such as agile development and artificial
intelligence and why these topics are related to system architecture and platform
development. It also covers the organizational progress that we can see in the indus-
try today and what this means for electronic systems development.
Part I
Chapter 2
2.1 Definition
Nothing is particularly hard if you divide it up into small jobs.

– Henry Ford
Founder of Ford Motor Company
Before going into detail, I wish to define the term system architecture design. A
system in this context is a limited hierarchical structure of architectural elements
that fit together into one logical piece that has a certain behavior. It is limited with
interfaces to the outside world and also limited to the inside atomic pieces that make
sense to observe in this particular case. Let’s use a house as an example and define
it as a system. We need to know what the architecture of the whole house looks like
and have a hierarchy going into increasing levels of detail. The smaller architectural
elements are, for example, the second floor of the house, the kitchen on the second
floor, or the refrigerator in the kitchen. The PCB1 controlling the refrigerator is
probably not interesting for this particular view anymore, but it becomes interesting
if we see the refrigerator as a new system itself. Then, the level of details is housing,
damping, and internal things and perhaps also the microcontroller used on the afore-
mentioned PCB. The hierarchical structure is limited because we stop in the upward
direction at the definition of the house. We do not want to see the whole street, city,
country, and Earth, but we need a clear interface definition between house and
1
PCB means printed circuit board. This is the board in electronic devices carrying the electronic
parts and circuits soldered onto it.

https://doi.org/10.1007/978-3-030-97695-8_2
8 2 System Architecture Design
Fig. 2.1 A house as a system
ground. Furthermore, we want to deal with environmental conditions and make sure
that the house remains stable and functioning in regional weather conditions. We
also limit our view to the inside and the other end of details. For example, we might
look into the microcontroller and move bits and bytes around, but we are probably
not interested in the transistors and electrons moving around in the chip. Therefore,
the smallest part, the atomic piece in this case, is relative and depends on the system
that is in focus. The architect for the house would probably end at the refrigerator as
the smallest element. The refrigerator itself is again a system, but another architect
has designed it – you get the idea (Fig. 2.1).
Especially in electronics systems, the architectural elements comprise at least
hardware, software, and mechanical elements in a specific environment and with
specific behavior. Those elements need to be evaluated, investigated, and designed
very closely together because of their interdependencies. In the automotive industry
in particular, where I come from, one must deal with additional requirements defined
for the different areas such as special hardware requirements, safety, and security
topics. Electronic parts should function in an extended temperature range with a
better failure rate than consumer products usually have. Other industries such as
medical or avionics engineering again have different requirements.
Finally, system architecture design is the process of creating system architectures
as described above.
2.2 Introduction to Systems Engineering 9
2.2 Introduction to Systems Engineering
Design is not just what it looks like and feels like. Design is how it works.
– Steve Jobs
CEO and Co-founder of Apple
In detail, what is necessary for designing a system and all its hierarchical architec-
tures? How is this topic embedded into the broader field of systems engineering?
Systems engineering is a discipline and a mindset for developing large complex
technical systems. It covers all aspects of technical development and project man-
agement (Fig. 2.2). A good overview can be found in the book Systems Engineering
by Kossiakoff and Sweet [1] or in Systems Engineering Fundamentals by the
Department of Defense [2]. While systems engineering covers the whole process, I
wish here to focus on the technical design part instead. I will not go into too much
detail in terms of project management. Moreover, I will write about integration and
test strategies only on a very high level.
Systems engineering is a holistic approach for developing a specified system. It
breaks the whole development process down into subsystems, components, and
parts and guides from idea to production. The main idea is to bring the different
disciplines together and control interdependencies. The systems engineer must fol-
low various well-defined processes.
Furthermore, systems engineering involves a special mindset. If one wants to
introduce systems engineering in a company, the whole culture must change.
Systems engineering became relevant around 1940, when Bell Laboratories
developed their first telecommunication systems.2 Its importance increased with
complex systems such as rockets, space shuttles, and satellites, where organizations
spent millions for a single shot.
Fig. 2.2 Systems engineering
2
https://en.wikipedia.org/wiki/Systems_engineering
Simon Ramo, who is considered the inventor of systems engineering, described

it as follows: “...a branch of engineering which concentrates on the design and
application of the whole as distinct from the parts, looking at a problem in its
entirety, taking account of all the facets and all the variables and linking the social
to the technological” [3].
Here, I wish to focus on electronic systems development. My main experience
comes from automotive and consumer electronic devices. Therefore, I will not talk
about space shuttles (Fig. 2.3) and satellites too much. If you are interested in such
systems, perhaps have a look into a book such as Spacecraft Systems Engineering
by Fortescue, Stark, and Swinerd [4], or download the NASA Systems Engineering
Handbook,3 in which you will learn all about spacecraft systems engineering. You
will see that the main principles are always the same, but every industry has its spe-
cialty. In spacecraft engineering, perhaps it is the challenging environment that
makes it special and influences the architecture design tremendously. Furthermore,
space shuttles usually don’t go into mass production.
Fig. 2.3 Space shuttle
3
https://www.nasa.gov/connect/ebooks/nasa-systems-engineering-handbook
2.3 Electronic Systems Development 11
2.3 Electronic Systems Development
Now we want to develop an electronic system. What does it mean? How do we

start? First of all, we need requirements. What should the system look like? What is
the purpose of the system? What should it do? How should it behave? Creating and
collecting requirements is already a systems engineering discipline. One needs a
requirements engineer to organize and manage the requirements and then immedi-
ately someone who can tell you how to realize a system with all of these require-
ments. This is the system architect! For complex systems, he or she probably cannot
work alone. He or she won’t be able to handle all of those specific technical domains.
Therefore, a team of specialists is required. Moreover, the team members need to
communicate. In addition, processes are required, such as processes for capturing
the requirements and tracing them systematically through all of the development
process phases. Other processes are also needed, such as one for creating the system
design or one for the RFQ4 phase. Moreover, the development process itself is of
course one of the most crucial. Then, someone at the end of the development can
look into the requirements and test the system against them. In terms of project
management, one of course needs a project manager who can kick off the project,
who creates a time plan; manages the team, budget, and effort; and has tools to track
the progress of the development teams. In particular, the system architect needs a
knowledge base for all kinds of hardware, software, and mechanical solutions, yet
those that exist in the company or are available on the shelf or in the roadmaps of
suppliers.
The so-called V model,5 illustrated in Fig. 2.4, is an effective approach to system-
atically work through the development of a system.
Fig. 2.4 V model
4
RFQ means request for quotation. We come back to that later.
5
The V-model is a graphical representation of a system development life cycle (Wikipedia).
The model starts with analyzing the requirements for the system. Then, it goes
through different levels of design phases until the implementation of features and
components. The testing phases receive specifications for how to test from the cor-
responding phases on the left side of the V. System testing is the final check of
whether the requirements are fulfilled. By the way, this is independent of one’s
project management style – it can be waterfall or agile – but these phases should
always be there. More details about agile and how it is related to system architecture
can be found at the end of the book in the chapter about agile development.
You can see that system architecture design is a highly interdisciplinary activity
and that the role of a system architect has some overlap with the other aforemen-
tioned topics. Therefore, let’s discuss the topics surrounding the actual design pro-
cess, starting with some details about requirements.
2.4 Preparation
2.4.1 Requirements
All architecture work starts with requirements. Without requirements, you cannot
start! The format, quality, and level of details of these requirements can vary greatly.
In the automotive industry, there are car manufacturers that just create some draw-
ings and hand them over to the supplier. Others create detailed architectures, con-
duct feasibility studies, manage subsuppliers upfront, and create thousands of
detailed requirements for a complete system with all aspects. The job of the system
architect is to screen these requirements, delegate them to specialists or functional
domain leaders, and create a first sketch of a system architecture together with them.
As mentioned above, this is an iterative process where the system architect with his
or her core team designs a system as a baseline for the requirements work of the
functional domain leaders. They might come back with a special requirement that
again changes the system architecture.
Creating the first sketch is a critical step in system design and requires a great
deal of experience, a technical strategy, and excellent knowledge about the avail-
ability of in-house and external technologies.
2.4.1.1 Technical Strategy
The system architect needs to have a technical strategy that is either aligned with
other architects in the company or given by the Chief Technology Officer or other
people in charge of technical directions such as Chief Engineers. This strategy could
include pushing for a certain technology. It could also mean that a certain processor
family is preferred, or that as much as possible should be used from an existing
2.4 Preparation 13
internal platform development, or that new proprietary technologies from one’s

company should be used. These are all internal requirements that need to be consid-
ered. They need to be added to the customer requirements.
2.4.1.2 Platform Content
The term platform here means a collection of key building blocks in software and
hardware and maybe more. It does not mean a platform that is one specific piece of
hardware. This is a common misunderstanding and needs to be defined clearly
before we start talking about it. Please refer to the platform chapter in the second
part of the book for further details. But here, let’s assume that it is a collection of key
components that are designed to be reused as often as possible across customers and
projects. Thus, the main benefit is to develop something once and use it often. For
example this can be achieved by employing the approach of developing modular,
scalable, hardware platform-independent, and configurable components.
The system architect needs to know and clearly understand what is available in
the platform development departments as well as what is not. In addition, he or she
needs to know the internal roadmap of all platform components to evaluate whether
something that is not yet available might fit the project timing.
From a requirements point of view, the features of the platform need to be written
down and maintained properly so that they can be compared against customer
requirements easily. This could be in the same requirements tool or at least using the
same language. A global approach with a central database helps a great deal.
The system architect also reports what his new project looks like back to the
platform along with what features are missing from the platform. With that informa-
tion, the platform can evolve and adapt continuously to the newest needs and mar-
ket trends.
2.4.1.3 Product-Specific Content
Even the most comprehensive platform might have some gaps for certain customer
requirements, so there will be always parts in the new system that need to be devel-
oped new and from scratch. At least a change of key components will be necessary.
The system architecture team identifies these gaps and creates concepts for develop-
ment. It might be necessary to immediately start some feasibility studies to mitigate
risks. Clever concepts must be developed. If these gaps are so-called no-brainers,
the development departments only need to provide an effort estimation. Either way,
the development departments need to estimate their development effort and inform
the project team about potential risk as well as their capacity to support the project.
It makes sense that a clear differentiation exists between requirements that can be
covered by platform components and those that need to be developed new. An all-
in-one requirements management tool with architecture descriptions and effort esti-
mations will help greatly in always having the full picture at hand.
2.4.1.4 System Requirements
With all of this information, the system architect sketches a first draft of the system
architecture. This first sketch creates more requirements – or let’s say precondi-
tions – for the following design steps. Therefore, some system requirements might
be written down already from the customer, while others might be created during
the design process. They should be written down and treated with the same under-
standing. These boundary conditions are the guidelines for the design of the subsys-
tems. This is again an iterative process where the architects of the subsystems need
to come back to the overall system architect and tell him or her whether they can
meet all of the requirements.
2.4.1.5 Networking and Libraries
It is essential for the system architect to know exactly what is available in the com-
pany and on the market. He or she must establish a network of experts and knowl-
edge pools to always have the latest information at hand. This might include skill
sets and experiences from different departments or concrete processor roadmaps
and comparison tables with detailed features. The system architect also needs to
know the history of previous products to evaluate whether solutions are already
available for certain requirements. Basically, he or she needs to create an expert
library, a technology library, and a concept library to quickly react to all kinds of
requirements (Fig. 2.5). This is one of the most critical elements.
Fig. 2.5 Knowledge libraries

2.4 Preparation 15
If a system architect is new in the role or enters a new company, the first and most
crucial steps are to talk to people, search through the intranet, find presentation
slides of previous products, find all of this information, and create a knowledge
base. He or she must talk to suppliers and to the purchasing department to determine
whether all loops are closed there; find the written or unwritten technical strategies
that exist; and find the platforms or at least the things that are good enough to reuse.
In my whole career, I have only seen one person who followed those steps. He
came new into the company and immediately started looking through all of the
information channels that he could find. In a very short time, he was up to speed and
at the same level as I was with my 10 years of experience in the company. He had
even newer contacts and more insight than me in some cases. Perhaps also benefi-
cial in this case was that having no history in the company, he was very neutral
about all of the technologies and solutions he found. He had no passion or emotions
about anything. When we received a major RFQ not long after, he was able to jump
into it and worked on it as main system architect with no more ramp-up time neces-
sary. He received much credit afterward about his approach.
If such a network is available, it will be easy for the system architect to spread
requirements, obtain answers, and get critical topics addressed.
2.4.1.6 Supplier Management
In addition, the system architect needs to know what is available on the market. He
or she keeps track of this using individual roadmaps of the relevant suppliers, gen-
erating benchmarking data, or triggering it in the company. To his or her own ben-
efit, the system architect makes sure that the procurement department is up to date
and that all contacts are still valid. He or she makes sure that second sources are
available where appropriate. Competition between suppliers is most often benefi-
cial, and of course it is a matter of risk mitigation to not only rely on single sources.
If the market is well-known and the supplier contacts are maintained, the system
architect can easily evaluate customer requirements with the help of suppliers. At
least for choosing hardware parts, a good network of suppliers is essential, and
third-party6 technologies might also be necessary in a product. It might be necessary
to forward requirements directly to suppliers with the approval of the customer. In
other cases, the customer might dictate the use of certain suppliers, which must also
be considered.
Having all of that information at hand enables the system architect to evaluate
requirements and especially to have enough data for make, buy, or reuse decisions.
6
Third-party is a phrase often used if technologies of subsuppliers need to be integrated into a
product and come with special contractual consequences. First party of the contract is the cus-
tomer, second party is the main supplier.
2.4.1.7 Requirements Management
Requirements management is an art in itself. It starts with the selection of the right
tools for capturing requirements. Those tools could be dictated by customers if they
deliver in certain formats, or they should be chosen wisely from internal tools
departments. It makes sense of course that the company decides on one tool and
then all projects align with that. Whatever format customers deliver then needs to be
converted into the internal standard. The possibilities vary from simple Excel lists
with statistical charts up to comprehensive tools such as those from IBM that cap-
ture requirements, dependencies, and architecture, as I mention later in the tools
chapter. They usually provide full traceability from requirements to test cases to
achieve certain levels of process excellence.
The management of requirements means creating an aligned understanding
between the customer and one’s company about what is expected to be delivered. If
customers create thousands of requirements for one product, one must make sure
that one has captured, understood, and answered all of them because most often
they are then a part of a binding quote for delivering all those details. To manage
this, clear processes for capturing, documenting, discussing, reviewing, aligning,
and answering these requirements make sense. The documentation needs to be
updated until the implementation is complete and can be tested against the require-
ments in the final product.
If you type “Requirements Engineering” into an Internet search engine, you will
probably find a nice series of pictures showing a swing on a tree. This is a funny
version of what is sometimes happening in real life if requirements engineering
goes wrong.7
The system architect plays a central role because he or she is responsible for the
content of the technical requirements. He or she needs to ensure that the architec-
tural part is understood and that all consequences are transparent. In summary, the
system architect must ensure the following:
• That requirements from the customer are captured and documented
• That internal or other stakeholder requirements that are relevant for the particular
project are well-known and written down
• That every single requirement is reviewed, discussed, answered, and understood
from all parties
• That architectural gaps or inconsistencies are pointed out and discussed inter-
nally and with the customer to reach a solution
The system architect is probably not doing all of this himself and is probably not
responsible for the fact that all of it is happening. However, it is in his or her best
interests that a good requirements engineer is on the team who cares about it all.
Usually the job of a requirements engineer varies between two different areas.
The requirements engineer could be responsible for tools and manages the
7
https://de.wikipedia.org/wiki/Tree_swing_cartoon
2.4 Preparation 17
Table 2.1 Requirements table
conversion from customer format to the internal tool. Perhaps he or she also creates
statistics but is rather a tools and database expert. Alternatively, he or she could be
someone who answers and translates the requirements into internal technical speci-
fications and is also a technical expert. This depends on the project complexity and
internal team setup philosophy. I would not say that one or the other is right or wrong.
In an RFQ phase in the automotive industry, one must be fast. Processes, tools,
and people need to be in place immediately. The process described later in the tim-
ing chapter will help in understanding roles and responsibilities.
Let’s assume that you receive a couple of pdf8 documents from a customer with
a request for quotation. Your internal tool standard is Excel. Thus, the requirements
engineer immediately converts everything into Excel lists and adds the additional
fields to work on every single line item. You might have something that looks simi-
lar to Table 2.1:
You can see an identifier (ID) to quickly search, track, and reference require-
ments. You also see a text description and maybe also a title of the requirement.
Maybe you also have an expert domain class to more effectively sort the document.
The most important thing is to have an offer state. Here, it makes sense to differenti-
ate between the following four states:
8
pdf means portable document format. Were you aware of that?
• Offered – No further explanation is necessary other than whether it is available

in the platform or needs to be developed. Thus, the development effort is interest-
ing, but that information should not be delivered to the customer.
• Not offered – This state of course requires explanation. You might want to have
different columns in your document for internal explanations and also a more
detailed answer to the customer for why this is not offered.
• Offered under restrictions – This state also needs an explanation, that is, of what
the restrictions are and why you are not able to deliver according to the full
requirement.
• Offered under assumptions – This also needs an explanation. You might assume
facts and dependencies in the system that are not explicitly written down or men-
tioned. Make sure that these assumptions are clear and part of the answer to the
customer. Avoid getting into a situation where these assumptions make your
whole quote weak.
This is independent of what industry one is working in. Maybe you are develop-
ing electronics not for B2B9 customers but for end users (B2C10). Either way,
requirements need to be written down, and a system architect needs to evaluate what
can be achieved under certain circumstances and what cannot be achieved.
Using cake diagrams, one can easily present the percentage of each of the above-
mentioned states (Fig. 2.6). Of course, all of this is the job of the requirements
engineer, but the system architect also needs to have an eye on it. He or she needs to
make sure that all of the restrictions and assumptions are known.
Fig. 2.6 Requirements statistics
9
B2B – business to business means in this case to develop a product that someone else is using and
selling to end users. A navigation system from a supplier is an example.
10
B2C – business to consumer means producing something directly for the end user. A Bluetooth
speaker might be a good example.
2.4 Preparation 19
During a time-critical process like an RFQ, one might want to track the work
progress of all contributing departments and experts, so creating statistics out of the
requirements document makes a great deal of sense – not only for the offer state but
also for the work progress. You might want to divide the work between different
expert domains and track the number of requirements for them. With statistics you
can easily track if they have started the work or if the appropriate fields are already
filled in and the line item is closed. Having a single contact person and the right
escalation paths provides an instrument for tracking work progress and triggering
the contact person, including escalation if nothing happens.
In Fig. 2.7, five different expert domains are presented along with their number
of requirements, including the work progress status. Such a chart could be sent
around every day to the relevant internal stakeholders to track the progress of the
overall RFQ.
The elicitation and evaluation of requirements must be completed before the
system architect can create and announce the architecture baseline. Therefore, it is
again in his or her own interest to ensure that all requirements are processed. The
architecture design usually goes in several iterations but must eventually be fixed.
The baseline goes back to development departments for them to estimate their work;
then, it goes to the purchasing department for them to calculate prices for hardware
and licenses; and finally, it goes to manufacturing to estimate costs for production.
With all of this information, the salespeople can create their business case.
Fig. 2.7 Requirements tracking

These examples are performed with simple Excel files. As mentioned above,
much more sophisticated tools are available. For projects with a low complexity and
teams that are not too globally distributed, this tool set might be sufficient.11
One more important aspect of requirements management is of course having
something written down between the customer and supplier to agree on. Usually the
customer has his or her own phrases and language for describing the systems, tech-
nology, and behavior of his product. Furthermore, the supplier has his or her own
language for the same content, which might be different. During the requirements
elicitation process, it is critical to identify these differences and find a common
language for description – only then is it possible to agree on a certain development
content in detail. One result of the requirements management process is a binding
description. It is in the interest of both parties to make sure that everything is cov-
ered and well-understood. If there is still room for interpretation, some bad sur-
prises might happen after 2 or 3 years of development.
Here, it is of course also possible to create a pleasant process with inputs, out-
puts, reviews, gates, work products, and so on. It depends on the industry, who one’s
customer is, and how much effort one wishes to invest into the verification manage-
ment of requirements.
2.4.2 Team Structure
Next, a team is required to work on the architecture. The more complex the system,
the more domain specialists that are required. This means that specialists for certain
technical domains, such as hardware, software, bus systems, mechanics, security,
connectivity, user interface, and environment, are required. Moreover, a main sys-
tem architect is required, who takes the lead in all activities, moderates the team of
specialists, and drives the whole thing. Because complex electronic systems in most
cases have software running on a piece of hardware and the whole thing comes in a
housing, hardware, software, and mechanics should be considered as the core team.
An example of a good organization chart is provided in Fig. 2.8 as follows:
For small systems, it might be enough to have only one system architect and no
team. Usually, at least a core team of hardware, software, and mechanics architects
is necessary.
Another common practice is to have a requirements engineer in place who man-
ages customer and internal requirements, translates them into internal terms, and
maintains the relevant processes and tools. Thus, the system architect can cluster the
topics and assign them to the architects and specialists according to their roles.
To complete the team, someone as a customer interface is necessary. Other
important members are a project lead, someone to control the budget, someone from
11
In the future, you can find further information and Excel sheet examples on my web page www.
system-architecture-design.com. Feel free to download everything you want and use it. The pass-
word will be system123.
2.4 Preparation 21
Fig. 2.8 Architecture organization chart
the purchasing department, someone to conduct testing and validation, and some-
one from manufacturing.
The person who sets up the team must make sure that he or she has the commit-
ment of all team members for the time that they are needed. Table 2.2 presents an
example of a team availability table that can help to document those commitments.
The table shows the members’ different functions, which region they are from,
and when they are available.
Overall, it makes sense to write down roles and responsibilities in a RASIC chart
or similar. Doing so can avoid most misunderstandings for the team working
together. The meaning of RASIC is explained as follows:
• R – Responsible: This person is responsible for a task; he or she is leading the
activity and makes sure the task will be finished.
• A – Approval: This person approves the results of a task or rejects them.
• S – Support: This person works actively on the task under the leadership of the
responsible person R.
• I – Information: This person is informed about the progress and results of the task.
• C – Consultancy: This person offers guidance or advice and does not actively
work on the task.
Table 2.3 presents a typical RASIC chart that shows all information on one page:
Here, one can see all relevant roles of the project, the names of the persons
responsible for fulfilling the role, and who has which function in terms of the RASIC
differentiation. It makes sense to employ color coding. In the table above, I have
colored the responsible person as an example.
Table 2.2 Team availability table
Table 2.3 RASIC chart
2.4.2.1 Skills and Roles
A system architect with the ideal skill set is not easy to find. This is someone who
has knowledge and experience at least in hardware and software details. Usually,
he or she also needs to be an effective moderator and project lead to guide the team
and get things done in the organization. Experience in leading task forces defi-
nitely helps to run time-critical activities like preparing results in an RFQ phase.
Last but not least, the system architect requires good presentation skills. He or she
might be the main person presenting the overall architecture internally and to
customers.
Most of the time, several departments contribute to such a system architecture
design process and all have different perspectives, priorities, and strategic interests.
And, as we all know, there is never enough time. The system architect is somehow
in the middle of all this and needs to handle it. To summarize, the ideal system
architect is a hardware architect, a software architect, and an experienced task
force leader.
2.4 Preparation 23
An effective strategy inside the company is to train employees with a special

program to become system architects. Hardware architects could be trained and
rotated through software development departments or vice versa. The best system
architects I have seen have a DSP developer background. Maybe it comes from the
special role that DSP development has in an embedded world. The DSPs are usually
small enough that one developer can have one customer project on his or her own.
Thus, he or she needs to deal with DSP application software as well as drivers,
hardware interfaces, and protocols to other processors. DSP developers also usually
need to deal with the digital hardware design. For debugging, it helps to always
work with an oscilloscope and to measure TDM12 signals or similar interfaces.
Therefore, DSP developers usually possess good system know-how and an under-
standing of hardware and software.
The roles and tasks of the system architect might be as follows:
• Defining and designing system architectures
• Leading the system architecture team
• Supporting requirements analysis
• Performing system analysis and concept creation
• Conducting technical coordination of detailed software and hardware
architectures
• Performing performance analysis and handling system resources
• Moderating the system architecture design process
• Creating and maintaining knowledge bases
• Supporting supplier management
• Presenting in front of developers, management, and customers
• Being responsible for the final architecture
The skillset for domain specialists must be as good as possible. They are the ones
who contribute all of the necessary details to the system architecture and bring their
input to the round table, which is moderated by the system architect.
2.4.2.2 Communication and Tools
Communication is key in these complex development environments. Ideally all

team members would sit in one place in the same location, but today this is becom-
ing increasingly unrealistic. Therefore, the communication rules and guidelines
should be clarified upfront as much as possible. A process or RASIC chart greatly
12
TDM means time division multiplex, an electronic data format transporting several audio data
channels from one processor to the other using three physical connections.
helps in defining roles and responsibilities and also in identifying interfaces between
different work packages or departments.
Numerous tools are available for documenting requirements, designs, decisions,
and processes among other things. This can be handled using simple Excel sheets,
Word documents, or Visio drawings, or a fully integrated solution could be employed
such as Rational Rhapsody Architect from IBM. All tools have different flavors,
advantages, and disadvantages. For example, I personally always preferred Visio
because of the full graphical flexibility it provides. The drawings in integrated solu-
tions are too technical to use for presentations to customers. On the other hand,
using Excel, Word, and Visio makes it hard to ensure the automated traceability of
requirements, features, and test results to fulfill the V model accurately. Furthermore,
they have no automated code generation at all, which might be useful and is avail-
able with the integrated solutions. One would need to program macros in Visual
Basic to ensure some automation, or one would need another tool such as DOORS
from IBM on top of that.
Basically, tools need to fulfill company standards in terms of design quality,
traceability, usability, and costs. Due to the fact that several departments are involved
in a V model development, the tools need to support collaborative work on a global
scale. In an automotive environment, process evaluations such as Automotive
SPICE13 are established to support the definition and tracking of the project. I return
to Automotive SPICE and more processes in a later chapter.
The communication, of course, mainly occurs in meetings and through emails
and documentation. In time-critical situations, meetings can occur on a daily basis
to update all team members about the latest progress. They could be 15-minute
meetings such as daily stand-ups in an agile development, or they could be more
intensive. I have seen situations where several experts were locked in a so-called
war room for several days to work out the full architecture of a system during the
RFQ phase.
Weekly meetings are necessary for updating and discussing regularly on a more
general basis. Special workshops are held to discuss and solve special topics inter-
nally or with customers and suppliers.
It is vital to document meetings, decisions, results, sign-offs, and all kinds of
information that is useful for the system architecture. In particular, to guarantee the
traceability of requirements, an effective documentation process is essential. To
ensure quality, all concepts and decisions should be reviewed with relevant experts
based on predefined checklists. Tools such as Confluence and Jira can be configured
and used for this.
Open issue lists are a perfect tool for tracking all open topics. Many such lists
will be used during the design phase of a system. A list is created with entries for
13
Automotive Spice is a standard to evaluate and improve capabilities and performance of automo-
tive development processes for electronic systems in the car. Spice means Software Process
Improvement and Capabilities Determination.
2.4 Preparation 25
Table 2.4 List of open issues
problem, requestor, responsible person, entry date, due date, and so on. Automation
or statistics in Excel helps again to have a full overview of the status and work in
progress instantly. Table 2.4 presents a to-do list example of individual topics:
This list can be easily sorted by topic or task name. The priority calculation is a
multiplication of importance and urgency. The two values could range, for example,
from one to three. In the notes/updates field, one can enter what happens every week
as well as the current status.
Another important topic to clarify during the whole process of system architec-
ture design is the definition of escalation paths in the company. The system architect
needs to know whom to talk with and if critical topics appear that he or she cannot
solve on his own, either because they have an underestimated cost impact, because
expert teams are missing, or because the development effort was underestimated. In
any case, it is crucial to create transparency and to promptly deliver the information
to the persons responsible for the project.
While the system architect must have an overview of all technical aspects during
the system design process, a project manager ensures that all departments work
together with the right timing.
2.4.3 Product Life Cycle
Timing is always critical, and it is always worth looking into process optimizations
to be better prepared when a new system design is required. Now, we get to the
interesting points in terms of platform development. Let’s assume that you have
developed the majority of components already, while a customer is asking for a
next-generation product. One would save a tremendous amount of time by just
offering what one already has. The key here is a proper platform development that
consists of key components and reference systems at the same time. We will return
to this later.
In the following sections, I examine different phases of product development for

a B2B scenario where a company wishes to develop parts to be delivered for another
company’s final product. Of course, the same phases are valid for B2C scenarios
with slightly different roles. What is a customer in a B2B scenario might be a strat-
egy or product management department in a B2C scenario. Someone is the requestor
of a new product – whether that is an external customer or internal strategy depart-
ment does not matter too much for the product life cycle.
2.4.3.1 Predevelopment
The path to the CEO’s office should not be through the CFO’s office,
and it should not be through the marketing department.
It needs to be through engineering and design.
– Elon Musk
CEO and Co-Founder Tesla Inc.
A company that sells electronic products might want to stay competitive, create
innovations, and steer the market in strategic directions that are beneficial to the
company. Thus, the company would want to spend some money on technology
development, or what is commonly known as Research & Development (R&D).
Typical is that approximately 10–15% of one’s revenue should go into this kind of
predevelopment.14 If the technical strategy is right, the company may convince its
customers to use its latest and greatest technologies for their next generation of
products, or the company might have something in its portfolio already that fits their
newest requirements. Having a proper process in place to generate the right deci-
sions about what to develop and what not to is absolutely key. It could not be more
beneficial in terms of time to market to have something already done before others
even start thinking about it. The definition of “done” depends on the strategy in
detail. It might make sense to have prototypes ready to demonstrate feasibility and
to make people aware of this technology but to wait with the final investment until
a customer actually orders. In general, the pure amount of R&D spending says noth-
ing. The crucial matter is how to spend the money and how to have a proper innova-
tion process in place that guides through inventions, customer value, and
business models.
For the system architect, it is important that he or she knows all of these activities
and can access all of the details during the system design process. Therefore, he
From www.fdiintelligence.com, numbers from 2020: Alphabet 15.1%, Huawei 15.9%, Microsoft
14
13.5%, Amazon 11%, Apple 7.1%, and Samsung 9%.

2.4 Preparation 27
might want to integrate a technology and need to find system resource requirements
immediately. Furthermore, he or she might need to know what risk is behind the fact
that, for example, only a prototype is available right now. Moreover, he or she needs
to know the roadmap of innovations in the company – perhaps a technology will be
available later that fits the overall project timing.
The platform development part of the whole story is an additional strategy for
performing predevelopment according to internal standards and integrated into
well-defined software frameworks. With that strategy, it is guaranteed that even if
the technology is not fully finalized and validated, it would run in a reference envi-
ronment already.
2.4.3.2 RFI and RFQ
In the automotive industry, car manufacturers usually approach suppliers by request-

ing information before they design the next product. Later, they request a quotation
when they have a clear picture, and all of the thousands of requirements are created
and given to suppliers.
With effective customer management, a company would not be too surprised
when such a request for information (RFI) comes in. Maybe even parts of its tech-
nologies are already described in the request because its predevelopment activities
are so strong and clearly communicated to the outside world that the customer
urgently wants to have them in their next product. The RFI could also be a total
surprise and the company might not have too much in its portfolio for it already.
Basically, the same is also valid for the later RFQ.
The RFI and RFQ phases in the automotive industry are, in my experience,
always time-critical. Therefore, it is worth investing effort into creating a proper
process for how to handle RFIs and RFQs. The following diagram (Fig. 2.9) pres-
ents an example of how an RFQ could be handled. The main focus here is on system
architecture, but the diagram also shows other departments involved in the RFQ
process.
In the figure, it can be seen that the request comes in through the customer inter-
face. This department immediately assigns a project manager to drive the request
process, who sets up a team. The requirements documents are handed over to the
requirements engineer who can scan through them and decide which departments or
experts need to be involved. He or she also hands over immediately to the system
architect who looks through them from a technical point of view and decides which
technical experts are necessary. For example, he or she might want to integrate a
special department if a cloud connection needs to be integrated into the product and
the requirements are so special that experts on the topic are necessary. The require-
ments engineer ensures the requirements process, and the system architect designs
an initial system architecture together with the team of experts. The expert
Fig. 2.9 RFQ process diagram
departments evaluate the detailed requirements and report back to the system archi-
tecture team. Thus, they can evaluate every dependency between hardware, soft-
ware, mechanics, components, and technologies. This is an iterative process that
leads to a final system architecture baseline that is used for all kinds of effort estima-
tions and price calculations.
Purchasing departments are involved to manage supplier prices, while sales
departments are involved to create prices for the final product.
2.4 Preparation 29
The system architecture is always the core element of the whole offering to a
customer. If the architecture is clearly understood from the beginning, then the proj-
ect can be calculated and major surprises in later development phases can be
avoided.
2.4.3.3 Product Development
One day, the RFQ phase ends and the customer program is hopefully awarded. In a
B2C environment, this would be the product definition and system architec-
ture phase.
Now, it is important to have a system architecture baseline to be very clear about
changes. These might be necessary changes during the development because of
customer requests or based on internal observations and needs. For both changes,
clear documentation is necessary to track costs and check them against the busi-
ness case.
Usually after the award, the detailed work of hardware and software architecture
starts. The system architect moderates this activity and makes sure that the system
requirements and boundary conditions are met. He or she conducts, for example,
weekly meetings with a core team to work on open topics. Furthermore, he or she
invites domain specialists to work out the architecture for their subdomain in the
context of the whole system.
The system architect is also the main contact person for the customer if they wish
to discuss specific architecture topics and issues. He or she also invites people to
workshops and moderates them together with the project manager. He or she knows
about project milestones and sample phases to align with his or her work products.
In terms of traceability, it is highly valuable to work with tools that allow the
tracing of requirements into architectural elements and later into actual implementa-
tions and final tests.
The concepts and architectures from the system architecture core team are passed
to the developer teams for implementation. They develop the system until it goes
into validation and finally into production.
2.4.3.4 Maintenance Phase
After the start of production, the system architecture team usually has nothing more
to do. They can double check if all relevant concepts are documented and up to date
so that they can potentially be reused in future projects. It might happen that critical
bugs arise in the field and the system architect needs to provide support, but usually
the whole architecture team can focus on the next project.
It makes sense to conduct a lessons-learned session to talk openly about the
whole project execution and see what could be optimized in the next project.
Especially in the automotive industry, it might occur that customers ask for a face
lift design after a certain time. This could require more or less effort and is also a
question of the effective preparation of this step.
I have seen face lifts that were completely new systems with new hardware and
software requested. However, it can of course also be smaller incremental steps on
the hardware or software side.
2.4.3.5 Product Retirement
Here, there is also not much to do anymore for the system architect. The production
of the whole system has stopped – nothing more will be sold to the customer. The
only thing that is relevant now is to store old parts to be able to repair devices even
after many years. How many years depends on the customer, but imagine having a
15-year-old car and the navigation system needs to be repaired. In this case, the car
manufacturer usually asks for several years of maintenance.
The following diagram (Fig. 2.10) summarizes the project development phases
and presents the main points for the system architect to consider.
2.4.4 Effort Estimation
The first 90 percent of the code accounts for the first 90 percent of the development
time. The remaining 10 percent of the code accounts for the other 90 percent
of the development time.
– Tom Cargill
Bell Labs
In conventional quotation processes in the automotive industry, customers expect a

concrete price for the product they are asking for. In the case of the aforementioned
thousands of requirements, the company will need to calculate the complete devel-
opment costs for the product to come up with a proper price and business case.
Thus, the development effort must be estimated, which is a crucial point that can
make quite some difference. I want to mention some general ideas here.
One of the main work products that needs to be generated in RFQ phases is an
effort estimation for every single development effort that would happen after the
award. Therefore, the overall system architecture needs to be fixed and the system
architect defines a baseline. This baseline is given to all relevant development
departments to estimate their development effort. With these numbers, finance
2.4 Preparation 31
Fig. 2.10 All product phases
department can calculate the business case and balance effort against revenue. The
more accurate the effort estimation, the more reliable the business case
calculation.
In a more agile development world and with a trustful relationship between cus-
tomer and supplier, it would be possible to agree on a fixed number of engineers per
time to develop as much as possible in that time frame. The requirements play a
similar role here. The customer still has roughly a clear picture about what he or she
wants to have, but effort estimation can be slightly more relaxed or at least not lead-
ing to such a fundamental financial risk. More details about agile development are
provided at the end of this book.
Effort estimation is also an art in itself. Because this effort results in pure costs
for the final product, it is definitely worth investing in a proper process that is opti-
mized continuously.
Several relevant concepts and tools exist. I personally have good experience with
the following:
• Capturing development efforts of running and previous product developments as
detailed as possible and using them for comparisons with new products (histori-
cal information).
• Defining and capturing the complexity levels of components and products as
further estimation input for discussions.
• Breaking down the system architecture into small pieces that can be the baseline
for a work breakdown structure. Doing so provides a good overview of develop-
ment tasks and can be used for bottom-up planning.
• Letting the experts estimate MIN and MAX values for development efforts and
allowing them to discuss and refine those values in a group, or at least letting
several people estimate the same development tasks and compare and take the
mean value or discuss differences.
• Estimating dedicated man-weeks etc., which can be possible if the team has
enough experience and historical data or if the development task is easy to esti-
mate. In more complex situations, it might be better to use agile methods such as
T-shirt sizes and planning poker (please find more explanation in the agile devel-
opment chapter at the end of the book).
• Comparing with previous products and generating a top-down estimation and
then comparing this with one’s bottom-up approach and discussing the differ-
ences. In the best case, the numbers are the same. In the worst case, it leads to
several discussions, but either way this is good because the number will be better
understood and refined afterward.
The effort required to perform this type of estimation depends on the level of
detail one can achieve in the system architecture. If time is short, the level of detail
is set accordingly.
It is obvious that a strong platform reduces the development effort. One can reuse
from the platform as much as possible, identifying the differences, adaptations, and
configurations and creating an effort estimation based on them.
If the project is awarded, effort estimation is hopefully performed and the devel-
opment departments should ensure that they stick to their plans. All changes or
unexpected occurrences from an architecture point of view must be tracked by the
system architect and his or her team. He or she can make sure that changes are com-
municated and a new effort estimation is generated. This needs to go to the business
department so that they can evaluate what cost impact the change will have and
react accordingly.
2.4 Preparation 33
2.4.5 Project Management
Project management is a huge topic and not really within the scope of this book.
However, what I wish to mention here is a special project management setup that
might make sense to use for RFQ phases in the automotive industry.
2.4.6 Task Force
The task force is useful for answering an RFQ in time as well as for improving
projects that are in bad shape. Every project, subproject, or subtask could be han-
dled with a task force if necessary.
A task force is an interim solution for fixing a certain problem in the shortest
possible time. It groups the best available people together independent of line man-
agement, running projects, or other organizational restrictions. Thus, the most
important element and the main difference from regular project management is the
team setup. The organization must ensure that the other running activities can be
stalled or critical positions can be backfilled to free up the necessary experts for the
task force.
The task force management itself is not very different from regular project man-
agement. To prepare, one needs the following:
• Analysis of the current situation, target definition, and risk analysis
• High-level planning, project setup, and detailed planning
• Contract and kick-off
The project setup is the special part here. One should create the ideal team, draw
an org chart, and create a table of availabilities (presented in Table 2.2 in the team
structure section). Here, the most important thing is to obtain buy-in from experts
and line managers for people and time.
After kick-off in the execution phase, one would want to make sure of the
following:
• Refinement of detailed planning
• Assignment of tasks and tracking of progress
• Project control
• Risk management
• Documentation, communication, and reporting
In particular, risk management requires special attention. A task force is usually
necessary because certain things in the project can go completely wrong. One
should determine the root cause and try to avoid stepping into the same trap. This
might concern cost, time, or quality as always in project management. Much can go
wrong in effort estimations, and effort estimations can go wrong if the scope or the
architecture is unclear. And here we are: The fundament is always the system archi-
tecture. Therefore, let us add this part very clearly into the project management of a
task force for developing electronic systems as follows:
Preparation phase:
• Analysis of the current situation, target definition, and risk analysis
• Recapturing of requirements management
• High-level design of system architecture
• High-level planning, project setup, and detailed planning
• Contract and kick-off
Execution phase:
• Refinement of detailed planning
• Assignment of tasks and tracking of progress
• Project control, detailed design of system architecture, and continuous refinement
• Risk management
• Documentation, communication, and reporting
The contract defines what is necessary for completing the task force activity. One
must make sure that this is measurable and clearly defined so that it does not become
a never-ending story. After the execution phase, one steps into the closing phase:
• Final report and system architecture specification
• Transition plan
• Final inspection and acceptance according to the contract
• Handover
These three phases are a summarized approach for describing project planning.
In the literature, you will usually find four or five phases of project management,
such as initiation, planning, execution, monitoring, and closure.
In my career, I have seen all kinds of task forces. Some have been really success-
ful and an RFQ phase, for example, was excellently managed. Others have not been
clearly defined or supported and ended up as never-ending stories. The problem
then is that management expectations are not fulfilled and engineers become frus-
trated. The task force might fix something in the short term, but it does not help in
the long term.
2.4.7 Processes
System architecture design has much to do with processes. Depending on the indus-
try, one must be compliant with several standards, such as Automotive SPICE in the
automotive industry. Fulfilling certain processes is sometimes a non-negotiable
requirement from customers or even governments. In the following subsections, I
sketch some processes to provide an overview.
2.4 Preparation 35
2.4.7.1 Systems Engineering ISO/IEC 15288
The ISO organization was founded in the 1940s. It globally creates and promotes
standards for proprietary, industrial, and commercial topics. ISO stands for the
Greek word isos, which means equal.
IEC stands for the International Electrotechnical Commission. This organization
is 40 years older than ISO and focuses on electrotechnical topics. ISO and IEC work
closely together for some standards. The ISO/IEC 15288 has its roots in military
standards from the 1970s and was first issued in 2002 with updates thus far until
2015. It defines processes defined by purpose, activity, and outcome and is divided
into the four parts of technical, project, agreement, and enterprise. The main goal is
to describe the life cycle of a system from end to end.
The agreement part defines processes for the acquisition and supply of systems;
the enterprise part covers processes for resource management and infrastructure; the
project part is all about project management; and finally, the technical part is what
we focus on here, namely, the development of a system starting with requirements
and ending with the retirement of a product.
2.4.7.2 CMMI
CMMI stands for Capability Maturity Model Integration. This is not a standard but
rather a tool for assessing and approving the content and quality of processes in an
organization. It comes with a set of best practices, and after the evaluation of pro-
cesses, it is possible to rate the maturity and capability based on different levels.
The capability levels are divided into incomplete, performed, managed, and
defined, while the maturity levels consist of initial, managed, defined, quantitatively
managed, and optimized.
Automotive SPICE is another nice example of such an assessment tool, which
we do in more detail in the next section.
2.4.7.3 Automotive SPICE
As mentioned above, SPICE is an international standard for evaluating the pro-

cesses of companies. It is based on ISO/IEC 15504, which describes a process
assessment model. Automotive SPICE is a special derivate for the automotive
industry. The domain system architecture design is part of the engineering pro-
cesses, so we want to focus only on those. Management, supply, acquisitions, and
all other domains are not described here.
In my view, this process evaluation is defined very clearly and is also applicable
for other industries and electronics development in general. For this reason, I want
Fig. 2.11 Automotive SPICE groups. (Copy from [5])
to go into more detail. The following diagram in Fig. 2.11 displays all of the topics
covered by Automotive SPICE.
As the diagram shows, the engineering processes are divided into 11 differ-
ent topics:
• SYS.1: Requirements Elicitation
• SYS.2: System Requirements Analysis
• SYS.3: System Architectural Design
• SWE.1: Software Requirements Analysis
• SWE.2: Software Architectural Design
• SWE.3: Software Detailed Design and Unit Construction
• SWE.4: Software Unit Verification
• SWE.5: Software Integration and Integration Test
• SWE.6: Software Qualification Test
• SYS.4: System Integration and Integration Test
• SYS.5: System Qualification Test
Once SYS.1 is complete, the processes follow the V model exactly. That means
that every element on the left-hand side has a corresponding element on the right-
hand side. In practice, this means that every single system requirement has its cor-
responding qualification test, or that every software unit construction has its
corresponding unit verification. This is critical for traceability and consistency. The
process ensures that every single requirement can be traced in the system, in soft-
ware, and in all corresponding tests. Finally, agreement and communication are
2.4 Preparation 37
Fig. 2.12 Automotive SPICE: additional topics and plug-in concept
crucial. The SPICE best practices also ensure that decisions are reviewed, aligned,
and communicated.
What is missing here is an explicit mention of the hardware and mechanical
development processes, which can be handled by the so-called plug-in concept
(Fig. 2.12):
Here, I want to focus only on SYS.3: System Architectural Design. This is the
topic of this book and the main focus here. So let’s assume that SYS.1 has been
completed and the requirements elicitation is fully processed. This would mean that
communication with the customer or stakeholder is established, and that require-
ments are delivered, understood, and agreed on. A requirements baseline is created
and changes are managed. Documents showing communication, reviews, analysis,
changes, risk management, and mitigation and finally the requirements themselves
are available.
Let’s also assume that the second step SYS.2 is done and the system require-
ments are specified. This would mean that the requirements are defined, structured,
and analyzed; the impact is analyzed; and the verification criteria for system tests
are defined. Furthermore, traceability and consistency can be demonstrated, and
finally, all of that is communicated to all relevant departments. Here again, docu-
ments are available showing communication, reviews, changes, analysis, and trace-
ability. In addition, interface specification and system requirements specification
might be useful.
SYS.1 and SYS.2 are done with a clear outcome that shows the system require-
ments. This is the main input for the system architectural design in SYS.3.
The main parts of SYS.3 are process outcome, base practices, and work prod-
ucts. The outcomes are as follows:
• The system architecture design is defined, identifying every single element of
the system.
• All system requirements have a corresponding element of the system.
• The interfaces for each system element are defined.
• The dynamic behavior of each system element is defined.
• Consistency and traceability are given between system requirements and system
architecture design.
• The whole system architecture design is agreed and communicated to all relevant
departments and parties.
The base practices cover things such as the following:
• Requirements, development, interfaces, and dynamic behavior
• Evaluation of alternative solutions
• Traceability, consistency, and communication
The work products are as follows:
• The system architecture design
• Communication, review, and traceability records
• Interface requirements specification
All of that sounds very reasonable. If one wants to develop a system of high qual-
ity, all of the points above are more or less common sense. Now, the interesting part
of SPICE is the process assessment. How do you make sure that all of these points
are covered and determine the quality of your process?
Automotive SPICE differentiates between six levels of process quality:
• Level 0: Incomplete process.
–– No process is installed; no systematic approach is visible.
• Level 1: Performed process.
–– A process is installed, base practices are performed, and work products show
the results of these base practices and process outcomes. People are assigned
to work on the process.
• Level 2: Managed process.
–– The process itself is managed. This means that clear objectives for the process
are defined and it is planned and can be adjusted. People to work on it are
defined, assigned, and trained, and their roles are communicated. Interfaces to
2.4 Preparation 39
all relevant departments are defined. Finally, the work products are clearly
defined with requirements, documentation, reviews, and potential adjust-
ments if necessary.
• Level 3: Established process.
–– The process is standardized in the company, including process charts, guide-
lines, roles and responsibility descriptions, methods, and measure descrip-
tions. Tailoring is defined and written down. Resources are trained, assigned,
and available. Data are continuously collected to demonstrate the effective-
ness of the process and enable continuous improvement.
• Level 4: Predictable process.
–– The process operates predictively. Work products are achieved in defined lim-
its and are aligned with quantitative business goals.
• Level 5: Innovating process.
–– The process is now continuously improved, including innovative process
opportunities, which are identified and evaluated, and implementation strate-
gies are put in place.
Thus, SPICE is not so much about the actual content of one’s work. It does not
describe which types of diagrams are important and which are not. It purely
describes the process quality in place. Do you have a need for a diagram? Is it clear
to create? Is it written down and aligned that you need it? Is it established as a stan-
dard process? Did you make a connection with quantitative business goals? Finally,
are you continuously looking for innovative new ideas about diagrams and the like?
Those questions are slightly simplified but more or less cover the idea in one sen-
tence. For further details, please see the book Automotive SPICE in Practice from
Hoermann, Mueller, Dittmann, and Zimmer [6].
2.4.7.4 Medical Devices – ISO 13485
If we examine the medical devices industry, we will also find other processes and
regulations that must be followed by the system architect who develops such
devices. ISO 13485 is one of those requirements for the design, manufacturing, and
rollout of medical devices. It is the main ISO standard for achieving a proper quality
management system in the development of medical devices. Certifications usually
play a major role for medical devices.
The FDA15 is an example of an organization that creates processes and regula-

tions around medical devices produced in the United States. The FDA has a history
in regulations for drugs but is also the main administration for all kinds of electronic
medical devices.
Another example for the UK and EU market is the MHRA,16 which provides
guidance and registration for medical devices. ISO 13485 is the base for all of these
activities.
2.4.7.5 Functional Safety – IEC 61508
This standard is also interesting, covering aspects of functional safety in electronic

devices. Different implementations of the same international standard exist, for
example, for nuclear power plants, train technologies, the aviation industry, and –
especially interesting here – the automotive industry. The road vehicle implementa-
tion is the ISO 26262 standard.
In general, the safety topic is divided into different safety integrity levels (SILs).
For the automotive industry, the equivalent is Automotive SILs (ASILs). These lev-
els describe the likelihood of occurrence combined with the consequences, which
can be categorized into four SIL levels from catastrophic to negligible.
This standard creates additional effort for system architects. Requirements come
onto the agenda such as much stricter development processes, redundancies, and a
higher quality or lower failure rate of electronic parts. Imagine wanting to have a
much more rigid development process, failure detection, and risk mitigation for
nuclear power plants than for consumer electronic devices.
2.4.7.6 Military
Of course, the military industry has its own standards for creating electronic devices,
such as MIL STD in the United States and DEF Stan in the United Kingdom. The
military standards are sometimes the roots for ISO standards, such as the aforemen-
tioned ISO/IEC 15288.
But now, enough about processes. For the system architect, it is important to
know in which industry he or she is working and what type of processes and regula-
tions are available or necessary. They might be a good help and provide best prac-
tices, or they might be mandatory to follow, with certain certifications necessary for
finally rolling out electronic products to the market.
15
FDA – Food and Drug Administration in the United States.
16
MHRA – Medicines & Healthcare products Regulatory Agency in the United Kingdom.
2.5 Execution 41
2.5 Execution
If you think good architecture is expensive, try bad architecture.

– Brian Foote & Joseph Yoder
Computer Scientists
from their article about the “Big Ball of Mud” from 1999
2.5.1 System Architecture
Now that we have covered all of the preparation topics, let’s look into the details of
the system architecture design process. Be aware that this is a process that usually
goes through several iterations. One will go in circles, and it is important for the
system architect to decide certain things based on all of the relevant facts and ana-
lyze the risk coming from all unknown parts.
The following diagram (Fig. 2.13) presents the general work flow that is usually
necessary for designing a complex electronic system:
The figure shows that it all starts with requirements analysis. With the knowledge
about previous projects or platform content or technologies, one can create or select
a concept. Together with the system requirements, one creates the system definition.
Fig. 2.13 System architecture work flow

If that is created, one would wish to conduct a performance analysis and see if the
bits and pieces are capable of fulfilling the requirements. This is already the first
loop that can occur. If the system performance is not good enough, iterations must
be gone through until it fits. In parallel, experts start to analyze or create the require-
ments for various subsystems. Furthermore, system definition and performance
analysis are performed for the subsystems. Out of both activities, an impact might
occur on the overall system again, which would create further system requirements
and you are back to zero with the bigger loop closed.
While the concept selection results in an evolution of concepts and platforms, the
system definition results in the system synthesis or system architecture of the proj-
ect under investigation. To reach concept selection and system definition, I have
usually used two different views to start discussing the concept, calling them out-
side in and inside out.
2.5.1.1 Outside In
This is the view from the outside of the device that one wishes to design. Let’s
return to the example of the house. Imagine that you are standing in front of the
house, viewing it from the outside. What does the ground look like? What is the
color? What are the dimensions? Are there any fancy architectural elements such as
balconies? How do water and power come in and go out? What are the weather
conditions in the area?
In electronic systems, one mainly deals with dimensions, interfaces to other
components such as connectors and antennas, and requirements coming from the
environment. For example, temperature is a critical point for the automotive indus-
try. With this view, one views the device as a black box and can draw a topology
diagram, which might look like the example in Fig. 2.14:
The device in the middle is the product to be designed. All other components
around it are not in the scope of the quote or the development, yet they are important
to know to design the interfaces properly. Thus, one needs to know what the inter-
faces for those outside components are, what data are going through them, what the
timing is, and what bandwidth is necessary. Which software components are needed
to enable these interfaces and what drivers are required to support them? Which
protocols are necessary? Other requirements probably exist for the system dimen-
sions, temperature range, and quality among others.
2.5.1.2 Inside Out
This is the view from inside the product. One may receive requirements about dif-
ferent features that need to be realized with the product. Perhaps a navigation appli-
cation needs to run on it, a face-tracking algorithm needs to be calculated, or a voice
assistant needs to run offline and also online connected to a cloud service. All of
2.5 Execution 43
Fig. 2.14 System topology diagram
these features at least require resources such as CPU power and memory. Some
other features might require bandwidth on bus interfaces or the calculation power of
the graphical processing unit. Adding up all of these features and creating use cases
provides a clear picture of how many of these system resources are needed – either
in parallel or not. This information is essential for the system architecture to make a
decision on the requirements of needed system resources such as CPU power, mem-
ory size, and the bandwidth of several busses (Table 2.5).
Returning to the example of the house, the inside-out view depends on the
requirements of the different rooms as well as the architecture and construction of
walls and other concrete things. One might require certain space for certain rooms
assuming a certain number of people living in the house. Some standard require-
ments such as a kitchen, a bathroom, and a living room might always be there with
certain dimensions and water connections. One must plan and install heating, water,
and electric installation as system components as well as ensure that the heating
system, for example, has enough power to heat the whole house.
Returning to our electronic devices, we want to know what kind of industry stan-
dards need to be fulfilled to create the product. Do they affect the system architec-
ture? Does the customer expect certain buffers and boundaries on the system
resources that need to be considered? Some customers, for example, specify a free
Table 2.5 Features and their resource needs
buffer of 30% on the CPU resources for the final product to be able to integrate
future updates, which must of course be considered in the system architecture.
As a system architect, one should write down all of these features with as much
information as possible. This could be CPU/GPU consumption, memory space, bus
bandwidth, DMA17 resources, and use cases.
2.5.1.3 Hierarchy
Another view of the system shows the hierarchies of elements. Let’s divide the sys-
tem into subsystems, components, and units to break it down into the smallest rel-
evant part. Remember the refrigerator in the example of the house. What is the
smallest relevant part in your system?
The figure (Fig. 2.15) depicts a system that consists of three subsystems. The
subsystems consist of one or two components, and so on.
2.5.1.4 Cross-Project Comparison
With an overview of the system, as described above, it is time to look left and right
and determine whether similar products have already been developed in the com-
pany. It is essential for the system architect to have a knowledge base of previous
projects or activities that are ongoing. He or she should create and maintain this
database of projects to always have the relevant information at hand. One should
take out the cross-project comparison table and scan through it, searching for
17
DMA means Direct Memory Access and is usually realized with a special controller in proces-
sors to move data independent from the CPU from point A to point B.
2.5 Execution 45
Fig. 2.15 Hierarchy of elements
available technologies, similarities, and concepts that could be used in the current
design. It is also important to report this information back to the CTO,18 since it is
highly valuable information for creating a technical strategy for the company and a
layout of the platform approach. He or she can decide based on similarities and
trends what the next generation will look like. The cross-project comparison table
could look like this (Table 2.6):
In this table, different system aspects can be seen, such as hardware, software,
mechanics, and system on the left-hand side as categories. The columns display dif-
ferent projects either ongoing in development or requested in RFQ phases. The
projects in this case have different levels, such as base, mid, and high, which is typi-
cal, for example, in the automotive industry.
I have added some entries for system and hardware as examples. Where similari-
ties and differences exist can clearly be seen. For example, the base systems all look
very similar and could be developed with one concept. Furthermore, the high sys-
tem of project 2 can be observed to be a superset of all features. It is worth thinking
of a strategy to develop this project as a platform for all other projects.
This table helps greatly to immediately see overlaps and differences. It is an
excellent base for the system architect to talk about reuse between different projects.
This information should be maintained in as much detail as necessary. In particu-
lar, the software framework, middleware, and OS19 dependencies are interesting
here. Reuse might go down dramatically if something is developed for OS XYZ and
requested in the current project for another OS ABC.
18
CTO is the Chief Technology Officer in the company, the person who is responsible for the over-
all technology strategy and development.
19
OS means operating system, usually QNX or Linux in automotive projects, or also Android and
Windows.
Table 2.6 Cross-project comparison matrix
The system architect ensures that available technologies are identified and can be
reused. Only then can an investigation about make, buy, or reuse be conducted.
2.5.1.5 Performance Analysis
Now it’s time to collect performance numbers for the internal features of the prod-
uct. One should let expert teams measure as much as possible and clearly differenti-
ate between solid measurements and pure assumptions based on extrapolation or
other data. This must be considered later in the risk investigation, or one should
request these data from suppliers and make sure that the deliveries can be trusted.
Here, it is also important that the system architect creates and maintains a library
of measurements from all kinds of features, use cases, products, and technologies.
The more data there are, the more accurately one can estimate system resources.
One should attempt to maintain these data through several generations, becoming
increasingly reliant on them. In larger companies with many complex projects, it
might make sense to have a dedicated department that is specialized in performance
measurements in all kinds of flavors.
2.5 Execution 47
Table 2.7 CPU and memory needs per project
Let’s use an example and look at simple CPU load and memory estimation for
static signal processing blocks in Table 2.7.
In the table, different software features are on the left-hand side with their cor-
responding CPU load consumption and memory needs. On the right-hand side, the
system architect can enable the features for different projects, maybe on a special
SoC.20 Thus, he or she can estimate the overall CPU and memory consumption per
project and create static load balancing to fill the processors appropriately. This
works well in deterministic environments like single-core CPUs with low-level
operating systems. One can see immediately that the high variant in project 1 has a
problem with 112% CPU consumption. Thus, either the project team would decide
to skip one of the features or the development department would commit to a task
to optimize the CPU consumption of these features to squeeze everything into the
processor.
More complex features might need graphics performance, and one would need to
estimate memory bandwidth and performance of the GPU. Things get even more
complex with an operating system like Linux or QNX, which supports load balanc-
ing on several cores, and there might be several competing applications that all need
to run as fast as possible. It might be the case that the navigation system eats up all
of the system resources during route calculation and map creation, while in the
background a Blu-ray disc is running with 7.1 multichannel surround sound, where
every single lost sample is audible. Thus, hard real-time requirements would exist
and one would need to guarantee certain time slots for audio. Luckily, today’s oper-
ating systems support all of these use cases, but the system architect needs to know
all of the traps and pitfalls along the way. Furthermore, he or she needs to know
whether someone in the company can evaluate that, because ultimately he or she
needs to sign up for a certain processor and guarantee that the system is working as
expected. To ensure a proper proof of concepts, feasibility studies are created and
they can be used appropriately.
20
SoC means System-on-Chip. This is typically a processor with multiple cores for different pur-
poses in it like CPUs, GPUs, DSPs, and microcontrollers.
2.5.1.6 Interfaces, Protocols, and System Layers
Finally, all of the interfaces to the outside world have certain requirements. As pre-
viously mentioned, the system architect needs to decide either which interfaces to
choose or to know which interfaces are required. If one has the choice, one might
wish to use something that fits the customer’s needs in terms of features, costs, qual-
ity, availability, internal development effort, and technical strategy. All system
aspects must be considered, such as associated connectors or antennas, hardware
effort such as space on the PCB, and necessary ICs.21 One must know which soft-
ware drivers and stacks are necessary and where to get them. Moreover, of course
you need to know how much data you want to transfer and the nominal bandwidth
of the interface.
When I started in the automotive industry, one of the most relevant bus systems
between devices was MOST22 technology. It connected head units and amplifiers or
other devices for transferring audio, video, speech, and control data using an optical
ring in the car. Later, an electric version was released. From a system perspective, it
was quite challenging because it defines all seven layers of the OSI model.23
However, when up and running, it was very comfortable and reliable, especially for
audio data transfer because of its synchronous transfer mechanism. Special inter-
face ICs were necessary to create the protocol and package audio and control data
on the ring and get it back. The bandwidth in terms of audio channels was clearly
defined and easy to design into a system.
One must ensure that one has an idea about the OSI model and that all seven lay-
ers are defined for the network interfaces. These layers are as follows:
1. Physical layer
This layer is responsible for the electrical, optical, or radio transmission of bits.
It describes how the digital information of ones and zeros is activated, deactivated,
and transmitted. Cables and connectors that connect two devices might play a role,
along with transistors to flip between one and zero and antennas and amplifiers for
wireless transmission.
2. Data link layer
This layer is responsible for a robust and error-free transmission. It describes
how to package the bits into frames, adds checksums, and might have a dynamic
flow control.
3. Network layer
This layer is responsible for the switching and routing of data streams and for
congestion avoidance. It describes how to handle, for example, multiple connec-
tions and which message must go to which address.
21
IC means integrated circuit that is usually a small black device with integrated electronics and
several pins to the outside world.
22
MOST means Media Oriented Systems Transport.
23
OSI means Open Systems Interconnection, a standardized model documented from ITU and ISO.
2.5 Execution 49
4. Transport layer
This layer is again responsible for congestion avoidance and error-free transmis-
sion but on a higher level of abstraction. It describes data segmentation, flow con-
trol, and error control from end to end of the connection.
5. Session layer
This layer is responsible for establishing connections on a higher level of abstrac-
tion to connect one application to another. It describes how to start, terminate, and
restore or synchronize connections.
6. Presentation layer
This layer is responsible for transmitting content from one point to the other.
Therefore, it needs to speak the same “language” between the two points. It also
describes how to compress and encrypt data if necessary.
7. Application layer
This layer is responsible for interfacing with the applications and provides func-
tions for doing so. It typically describes the communication partners, resource avail-
ability, and synchronization.
To offer a comprehensive picture, I also want to talk about layers 8, 9, and 10.
Layer 8 is the person using the technology. Humorously, developers sometimes
defend their implementation by saying “this is a layer 8 issue.”
Layer 9 is an organization and layer 10 is a government, which are not particu-
larly relevant for system architectures but might be worth knowing.
All network or connection interfaces can be divided into these layers, and some-
times the individual ones are more or less important for the current task of the sys-
tem architect.
Other bus systems in the car are CAN,24 AVB, Ethernet, or more special busses
for sensors such as PSI5. It makes sense that the system architect has a good over-
view of the technical details and system-relevant features of these busses. He or she
should maintain a comprehensive table describing interface devices from suppliers,
descriptions of system-relevant features and requirements, hardware and software
dependencies, bandwidth capabilities, master/slave dependencies, and typical appli-
cations. Of course, it is important as always to know what is available in the com-
pany or in the pipeline of technology development departments. A good relationship
with suppliers to obtain preview information is also highly valuable to plan for
future architectures.
However, the interfaces are not only relevant to the outside world but also inside
the product. One might want to have several processors in a device with several con-
nections between them and to other devices.
Typical interfaces are UART, I2C, SPI, I2S/TDM, and PCI. Here, a comprehen-
sive table containing all of the details also makes a lot of sense. These interfaces can
have several variants and it is crucial to define what you need and want to achieve
with them in detail, or if they are compatible if you are connecting two devices with
24
CAN means Controller Area Network.
it. A detailed analysis of technical data sheets is usually necessary to ensure compat-
ibility and a proper design.
Last but not least, one might want to have user-accessible wired or wireless inter-
faces such as USB, SD card, WLAN/Wi-Fi, and BT. A table for comparison is again
extremely valuable.
2.5.1.7 Protocols
For the system architecture, it is important to know the requirements for communi-
cation protocols, how they work, and what effort can be expected in hardware, soft-
ware, connectors, and development work. They can be implemented in hardware,
software, or both, and they are always needed to transport messages from A to
B. Without going into too much detail, I wish to describe some of the fundamental
principles. For more details, it might be worthwhile looking at books such as
Principles of Protocol Design by Sharp [7].
The first question is as follows: How many participants do you have in the com-
munication? Is it a single connection from A to B? Or are C and D involved? Or is
A communicating with a huge crowd of participants from B to Z and beyond?
(Fig. 2.16)
The next question is, who is speaking at all? Are A and B communicating back
and forth or is one participant speaking and the other one only listening? The same
question is valid for the other structures.
Fig. 2.16 Network topologies

2.5 Execution 51
The next question is, how does the communication start and end? Is B always
listening or does it need a wake-up? Is there a special word necessary to make both
aware that the communication starts and ends? What happens if the communication
is interrupted and requires a restart?
Speaking of words, it is of course essential that all participants speak the same
language. If the language is modulated or encrypted, all participants need to be able
to speak and understand these layers.
The next question is, how complex is the communication? Is A talking and not
caring whether B is listening? A might not be waiting for confirmation and does not
care whether B has enough processing power to follow at this speed of communica-
tion, or vice versa.
Last but not least, how urgent is the communication? Is A interrupting B and is
there no excuse for not listening? Or is A only giving information if B is explicitly
asking something?
With these questions, it might be possible to see already which protocols fit
which category. It’s also possible to see that it is not too far off human interaction.
In the following paragraphs, I provide two examples to illustrate what this means:
1. I2S – This is a hardware protocol typically used to connect two audio devices to
transfer audio samples from one device to another. It is a single direction, so
there is one speaker and one listener. It is a fire-and-forget connection, which
means the speaker cannot control whether the listener has received the message
or not. It is also a connection that requires the strict synchronization of clocks.
Otherwise, the individual bits would be wrong immediately. The hardware inter-
face itself usually does not care whether the listener has enough processing
power to process all messages in time. There is no error control and no repetition
of messages in case of failure. If that is necessary, it needs to be solved in higher
layers, such as in software. The language of the messages can be configured
slightly. The interface consists of three electric lines, one of which is the bit
clock (or serial clock), which dictates the speed of bits. The second is the frame
rate clock (or frame sync or word select), which dictates the audio sample rate
and announces the beginning of a message. The third is the data line, which
transfers the content of the messages. The frame rate and bit clock need certain
settings, and the word length can vary but is typically 16 bits. There is a start
message that is a transition from low to high on the electrical signal side, and
there are two channels of audio transported in one message. The 16 bits for the
right and left channel directly represent the value of the audio sample. Therefore,
this interface is rather simple, comes with low effort, and requires a careful setup,
but once configured it usually runs without any issues (Fig. 2.17).
2. Software protocol – I wish to describe a general software interface in contrast to
the simple I2S interface described above. Many protocols use parts or all of the
interface. Let’s assume that we have a graphical user interface on a PC to access
a number of hardware devices with many functions and features. We want to
write into the devices, but we also want to read back from the device or the
devices want to message back. For this communication, hardware interfaces are
Fig. 2.17 I2S interface
of course also necessary, but let’s concentrate on the higher software layers only
in this example. Let’s also assume a connection is in principle already estab-
lished and open. One scenario could be that a user can move a slider up and
down, and this changes a parameter in one of the devices. Certain functions in
the GUI capture the slider position and put a value into a protocol for transfer.
The first question is, what happens if the user moves the slider up and down in
an erratic manner? Do we need all of the individual values in between or can we
skip certain messages and concentrate maybe only on the last one?
This intelligence would be in the GUI itself. Alternatively, if we need all val-
ues, we must make sure that the speed and bandwidth of our software and com-
munication protocol are fast enough to capture and transport all. Then, if the
messages are put into the protocol, we need to make sure that the slider corre-
sponds exactly to the right function in the right device. For this, we need an
address concept similar to our mail systems. What is the letter type/size, country,
city, street, house, and maybe floor or apartment number in real life? In this sce-
nario, this might be urgency, message size, device ID, processor ID, CPU core
ID, function ID, and maybe subfunction IDs in several ways. So, we are compos-
ing a message that consists of the data and address (Fig. 2.18). There might be
other things on top such as encryption or checksum calculations. The message is
now transferred to the hardware interface, which is connected to all devices
simultaneously. Every device receives the message, but only one device recog-
nizes its address and transports the message into higher software layers for
decryption, unpacking, or whatever is necessary. It might be the case that many
messages are going forth and back and we need a data buffer to store messages
in between. Here, intelligent mechanisms are also possible for prioritization and
error handling, but finally the message reaches the right software function in the
right device. The software function itself returns an answer that acknowledges
the reception of the message. This acknowledgment is sent back in the same way
to the GUI, and only when received has the transfer been successful. A timer
might run in the GUI that will not wait forever for an acknowledgment message.
If the timer runs out, a clear error message might be given to the user.
2.5 Execution 53
Fig. 2.18 Software message example
A system architect must make sure that he or she knows the relevant protocols
and what it means to use them in the particular architecture, in addition to the
requirements and which protocols are fulfilling or overachieving them.
2.5.1.8 Environment
Another special topic related to the outside-in view is the investigation of the envi-
ronment. For example, one must know in which temperature range the product shall
work. In the automotive industry, this could be from −20 °C to 80 °C. In other
industries, temperatures can be much more extreme (e.g., a space shuttle must be
able to withstand extreme temperatures).
Humidity also has a crucial effect on electronic parts and must be specified and
investigated carefully.
Dust, dirt, mud, and water can play a role. Imagine electronic parts outside a car,
which must survive heavy rain conditions. Furthermore, electronic devices with
huge processors or amplifier stages produce a significant amount of heat inside the
box, so a fan might be necessary. The fan of course causes air flow in the box, as
expected, but it is also a root cause of dust in the box. The box itself requires certain
dimensions because there is limited space in the car for all of the electronics.
Finally, while the car is being driven, a significant amount of vibration must be
considered. All electronic systems in a car need to survive in this extreme environ-
ment. Therefore, these topics usually need to be specified, and clear requirements
can be created to design and test a system accordingly.
Now that we know all of the boundary conditions from the outside and inside of
the system, we can start to look for dedicated hardware ICs.
2.5.1.9 IC Selection
Let’s start with the main calculation unit of the system. One would want to run all
of these identified features and applications in software on a certain processor. For
small control systems, this might be a microcontroller; for pure audio systems, it
might be a DSP; and for more complex systems, it might be one of the general pur-
pose main CPUs and SoCs, such as those from Intel, nVidia, Qualcomm, Renesas,
Mediatek, or Texas Instruments. All of these have powerful CPU cores that can
handle several applications and use cases with several GHz providing calculation
power of certain GFLOPS25 or MIPS26 on multiple cores.
The performance calculation should be carefully investigated. SoCs have several
cores running with an individual clock speed in MHz or GHz. The calculation units
can then perform add or multiply or memory access functions in a certain number
of clock cycles for a certain number of words in the calculation registers. This usu-
ally leads to a calculation of maximum FLOPS such as 2 cores × 1 GHz × 8 words
× 4 calculations = 64 GFLOPS. In reality, several factors reduce this calculation
speed, so it can only be an indication of what is theoretically possible. To bench-
mark different cores, it is always necessary in my experience to conduct some refer-
ence measurements for standard calculations. Then, one can compare apples with
apples and have a reliable starting point for further estimations and conversions
from one processor to another.
Today, the huge SoCs combine multicore systems with GPUs and other special-
ized processors or hardware accelerators. They can process video inputs and outputs
and drive displays for user interfaces. Moreover, they can include all kinds of safety
and security mechanisms to fulfill current requirements in those areas. They also
have powerful memory interfaces to connect to all kinds of memory. Furthermore,
they might have specialized hardware accelerators such as neural networks engine
support.
For most products, it is not too complicated to choose the right level of proces-
sors such as a microcontroller, DSP, or main CPU, or a combination of all of them.
After narrowing down this first category, it can be more complicated to select the
right device. Usually two or three different IC suppliers are relevant, and from every
supplier, there might be different families as well as different derivates per family.
My experience is that sometimes not even the supplier itself can provide a proper
overview of the relevant features and interfaces. Therefore, I always created com-
parison tables on my own. I added all of the relevant features and had a good sum-
mary of what was relevant for the products I worked on. This included hardware
interfaces, CPU and core details, memory details, special features, availability/road-
map, price, and software support. I recommend staying in regular contact with sup-
pliers to ensure that you always have the latest roadmaps at hand. Create an overview
and make a preselection of the processor of your choice, which could look like the
following table (Table 2.8):
This table presents an example of the selected features per processor. The details
that are necessary depend on one’s industry and use cases. The last column is inter-
esting for observing how much performance is available per price. This is also help-
ful for arriving at the right choice of processor.
Now, it is important to design all of the peripherals. Certain ICs may be required
for interfaces such CAN. Other processors and ICs are required to make things such
as FM radio, Bluetooth, and Wi-Fi available in the system. All of these ICs usually
25
GFLOPS – Giga floating point operations per second.
26
MIPS – Million instructions per second.
2.5 Execution 55
Table 2.8 Processor family comparison matrix
need to be connected to the main CPU to run high-level applications on it. It is cru-
cial to have enough interfaces, and all interfaces must actually fit together. There are
several things to consider such as clocks, formats, master/slave configurations, volt-
age levels, and timings. Here, it also makes sense to have comparison tables for all
kind of IC categories.
Think outside the box! Be creative! If it is possible to run an audio algorithm on
a small microcontroller that is initially not made for it, then you might save some
money. Or, if several devices can be connected to one bus to save some interfaces on
the main CPU, you might be able to choose a smaller derivate and save money here
as well. However, make sure that it is not a major effort on the software side that eats
up all of your benefits there again. Or, if you see that all of the small and specialized
interfaces on your main CPU are missing, you might be able to pick and choose an
FPGA27 or ASIC28 to realize all of these interfaces and connect with a high band-
width bus such as PCIe29 to the main CPU. There are often several possible solu-
tions. Spend some time to create different alternatives, discuss and compare them
with your colleagues, and finally decide on the best choice in terms of features,
quality, effort, and risk.
By now, you should have a good idea of all system-relevant features and require-
ments. You can create a diagram that shows all of these elements and investigate
whether to make, buy, or reuse them in all cases. Such a diagram is slightly more
detailed than the topology diagram and could look like this (Fig. 2.19):
This figure displays all of the main system components in one view. The diagram
shows not only hardware components like the main processors but also the main
software blocks running on them. For a first high-level overview, these diagrams are
extremely useful. It is also possible to use different colors for the blocks to show the
development status or responsibilities. Furthermore, it is also highly valuable to
27
FPGA means field programmable gate array and is a programmable IC containing flexible
generic logic elements and interfaces that can be designed and configured after manufacturing.
28
ASIC means application-specific integrated circuit and can be designed similar to FPGAs but has
a fixed design after programming.
29
PCIe means peripheral component interconnect express and is an interface standard between
peripheral devices and a main CPU.
Fig. 2.19 Diagram of system elements
create these diagrams for different use cases. You could create, for example, one
special diagram to show which elements are part of an MP3 file’s playback in the
system and where the audio and message paths pass through. These diagrams are
useful for discussing the architecture of a single use case or feature.
2.5.1.10 Hardware Design
People who are really serious about software should make their own hardware.
– Alan Kay
American Computer Scientist
The next level of details is the creation of a hardware design diagram. A first draft
of a hardware block diagram can be created that shows ICs, interfaces, and connec-
tors to the outside of the system. This should be done in close cooperation with the
2.5 Execution 57
hardware architect, who must be involved now for all of the details on the pin level.
He or she will also create dimensions for power supply and other hardware-related
details. Last but not least, he or she must evaluate what kind of PCB can be used for
the product. The number of layers has a cost impact and needs to be chosen care-
fully. Placement studies, space on the PCB, grounding, and partitioning – all of that
needs to be created now from the hardware architect based on the high-level hard-
ware block diagram from the system architect. The hardware architect creates a
more detailed hardware block diagram that could look like this (Fig. 2.20):
Here you can see all of the details that we have discussed so far. How many PCBs
are part of the system? What interfaces inside the system and connectors to the out-
side world exist? And, of course, which processors, ICs, and memory devices did
we choose? This diagram captures all of these details in a single view. If your sys-
tem has several variants, it is easy to show that here too. Memory variants, inter-
faces, population options, as well as different system levels can be shown if your
tool has the option to work with layers.
The next step for the hardware architect might be to look into details on the pin
level. Most of the main CPUs and more complex SoCs have a pin multiplexing
Fig. 2.20 Hardware block diagram

concept. This means that it is possible to configure several interfaces using the same
pin group. The architect needs to decide which interface to realize and needs to be
careful designing it. The data sheet of the processor usually counts all possible inter-
faces. So, for example, in the overview you might read that there are four different
SPI interfaces available, but upon looking into the details, you see that only two
have dedicated pins and the other two are multiplexed with UART or I2C interfaces.
Therefore, it’s important not to rely on the data sheet overview and to check pin
multiplexing in detail.
As mentioned above, the power supply of the whole system needs to be designed.
How much power do we need in total? How many watts do we need to foresee as a
worst case? How many different voltages are necessary in the system? Do we need
3.3 V and 5 V or more? Is there analog audio in the system and do we need to be
careful with the distortion of these signals? Or are there many high-frequency com-
ponents in the system? Signal integrity is a large topic. Different things should be
simulated upfront to avoid expensive trial and error iterations with real hardware
built up.
In an RFQ phase, one may wish to design as much as possible or necessary to
obtain solid effort and cost estimates. In the development phase, the hardware
design follows the regular development flow, such as concept, design, schematics
creation, layout creation, PCB ordering, assembly of parts, hardware bring-up, mea-
surement and testing, and interface checks. Once all of that is done, the system can
be handed over to software department, but especially the checking of interfaces
needs to involve the software department already. It could make sense to have a
small team that creates software for hardware checks only. Parameters and registers
can be configured, and hardware interfaces can be physically measured and com-
pared with the specification and the requirements.
The system architect needs to have an overview of all of that. He or she needs to
point out hardware and software dependencies if they are not obvious, as well as to
request checklists or other proof of evidence documents that show designs, reviews,
implementations, and tests. With a systematic approach, it is easy to create gates and
approvals and go from one step to the next in such a development.
There are perhaps two main challenges on the hardware side for the system
architect to be aware of:
1. Compromise – There are many cases where hardware parts don’t exactly fit
one’s needs. It is always a compromise and difficult to choose between different
suppliers, features, prices, software support, and development effort. In particu-
lar, the system architect has the responsibility of having an eye on all of these
aspects. A well-known trap is the hardware department choosing a device with-
out talking to software departments first, which might result in bad surprises.
The system architect should create the bridge between both disciplines and
ensure that all aspects are covered.
2. Timing and risk – I often worked on projects where we discussed chipsets that
were on the roadmap of suppliers but did not yet exist in mass production. If you
are integrating such an IC into a system, you are introducing quite some risk of
2.5 Execution 59
course. You have the benefit of being on the cutting edge of development, and
competitors might not be there already. However, you might also be required to
much work in helping to debug the IC together with the supplier and making sure
that all is working and bug-free. The system architect might play a crucial role
here because he or she has a market overview and helps to create specifications
for feasibility studies to mitigate the risk as effectively as possible.
In general, hardware maturity is validated through the different development
phases. In the automotive industry, especially in Germany, these might be phases
A, B, C, and D in the product development. Please see the document
Reifegradabsicherung für Neuteile by VDA for more details [8]:
A Sample
The A sample usually proves some basic functionality. That might be an evaluation
board in the laboratory with some hardware building blocks or only a mechani-
cal sample.
B Sample
The B sample usually validates the full hardware content with some basic software.
Hardware and mechanics should be close to final product requirements but still a
prototype. The design verification can begin.
C Sample
The C sample has the full functionality to finish the design verification. It is pro-
duced already using manufacturing processes to start process verification.
D Sample
The D sample is produced using mass production tools and processes to get to the
final product verification and be able to start the production.
In the US market, these phases have different names such as the EVT (engineer-
ing validation test), DVT (design validation test), and PVT (production validation
test) – but the idea is more or less the same. The concept, architecture, implementa-
tions, and processes are tested one step after the other to clearly track the maturity
of the development and to mitigate risk of failures from early stages.
2.5.1.11 Mechanics Design
Once the hardware placement study has been conducted, one can start involving the
mechanics department. PCB space should be defined now and they can design a box
around it. It is crucial to have all relevant heat dissipation information from the
processors and amplifiers so that the temperature management can be created. This
means adding special cooling materials and fans to the system. Temperature or ther-
mal simulation can usually be performed based on the information currently avail-
able. This provides further input for fan requirements, heat dissipation strategies,
and mechanical design in general.
Furthermore, the EMC30 department must be involved to make sure that the
unwanted effects of electromagnetic energy are avoided from or in the environment.
Said department must work closely with the mechanics department to produce a
proper design for the housing of the system.
2.5.1.12 Simulation
Part of hardware and mechanics development is building things up physically, but

creating a PCB and assembling all of the parts takes quite some effort. Furthermore,
building a box can be quite complex as well as time- and money-consuming. In
particular, creating the tools to manufacture housings for mass production is expen-
sive and should only be done once. Thus, in the development phases of those things,
one must reduce the iterations as much as possible to save money and time. Here,
simulations can be of great help.
Hardware simulation can be done in several ways. For example, one could start
by creating schematics and then use systems such as PSPICE31 to simulate all kinds
of analog, digital, and mixed-signal behaviors. This would already provide an over-
view of the signal integrity and feasibility as well as verify the design in general.
High-speed designs such as memory interfaces that run with several hundred MHz
or GHz need a proper high-frequency design, which can be simulated using systems
such as those from ANSYS or Mentor.
Mechanics simulation starts on a graphical base. A first-hand drawing could be
seen as a first simulation that already shows how the mechanic dimensions and parts
work together. Of course, today CAD32 design is used everywhere and can be com-
bined with 3D printing to test things quickly. Dimensions, materials, and behaviors
can be designed and configured in all kinds of flavors, and tools exist to integrate the
three-dimensional drawings into the overall workflow to reach a full virtual product
development. The combination of graphical, material, and behavioral simulation
leads to more or less full models in the virtual reality space. Then, it is possible to
simulate thermal behavior, fluid dynamics, stress tests, acoustic behavior, user expe-
rience, and much more. For example, it is possible to simulate car acoustics with all
relevant components such as music playback, signal processing, the amplifier,
speakers, and the car interior and then experience it using headphones. Thus, it is
possible to listen to the car sound system before the car is actually built. All that is
required is the complete CAD description of the car and speakers combined with an
amplifier simulation.
30
EMC means electromagnetic compatibility.
31
PSPICE is a commercial version of the open-source project SPICE that means simulation pro-
gram with integrated circuit emphasis.
32
CAD means computer-aided design.
2.5 Execution 61
The gap between the real world and simulation must be evaluated carefully.
However, for most of the aforementioned topics, the simulation capabilities are
already very solid and reliable.
Of course, software can also make use of simulation. CPU load and memory
bandwidth can be simulated before everything is run on hardware or dedicated chip-
sets. Development environments can be packaged into virtual environments, and
graphical user interfaces can be simulated on development PCs before they are
available on target devices. Furthermore, behavioral things can be simulated, such
as environmental changes, user inputs, and errors.
The system architect should know what might be possible and how to speed up
development on the one hand while mitigating risk in early development stages on
the other hand.
2.5.1.13 Software Design
Software is a great combination between artistry and engineering.

– Bill Gates
Microsoft
After IC selection, several processors and peripherals are selected to realize the
system, which is the necessary input for software departments. They create software
architectures starting with requirements collected based on the given hardware com-
ponents. The main CPUs might be equipped with an operating system such as
Windows, Linux, or QNX,33 while smaller microcontrollers might have customized
frameworks or lightweight operating systems such as μC/OSII.34 Which way to
choose depends on features, footprint, availability, effort, technical strategy, and
customer requirements. In the projects I worked on, we did not have much choice.
For the automotive world, QNX was quite popular for a certain time. Linux came in
later and finally Android. To deal with the instability and uncertainties of an operat-
ing system like Android, strategies such as software virtualization and hypervisor
approaches were chosen to encapsulate but also to be able to integrate everything
into one multicore processor.
Hardware interfaces automatically lead to software drivers, which need to be
developed and configured on the particular processor in the respective operating
system. Resources such as memory, DMAs, and GPUs also need drivers and con-
figurations. Software frameworks for handling middleware, applications, and mes-
saging in a standardized manner can be developed or used from third-party suppliers
33
QNX is a commercial operating system mainly for embedded systems.
34
μC or MicroC OS II is another real-time operating system for embedded systems.
like Autosar.35 Also in the Linux world for the automotive industry, initiatives such
as the GENIVI Alliance36 appeared to use and develop open-source software and
create standards across car manufacturers to make life easier and those complex
systems more reliable.
So-called middleware needs to handle the low-level functionality of applications.
Software stacks include everything from hardware drivers to application layers and
are ready to use from applications if available for the processor.
In addition, all manner of supporting functions must be taken care of. You might
want to have certain implementations and functionalities for booting up and shut-
ting down the system. Peripherals might need to be controlled from a higher level in
a centralized manner. Diagnostic functionality is another huge topic in the automo-
tive industry. Last but not least, software updates play an important role. What used
to be done in the garage or at the dealer can today be done using over-the-air update
mechanisms. The system can be diagnosed, updated, configured, and controlled
remotely.
Also necessary are topics like security and safety: that is, security to make sure
the system cannot be hacked and safety to make sure requirements for different
safety levels like ASIL-A/B/C/D37 are met.
To create all of this and visualize the software design, several block diagrams can
be considered. The high-level design should show the main components of a sys-
tem, such as the operating system, software frameworks, main applications, and
main supportive functions. This could look like the following figure (Fig. 2.21):
The figure presents a high-level diagram for illustrating the application XYZ and
its surrounding components.
Another view could show different applications or use cases in more detail. For
example, one could draw a diagram per application to show signal and control paths
between software blocks, including interfaces and drivers per core or processor.
This could look like the following figure (Fig. 2.22):
This view is very useful for presenting all of the components that are necessary
for realizing one application in the overall system. In this example, application can
be seen XYZ in focus. Color coding can be used to present the application itself as
well as dependencies to components from other applications such as the function
and driver.
More detailed diagrams can be created using UML38 as a standardized graphical
design language. This already shows the level of software functions, classes, and
interfaces that could directly be used for development departments as design speci-
fications or for automatic code generation. These diagrams usually look like this
(Fig. 2.23):
35
Autosar means Automotive Open System Architecture and is an industry partnership to create an
open standardized software architecture.
36
GENIVI means next-generation in-vehicle infotainment and is an open development community
and standard producing software components.
37
ASIL means Automotive Safety Integrity Levels as mentioned above.
38
UML means unified modeling language.
Fig. 2.21 High-level software block diagram
Fig. 2.22 Application-based software diagram

Fig. 2.23 UML diagram
Furthermore, the complete system can be designed using diagrams such as these
with the design language SysML.39 This is based on UML and describes the whole
system. More can be found in the book Systems Engineering mit SysML/UML of
Weilkiens [9].
2.5.1.14 System Variants and Scaling
Sometimes not only one single system or device is required as a product but rather
a number of variants or product levels. The responsibility of the system architect is
to make sure that the effort to realize those variants is optimized.
It might be the case that for different regions in the world different radio tuner
modules and software components are necessary. Therefore, an architecture that is
modular and configurable makes a great deal of sense. This is because it would
enable the exchange of relevant modules in hardware and software on the product
platform while keeping everything else the same, thus keeping development and
testing efforts low.
Alternatively, the customer might ask for different product levels. This is often
the case in the amplifier product market. For example, he or she could ask for a
base system, a premium system, and a high-end system. Here, one should ensure
maximum reuse between those product levels. You might be able to choose proces-
sors from the same product family such that hardware differences are small. In an
ideal case, they would even be pin compatible. Software might be exactly the same
39
SysML means system modeling language.
2.5 Execution 65
Fig. 2.24 Variants and scaling
with different drivers and configurations. Other hardware parts like amplifier ICs
might be able to be populated or depopulated so that the main PCB is the same in
all variants, which would save time and effort in development and testing
(Fig. 2.24).
2.5.1.15 Distributed Systems
Many electronic systems cannot work as stand-alone systems. Your smartphone at

home is part of the Wi-Fi system in your house, or it has a data connection into vari-
ous clouds. Especially in an automotive electronics environment, the individual
control units are connected most of the time through automotive busses like CAN,
AVB, Flexray, or similar. If the unit more or less works stand-alone and the connec-
tion only serves to exchange a small amount of status data back and forth, then I
would not see many challenges regarding distribution. However, for several control
units with powerful processors as well as functions distributed across devices, then
one should speak of a distributed system.
My favorite example is the audio system in an automotive infotainment environ-

ment. The classical approach is to connect an amplifier to a head unit. The head
unit contains all of the source processing like a media player, audio decoders, and
sample rate conversion. The plain audio channels are then transferred through a
multimedia bus such as AVB, A2B, or MOST to the amplifier where the DSP is
located, which is performing all of the digital signal processing. It might be the
case that a telematics box is also in the car that covers all of the connectivity like
Bluetooth and Wi-Fi in addition to handling all telephony functionality. Thus, DSP
power would also be necessary as well as some audio algorithms for echo cancel-
lation and noise reduction. Last but not least, you might have a cloud connection to
process voice recognition in the cloud. The system thus becomes even more dis-
tributed (Fig. 2.25).
Now, there are DSP power and signal processing for audio in three different
devices and in the cloud. The system architect needs to very carefully design how
the signals are routed, which functions are necessary per unit, what latency is
required to fulfill specialties such as speech processing, and so on. A holistic view
is necessary, which can help to find the best possible solution in terms of system
costs and resources, development effort, and risk.
Fig. 2.25 Distributed systems

2.5 Execution 67
In the figure above, how these system elements would be connected from a high-
level perspective can be seen. A single system architect does not usually have the
responsibility of designing systems like this. In particular, a smartphone is full of
standards and standard interfaces that must be fulfilled to connect it to a system. The
system architect of an infotainment system does not have much choice there.
Another example of distributed systems might occur when a company does not
receive an award for all devices but is still responsible for the overall system setup
and integration. Then, it is crucial to cooperate with the other suppliers and create
detailed interface specifications. This is usually also part of the system archi-
tect’s job.
2.5.1.16 Dynamic Behavior
All that was described so far is a rather static view of the system. However, it is of
course also important to look into the dynamic behavior and the requirements for it.
Typical topics are boot-up timing, early application starts, latency between signals
and events, switching scenarios, and system shutdown timing.
Boot-up timing is always important in an electronic system. Imagine a PC or lap-
top as an example. The boot-up timing is not mission critical but is always noticeable
to the end-user. In the automotive industry, the boot-up timing is much more mission
critical. One example I always had to deal with is the so-called taxi driver use case.
Imagine that a taxi driver is sleeping in his car and suddenly wakes up, immediately
starting the engine and wanting to reverse. Let’s assume this is a car with an ultra-
sonic sensor system at the front and rear bumpers to detect objects and especially
distance to the next objects. This system generates a tone or something similar to
warn the driver that he or she is getting closer to an object that could damage his car.
Thus, when the taxi driver wants to reverse, the system needs to respond immediately
to prevent damage. The system requirements are usually that the head unit is booted
and the audio system is functioning and responding to the sensor data in a time frame
of 1 second. This can be quite challenging if you have a main CPU with an OS and
several processors in the system that need to play together for that particular use case.
One might end up with scenarios where the system is not yet fully booted or where
one runs these functions on a small subprocessor to guarantee the timing.
Another topic dealing with critical timing requirements is active noise cancella-
tion. There are several applications in cars like active engine order cancellation or
active road noise cancellation. Similar to active noise canceling systems for head-
phones, these systems usually estimate or measure noise, and the audio system then
creates anti-noise to cancel out unwanted noise. This leads to a quieter driving expe-
rience and increases comfort for both driver and passenger. However, in these cases
the anti-noise must be created with a certain timing. In particular, when noise is
measured, the anti-noise must be as fast as the real noise when traveling to the ears
of the driver and passengers to guarantee good results. This can be quite challenging
Fig. 2.26 Timing behavior diagram
for the system architecture. The whole signal chain from sensor to hardware, from
software driver into the algorithms and back to the loudspeakers, needs to be much
faster than regular music playback applications usually require. If both applications,
music playback and noise cancellation, should run in the same system, a tricky
setup is necessary to solve this problem.
It helps in any case to create a timing diagram where all components and their
timing behavior are visible. Figure 2.26 presents a simplified example of sensor data
that goes through hardware and software layers until a software application creates
a result from it.
Furthermore, UML helps here with sequence diagrams to visualize timing
dependencies between different functions and the dynamics of messaging
between them.
Another application in a car is a hands-free telephone, where an echo cancella-
tion algorithm is necessary in the system. Special timing requirements are also
given to realize the system. If the anti-sound comes too late, then the whole system
is not canceling anymore, and strange and annoying behavior can occur. Of course
one cannot overcome physics and cancel a noise or sound that is already in the ear
and perceived by the brain.
2.5.1.17 Priorities
Priorities are necessary in products with several competing applications on one pro-
cessor, where the system needs to decide which use case is more important in cer-
tain situations. Usually operating systems such as Linux, Android, QNX, and
Windows have everything on board that is required to handle priorities. Yet, one
must define it carefully to avoid unwanted delays or false behaviors of the system.
An example of a priority topic is controlling the load peaks of applications. Let’s
assume the navigation system is started and calculates a long-distance route with all
of the CPU power available. It should be ensured that other applications like the
audio subsystem still have enough priority in the software to process every single
audio sample in time. Whether the navigation calculation takes one second longer
or not might not disturb the user in the car, but if a single sample is lost due to prior-
ity issues in the software, then one might be able to hear a click, which should be
avoided in any case.
2.5 Execution 69
Furthermore, the audio source and output channel management can be quite
complicated. The number of audio sources in cars is no longer small. A complex
matrix might be necessary to define priorities and what-if scenarios. For example,
let’s assume that you are listening to music and a navigation prompt occurs.
Simultaneously, a warning tone needs to be played and a telephone call comes in.
This might happen in reality, and therefore, the architect needs to define how many
channels can perform playback in parallel, what the priorities are, what is muted and
demuted, and how the volume should behave.
2.5.1.18 Compromises
As mentioned above in the hardware section, an important topic for creating system
architectures is how to find the right compromise, but of course this is not a hard-
ware topic – it affects all disciplines.
Usually, chipsets do not fit perfectly. Furthermore, requirements may compete
with each other, development time may be longer than necessary, the perfect solu-
tion may not fit the company strategy, or the cheapest processor may have very poor
software support. There are several reasons for why a compromise might be neces-
sary, and I argue that to deal with this, creating and evaluating options should be the
daily work of system architects.
While there is no generic set of rules that can be followed to reach a good com-
promise, there are still some things to be considered.
1. Brain and team power – Finding compromises is a creative process. Find the best
and most open-minded people in the company for that particular problem, sit
together, and try to solve it. A system architect can have excellent skills and be
extremely brilliant. In a team, usually much more is possible, so he or she should
not rely on his or her own skills. With the right atmosphere, a great deal is pos-
sible. One of my famous examples is the creative brainstorming session that was
necessary to save the Apollo 13 mission. Watch the Apollo 13 movie starring
Tom Hanks to see what I mean.
2. Project management – Ultimately all compromises are reflected in different proj-
ect management setups. Development time might be longer, risk might be higher,
chipsets might be more expensive, and features might be dropped. All of that has
to do with timing, quality, or scope – the triangle of project management.
Therefore, if the supplier–customer relationship and communication and escala-
tion paths are well-established, the compromise can be negotiated with stake-
holders or customers, and even a bad compromise might lead to a good,
working system.
3. Data and tools – A decision should be made based on facts. The more data one
has and the more tools one uses to gather, process, and display the data, the better
it will be. Don’t rely on your gut feelings. System architecture is a technical
discipline, not an emotional topic.
However you reach a compromise, make sure that you document it well enough.
This will help future decisions and can also be used as binding documentation
between the supplier and customer if necessary. Decisions and how you got there
should be clearly marked in the system architecture documentation, which is one of
the main work products of the system architect.
2.5.2 Work Products and Documentation
I have described a great deal about work products already. I now wish to summarize
the essential parts, including what should be mandatory in a company and what
might be optional.
Of course, how detailed and comprehensive the documentation is depends on the
project phase. However, in general, an essential part of system architecture design
is to document everything – not only concepts but also what the process was to get
there, including reviews, decisions, and why they were made. This is not only
important to remember it one day but also to document negotiations with other
departments, suppliers, and customers. What is written down, reviewed, and signed
can be binding and thus business-relevant.
In general, the following topics and activities should be documented:
1. Requirements – As mentioned in the requirements chapter, this is an essential
part and the beginning of the V model. If the system is developed in a supplier–
customer relationship, the requirements come from the customer usually. Then,
answers, restrictions, deviations, and assumptions need to be documented.
Workshops, negotiations, reviews, and decisions about those requirements
require a written protocol, and the requirements need to be broken down into
system requirements and subsystem requirements. Even a split into hardware,
software, and other functional domains might be necessary. If the system is
developed without a supplier–customer relationship, the requirements should
still come from somewhere and need to be written down. In that case, it could be
the product management department or someone else defining products, but it
will be a great help if requirements are clear from the beginning and before the
development phase. This can be different for waterfall-driven projects or agile
development projects. You will read more about this in the last chapters of
this book.
2. Design – This is fully within the responsibility of the system architect, depend-
ing on the project phase, which could be more or less detailed. In an RFI phase,
it might be block diagrams in a set of PowerPoint slides with some descriptions.
In an RFQ phase, a detailed concept is necessary as a baseline for the upcoming
project and for effort estimations. This should be written down in a system archi-
tecture specification covering all of the abovementioned block diagrams, includ-
ing detailed descriptions. This includes, for example, topology diagrams, system
diagrams, hardware block diagrams, placement studies, software partitioning,
2.5 Execution 71
mechanics, simulations, designs, interfaces, and dynamic behavior with dia-

grams among others. Everything related to resource estimations such as the CPU
and bandwidth must be documented. In the development phase, this specification
is the baseline to work with, and all necessary details during the development
must be added. Before the development phase, this might also be a baseline for
refining the effort estimation of the overall project. In particular, interface
descriptions can be essential when they also describe the border between differ-
ent organizations. These could be two different departments or a supplier–cus-
tomer border if, for example, subsuppliers deliver something into the system.
Why one or the other option was decided on and who participated in the discus-
sions around it should be written down.
3. Meetings and workshops – One should make sure that reviews and decisions are
also documented. In particular, what comes out of workshops between customer
and supplier is important to document. A special document or intranet page col-
lecting meeting protocols and open issue lists makes sense.
4. Commercials – The result of the RFQ phase is usually also a list of all parts and
components, the bill of material, and a list of licenses called the bill of licenses.
The whole development effort must be estimated. This is usually not a task for
the system architect, but it reflects the commercial aspects of his or her system
architecture. The system architecture design is the baseline for effort estimations
and cost calculations.
5. Other optional documents – I mentioned some helpful tables and documents
above that might make sense for the system architect to create. Project compari-
sons, processor family comparisons, technology/feature/platform lists, and a list
of experts – all of these will help the system architect to make data-driven deci-
sions during a design phase.
2.5.3 Presentations
If you can’t explain it to a six year old, you don’t understand it yourself.
– Albert Einstein
Theoretical Physicist
Developer of the theory of relativity
Finally, when the whole work is done, you now need to sell it. You will want to
convince and explain internally in the company what you have created and why.
Furthermore, if that product is an answer to an RFQ, then you probably need to
stand in front of the customer and explain the system architecture. This might be
part of the RFQ presentation at the customer’s location. The system architect should
be responsible for this technical part and should present it himself/herself. Depending
on the customer, it can be a presentation and discussion on the same level of exper-
tise, or it can be a presentation in front of people who don’t have much technical
understanding. One must be prepared for all occasions.
A presentation is of course also an art in itself. Numerous books and training
courses are available. I think the most important thing is to transport the message,
either technical content, facts and figures, competency and excellence, or whatever
is important in that particular presentation. Think about the audience upfront and
prepare accordingly! It doesn’t make sense to present detailed specifications to top
managers, or vice versa, to present high-level strategies to engineering experts.
Here, I want to mention two points that helped me during my career. The first is
working with agencies. It is such a difference to have a presentation from an engi-
neer who just does not understand the basics of presentations, compared with a
professional PowerPoint slide deck that has excellent language, appealing graphics,
a well-defined flow, and all of the engineering content that one would want to show.
If you have a budget, then use it.
The second point concerns the so-called thinking hats from De Bono. Please read
his book Six Thinking Hats [10] for the whole story around this concept. The six
thinking hats all have different colors and stand for different approaches of thinking:
• White hat: facts and figures.
• Yellow hat: optimistic view. What is the value and benefit?
• Black hat: pessimistic view. What might go wrong and what are the issues?
• Red hat: emotions and feelings.
• Green hat: view on creativity and opportunities.
• Blue hat: processes and structure.
Now think about the audience for your presentation. How can you make sure that
you can convey the message to everybody? You might have engineers, managers,
financial experts, and quality experts in the round – perhaps totally different types
of people, all with different mentalities. How can you trigger them all and present
something that they will like and remember? Try to cover all six hats in your presen-
tation, and then you might be on the safe side. Present facts, figures, and processes.
Present not only the main technical part but also the benefits, issues, and opportuni-
ties. This will round up nicely what you have presented before and provide a com-
prehensive overview. Add some emotions to it, perhaps by telling a story. Try it out!
2.6 Example and Summary
If you could get all the people in an organization rowing in the same direction, you could
dominate any industry, in any market, against any competition, at any time.
– Patrick Lencioni
Manager and author of “The five dysfunctions of a team.”
2.6 Example and Summary 73
I hope that you now have an idea of system architecture design. We have covered the
principles of system architecture and discussed the preparation and execution of the
design process.
Let’s create an example to illustrate what was described thus far and to provide
more practical aspects. Let’s also make it a little bit larger than just a sketch of a
system architecture design job. Imagine that you receive an assignment to lead a
task force to improve the development of three automotive customer projects and
they all use the same kind of middleware software to enable a certain set of features
with high overlap in functionality. The timelines are more or less in parallel and all
are critical. The middleware is not ready yet and customer deliveries are all at risk.
Management has decided to create a task force to solve the problem and join forces
independent of department boundaries to deliver the middleware in time. How do
you start?
2.6.1 Step 1: Preparation Phase
The first step is to analyze the current situation. What is really the problem? Where
are the delays and how bad are they? What does the architecture for the individual
projects look like? What are the requirements? How are the teams organized and
how is the relation between different teams? Are there other issues or any strategies
worth looking into? Basically, take a deep dive into requirements, architecture, proj-
ect management, processes, and people!
Requirements:
• Request requirements elicitation documents. Go through the statistics and inter-
view the requirements manager. Let’s assume you find out that they all have
worked on requirements pretty thoroughly. Everything is documented and clearly
communicated with the three customers. However, there is not much communi-
cation between projects and also no link to feature descriptions of the middleware.
–– Analysis: Requirements are more or less clear in the individual projects, but
there is no investigation about reuse between the projects. There might be an
opportunity to avoid double work and that is not visible at all. Moreover, a
process is missing for how to immediately answer customer requirements
with middleware features, and a clear link between both is also missing. This
is a source of misunderstandings and potential loss of information.
–– Action A: Find a good requirements engineer, and assign him or her a task to
compare all three projects. Find similarities and differences. If necessary,
assign a system architect for support when it comes to detailed technical
questions.
–– Action B: Find a technical expert from the middleware team who can link the
middleware features to customer requirements.
Requirements are always the first step. You should know what you want to
achieve. If the requirements from customer projects are clear and the overlap is
identified, then you can compare that with middleware features and discover what is
already available or what needs to be developed. For the missing features, a discus-
sion can begin about resources and responsibilities.
Architecture:
• Request system architecture work products from all four parties (three projects
and middleware). Ask for system requirements specification, interface specifica-
tions, system architecture design documents (static and dynamic behavior),
checklists from reviews, documentation about decisions, documents showing
communication in the team, and traceability and consistency records. Let’s
assume that you find that some block diagrams are available, all in different for-
mats. Some interfaces are described and specified. There is no global alignment
between the projects. The team developing the middleware made some efforts to
align them but they are stuck in political discussions about who owns what.
–– Analysis: The system architecture seems to be an issue here. We can see that
the system architecture design is necessary for proper effort estimation. Other
than that, no global alignment is in place. That also means that no platform
development strategy was created. No one is checking reuse between projects.
The middleware team has the competencies to do it, but there is no assign-
ment for them, and capacity doesn’t allow to work on it proactively.
–– Action C: Assign a system architect to align these three projects in the context
of integrating the middleware. He or she should create an overview of the
features, interfaces, system impacts, and details of the integration. Furthermore,
he or she needs to check whether the architecture designs are completed at all.
The requirements work from Actions A and B is a very good starting point.
The architecture is the foundation of everything else. Only with an architecture
in place can a proper work package breakdown be generated, proper effort estima-
tion be done, and project plans be created and reuse between concepts, and tech-
nologies be evaluated. It is essential to create a system architecture specification for
each project and work through the main aspects like topology diagrams, system
diagrams, hardware and software diagrams, interface specifications, performance
analysis, dynamic behavior, regulations, certifications, and mechanics solutions.
Project plans:
• Request the project plans from all three projects. Check when the middleware is
expected and what the plan is for the feature rollout, so which version of the
middleware is necessary and which features in detail are necessary. Check also
what effort was planned to integrate the middleware. Let’s assume that you find
out that they all talk about different things, the features are not clear, and they all
have different understandings of the architecture of the middleware. The effort
required to integrate the middleware is not clear. Only high-level requirements
are clear. Plans are generated using a waterfall approach and are available in MS
Project and MS Excel. Feature descriptions and time plans for releases are not
clearly communicated.
–– Analysis: Plans are available in general but not reliable because the system
architecture with the integration of the middleware is not understood clearly.
Effort estimations cannot be right or at least are at risk. A detailed analysis of
feature descriptions and whether they fit the requirements is not in place.
Furthermore, it is unclear which versions of middleware and features are nec-
essary, when they are developed, and what effort is necessary to integrate them.
–– Action D: Again, create a clear system architecture design for all three proj-
ects including the middleware and all of the required features. The system
architect is again the central person here.
–– Action E: Together with project managers, a cleanup is possible. A hierarchy
of plans is necessary to show individual gates and milestones of projects and
middleware and how that all fits together as a big picture. One project man-
ager needs to create a master plan showing customer project milestones and
middleware releases in one plan.
–– Action F: The development teams are necessary to re-estimate the develop-
ment effort based on the new results so that the plans can be adapted.
• Request the project plan for the middleware and check feature deliveries against
plans from above. Let’s assume that you discover that they are running in a type
of Scrum framework but without long-term planning and cannot give you exact
numbers. They all have the main features on the agenda but without clear mile-
stones of when to deliver. Some features are planned to be developed by other
teams who have no clear assignment yet. For that, no time plan is available again:
The middleware development is split between five different teams and all work
in Jira using agile methods such as backlogs, sprint backlogs, user stories, and
tickets. The individual team structures changed significantly in the last 12 months,
so team velocity is not possible to calculate and not available.
–– Analysis: No long-term planning is available. No milestones for middleware
deliveries with certain features are available. Some features are not planned at
all. The team setup is questionable. Interdependencies are not written down.
An overall software architecture and plan are not available.
–– Action G: Assign a software architect and technical expert for features, and let
them check what the situation is together with the main system architect.
They need to create a detailed software architecture that covers all relevant
features. Moreover, they need to create a work breakdown structure that can
be used for effort estimations.
–– Action H: Assign a project lead and identify work packages for different
teams. Create user stories and update the backlog. Estimate the effort of rel-
evant backlog items. Estimate team velocity based on current teams, and
create a plan from the complete backlog. The whole team probably needs to
be involved to estimate the development work.
–– Action I: Sit together with architects and project leads and think about the
team setup. If necessary, create a new proposal, such as integrating all relevant
middleware teams into one task force organization using existing resources. A
scaled Scrum setup might be the right choice to be installed later (see the last
chapters of this book).
–– Action J: Align the project plans with the middleware plans, and check critical
paths and potential delays in that master plan.
–– Action K: Add resources to the plan until delays are compensated, or reduce
tasks if adding resources doesn’t help. Remember that adding resources is not
always possible. As one of my colleagues always said, “Nine women can’t
give birth to a baby in one month!” Of course negotiation with stakeholders
and customers might be necessary if you are reducing tasks and features.
After the architecture is clear and work packages can be defined and estimated,
it is possible to create improved project plans. The next step is to see if the project
plans can be filled with people and all tasks can be assigned to someone.
Teams:
• Request org charts and all information that is legal to collect, namely, the names,
location, skill sets, roles, and responsibilities. Map the resulting competencies to
the current tasks of project development and middleware development. Check
how efficiently the teams are communicating, especially when working across
different time zones. Let’s assume you find that the competencies and skillsets
are outstanding. There are excellent people on board. However, you also find that
the global setup seems to be difficult. Some teams are spread around the globe.
The potential benefit of that, namely, working around the clock, is not used.
There seem to be some communication barriers between teams.
–– Analysis: It already emerged in the project management investigation that the
team setup has some potential. The two main factors here seem to be working
across time zones and a missing sense of cooperation between teams. There
seems to be a mix of management failure, misunderstandings, a lack of com-
munication, and a lack of trust, which results in silos and bad moods.
–– Action L: Continue the brainstorming from Action I to improve the team
setup, but integrate the topic of cooperation into it.
–– Action M: Sit together with line managers and stakeholders and address lack
of cooperation throughout the whole team. Find a way to bring teams together.
Consider team-building events and make sure that communication in general
receives an increased focus. Determine the targets, who is responsible for
what, and who has achieved what and so on. Try to get everyone on board to
improve the situation and increase motivation to be successful in the over-
all setup.
–– Action N: After improving the situation, you should check whether enough
resources are on board. Does the improved setup compensate for the
previously noticed delays? If more people are necessary, sit together with
management and discuss it.
Of course, Action M is something for the line managers rather than for a task
force leader or a system architect, but it is one of the most important points.
According to Lencioni [11], a potential root cause of scenarios like this is a lack of
trust among individuals in the team and in the organization. Thus, increasing trust
should cause everything else to fall into place.
Process:
• Request process descriptions for the development process, releases, bug fixes,
and feature requests. Let’s assume that you find a good description about the
development process. The individual project teams are on the way to increase the
Automotive SPICE level and have had several gap analysis sessions and improve-
ments. The middleware team is falling behind and does not have a clear release
and branching concept. Versioning and compatibility between releases seem to
be an issue. The customer project teams do not know exactly how to integrate the
middleware and what effort is required.
–– Analysis: The customer project teams are not in bad shape regarding pro-
cesses, but the middleware development is not aligned with it. Some pro-
cesses from this team are very specialized and work fine, but there is no
common ground between teams.
–– Action O: Identify a development process expert. Sit together with DevOps
and development team leads and discuss how to align processes.
–– Action P: Initiate a gap analysis to investigate the Automotive SPICE level
from the middleware development team.
With all actions from A to P, you should have a clear recipe for how to address
the first steps for the task force. Make sure to improve and complete the require-
ments and system architecture aspects quickly in order to have a solid foundation
for all following steps. Especially with the new planning and the org chart, you need
to go back to management and tell them about the outcome of your analysis.
Negotiate the target and the timeframe of the task force now that you have all of the
data available. Clearly state what kind of people are necessary to work on all of
these action points and which skillsets, roles, and responsibilities are necessary.
Agree on measurable success criteria for the task force. Prepare a kick-off meet-
ing – and then go for it.
2.6.2 Step 2: Execution Phase
Now it is all about executing your action items and seeing how the task force runs
as a project. Please remember what we discussed in the task force section above.
By now you should have clear criteria for how long the task force should run or
what the necessary outcome is to be able to stop the task force. Let’s assume that
you have negotiated a time-boxed approach. The task force should run for three
months and the results need to be improved project plans that clearly show how to
deal with and achieve the customer milestones as well as a final report about the
situation and what should be changed in the overall setup.
A path going forward could look like this:
1. Kick-off – Prepare some material showing the scope, timing, and team needs for
the task force activity. Invite relevant managers, stakeholders, and maybe archi-
tects and teams to present the material and let them know what the task is and
that you need a team now to work on the details. Make sure to tell a good story
not only to management but also to the individual engineers.
2. Team – The next thing is to negotiate with teams and managers who are the rel-
evant candidates for the roles of requirements engineer, system architect, and
middleware expert among others. All of the roles that you identified in your
preparation phase need to now be assigned to real people. Define a core team that
maybe consists of a project lead, a system architect, and a requirements engineer.
3. Meeting, protocol, and reporting structure – Set up regular meetings with the
core team and work out a protocol and reporting structure with them in align-
ment with management and stakeholders.
4. Refinement – In the first core team meeting, I would present and discuss the find-
ings and action points and collect further input from the team. I would also add
the creation of the final report as a dedicated action point to the list.
5. Action – Then, it is all about assigning tasks and working on the action points.
Your project manager should handle the task force itself as a project and manage
the action points like project tasks. Define, estimate, and track everything, and
report it maybe in weekly meetings to the stakeholders.
6. Targets – During the whole activity, it makes sense to have the final targets in
mind and to start working on them. You can start creating the master plan and the
final report very early on and add an increasing amount of detail during that time.
Of course, all kinds of things can happen during the execution. A main aspect
will probably be that you should not slow the development activities down. The
teams are already in trouble. Another aspect could be that you do not receive the
necessary resources. A clear escalation path should be in place, where you get help
from higher management. Alternatively, you might discover that 3 months are not
enough to fix all of the issues. As with similar project management tasks, work out
the possible options, and then go to the stakeholders and negotiate the best solution.
In my experience, a missing system architecture is the most common root cause
for projects in bad shape. So, you can also see that clearly in this example.
2.6.3 Step 3: Closing Phase
Finally, the 3 months are over. Let’s assume that you were able to improve the proj-
ect plans and the confidence level of the organization increased. Your task force
team worked on all of the action items. The protocols exhibit clear progress and the
closing of all items. All items were discussed with stakeholders and got a final
sign-off that they are finished. You should document all of that and add it to your
final report. It is recommendable to add a chapter for future tasks or changes based
on your findings. Thus, creating the final report is the last step before closing and
working on new projects.
2.6.4 Summary
In this part of the book, I described system architecture design for electronics devel-
opment. I presented the preparation and execution phase and ended with an example
to provide some more practical aspects. While the preparation phase mainly covered
requirements management and team setup, the execution phase covered the full
design process through various system layers, components, and interfaces.
I mentioned reuse and the need for platforms here and there. Maybe you already
got an impression of what role platform development might play in such an environ-
ment. As long as you have some similarities between projects, you will be able to
find reuse, and if reuse is possible, then you can save resources and work more
efficiently. In the second part of the book, I investigate the platform topic and deter-
mine what that means for electronic systems development.
Part II
Platform Development Strategies
Chapter 3
Platform Development Strategies
In the first part of the book, I described system architecture and the basic principles
of the design process. I mentioned platform development and reuse several times,
and I wish to describe this topic here in more detail. This chapter describes platform
development strategies in context of electronic systems development with focus on
reuse to increase engineering efficiency and quality. It covers several aspects such as
business case, time to market, team setup, and how platforms can be successful or
fail. It also covers the technical aspects of how to develop a technical platform regard-
ing hardware, software, and system components. Let’s start with the definition.
3.1 Definition
A platform is a structure that lifts one up and things can stand on it (Fig. 3.1).
Platform development is the creation of such a structure to enable things to stand out
and have a solid ground. A platform development strategy is a way to achieve the
goal of developing solid ground as well as things that stand out and can be reused.
It is a strategy and a process for how to develop things once and use them as often
as possible. Furthermore, it is a strategy of creating a standardized framework to
increase engineering efficiency and quality.
Platform development in this case does not mean that we want to develop one
single system as a platform. It means that we are developing with platform princi-
ples in mind. We use platform thinking, which can be a huge difference.
Let’s return to the example of a house from the beginning of the book. Let’s
imagine that we want to sell houses and there is a market for small houses of the
same size. Building a house needs to be divided into several parts. First, we need an
idea of what the house should look like and what features it should have. An archi-
tect needs to create detailed drawings and static models to make sure that the fea-
tures are integrated and that it does not fall apart when the entrance key is turned for

https://doi.org/10.1007/978-3-030-97695-8_3
84 3 Platform Development Strategies
Fig. 3.1 Platform on three pillars as solid ground
the first time. You need to find suppliers who can deliver or build the parts of your
house, and you need an internal design to decide which colors and materials your
applications should have, such as windows, stairs, doors, and floors. You can see
that I am already using electronic system phrases to describe this house.
If we want to sell those houses efficiently, we want to see where the hot spots in
terms of effort are. So, where do we spend most of our money to actually get it
done? We also want to find out which parts of the house are always the same and
which parts need to be customized. Let’s assume that we have three major topics:
the architect, the suppliers, and the actual construction.
How can we optimize all three points and have the most efficient development of
houses? Maybe we could create an architecture that is always the same but keep
applications such as windows and doors variable. Therefore, we design a clear inter-
face and a method for changing windows and doors according to customer needs.
Thus, we need to pay the architect once. Maybe we have only one supplier for all
different doors and receive a great discount. We have a good relationship with the
supplier and sometimes he delivers a special door for a small price, or he develops
a door especially for us that fits perfectly into our concept. Thus, we have a price
and feature benefit. Last but not least, we decide to build mainly using wood, and
we pre-manufacture all of the walls, floors, and the roof in a large factory – always
the same structure with different colors if necessary. Therefore, the main parts can
be transported to the location and built in 1 day by just clicking the walls together.
We had our best people sitting together designing this interface mechanism between
the walls, but now everything is solid and stable. Maybe some people will ask about
the quality of your wooden house. Your answer can be that you have built so many
houses with the same architecture that all of the growing pains are over already.
Ensure that the quality is as high as necessary and comparable to conventional
house building. Maybe you can build the basement in a traditional manner to have a
solid fundament and then everything on top of that using your new approach.
3.2 Why Platforms? 85
I hope that you get the idea. Of course, this way of building houses is well known
already and used frequently.
If we transfer it to electronic systems development, we would want to use the
term platform in a way that describes a specific way of thinking. We develop things
with reuse in mind; we develop things with maximum modularity and configurabil-
ity; and we develop standardized frameworks that allow building middleware and
applications on top of it that follow certain rules and interfaces. Then, we can make
sure that everything that has been developed can be assembled into new products in
any kind of flavor, like a Lego© system,1 where you have standardized building
blocks of different sizes, different colors, and some specialized parts. The standard-
ized framework is the interlocking mechanism with which you can connect every-
thing together as you like. You can visit LEGO City to see what is possible and have
a high reuse factor in all of your elements.
Platform development is also about creating reference systems. This is necessary
to prove the interconnection between components and a bigger picture and making
sure the components really work in a system context. Finally, it is about creating
processes around the development, the distribution of technology, and the mainte-
nance of components. This automatically implies an organizational and mindset
aspect of platform development. Usually it is worth thinking about change manage-
ment if you are introducing platform development in an organization.
So, maybe that sounds reasonable, and of course many companies are develop-
ing systems in this manner. But why is it always a challenge to introduce it in a
company? The answer is revealed on the following pages.
3.2 Why Platforms?
However beautiful the strategy, you should occasionally look at the results.
– Sir Winston Churchill
Former Prime Minister of the United Kingdom
What are the three secrets of the French kitchen? Butter, butter, and butter. What are
the three secrets of platform development? Reuse, reuse, and reuse. Perhaps this
isn’t a perfect comparison, but the main thing discussed on the following pages is
how to maximize reuse to increase engineering efficiency and quality. We also dis-
cuss when reuse is more efficient and when it is not. The system architect in the
previous chapters always has the choice between make, buy, or reuse. This is a
1
Lego – the well-known Danish company that produces toys consisting of interlocking plas-
tic bricks.
difficult choice and needs to be balanced carefully. Finally, I want to discuss the
preconditions for creating reuse. How much time and money do we need to invest
and how much efficiency do we gain from reuse later? Where does the efficiency
come from? Do we save time? Or do we also increase quality? And what does the
architecture of a platform that can be reused look like? What is a platform? What do
the hardware and software components look like? In addition, does that have any
impact on processes and organization? Do we need to create special teams and
departments for platform development? Do we need a special mindset in the com-
pany to be successful with this platform approach?
These are interesting and challenging questions.
Usually, companies think about platform development when they want to speed
up development cycles (efficiency); when they want to have consistent quality
across products (quality); or maybe when they want to scale the organization and
the one team doing it all doesn’t work anymore.
Before starting with a platform development, it makes sense to create a so-called
i.m.p.a.c.t. analysis. Finding out everything about the following points is essential
to make it successful:
• Investment – How much money is necessary to develop the platform?
• Market – What does the market for the platform look like? Is it only for company
internal reasons? Do you also want to sell it externally? What competitors and
suppliers are out there?
• People – Who is involved? What mindsets and cultures are we dealing with?
• Activity – What do the processes look like today and how would the platform
improve them?
• Customer – Who are the users and customers of the platform?
• Technology – What does the technology look like in detail?
This is also similar to a business model canvas where one wants to find out
whether a business can be successful.
If you have investigated all of these topics and answered all of the questions, you
should have a clear WHY for your platform, and maybe also a WHY NOT.
Make sure you understand that reuse and standards are the main technical aspect
of the platform. However, this can create several consequences like efficiency and
quality benefits. It also creates challenges like changing the way your engineering
team is currently working. A successful platform can also lead to a very powerful
product. Consider Apple’s App Store as an example. Apple created a standardized
development framework and has a very successful business framework around it.
The following sections can be divided into business aspects, technical aspects,
and organizational aspects of platform development. In general, platforms are of
course considered to make more money. We will also see what organizational
impact that has and finally how we can create a platform from a technical
perspective.
3.3 Business Aspects 87
3.3 Business Aspects
3.3.1 Initial Overhead, Payback, and Life Cycle
What does it cost to create such a platform? When can one expect an efficiency
increase? When does a platform really start paying back? What is the life cycle of a
platform and how long can a certain payback be expected? These are probably the
most important questions for engineering management. Does it make sense at all to
develop a platform? What is the motivation – engineering efficiency? Quality?
Stability? Time to market? Other strategic thoughts? Politics?
To answer these questions, we need to compare different development approaches
in terms of effort. Moreover, we need to see what kind of product portfolio we are
talking about.
Let’s start with a quick introduction to business calculations.
3.3.1.1 Business Case Calculations
Business must be run at a profit, else it will die. But when anyone tries to run a business
solely for profit, then also the business must die, for it no longer has a reason for existence.
– Henry Ford
Founder of Ford Motor Company
On the following pages, I want to compare profitability for different development

scenarios. To do that in a consistent way, here are some basic definitions.
Variables
Fixed costs – These are expenses a company has during the year that do not change
with products and sales volumes. Renting for offices or salaries are typical examples.
Variable costs – These are costs directly related to your sales volumes, such as
material or engineering services based on hours.
Volume – The number of sold units per year.
Price – The price per unit.
Calculations:
Variable costs = cost per unit × volume of units
Total costs = variable costs + fixed costs
Revenue = Price × volume of units
Profit = Revenue – Costs
In general, what is of interest to us to calculate a platform benefit is as follows:
Profit = Price × Volume of Units − Cost per Unit × Volume of Units − Fixed costs
We leave out any tax calculations or other things to make it as simple as possible.
Yet, we need another factor, which is the most crucial point here – the reuse fac-
tor! We will use that as a percentage. It indicates the amount of reuse we have for a
customized project compared with the content available from the platform.
Reuse factor – This is the amount of product development effort that is already
done by a platform development.
A reuse factor of 50% would mean that a product development team is spending
50% effort for a 100% product; 50% is realized by reusing what is already available
without any additional effort.
Now we are prepared for further calculations, so let’s start with development
efforts. We define the development approach first as follows.
3.3.1.2 Sequential Development
Before a team starts thinking about reuse, it usually develops sequential products.
When a company is small and only one product is developed at a time, the necessity
for platform development is probably not yet there. So, there might be only one devel-
opment team creating one product after another. The team perhaps reuses what they
have created in the previous project by copying and pasting, or the products are so
different that even copying and pasting is not possible. We call this sequential devel-
opment and assume it to be a first evolutionary step of a development team (Fig. 3.2).
3.3.1.3 Sequential Development Effort
Let’s assume this team is developing a small device that has some interfaces, a
microcontroller, and maybe a user interface. Therefore, they need to develop sche-
matics and a layout as well as produce a PCB. They also need to write software for
the microcontroller. Everything is packaged into a small plastic box with some con-
nectors for power and the user interface. We assume a development effort ratio
between hardware, software, and mechanics of around 2:20:1 to develop the full
product. For example, if the hardware development needs 3 man-months, the soft-
ware needs 30 man-months, and the mechanics part needs 1.5 man-months. This
results in an overall engineering effort of 34.5 man-months. You will find similar
Fig. 3.2 Sequential development

ratios in your industry or company, and usually it helps to create a very high-level
effort estimation or to double check the numbers provided by different departments.
Let’s assume all kinds of tests and validation are already included in those numbers.
This is just a rough guess to have some numbers to play around with.
If your company is running the abovementioned serial development and you
want to launch a product every year, the engineering plan looks very simple: 34.5
man-months spread across a year means 2.875 developers in the team. The majority
of it is software development. Let’s say two software developers and one more per-
son doing supplier management for hardware and mechanics engineering services,
assuming there is no communication overhead to keep the calculation simple. We
also assume manufacturing to be outsourced with a relative cost factor of 10%.
With these three engineers, one product can be developed per year, assuming that
they always start from scratch and have no reuse of previous products. That might
be the case if they never use the same microcontroller and the interfaces are always
different. The housing also looks always different, or for some reason you change
the development team with every product, and thus, all three engineers need to start
from scratch again and again.
Another thing to consider is the material price (variable costs). Let’s say it is $20
and we sell the product for $27 with a profit of $7. We have a market where we can
sell 100,000 pieces per year over a lifetime of 3 years. Let’s also assume that your
engineers are on an architect level with a salary of approximately $10,000 per per-
son and per month. Here, we also leave out differentiating between salary and real
costs for the company. We also assume that renting offices is independent of the
development approach and we can leave it out of our calculations.
For other departments, let’s assume the following:
Marketing/Sales: One person at the beginning, maybe also on $10,000 a month.
Later around 10% of revenue (9.7% from The CMO Survey, February 2018) includ-
ing costs for sales channels.
Management: We assume one manager with a monthly salary of $20,000 a month.
We leave everything else out to simplify the calculation and can delve into the
details as follows:
First year, investment phase
Engineers: 3 × $120,000 = $360,000 yearly salary, developing the first product
Management/Marketing/sales: 1 × $240,000 + 1 × $120,000 yearly salary
No revenue yet. Total cost: $720,000
Total profit: −$720,000
Second year, first product out in the market
Engineers: $360,000, developing the second product
Management/Marketing/Sales: 1 × $240,000 + 1 × $120,000 = $360,000
Manufacturing: 10% of $20 per unit = 100,000 × $20 × 10% = $200,000
Sales: 100,000 pieces for $27, variable costs 100,000 × $20 resulting in a profit of
100,000 × $7 = $700,000
Total profit: −$220,000
Third year, first and second product in the market

Engineers: $360,000, developing the third product
200,000 × $7 = $1,400,000
Total profit: $280,000
Fourth year, also third product in market
Engineers: $360,000, developing the next product
300,000 × $7 = $2,100,000
Total profit: $780,000
We leave out any salary increases here and assume it is all running successfully
without any issues or additional costs. This is of course a bit of an ideal situation,
but we want to use these numbers for a comparison with platform development
(Fig. 3.3).
From now on, we cannot expect further growth because of the 3-year life cycle
per product. We assume that we always have three products in parallel. We have
taken everything else out of the equation here and assumed it to be constant.
3.3.1.4 Parallel Development
Now let’s assume the number of projects is increasing, the company is successful,
and many projects need to run in parallel. That means different teams need to work
on different projects in parallel and the reuse between the teams depends on several
Fig. 3.3 Sequential development profit

Fig. 3.4 Parallel development
factors. It could be quite challenging if the teams are distributed around the globe,
all start fresh, and all want to create new things. Therefore, potentially they all start
from scratch and invent the wheel repeatedly. This might happen when a company
becomes more successful and projects increase with products and customers around
the globe, or developing in that way might be chosen on purpose. We call this paral-
lel development and assume it to be the second evolutionary step for a development
team (Fig. 3.4).
3.3.1.5 Parallel Development Effort
Fast forward to this situation: Your company is still developing products comparable
to the serial development phase but on a global scale, and you have a solid market
share and much more is going on in parallel. You are increasing your company size
at a crazy rate either through hiring more engineers or simply buying other compa-
nies to extend your engineering force and product portfolio. You are in the above-
mentioned parallel development mode. We assume that you have had no chance yet
to define global standards. Platform thinking starts to grow but is not fully estab-
lished. Let’s assume that you have 27 engineers globally, and all are working on
similar products with similar effort. They are managed by three managers, and mar-
keting and sales is approximately 10% of revenue. You have 27 products out in the
market, and they all have a lifetime of 3 years as above. We simplify here as much
as possible again to be able to compare the different development approaches.
Let’s assume that the company is 10 years old and you cannot really speak about
an initial investment anymore. Your engineers receive a monthly salary of $10,000
as above. Therefore, the calculation is as follows:
10th year, parallel development, 27 products
Engineers: 27 × 12 × $10,000 = $3,240,000
Management: 3 × 12 × $20,000 = $720,000
Manufacturing: 10% of $20 per unit = 2,700,000 × $20 × 10% = $5,400,000
Fig. 3.5 Parallel development effort
Marketing/Sales: approximately 10% of revenue = $7,000,000

Sales: 2,700,000 pieces for $27, variable costs 2,700,000 × $20 resulting in a profit
of 2,700,000 × $7 = $18,900,000
Total profit: $2,540,000 (Fig. 3.5)
Compared with the aforementioned approach, the company has scaled success-
fully and increased its profits from nearly $0.8 M to approximately $2.5 M. Again,
this is a simplified calculation.
Yet, how can we make more profit or develop in a more efficient way? How can
we improve the overall development? Let’s discuss platform development.
3.3.1.6 Platform Development
The interesting part is the third evolutionary step – platform development! In this
case, one central team cares about the overlapping and generic part of all projects
and delivers them to customer project development teams so that they can customize
and release them. The platform team creates, for example, a fixed-release cadence
with aligned milestones and features, and the customer teams have the choice of
using whatever release fits their individual development plan best (Fig. 3.6).
This is an improved strategy for ensuring that the reuse is maximized. Everything
that can be reused is developed in a centralized manner from the platform team, and
the customer projects can integrate and add their customer-specific part to it. The
challenging part here is to make sure that all customer milestones and product
release milestones are met and that the content of the platform releases fits all cus-
tomer projects. The size of the platform team is also crucial. They are doing the
majority of work and should be comfortably staffed; otherwise, the customer teams
would not get what they need in time and potentially break out of the platform
approach, leading to a situation where the development approach falls apart and
becomes inefficient. Furthermore, the project management between the platform
Fig. 3.6 Platform development
team and customer project teams must be highly structured and disciplined. It is all
about delivering in time. In the automotive industry in particular, where fixed SOP2
dates are used, holding the milestones is everything.
3.3.1.7 Platform Development Effort
In the abovementioned situation of parallel development, the engineers quickly

come up with ideas for improvement. They don’t want to reinvent the wheel repeat-
edly. For them it might be annoying that they spend effort on implementations that
already exist elsewhere in the company.
Thus, we consider two things that need to change: (1) we reorganize the global
engineering team, and (2) we create architectures following a platform thinking
approach. Which one comes first? Let’s see below.
There are two possible targets that the management team might have in mind.
Either we optimize the engineering efficiency to reduce the number of employees –
the same result with less effort and better profit – or we optimize to have more out-
put with the same capacity – more results with the same effort and faster time to
market. Guess what – we go for growth and keep the engineering team constant.
Let’s assume that we have three different development locations such as the
United States, Germany, and China. We still want to have the same number of engi-
neers, and we are ready to invest for a platform approach with an initial overhead.
Let’s assume that we have three teams in each location, summing up to 3 × 3 × 3 = 27
engineers. Our goal is to reduce the effort down to 50%. We want to have pure
2
SOP – start of production. The point in time where car manufacturers start to produce a specific
new car model in their factories
product development in two locations and a platform team in the third location cre-
ating the key platform components and reference systems with one additional team.
We also assume one platform integration engineer per product development loca-
tion. This potentially results in four teams in total covering all products. The plat-
form team prepares the key components, while one team per location is enough to
develop at least nine products in parallel. Nine products per location result in 27
products in total.
Let’s also assume that the platform team consists of one engineer per engineering
discipline plus a project manager and that they need around 1 year to develop the
platform, perhaps slightly more to cover the architectural overhead. We compensate
these three engineers that we have taken out from regular development with con-
tractors per location.
First year, preparing the platform initiative
The management decided to invest in a platform approach. Engineering promised to
get it done with three additional engineers, and they need 1 year for development,
which is equivalent to the regular product development effort. The best hardware,
software, and mechanics engineers are taken out from the global team to create the
platform. The vacant positions are compensated with external contractors for a
slightly higher price such as $11,000 per month. A project lead is hired by contract
for $15,000 a month, and a technical writer comes on board shortly before launch-
ing the platform, costing around $8000 per month. Furthermore, a tools and integra-
tion team is necessary, which is compensated with another three engineers. This is
just to have some numbers available.
We assume that engineers for compensation need around 3 months for ramping
up. Therefore, the platform development starts with ramping up three engineers for
compensation.
In addition, we are preparing the launch of the platform after 1 year. A good
transition might look like this:
• Six months before the launch of the platform, you hire three more contractors to
compensate the tools and integration effort. They are integrated into the develop-
ment teams per region and ramp up for 3 months.
• Three months before the launch, the new contractors are ramped up and three
engineers are selected as platform integration specialists per region. They join
the platform team and after quickly training help to finish the platform. These
additional 9 man-months also compensate for the architectural overhead in
development.
• Also 3 months before launch, you hire a contractor for creating documentation
and training material. He or she starts working after quick ramp-up planning to
be ready 1 month before launch.
• One month before launch, you start an intensive training phase to ramp up the
global team. This slows down development slightly, let’s say by 0.5 months.
The company is still able to develop and produce all 27 products in parallel, but
you have an additional cost impact of six engineers, one project lead, and a
tech writer.
To synchronize with the development cadence above, we assume that the first
three engineers are ramped up in the last 3 months of a year. This increases costs for
3 × 3 × $11,000 = $99,000. The overall profit goes down from $2,540,000 to
$2,441,000, which is approximately 3.9%.
Second year, starting platform development
In the second year, the three contractor engineers and the project lead are working
full time. The internal platform team has started development. The other three con-
tractor engineers for tools and integration start after 6 months and work half a year
full time. The technical writer starts after 9 months and works full time on docu-
mentation. This results in the following costs:
1 × 12 × $15,000 Project lead

+ 3 × 12 × $11,000 Contractor engineers, development
+ 3 × 6 × $11,000 Contractor engineers, tools & integration
+ 1 × 3 × $8,000 Technical writer
= $798,000
The profit reduces from $2,540,000 to $1,742,000, which is equivalent to a loss

of nearly 31%. This is significant and requires a clear strategy.
Third year, platform available
The first generation of the platform is finished and ready to be integrated into prod-
ucts. A reuse factor of 50% is considered. The regular product development was
delayed by 0.5 months for training and the rollout of the platform.
The organization needs a slight change in the global engineering team to handle
the rollout. A good transition might look like this:
• When launching the platform, the integration specialists go back to their regions
and support the integration.
• Furthermore, the teams need to be reorganized to be able to integrate and config-
ure the platform content. This means that you have a hardware team, a software
team, a mechanics team, and an integration team per region. The engineering
team is able to integrate and configure the platform content and also add
customer-specific content to it. Let’s assume that this delays the overall develop-
ment by another 0.5 months.
• To be on the safe side, you want to keep all three platform engineers for feature
add-ons, change requests, bug fixes, and general maintenance for the whole year.
Moreover, the project lead continues to handle ticket systems and change con-
trol boards.
• The three engineers who compensated for the integration effort might continue
for a further 3 months to have a transition time and ramp down afterward.
• A dedicated tools specialist is working on development tools and IT-related

issues and is an additional contractor for the platform team with a salary of
$11,000.
• The technical writer has created a solid fundament and can hand over to internal
engineers for incremental changes. He continues for maybe 5 months in the third
year until his contract ends.
The support from external contractors in the second year sums as follows:
1 × 12 × $15,000 Project lead

+ 4 × 12 × $11,000 Contractor engineers, development and tools
+ 3 × 3 × $11,000 Contractor engineers, integration
+ 1 × 5 × $8,000 Technical writer
= $847,000
Additionally, we have a delay for new product launches because of training and
reorganization. That is, 1/12 of the profit of nine new products: 9 × $700,000 /
12 = $525,000 loss in the third year.
Now, the interesting thing is how much we gain from platform development?
How much reuse can we expect and how is that reflected in the profit numbers?
For the calculations here, we want to assume a reuse factor of 50%. This means
that we are using 50% content from platform development, while the customization
part needs the other 50% of effort. Thus, we are saving 50% of the engineering costs
and can have these people working on something else. Our regular product engi-
neering team still consists of 27 engineers, and if we reduce the effort by 50% we
save 27 engineers × 12 months × $10,000 × 50% = $1,620,000.
The overall profit decreases by $847,000 + $525,000 = $1,372,000 from
$2,540,000 to $1,168,000, which is a reduction of approximately 54%. At the same
time, we gain $1,620,000 and increase to $2,788,000, which is equivalent to an
overall increase of approximately 10%. You gain this money if you fire half of the
team and save the cost for salaries, or as we decided above, you have half of the 27
engineers free to work on something else, which creates another revenue stream.
Last but not least, you might use the free engineers to accelerate your development
and have a faster time to market. I investigate this point again later.
Fourth year, platform maintenance
The platform has increased maturity, and the platform development team can be
reduced to a pure maintenance team. We assume that it is possible to cut it in half.
We also assume that the development delay is compensated in the meantime by the
free resources we have gained by platform reuse. Thus, the effort for the platform is
reduced to approximately $350,000, which is the only decreasing factor. The profit
calculation is as follows:
$2, 540, 000 − $350, 000 + $1, 620, 000 = $3, 810, 000
This is an increase of 50% compared with the pure parallel development, and we
have not yet considered that half of the teams are working on new products, which
might increase the overall profit again. Therefore, this calculation is in reality
assuming a reduction of the team by half.
If we assume that half of the team can create half of the $2.5 M profit from paral-
lel development, we can add nearly $1.25 M to the profit calculation:
$2, 540, 000 − $350, 000 + $1, 250, 000 = $3, 440, 000
This is equivalent to an increase of approximately 35%. This can be expected

after a 3-year development cycle where 12 or 13 new products are fully developed
and in the market. It is an ideal case of course, leaving out many other factors.
In larger companies, where we are not talking about the whole engineering com-
munity but only about certain projects, there is a clear benefit from using fewer
engineers for the same project result. Figure 3.7 shows the profit decrease during the
first 2 years and the benefit that starts to be effective in the third year.
What have we learned from these calculations?
• The most important factor is the reuse factor. It creates the greatest impact in the
overall calculations. Below, we will see in further diagrams how it changes the
calculations if varied between 10% and 90%.
• A rule of thumb could be that an initial investment of one additional development
team for a doubled timeline results in an overall profit increase.
However, some strong dependencies need to be discussed further. As mentioned
above, we want to vary the reuse factor and see how it impacts the overall profit after
6 years compared with the initial state. Let’s work with 6 years because then the free
engineers have 3 years to develop completely new products and bring them to
the market.
Fig. 3.7 Platform development effort

Fig. 3.8 Profit increase based on the reuse factor
The initial profit is $2.54 M, as above, and the reuse factor varies from 0.1 to 0.9.
Figure 3.8 plots profit increase in percentage compared with initial profit:
It can easily be seen that the profit increases on a linear scale. A reuse factor of
0.74 doubles the profit, while a reuse factor of 0.4 increases the profit already by
50%, which is a solid number with feasible reuse in platform and technology. The
gradient of the linear curve depends on the product margin. This is the profit per
product. It can be seen that platform reuse is more beneficial for products with low
product margin than it is for high product margin.
These numbers are of course only tendencies. The overall effort for platform
development needs to be estimated carefully. In my experience it needs around 10%
additional effort to develop with platform thinking in mind.
3.3.1.8 Life Cycle
One more point must be considered, namely, the lifetime of a platform. In the exam-
ple above, there were product life cycles of 3 years; therefore, the platform would
probably also be able to live for 3 years. This means that in the worst case we need
to repeat platform development every 3 years again. Again in the worst case from a
resource point of view, we should just continue with the platform development
team. After finishing one generation of the platform, they could immediately start
with the next generation, or they could continuously update the building blocks of
the platform.
The following calculations assume a continuous platform development with a

separate team that constantly works on platform content. The difference from the
calculations above is that additional engineers are hired permanently and do not use
contractors. We of course have them constantly on board. To be comparable, we
assume a reuse factor of 50% as above.
Compared with the $11,590,000 from above, the total profit is $10,700,000,
which is still a great increase. The majority comes from reinvestment in new prod-
ucts and revenue streams. This means that, in any case, investing in a platform team
that continuously develops platform components pays back.
3.3.1.9 Maintenance Effort
One of the most important points in terms of costs is maintenance. Platforms cannot
be created, released, and shipped without further effort for maintenance. Bug fixes,
change requests, and feature updates must happen continuously. If everybody is
using the platform, the requirements will constantly increase and bug fixing will of
course continue. A platform maintenance team is required.
Here, different levels are also possible. We want to divide between further devel-
opment of features and change requests and on the other side pure maintenance in
terms of bug fixing, training, and integration support.
1. Constant growth – This approach is necessary if the platform needs to evolve. A
good example is porting to new processors or the need to always integrate the
newest key technologies, which change the frameworks. Here, more or less, the
full team is continuously necessary to keep the platform up to date as
described above.
2. Maintenance – This approach is sufficient if you can freeze the features and
architecture of your platform for a certain time. Then, new technologies can be
integrated using a defined standard that does not change anymore. Here, a small
team is necessary for some level of support and training.
3.3.1.10 Automation
Depending on the impact of platform development, it is more or less important to

automate tools and processes. Usually, build and test is a good target in software
development for automation. The more popular a platform, the more effort that is
required to maintain it. Compensating this effort with increased automation repre-
sents a good investment. Otherwise it might end up in unmanageable effort for the
platform team, leading to an increasing number of delays in deliveries. Then, the
platform would be perceived as slow and management will lose patience.
Fig. 3.9 Frozen platform release
3.3.1.11 Continuous Development
The aforementioned results indicate that there are two main possibilities for how to
continue after finishing a platform’s development.
1. Freeze platform architecture and features and keep a small platform team for
maintenance. This team is responsible for bug fixing, integration support, and
maybe also small feature add-ons depending on the effort. Product portfolio and
technology allow one to keep the architecture constant for a certain time
(Fig. 3.9).
2. Product portfolio and technology have certain dynamics that create the necessity
to continuously update and add new features. The platform team remains con-
stant and is probably split into a core team that constantly works on updates and
features and a maintenance team that cares about integration support and bug
fixes (Fig. 3.10).
In this continuous development, it is necessary to release with predictable cadence
to ensure that the customer projects can plan accordingly.
However, is this the end of the evolution? One further step could look like an
open-source model.
3.3.1.12 Open-Source Development
A fourth evolutionary step in development can be a step toward a company-internal

open-source model. This means that the platform development standards and gover-
nance are strong enough that engineers simply use the platform and respect it.
Everybody in the company’s engineering community contributes to the open-source
model, and the platform team is rather a team of architects and reviewers who
ensure that engineers stick to the standards and don’t break the system (Fig. 3.11).
Fig. 3.10 Continuous development with releases
Fig. 3.11 Open-source platform development
3.3.2 Time to Market
Another aspect of creating a platform is the time-to-market improvements that one

can get out of it. Imagine that 50% of your development is already done. Design,
implementation, testing, and documentation are completed for 50% of your new
product. The time to configure the platform and develop the other 50% is much
shorter and the effort much smaller than developing 100% of the product.
My experience from the automotive industry is that one can greatly impress cus-
tomers by showing up with 50% of a product already during RFQ phases. If they
can see that the highly complex system they have in mind is already alive to a cer-
tain extent, they will become excited quickly and your chance of winning the busi-
ness is very high. A precondition for that is of course that you have a fairly good
understanding of where the market is going and what the customers want, along
with which features, technologies, processors, protocols, and interfaces are coming,
giving you the chance to predevelop them before a customer requests them.
In other industries, such as consumer electronic devices, the timing factor is
crucial for being first to market among others. Timelines for development are rather
in the 6–12-month range compared with 3–4 years or even longer in the automotive
industry.
The calculations we performed above considered the same development cycles
of 1 year per product. However, it is of course also possible to use the efficiency
increase to speed up the product release time.
We saw that with a reuse factor of 50%, half of the team can work on something
different. That can of course also be to cut the development time in half.
Thus, to summarize we have three different choices of how to use the platform
development efficiency increase:
1. Fire half of the team and save the costs for salaries.
2. Use half of the team for new products and revenue streams.
3. Use the full team to speed up product releases, and put out twice as much prod-
ucts into the market.
The decision between the second and third choices depends on one’s products
and market. One or the other might make more sense from a strategic perspective.
The first option is probably the least attractive if you are considering growing your
company anyway. Here, I am also personally hesitant about promoting a solution
that leads to firing people.
Therefore, to increase the time to market factor, two choices exist:
1. Establish platform development and use the free resources to accelerate the
development.
2. Develop a platform with key elements and a good estimate for future product
scopes to have something done already before the first customer requests it.
3.3.3 Commercial Platforms
Today, the name platform is often used for commercial platforms such as Amazon
and Facebook. One of the main characteristics here is that someone has created a
system that everybody is using. It is a platform that connects suppliers and
3.4 Technical Aspects 103
customers or just people in a centralized and standardized manner. The owner of the
platform has created a set of rules and contracts and usually receives a large portion
of every single transaction that occurs on the platform, either directly as a percent-
age of prices or indirectly through the collection of customer data.
Apple’s App Store is a good example that is slightly closer to the platform
approach described above. Apple has created a standardized software framework
for apps and an approval process for people who want to contribute to the Apple app
market. Apple has full control and receives money for every single app published.
Another aspect of these platforms is of course the massive amount of data captured
during its use. Amazon can run statistics and machine learning algorithms on peo-
ple’s shopping behavior, leading to a completely new way of doing business.
Moreover, the individual customer is becoming increasingly transparent in all areas
of life. Amazon can compare a user with millions of other users and create strategies
for how to sell more. Owning such data is already key to making business today.
Please have a look also into the book Product Strategy For High Technology
Companies by M.E. McGrath [12] to see further examples.
The platform approach described in this book here is rather meant to be a
company-internal approach for increasing the engineering efficiency and quality of
development results. However, if your approach is so successful internally that you
believe other companies could be interested in using your platform, then you could
sell it as a product. Then, more strategies such as creating an industry standard,
dominating a market, applying new business models, and employing data collection
come into the game.
With this, I wish to finish describing the business aspects of platforms. With a
certain number of products, we have seen that it is beneficial to introduce platform
development. We have also seen that the reuse factor is one of the most important
aspects for making it commercially attractive. Let’s see what that means from a
technical perspective.
3.4 Technical Aspects
3.4.1 Key Components and Reference Systems
The technical aspects of platform development deal with architectures, frameworks,

technologies, components, standards, and processes to create reuse with the goal of
increasing efficiency and quality.
Let’s imagine that we are in the automotive industry and we target the head unit
market. We want to develop key components for navigation, multimedia, office use
cases, telephony, and connectivity among other areas. These components could be
mainly focused on the software side. We also want to develop hardware components
such as power supplies, processors and memory, interfaces, displays, amplifiers,
and much more. These components are all subsystems that again consist of several
modules and components. They can be hardware and/or software components. This
is one side of platform development.
The other side handles the topic of reference systems. It is important to make
sure that all of the key components work well together in a complete system and can
stand on solid ground – namely, the platform. One must prove to the rest of the
organization and potential customers that they can rely on all of the system compo-
nents, because they can experience and see them working in the reference systems,
which are tested to a certain extent. This could only be one reference system that
covers all components at once, or it could be several reference systems covering, for
example, different product levels, customer groups, or chipset families.
Finally, certain processes are necessary to develop platform components in a
standardized manner. A well-defined development process that is aligned with all
departments receiving the components is required. Then, processes are needed for
requirements engineering, project planning, releases, distribution, changes, moni-
toring, and maintenance of the technologies. A team of project managers, field
application engineers, and tool developers is required to support the distribution of
platform elements in the company.
Thus, the platform development consists of three main pieces: the development
of key components, the development of reference systems, and the processes around
them. All three elements have numerous dependencies and should be in one organi-
zation, in one department. This will enable short communication paths and the
avoidance of handovers as much as possible. All of the engineers who work on key
components must also make sure that the components work in the reference system.
This will automatically increase their sense of ownership. They all work in a stan-
dardized way according to the processes.
Figure 3.12 is a diagram that illustrates the context of platform development as
well as how the organization might look. The innovation and technology part in the
diagram is coming from outside of the platform organization. This can be the case
but is not urgently necessary. Innovation and key components could also be in the
same department. This depends on the size of your organization and also on the
characteristics of the key components. Innovation and technology development
Fig. 3.12 Essential platform parts

need to be investigated separately and depend on company size, product portfolio,

business, and industry.
The diagram also shows that products are outside of platform development,
which is usually necessary. The platform department creates generic functions with
a high reuse factor. All of the customization must be done in the product develop-
ment departments. Not all of the little details and adaptations can be managed in the
platform team. They need to be managed in the product development outside of the
platform. However, the platform approach must be configurable and adaptable
enough to cover all requirements of the product development, or the platform can be
extended so that customer-specified elements can be added easily. Again, this
depends on factors such as company size, products, and the market. It could also be
the case that the platform team is responsible for integrating their components into
final products.
What else characterizes a platform? What else makes a platform successful?
First of all, it needs to be easy to use. Developers should not require major effort
to ramp up their understanding of how to develop in the frameworks and with the
platform. Clear, easy-to-use templates and examples should make life easy and
ensure a quick start for all developers who want to contribute to the platform. A
proper set of training material needs to be available. This is part of the processes.
Second, stakeholders and technology evangelists must promote the platform. A
certain traction and momentum are required to make others want to jump on the
train and use it. This is the processes, organization, and also politics in the company.
Third, it needs to be easily configurable such that many products can be made out
of it. It needs to attract developers, third-party suppliers, customers, and consumers
at the same time. Customization needs to be as easy as possible. Finally, the features
of the platform need to meet the majority of requirements from customer projects.
These are the technical aspects.
To summarize, I present my four principles of platform development (Fig. 3.13):
1. Reuse – the main driver for this type of platform is reuse, which increases effi-
ciency and quality.
2. Easy – the platform needs to be easy to use and easy to configure.
3. Momentum – the platform requires momentum to attract developers, customers,
and suppliers.
4. Fit – the platform needs to fit the future product and technology portfolio.
For the following technical aspect, we work through the V model.
3.4.2 Platform Requirements
Let’s first look into the platform requirements. We also follow the V model here to
describe what we want to achieve first. How do we know what needs to be part of
the platform? What requirements do we want to cover with it?
Fig. 3.13 Four principles of platform development
The answer is as follows: a good overview of past products, future products,

potential new technologies, and innovations is required. Then, similarities between
all of these products should be found using a project comparison table, such as the
one mentioned earlier in the first part of the book. Listing all of the high-level fea-
tures for hardware, software, and system in the table will create a broad overview of
what is required immediately and in the near future. Use all of the data available
from products currently under development, from RFQs and from RFIs. In addition,
see what the predevelopment departments are developing right now. Maybe these
things will lead to special requirements for your platform. Furthermore, investigate
what is happening on the market – which technologies are available and on the
roadmaps of suppliers and competitors. All of this internal and external research
might create an overview of what your next generation of products may look like.
Find similarities and create an architecture and framework around them. The frame-
work needs to be modular, configurable, extendable, and easy to use. This approach
can ensure that future needs are covered as well as possible. The overlapping part of
all of these features creates a nice set of requirements that are the base for your
platform design. Let’s look into reuse opportunities in slightly more detail.
3.4.3 Reuse of Components
How much reuse is possible? What technologies and key components do you con-
sider part of the platform? The ultimate question leading to the abovementioned
reuse factor is as follows: Where should you draw the line? What is platform- and
what is product-specific? What increase in efficiency does the reuse factor create?
3.4.3.1 Levels of Reuse
Let’s start with the question of efficiency increase. This is not easy to answer and,
as I stated above, the cleverest guys in the company are needed to create the right
level of reuse and define where to draw the line. I have defined six levels of reuse
that could be considered in your development:
• Level 0 – Experience Reuse:
For some reason, you have no chance of reusing any kind of software or hard-
ware modules. The least that you can do is to keep the teams stable and retain the
experienced people in your company. Then, at least you will be able to reuse their
experience.
• Level 1 – Concept Reuse:
This is similar to experience reuse but at least with documents and diagrams
describing your architectures and concepts on a higher level. You can reuse those
concepts and potentially need to always start the implementations from scratch.
• Level 2 – Reference Reuse:
The major hardware and software implementations can be reused. Reference
implementations exist, and development teams have the freedom to change what
is necessary for customer-specific functions. Hardware comes with schematics
and a reference design. Software comes with reference or example implementa-
tions and descriptions of how to use them. Creating a new product might be
copy-and-pasted from previous implementations or from reference designs.
There is no guarantee of quality from examples and reference implementations.
• Level 3 – LEGO© System Reuse:
Hardware and software are developed like LEGO blocks and exist in compo-
nents and building blocks. Software components exist as, for example, libraries,
header files, and configurations. Hardware exists in fully defined reusable blocks
with fixed schematics and layout. Software and hardware interfaces are standard-
ized, and the components are embedded in well-defined frameworks so that the
blocks always fit together easily. Build systems, integration, and test-and-release
processes are standardized so that technology can be exchanged globally if nec-
essary. The quality of components is guaranteed and increases over time
automatically.
• Level 4 – Plug & Play Reuse:
A system is changed by installing or uninstalling software functions. Hardware
modules can be plugged in and out with automatic software driver management.
Hardware and software are highly standardized and modular so that add-ons
work like a plug & play system.
• Level 5 – System Reuse:
A complete system can be sold to another customer by only changing some con-
figurations or tunings, or changing the color or the brand. No hardware, software,
or mechanical changes are necessary.
These six levels cover the range from minimum to maximum reuse. Which one
to use depends always on architectures, products, and technologies and must be
evaluated case by case.
3.4.3.2 Methods of Reuse
I also want to introduce two different methods of reuse:

1. Opportunistic reuse – only looking backward:
If a new system development is on the agenda, just look into the past and see
what similar projects have been developed. Find similar modules and compo-
nents and try to reuse them.
2. Planned reuse – looking into the future also:
Anticipate the similarities that exist in all of your projects, including future
products. Find out what modules and components have a high overlap between
projects and need to be used repeatedly. Create a framework around them, make
them as modular and configurable as necessary, and plan to reuse them as often
as possible.
The latter method obviously comes with an initial overhead because you need to
prepare your whole development to handle future reuse. This is the interesting
method that we discuss further here.
3.4.3.3 Rules of Reuse
Let’s assume that we decide to have a planned reuse and should now follow certain
rules. Develop according to the following criteria:
• Modularity:
Components and functions are modular so they can be assembled and reused
depending on requirements. The granularity of these modules is a critical topic
and requires careful investigation.
• Scalability:
Components and functions can be scaled up or down to support more or less
complex systems and consume system resources accordingly.
• Configurability:
Components and functions are compiled once and can be adapted by external
configurations. Thus, the core function always remains the same, while the
behavior is defined by the configuration.
• Portability:
Software components, functions, and applications in particular are divided into a
generic and hardware-independent part and a hardware-specific part that can be
easily exchanged when ported to another processor or operating system.
• Extendibility:
The whole architecture must be created such that it can be extended easily.
Modularity already helps in this, but it needs to be easy to add components, func-
tions, and parts into it for future requirements.
• Testability:
Components and functions can be tested independently following a hierarchical
approach from unit to integration to system testing. This ensures the delivery of
reliable subparts into a larger system.
• Component-based:
Components and functions follow an internal standard according to an aligned
framework. Standard interfaces and communication work together without addi-
tional effort. Proper encapsulation ensures multi-instantiation capabilities.
• Centralized:
Components, parts, and functions are stored and managed in a central system to
ensure the wheel is not invented several times in always slightly different flavors.
This also ensures that the invented wheel is not reused in an uncontrolled manner
in all corners of the world with no idea of what changes are made elsewhere.
Thus, you can see a technical and architectural aspect as well as a development
process aspect. Both parts create the solid ground that other things can stand on it,
and both need to be considered to create an initial overhead to develop and estab-
lish reuse.
3.4.3.4 Benefit of Reuse
We calculated earlier that the reuse factor is the most important factor when it
comes to profit benefits. Depending on the level of reuse, the overhead of creating a
flexible architecture is either larger or smaller. Figure 3.14 illustrates the general
tendency:
Here, with increasing reuse, the architectural complexity as well as the develop-
ment time for a pilot project can be seen to increase. This means that the effort is
increasing. On the other side, the development costs per repeated or similar product
decrease with higher reuse levels. The reuse levels between 2 and 4 are perhaps the
most interesting – I call this the region of interest.
3.4.3.5 Draw the Line
The most important decision for platform development is where to draw the line. All
of the aforementioned strategies, such as reuse levels, methods, and rules, need to
be considered when deciding what is part of the platform components and what is
not. This is a very individual thing and needs to be evaluated case by case, team by
team, and technology by technology.
Through a detailed investigation, an overview can be created of all of the aspects
of development that might be relevant for platform strategies and reuse. Some things
Fig. 3.14 Reuse vs. effort
might be obvious, such as the same components being developed several times
repeatedly in different departments or a certain feature being required in all future
products. Some other aspects might require a more detailed investigation and a
higher-level technical strategy, such as choosing a certain processor family for all
products globally.
Furthermore, it is also clear that creating reuse needs to be established in all of
these departments and is more or less relevant for the whole company. Every depart-
ment might draw the line differently for good reasons. All of these aspects should be
considered when creating a company-wide technical strategy where platforms are a
fundamental aspect.
3.4.4 Strategy and Innovation
Why do we also need to discuss technical strategy and innovation here? Isn’t the
architecture design and platform development occurring in development phases
later than ideation sessions and brainstorming workshops? Yes and no. Let me start
with technical strategy.
3.4.4.1 Technical Strategy
We defined the term technical strategy already in the first part of this book. As
already mentioned there, it could be a strategic decision to use as much as possible
from an existing platform development in the company for future products. It could
also be an effective strategic decision to ensure that every innovation uses the
platform frameworks and processes as early as possible, thus making it easier for
the later industrialization of those innovations. What does this mean exactly? Let’s
look a little deeper at innovation development processes to understand this.
3.4.4.2 Innovation and Technology Development
The teams and colleagues I worked with, it was always the same: the engineers
always had a certain hunger for new topics. Many people wanted to work on innova-
tions. In reality, only a small percentage of our engineers had dedicated roles work-
ing on innovative topics, but all of the others also had great innovative ideas while
working in platform or product development.
I think that this is the nature of engineering. Every engineer is also an inventor,
and we should give everyone the chance to contribute to the company’s innovative
power. By the way, this is an approach that Mark Randall from Adobe established
quite well with his Kickbox concept,3 where engineers are given some tools and
$1000 to start an innovation. If they are able to sell it in the company and it survives,
then it is deemed a good innovation.
However, let’s go back a little bit and look at it in a more systematic way.
Innovation always starts with questions and ideas. There are several methods,
tools, and processes concerning how to create ideas and the right questions. The
common understanding is that quantity is key for ideas at the beginning. It is not
easy to ask the right questions, but that is also well-established with tools and pro-
cesses that are out there.
Then, we need a fast evaluation of those ideas and to filter what makes sense to
pursue further as well and as quickly as possible. This filtering could be based on
technical feasibility or business aspects, or it could be driven by user/customer feed-
back and processes such as Design Thinking.
The most promising ideas can lead to feasibility studies, early prototypes, simu-
lations, or similar realizations with the goal of performing some early tests. Actually,
the Design Thinking process is a nice tool for speeding up prototyping and creating
first test cycles. One could easily have a paper prototype in hand after 1 day to play
around with.
Up to now, we have not spent much effort. Perhaps the whole ideation and design
thinking process is part of a week-long workshop within a team of 10–20 people.
Now, we need to make sure that we check facts and figures.
The next step could be a thorough market analysis to check the business potential
of the new ideas. There is always a way to come up with some estimated numbers
and a rough business case. This is then a perfect input for your leadership team to
decide whether to invest in these ideas.
If you get a yes, an important part must be considered. Usually now the real pro-
totyping starts and some real demos are targeted as a result of the next phase. Here
at the latest, the platform comes into play. If you have the option of performing the
3
https://www.kickbox.org/
prototyping within the framework of your platform – do it! It will save so much
effort in the later stages. A simple example is hardware development. Let’s assume
that your predevelopment engineers are fresh from university and they are assigned
the task of designing a PCB for an innovative circuit. They could use a freeware tool
for drawing schematics and designing the layout or some other tool that is available
from their university. You might have difficulties afterward in transferring that into
your product development tools. They could also use the standard professional tool
in your company with all of the parts in the library so that a later transition into
product development is much easier. A precondition is that this tool is so flexible
that everything necessary for rapid prototyping can be performed. For example, you
want to be able to use parts that are not yet in the library if necessary.
Another nice concept is to rotate senior people from product development into
the predevelopment activities. This is usually fruitful because of their extensive
background and experience. Furthermore, it helps to introduce the product-relevant
frameworks and tools already in early stages.
The same is of course valid for software tools, frameworks, and processes. The
earlier the predevelopment technologies are embedded in the platform frameworks,
the easier it is later to industrialize them and make real products out of them.
This might also be beneficial for handovers between departments. If predevelop-
ment and platform development is split into two departments but they are working
with the same framework using the same platform standards, a handover is much
faster and easier than without.
The innovation process can go further and through certain phases with defined
gates and decisions. The earlier the platform frameworks can be used to create pro-
totypes, the easier it is to later transfer the development into a phase for industrial-
ization and product development. A precondition is always that the platform
frameworks are flexible enough and easy to work with. There should be no restric-
tions for the early prototypes.
At the same time, platform should be informed about what is going on in the
predevelopment departments to be able to prepare. New technologies might require
new frameworks, chipsets, or other system-relevant parts. The earlier a platform can
prepare for upcoming changes the better.
3.4.5 Software
Code reuse is the Holy Grail of Software Engineering.

– Douglas Crockford
Computer programmer and entrepreneur
Today, software development is always the largest part in complex electronic

devices, so it makes sense to focus on platform development especially in this area.
In my experience, the software development effort might be ten times higher than
the hardware development effort. I also used this ratio earlier for the business case
calculations.
Component-based development is well-known in the industry for creating reuse.
Therefore, this is definitely a good choice for structuring your development in
this manner.
However, software always needs a piece of hardware to run on, so this is the first
relevant thing for creating reuse. If it is possible to choose one particular processor
and stick to it, the reuse factor for embedded development will be high. If it is neces-
sary to support several processors, extra effort is required to create hardware abstrac-
tion layers and ensure that the software platform supports all variants.
The selection of an operating system is also a choice for a certain platform. If it
is possible to stick to one particular OS, the company needs to live with the depen-
dencies that accompany that decision, but it will ensure high reuse. If you need to
be flexible, you should create a good OS abstraction layer to reuse everything on top
of the OS.
This continues with software frameworks, communication protocols, program-
ming languages, and so on. It is necessary to clearly identify what the require-
ments and boundary conditions are and then find the overlapping and
reusable pieces.
3.4.5.1 Horizontal and Vertical Lines
The important aspect here is where to draw the line between platform components
and product-specific components. I introduce two types of lines that might be rele-
vant for software development as follows (Fig. 3.15):
1. Horizontal lines – two main lines can be drawn:
(a) Hardware/OS line: This line defines which components are hardware- or
OS-dependent and need to be adapted repeatedly if we are switching from
one processor to the other or from one OS to the other. Below this line, the
reuse is small and components might be excluded from the platform reuse
strategy. Above the line, there could be platform components that are generic
and can be reused repeatedly independent of hardware and OS details.
(b) User interface line: This line defines which components are part of the
graphical user interface and potentially different with every project and also
which components are below supporting generic functions and are poten-
tially part of the platform.
2. Vertical lines – These exclude certain features and applications that are not
platform-relevant because they are created for a single product only with no
reuse expected in other projects. This might also be an organizational topic
Fig. 3.15 Horizontal and vertical lines within software architecture
because the question is usually which department is investing in the development

of such a feature. Technically, the development must follow the platform rules
anyway to fit into the platform system.
3.4.5.2 Reuse Levels
The next aspect is the level of reuse. Component-based development is probably

somewhere between Level 2 (reference reuse) and Level 3 (LEGO© reuse). The
exact location to choose depends on the details of the development process.
For example, Level 2 reuse means the following:
• Software frameworks, protocols, modules, and applications exist as a fully func-
tional reference system.
• Software is created with reuse in mind to cover the majority of future projects.
• New project teams use the source code of the reference through copy-and-pasting
and can change and adapt wherever necessary.
• The reference system is well-documented, and the inventors have enough time to
support new integrations.
• The reference might be a platform project or a previous product development
project. A dedicated platform team is not urgently necessary.
• The teams copying the reference systems for products have a similar skill set as
the inventors and know what they are doing.
• Source code ownership goes potentially from platform team to project team by
copy-and-pasting or from project team to project team.
The following advantages and disadvantages can be considered.

Level 2 Pros:
• In general, a software platform is available and can have a high reuse factor.
• Customization can be fast and easy because project teams have full access to
source code.
• Individual optimization is possible.
• Debugging, bug fixing, and maintenance can be fast and easy for the same reason.
• A dedicated platform team is not urgently necessary. The platform might auto-
matically always be the latest product.
Level 2 Cons:
• Copy-and-pasting introduces various risks:
–– Changing the source code on the project side raises the question of ownership.
The inventors can’t be responsible anymore for changed source code.
–– The project teams need a full understanding and to take full responsibility if
they change the source code.
–– Performing bug fixes and feature add-ons on the project side introduces the
risk of many different variations of the same functionality. Integrating these
back into the platform becomes more complicated if the departments are
increasingly separated.
• The project teams need to have the full skillset and a high capacity to develop
and own the full software.
Level 2 reuse can work for smaller organizations where management has a good
overview of teams and products. The development process should be strict enough
to handle changes and bug fixes in a centralized manner. A special mindset of creat-
ing reuse and maintaining the platform would be great in the whole organization.
Management can help with a rotation concept, where engineers change between
platform development and project development on a regular basis.
Level 3 reuse is significantly different compared with Level 2 reuse. The organi-
zation has implemented a mechanism to centrally control all source code changes,
bug fixes, and add-ons. This can happen more or less in two different ways:
• Centralized repository: The reference source code is stored and developed in a
central version control system. The platform team develops, tests, and releases in
the system, and the project teams build directly from it. No copy-and-pasting is
necessary.
• Library deliveries: The reference source code is also stored and developed in a
central version control system, but the platform team is compiling libraries and
delivers them to the project teams. The libraries are tested and documented so
there is no need for project teams to change them. Versioning and backward
compatibility must be handled carefully.
This mechanism introduces the following advantages and disadvantages:

Level 3 Pros:
• In general, a software platform is created with high reuse.
• The source code is fully controlled in a centralized manner. There is no risk of
different variations and double effort.
• The ownership of platform components is clearly on the platform develop-
ment side.
• Considering that the inventors are skilled and motivated, the most efficient team
is handling changes and bug fixes.
• The product teams do not need a full understanding of the platform source code.
They are rather users integrating well-described functions.
• The libraries are fully tested and validated for releases. The product teams can
rely on a certain quality and do not need to be as highly skilled as in the Level 2
approach.
Level 3 Cons:
• There is a risk of an overhead to make sure the libraries are flexible enough to
cover all projects.
• The effort for bug fixes, optimization, and changes is completely on the platform
team side regarding what needs to be considered and planned accordingly.
Communication, timing, processes, and planning become more complicated to
support all different products.
• The inventors might enter the situation to perform bug fixes and changes now,
which is not particularly good for the highly skilled architects. An effective rota-
tion or handover concept might be necessary to motivate the whole engineering
community to maintain the platform.
Level 3 reuse might be better for larger organizations. It might be a good idea to
treat the platform team as separate suppliers to the project teams. They deliver
libraries, documentation, and integration support like a third-party supplier. Thus,
the platform team and the product teams have a customer–supplier relationship.
The next topic for software platforms is the rules for reuse described above.
Modularity, scalability, portability, testability, and configurability are the main
aspects that need to be considered.
3.4.5.3 Modularity
Modularity in software means having a strong concept about the granularity of

encapsulated functions. The granularity again depends purely on the potential reuse
in future configurations. If certain functions are necessarily repeatedly in different
applications, it might make sense to extract them, have them available only once,
and reuse them in different features and applications. An example could be a digital
signal processing filter that needs to be used in several algorithms. The finest granu-
larity could mean that you provide components for the low-level mathematical
functions, from which users can create the filter algorithm. The second granularity
level might be to develop the filter once and make it flexible and configurable, and
then users can create algorithms out of it. The filter is a standard module with a low
chance of many variations. A third level of granularity could be to decide to develop
this particular filter again for every single algorithm where it is necessary. This
might have optimization potential in terms of CPU usage or memory usage. The
whole algorithm is then the level of component granularity.
To decide the level of granularity, one must consider how the product teams will
use the platform, how much overhead might be introduced with certain levels of
granularity, and how much reuse can be achieved.
However, it is usually beneficial to have huge components, not as a monolithic
block but rather as encapsulated components that have the potential to be reused
elsewhere.
Here (Fig. 3.16), you can see that functions #1 and #2 have implemented the
same subfunctions B and D. In a nonoptimized version, they are implemented twice
and must also be maintained twice. Ideally they can be shared in a modular way and
instantiated as often as necessary.
Fig. 3.16 Modularity

Fig. 3.17 Scalability
3.4.5.4 Scalability
Scalability in software means that you can resize components to save resources
where they are not used. Again, I present an example from digital signal processing:
Imagine that you have an algorithm that runs calculations on different input chan-
nels. In your products, these input channels vary from low to high numbers. Also
imagine that calculation resources such as CPU and memory usage scale linearly
with the number of channels. It makes sense to create a component that uses
resources according to the number of channels. It would not make sense to create,
for example, a 32-channel algorithm and use it in a product only on 2 channels. That
would be a waste of resources because the calculation of 30 channels would con-
sume resources that are not necessary for the functionality of the overall system
(Fig. 3.17).
3.4.5.5 Portability
Porting software usually means reusing components and functionality in different

environments. In embedded development, this is usually dependent on the hardware
processor and the OS. Portability means creating software components that are easy
to move from one processor to another and from one OS to another. The closer the
software is to the hardware interfaces and drivers, the more relevant this question
becomes. A typical scenario is that software components access hardware- or
OS-related functions directly to work properly or in an optimized manner. Imagine a
driver component for a simple UART or I2C interface. At one point, the software
needs to access hardware registers to process messages. These hardware interfaces
might differ with every single processor family, and the software must be adapted
repeatedly. Here, it might make sense to create a hardware abstraction layer in
between to separate generic and processor-specific functionality. The generic part
would be developed once and remain the same across processors. This is the plat-
form component that can be reused! The processor-specific part is much smaller than
the whole interface driver and must be adapted with every single processor (Fig. 3.18).
The hardware abstraction layer means extra development effort and possibly also
extra processor resources such as CPU and memory, but the overall reuse of the
component is increased.
Portability is not only relevant for hardware- and OS-related topics but also for
interfacing to the graphical user interface, to specific protocols, to development, and
Fig. 3.18 Portability through abstraction layers
to debugging systems among others. All interfaces of a component that might

change from one project to another might require an abstraction layer. Deciding
whether to create such a layer is always a balance between development effort and
reuse benefit.
3.4.5.6 Extendibility
Another crucial aspect of platform development is future proofing, which is usually

possible to a certain extent. Software languages do not change drastically. A com-
mon understanding of software architecture and design patterns is quite mature, and
something created today has a good chance of surviving for the next 5–10 years at
least in the embedded electronics world. It is worth thinking about what might hap-
pen in the future and how an extension of the software can be achieved with the
architecture that has been created today. The architecture quality of software frame-
works plays an essential role in ensuring that new functionality, protocols, and
applications can easily be integrated so that the platform software is extended and
can survive another round of generations. The aforementioned topics such as scal-
ability, portability, and modularity of course play into this topic. If an analysis of
past results in an overview of the changes in this part of the software as well as an
analysis of potential future changes result in certain requirements, then there is a
good chance of creating something that is future-proof enough to invest in and gain
reuse, thus increasing the overall efficiency of the software development over time.
One of the bestsellers describing design patterns and how to create reusable code
is the book Design Patterns from Erich Gamma [13].
3.4.5.7 Configurability
Configurability means creating generic components for different use cases and cre-
ating an architecture that ensures configuration from outside the software compo-
nent, which you do not want to touch again. Compiling a component into a software
library is usually a factor in the overall development process that might decide
between different reuse levels or how to interface between different departments in
the company. Or, it might be the case that you don’t want to touch the components
anymore to avoid too many test cycles. If this is the case and if the variability of the
software components is such that one component can cover different use cases, then
configurations from outside make sense. Imagine again a signal processing algo-
rithm designed for different numbers of channels. Let’s also assume that certain
features need to be switched on and off for different projects during the design time.
Ideally, the platform team delivers a library that is compiled, tested, and docu-
mented; in addition, it delivers a configuration file that is human-readable, where
the product team can easily configure the number of channels and the availability of
certain features. They can change this configuration file according to their needs,
and the functionality is changed accordingly. Of course, this is also how the scal-
ability of components can be realized (Fig. 3.19)
3.4.5.8 Development Process
Another aspect of software development is the whole topic of development pro-

cesses. While developing along the V model and having best practices such as
reviews and continuous integration, I would like to describe what it means to
develop a software platform for a complex product and customer landscape.
It makes sense to divide between the internal activities to achieve a certain qual-
ity and the external or interface activities for the input and output of the process.
Fig. 3.19 Configuration of software modules

The internal activities are interesting because the platform team needs to make
sure that they cover several variants, configurations, and timelines of the platform.
Furthermore, the team needs to make sure they have a solid project management
structure to support all products. I do not wish to focus on actual software develop-
ment processes such as coding styles, documents, tests, and reviews, assuming that
they are already well-known and published in many books.
Let’s start with requirements as it is always the first point in the V model.
3.4.5.8.1 Software Platform Requirements
The software platform might start after an initiative from system architects, where
they discovered what functionalities are overlapping across projects, what features
are necessary in the future, and how the market is evolving. I described this first
investigation earlier. A result might be that we need a certain programming lan-
guage, a certain framework, communication protocols, and interfaces to other soft-
ware modules among other elements. We might see that we need to support certain
processors and other hardware modules and interfaces. Furthermore, we might have
internal development rules such as coding styles, or we need to follow certain regu-
lations to achieve certifications and quality assessments with the resulting software.
All of these requirements are the first input for the development team to come up
with a concept covering them all. It makes sense to write them down and review
them with stakeholders. Here, it is interesting to know who is funding the platform
and who are its later users or customers. One must ensure alignment between them
upfront to avoid surprises later. A steering committee makes sense to treat the plat-
form development similarly to a full product development with all business and
engineering consequences in the company.
3.4.5.8.2 Software Platform Concept
After requirements collection, the development team creates a high-level concept

that covers them all. This is similar to the RFQ process described in the first part of
this book. Requirements come in, and then the team creates a concept as a baseline
to estimate effort and timelines so that a business case and project management can
be established. It makes sense to have an effort estimate per requirement so that a
discussion about priorities can occur. This discussion might be an effective gate for
deciding how to proceed. It might occur that the stakeholders skip certain require-
ments because effort and costs are much higher than expected.
After the high-level concept has been created, it should also be possible to esti-
mate the overall reuse factor for future products. This means that all information is
available for deciding what to implement.
3.4.5.8.3 Software Platform Architecture
The next step for the development team is to create an architecture out of the con-
cept that covers all of the agreed requirements. Here, it is crucial to consider that the
software components are modular, scalable, portable, extendable, testable, and con-
figurable, as I described earlier.
Furthermore, it is also important that it is clear where to draw the line between
platform- and project-specific content. It might be necessary to align with other
development departments and discuss the interfaces in detail.
From a platform point of view, it is critical to document the architecture properly
to always and easily be able to explain all details and decisions. The traceability of
requirements is part of best practices. After some time, you might be asked how you
did this and why you decided to do so. Clear documentation helps greatly.
3.4.5.8.4 Software Platform Implementation
Now, the development team implements what was agreed during the architecture
phase. We want to assume they are following state-of-the-art processes and have
tools according to them. The creation of unit and integration tests can be part of
this phase.
Transparency about content and timelines helps the rest of the organization to
understand what the platform team is doing the whole day. Sprint reviews in agile
development are a nice way of presenting results every 2–3 weeks so that stakehold-
ers can see what is happening and give feedback, and the team can also celebrate
their results.
The initial implementation of the software platform is straightforward: require-
ments, concept, architecture, implementation, and test. It becomes more compli-
cated if the platform is rolled out already and part of the development is maintenance
and the other part is continuous development of new features. I describe this further
as follows.
3.4.5.8.5 Software Platform Tests
During the implementation phase, the team might create unit and integration tests
already.
Unit tests cover the inside quality of a component or module (Fig. 3.20). One
could also call them white box tests because we are examining the module in detail.
Several unit tests are usually necessary to test all code lines and branches in a soft-
ware module. The coverage reports how much percentage of the code is actually
tested. There are enough tools and frameworks out there to support this. Static code
quality analysis can also support the detection of bad coding styles, mistakes, or
areas of risk. Continuous integration tools help to run these tests automatically, for
example, during the night when no developer is active.
Fig. 3.20 Unit tests
Fig. 3.21 Integration tests
Reporting the number of tests, code coverage, and of course whether the tests are
passed is an effective approach for creating confidence for the rest of the
organization.
Integration tests cover the behavior of a module in its environment. Now, the
module itself is treated as a black box and the software environment is white
(Fig. 3.21). Input, output, configurations, and control events – does everything work
as expected? Furthermore, the integration tests can be automated and run over night,
and reporting those results will help the rest of the organization.
Here, an interesting aspect is how far the platform development team needs to go
to cover integration into all possible product environments. In principle, there are
two ways to go about doing this, and the organization should carefully investigate
and decide which one to follow:
1. Integration into the reference environment
This means that the platform team has one or more reference systems and they
integrate the software platform into it. The reference system might be running on an
evaluation board or on a PC. The reference is close enough to all other product
environments that the product teams can easily take the software platform, which is
tested on a reference and integrated into their particular product (Fig. 3.22). It is
obvious that this is beneficial for the effort of the platform team. They have to sup-
port only a subset of all possible platforms and still be able to test and deliver. This
Fig. 3.22 Integration on reference systems
might be sufficient for the product teams. Furthermore, other dependencies may
exist such as system availability and location restrictions, which must be considered.
Depending on the number and complexity of the reference systems, it might
make sense to invest in the automation of testing activities. Continuous integration
and tests overnight are extremely helpful for accelerating development and avoiding
manual and error-prone work. A sufficient number of server and tool concepts exist
to realize an effective testing bench where every single hardware platform is con-
nected and all software variations can run tests automatically. This is especially
useful if the platform is used by many other teams, where automation is essential for
not increasing the effort for the platform team exponentially.
2. Integration into all product environments
This means that the platform team has every single product on their desk and
integrates the software platform into them. They deliver an integrated solution fully
tested on the final target system. This is a highly efficient solution with respect to
know-how and communication overhead. No handover of software or know-how
duplication is necessary. Of course the consequence is a much larger platform team
because they are responsible for the whole product integration effort. Furthermore,
they need to understand the rest of the environment, which might be complicated
Fig. 3.23 System tests
and have many variations. Overall, however, taking the efficiency described above
into account, it might be the better solution.
Here, test automation should also be seriously considered.
The last stage for testing is the system test. Now the whole system is a black box,
including the software platform that is somewhere in it (Fig. 3.23). It makes abso-
lute sense that the platform team also performs system tests, but this depends again
on the aforementioned integration strategy. If the software platform team is integrat-
ing into a reference system, then they should fully test on these systems. If they
integrate into all products, a separate validation team might be responsible for sys-
tem testing. Then, it might be better for the software platform team to design, create,
and describe the system tests while the validation team executes them. In any case,
the loop of traceability must be closed here to ensure that every single requirement
from the beginning of the development process is covered and tested.
3.4.5.9 Rollout
The last stage of the development is the rollout of the software platform. This is one
of the most important aspects because it creates another level of complexity for the
overall process.
If software is rolled out, it is in principle necessary to prepare for that thoroughly.
The rollout is not something that happens only at the end of the development.
Actually, it starts at the very beginning with buy-in from stakeholders.
As described at the beginning of the platform part, an initial analysis should hap-
pen involving several departments and stakeholders. Obtaining their buy-in and
commitment is essential for the later rollout of the platform.
During the development, it makes sense to start involving the later users and
make sure they know what is coming because they can offer input and feedback.
Everything that helps communication such as clear time plans, feature descriptions,
processes, and support models helps to secure buy-in from management, sales and
marketing, developers, and users.
Stakeholders, developers, and users help to create the set of requirements that is
always the starting point for the development.
Besides training material, it is necessary to install processes and organization for
bug fixing, change requests, feature requests, and integration support.
In general, it is the question of how the deliveries happen. We will return to orga-
nizational aspects again later and focus on the delivery strategies here first.
The method of delivery depends heavily on the content of the platform and on the
development tools in the company. It also depends on the product development tim-
ings of the teams receiving the platform. The following options can be listed.
Content delivery options:
• Software as source code (e.g., C/C++ files, header files)
• Software compiled as binary code (e.g., as software libraries)
• Examples and reference integrations as source code
• Executables for tools and packages (e.g., compilers, IDEs)
• Packages such as
–– Links to version control repositories to download content or to sync with the
local development environment
–– Websites to download separate parts
–– Executables installing all necessary parts on a PC
–– A virtual environment to be installed on the PCs of users and developers (e.g.,
virtualization of the development PC and OS including all tools)
• Reference hardware to install and run the software platform
• Reference environment to demo and test the software platform in a system
• Supporting tools, licenses, and optional content
• Documentation such as
–– Detailed design and implementation description
–– Integration and test descriptions
–– Datasheets and test results
–– User manuals and validation guides
–– Marketing material
• Contact points such as
–– Links to software repositories and download websites
–– Links to support request portals and training material
–– Name, telephone number, and email address from field application engineers
• Training materials such as
–– Tutorials and getting-started guides
–– Examples
–– Online and classroom courses
Timing is another fascinating aspect for a software platform rollout. Developing
the platform itself is one thing, but integrating it into various products can be highly
complex. Imagine the following worst-case scenario:
• The software platform needs to be integrated into dozens of products worldwide
with totally different configurations, features, processors, and timelines.
• All products have different concepts and timelines for feature freeze, software
freeze, and test cycles.
• The software platform is not 100% complete to cover all features for this number
of products. Certain add-ons and small changes need to be developed.
• With every integration into another product, more change requests and bug fixes
are necessary, and automation is not yet developed to compensate for it.
• Product teams are not yet trained very well, skillsets are not sufficient, and stake-
holders are not fully convinced.
The majority of these points can be handled through careful investigation of the
situation upfront followed by proper planning and preparation. Transparent com-
munication and commitment from all stakeholders are necessary to make this suc-
cessful. The last point in particular can be avoided completely through proper
preparation.
In any case, the number of product integrations will increase the effort on the
platform team side for bug fixes, change requests, and integration support. This
must be considered and can be solved either by increasing the platform team or
investing in automation.
Some of the most interesting questions concern the timings of test cycles, the
integration effort of new releases, and in general backward compatibility. Product
teams probably want to freeze the software 1 day. They would only allow changes
for severe bugs after this point in time and only bug fixes that cause such little
change in the overall system that they can avoid a full test cycle of their product.
However, what happens if the platform team can only provide this bug fix with a
new major release that would cause numerous changes in the product software? The
product team has the full integration effort again as well as a full test cycle, which
might take too long to hold milestones and deliver in time.
Then, there is also the question of answering whether product teams perform
continuous integration of every small upgrade of the software platform or if they
integrate only once or twice a year with a much greater and maybe surprising
amount of effort.
It is necessary to think about all of these aspects from the very beginning and to
design a concept that is accepted by all stakeholders. The later one discovers that the
platform does not fit the needs of the product teams, the worse it is in terms of tim-
ings and effort. Everybody must be committed to using the platform, making all
information transparent, training involved people thoroughly, obtaining feedback,
and monitoring usage of the software platform. Basically, ensure a proper platform
design, and do your homework in terms of change management.
3.4.6 Hardware
Hardware is the basis for all electronic systems. Without it, no single piece of soft-
ware can be executed. Even today, abstract places such as clouds run software some-
where on an IT server, which is ultimately a piece of hardware. We require
processors, memory, interfaces, networks, displays, user ports, antennas, and power
supplies among other things. They are all mounted on PCBs, where schematics and
specific layout techniques are used to ensure that every component receives the
appropriate power and signals.
Hardware in terms of platform development doesn’t necessarily mean develop-
ing one specific system and calling it the “the platform.” It can also mean develop-
ing key components and reference systems as described above. How the platform
approach should be defined depends again on the desired reuse levels.
The key components might be specific processors, power supplies, or interfaces.
The reference system is one example of how to assemble all of these key compo-
nents into one system. If you want to develop several key components for the same
purpose – for example, if you want to try out different microcontrollers from differ-
ent suppliers – then you might want to create a reference system where it is easy to
exchange this microcontroller through a socket system, or you could build up differ-
ent reference systems. You might also want to create a playground to try out new
technologies on a superset of hardware components and interfaces.
3.4.6.1 Reuse Levels
Returning to the six levels of reuse, I now want to explain what they mean for hard-
ware development.
Level 1 Hardware Reuse:
The first reuse level of “experience” simply concerns keeping the hardware
development team together. Make sure that you have skilled hardware architects in
the team and that they all know the relevant history of the company’s products, its
current products, and what might come in the future. Knowing the supplier land-
scape is also essential for hardware design. Make sure that you have an expert for
every specific domain such as displays, power supplies, and processors. It is a com-
plex world and one person usually cannot master all hardware topics alone. If you
are developing products sequentially, then this team can use its experience
repeatedly.
The second level “reference” is more about creating schematics once and using
them often in many projects. For example, you might create a special power supply
circuit using a special chip with all kinds of resistors, capacitors, and coils to pro-
vide 1.8 V, 3.3 V, and 5.0 V for a specific product. The hardware team has chosen
the components so that they will fit all kinds of future products, and therefore, this
circuit can be used repeatedly.
Alternatively, you may have a strategy to work with a certain processor family of
microcontrollers. The hardware team creates schematics around it with interfaces,
clocking, memory, and voltage. They can be reused whenever needed. You might
want to change memory sizes or interfaces here and there, but the majority of work
is done and can be reused. Here, the question arises of how to store and manage all
of these concepts and reference implementations. Another question is how to store
information about components and parts in general. Highly integrated systems are
available, starting with an abstract system design and going through PCB design
and layout until production. There are databases in the background managing all
information about availability, prices, and technical specifications per part so that
hardware designers can get access easily and work efficiently. Then, the team can
create its own standards for drawing schematics and create naming conventions.
Standardizing these things is an essential part of a hardware platform.
The third level “LEGO©” has this kind of integrated tools as its basis. The inte-
grated tool set is the counterpart to frameworks in the software domain. It is a stan-
dardized and common ground, and everybody follows the same rules while
developing hardware. This tool set combined with a standardized development pro-
cess ensures that the individual pieces always fit together. Someone in India might
be creating schematics for the power supply, while someone else in the United
States is creating schematics for the microcontroller. They all work with the same
database, with the same tool set, and in the same system. These integrated systems
also support various approaches to work collaboratively around the globe. Thus,
ultimately both schematics fit together and can be developed once and used often,
but this level goes one step further. It is also possible to develop the PCB layout as
a reusable block, so the key components consist of hardware parts, schematics, and
a layout that is fixed for a certain circuit. If someone wants to use this specific block,
then he or she needs to make sure the boundary conditions are met, such as the
number of layers. However, if that is the case, then that person can use this block
with no additional effort.
The fourth level is “Plug & Play.” This is on the hardware side and rather what
we all know from PCs and laptops. Microsoft coined this term when they published
Windows 95. It is a combination of hardware and software features that make sure
a new device can be plugged in or a new piece of hardware can be connected to the
main PCB and they fit together, automatically being detected and with drivers auto-
matically installed. Therefore, Plug & Play concerns standardized hardware sockets
and connectors as well as automatic detection when a component is connected. For
electronic systems development, this means that you might develop systems that
can be adapted with specific PCB cards on standardized socket connectors. If you
have developed a variety of radio tuners to cover worldwide signal reception, then
you might have them on small PCB cards that can be used per country in a larger
system. The connector is standardized, including an automatic detection mecha-
nism, such that the software on the main processor immediately knows which tuner
applications to run per country.
The last reuse level is “System,” where the whole PCB with all of its components
is reused for another product. If that is possible, then you are of course in a very
comfortable situation. This is the best possible reuse in terms of development effort.
It might be difficult if only a subset of features is necessary for the new product and
the reused platform is more expensive than necessary.
Here, I want to also examine the different rules of reuse and discover what that
means for hardware.
3.4.6.2 Modularity
Modularity in hardware also means finding the right level of granularity for compo-
nents. It is certainly not very efficient to say that every single part, such as resistors
and capacitors, is the desired granularity level. Rather, it is a combination into a
larger reusable block that makes sense. A small microcontroller always used for the
same functionality on a PCB could be a component that can be reused repeatedly, or
a power supply circuit could be configurable and scalable for all sorts of product
variations.
3.4.6.3 Scalability
Scalability in hardware means being able to resize a component or a system without

too much effort. A typical example is to scale processing power up and down.
Processor families are available on the market that run with different clock speeds
and memory sizes. They are pin compatible so it is easy to change from one proces-
sor type to another. Alternatively, you might want to achieve system scalability by
removing parts for the smaller variants. Perhaps you have an architecture where
four similar processors are required for a high-end system and you can just remove
two of them for the smaller variant, or in production you simply do not solder the
part onto the PCB.
3.4.6.4 Portability
Portability in hardware doesn’t have a clear counterpart to the meaning in software.

You might consider porting schematics and layout information from one develop-
ment tool to another, but in a company with standardized tools, this is not particu-
larly relevant.
3.4.6.5 Extendibility
Of course, this is absolutely relevant again. In hardware, one might also be able to
foresee certain things in the future and to account for them in your current design,
such as reserve pins on processors, power stages, or interfaces.
3.4.6.6 Configurability
Here, the counterpart to software is rather on the tool side than on the hardware
itself. Once a part is soldered onto a PCB, it is fixed and cannot be configured too
much afterward. Some tunings might be possible, but the main configuration again
comes with flexible software in processors or on standardized interfaces. Then, mul-
tiplexing on pins of processors can be changed and reconfigured if necessary.
One compromise between hardware and software configurability is to use archi-
tectures with a FPGA.4 These devices are considered hardware devices but can be
programmed using hardware description language. The hardware interfaces that are
usually fixed on processors can be freely designed, programmed, configured, and
changed whenever necessary. Logic can be downloaded to the device to realize all
kinds of hardware solutions: interfaces, calculation engines, algorithms – even real-
izing complete microcontrollers is possible. If configurability is necessary in hard-
ware, this might be a solution.
3.4.6.7 Development Process
The development process for platform hardware follows the usual steps as were
described for software. Requirements, concept, architecture, implementation, and
testing are very similar. Of course, dependencies exist between software and hard-
ware, but these are not platform-specific, so I do not wish to go into more detail here.
Furthermore, the rollout of a hardware platform is very similar to that of a soft-
ware platform. It involves stakeholders, transparent communication, and commit-
ment from management, developers, and users among other requirements.
3.4.7 Quality and Stability
This section concerns the quality and stability of a platform approach. The strategic
goal is definitely to increase the quality and stability of the platform by reusing it
repeatedly. In an ideal world, this happens if it is used in several products already.
The key components have undergone several bug-fixing phases and releases, and
the quality is constantly increasing. The more people that are using the key compo-
nents, the more bugs that can be found and fixed. Moreover, the reference systems
are an essential part of the platform development, and the full integration of all key
components has undergone the same bug fixing and release phases. Interdependencies
are solved, and the stability is proven for those combinations available in the refer-
ence systems. The stability increases with every release cycle and product.
4
FPGA means Field Programmable Gate Array.
Fig. 3.24 Platform in the pilot project
In reality, the platform is developed first or in parallel with a pilot program. It

might be difficult to integrate it into the first pilot project and the quality might not
be as good as expected, but over time it continuously improves. Management needs
to understand the effort for the first pilot project, be patient, and stick to the plan. A
long-term strategy and reliable planning are necessary to justify the initial overhead
and count on the payback. Furthermore, a long-term technical strategy should be in
place to make sure the platform has the reuse that everybody was counting on at the
beginning. The reuse factor increases with every new product that uses the platform
components (Fig. 3.24).
3.4.8 Central Storage
One main aspect of all strategies of reuse is a central storage concept. All compo-
nents, parts, concepts, designs, and projects need to have a central and well-
organized storage place. The system architects must have immediate access to those
storages to determine whether something already exists.
The platform develops and stores, and with this storage concept, the product
teams have a centralized way of taking key components and using them for their
products (Fig. 3.25).
This is relevant in the design phase to have immediate access to information such
as concepts, performance numbers, and interface descriptions. It is especially rele-
vant for software repositories and delivery structures. It is crucial to control changes
Fig. 3.25 Central storage
and variants of software parts in the platform to avoid double work and unneces-
sary effort.
In addition, for hardware it is important to have centralized systems for concepts,
schematics, parts, and supplier management. This of course has some consequences
that could lead to complicated branching structures.
3.4.9 Support and Training
One essential goal of a platform is for it to be integrated into as many products as

possible. This also means reaching as many people as possible, which automatically
means that the platform development team needs to create a concept for training and
customer support.
3.4.9.1 Bug Fixing, Change Requests, and Feature Requests
Usually, the most crucial thing is to deliver a more or less bug-free system. The
platform team will create a ticket system where users can log bugs and have trans-
parency about the status. This also makes sense for change requests and feature
requests. Many ticket systems are commercially available. Today, one of the most
popular is Jira. The fundamental principles are always the same: a centralized data-
base is required where people can create a ticket easily and the platform team can
work on it. Transparency, priority, and status are managed in the system and can be
used for creating statistics.
If the platform reaches many development teams in different regions and for dif-
ferent markets, a situation might occur where contradictive timings and require-
ments must be solved. Therefore, an overall steering committee should be established
to decide those things, thus resulting in global alignment.
3.4.9.2 Application Engineers and Integration Support
After creating something that others will use, it is important to sit together and
explain everything about it. Platforms can be rather complex. Do not underestimate
the effort required to explain what you are doing to the whole development com-
munity. Creating special roles like field application engineers might make sense.
These engineers sit together with the platform users and explain every single detail.
They can also be seen as the so-called evangelists of the platform, convincing users
about the value. Furthermore, they receive direct feedback that they can then feed
back into the platform development.
The platform that I am describing here is, most of the time, not a single product
but rather several key building blocks. They must be integrated into a more complex
product. Thus, integration support is one of the most critical things to consider.
Remember that one of the most important success factors for a platform is ease of
use. If the development community can integrate the platform building blocks eas-
ily, then everybody will genuinely see the benefit in terms of timing and overall
development effort. Field application engineers can play an essential role here.
3.4.9.3 Training
Part of the game is of course to create training material. This can start with videos
on the company intranet pages. They can be online or classroom courses, such as
tutorials with all kinds of variations, including examples and reference implementa-
tions. Make sure that you start early with training sessions to achieve buy-in from
users as well as transport know-how.
Training sessions and proper materials are essential parts of a platform rollout
phase. The time and effort invested here will definitely pay back. On the other hand,
making mistakes here can destroy the whole positive momentum. If you throw the
platform over the fence and leave the users alone with it, you will not be successful
and the whole investment might be wasted.
3.4.10 Technology Releases and Platform Development
Platform teams usually have two main interfaces with other organizations. One is
the interface for innovation and technology development teams to receive input and
mature it in the platform. The other interface is for product development teams
(Fig. 3.26). Let’s look at the innovation interface first.
Let’s assume that the innovation and platform departments are not the same. In
that case, someone in the company is usually developing new features and technolo-
gies and driving innovation workshops. These technologies can be anything from
software features and applications to new hardware solutions or system compo-
nents, such as new SoC selections. It helps greatly if platform development is
Fig. 3.26 Platform development interfaces
involved in these activities to be informed about future requirements and simultane-

ously to provide input for future solutions and consequences in the platform’s devel-
opment. It also might make sense to create special reference systems to be prepared
for these technologies and mature them early before they go into product develop-
ment cycles. This is all about the maturity of new complex topics and the discovery
of issues as early as possible.
This is also relevant for third-party technologies and partnerships. The platform
team needs to be involved early to avoid expensive surprises later in the platform
development.
In addition to these architectural topics, it is equally important to align on timing
factors. The platform team is usually fully booked, which is the nature of a platform
team that wants to be as efficient as possible. If it is fully booked, it is essential to
have a roadmap or master plan from innovation departments with clear release dates
and milestones such that the platform can prepare and plan accordingly. This is of
course contradictory. How can an innovation team create a release date if the tech-
nology itself is just an idea at present? How can innovation teams create milestones
if the general feasibility of a technology has not yet been investigated?
Here, it is of great help to develop technologies and innovation with clear gates
and reviews in the organization. You might start with a very rough plan and a high
risk of delivering wrong numbers. Yet, in any case the platform team can be involved
and informed. With every development step, the plans can be refined until an inno-
vative topic is sufficiently matured to be handed over to platform development teams.
It makes sense to have a clear final gate for the handover from technology devel-
opment to platform development. It is crucial to define exactly what is possible and
expected so that the platform team can pick it up and continue.
In the past, I always sketched all of the development phases for certain features
or technology areas and put them into a frame of gates and potential handovers from
innovation to platform as well as from platform to product development. Going
through this with a real-world example usually helps all of the involved people to
follow and understand. This sketch is a helpful way of discussing with the involved
teams, coming to an agreement, and ultimately reaching a process definition that
everybody can live with.
3.4.11 Product Development and Platform Releases
The other interface is from the platform to all of the product development teams, as
mentioned above. Here, clear gates and reviews also help greatly to understand the
progress and status of technologies in the platform and the platform maturity itself.
The final gate is a release from the platform with a clearly defined quality and matu-
rity, making it easy for product development teams to use the releases in their prod-
ucts. The definition of technology or platform readiness levels like introduced in [2]
should be considered to describe the maturity.
In the industries I worked in, the product development teams were always under
the highest pressure in terms of timing, quality, and resources. The platform team as
a kind of supplier should support the product development teams and ideally make
it easier to develop products by using the platform. Several aspects must be
considered:
1. Platform requirements and priorities
The more internal customers the platform has, the more complicated it can be to
fulfill all of their requirements in time. Ideally, the platform team starts in parallel
and can get the majority of the work done before the platform is rolled out. Then it
is possible for all of the bug fixes, change requests, and feature requests to be han-
dled by the existing platform team. Nevertheless, the main frameworks and internal
standards should be settled and aligned before the rollout so the product develop-
ment teams do not have a moving target for a long time.
The first set of requirements can be handled as described above. Making a clear
comparison between known projects and an estimation about the future will provide
a specific set of deliverables from the platform.
After the rollout, a well-defined steering committee needs to be in place to han-
dle requests and decide priorities. It is essential for the platform team to have trans-
parent roadmaps and feature requests to be able to plan accordingly. As mentioned
before, the platform team is always fully booked. Thus, to make it agile enough for
a complex development environment, it is not sufficient to run with agile develop-
ment methods in the teams. However, it is also essential to have this team of
decision-makers who can set priorities across all product development teams and
decide what should be developed next for the platform.
2. Deliverables
Let’s assume that the requirements are clear and the priorities are set. It would
still be essential for the platform to deliver content with appropriate processes that
are easy to use. The platform should accelerate the overall development and not
slow the development processes in the company. Therefore, the deliverables must be
easy to use and to integrate into the products. Well-defined frameworks and working
standards are essential for this, and furthermore, the cadence of releases and integra-
tion play an essential role.
3. Timing
Not only is the planning input essential for the platform teams but also how they
release and what cadences they use. How long the platform can evolve before the
product teams integrate new versions of it must be investigated carefully. The usual
discussion needs to occur between continuous integration in small and predictable
steps and a big bang integration after a long time with much effort and many
changes. How this is done always depends on development cycles, the likelihood of
change requests, and branching strategies. There needs to always be a balance
between these aspects.
4. Support
As previously mentioned, platform teams require a strong support structure to
help product development teams to understand and integrate the platform deliver-
ables. Field application engineers, solution architects, and similar roles might be
necessary. Documentation and training material are essential to deliver with the
platform releases.
Another useful approach is to rotate product development engineers into the plat-
form to be ramped up on platform details and then move them back to product
development teams to be technical evangelists. If newly hired people have a ramp-
up phase in the platform before moving into product development teams, this is a
win-win situation.
3.4.12 Supplier Management
Here, I want to briefly mention supplier management. This is because in all organi-
zations I have observed the need for integrating third-party components. The ques-
tion is always what the most efficient and flexible setup to support this is. I always
saw that the stronger the platform, the more effectively all of the suppliers could be
handled, as then they have a clear framework to work with.
Let’s leave the commercial and project management aspects of suppliers and
focus on the technical details and engineering level. In any case, it is important to
clarify roles and responsibilities and to create a RASIC chart to clarify what to
expect from whom.
In principle, two major directions are possible:
1. Integrating third-party components into the platform
Ideally, this component is one of many other internal components. Then, the
integration will already be well-described and well-developed for internal purposes.
The question is then whether to provide the platform to a third-party supplier so that
the components can be integrated and tested or whether the supplier should deliver
the component and the internal platform teams integrate and test it. The answer
depends on resources, skillsets, timing, as well as confidentiality.
The more this setup deviates from the ideal scenario, the more architecture work
is necessary to find options for how to integrate the supplier’s solution into the plat-
form. It is essential to determine whether this is a solution for a single product or if
it has a high reuse potential and should be integrated in a reusable way.
2. Integrating the platform into a third-party environment
It might be the case that the platform is a software block that needs to run on a
certain processor. The processor might be delivered from a supplier including
software portions either completing or competing with the internal platform soft-
ware. It is again essential architecture work to create options and recommendations
to integrate the platform software onto the processor.
3.5 Organizational Aspects
Culture eats strategy for breakfast.

– Peter Drucker
US-Austrian author, educator, consultant for management topics, and inventor of
management by objectives
3.5.1 Platform Development Organization
Organizing development with platform thinking in mind requires special attention.

Organization is probably one of the most important things to consider for platform
development in general. The challenges are to align teams, have a common under-
standing of platform thinking, avoid unnecessary handovers, and create a sense of
ownership while simultaneously balancing skillsets and roles in the overall engi-
neering community. Introducing platform development usually requires an effective
change management approach because one might need to change the mindset and
development style of many engineers in the organization. Thus, mindset is the
fourth aspect that I want to add here (Fig. 3.27):
Creating an effective organization structure is not an easy task and depends on
many factors, which must be considered. Usually the whole engineering community
is involved if platforms are introduced in a company. The first question probably
concerns creating one central platform or several platforms per functional domain.
Fig. 3.27 Platform mindset

3.5 Organizational Aspects 139
One central platform would mean creating a team of experts from all domains,
who start developing a platform in parallel with the rest of the engineering commu-
nity. This team could work in parallel for a certain time before the platform is rolled
out and all other teams use it.
Several platforms would mean requesting from every functional domain to create
their own platform. There might be a systems department collecting all the different
platforms and integrating them into a main platform, but that is optional.
Whether one or the other way should be chosen depends entirely on the indi-
vidual company setup in terms of technologies, products, and team sizes, among
other factors.
Companies usually do not start from the beginning with platform thinking. This
is rather an evolutionary step to solve some engineering issues, so there is usually
an organization in place already. This also means ensuring an effective change man-
agement approach and taking a transition phase from the current situation to an
ideal scenario into account when introducing platform strategies.
Let’s assume that the company went through the evolutionary steps of serial and
parallel development that we discussed in a previous chapter. Now, the need to
develop with platform thinking in mind comes from the fact that a company wants
to develop several similar products in parallel at roughly the same time. A proper
platform supporting all of these products makes sense in that case. Here, I want to
discuss what organizational impact this has.
3.5.1.1 Departments and Platform Team
Do we need to create special organizations around platform development? My state-

ment here is – definitely yes! First, as I said at the beginning of this part of the book,
the cleverest people in the company are required. They must be highly skilled in
their domain and have enough historical background from your company or others.
Furthermore, they must have a broad overview of where the market is going in the
coming years and also qualifications such as a master’s or PhD degree and
10–15 years of experience. In addition, it’s important to carefully add young people
with a state-of-the-art education and an open mind to incorporate the newest ideas
and innovations from universities into discussions. These people are needed because
they will create the foundation of the company’s development for the coming years.
The better they are, the more efficient the platform development will be. It’s
very simple.
Now, they need to develop and test the key components, frameworks, and refer-
ence systems as well as the relevant processes. It’s crucial not to forget change
management.
Depending on the size and scope of the platform, one might want to split the
teams according to the development flow of innovation, platform, and product
development. The decision of whether to split between functional domains or not
highly depends on the technical complexity of the company’s products. The head
units in the automotive industry are fairly complex, and a split in specialized
departments is necessary to handle the complexity. These departments might

develop their own platform approach and deliver into a larger system platform.
It helps to take Conway’s Law5 into consideration, which states that system
design in an organization follows the communication structure in the company. This
means that it follows the department structure, which means that an optimized orga-
nization should follow the architecture in the system. This, of course, has a platform
organization impact.
Depending on the platform scope, it makes sense to have dedicated architects
and experts for each technology domain. They would cover the relevant hardware,
software, and mechanics parts. It might make sense, as mentioned above, to have
one system platform team that creates the frameworks, development standards, and
major processes around the platform. The technology domain departments might
deliver into this system department where the integration into the reference systems
occurs. The final stage of the platform activity might always be a test and integration
step so that the platform teams can release something of value to the rest of the
organization. These considerations lead to another organizational strategy, namely,
platform development having a setup similar to product development. A system
architect is highly recommended, and a skilled test team needs to be in place to vali-
date all deliverables and releases.
Part of the platform team is also a project management organization. Depending
on the size of the team and the approach, several people are necessary to create
plans and help the teams with work breakdown structures and priorities. The roles
of product owner and scrum masters might be necessary if agile development is
used. More details are provided later in the Platform Project Management chapter.
Another question for the organization is whether the platform is a one-time activ-
ity that can be frozen after rollout or whether it is a continuous effort with further
improvements, upgrades, new features, and one release after another.
The idea of developing the platform and then freezing it leads immediately to the
question of who is responsible for maintenance and support afterward. The platform
development team might still be available and can take care of bug fixes and change
requests. Furthermore, small feature add-ons might be possible if necessary. From a
know-how perspective, this is the ideal situation because the inventors of the plat-
form are still available for support. However, for the platform engineers, it might be
frustrating to change from highly creative platform creation to maintenance tasks. A
special maintenance team should be considered.
Let’s consider the other option: the first generation of a platform is finished, but
development continues with further increments. The development team is occupied
with continuous upgrades. It must be clear that bug fixing and change requests result
in a significant amount of effort, which needs to be clearly considered. An efficient
solution might be to add a new team that cares about maintenance and support.
5
Well-known thesis from Melvin E. Conway’s paper “How Do Committees invent?” from
April 1968
Some of the platform specialists might be considered solution architects or field

application engineers to help the customer teams integrate the platform into the final
products.
3.5.1.2 Management
Furthermore, it’s important to determine how the platform can be introduced into
the company. The platform team itself needs to cover the technical part and needs to
create the technical foundation of the platform. Engineers provide training to other
engineers. Field application engineers help out with all kinds of customer projects,
supporting their architecture or integration.
But in addition, full management alignment is also definitely necessary along
with a top-down message to make a platform successful. The more this bottom-up
and top-down approach is established and maintained throughout the whole life
cycle of the platform, the more successful it will be.
In general, management is responsible for creating a platform organization, car-
ing about change management, and being patient about sticking to the strategy and
time plans.
3.5.2 Timing and Team Size
We are not living in a perfect world and people, teams, and strategies change.
Therefore, the timing of when to discuss the introduction of a platform will differ.
Furthermore, as previously mentioned, team size is a crucial factor.
3.5.2.1 Start from Scratch
First, it is possible that the development department starts from scratch in a start-up
environment. Therefore, you might want to investigate whether a platform approach
makes sense from the beginning. This depends on the business opportunities that
you have in mind. Whenever you aim to sell something more than once to custom-
ers, a platform approach should be considered. This is one of the easiest situations
because usually some budget is available for development anyway. Technical and
business development are started in parallel. As the platform grows, the potential
customer interest also grows. The whole development team is not occupied by prod-
uct development because there is no product yet, and they can fully focus on the
ideal platform. Of course this needs to go into a product soon. Depending on indus-
try, product, and business cases, this point in time will come sooner or later. The
team should at least be as large as for a full product development. Add some over-
head (e.g., 10%) to develop with platform thinking and creating reuse in mind. But
it might pay back also quickly if you have all standards, frameworks, and processes
defined from the beginning.
3.5.2.2 Start During Projects
The second option is to start during running project development cycles. Imagine
that your company has organic growth. Projects are developed around the world in
several flavors. Now, you should investigate whether to introduce a platform
approach to change the whole development strategy. This is the most interesting but
also the most challenging option because an additional investment is required to
create a platform team. All other developers are usually fully assigned to product
development tasks, but the platform itself can be counted as a full product itself, and
thus, it of course needs a proper development team plus the 10% overhead as a rule
of thumb. This overhead is necessary to create architectures and implementations
for reuse instead of product-specific straightforward development.
In all organizations, I saw that it was necessary to create a dedicated team to
develop the platform in parallel with the product development. Then, they had a
chance to create something before other teams and customers picked it up and cre-
ated a huge effort for support and maintenance. Starting the platform within the
product teams is also possible but not easy. If a product project is under high pres-
sure, one would always prioritize for that instead of the platform activity. The plat-
form engineers might require a long time to create something if they are repeatedly
disturbed by product development activities. Frustration among management might
increase, ultimately leading to the platform not being successful.
3.5.2.3 Kill the Platform
The third option does not concern creating a platform but rather shutting one down.
Remember that software usually has a certain lifetime. It is also aging. One day, the
architecture, interfaces, concepts, and features will be so old that they no longer
meet the current requirements and the maintenance effort becomes greater than the
effort required to start something new from scratch.
I remember a software tool that was still maintained in around 2015 that was
programmed in Borland Pascal. Unbelievable! Therefore, one can imagine that
sooner or later an existing platform will need a serious investigation into whether it
should still be maintained.
The possibilities are as follows:
• Keep on maintaining: it is still good enough.
• Refactor: rework the platform and rejuvenate the important parts.
• Kill: the platform cannot be reworked and a new approach from scratch is
necessary.
To make this decision, the following should be considered:
Maintenance might need a few developers per year, with the risk that more fea-
tures cannot be added quickly because of outdated tools or similar.
Refactoring might require several developers to achieve as well as another to

maintain the platform. With updated tools and methods, you might survive some
more years without risk.
Killing the platform means either creating a new one with all of the effort required
to start from scratch or not developing a platform at all anymore. Killing of course
means finding an effective way to fade out using the existing platform. Some proj-
ects might still want to use it, while some others might start from scratch without it.
One possibility is to hand over the platform to each individual product development
team, and they can decide whether they continue it or not.
3.5.3 Platform Project Management
The project management of platform development is rather complex. Imagine that

there are numerous technologies under development in the research and innovation
departments. They will all be handed over to the platform development at a certain
point in time to be integrated into the platform. On the other side, there are numer-
ous internal product development teams waiting for releases and bug fixes and who
continually request changes and support from platform engineers. Of course, there
is also the main platform development, which needs project management to define,
track, and manage the tasks of the development teams. It is essential for the project
management in platform development to create an overall master plan to describe
and manage all of the activities and dependencies.
In the automotive industry, the timelines of product development teams are
always tight and not very flexible. By contrast, the timelines of technology depart-
ments are usually not very reliable. The more they work on feasibility studies and
cutting-edge technology, the less they can generate reliable plans. This is just the
nature of research and innovation. The platform team in the middle might have their
own agenda in terms of platform creation, so they might not be able to focus fully
on integrating features from technology departments. All of this needs to be bal-
anced very carefully and is not easy to manage. In particular, versioning and back-
ward compatibility will be issues if the platform rollout is too early in the
development and the platform is still undergoing major upgrades and changes. This
also increases the complexity of project management, including release and version
management.
The following aspects can help to handle the complexity:
1. Selection of an effective project management approach: A traditional waterfall
approach might make sense for handling the tough deadlines from product devel-
opment teams. However, agile development is probably preferable for handling
the dynamics between unknown technology releases, an unpredictable number
of bug fixes and change requests, and the complexity in general of these many
stakeholders. Scaled agile approaches like SAFe could be beneficial for handling
all of these aspects. Readers will learn more about agile and SAFe in the last part
of the book in the Agile Development chapter.
2. Stakeholder management: As mentioned above, a balance is necessary between
platform internal development, technology input, and output to product develop-
ment teams. It helps greatly to meet on a regular basis and understand expecta-
tions. A steering committee is necessary to discuss dependencies and to decide
priorities for the platform team.
3. Releases and an optimized cadence: Even in the automotive industry, product
teams have some flexibility. They have a chance to adapt if the platform teams
create releases on highly reliable and predictable timelines with planned content.
The cadence depends on many factors and needs to be chosen carefully. It also
depends on the ability of the product teams to perform continuous integration or
if they rather want to have fewer big bang integrations.
4. Timing: Avoid starting with the rollout of the platform too early. The platform
needs a certain maturity so that future changes will not be too large. If this is
possible, the risk of huge issues with versioning and backward compatibility can
be minimized.
In general, the platform team is created to increase efficiency in the organization.
The team itself is probably always fully booked. The platform product owner must
create a good balance between platform internal development and feature integra-
tion so that the releases fit the product development requirements. If a team is
always fully booked, it needs to have an effective way of changing priorities quickly
at any given time. Two essential points are as follows:
1. Agile development is applied to change the direction of development quickly.
2. A steering committee, as mentioned above, where all stakeholders can come
together quickly and decide whether to change direction.
Platform project management is essential for making the dependencies transparent
and demonstrating the consequences of potential changes immediately – only then
can the steering committee work efficiently.
3.6 Why Platforms Fail
As mentioned in the introduction, there are several reasons why platforms fail or the
strategy for developing one is skipped before someone starts working on it.
I believe there are four main reasons:
1. Communication: Most of the time, it is unclear what a platform is. People have
different expectations and teams have different approaches to develop the
platform.
2. Costs: The cost and effort estimation are most of the time not comprehensive
enough, so management can only see the initial investment. That is of course
higher than individual, straightforward, and customer-specific development.
3.6 Why Platforms Fail 145
However, it becomes beneficial over time and saves costs in the long run. Several
factors need to be considered to make a precise calculation including the rising
complexity in today’s technologies in general. A project cost simulation without
a platform could make sense to show the costs of development without platform
benefits.
3. Reuse: The actual platform development approach needs to be chosen very care-
fully. Which approach is correct and actually brings efficiency, and not just a
large overhead, depends on the product portfolio, customer landscape, and sys-
tem complexity level. This goes wrong sometimes, and therefore, people might
have a bad experience with platform approaches and refuse to work on them.
This is why I like to call it a strategy: it is necessary to obtain a strategic decision
from management to invest in platform development. Management needs a long-
term view to invest into the future. Moreover, the cleverest people in the com-
pany need to define the level of platform development and how to get maximum
reuse out of it. They need to have long-term experience in the company, in the
market, and with customers to evaluate exactly where to draw the line between
platform and customization.
4. Company size: My experience suggests that platform development becomes rel-
evant when companies become large and successful and especially when they
have several programs running in parallel. A larger product portfolio usually
leads to opportunities to find overlaps and use synergies. Then, the development
is also probably distributed globally; every region has its own engineering leads;
and they all have their own agenda. This means that the larger the company, the
more relevant platform development is but also the harder it is to achieve global
alignment across all engineering teams.
Let’s continue to talk about management. Numerous pitfalls exist in manage-
ment, but one main issue that I want to discuss is the triangle of platform failure.
3.6.1 Triangle of Platform Failure
This triangle consists of three major influences that decide whether a platform is
successful or not. The first corner of the triangle is management and top-down mes-
sages. Communication in general is a key aspect to support the change management
that is necessary to make the platform successful. The second corner is the global
footprint, company size, and especially the engineering in the particular company.
The third corner is the platform quality in terms of technical strategy and content.
As mentioned above, the platform needs to fulfill the product requirements and
needs to be easy to use (Fig. 3.28).
All three corners have a relationship with each other:
• The larger the company, the more top-down messages from management are
necessary to make sure the platform is accepted and used.
Fig. 3.28 Triangle of platform failure
• The higher the quality of the platform (in terms of technical strategy and con-
tent), the more convinced management will be and the more it will support the
platform activity.
• The larger the company and the more spread out around the globe its teams are,
the harder it is to have a central and efficient platform team that creates a high-
quality platform.
Now, let’s discuss what else can go wrong.
3.6.2 Management Failure
First, management needs to fully support the platform strategy. As discussed above,
in a large company, management must make top-down messages so that engineering
has a clear direction.
Second, management needs to ensure that the best people in the company work
on the platform to create the highest quality with the best possible strategy.
Third, management needs to be patient and calculate from the beginning in the
right way. Effort estimations are essential. If management decides in the middle of
the platform development to skip the whole activity, then a great deal of money will
have been burned for nothing.
3.6.3 Engineering Failure
The engineering teams that create the platform must have the right mindset and have
a sense of reuse and future-proof development. If they create an architecture that is
not reusable or draw the line in the wrong way between platform and customization,
it will fail.
Engineering teams who are internal customers must accept the platform and
work with the platform team cooperatively. If this relationship is under stress, then
the result will be a great deal of trouble.
3.7 Summary and Platform Development Cookbook 147
3.7 Summary and Platform Development Cookbook
If a company decides to look into platform development, many topics must be eval-
uated and the decision must be taken very carefully. I want to provide a cookbook
with a clear step-by-step guidance to summarize the abovementioned.
Let’s assume that you are hired into a company with reasonable electronics
development, where you are responsible for creating a platform from scratch. The
expectation is that you increase efficiency and streamline all of the engineering
activities. How would you start? As I mentioned earlier, start by going into the
departments, talking with people, and finding out what the overlap is between all of
the products that the company is developing. To obtain a comprehensive picture,
also take timings and locations into account. It should be possible to come up with
an overlap landscape that leads quite easily to first initiatives.
Usually, however, you need to start one step earlier and ask the following ques-
tion: What is your understanding of a platform? The following is a final cookbook
for platform development and change in an engineering community.
1. Analysis:
• Find out what the company’s vision, mission, and values are.
• Find out what platform means in this particular department or company.
• Find out what the need is and why people are considering developing a
platform.
• Find out who the platform stakeholders are and who is rather against platforms.
• Find out what people are actually expecting from you and what the task is.
• Find out everything about past, current, and future product development:
–– How many different products there are?
–– What the usual development time is?
–– Where the development teams are?
–– Where the customers are?
–– What the requirements of all these products are?
–– What the common challenges and bottlenecks are?
–– How the budget is planned and resources are allocated?
• Talk to the lead software engineers of every single product:
–– Which tools they are using?
–– What programming language is used?
–– Which processors are supported?
–– What operating systems are used?
–– What drivers are developed?
–– What middleware is developed?
–– What applications are developed?
–– Which third-party components are used and integrated?
–– What test systems are used?
–– What tools are necessary for manufacturing?
–– What the common challenges and bottlenecks are

• Talk to the lead hardware engineers:
–– What tools and databases they are using?
–– What components and building blocks are developed?
–– What processors and ICs are used?
–– Who the suppliers and distributors are?
–– What test systems are used?
–– What manufacturing looks like?
• Talk to the lead mechanics engineers:
–– What tools are used?
–– Which materials are used?
–– Which tests are executed?
–– What manufacturing looks like?
• Talk to the predevelopment departments:
–– Which technologies are under development?
–– Which technologies are on the horizon or under investigation in research
departments?
–– What the timelines are?
• Talk to the product management department:
–– What the latest product strategies are?
–– What the competitive landscape looks like?
–– What the supplier landscape looks like?
–– Where partnerships or industry cooperation exists?
• Talk to the project management department:
–– How projects are managed?
–– Agile
–– Waterfall
–– What the expectation is in terms of budget and resources?
–– What the expectation is in terms of timelines?
–– What the challenges and bottlenecks are?
• Talk to managers:
–– How the teams are organized?
–– Which roles and responsibilities the teams have?
–– Any challenges or bottlenecks.
• Talk to the CTO:

–– What the technical strategy of the company is?
–– Which partnerships are essential?
–– What role the platform should play?
–– What the challenges and bottlenecks are?
• Talk to human resources:
–– What change management processes are usually used?
–– What incentives are possible to support a change in development style?
–– How yearly targets are handled?
–– What challenges and bottlenecks are regarding engineering career ladder?
If these questions are all answered, you can create a comprehensive overview
about the situation in the company and you can start creating a platform strategy.
2. Preparation:
• Create and align a platform story:
–– What a platform is and why it is needed?
–– How can the platform be anchored within the company’s vision, mission,
and values?
–– How can the platform be anchored in the company’s technical strategy?
–– Examples of what the platform could improve.
–– Compare expectations with your findings and align with stakeholders.
• Compare projects from analysis:
–– Compare system architectures.
–– Compare features and technologies.
–– Compare frameworks and operating systems.
–– Compare hardware building blocks.
–– Compare mechanical solutions.
–– Compare tools.
–– Compare challenges and bottlenecks.
–– Create comparison tables to find similarities quickly.
• Narrow down the reuse levels:
–– Which levels of reuse are the most promising here?
–– Align with technical specialists to create a concept for where to draw the
line between platform- and product-specific development.
• Investigate new technologies:
–– What system impacts do the new technologies have and is it necessary to
consider them in the platform development?
• Prepare options for how to set a platform organization up:
–– Potential split between innovation, platform, and product development.

–– Platform team starting in parallel or within the current setup.
–– One platform covering all topics or several decentralized platforms.
–– Which people and teams are potential candidates for managing and devel-
oping the platform?
–– What the architects team could look like?
–– What project management looks like?
–– Who the customers, stakeholders, and decision-makers are and how they
can be involved formally?
–– Discuss with management and human resources how large the change
might be and how to perform change management.
• Create a high-level project plan to create the platform:
–– What the scope and technical concept are?
–– What the effort and timeline are for developing the platform?
–– How many people are necessary and what the skillsets are?
–– The potential cost of tools, equipment, facilities, and locations.
–– The potential major milestones and when to expect a clear benefit from
platform development.
–– The plan for the rollout of the platform.
–– Which project management framework and tools best fit the platform
development (agile or waterfall)?
–– Simulate different project plan scenarios to demonstrate the most benefi-
cial scenario.
• After alignment with management, create a final plan about what to do and
who is affected.
These tasks prepare the platform development. By the end of this phase, you
should be able to show management what it is all about. Ideally you can create more
than one scenario to provide some options.
Usually, some more clarification, alignment, and negotiations are necessary
before a decision is made. However, let’s assume for the next step that everyone is
on board and management has given a clear GO for the platform development
project.
The next step is more or less a regular project setup in electronics development.
With the learnings from the first part of this book, we want to ensure that the sys-
tems engineering or system architecture aspect is set up correctly from the begin-
ning. The platform can be seen in any way as a system, and a system architect is
necessary to lead the overall architecture discussions. Even if the company decides
to develop a software platform only, it still needs to be integrated sooner or later into
a piece of hardware, and thus, the role of a system architect is unavoidable.
Yet, platform development is usually not just a project. It usually affects the
whole engineering organization. This means that a special focus on change manage-
ment is recommended to get everyone on board.
For the following execution phase, we want to briefly describe a regular project
setup but mainly focus on the platform part.
3. Execution
• Change – depending on the size of the platform and the necessary organiza-
tional change in the engineering teams, preparation is more or less necessary
to inform everybody about the change.
• Kick-off – assuming the organizational change is communicated and handled,
a kick-off with all involved people and teams can occur.
–– Invite all affected people such as stakeholders, management, and
developers.
–– Inform them about expectations, concept, scope, affected teams, and
timelines.
• Team setup – ideally, a team comprising a project manager, a system archi-
tect, and a product manager should be formed to lead the overall platform
project. The individual architects, development teams, and further project
leads depend on the size and topic of the platform.
• Project management setup – depending on the framework, the usual formali-
ties must be instantiated, such as tools, events, and cadence to set up, inspect,
and adapt the running project. Escalation paths should be defined, and regular
reporting to the necessary layers in the management should be created.
• Change management – depending on the impact, it might take time to con-
vince everybody about the platform strategy. Not only do the developers and
stakeholders need to be convinced but also – and especially – the future inter-
nal customers of the platform, who need to be involved from the beginning.
• Rollout – sooner or later the platform team will release what they have devel-
oped. The rollout requires proper planning and communication from the
beginning. Documents, training, and supporting engineers – all of these might
be necessary to ensure success.
• Releases and maintenance – depending on the long-term strategy of the plat-
form, a maintenance plan or a plan for regular releases might be necessary.
Make sure that the internal customers are satisfied with or convinced about
the platform strategy.
• Reporting and demos – besides the regular management reports, a regular
setup for platform demos might make sense to demonstrate the organization’s
progress and success. Agile development might be considered where regular
demos are a strong part of the project management framework.
• Steering committee – establish a committee of decision-makers and stake-
holders to decide the direction and priorities of platform development.
• Four principles – always remember the four principles for a successful plat-
form, and always try to achieve them:
–– Increase efficiency and quality through reuse.
–– Create something easy to use for internal customers.
–– Create momentum to make it happen.

–– Create something that really fits the company’s product landscape.
• Three main issues – always remember the three main threats to platform
development and attempt to overcome them:
–– Missing management alignment and internal communication.
–– Excessively large company size.
–– Technical scope not well-defined.
With this cookbook, you should be able to evaluate and start platform develop-
ment. Of course, many detailed aspects are necessary to investigate and consider.
However, I hope you can take this as a generic guideline for your special case.
With all of the other chapters above, you should now have a good understanding
of the aspects that are part of platform development strategies and what platform
development might look like.
This second part of the book described platform development strategies. I cov-
ered business, technical, and organizational aspects of platform development and
ended the chapter with a platform development cookbook.
In the third part of this book, I want to show you what else is going on in the
industry and how it impacts system architecture and platform development.
Part III
AI, Agile, and Organizations
Chapter 4
AI, Agile, and Organizations
In this part of the book, I want to discuss some of the topics that are all around in the
industry today and how they are related to system architecture and platform develop-
ment. I have chosen three topics that I think are the most relevant and interesting today.
The first topic is the technology of machine learning and artificial intelligence. I
want to provide an overview of the main categories and topics. We will learn what
system architecture principles are relevant and whether platform development
approaches are possible.
The second topic is agile development, which I mentioned in previous chapters
several times. I want to provide an overview of what is currently happening in the
industry, as well as what this means for system architecture and platform development.
The third topic is organizational change. Industries have undergone several evo-
lutionary steps since Henry Ford built his legendary Model T. Industry 4.0 and man-
agement 4.0 are current buzzwords. I provide an introduction and again make the
connection to system architecture and platform development.
Let’s start with machine learning and artificial intelligence.
4.1 Machine Learning and Artificial Intelligence
4.1.1 Machine Learning
The principles of machine learning go back to the eighteenth century when people
like Thomas Bayes worked on mathematical problem-solving approaches. Since
then, several steps have occurred to reach the portfolio of approaches we have today.
You may wish to view a nice timeline on Wikipedia.1
In general, machine learning can be divided into three main categories.
The first category is called “supervised learning.” Imagine that you have a system
that receives pictures as input data and outputs whether this picture shows a circle or
not. The algorithm inside the system needs to know what a circle looks like. A model
is created by training data, and it can be tuned to handle certain variations of circles.
1
https://en.wikipedia.org/wiki/Timeline_of_machine_learning
https://doi.org/10.1007/978-3-030-97695-8_4
156 4 AI, Agile, and Organizations
This model is trained using labeled data sets that say “circle” or “no circle.” After the
system is trained, it can be used as an application. If the preprocessed input signal is
equal to the model within some boundaries, the output will say “Yes, this is a circle!”
or that it is a circle with a certain probability. Supervised learning means that you
have created and trained a model and a decision instance inside the algorithm. Of
course, most applications are much more sophisticated. Face recognition and hand-
writing detection among other applications make use of supervised learning.
The second category is called “unsupervised learning.” Here, there are data sets
without any labels, and one attempts to find patterns. So-called classifiers are used
to create groups of similarities. One example is a user investigation such as correlat-
ing age or gender to certain shopping behavior. The portfolio of algorithms, cluster-
ing methods, and solutions is huge, and the scientific world has been conducting
relevant research for many decades. A good starting point for those who are inter-
ested is the book Pattern Classification from Richard O. Duda [14] or Machine
Learning by Tom Mitchell [15].
The third category is called “reinforcement learning.” This involves agents that
work through data or in an environment and get rewarded based on actions. The
reward can be positive or negative so the agents can adapt their behavior and opti-
mize their action. A clear example is an automated stock trading agent. The simple
function is “maximize money,” and the agent buys and sells accordingly. The algo-
rithms are complex and should of course be bullet proof.
All three approaches share the common feature of requiring a huge amount of
data to learn from. Furthermore, training processes must be dealt with, which might
consume a great deal of calculation power. Last but not least, real-time processing
must be considered to produce results and probabilities.
The implementation of machine learning can happen in various ways. Feature
extraction and classification algorithms could be run in real time on a DSP; Python
scripts might be run on a cloud server; a real-time sensor input might be linked to
your electronic device; or you might have massive user data as on Google, Facebook,
or Amazon and work with it.
In general, machine learning generates knowledge from experience.
4.1.2 Artificial Intelligence
AI is likely to be either the best or worst thing to happen to humanity.

– Stephen Hawking
Theoretical physicist and cosmologist
The idea of intelligent machines goes back several hundred years,2 but the phrase
artificial intelligence (AI) was born in 1956 at a workshop in New Hampshire. Since
2
https://en.wikipedia.org/wiki/History_of_artificial_intelligence
4.1 Machine Learning and Artificial Intelligence 157
then, AI has been a part of computer science, describing machine behavior that has
similarities with human intelligence. Factors in this are learning and problem-
solving. It draws upon several scientific fields such as computer science, engineer-
ing, mathematics, and psychology. It also spans from very simple machine learning
approaches to human-like robots with even more brain power than we have. The
most advanced systems today are probably in robotics and natural language pro-
cessing areas.
AI can be subdivided into strong AI and weak AI. While weak AI focuses on
certain problems such as face recognition, strong AI concerns the recreation of
human intelligence and skills. Strong AI is up to now still a vision. People talk about
“the singularity,” which is a special point in time where AI will be stronger than
human intelligence and will take over development. This is rather a chapter in a
book about the future and we want to focus here on weak AI.
AI can also be subdivided into knowledge-based systems, pattern recognition,
prediction, and robotics. Current voice assistants such as Alexa, Cortana, and Siri
are quite intelligent already. They can understand the human voice, search through
massive databases, and search for relevant answers. They can help users control
their smart home, search for their favorite song in a music streaming database, and
help them write emails and messages. The applications are increasing ever further
due to an open API standard. When Alexa starts moving, cleans my house, and
makes my coffee – that’s when it will become interesting for me. For now, I’m
slightly concerned about the massive amount of data captured from every single
user. Data privacy and ownership of these massive information databases are one of
the largest topics that the industry must solve. In terms of system architecture, the
example of voice assistants is a useful one to explain.
4.1.3 Impact on System Architecture
If we examine the aforementioned descriptions, we find algorithms, huge data sets,

training phases, smart devices, connectivity, cloud processing, and robotics. These
elements can be described easily by system architecture principles.
Algorithms:
Algorithms usually have input and output interfaces and need another interface
to configure and control them. They run more or less as software on processors.
Depending on the processing power that is necessary, one may want to choose
smaller or larger processors to run these algorithms. They can range from regular
DSPs for simple machine learning tasks up to super computers like Deep Blue.3
3
https://de.wikipedia.org/wiki/Deep_Blue
Huge data sets:

First of all, data sets need to be collected, which is already a challenging task.
Let’s imagine that you want to create a machine learning approach for detecting cars
in a picture. You need to go through a huge collection of pictures manually and note
down whether there is a car in them or not. This collection of tagged data can then
be used to train algorithms. In addition, data sets need storage space as well as some
kind of organization, such as a database. Therefore, you can easily navigate through
the data and create all kinds of search queries.
Training phases:
Most AI and machine learning systems deal with training phases. These can be
executed before the real application starts or during runtime. This of course has a
huge impact on the processing power and memory of your electronic device. For
example, if the whole training phase is offline and only the resulting model needs to
be downloaded to your device, the runtime requirements are usually much lower.
The offline training phase might be even larger with calculation times of several
days on a special computer.
Smart devices:
Following the example of voice assistants, we can see that the cloud itself does
not help if we do not have a certain distribution of small devices that are the eyes,
ears, and mouths of the intelligent cloud. Voice assistant devices are equipped with
microphones and loudspeakers, and cameras are on the way. You can combine these
with more sensors, which will immediately enhance the device and make it even
stronger than human perception capabilities. Temperature, air pressure, and humid-
ity are examples. Radars and electromagnetic field measurements are easy to add
and would be superhuman features. Compass and GPS data are already standard
features in all smartphones. Now, imagine that your smartphone is always measur-
ing with all sensors and is reporting all of the collected data back to an intelligent
cloud. The size of the data bandwidth would be huge and can only be achieved with
a sophisticated connectivity concept. Or the smartphone does some preprocessing to
reduce the bandwidth needs significantly.
Connectivity:
The interface channels through Wi-Fi or today 5G are necessary to transfer
everything in reasonable real time to the cloud and possibly back. The processing
power in the cloud needs to be high enough to process all of that and create results.
Several architectures are possible, such as very small devices as end points that send
measurement data back to the cloud. Alternatively there are edge devices in between
that capture most of the sensor data and perform a first interpretation and data
reduction.
Cloud processing:
You can rent servers, for example, from Amazon or Google, and use their AI
functions for your applications. You need interfaces into the cloud, licensing mod-
els, perhaps security checks, and a front end for your application – and of course
you need a nice application. You can offload processing and data storage to the cloud.
4.1 Machine Learning and Artificial Intelligence 159
Robotics:
This is probably the most advanced AI category regarding system architecture.
Just look at the robots that Boston Dynamics has been developing recently. These
are masterpieces of mechanical engineering, including AI technology.
I have not mentioned natural language processing explicitly as a category because
this is a mixture of most of the categories above. Algorithms are needed to detect
speech correctly; huge data sets are needed to train models; and they are probably
run in the cloud with a user interface on a personal device.
To summarize the system architecture aspect, you must deal with processing
power, memory, interfaces, distributed systems, and mechanics. Sounds familiar,
right? The complexity level and scale are higher than ever, but with a hierarchical
and systematic approach such as that described in the first part of this book – noth-
ing is impossible.
Nevertheless, there is another interesting aspect behind the combination of AI
and system architecture: the chance exists that AI and ML can enhance current tool
sets to make life easier for system architects. Many tasks involve data, comparisons,
decision finding, and work according to certain rules. This presents a huge opportu-
nity to automate these tasks and processes with the help of AI and ML. Thus, it is
not only relevant to create an AI and ML system with system architecture principles
but also very interesting to solve system architecture challenges with AI- or
ML-enhanced tools.
4.1.4 Impact on Platform Development
How can we create platforms or reusable components for machine learning and AI?
We can use the same principles as mentioned earlier in the platform chapter: we can
look into our systems and applications and estimate the future market, finding simi-
larities between products and applications. What kinds of components need to
always be there? Perhaps it makes sense to implement some of the classification
approaches and reuse them where possible. Perhaps a cloud and a powerful inter-
face into it are always necessary. Invest into the reuse of this part. It is also possible
that the data collection is always similar; therefore, invest to have a common tool
and database setup. Thus, it depends on your technical and product strategy. If you
estimate your future activities for machine learning and AI, you will see where the
overlap is and where a platform approach makes sense.
Companies have also developed platforms to support machine learning and
AI. That is of course also possible. Then, not only is reuse considered from within
a company but also the platform can be sold to others to be integrated into their
products.
4.2 Agile Development
Agile! This topic is also not really new, but today the timing seems to be right and
everybody wants to jump on the train. Today’s technologies become increasingly
complex, markets and products are changing fast, and the need for agile develop-
ment as a solution is high to handle the pace of change. Transforming an organiza-
tion with agile development methods sometimes does not only target the project
management setup. Agile is also used to transform an organization, with agile only
set as a trigger for other things. Let’s focus here on topics that are relevant to project
management and development processes only.
The term agile in a development context was first used during the legendary
Snowbird meeting in Utah in 2001, where some software people came together to
talk about revolutionary methods for software programming. Extreme program-
ming (which is quite similar to Scrum) had already been established, but many
people were still frustrated by heavy software development processes and very long
development times. Complex systems such as space shuttles had development times
of more than 20 years. Can you imagine? How can someone capture requirements
and create a concept and 20 years later finish the implementation? All of that was
planned with the waterfall project management method. I will return to this later.
Those people in Utah created the Agile Manifesto.4 This paper describes the
main principles of agile development, but the roots go back to the 1960s when
people began to attempt rapid development. Even Scrum, one of the most popular
agile methods, was developed earlier in 1995.
Agile is a mixture of project management and development processes. Scrum as
well as Kanban could be considered pure project management methods. Other agile
methods such as test-driven development, pair programming, and continuous inte-
gration are rather on the software development and even quality assurance side.
I want to start here with the project management side of agile and compare it
with other methods.
Perhaps the exact opposite of agile is the waterfall development method. I will
compare waterfall and agile, but let’s first recapture what kind of development flow
makes sense in general. I refer back to a previous chapter in which I described the
so-called V model.
Everything starts with requirements. The very first thing should be to write down
what you want to achieve. It doesn’t matter how well-defined or detailed that is, but
please write something down to refer to it later. The second thing is to create a con-
cept based on the requirements that you have described. The third thing is a design
that is as detailed as possible or necessary in that stage. The fourth thing is to
develop what you have designed. Finally, the fifth thing is to test it. That’s it.
Requirements – Concept – Design – Implementation – Testing. Now, let’s see if
there is a difference in that flow between waterfall and agile.
4
https://agilemanifesto.org/
4.2 Agile Development 161
Fig. 4.1 Waterfall flow
4.2.1 Waterfall vs. Agile
The development of the waterfall model has undergone several stages and was first
mentioned in 1956 in a paper about software development. Over the next decades,
it was refined and finally adopted by the US Department of Defense as a standard
for handling contractors. The waterfall model describes a way to handle the devel-
opment process steps in a certain order (Fig. 4.1).
Here, you can see that all activity starts with requirements. When this step is
done and requirements are fully described, the design can be created. Then, one
enters the implementation phase. The nature of the pure waterfall model is that one
step must be fully completed before moving onto the next step. Several problems
can arise with this approach:
• Requirements are often not complete from the beginning. Changes afterward
require the process to be completely restarted, which is usually not a big deal if
the changes are small. However, the larger they are, the greater the need to restart
the process.
• Long development times risk the requirements already being outdated when the
implementation starts. This is very obvious in the automotive industry for navi-
gation system development. The development time is usually 2–3 years. Adding
concept phases results in development times of 4–5 years. When the car is finally
on the street, the navigation system is already outdated. Today, this situation is of
course improved due to software updates over the air, but the hardware is still old.
• Short-term decisions about priorities or feature changes are not easy to integrate
in later stages. The same goes for change requests.
• Translating requirements into specifications and specifications into implementa-

tions includes handovers with misunderstandings in all kinds of flavors. Also
here – the bigger the package, the higher the chance that you miss something,
causing extra effort later.
Thus, the waterfall approach can work if the requirements are absolutely clear
from the beginning and no change in direction is expected during development.
Then, it fully follows the flow described above. However, clear requirements and no
change in direction – is this the case in today’s software or system development?
Basically, the waterfall process is too rigid for complex software or system
development, which is why agile entered the stage.
Agile development methods are iterative. They also follow the full development
flow but with much smaller cycles. They are created to deliver fast and obtain early
feedback from users or stakeholders. This has the benefits that products are in the
hands of the end-user faster and that feedback is much faster back in the develop-
ment team. The team is committed to adapting its direction quickly based on feed-
back and priorities, so all of the problems described above are addressed through
short feedback cycles and transparency. Finally, the team is committed to continu-
ous improvement. Every sprint ends with a retrospective where everyone has the
chance to speak up and talk about potential improvements for the next round.
One thing that cannot be missed from a comparison of agile and waterfall – or if
we examine the quality of project management in general – is the “Chaos Report”
from the Standish group.5 Here, one can find many detailed charts and statistics
about how successful projects are. I wish to list the following to summarize some
interesting facts:
• Approximately 50% of the features of large software products are not used at all.
• Small projects have a higher success rate than large projects, and agile vs. water-
fall doesn’t really matter in that case.
• The larger the project, the higher the failure rate if managed by waterfall.
• The success rate of large projects is higher if managed by agile.
The first point is particularly fascinating. Imagine discovering during your devel-
opment that you can skip the development of 50% of the features. Imagine how
much time and effort you would save! Agile has the benefit of checking from the
beginning with users, stakeholders, and customers whether the direction is right and
whether the objectives for the next weeks are of maximum value and also whether
it is working with a prioritized backlog. The most important thing is always next. If
at the end of the project development period some items are still in the backlog, they
are automatically the least important ones – and skipping them will not hurt.
Another report worth reading is “Pulse of the Profession” from PMI.6 For exam-
ple, the 2017 report states that 71% of companies are using agile project manage-
ment methods somehow. Huge hype exists at the moment.
5
The chaos report is a project management quality research activity for IT projects. www.standish-
group.com.
6
Pulse of the profession is a global survey activity for project, program, and portfolio management.
www.pmi.org.
However, let’s return to a more detailed view. Agile also concerns team spirit,
team empowerment, and cooperation to a large extent.
The Agile Manifesto describes 12 principles that I summarize as follows:
• A happy customer is the highest priority.
• Requirements can be changed during the whole development cycle.
• Deliver working software frequently in short cycles.
• Developers and business people need to be connected very well.
• A supportive environment of trust and motivation for developers is key.
• Self-organizing teams are key for high quality.
• The team itself reflects regularly about improving themselves.
• Face-to-face meetings and co-location are always preferred.
• Working software is the primary measure of success.
• Technical excellence and strong designs are continuously in focus.
• Simplicity is essential.
• Sustainable development and a constant pace are the nature of agile.
Thus, one can see a good mixture between software-related and people-related
topics. This, in my view, is one of the key factors of agile: the engineers and their
cooperation are key to success. I personally have had the best experience with engi-
neers who do not put their career over that of others and who are able to create a
trustful and respectful environment within the team. For people who are used to
working in an isolated manner and not cooperatively, they cannot be managed
through project management such as Scrum.
Ken Schwaber and Jeff Sutherland, who were some of the creators, had pub-
lished an earlier paper about the Scrum software development process, which is one
of the most popular agile methods today.
4.2.2 Scrum
The thing that cripples communication saturation is specialization—the number of roles and
titles in a group. If people have a special title, they tend to do only things that seem a match
for that title. And to protect the power of that role, they tend to hold on to specific knowledge.
– Jeff Sutherland
One of Scrum’s inventors
The Scrum framework has been well-described but is not easy to use. It provides a
framework of team roles, events, and work product artifacts. Under some circum-
stances, it works perfectly if you stick to the rules 100%. The more one deviates, the
more efficiency one loses, potentially even more than without using Scrum.
Furthermore, it doesn’t make sense for all kind of projects. You will learn later how
to decide which project management methods fit your needs.
To learn more about Scrum, I recommend a book by one of its inventors such as
Scrum: The Art of Doing Twice the Work in Half the Time by Sutherland [16] or
Software in 30 Days by Schwaber [17] as a starting point. But ultimately – try it out!
Scrum defines the following:
• Roles – In a Scrum framework, there are developers, scrum masters, product
owners, and stakeholders. The developers are just developers: no architects, no
testers – just developers. It might happen that former architects need to do testing
work and vice versa, which has many positive aspects. Scrum masters are the
process supporters. They need to take care of the team meetings and make sure
that the team has everything it needs and that no impediments are slowing it
down. The product owner takes care of stakeholder management and needs to
ensure that the development occurs in an order of “most valuable first.” He or she
maintains the backlog and sets the priorities of development tasks.
• Events – Scrum has defined meetings such as daily stand-up, sprint review, ret-
rospective, backlog refinement, and sprint planning meetings. All events have
certain rules for how to run them, and especially the scrum master needs to make
sure they are being held efficiently. The most important event is the sprint itself,
which is defined as a time-boxed development period to work on a fixed scope.
Usually, the sprint represents a full V model development cycle. Everything that
the team is showing after the sprint in the sprint review should be fully tested and
validated.
• Artifacts – Artifacts in Scrum are physical things. The product backlog is a list of
topics and tasks, similar to requirements that the product owner has negotiated
with the stakeholders and detailed with the development team. The sprint back-
log is the part of the product backlog that is currently used in the running sprint.
The product increment is a result of the sprint that might be shippable to end
customers. It is functioning and fully tested.
When I first learned about Scrum, people thought that it was a theoretical
approach for better communication in software development. I had training and all
that we used was the daily stand-up afterward. Everything else seemed not to be too
relevant for us. By that time, I was team lead in a DSP department and we had well-
defined structures, plans, roles, and responsibilities. The team had great motivation
and was performing very well. We worked mainly on very clear defined tasks in
product development and used waterfall planning with Gantt charts7 among other
things. That was somewhere around 2009 or 2010.
The second time, I was working in a technology development department, and a
top-down decision was made that we all use Scrum now completely. We all received
training again. Scrum masters and product owners were assigned and went through
training and certifications, and we had a consultant who helped us make it happen.
By that time, Scrum was an eye opener to me. It solved so many problems that we
7
A Gantt chart is a planning diagram usually used in waterfall planning. The name comes from
Henry L. Gantt, an engineer from the United States.
had in the organization immediately, and I was totally convinced. I’m still using
Scrum today, but I also see that it doesn’t work in all environments. It definitely
works for small feature teams who can create a technology in 6–12 months. Then, a
Scrum approach with zero deviations from theory makes sense.
However, the problems start with the surrounding environment. If the stakehold-
ers do not really accept this process and do not show up at sprint reviews, then the
important element of feedback loops is missing. Another problem occurs when the
developers are so specialized and the roles are so different that no homogeneous
team can grow. Yet, as I mentioned earlier, I have found that the most important
thing is the mindset of the people. The product owner should not act as architect and
start micromanaging. He or she is only interested in features and what to do. The
development team decides how to do it. The Scrum master is not a project lead who
gets reports from developers, but rather a supporter destroying roadblocks for the
team and always triggering them to come up with more improvements. The devel-
opers need to have a strong attitude of respect for each other. Team spirit is key to
all Scrum activities.
Another problem can occur if projects are growing. What happens if you have a
huge software product and the development team exceeds the theoretical number of
nine developers? A scaled Scrum approach is required, which is detailed below.
The last issue that I want to mention here concerns project timing and different
project management styles. It can be quite tricky if you have a clean Scrum frame-
work up and running but you are delivering your product as a subcomponent for
further use in a pure waterfall-driven organization. Again, see below for further
details.
Let’s first examine large software products.
4.2.3 Agile Development for Large Projects
The nature of Scrum is to have small teams of three to nine people working together
on a project. However, what happens if you have a software project with several
dozens of developers and a much larger product than one team can develop? The
industry has defined some approaches to scale Scrum to larger software products.
Scaled Scrum approaches include Nexus, LeSS (Large-Scale Scrum), and SAFe®
(Scaled Agile Framework). The general idea is always that small development
teams deliver to higher-level teams and so on until the full product is complete.
Several new rules, artifacts, teams, and meetings might be necessary. The following
approaches are most common today:
• Nexus: The idea here is to have an organization layer on top of a number of
Scrum teams. The planning and retrospective occur for all teams at once. In addi-
tion to the development teams, there is an integration team that brings all of the
pieces together. Thus, the dependencies between teams can be managed. Nexus
involves using the Scrum ideas to scale.
• LeSS: Here, a scaling is realized by combining events in addition to the single

Scrum events. The sprint starts with planning for all teams followed by individ-
ual sprint planning per team. The teams run their sprint with regular coordination
between them and come together in an overall sprint review at the end. Therefore,
the scaling is usually done with extra events on a combined level. The Scrum
philosophy is also not corrupted.
• SAFe: This is the most comprehensive scaled Scrum approach out there at the
moment. Here, the individual feature teams still run in a Scrum or agile frame-
work, but there is much more on top of it such as release trains, solution manage-
ment, value streams, portfolio management, and strategy. Therefore, this
approach considers the whole portfolio management of a development area.
When we created the software platform in one of my previous positions, we went
through a huge learning curve. We started with small and individual teams and
quickly saw the need to combine all of them into a bigger picture and a comprehen-
sive software product. We ended up with a mixture of Nexus and LeSS, which
involved
• Using a so-called sprint zero to define the next 3 months on a higher level
• Having an integration and test team putting the pieces together
• Organizing communities of best practice to discuss cross-team architec-
tural topics
This worked quite well and was perfectly tailored to our needs. The only issue
was the waterfall environment that we lived in. It was still the good old automotive
industry with its rigid timelines and SOPs. Let’s see what happened in the next
chapter.
4.2.4 Scrum in a Waterfall Environment
How one should work with Scrum in a waterfall environment is fascinating. Let’s
imagine that you have created Scrum teams in your organization to develop new,
innovative technologies. Budgets are set, development cycles are time-boxed, and
stakeholders are happy with what they are getting for their money. They are part of
the biweekly sprint reviews and immediately see where their money is going. They
trust the Scrum teams and believe that they create the maximum possible value out
of the given time and money. Perfect.
However, what happens if these technologies should be delivered to a product
development unit with very strict, rigid waterfall planning and development pro-
cesses? In other words, what happens between technology development and product
development?
Fig. 4.2 Complexity diagram
One answer can be found in the so-called Stacey Matrix,8 which has been slightly
reinterpreted into a complexity diagram in Fig. 4.2:
In the figure, technology and requirements are plotted on the x and y axes,
respectively. Both go from well-known to unknown. Imagine that you know exactly
what to do and how to do it. This is a fairly simple case, and a very detailed process
can describe and control the development. You might want to use pure waterfall
project management. Imagine a complicated environment as the next level. It might
still be possible to use waterfall planning. The next level is the complex world.
Requirements can be totally unknown, and how to realize it is also unknown. Here,
agile development methods enter the game and create full benefits because one must
find out certain things during the development. With agile, this is possible. Above
all of that in the upper-right corner is chaos. It is very difficult to manage something
here. Let’s say that this is the area of innovation where different approaches such as
Design Thinking must come forward.
For the sake of comprehensiveness, let’s define the terms complicated and
complex:
• Complicated – Imagine an analog watch from Switzerland. It looks very compli-
cated with all of those gears and moving parts, but it is only complicated for
someone who is not an expert. It is fully controlled. Time runs in exact, foresee-
8
Ralph D. Stacey was a Professor of Management at Hertfordshire Business School in the United
Kingdom who wrote several books about management and the complexity of organizations.
able movements. If a button is pressed, the watch always reacts in the same way.
Therefore, things are only complicated for nonexperts in this field. A compli-
cated technology development might look unmanageable, but to experts it is a
piece of cake, and they can precisely anticipate the outcome.
• Complex – This is totally different. Something is complex if its reactions cannot
be foreseen. Often it has to do with people. Teams are complex because every-
one’s reaction and actions cannot be foreseen. Soccer games are complex because
you cannot foresee the outcome. Thus, a complex technology development has
no defined outcome.
Now, imagine that you are working in a company that is creating innovations.
That would rather be in the complex and chaos area of the diagram. Therefore, you
might want to use agile methods to develop those innovations. The further down you
get into product development, the more requirements and technologies are well-
known, so waterfall planning makes an increasing amount of sense. This goes down
to the very bottom-left corner where manufacturing occurs. In manufacturing, you
know exactly what to do, so agile should not be used here at all.
This means that it is natural in electronics development for agile methods to have
to transition somewhere in the development flow into a more waterfall-driven envi-
ronment. Usually, products have hard deadlines, and project management wants to
finish the development by a certain point in time. A key element is a solid approach
to effort estimations in Scrum. Another key element is the stability of the teams. If
these two elements are set up in the right way, then it will enable the product owner
to create very solid time plans and milestones and to adapt easily to a waterfall
environment.
To complete the picture, I want to present another agile process called Kanban.
4.2.5 Kanban
Kanban has its roots in Toyota manufacturing plants in Japan. There it was devel-
oped to optimize the workflow through the manufacturing lines. Kanban works with
signal cards on a Kanban board. The main motivation was to optimize the workflow
and minimize storage space.
Kanban in software development is slightly different. One still works with a
Kanban board and cards. The difference to Scrum is that there are no definitions for
certain roles, events, and artifacts. You rather reuse your existing processes and can
add Kanban on top of them. The following best practices are usually employed:
One main aspect of Kanban is visualizing work phases. Usually, teams use large
Kanban boards or white boards where individual phases are sorted in columns. They
could be requirements, concept, design, implementation, and testing according to
the V model, but they could also be backlog, planning, development in progress,
development finished, and release. Furthermore, it could also be on a higher level,
such as for managing a portfolio. The existing development process can still be
maintained. The individual tasks are written down on cards, or so-called tickets, and
they move from left to right.
Another main aspect is limiting the number of tickets per column. This depends
on the team size and complexity of the tasks. Let’s assume that you have two devel-
opers, where you might want to limit the number of tickets in the “development in
progress” column to two. This can also be handled based on effort. Every ticket
should include information about the development effort. You can also limit the
amount of effort per column. Whoever is responsible for working on tasks in a cer-
tain column can pull tasks from the previous stage. This pulling mechanism is
another key aspect that goes with ownership and motivation.
The third aspect is measuring and managing the work flow in the individual col-
umns. If you find that you have long waiting times in one of the columns, then this
might be a bottleneck where optimization would be most effective. This could mean
increasing the team size or optimizing the development process or similar. Improving
the process continuously is another key aspect. Overall, this leads to a reliable plan-
ning capability for the whole team.
The next aspect is to explicitly write down the rules for the whole process. The
definition of done or the meaning of the columns is something that everybody in the
team needs to understand and follow.
The following aspect is to implement feedback cycles. Retrospective meetings
such as in Scrum or daily stand-ups are possible, but not mandatory as they are
in Scrum.
Last but not least, Kanban uses models to find potential improvements in col-
laboration with the teams and setup of the process. So again, it is a tool that continu-
ously improves the overall process.
Therefore, Kanban is more flexible in terms of task changes and backlog changes.
Whatever comes next can be given to the teams immediately. Compared with
Scrum, you do not have to wait until a sprint is finished.
The tickets can include information such as task name, effort, and value or prior-
ity. With the latter, the agile aspect again fully enters the game.
A combination of Scrum and Kanban is possible in technology development.
Let’s imagine that there are several development departments in your company,
namely, regional departments, platform development departments, and product
development departments. In all areas there are engineers who want to sometimes
be involved in creating new things and innovations. Let’s also imagine that the
capacity of the teams is not fully squeezed out and sometimes a team has the band-
width to work on innovative topics. Kanban is a perfect tool for managing this. You
could have concepts and ideas in the backlog, and whichever team has time could
pull a topic and start the development. The development itself could be organized
using the Scrum framework, allowing the complexity of an innovative task to be
handled. Thus, portfolio management is performed using Kanban, while the tech-
nology development uses Scrum.
In my view, all of these agile methods have huge potential. As I described earlier,
it was an eye opener for me when I started with Scrum some years back. However,
there are also drawbacks that can make one’s life difficult:
Co-location is one of the main aspects of Scrum. During the time I worked with
Scrum teams, we unfortunately created a worst-case scenario. One engineer was on
the US west coast, while two more were on the east coast; three were in Germany;
and two more in India. This was not the only team that was so scattered in terms of
co-location. The whole product consisted of five teams in total and did not look bet-
ter, but we had no other choice. Here, it was really tricky to run Scrum. The Scrum
master had to develop little games and tricks to motivate the team and make the
work as collaborative as possible.
If you have the chance to create an organization from scratch and you want to use
Scrum, please make sure that you have local teams only. This is so much more
efficient.
Another aspect is the promotion of developers in Scrum teams. The whole human
resources process must be redefined. Individual targets are hard to set because it is
always the whole team that owns something. Promoting people in the team can’t be
combined with more responsibility easily. It also depends highly on the mindset of
the developers. If they were to be promoted from software developer to architect
and start working on architectural tasks only, then the whole concept would
become tricky.
One can find other aspects of agile development in the relevant literature, such as
vertical teams or potentially shippable products. Below, I summarize the most
important aspects to system architecture design and platform development strategies.
4.2.6 Agile Development Methods
Now that we have covered the project management aspects of agile quite well, let’s
also look into the development methods. They can all be combined with Scrum
and Kanban.
First, I want to look into software development in general. Look at your team of
software developers, and investigate the education, experience, skillset, develop-
ment style, and character of the individual people. They are all individual humans
and thus all different, so how can you make sure a homogeneous software product
comes out of a heterogeneous team of developers? I’m guessing that you want to
have a product that is at least consistent in terms of quality! Let’s sketch the extreme
cases. Imagine you have developers who
• Like to document their work or don’t like to document it
• Like to have reviews of their code and change it and others who do not
• Like to adapt to commonly agreed coding styles and those who do not
• Like to create unit and integration tests for their work products and others
who do not
• Like to create reusable code and others who do not care
• Are very skilled and fast and others who are not
This is potentially a very heterogeneous team in terms of quality. What are the
important points to create high-quality software? From my experience, the follow-
ing are the main aspects that ultimately decide overall quality:
• Documentation
• Design and architecture
• Coding styles
• Reviews
• Tests
How can you increase quality and train engineers to reach a certain level of engi-
neering excellence? In an ideal case, you want to have a team that is constantly
growing in terms of software development quality. They will become increasingly
experienced and skilled. Luckily, agile development has some methods to clearly
support this.
4.2.6.1 Pair Programming
Pair programming is simple. Two people sit in front of one PC and write source
code. One writes and the other one thinks about it, corrects it, discusses it, or com-
ments on everything, and vice versa. These two people can also change often so that
everybody sits together with everybody else in the team at least once.
Usually, this takes a little longer than having two engineers working in parallel,
but the resulting quality is in my view so much higher that it is always worth trying
here and there. There is also scientific evidence for this. Especially for pairs with
different skillsets, it can be highly beneficial for the person with the lower skillset to
have a very fast ramp-up in software coding styles and architecture.
The quality is higher because you are automatically reviewing the source code
using another person. Two people discuss the design and architecture and immedi-
ately come up with the optimal solution, and two people who check the coding
styles using the four-eyes principle. Moreover, it is a real face-to-face collaboration
that is usually a much more fun way of getting to know other team members
much better.
4.2.6.2 Test-Driven Development
Surprise, surprise – this is all about testing. Basically, the concept here is to write a
test first, let it fail, and then create the functionality until the test does not fail any-
more. This method makes sure that every software function has a test at the end,
which is of course beneficial for the overall quality of the source code. Here, people
also argue about the extra effort, but one would want to have these tests anyway.
Furthermore, an extra benefit is obtained from the fact that the developer needs to
look into the task at design time from another perspective. Thus, the overall quality
of the solution is usually better than if you had not started with the test creation.
In my opinion, this is a very nice concept but difficult to achieve for all develop-
ers. It heavily influences the individual development styles and for some people is
hard to accept. It helps to have a test framework and an automated build system to
speed things up and support this idea.
4.2.6.3 Code Reviews
Conducting reviews of the source code is, in my view, mandatory. It covers so many
aspects that there is no excuse for not doing it. However, it is again also a mindset
thing for developers. They need to be open to showing their work products to others
as well as flexible to react to comments and criticism. Moreover, they want to con-
stantly learn and improve themselves. This is possible in a trustful environment
where performance measures are used very carefully.
For me personally, code reviews are the strongest method for improving software
quality.
4.2.6.4 Cross-Functional Teams
Another aspect of agile development is having team members who cover a wide
range of skills. A certain diversity is usually beneficial for problem-solving and out-
of-the-box thinking. However, one must be careful when setting up a team of spe-
cialists. They need a certain overlap in their skills that fit the current task such that
they can share tasks within the team. If you end up with five specialists working on
their own in isolation, then Scrum would no longer be required.
However, a cross-functional team is highly beneficial if you need to realize verti-
cal features requiring several functions to work together. Thus, whether a cross-
functional setup is required always depends on the scope of the team.
4.2.7 Continuous Integration and Automation
One main aspect of agile is that there is always a potentially shippable product ready
after, for example, a sprint. This means that the overall software product needs to
have very fast and short integration cycles to ensure that everything is fully working.
Continuous integration is the process of integrating small parts of software updates
immediately and trying to build and test with the updates. Usually, this means hav-
ing a special server, where code can be uploaded and an application is running that
compiles the source code, integrates it into the overall product, and tests everything
automatically. Thus, the developer receives immediate feedback if his or her updates
are running in the system or breaking it.
Here, automation is one of the key aspects for speeding up the whole process.
For example, the developers create source code the whole day and check it in, and
the continuous integration server builds and tests everything overnight. The
developer returns to the office in the morning and has a result. A precondition is of
course a proper setup of the overall system, which is usually a huge effort. Moreover,
the developer needs to make sure that his or her own unit tests are uploaded so that
the server can run them.
In my view, agile development and automation are tightly coupled. Due to the
fact that agile development theoretically goes through the whole V model in each
sprint, it also produces new tests in each sprint. If these tests cannot be automated,
then the team will quickly find itself doing manual tests and no more development.
This means that new tests must be integrated into the automated test framework so
that the team can focus on new feature development.
4.2.8 User Stories
This is an interesting aspect. If you are following the V model, you usually start with
requirements. Then, a concept is created and a design follows on different levels.
When you are down at the bottom and implementing your functions, the big picture
can be lost, which is a bit dangerous. Remember the requirements chapter in the first
part of this book. Making sure that everyone knows what to do all the time as well
as how to do it helps greatly to avoid mistakes and misunderstandings.
A user story creates a different perspective for the developers. In a Scrum frame-
work, the product owner creates a user story by saying something like “as user of
this product I want to have this and that functionality doing this and that.” Thus, the
owner is describing what to do, and now the developers are responsible for saying
how to do it. This creates a sense of value for the developers, and it always helps to
have the big picture in mind.
The user stories can be organized as paper on a board with information such as
effort, risk, description, and priorities, as well as a definition of done. The same can
be done digitally in a system like Jira. It makes sense and is part of agile develop-
ment that the user stories individually go through the V model. The definition of
done then contains test criteria and expectations for quality.
4.2.9 Effort Estimations
Effort estimations in agile development require special attention. I always remem-

ber one colleague who said, “Now we are doing Scrum and now we don’t plan
anymore.” It seems to be a common misunderstanding that planning, milestones,
and roadmaps are not possible within agile development frameworks. My personal
experience is exactly the opposite. The artifacts and events in Scrum deliver an
excellent framework for planning as far in advance as necessary and possible.
Furthermore, the quality of work breakdown structures and detailed effort estima-
tions can be extremely high due to the fact that teams have so many discussions
about architectures, tasks, and solutions and also meet daily in the daily stand-up.
The effort estimations follow a concept of relative estimations, as opposed to the

absolute estimations in traditional project management. If a task is considered large,
for example, then the following estimations could be extra-large, medium, or small
compared with the first task. This concept of using T-shirt sizes is well-known and
widely used.
Effort estimations usually occur in team meetings, where every team member
estimates the effort for a task based on Fibonacci numbers. This could happen anon-
ymously using concepts such as the so-called Scrum poker. A fruitful discussion can
occur after everyone has shown his or her numbers. This concept of estimations has
several positive side effects such as knowledge sharing, improved architectures, and
enhanced solutions.
This high quality of effort estimations in combination with stable teams leads to
a predictable amount of work that a team can do per sprint. This so-called velocity
then becomes the base for proper long-term project planning.
Let’s now look into the impact that agile development has on system architecture
and platform development.

How can we combine agile development and system architecture design? How is it
possible to develop a platform with agile development methods?
Remember the development cycles of agile and how fast you need to go through
the V model in each sprint; this is already part of the answer regarding system archi-
tecture. In principle, there are two choices. Either you separate the system architec-
ture design phase from the implementation phase and run it in separate sprints, or
you try to create vertical topics and finish one module after the other, hoping that
your system architecture is still valid when everything comes together. The larger
and more complex the system is, the more difficult it will be to work in the second
mode. However, there is a famous example where a team built a car using agile
methods in only 3 months.9 In my view, the secret lies in three main points:
• Definition of the minimum viable product (MVP): In software development, it is
much easier to create something shippable after each sprint. The development
cycles are rather fast compared with hardware or mechanical development.
Especially in hardware development, there is no chance to have another fully
tested increment of a PCB after each sprint, which is 2–4-week long. However,
if you redefine your MVP, which is allowed to deliver intermediate steps – then
you are fine! Deliver a placement study first, deliver interface definitions next,
and so on. The product is growing, and you still can apply agile principles and
9
https://en.wikipedia.org/wiki/Wikispeed
deliver something fully tested after each sprint. The same is valid for the overall
system architecture!
• Modularity of the overall system: This gives the opportunity to develop smaller
pieces in smaller steps with better control of the overall complexity. Modules are
interchangeable and can also be updated independently. This provides much flex-
ibility and makes agile development possible.
• Simulation wherever possible: This accelerates the development process signifi-
cantly. Hardware and mechanics can be simulated up to a certain point, and in
combination with the redefinition of the MVP, the simulation result is a very
good incremental delivery after a sprint.
In any case, an overall idea, concept, or high-level system architecture needs to
be in place before starting with something.
In my experience, redefining the MVP is the strongest instrument for applying
agile development to all kinds of development tasks. Remember the first part of the
book where I wrote a great deal about RFQ phases in the automotive industry – this
can be seen as a typical agile development sprint. You have 2–4 weeks to create a
high-level system architecture and use it as a baseline for the commercial offer. This
could be your first sprint of a development project. When this is finished, divide into
modular subtopics, and let the subdomains run individually in further sprints.
Let’s see what impact we have for platform development strategies. Basically,
there are two aspects that I want to discuss here. The first is how to use platforms in
agile system architecture design, and the second is how to develop a platform using
agile development.
I already mentioned platforms for system architecture design in the first part of
the book. For the main system architect, it is essential to know what is available in
the company and which platforms need to be considered for the design activities.
So, for the architect, it is an aspect of make, buy, or reuse of technologies or archi-
tectures for the design. I do not see a special impact in the combination with agile
and platform in this sense.
Developing a platform and the processes around it can benefit greatly from agile
development. The following points describe the details:
• A platform usually has a first development phase where the direction is not yet
very clear. Agile helps regarding the flexibility. Changing the direction is not an
issue in agile development.
• Platform development is usually a significant investment from the company, and
stakeholders want to know where their money is going. Sprint reviews can be of
much help in creating transparency and immediate influence from the stakehold-
ers if they want to change direction.
• Usually a platform has many customers and users. Creating user stories covering
all of these different views and aspects helps to create transparency for each
developer regarding the final outcome.
• From the beginning, a platform is usually under time pressure and people want
to use it sooner rather than later. The concept of MVP can help here to ship early
stages of the platform so that users can either try out what they will get later or
already fully use a subset of functionalities.
• Usually the success of a platform is also defined by how easily it can be used by
the customers and users. Here, the concept of MVP is also a great help in getting
early feedback and changing direction or priorities if necessary.
• Usually, platform development is not just a development task that someone has
specified and someone else implements. Rather, it is an activity where you need
the best people in your company to sit together and create the best possible prod-
uct for the next couple of years. Thus, team motivation, collaboration, owner-
ship, and passion for the platform development are essential to achieve good
results. Agile development is precisely the right tool to support this.
Therefore, developing a platform using agile development can be seen to have
definite benefits and should be seriously considered. However, please don’t miss the
point in time where the development is more or less done and your platform goes
into maintenance mode. This can happen by handing over to a different team, and in
terms of agile, it is not too important anymore to run in Scrum or similar frame-
works. A Kanban board might make sense for handling tickets about bugs, change
requests, and feature requests, but this depends on the number and complexity of
changes. Usually the platform is used in many projects, and waterfall and fixed
milestones are rather likely part of the daily work. Furthermore, the changes are not
complex anymore, so agile development no longer has extra benefits.
I have described agile development and its impact on system architecture design
and platform development strategies. This is a popular topic at the moment in the
industry, which in my view is for good reasons.
Let’s move on and discuss the last topic in this book, seeing how organizations
are changing in general at the moment.
4.3 Organizational Change
The most obvious characteristic of science is its application: the fact that,
as a consequence of science, one has a power to do things. And the effect
this power has had need hardly be mentioned. The whole industrial revolution
would almost have been impossible without the development of science.
– Richard P. Feynman
American Theoretical Physicist
As I mentioned above, industries have undergone several revolutionary steps, but

let’s not start too early. Henry Ford and his way of producing cars was for sure a
significant milestone to the industry we have today, but in fact that was already
Industry 2.0. Common sense dictates the following:
• Industry 1.0 – the time of water power and steam engines
• Industry 2.0 – mass production such as that by Henry Ford
• Industry 3.0 – automated and computer-aided production
4.3 Organizational Change 177
What is Industry 4.0 and does it have an impact on system architecture and plat-
form development?
Organizations are changing drastically at the moment. The good old boss who
tells you what to do is quite outdated these days. Why is this the case and what
implications does it have for management and organizations? What is manage-
ment 4.0?
4.3.1 Industry 4.0
Industry 4.0 is a term that was first used in Germany in 2011 and 2012. It was a
name for a study by the German government regarding the next steps in the industry.
Whether or not this term is questionable or should be renamed to something such as
the second wave of Industry 3.0 does not matter here. Industry 4.0 is a common
term, and I want to use it to describe the new tendencies in production.
Its motivation is of course to make more money. In production, it is all about
efficiency, and in today’s complex world everyone wants to have individual person-
alized products. So, how can an industry produce millions of products that are all
slightly different and personalized?
The idea here is to have highly flexible and customized mass production. Let’s
imagine that we put together AI, robotics, and IoT10 – and the result is a fully con-
nected, automated, self-optimizing production. The high grade of automation makes
it possible to decentralize production units as well as make them flexible in terms of
their location. Thus, a scenario could be that someone wants to have new sports
shoes and configures the pair on the website. He or she configures colors and the
material and maybe also uploads a footprint so that even the size can be fully per-
sonalized. The shopping request is handled digitally – no human is involved at all.
The shoemaker has a small, fully automated production location somewhere in each
major city, and the production of the new shoes starts immediately. Every step is
watched and controlled digitally, and the customer can even see on the web page
how his shoes are made in real time. After completion, the shoes are packed. An
autonomous transport vehicle picks them up, and the customer gets a notification
when the shoes arrive at the front door. The production is fully automated and full
of sensors. A central AI system in a data center watches the quality of the production
cycles and automatically refills the materials, repairs tools, controls costs and prof-
its, and performs power control. Today, this still sounds a little like science fiction,
but it is not far off. Adidas have trialed fully automated factories in the last years in
Germany and the United States, so technically most of it is possible already.
Industry 4.0 has four main design principles that lead exactly to what was
described above:
10
Internet of Things – a term commonly used today to describe network connections and intelli-
gence between all kinds of electronic devices.
• Interconnection – Everything is digitally connected and can exchange informa-

tion and control data.
• Information transparency – Information is highly transparent and available to
anyone who wants to see details in every production step.
• Technical assistance – Information and mass data are visualized in a useful way
to manage the production, and physical assistance occurs through robot-like
extensions.
• Decentralized decisions – The production is divided into several subsystems that
can act autonomously and make decisions automatically.
What is the impact on system architecture and platform development? Let’s put
it this way: all of these new production tools are electronic devices. Some are sim-
ple, while others are highly complex. Everything is somehow connected and the
topic of distributed systems is much more relevant than ever before. In addition,
numerous software packages are running on these electronic devices. All of this
requires a proper system architecture to design it and make it work. Whether plat-
form development plays a role depends on which devices in the production chain
you want to develop, but the same principles as above exist. Wherever there is an
overlap, there is a chance to create something once and use it often. A good example
is the high demand for connectivity interfaces. It makes sense to create standardized
interfaces and have a platform development approach for this topic.
Thus, Industry 4.0 has no direct impact. However, the indirect impact is a much
higher demand on complex and connected electronic devices as in previous produc-
tion systems.
4.3.1.1 Cradle to Cradle
An outlook to an option for the industry of tomorrow is a concept known as cradle

to cradle.11 Michael Braungart and William McDonough developed this concept in
the late 1990s and founded a kind of movement around it. The basis is a concept that
all production and consumption happens in two major life cycles. One is a biologi-
cal life cycle with material that can be created out of growing plants and can be
composted 100% to nourish the new plants. The other cycle is a technical cycle that
also concerns 100% recycling of material. Let’s say that you are developing a
TV. Your company owns it forever and someone can rent it for 2000 hours. Once the
2000 hours are over, you take it back, disassemble it, and build new TVs out of it.
The interesting thing here is the combination of a 100% recycling approach with a
new business model that more or less gets rid of ownership from consumers. People
are renting consumer goods only. For example, a chair would be owned by the chair
company forever and you as a consumer would buy 2000 hours of sitting – a very
interesting approach. What would this mean for system architecture and platform
development?
11
https://en.wikipedia.org/wiki/Cradle-to-cradle_design
The impact on system architecture would probably not be too great. Of course
reuse and recycling need to be considered very strictly and need new processes.
The platform development approach becomes interesting as you want to create
platforms of elements that can be reused across product lifetimes. That is certainly
a new challenge. This kind of reuse from product to product, including the recycle
phase, is a new aspect!
4.3.2 Management 4.0
The last chapter in this book is about management. How does management change
with all of these new trends, such as agile development, digitalization, AI, robotics,
and automation? How are the generations of engineers changing? Is there a differ-
ence between an engineer born in 1972 and another born in 1995? Do they need
different management styles to demonstrate their best possible performance and
have fun at work? What is their motivation in general at work? What does a typical
career look like in comparison to that of former days? How can we all catch up with
the continuous demand from business to continuously grow? Ultimately, what is
management 4.0?
In contrast to the term industry 4.0, management 4.0 is not yet a commonly used
term. When I started writing about it, I was not able to find anything on Wikipedia.
The small number of books available on it leads to the conclusion that management
4.0 is correlated to industry 4.0 and to the digitalization we have today. If someone
needs management in industry 4.0 environments, of course this management is
called management 4.0. Is this right? Let’s explore and discuss it further to find out.
Furthermore, let’s try to also create a historical view. What one finds is the
following:
• Management 1.0 – The classical form of hierarchies. Strategic and operation
management focusing on efficiency, with command and control from top
to bottom.
• Management 2.0 – Here, the human factor enters the game. Psychologists
researched how motivation and efficiency can be increased. Typical here is creat-
ing visions and values, increasing motivation through information transparency,
and delegating ownership.
• Management 3.0 – Everything about agile and lean management reflecting new
complex environments. Roles and responsibilities are changing and career paths
need to be refined.
I want to focus here on management in an agile world first and then see how it is
transitioning into a new dimension, which we might call management 4.0.
Probably one of the most interesting books about agile management is
Management 3.0 by Appelo [18], in which the reader will find a comprehensive
overview of management in today’s complex environment. Appelo outlines the
influence of complexity on the work environment and how teams and managers
must change to cope with this situation. I believe this to be a truly evolutionary step
that is significantly changing how we work and manage. By contrast, I cannot see a
significant change in what is described today as Management 4.0 – the impact of
industry 4.0 is not high enough and the digitalization does not differ from what
Appelo describes.
4.3.2.1 Four Drivers for Industry Change
The drivers for a new phase of management and organization were described in an
article by Hans-Gerd Servatius,12 which is the most plausible source that I found.
Furthermore, it is fully in line with my own experience.
• Platforms like Amazon and Google are disrupting the market. Established com-
panies are increasingly getting into trouble when competing with those platform
giants. One approach is to cooperate and use their technology. Thus, the manage-
ment impact involves cooperation and shared business models.
• The use of AI-based systems is entering management and human resources
departments. An increasing number of processes and tasks can be automated and
digitalized. Managers today need to catch up with those systems and use them
efficiently.
• Agile development methods are increasingly being established. This started for
management 3.0 already but is used much more in the meantime.
• The OKR13 method is increasingly used and is another key driver of management
4.0. Again, giants such as Google base their success on this method.
I personally want to add two more drivers. A fifth driver is the change of genera-
tions. I believe that we are on the edge of a new engineering generation.
4.3.2.2 Fifth Driver: Generational Change
There is great deal of material out there describing generations. Let me summarize
the most important facts:
• Traditionals, born before 1945: They possess direct experience of the impact of
two world wars and the education styles that developed accordingly. They are
part of the rising economies in all corners of the world, but no longer part of the
industry today because of their age.
• Baby boomers, born between 1946 and 1964: They were clearly born into a ris-
ing economy and are still found in top management circles worldwide influenc-
12
https://www.aws-institut.de/im-io/intrapreneurship/was-ist-das-neue-am-management
-4-0-paradigma/
13
OKR means objectives and key results. It is a management framework to create and measure
meaningful and measurable objectives for employees.
ing management styles. They have a tendency to fully focus on their career in
their lives. So-called workaholics began to appear in this generation. They have
a structured work approach and a good network.
• Generation X, born between 1965 and 1979: They were influenced by economy
crises and increasing divorce rates. They are well-established in all management
levels with a tendency to be ambitious and work hard to have a safe life. Time is
more important than money.
• Generation Y/millennials, born between around 1980 and 1995: They are influ-
enced by the Internet, global economies, and high education. They are also estab-
lished in management levels. They want to have a meaningful job, want to
develop self-fulfillment, are good team players, and have excellent online knowl-
edge. They are digital natives who have grown up with all of the technologies
that we have today. Their private life is important to them.
• Generation Z/YouTube, born between around 1995 and 2010: They are associ-
ated with a full integration of the digital lifestyle. This generation is entering the
industry right now, and they seem to have completely different understandings of
their job, relationships, salary, and work–life balance than previous generations.
They desire self-fulfillment rather in private life and they are aware of a risky
future. They feel much pressure due to social media and seem to have a tendency
not to commit to certain things as generations have done before.
As you can see, values and work behavior are changing quite a bit. This needs to
be taken into account from the management side. Motivation, working hours, and
meaningful tasks are more important than ever. Furthermore, online tools and coop-
erative task management play crucial roles. As I write this book, we are all in lock-
down mode due to the impact of COVID-19. I have been working with office
restrictions and from home for 20 months now, and everything is being done using
video conferencing systems. I believe this will have a great influence on all discus-
sions around the home office. We can all see that efficient work from home is abso-
lutely possible.
Companies are of course trying to adapt to the new tendencies. Flat hierarchies
are increasingly being implemented. The traditional boss is increasingly becoming
a coach and mentor for his or her employees.
Finally, a sixth driver is definitely the globalization that has occurred in the last
10–20 years everywhere, which is discussed in the following section.
4.3.2.3 Sixth Driver: Globalization
I remember that when I started my first job in the industry in 2002, we had approxi-
mately 1000 employees at the location in Germany. Everything was in one place.
We had predevelopment, prototyping, platform development, product development,
and manufacturing in this one location and of course also management, human
resources, sales, and legal. However, let’s focus on engineering. If someone had a
technical question about anything, there was someone around the corner who was
able to answer it. The whole engineering team of approximately 700 people was
co-located.
Nearly 20 years later, this has totally changed. In one of my last positions, my
boss was in Bangalore, India, and my team was spread around the globe. Some
employees were on the US west coast, while some were close to Detroit. Some oth-
ers were in three different locations in Germany and some more were in Bangalore.
We also had support from colleagues in Poland and China, so we had to deal with
five different time zones in one development team. The benefit is of course that you
can use the full 24 hours to develop something or be available for support tasks.
Moreover, talents can be hired where they are and can better support local projects.
A main driver is that in some regions of the world, engineers are far cheaper than in
others, but it is a huge challenge to manage a team like this and maintain an efficient
communication. Line management and project management have totally changed
compared with some years ago.
I believe these two drivers are heavily influencing the future of management
styles. Furthermore, it was the huge push we all had for staying at home and estab-
lishing a home office as a valid alternative in particular that created new challenges
for the new management. Moreover, I believe that there is still enough to do to fully
establish Appelo’s strategies and best practices in our complex environment to
improve the current situation.
Does all of this have an impact on system architecture and platform development?

What influence does the aforementioned have on system architecture design? How
is it possible to develop a platform in these new work environments?
Let me summarize quickly what we have learned in previous chapters:
• Generation change: Management and engineering need to adapt to new require-
ments coming from new generations.
• Industry change: Globalization is all over the place. Co-location for development
teams is becoming a rare working model. Furthermore, platform giants like
Amazon and Google are disrupting business models. Manufacturing is more
automated than ever, and agile methods are becoming increasingly popular.
• Technology change: People are increasingly online. AI creates huge opportuni-
ties to automate processes, tasks, and tools. Home office becomes a new standard.
This means that the new work environment is full of technology and teams are
spread around the globe. Older generations need to catch up with new technologies
and tools and constantly learn new things.
System architecture design is being performed with collaborative online tools in
virtual environments. Work processes are highly standardized so that engineers can
pick up work quickly from all corners of the world. Furthermore, investigations and
visualizations of analyzed data are supported by online tools, AI, and machine
learning approaches. Knowledge bases will enter a new age because the possibility
to go through data and previous solutions automatically is accelerating design pro-
cesses dramatically. Finding the right conditions and parameters for a project is no
longer an iterative and manual process – it can also be automated. Management is
all about creating the right environment for decentralized agile teams and coaching
them through their daily work with the help of AI tools.
Moreover, platform development strategies will benefit from new tools. One of
the main questions is always how much money can be saved with a platform
approach. If you have all of your business data such as engineering costs in a tool,
you can run through it and simulate the platform development easily. The standard-
ization as part of the platform development greatly helps to get the global engineer-
ing community in a company under one umbrella. Thus, the need for platform
strategies is increasing even more to manage the efficiency in the globalized
engineering.
Summary
These are exciting times. The world is changing dramatically, and technologies and
systems are being invented and developed at the speed of light. Autonomous cars
are on the road; smart homes are the new way of living; and robots and automation
are taking over industries. AI is ubiquitous, and users are constantly connected
through their smartphones with thousands of apps and an overarching and omni-
present cloud architecture. At the same time, technology platforms and commercial
platforms are dominating industries so that suppliers can remain competitive and
increase profit.
All this is driven by electronic devices, and these devices have one thing in com-
mon: they require a system architecture. For some devices, this might be so simple
that one person can accomplish it easily. However, with other devices, designing a
system architecture is extremely complex, and many teams are necessary to com-
plete the task. In some cases, the design process is so informal that it perhaps should
not even be called a process. Some others might require a very structured, system-
atic, and well-documented approach to handle the complexity of the system.
Whenever reuse plays a role, the strategy of platform development becomes a
popular topic. Reuse can be used as an internal development improvement to
increase efficiency and quality, or it might be a product strategy to create a platform
and sell it or use it as a product. In either case, it comes down to one single criterion
in development: reuse. Reuse can extend across products and generations to improve
development in a company, and it can even go beyond, across many customers.
I believe that system architecture design and platform development strategies are
the most important considerations in areas where electronic devices are developed.
Furthermore, in today’s complex environment, they are becoming increasingly
crucial.
System understanding and thinking in terms of platform are absolutely essential
for engineers. They can only benefit from having the big picture of their current
development task, while management can only benefit from engineers who want to
https://doi.org/10.1007/978-3-030-97695-8
186 Summary
develop something once and use it as often as possible. What could be better? The
answer is: creating something once and then selling it over and over again.
Other major influences in industries and electronic development today are AI and
machine learning. These can potentially change the way we work and think, and
they also require new systems approaches. Additionally, agile development is well
established, and even conservative car manufacturers are applying scaled agile
frameworks to handle the complexity of electronics and software in cars. Finally,
management style must change to cope with the complexity of organizations and
the agile development methods.
In this book, I provided an introduction to system architecture design and plat-
form development strategies. In the first part, I defined system architecture design in
the context of systems engineering for electronics development. I presented the
preparation of the design process: requirements engineering, team structure, prod-
uct life cycle, effort estimations, processes, and project management. The V model
provided guidance for a systematic approach. Then, the actual design process was
described including different components, behaviors, and layers of the system.
Furthermore, I described how to create performance analysis, variants, scaling, and
distribution of system elements. The first chapter ended with an example to illumi-
nate some of the more practical aspects.
The second part of the book described platform development strategies and why
they should be considered, such as improving time to market or increasing quality.
I covered business, technical, and organizational aspects of platform development
and ended the chapter with a platform development cookbook to provide generic
guidance for anyone who is considering platform development.
Finally, in the third part of the book, I described some of the main drivers that are
currently changing industries, for example, AI, agile development, and organiza-
tional change as well as how they impact system architecture and platform
development.
The following diagram shows the essential elements in a single view (Fig. 1):
It can be seen that all the elements are placed around people. Engineers, employ-
ees, and people in general are the most important factors. Without them, nothing can
be accomplished. In yellow can be seen the two main topics of this book surrounded
by the key elements such as software, hardware, mechanics, V model, outside-in,
and inside-out for system architecture design. Other elements include the four prin-
ciples and four components, reuse levels, and the triangle of failure for platform
development strategies. Project management, processes, and regulations play
important roles for system architecture and platform development. System architec-
tures provide strategy to platforms, and platforms provide reuse to system architec-
tures. All this occurs in the context of the product life cycle. The main drivers for
management are time to market, engineering efficiency, quality, and profit, while
product management and business units care about innovation, technology, and
product definitions. All these are influenced by the three drivers AI, agile develop-
ment, and organizational change. All elements are applied in one or the other variant
in different industries such as automotive, consumer, medical, and avionics.
Summary 187
Fig. 1 System architecture and platform development overview
Finally, I hope my book has provided enjoyable reading and valuable informa-
tion. Furthermore, I am always interested in learning about other ideas, new meth-
ods, and different approaches. Please do not hesitate to contact me on one or the
other platform or through my web page, www.system-architecture-design.com.
Literature
1. A. Kossiakoff and W. Sweet, Systems Engineering, United Kingdom: John Wiley Sons,
Inc., 2003.
2. Department of Defense, Systems Engineering Fundamentals, Virginia: Defense Acquisition
University Press, 2001.
3. K. Hambleton and et al, Conquering Complexity: Lessons for Defence Systems Acquisition,
London: Stationery Office Books, 2005.
4. P. Fortescue, J. Stark and G. Swinerd, Spacecraft Systems Engineering, West Sussex, England:
John Wiley & Sons Ltd., 2003.
5. SIG, VDA QMC Working Group 13 / Automotive, Automotive SPICE, Version 3.0, VDA, 2015.
6. K. Hoermann, M. Mueller, L. Dittmann and J. Zimmer, Automotive SPICE in Practice, USA:
Rocky Nook Inc., Santa Barbara, 2008.
7. R. Sharp, Principles of Protocol Design, Berlin Heidelberg: Springer Verlag, 2008.
8. Verband der Automobilindustrie, Reifegradabsicherung für Neuteile, Online: VDA, 2021.
9. T. Weilkiens, Systems Engineering mit SysML/UML, Heidelberg: dpunkt.verlag, 2014.
10. E. d. Bono, Six Thinking Hats, New York: Penguin Books, 1999.
11. P. Lencioni, The Five Dysfunctions of a Team, San Francisco: Jossey-Bass, 2002.
12. M. E. McGrath, Product Strategy For High Technology Companies, New York: McGraw-
Hill, 2001.
13. E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns, New York: Addison-
Wesley, 1994.
14. R. O. Duda, P. E. Hart and D. G. Stork, Pattern Classification, 2nd edition, New York: John
Wiley & Sons, Ltd., 2000.
15. T. M. Mitchell, Machine Learning, USA: McGraw-Hill Companies, Inc, 1997.
16. J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, New York: Crown
Business, 2014.
17. J. S. Ken Schwaber, Software in 30 Days, New Jersey: John Wiley and Sons, Inc., 2012.
18. J. Appelo, Management 3.0, Crawfordsville, Indiana: Addison Wesley, 2014.
https://doi.org/10.1007/978-3-030-97695-8
Index
A data privacy and ownership of, 157

Agile, 160 knowledge-based systems, 157
Agile development, 31, 160, 186 pattern recognition, 157
conducting reviews, 172 prediction, 157
continuous integration and robotics, 157
automation, 172–173 strong AI, 157
cross-functional teams, 172 voice assistants, 157
effort estimations, 173–174 weak AI, 157
extreme programming, 160 Automatically reviewing, 171
high-quality software, 171 Automation, 25, 99, 124, 127, 172, 173, 177, 179
Kanban, 168–170 Automotive electronics environment, 65
for large projects, 165–166 Automotive industry, 2, 8, 12, 27, 30, 33, 40,
methods, 162, 180 53, 62, 102
pair programming, 171 Automotive SILs (ASILs), 40
Scrum framework, 163–165 Automotive SPICE, 24, 34–39, 77
Scrum in waterfall environment, 166–168 Autonomous cars, 185
software development, 170 Autosar, 62
software programming, 160
system architecture and platform
development, 174–176 B
test-driven development, 171, 172 Boot-up timing, 67
user stories, 173 Bug fixing, 99, 100, 115, 125, 131, 140
vs. waterfall, 161–163 Business case, 83
Agile Manifesto, 163 automation, 99
AI-based systems, 180 business calculations, 87–88
Alexa, 157 continuous development, 100
Algorithms, 157 life cycle of a platform, 98–99
Amazon, 102, 103, 180 maintenance, 99
Anti-noise, 67 open-source development, 100, 101
Apple’s App Store, 86, 103 parallel development, 90, 91
Architectural gaps/inconsistencies, 16 parallel development effort, 91–92
Architecture, 74 platform development, 92, 93
Architecture design, 19 platform development effort, 93–98
Artifacts in Scrum, 164 sequential development, 88
Artificial intelligence (AI), 3, 4, 156, 185, 186 sequential development effort, 88–90
https://doi.org/10.1007/978-3-030-97695-8
192 Index
Business to business (B2B), 18, 26 Electronic systems, 1, 4, 10–12, 42, 53, 65, 85
Business to consumer (B2C), 18, 26, 29 Engineering processes, 36
Environment, 53
Execution, system architecture design
C action, 78
Capability Maturity Model Integration application-based software diagram, 63
(CMMI), 35 closing phase, 78
Car manufacturers, 1, 12, 186 compromises, 69, 70
Car navigation system, 1 CPU and memory, 47
Cars, 186 cross-project comparison, 44–46
Centralized repository, 115 distributed systems, 65–67
Chief Technology Officer (CTO), 45 documentation, 70, 71
Cloud processing, 158 dynamic behavior, 67, 68
Code reviews, 172 environment, 53
Commercial platforms, 102 features and resource needs, 44
Communication, 23–25 hardware design, 56–59
Component-based development, 113, 114 hierarchy, 44, 45
Computer-aided design (CAD), 60 high-level software block diagram, 63
Computer science, 157 IC selection, 53–55
Conducting reviews, 172 inside out, 42–44
Configurability, 108, 120 interfaces, 48, 49
in hardware, 131 kick-off, 78
Connectivity, 158 mechanics design, 59, 60
Constant growth, 99 meetings, 78
Consumer electronic devices, 102 OSI model
Continuous integration, 172 application layer, 49
Contractor engineers, 95 data link layer, 48
Controller Area Network (CAN), 49 network layer, 48
Cortana, 157 physical layer, 48
Cost-optimized approach, 3 presentation layer, 49
Cradle to cradle, 178 session layer, 49
Cross-project comparison, 44–46 transport layer, 49
outside in, 42
performance analysis, 42, 46, 47
D presentations, 71, 72
Data sets, 158 priorities, 68, 69
Design, 9, 70, 185 protocols, 48–53
Diagnostic functionality, 62 refinement, 78
Digital Signal Processor (DSP), 2, 23, requirements analysis, 41
53, 54, 66 simulation, 60, 61
Direct Memory Access (DMA), 44 software design, 61, 62, 64
Distributed systems, 65–67 software message example, 53
Documentation, 70 system layers, 48, 49
Dynamic behavior, 67, 68 system performance, 42
system variants and scaling, 64, 65
targets, 78
E task force, 77
Effort estimations, 30, 32 teams, 78
in agile development, 173 timing behavior diagram, 68
in team meetings, 174 topology diagram, 43
Electromagnetic compatibility (ECM), 60 UML diagram, 64
Electronic devices, 43, 185 work flow, 41
Electronic parts, 8 work products, 70, 71
Electronics product development, 3 Extreme programming, 160
Index 193
F I2S, 51
Face-to-face collaboration, 163, 171 I2S interface, 51, 52
Feature extraction, 3 ISO/IEC 15288, 35
Fibonacci numbers, 174 ISO organization, 35
Finding compromises, 69
Food and Drug Administration (FDA), 40
Frozen platform release, 100 K
Functional safety – IEC 61508, 40 Kanban, 160, 168–170, 176
G L
Gantt chart, 164 Lego© System, 85, 107
Generations, 179–182 Library deliveries, 115
Giga floating point operations per second Linux, 62
(GFLOPS), 54
Globalization, 181–182
Google, 180 M
Machine learning (ML), 3
and AI (see Artificial intelligence (AI))
H implementation, 156
Hardware principles, 155
components, 103 reinforcement learning, 156
configurability, 131 supervised learning, 155
design, 56–59 unsupervised learning, 156
development process, 131 Maintenance, 99
electronic systems, 127 Management, 179
extendibility, 130 Management 1.0, 179
interfaces, 51, 61 Management 2.0, 179
key components, 128 Management 3.0, 179
maturity, 59 Management 4.0, 179, 180
modularity, 130 Market, 86, 89, 90, 96, 101–103, 105, 111, 121
platform development, 128 Mechanics, 88, 94, 95, 140, 148
portability, 130 design, 59, 60
reference system, 128 simulation, 60
reuse levels, 128–130 Media Oriented Systems Transport
scalability, 130 (MOST), 48
simulation, 60 Medical devices industry, 39
Hierarchy, 44, 45 Medical devices – ISO 13485, 39, 40
Humidity, 53 Medicines & Healthcare products Regulatory
Agency (MHRA), 40
Microcontroller, 88, 89, 128, 129
I Middleware, 62, 73, 74
IC selection, 53–55, 61 Military, 40
Industry 1.0, 176 Million instructions per second (MIPS), 54
Industry 2.0, 176 Minimum viable product (MVP), 174–176
Industry 3.0, 176 Modularity, 116, 117, 130
Industry 4.0, 177, 178
Integrated circuit (IC), 53, 54, 56, 57, 59
Integration, 166, 170, 172 N
Integration tests, 123 Name platform, 102
Interfaces, 48, 49 NASA Systems Engineering Handbook
International Electrotechnical Commission (book), 10
(IEC), 35 Navigation system, 68
Internet of Things (IoT), 177 Next-generation navigation system, car, 1
194 Index
O reuse and standards, 86

OKR method, 180 on three pillars as solid ground, 84
Open-source model, 100 triangle of platform failure, 145, 146
Open Systems Interconnection (OSI) model Platform development, 27, 159
application layer, 49, 50 business aspects (see also Business case)
data link layer, 48 commercial platforms, 102–103
network layer, 48 time-to-market improvements, 101–102
physical layer, 48 creating reference systems, 85
presentation layer, 49 departments, 13
session layer, 49 development cycles, 86
transport layer, 49 i.m.p.a.c.t. analysis, 86
Operating systems, 61, 68 platform thinking, 83
Organization, 33 secrets, 85
Organizational aspects of platform strategies, 83, 152
development technical aspects (see Technical aspects of
challenges, 138 platform development)
companies, 139 Platform development strategies, 186
departments and platform team, 139–141 electronic devices, 185
management, 141 engineers, 185
mindset, 138 reuse, 185
organization, 138 Platform maintenance team, 99
project management, 143, 144 Plug-in concept, 37
timing and team size Portability, 118, 119
kill the platform, 142–143 in hardware, 130
start during running project, 142 Porting software, 118
starts from scratch, 141 Precondition, 102, 112
Organizational change Presentation, 71, 72
cradle to cradle, 178–179 Printed circuit board (PCB), 7, 48, 57–60, 65
drivers for industry change, 180 Priorities, 68, 69
generational change, 180–181 Processors, 54, 55
globalization, 181–182 Product development, 29
Industry 1.0, 176 Product life cycle
Industry 2.0, 176 B2B scenario, 26
Industry 3.0, 176 B2C scenario, 26
Industry 4.0, 177, 178 maintenance phase, 29, 30
management 4.0, 179 next-generation product, 25
system architecture and platform predevelopment, 26, 27
development, 182–183 product development, 29
Organizations, 177 product phases, 31
product retirement, 30
RFI, 27, 29
P RFQ, 27, 29
Pair programming, 160, 171 Product retirement, 30
Parallel development effort, 92, 94, 97 Product-specific content, 13
Performance analysis, 46, 47 Project management, 9, 33, 34, 69, 76
Platform, 13, 32, 86 of platform development, 143, 144
communication, 144 Project plans, 74–76
company size, 145 Project setup, 33
costs, 144 PSPICE, 60
definition, 83
engineering failure, 146
management failure, 146 Q
reuse, 145 QNX, 61
Index 195
R framework, 163–165, 169, 173

Reinforcement learning, 156 LeSS, 166
Relative estimations, 174 masters, 164, 165
Request for information (RFI), 27, 29, 70 nature, 165
Request for quotation (RFQ), 11, 15, 17, 19, Nexus, 165
22, 24, 27–30, 33, 34, 45, 58, 70, 71 poker, 174
Requirements, 70, 73, 74 roles, 164
elicitation process, 20 software development process, 163
engineer, 16, 27 in waterfall environment, 166–168
management, 16–20 Security, 62
Research & Development (R&D), 26 Sequential development, 88
Responsible Approval Support Information Simulation, 60, 61
Consultancy (RASIC), 21–23 Siri, 157
Reuse and standards, 86 Six Thinking Hats (book), 72
Reuse factor, 88 Smart devices, 158
Reuse of components Smartphone, 67
benefit of reuse, 109 Software, 61, 64
levels of reuse Software design, 61, 62, 64
concept reuse, 107 Software development
experience reuse, 107 complex electronic devices, 112
LEGO© System Reuse, 107 component-based development, 113
plug & play reuse, 107 configurability, 120
reference reuse, 107 development processes, 120
system reuse, 107 architecture, 122
methods of reuse high-level concept, 121
opportunistic reuse, 108 implementation, 122
planned reuse, 108 internal activities, 121
reuse factor, 109 software platform requirements, 121
rules of reuse unit and integration tests, 122–125
centralized, 109 extendibility, 119
component-based, 109 horizontal lines, 113
configurability, 108 modularity, 116, 117
extendibility, 109 portability, 118, 119
modularity, 108 reuse Levels, 114–116
portability, 108 rollout, 125–127
scalability, 108 scalability, 118
testability, 109 selection of OS, 113
where to draw the line, 109–110 Software programming, 160
Reviews, 171 Software protocol, 51
Risk management, 33 Spacecraft engineering, 10
Robotics, 157, 159 Spacecraft Systems Engineering (book), 10
Space shuttle, 10
Sprint review, 164–166, 175
S Stacey Matrix, 167
Safety, 62 Stakeholder management, 144
Safety integrity levels (SILs), 40 Supervised learning, 155
Scalability, 118, 130 Supplier contacts, 15
Scrum, 160 Supplier management, 15, 137
approaches, 165 System architecture design, 186
artifacts, 164 automotive customer projects, 73
communication in software definition, 7, 8
development, 164 electronic devices, 185
events, 164 electronics development, 79
196 Index
System architecture design (cont.) System-on-Chip (SoC), 47, 54, 57

electronic systems development, 11, 12 System requirements, 14
execution (see Execution, system Systems engineering, 9, 10
architecture design) Systems Engineering ISO/IEC 15288, 35
house as a system, 8 System testing, 12
management, 73
middleware, 73
platform development, 79 T
space shuttle, 10 Task force, 33, 34
systems engineering, 9, 10 Technical aspects of platform
System architecture design preparation development, 103
architecture, 74 central storage, 132–133
effort estimation, 30, 32 characterization, 105
processes, 77 components, 103
Automotive SPICE, 34–39 development of key components, 104
CMMI, 35 development of reference systems, 104
functional safety – IEC 61508, 40 essential platform parts, 104
medical devices – ISO 13485, 39, 40 hardware development
military, 40 (see Hardware)
Systems Engineering ISO/IEC innovation and technology
15288, 35 development, 111–112
product life cycle (see Product life cycle) platform requirements, 105–106
project management, 33, 34 principles of platform development,
project plans, 74–76 105, 106
requirements, 73, 74 processes around them, 104
automotive industry, 12 product development and platform
knowledge libraries, 14 releases, 135–137
management, 16–20 quality and stability, 131–132
networking and libraries, 14, 15 reuse of components (see Reuse of
platform content, 13 components)
product-specific content, 13 software development (see Software
statistics, 18 development)
supplier management, 15 supplier management, 137
system, 14 technical strategy, 110
table, 17 technology releases and platform
technical strategy, 12 development, 134–135
tracking, 19 training and customer support
teams, 76, 77 application engineers and integration
team structure support, 134
architecture organization chart, 21 bug fixing, 140
communication, 23–25 change requests, 133
customer interface, 20 feature requests, 133
electronic systems, 20 training material, 134
open issues, 24, 25 well-defined development process, 104
RASIC, 21, 22 Technical strategy, 12, 110
skills and roles, 22, 23 Test automation, 125
team availability table, 22 Test-driven development, 160, 171, 172
technical domains, 20 Time division multiplex (TDM), 23
tools, 24, 25 Time-to-market improvements, 101
System architecture principles, 157–159 Traceability, 29
System modeling language (SysML), 64 Training phases, 158
Index 197
U W
Ultrasonic sensor system, 67 Waterfall
Unified modeling language (UML), 62, and agile, 160, 162
64, 68 complex software or system
Unsupervised learning, 156 development, 162
development process, 161
planning with Gantt charts, 164
V project management, 167
V model, 11 Waterfall environment, 166
Voice assistants, 157, 158 Waterfall flow, 161

System Architecture Design and Platform Development Strategies

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Architecture Design and Platform Development Strategies

Uploaded by

Copyright:

Available Formats

Tobias Münch

System Architecture Design

ISBN 978-3-030-97694-1 ISBN 978-3-030-97695-8 (eBook)

Part I System Architecture Design

Part II Platform Development Strategies

Part III AI, Agile, and Organizations

4.2.5 Kanban���������������������������������������������������������������������������������� 168

Fig. 2.1 A house as a system�������������������������������������������������������������������������� 8

Fig. 3.1 Platform on three pillars as solid ground������������������������������������������ 84

Table 2.1 Requirements table �������������������������������������������������������������������������� 17

Tobias Münch studied telecommunication electronics at the Technical University

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 1

1.1 Personal Excursion

1.2 Who Should Read This Book?

Nothing is particularly hard if you divide it up into small jobs.

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 7

Fig. 2.1 A house as a system

2.2 Introduction to Systems Engineering

Fig. 2.2 Systems engineering

Simon Ramo, who is considered the inventor of systems engineering, described

Fig. 2.3 Space shuttle

2.3 Electronic Systems Development

Now we want to develop an electronic system. What does it mean? How do we

Fig. 2.4 V model

2.4.1.1 Technical Strategy

internal platform development, or that new proprietary technologies from one’s

2.4.1.2 Platform Content

2.4.1.3 Product-Specific Content

2.4.1.4 System Requirements

2.4.1.5 Networking and Libraries

Fig. 2.5 Knowledge libraries

2.4.1.6 Supplier Management

2.4.1.7 Requirements Management

Table 2.1 Requirements table

• Offered – No further explanation is necessary other than whether it is available

Fig. 2.6 Requirements statistics

Fig. 2.7 Requirements tracking

2.4.2 Team Structure

Fig. 2.8 Architecture organization chart

Table 2.2 Team availability table

Table 2.3 RASIC chart

2.4.2.1 Skills and Roles

An effective strategy inside the company is to train employees with a special

2.4.2.2 Communication and Tools

Communication is key in these complex development environments. Ideally all

Table 2.4 List of open issues

2.4.3 Product Life Cycle

In the following sections, I examine different phases of product development for

13.5%, Amazon 11%, Apple 7.1%, and Samsung 9%.

2.4.3.2 RFI and RFQ

In the automotive industry, car manufacturers usually approach suppliers by request-

Fig. 2.9 RFQ process diagram

2.4.3.3 Product Development

2.4.3.4 Maintenance Phase

2.4.3.5 Product Retirement

2.4.4 Effort Estimation

In conventional quotation processes in the automotive industry, customers expect a

Fig. 2.10 All product phases

2.4.5 Project Management

2.4.6 Task Force

2.4.7.1 Systems Engineering ISO/IEC 15288

2.4.7.3 Automotive SPICE

As mentioned above, SPICE is an international standard for evaluating the pro-

Fig. 2.11 Automotive SPICE groups. (Copy from [5])

Part I System Architecture Design

Part II Platform Development Strategies

Part III AI, Agile, and Organizations

4.2.5 Kanban�� 168

Fig. 2.1 A house as a system�� 8

Fig. 3.1 Platform on three pillars as solid ground�� 84

Table 2.1 Requirements table �� 17

1.1 Personal Excursion

1.2 Who Should Read This Book?

2.2 Introduction to Systems Engineering

2.3 Electronic Systems Development

2.4.1.1 Technical Strategy

2.4.1.2 Platform Content

2.4.1.3 Product-Specific Content

2.4.1.4 System Requirements

2.4.1.5 Networking and Libraries

2.4.1.6 Supplier Management

2.4.1.7 Requirements Management

2.4.2 Team Structure

2.4.2.1 Skills and Roles

2.4.2.2 Communication and Tools

2.4.3 Product Life Cycle

2.4.3.2 RFI and RFQ

2.4.3.3 Product Development

2.4.3.4 Maintenance Phase

2.4.3.5 Product Retirement

2.4.4 Effort Estimation

2.4.5 Project Management

2.4.6 Task Force

2.4.7.1 Systems Engineering ISO/IEC 15288

2.4.7.3 Automotive SPICE

2.4.7.4 Medical Devices – ISO 13485

2.4.7.5 Functional Safety – IEC 61508

2.5.1 System Architecture

2.5.1.2 Inside Out

2.5.1.4 Cross-Project Comparison

2.5.1.5 Performance Analysis

2.5.1.6 Interfaces, Protocols, and System Layers

2.5.1.9 IC Selection

2.5.1.10 Hardware Design

2.5.1.11 Mechanics Design

2.5.1.13 Software Design

2.5.1.14 System Variants and Scaling

2.5.1.15 Distributed Systems

2.5.1.16 Dynamic Behavior

2.5.2 Work Products and Documentation

2.6 Example and Summary

2.6.1 Step 1: Preparation Phase

2.6.2 Step 2: Execution Phase

2.6.3 Step 3: Closing Phase

3.2 Why Platforms?

3.3 Business Aspects

3.3.1 Initial Overhead, Payback, and Life Cycle

3.3.1.1 Business Case Calculations

3.3.1.2 Sequential Development

3.3.1.3 Sequential Development Effort

3.3.1.4 Parallel Development

3.3.1.5 Parallel Development Effort

3.3.1.6 Platform Development

3.3.1.7 Platform Development Effort