This series of blog posts is entitled “Managing new complexity, ”but why is it new? With the “Internet of Things,” devices everywhere with “software everywhere”, and people in the middle, means we have had to face new behaviors, including an explosion of interactions and an emergence of properties, without theoretical foundations. Humanity has known this kind of challenge already, for instance from the first steam machine (Heron of Alexandria 1st century A.D.) to Carnot and the first laws/theory on thermodynamic in the 19th century, so much questions! Now even a kid can tell you why an open fridge in a close room will never cools it down.
Socio-technical systems can be, for instance, an enterprise, a department in a public administration, a community in a social network, or also a city which offers more and more interactions with its citizen via mobile applications for instance. With my laptop right now I constitute a socio-technical system. Let us focus on this. On a System of Systems (SoS) point of view I am a biological-ethical-system, my computer an IT system. We both have goals; right now mine is to write this article in interaction with a word processor, a sub system of my computer, and my word processor goal’s is to offer me word processing and sometimes (!) correct my spelling mistakes. The system composed by my computer and me has a main goal; in this context it is a written article with no spelling mistake. What about other properties of such a SoS? For instance, what is its spatial boundary or its time boundary? When I leave my chair to have a coffee, and I’m still thinking about this article, which preserves the goal of the SoS, how may I characterize this property? When I am writing, and suddenly a thought which has nothing to do with the article crosses my mind (a sub-system of me) interrupting the main goal, while my fingers (with a certain degree of autonomy) are still achieving the main goal, how can I characterize this property? How can I represent it, model it, design it, if I want to simulate it? In fact, there is not a clear and shared answer in the various communities working on SoS. In my reading about SoS and how to characterize and define them (problematic #1), I found a PhD thesis, “Proposal for a Product Centric Multi-Scales Modeling Framework of an Enterprise Information System” written by J.P. Auzelle, where one can find a synthetic summary of what are the main characteristics of SoS shared by the different communities which work on the subject. The figure below is adapted to it.
Ok, there is a beginning of a shared characterization and definition of SoS. But are there any theoretical foundations of SoS (Problematic #2)? Whilst SoS is a reality, on what should one base one’s reflections to improve SoS design and operation? The best to do, right now, is to ask your neighbor, think by analogy (sometimes it works!), find best practices in your field of operations, try and … pray! The main cause of this lack of a unified theory about SoS is due to the multidisciplinary nature of SoS. For instance, interoperability which is a fundamental concern of SoS must be design and operate at various levels. The European Interoperability Framework has four levels: legal, organizational, semantic and technical. Then, you need many types of expertise to address these four levels: lawyers, sociologists, psychologists, engineers, (…), plus climatologists, agronomists, physicists, etc. if you are working on a SoS in the fields of agriculture or a supervision system based on satellites. Furthermore, as you can see in the above figure, several authors have identified characterizations of SoS and have tried to define them, but still, there is no set of agreed principles for SoS, and there is not an established conceptualization for SoS. For this last one, many people involved in SoS think we need a new way of thinking. Reductionism, based on a common way to analyzing things or situations, is not enough and not even appropriate. For instance, if you search the optimum of a system, be sure it will not be the sum of the optima of the sub-systems which compose it. A holistic approach tends to be one, as they proceed in the cybernetics communities, for instance.
SoS have sometimes a behavior that seems a bit bizarre, at least unexpected, as it relates to emergence (Problematic #3). This fundamental property of SoS may come from changes in the ecosystem in which the SoS is immersed in, or changes to individual systems and/or changes to their interactions. Emergence can be beneficial or detrimental; in both cases it is mostly unpredictable, meaning you cannot design it. At the very least, it is difficult to operate. As there is no theoretical foundation for SoS, there is no fundamental models for SoS to provide a scientific understanding of how and why emergence occurs. Note that in the case the emergence would be beneficial, it could be interesting to exploit this situation; at present you can detect it, but sometimes it’s too late.
What about the “damned human factor” in all that? The human aspects (Problematic #4) are usually taken into account as a high-risk in security policies, although the higher levels of interoperability are concerned with human aspects, either at the individual level or organizational level. The human aspects are not seen as an integral component of the SoS, with, for instance, statistical, fuzzy logic, or stereotyped behaviors or interactions with others sub-systems.
Last summer, an active SoS community, The T-AREA-SOS (Trans-Atlantic Research and Education Agenda in Systems of Systems), had proposed an agenda for 2020 composed of twelve themes to work on to better understand, control and command SoS. I gave you a summary of the first four ones. The others are as follows:
- Multi-level Modeling (Pb #5): need of a meta-modeling approach that joins the need of theoretical foundations.
- Measurements and Metrics (Pb #6): what to measure and when is still not yet complete and consistent enough due to the independence of management and operation of the components.
- Evaluation of SoS (Pb #7): even if there are many things to take from software engineering discipline, for instance SPEM (Software & Systems Process Engineering Metamodel), for highly reconfigurable SoS and those which involved more physical and social aspects further works are needed.
- Definition and Evolution of SoS Architecture (Pb #8): architecture frameworks like Zachman, IAF, and more recently Togaf, with their high level and holistic approach of enterprise architecture are good candidates for future research that “should address dynamic architectures, partitioning, and the explicit means through which architecture informs decision making process”.
- Prototyping SoS (Pb #9): due to the lack of knowledge about emergent behavior which may not be observable until the SoS is complete.
- Trade-off (Pb #10): know all the possible trades between SoS and its ecosystem and inside the SoS is difficult and even impossible due to the lack of characterization and definition of SoS, the dynamic nature of the SoS and its ecosystem.
- Security (Pb #11): Interoperations are needed, but are also breaches for security. This problem area needs research to develop the “means to ensure that the physical, ethical, and cyber aspects of safety and security of the SoS, its people, its end-users, and its social and physical environnement are properly addressed”.
- Energy-efficient SoS (Pb #12): all SoS need energy, “there is a need to operate them in such a way as to minimize the detrimental effects on” their ecosystems.
In Toulouse Sogeti works on an ambitious innovative program that tries to include new visions, methods and techniques in the field of SoS WE call it “Cockpit for Big Systems (CBS),” a centralized and agile solution to control and command ultra large scale systems (scale of 1 million assets (CPU, GPU, RAM, HD, printer, License, …) in organizations with scale of 100 000 employees. Any inputs are welcome!
Next week I will talk about the potential of Reflexivity in our context of SoS.
 Is it a composition or an aggregation? Will see later, the answer to this question is not so easy.