1.3 Addressing Systems Architecting becomes Key

1.3 Addressing Systems Architecting becomes Key

Due to that complexity threshold as presented in section 1.2, which is – in our understanding – the root cause of most engineering issues observed in complex systems development (we here refer to Appendix B for more details), addressing systems architecting becomes therefore key for engineering organizations that are dealing with complex systems. These organizations are indeed confronted to the need of working efficiently in transversal mode, due to the core integrative nature of the systems that they are designing and developing.

This is exactly the context where systems architecting will bring all its value. This discipline allows reasoning about hardware & software components (technical dimension) and human factors (human dimension) related to a given system, both in a unified framework and in subsidiary with all existing disciplines & engineering fields (see Figure 12). To achieve this goal, the fundamental principle on which systems architecting relies, is a logical vision of engineering brought by systemics. As one can easily understand, it is indeed merely impossible to strongly consolidate all formalisms that are used to model and work with the different components of a heterogeneous system¹ Electromagnetism or fluid mechanics are for instance based on partial differential formalisms such as Maxwell or NavierStokes equations, when signal processing relies on a distinction between time and frequency domains, leading to Fourier or Z transforms formalisms, which have all typically nothing to do with the logical and discrete formalisms used in information technology. Human factors are moreover of a totally different nature, without any strong mathematical background, but they shall also be included in the global picture. We thus do not believe to the existence of a “universal theory of systems” that could federate all these different formalisms since they are analyzing the world in lots of mutually incompatible ways. In the best of our knowledge, systems architecting remains thus the only tool to consolidate all these points of view. . Systems architecting thus proposes a purely logical approach to federate all these “local” formalisms, rather than trying to consolidate them in a unique global formalism.

The main idea here is to simply use logic²In the mathematical meaning of that term (see for instance [12]). as a pivot language in order to be able to work in the same way with all hardware, software and “humanware”-oriented disciplines, involved in a given complex system design & development context. Each discipline can indeed easily formulate its requirements, constraints, findings or models using the universal language provided by logical predicates, which are formally Boolean functions telling us whether a given property is satisfied or not depending on the values of its entries (see [91]). In a system context, a logical predicate is thus nothing more than a statement that may true or false for a given system. A typical reasoning in systems architecting will thus be based on logical predicates associated, on one hand with the whole considered system and on the other hand with the different involved components and disciplines³ Imagine for instance that thermic experts tell us that predicate P1 = “the engine works well only when refrigerating fluid temperature is less than 30°C” is true, when we know through a discussion with fluid mechanics division the that predicate P2 = “the refrigerating fluid temperature can be over 30°C when pressure is low”. Somebody who has the global vision on that two domains can then easily deduce that P3 = “the engine may not work correctly when pressure is low” is true, since it is a logical consequence from P1 and P2, formally P1 ^ P2 → P3 (where the ^ symbol means AND). This is typically a (here quite simple) systems architecting type of (logical) reasoning..

Figure 12 – The integrative & collaborative dimension of systems architecting 

As one can see, there is therefore absolutely nothing magic in the promise of systems architecting of proposing a unified framework for working with all systems dimensions, as a simple consequence of the universality of logic⁴This probably also explains why systems architecting is so difficult to penetrate in practice in engineering organizations. Most of engineers are indeed very well trained in analysis and control theory, but absolutely not in logic which happens to be the core fundamental on which relies systems architecting. It is really a pity if one remembers that logic is probably the oldest scientific discipline in the world, which can be traced back to Aristoteles in the 4th century before Christ (see [84]).! One may also notice that systems architecting can thus be fundamentally seen as an observational modeling approach⁵ A typical example of observational model is Ptolemeous epicyclic system which was a purely geometric model, used from the 3rd century before Christ up to Copernic in the 16th century, to explain the movements and variations in speed and direction of the apparent motion of the Moon, Sun and visible planets (cf. [65] or [85]). This model fitted perfectly with the observations since it was exactly constructed on that basis. It was also predictive, in particular with respect to phenomena such as the Moon and Sun eclipses. But it is nowadays considered as completely false from a physical perspective. This example illustrates what is expected from an observational model: precision and prediction, but not necessarily truth…: the construction of a system model – in the meaning of systems architecting – is indeed the result of the observation of all components and engineering domains involved in the considered system and of the federation of all these observations in a unique logical model of system level.

Last, but not least, it is important to also point out that systems architecting always integrates a strong collaborative dimension: it is indeed simply not possible to construct a system model without implying all people who are representing the different involved system components and engineering domains, as soon as one wants to get a realistic model⁶The best way to construct an unrealistic system model is indeed probably to construct it alone in its corner… . Moreover sharing a system model is also a key good practice for ensuring its robustness. Collaboration is thus at the very center of any systems architecting approach (cf. Figure 12, but also section 1.5 for more details).

All these elements allow easily understanding that systems architecting is the discipline by excellence which is required to efficiently address systems integration issues. At this point, it may thus be useful to position precisely systems architecting within systems engineering (see Figure 13).

To this purpose, let us first recall that systems engineering is nothing else than systemics applied to engineering. Systemics⁷ Systemics can be traced back to the 50’s with the seminal work of H. Simon published in 1962 (cf. [75]). One usually alsocite von Bertalanffy, who tried – but without being terribly convincing – to construct a “general systems theory” (cf. [80]). here refers to the discipline that deals with – formal and real – systems. It provides holistic vision and holistic analysis methods (see Chapter 0 and [96]), integrating crosswise all dimensions of a given topic. Systemics applies to many application domains such as archaeology⁸We refer in this matter to Case study 2., biology⁹Systems biology defines itself as the computational and mathematical modeling of complex biological systems and as an emerging engineering approach applied to biological scientific research (see [93]). Systems biology is a biology-based interdisciplinary field of study that focuses on complex interactions within biological systems, using especially a holistic approach applied to biological research (holism instead of the more traditional reductionism)., city planning¹⁰Systemics applied in city planning means considering all the many different dimensions of a city (economy, energy supply, entertainment, people welfare, traffic, water distribution, waste management, etc.) when taking an urbanistic decision. Due to the numerous interactions between the sub-systems of an urban system, it is indeed quite easy to take an optimal local decision which is globally under-optimal (e.g. developing public transportation in an area to resorb local traffic congestion, but that as a side-effect is increasing the value of the considered area, thus bringing middle class people in that area and moving population, and at the very end, creating new traffic jams since the new inhabitants had two cars in average, one for each person in a husband-wife couple). One thus understands that systemic models are of interest for urban design., enterprise¹¹Systems approach applied to enterprise typically gives rise to enterprise architecture frameworks (see [86]) such as for instance TOGAF ® (cf. [77]) or our own (see Section 0.4). or psychology¹²Systems psychology is a branch of both theoretical psychology and applied psychology that studies human behavior and experience in complex systems. Individuals are considered within groups as systems (see for instance [95]). A consequence of such an approach is that one cannot cure an individual who has psychological or sociological problems without trying to understand the groups to whom he/she belongs. Root causes of his/her problems may indeed be found at group level and shall thus be addressed at that level and not at the individual level. For instance, if an alcoholic father beats his child, one must typically understand the cause of his alcoholism and tackle it, rather than taking the child out of his/her family. to provide few non-exhaustive examples. From a systemics perspective, systems engineering is thus just another application domain.

This fact must of course not make us forget that systems engineering (cf. [94] for more details) also has its own tradition that goes back to the 1950’s, with first textbooks in the 1960’s (see [96]) and its first industrial processes formalization with the seminal NASA systems engineering handbook in the 1970’s (see [66] for current edition). Many other textbooks (such as [9], [10], [15], [30], [47], [57], [61], [62], [71], [74], [78]) and industrial standards (such as [5], [42] or [44]) were then constructed in the line of that initial works. More recently, the International Council on Systems Engineering (INCOSE) emerged in the 1990’s. It is currently federating and developing the domain at international level (see for instance [42] for the INCOSE systems engineering handbook).

Following INCOSE (see again [42]), systems engineering defines in particular as “an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem (operations, performance, test, manufacturing, cost & schedule, training & support, disposal)”. When one analyses more precisely the systems engineering processes, one can however decompose them naturally according to a product/project distinction as discussed in section 1.1, that is to say in the following two types of activities of quite different nature:

• Project-oriented activities, such as systems projects planning, follow up and monitoring, engineering referential and configuration management, reporting and quality, which may be seen as systems project management,
• Product-oriented activities, such as requirements engineering, operational, functional and constructional architecting, trade-off and safety analyses, verification & validation, which do cover exactly the scope of systems architecting.

In that perspective, systems engineering can be seen as the union of systems project management and systems architecting, which can thus also be analyzed as the core part of systems engineering, dedicated to the design & construction of robust systems models. System architecting shall thus be seen as the discipline synthesizing the methods and the tools which allow an exhaustive & coherent modeling of a system (in its triple operational, functional & constructional dimensions) in order to manage it efficiently during its lifecycle (design, test, deployment, maintenance, …)¹³Other alternatives definitions are proposed by 1) ANSI / IEEE 1471-2000 [6]: systems architecting is the process of describing the structure of a system, given by its components and its internal interfaces, and the relationships of the components of the system with its environment among time (i.e. starting from the design and including all possible evolutions of the system); 2) Wikipedia [92]: systems architecting is the process of defining a set of representations of an existing (or to be created) system, i.e. of its components (hard-ware, software, “humanware”, functions, roles, procedures, etc.), of the relationships that exist between these components and of the rules governing these relationships..

Figure 13 – Relative position of systems engineering and systems architecture within systemics 

TABLE OF CONTENTS

References

[5] ANSI/GEIA, ANSI/GEIA EIA-632 – Processes for engineering a system, 2003

[7] Antonopoulos J., The great Minoan eruption of Thera volcano and the ensuing tsunami in the Greek archipelago, Natural hazards, 5 (2), 153-168,1992

[9] Aslaksen E.W., The changing nature of engineering, McGraw-Hill, 1996

[10] Aslaksen E., Belcher R., Systems engineering, Prentice Hall, 1992

[12] Barwise J., Handbook of mathematical logics, North-Holland, 1972

[15] Blanchard B.S., Fabricky W.J., Systems engineering and analysis, Prentice Hall, 1998

[30] de Weck O.L., Roos D., Magee C.L., Engineering systems – Meeting human needs in a complex technological world, The MIT Press, 2011

[42] IEEE, IEEE 1220-2005 – Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics Engineers, 2005

[44] ISO/IEC/IEEE, ISO/IEC/IEEE 15288:2015 – Systems and software engineering — System life cycle processes, May 2015

[47] Kossiakoff A., Sweet W.N., Systems engineering – Principles and practice, Wiley, 2003

[57] Maier M.W., Rechtin E., The art of systems architecting, CRC Press, 2002

[61] Meinadier J.P., Ingénierie et intégration de systèmes, Lavoisier, 1998

[62] Meinadier J.P., Le métier d’intégration de systèmes, Lavoisier, 2002 

[65] Murschel A., The Structure and Function of Ptolemy’s Physical Hypotheses of Planetary Motion, Journal for the History of Astronomy, xxvii, 33–6, 1995

[66] NASA, Systems Engineering Handbook, 2007-edition, NASA/SP-2007-6105, 2007

[67] Novikova T., Papadopoulos G.A., McCoy F.W., Modelling of tsunami generated by the gian late bronze age eruption of Thera, south Aegean see, Greece, Geophysical Journal International, 186 (2), 665-680, 2011 

[71] Sage A.P., Armstrong J.E., Introduction to systems engineering, Wiley, 2000

[74] Sillitto H., Architecting systems – Concepts, principles and practice, College Publications, 2014

[75] Simon H., The Architecture of Complexity, Proceedings of the American Philosophica, 106 (6), 467-482, December, 1962

[77] The Open Group, TOGAF Version 9.1 – The Book, The Open Group, 2011

[78] Turner W.C., Mize J.H., Case K.H., Nazemetz J.W., Introduction to industrial and systems engineering, Prentice Hall, 1978  

[80] von Bertalanffy K.L., General System Theory : Foundations, Development, Applications, George Braziller, 1976

[84] Wikipedia, COSYSMO, https://en.wikipedia.org/wiki/COSYSMO

[85] Wikipedia, Deferent and epicycle, https://en.wikipedia.org/wiki/Deferent_and_epicycle

[86] Wikipedia, Enterprise architecture framework,
https://en.wikipedia.org/wiki/Enterprise_architecture_framework 

[91] Wikipedia, Predicate, https://en.wikipedia.org/wiki/Predicate_(mathematical_logic) 

[93] Wikipedia, Systems biology, https://en.wikipedia.org/wiki/Systems_biology

[94] Wikipedia, Systems engineering, https://en.wikipedia.org/wiki/Systems_engineering

[95] Wikipedia, Systems psychology, https://en.wikipedia.org/wiki/Systems_psychology

[96] Wikipedia, Systems theory, https://en.wikipedia.org/wiki/Systems_theory