follows the well-established spiral design and prototyping model [Boehm
1988].
As discussed in Section D.3, besides the architecture and domain analysis, we
also provide the user of the ARM with guidance for deriving concrete
architectures (see Figure 165 ). Besides being of benefit for the user of the
ARM, the generation of such guidelines has the side benefit of providing
valuable feedback to the ARM derivation itself. When devising guidelines for
translating the ARM into a specific architecture, potential gaps and
inconsistencies are revealed. Also, this exercise deepens our understanding of
the IoT domain, and provides additional guidance on what aspects of the ARM
need further enhancement.
The spiral-model approach inherent in the ARM development process was
chosen for the following reasons. First, each iteration increases the stability of
the ARM. Second, due to its multi-step nature, the dissemination of the
(embryonic) ARM started early within the project run time. The first public
version was already released during the first project year. Version two followed
during the second project year, while the last two versions were planned for the
third project year. Thanks to early publication and active engagement of the
community through, for instance expert workshops, corrective impulses from
peers and external stakeholders are received early on in the development
process and can thus positively influence both the applicability of the ARM as
well as its acceptance. Third, this approach formalises and coordinates the
interaction of the architecture activity within IoT-A with that of the other activities
(technical analysis and demonstrator set up), which is expected to enhance the
efficacy of the entire project.
D.4.2 Generation of architectures
So far we have only described the genesis of the IoT ARM, but not how its use
for the generation of specific architectures actually works. We dedicate an entire
Section in Chapter 5 to this, namely the ―Process‖ Section, where we describe
all details in thorough detail. However, the reader needs at least some
appreciation of the role the IoT ARM in order to take full advantage of the IoT
Reference Model and the IoT Reference Architecture in Chapters 3 and 4 ,
respectively.
When applying the IoT ARM in the design of systems, it is likely that different
architectures will result. So, while one gets the impression from Figure 164 that
the process of translating the reference architecture into a concrete architecture
is independent of the use case itself this is, in reality, not so. Rather, the
guidelines and the chosen engineering practices rely on a use-case description
and requirements. This fact is reflected in Figure 167. The role of the ARM is to
provide transformation rules for translating the rather abstract models into a
concrete architecture. This step is strongly influenced by the use case and the
related requirements. One entry point for this information is during the process
of design choices, viz. when the architect favours one avenue of realising the
needed functionality or quality over the other. Also, the ARM recommends