The user of the IoT ARM is advised to use her own domain understanding in
order to devise the Physical-Entity View. Where needed, pertinent models (for
instance freshness vs. room temperature model for orchids) either need to be
developed by the architecture team or it can be extracted from outside sources
(literature, standards, etc.).
5.2.4.2 IoT Context View
As indicated in Figure 65 , the IoT Context View consists of two parts, the
context view and the IoT Domain Model. The context view is an architecture
view that is generated at the very beginning of the architecture process. It
describes ―the relationships, dependencies, and interactions between the
system and its environment (the people, systems, and external entities with
which it interacts)‖ [Rozanski 2012]. To be more specific, the context view
describes ―what the system does and does not do; where the boundaries are
between it and the outside world; and how the system interacts with other
systems, organizations, and people across these boundaries‖ [Rozanski
2013]. The concerns addressed by the context view are [Rozanski 2013]:
System scope and responsibilities; Identity of external entities and services and data used; Nature and characteristics of external entities; Identity and responsibilities of external interfaces; Nature and characteristics of external interfaces; Other external interdependencies; Impact of the system on its environment; Overall completeness, consistency, and coherence.Notice that at least one of the concerns, viz. ―impact of the system on its
environment‖ also applies to the Physical Entity, and investigating this concern
thus requires input from the Physical-Entity View (see Figure 66 ).
A detailed example of a context view, including a context diagram and a
description of the system components can be found in Section 5.3.
Notice that the context view mainly focuses on what lies outside the system and
how the system interfaces to the outside world. This is sufficient for ―generic‖
architecting processes. However, in IoT domain we not only know more about
the system to be devised, but also should gather more information about the
system already at a very early stage in the architecting process. Why? First,
since IoT systems have many aspects in common by virtue of operation in the
same domain, a lot of concepts are recurring. One of the goals of the IoT ARM
is to avoid ―reinventing the wheel,‖ namely to avoid discovering, analysing and
naming the very same aspects every time an architecture gets generated. In
order to permeate the entire architecture description with this understanding, we