2.2 The three Architectural Visions (1/2)

2.2 The three Architectural Visions

We are now in position to introduce the three systems architectural visions which will be our first key systems architecting tool for analyzing any system..

2.2.1 Architectural Visions Definition

The heterogeneity of the environment of a system requires to address it by means of different axes of architectural analysis in order to be able to integrate the whole set of various perceptions of the different system stakeholders¹For an electronic toothbrush, these perceptions can be typically the one of the mother who wants good dental hygiene for her children, the one of the stressed business person who wants to clean his/her teeth as quickly as possible, the one of the dentist who will understand whether the toothbrush is efficient or not with respect to teeth cleaning and the one of the engineer who knows how to construct and how works the electronic toothbrush. . Such a consideration naturally leads us to organize these points of views according to different architectural visions that are both necessary due to the variety of any systemic environment, but also useful since they allow decoupling the representations of a given system in different “properly” interrelated separated views²This way of managing different views on the same system is in fact quite common in usual life. Think for instance of a tourist visiting a city. He/she will probably use many different views, typically provided by a touristic guide, a metro map and a city map. To find his/her way, he/she may for instance first chose the monument to visit in the touristic guide, then move there using the metro map and finally manage the local approach using a city map. In architectural terms, the tourist is thus taking information in different coupled views and integrating them in order to take the “good” decision! which always leads to better clearness and flexibility in terms of system design and development management³A classical difficulty is that such views can correspond with totally – and even sometimes opposite – different perceptions on the system, depending on the involved stakeholder..

As a matter of fact, each integrated system S can always be completely analyzed from three different and complementary perspectives that give rise to three generic architectural visions, that is to say operational, functional and constructional visions, each of them grouping different types of systemic models, as defined below:

• Architectural vision 1 – Operational vision: strictly speaking, the operational vision groups only the models of the environment of S – and not of S itself – which are involving S. Such operational models are thus describing the interactions of S with its environment.
• Architectural vision 2 – Functional vision: the functional vision groups all system level models describing the input/output dynamics of S, without making reference to its concrete components⁴ That is to say without referring to any technological choice or to any chosen solution.. Such functional models are thus abstractly modeling the behaviors of S.
• Architectural vision 3 – Constructional vision⁵Other names do classically exist for that vision. One may for instance also speak of structural vision. Some frameworks are also speaking of logical vision to denote the constructional vision in the CESAM meaning: the constructional vision groups the natural system level models of S constructed by composition of the lower level models associated with its components. Such constructional models are thus describing the structure of S.

An illustration of these three different architectural visions is provided by Figure 20 on the electronic toothbrush example. We sketched there our three different types of models, with their connections (see the last subsection of the current section for more details), each of them illustrating a different architectural vision. One sees that the operational vision is not interested by the toothbrush behavior or structure, but just by describing its interactions with (in this example only some) external systems, which are here Power supply, End-users and Internet. On the other hand, the functional vision gives the main toothbrush behaviors – i.e. Provide electrical power, Generate brushing power, Provide brushing capability – that allow producing these external interactions as captured by the operational vision, when the constructional vision shows how to implement concretely these internal behaviors through suitable components, here a base, a body, an head and an embedded software.

Figure 20 – Illustration of the three architectural visions on an electronic toothbrush

It is also important to point out that the previous architectural visions definitions are consistent. In this matter, the key point is here only to be sure of the existence of functional models as defined above. This is however directly connected to the emergence postulate (see Section 0.2) that claims that the mere knowledge of the models of the components of a system and of their interaction laws is never sufficient to model the system that results from their integration. This fact explains why any system always has purely functional models, whose core fundamental role is to express the emerging behaviors⁶Unfortunately, this is not a common understanding of the functional vision. When doing “functional analysis”, most of people are indeed just modeling the functions of the components of a given system, which is not functional analysis in our meaning since this activity shall focus on describing functions at system level, and not at component level. that one will never be able to capture and read within constructional models⁷To understand this phenomenon, consider the example of a car whose constituent (high-level) systemic components are the car body, powertrain, binnacle, chassis and embedded electronics. The interaction of these components typically allows for features like “obstacle detection” which requires the cooperation of a radar (placed in the car body), an embedded software (within embedded electronics), a LED (positioned in the passenger binnacle), and possibly chassis or powertrain if one wants to act on the brakes and / or to reduce engine torque when an obstacle is too close to a car. Such a “transverse” feature is clearly difficult to catch in a purely constructional car model when one will see the flows exchanged between the various involved components of the vehicle without being able to account for their overall logic. Only a functional model at car level will allow capturing the semantics of such a transverse function..

We can thus now understand why it is necessary to have three different types of models in order to model in practice a real system: the operational vision indeed captures the external viewpoint while functional and constructional views do capture the internal perspective, by modeling respectively firstly the emergent behaviors and secondly the concrete constitution of the considered system.
As we will see more in details in the sequel, architectural visions are of course key for in a systems architecting perspective: the first job of any systems architect will indeed always be to classify the modeling information according to our three architectural visions⁸That will be segregated more precisely according to a systemic analysis grid and organized in different abstraction levels, as we will see further in this pocket guide., so as to obtain homogeneous system models each of them capturing a well-defined view.

2.2.2 Architectural Visions Overview

Let us thus now present more in details the three different – operational, functional & constructional – architectural visions that we introduced in the last section.

2.2.2.1 Operational Vision

The operational vision provides “black box” models of a given system where one does not describe the system of interest, but rather its interactions and its interfaces with its environment. Its core motivation is to understand in that way the motivation – that is to say the “Why” – of the system.

In this matter, the key point to understand is that an operational analysis manipulates concepts at environment level, which are mixing – by definition – both the system of interest and its external systems. The operational concept of “mission of a system” is a typical example of such a situation. Formally speaking, a mission for a given system S can indeed be defined as a function of the environment of reference Env(S) of that system⁹In other terms, Mission(S) ≡ Function(Env(S)) for every system S.. When one analyzes for instance the function “To guarantee dental hygiene”¹⁰Due to the functional nature of a mission, we do recommend to name it as a verb in infinitive form (cf. next subsection). , whose functional behavior consists in transforming dirty teeth into healthy teeth and/or maintaining teeth in an healthy state, one can see that a toothbrush can clearly not achieve alone this feature, which also requires at least an end-user, toothpaste and water plus may be a dentist. Such function can thus only be allocated to the environment of the toothbrush, considered as a system in the meaning of Section 2.1, and not to the toothbrush alone. In other words, “To guarantee dental hygiene” is hence not a function of the electronic toothbrush, but a function of its environment, which means that it shall be interpreted as a mission – and again not a function¹¹The role of functional analysis is in particular to extract, strictly speaking, the functions of a system of interest which are hidden within its missions, that is to say the internal behaviors of the considered system that are only involving the system and nothing else around it (and thus also only partially contributing to the missions). For an electronic toothbrush, we may for instance analyze that the toothbrush is only achieving the function “To brush teeth”, which basically only provide brushing forces, as a partial contribution to the mission “To guarantee dental hygiene”. To illustrate this subtle distinction, we may take the other classical example of the cigarette system. Most of people will probably say that the core function of a cigarette is “To smoke”, but again it is easy to see that one cannot smoke without at least a smoker, a source of fire and air, plus probably also an ashtray. “To smoke” can hence be only allocated to the environment of a cigarette and it shall be interpreted as a mission – and not a function – of a cigarette. One may indeed understand that “To smoke” is a complex protocol requiring first a smoker, a cigarette and a source of fire to provide its own function “To deliver fire”, passing then through a loop where smoker “inspires pure air”, cigarette “propagates fire” & “delivers tar” and smoker “expires dirty air” up to arriving to the cigarette consumption, with a final request by the smoker of the ashtray function “To keep ashes” applied to the burned cigarette. This analysis shows that the underlying cigarette functions – or in other terms the intrinsic behaviors of a cigarette – are here “To propagate fire” and “To deliver tar”. – of the toothbrush according to our above definition.

The operational vision relies on other operational concepts such as life cycle, operational contexts, operational scenarios or operational objects (cf. Section 2.4 for more details). All these concepts may also be managed at different levels of abstraction / grain. Figure 21 shows for instance the Mission Breakdown Structure (MBS) of an electronic toothbrush where its core missions are put in a hierarchy according to the fact that a high level mission needs the lower levels missions to be achieved.
The operational vision can also be seen as a natural interface between engineering and non-technical people. Typical examples of operational models are indeed for instance development, assembling or maintenance models (that specify how a product system will be managed by the associated design, manufacturing or support systems), but also marketing or usage models (that describe how a product system will be seen by the market or used the end-users) and business models (which explain how the constructing company will earn money with a product system). In this matter, the role of the operational vision is to express the information contained in these different business models within a language that can be understood by the system designers and used in the development process.

2.2.2.2 Functional Vision

The functional vision provides “grey box” models of a given system of interest where one begins to apprehend the inside of the system, but only in terms of input/output abstract¹² That is to say independent of any technological implementation. behaviors and not of concrete implementation choices, in order to begin understanding more deeply what does the system, without however knowing at this point how it is concretely structured. Its core motivation is to elicit in that way the behavior – that is to say the “What” – of the system. The core notion of the functional vision is of course the notion of “function of a system”, which refers to an input/output behavior of the considered system. In other terms, a function associated with a given system models a transformation process – which can be achieved by physical, software or even “humanware” resources – that transforms a given series of inputs into a given series of outputs. This explains why a common pattern to name a function is a verb followed by a complement, the generic patterns being typically “To do something” or “To transform inputs into outputs”. In any case, one shall always check when defining a function whether it expresses such a transformational behavior.

Contrarily to the operational vision, all functional concepts – such as functional modes, functional scenarios or functional objects (see Section 2.4 for more details) – are now uniquely referring to the system of interest, without involving any external system. All these concepts can again be managed at different levels of abstraction / grain. Figure 22 shows for instance the Functional Breakdown Structure (FBS) of an electronic toothbrush, where its main functions are put in a hierarchy according to the fact that a high level function needs the lower levels functions to be achieved (i.e. the “algorithm” of the high level function involves the lower functions as sub-routines).

We may now point out that a key difficulty of functional analysis is the identification of transverse functions that is to say of functions that cannot be directly allocated to a single component of a given system. Such functions are indeed capturing the emergent behaviors resulting from the cooperation between the different components of a system, which by definition cannot be easily observed at constructional level. It is therefore always important to identify these functions in order to master the integration process since these functions are also telling us where different teams in charge of different components shall work collaboratively¹³We already provided an illustration on that situation in footnote 80 to which the reader may first refer. Another similar example is the thrust reversing function on an aircraft: this function, which reverts the air flow passing in an aircraft engine to decrease the speed of the aircraft when on ground, is provided by the cooperation of a cylinder that pushes a trap both located in the nacelle, the engine itself and a critical embedded software that coordinates the involved nacelle and engine components when thrust reversing operates. Such a function is typically transverse since distributed on several hardware & software components which are located moreover provided by different suppliers (typically one for the nacelle, one for the engine, one for the embedded system): identifying the function and putting it under control in the aircraft development project is thus totally key to ensure the success of its integration. . Within a functional breakdown structure, one may thus normally always find both component functions and transverse functions. Unfortunately most of engineers are often forgetting the transverse functions in their analyses, which leads them to lose the most important value of a complete functional analysis in a systems architecting perspective.

Another key point is that the functional vision is fundamental in systems architecting since it provides the deep invariants of any system. Any communication network will achieve for instance always the same basic functions such as “To receive messages”, “To route messages” or “To deliver messages”, independently of its implementation technology that may either purely manual (think to your snail mail operator) or based on many different techniques (Hertzian waves, twisted cables, copper wires, optical fiber, etc.). In a totally different direction, consider a State as an organizational system: one may observe that it always relies on the core function “To collect taxes”, consisting in taking money from the citizen pockets and bringing it in the State ones, which is basically invariant among time even if the tax collecting mechanisms evolve a lot from Roman antiquity up to our modern societies. In other words, technology changes but functional architecture remains. As a natural consequence, functional architecture always provides a robust basis for architecting a system. It indeed allows the systems architect to reason on a system independently of technology and thus to define, analyze and evaluate different implementation options for a given functional architecture. Such an approach is key to choose the best solution, which cannot be done if one directly works at constructional level where one will be glued in a given technical choice, without possibility of making another.

Good systems architectures are also based on functional segregation principles. This simply means that some key functional interfaces must be strictly respected at constructional level¹⁴In this matter, the role of the systems architect is to guarantee that such interfaces will never be violated in the design.. This gives rise to layered architectures where components are clustered in different independent layers connected by functional interfaces. Typical classical examples of such architectures are computer, mobile phone or communication network architectures that are organized in different independent layers, starting from the physical layer up to arriving to service layers (see for instance [90] for more details). One must thus for instance be able on one hand to change a signal processing protocol within the physical layer without any impact on the service layer and on the other hand to implement a new service or a service evolution in the service layer without any impact on the physical layer. Such a result is typically achieved by means of robust functional interfaces that shall also be stable among time, in order to absorb the technological evolutions that will naturally arrive in the life of any system¹⁵ Another motivation for such functional segregation is abstraction. It would indeed be basically impossible to develop a service if one would access directly to the physical layer of a computer system since the physical world is here usually highly non deterministic with many probabilistic phenomena that must be hidden to a service developer. .

It is finally interesting to observe that the standard vocabulary used to discuss of the functional vision is traditionally different, depending whether the considered system is a technical or an organizational system. The term “function” is for instance usually reserved for technical systems (that may be of either hardware or software nature), when one rather uses the terms “process”, “activity” or “task” to express the same behavioral concept when dealing organizational systems. It shall however be clearly understood that processes, activities or tasks are in fact nothing else than functions of a given organizational system, considered at different levels of abstraction.

TABLE OF CONTENTS