2.1 Elements of Systemics
Before going further, we first need to introduce the notions of interface and of system environment. These elements of systemics will indeed be useful for presenting further the CESAM framework. We refer to Definition 0.1 and Definition 0.2 of Section 0.1 for the fundamentals of systemics, that is to say the core definition of a system, on which CESAM framework is constructed.
2.1.1 Interface
The concept of interface is the first key systemic concept1Remember indeed that a systems architect deals fundamentally only with interfaces… (cf. section 1.5). that we need to present. In this matter, let us thus now recall that an interface models an interaction, an exchange, an influence or a mutual dependence between at least two systems (some interfaces may indeed be complex when involving several systems2The toothbrush has for instance a complex interface with the user during the brushing phase since both toothpaste, water and user mouth, teeth & hand are then involved at the same time.). Beware that an interface may not necessarily have a concrete implementation: it is just a way of expressing the relative impacts that different systems have one on the others3Most of people are making for instance the confusion between networks and interfaces. A network is indeed strictly speaking not an interface, but another system with which the system of interest has also a specific interface. In first stages of a design, one may of course abstract it and only consider the logical interface between the systems it connects, but the abstract interface involved in such a mechanism shall not be mixed with the network system in itself..
With respect to a given system S, interfaces may then be either external when they are involving the considered system and some other external systems, or internal when they are only relative to subsystems of S. Figure 18 illustrates this notion on the electronic toothbrush example by showing two external interfaces between the toothbrush and the end-user (here one with his/her mouth, the other with his/her hand) and several internal toothbrush interfaces (that is to say two mechanical interfaces and one inductive interface between the base and the body of the toothbrush).
Figure 18 – Examples of interfaces for an electronic toothbrush
Note also that the technical interfaces, corresponding to a concrete interaction or exchange between several systems, are usually the easier to identify since they refer to a visible relationship between the involved systems. However the invisible interfaces, relative to an influence or interdependence between different systems that may typically be of strategic, political, societal or regulatory nature4Think also on the possible impacts of competitors, new technology, industrialization or maintenance on your system. , are also crucial. They are indeed much more difficult to find. They can thus be easily initially skipped and discovered too late, only at the moment where the designer will “see” their impact…5Such issue typically occurs when existing stakeholders who were forgotten during the initial analysis, remembers to the project team that they exist! We refer to the first section of Appendix B for an illustrative case study of this situation.
2.1.2 Environnent of a System
The recursive nature of systemic analysis naturally leads us to introduce the notion of (systemic) environment of a system. We here mean a closed6A closed system is a system which is considered to have no external interfaces. super-system of a given system S, which will thus be a natural basis to begin a recursive analysis of S. To be more specific, we will say that a system Env(S) is an environment for S if it is a closed system that results from the integration of S and of another system Ext(S) that will be called the outside of S within its systemic environment Env(S).
Figure 19 – Environment of an electronic toothbrush
A real system has of course many real systemic “environments” in the meaning of our definition, the physical universe in its whole being typically a common environment for each real system… However the pragmatic constraints of any system design & development project lead us to define a reference environment for any concrete system S, which will be called the environment of S by a slight abuse of language. This reference environment is the smallest “useful” systemic environment of the system of interest S. It is just the system that results from integration of S and all other real systems, external to S, that have an influence on its design. We will thus neglect in this way all other real external systems when one considers that they have no strong interdependence or no strong interaction with S7One can for instance typically consider that the Proxima Centauri star has simply no influence on most of the engineered systems on Earth, even if it is probably sending them lots of neutrinos each day….
Defining the environment of a system means defining its border, that is to say defining what is inside the system and what is outside the system. Figure 19 typically illustrates this key distinction on the electronic toothbrush example. We described there the main external and internal systems relatively to the considered case study, also specifying their hardware, software or “humanware” nature.
Note also that defining this border is typically the first key systems architecting decision that one must take in practice, since it allows precisely specifying the system of interest which is under design. This decision is usually quite difficult8In the worse cases, it may typically take several months to identify precisely the scope of the system of interest. to manage in reality, especially when a system is a small part of another system in which it should precisely be delimited. One shall also beware of the fact that one can reason on many different systems, all of them being naturally connected to the system of interest, such as for instance the used system (where one put the user within the system of interest) or the maintained system (where one puts the maintenance system within the system of interest), that shall never be mixed.
The inside/outside distinction is also at the heart of the separation between the different visions that are used in systems architecting (see next section for more details). One can typically not speak of needs and requirements with respect to a system without having a clear border between a system and its outside, as we will see in the sequel of this pocket guide.