Conclusion 1
Introduction
Some authors, whose names we will politely omit, mix human beings, organizations and technical systems in hurried concepts, without marking the difference between their specific characteristics, within a rationale close to syncretism in which everything is linked, everything is in everything and vice versa. On the contrary, the 12 chapters of this book have demonstrated the richness, even the polysemy, of the notion of system. Such richness, such complexity, takes us all the farther from a basic definition.
Let us keep in mind a few important, structuring points which will have to be studied in depth to offer the systems of systems the proper concepts, methods and tools.
Evolutions and stakes
We have seen the characteristics of systems of systems, their constitutive systems, their organization in terms of architecture, and their operation modes.
If, at first, systems engineering treated the systems mostly, sometimes exclusively, in terms of product, recent evolutions, partly linked to the development of systems of systems, lead to the apprehension of systems in terms of service. These evolutions are not without consequence. As a service, the system modifies the contracting models, the processes and activities which must be implemented. In this way, we try to contractualize quality of service through time, in terms of performance, availability, absence of anomaly. Validation is not only performed before the operational use of the system, but during all its operational exploitation. We do not purchase a system, rather we purchase its use, a service. We are still in a technological context when the service treats information; after a few adjustments, the same concepts are implemented. In the case of human services, however, in which the result depends on the quality of the interaction between the service’s client and the supplier, and the object of transformation is not a technological object, but the service’s client (health service, education service), we rapidly leave the purification of our concepts, methods and tools behind. It is no longer a problem of adaptation, but entails important evolutions. One of the first and main consequences concerns the contracting mode. The supplier doesn’t guarantee the results, but the means. If we try to reduce the variables within the realization of a product or a technical service – which is, incidentally, what defines quality of service – it is much more difficult, or even perfectly illusory, in the context of human services. Of course, mechanisms, such as protocols, help control the variability inherent to any living system, but the abusive use of such mechanisms might penalize the interaction between the client and the service supplier and, in fine, deteriorates the quality of service more than it improves it. Indeed, the intersubjective relationships that come into play and largely contribute to the client’s satisfaction can neither be modeled, nor simulated, with the engineer’s concepts and mathematical tools. But are we still talking about the same thing?
We are facing a singular situation. The word “system” is polysemous. On the one hand, we have systems engineering, and on the other, systemics. Through lack of rigour, some authors mix them up, which we find deplorable, since this considerably reduces the capacity of progress and enrichment of the concerned disciplines.
Indeed, systems engineering is a discipline, the engineer’s science to conceive systems. The systems are designed by human beings, heteronymous systems. The human designer is looking for complete control of the system, which must behave as has been defined. Risk analysis and reliability activities are led to plan different behaviors and design a set of solutions to control these behaviors. In this context, a system’s autonomy resides in the elaboration, by the designer, of a defined set of rules and laws within the system, so that the latter can adapt its behavior according to the environment’s demands. We cannot talk, stricto sensu, about the system’s autonomy, since the system itself doesn’t create its own rules1. The highest control of behavior is associated with the reduction of variability. This concerns technological systems. If, in the various definitions we can find in literature, the human being belongs to the system, it is a fallacy, for such a thing is quickly eluded and none of the concepts, methods and tools of systems engineering offer the capacity of taking human behavior into account. This is not surprising. In a heteronymous system, in which the engineer is looking for the highest degree of control, the existence and standardization of the behavior of an autonomous agent are neither coherent nor easy. Apart from the heteronomy, the system is characterized by a clearly defined perimeter, which also marks the limits between the system and its environment, with specified interfaces between them. The system dimension resides, for the most part, in the fact that numerous acts of engineering are called upon to specify, conceive, design, validate, maintain and take apart that kind of system. Systems engineering is based on the analysis and the breaking down of the system into subsystems, in a recursive manner. This point is important, for it differentiates systems engineering from systemics2. Since systems engineering is interested in the system to do and the processes and activities needed for that purpose, it is the counterpart of project management, which concerns the management of the means put to work to create this system, while respecting the deadlines and the financial envelope. We are in the field of control.
If systems engineering aims for mastery and control, systemics have another goal, to understand an ensemble of phenomena in the field of living forms and materials. The concerned systems are not designed by human beings, and display autonomous behavior. The question is raised as to what concerns organizations, both autonomous and designed by human beings. Apart from the autonomy of the observed systems, what differentiates systemics is the inability to analyze or break down the systems. Systemics tends to demonstrate other major properties of systems, such as the capacity to maintain, generate, reproduce and adapt oneself within a process of conjoint and interdependent evolution of the system and its environment. Moreover, these systems are also characterized by blurry boundaries. These major properties make the system a priori uncontrollable through the concepts, methods and tools of systems engineering. Finally, systemics deal with dimensions and concepts, such as the paradox, or the trust that people can have for each other, dimensions and concepts that are not familiar to engineers and the mathematical tools they have at their disposal, and which are however necessary in a human services rationale. Paul Watzlawick, who just left us a year ago, has largely contributed to the subject ([WAT 72, WAT 75, WAT 78]).
The situations which we currently have to deal with, such as the need to control the ecosystems’ dynamics in order to avoid huge catastrophes, bring us to a paradox. On the one hand, the concepts, methods and tools of systemics which help report these complex phenomena, do not help control said phenomena. On the other hand, the concepts, methods and tools of systems engineering, which help control these systems, are incapable of reporting and maintaining natural systems. Faced with this paradox, two solutions appear. The first one, frequently implemented, consists of using, without proper judgment or a reflection on the relevance of that action, the current concepts, methods and tools of systems engineering on the living, complex, autonomous and dynamic living systems. Despite justifications under cover of mastery of complexity, this first solution is basically akin to the “garbage can model” described by James March. The second solution, which we recommend, is more demanding and does not necessarily receive a warm welcome from a quick and dirty thinking. This solution consists of making the systems engineering corpus evolve, in order to design the conceptual tools necessary and sufficient to reach the objective of improved control over living systems, without however seeking illusory control, as defined by systems engineering.
How should these concepts, methods and tools evolve?
Obviously, it is not possible to validate a system, such as an organization, with a validation protocol, by theorizing that the organization will keep on behaving like it did during validation. It is just as obvious that for an ecosystem, there is no acquirer demonstrating needs and no supplier designing a system to fulfill said needs. Just as radically, we cannot treat the interaction between a system and its environment, in terms of interfaces and flows exchanges. Indeed, interaction, in keeping with the principles of coevolution, can modify the system’s organization and operation. The rules of command and control are far from embracing all the complexity structuring the laws of social regulation within a group of human beings.
If an answer cannot be reached in this conclusion, for it alone would require, at the very least, its own book, we can identify the actions which must be led. In the various domains described by systemics, it is necessary to identify the phenomena subsets which must be controlled by human beings in order to avoid ecological and human disasters. For each of these phenomena subsets, it is necessary, on the one hand, to understand, among other things, their dynamics, the interdependence they have to other phenomena, the modes of regulation governing them; on the other hand, it is necessary to define the objectives of control of these phenomena in terms of desired or feared evolutions. Then, it is necessary to make the concepts, methods and tools of systems engineering evolve, in order to control these phenomena, to evaluate the state of these phenomena and channel the evolution of the states of these phenomena depending, on the one hand, on the defined goals and on the other hand, on the evolution laws of these phenomena, e.g. chaotic.
These are the important, even critical, stakes. To reduce complexity through a Cartesian breakdown rationale is to condemn ourselves to failure.
What should be remembered?
The specification, design, realization, validation, and implementation of systems of systems put into sharp light the need to make the concepts, methods and tools of systems engineering, which help control human-designed systems, evolve, enriching them against the yardstick of rich production in the field of systems, and the first works on services science. Listening to the sirens who singsong that the current concepts are enough, is dooming ourselves to failure. Like Ulysses strung to the mast, the ones who will succeed are the ones who, with perseverance, will have made the concepts evolve and progress in order to reply to the challenges we are confronted with.
Bibliography
[ABE 05] ABE T., What is Services Science?, The Fujitsu Research Institute, Research Report, n° 246, 2005.
[MOR 05] MORIN E., Introduction à la pensée complexe, p. 28, Le Seuil, Paris, 2005.
[WAT 72] WATZLAWICK P., HELMICK-BEAVIN J., JACKSON D., Une logique de la communication, Points Seuil, Paris, 1972.
[WAT 75] WATZLAWICK P., WEAKLAND J., FISCH R., Changements, Points Seuil, Paris, 1975.
[WAT 78] WATZLAWICK P., La réalité de la réalité, Essais Seuil, Paris, 1978
1 Conclusion written by Jean-René Ruault and Dominique LUZEAUX.
1. Autonomous; from the Greek word autonomos, “which governs itself with its own rules” (new etymologique and historic dictionary, Larousse, 1971).
2. The definition of the notion of system, from the standpoint of systems engineering, belongs to what Morin calls the system analysis in systemic theory [MOR 05].