Relying on standards and public documents of system engineering and management in our version of a systemic approach ​

The version of the system approach that we present in our course is based mainly on the material from standards and public documents of systems engineering. We have added some management standards to the engineering standards. A public document is a standard for which a conformity assessment procedure is not defined. However, everything else is the same: the specification is issued by some collective and regularly reviewed. Public documents serve the purposes of informing, disseminating knowledge, rather than unification. These are mainly materials of the second generation of the system approach, "target systems that are conceived, manufactured, and operated by system creators from teams of people".

Of course, we have incorporated modern ideas of the third generation system approach that have emerged in physics, biology, and control systems engineering in the last five years. We have discussed these ideas in previous sections (scale-free networks, including scales of size as well as time scales, including Darwinian/biological evolution and techno-evolution, non-anthropomorphism in exposition, conflicts between objects of different system levels, and disorder).

Nevertheless, the main concepts and terminology were taken from the engineering and management versions of the system approach, not from academic literature. From these standards and public documents, we took the basic concepts and their terminology, and only slightly adapted these concepts and terminology to make the connection between the concepts defined in various standards and public documents obvious.

Relying on standards is important because the standards and public documents themselves are regularly reviewed every few years. This allows us to stay up to date, unlike how the texts of the general systems theory by Bertalanffy have become outdated for decades and can still be found in bookstores and on the internet today (remember that these ideas were first proposed in the 1930s). Someday, the version of the system approach that we present in the course will become outdated (and it has happened before! The current text is the result of the ninth revision!), but by relying on regularly reviewed standards and public documents, as well as regularly published scientific articles, this can be noticed (as we noticed the recent shift from "interdisciplinarity" to "transdisciplinarity" in public documents of systems engineering, the recent discovery of the role of disorder from conflicts between different system levels as the basis of complexity growth in biological, memetic, and techno-evolution, the departure from requirements engineering in systems engineering, the departure from the concept of the life cycle toward "continuous everything").

In our version of the system approach, we used the following versions of engineering and management standards and public documents (this list is not exhaustive, only the main sources presented^[1]):

• The standard ISO/IEC/IEEE 15288:2023 Systems and software engineering --- System life cycle processes defines the concept of a system and life cycle, distinguishes the system of interest, the system environment, and the enabling system, introduces the concept of life cycle methods/processes/practices. Although it is significantly outdated as it mainly assumes a one-time development, it includes requirements engineering methods, which are no longer relevant in engineering (this became irrelevant around 2017, but international standards of this level change slowly). Nevertheless, we still use many concepts introduced by this standard.
• The general architecture description standard ISO/IEC/IEEE 42010:2022 Systems and software engineering --- Architecture description introduces the multiplicity of descriptions and an activity-based approach. This is a "mind shift" from the reductionist approach of one-sided description to a systemic approach, implying the multiplicity of related descriptions located in different information systems.
• The generic OMG Essence 1.2:2018 --- Kernel and Language for Software Engineering Methods standard sets the language for describing the creation and development method of a system in terms of working methods/practices. This standard also introduces checklists/control questions. We use not so much its Kernel (set of basic alphas) but its Language (the concept of alpha as an important object, for which the state is tracked in the project of creating and developing the system).
• The IEC 81346-1:2022 Industrial systems, installations and equipment and industrial products --- Structuring principles and reference designations --- Part 1: Basic rules standard is used for the minimal necessary description of the structure of complex engineering objects, defining the principles of designating systems and their parts. This is the foundation for configuration management throughout the life cycle. Additionally, this standard distinguishes three types of descriptions: functional, product, and location, although it does not address the need for cost description, which is already essential for modern systems thinking.
• The ISO 15926-2:2003 Industrial automation systems and integration --- Integration of life-cycle data for process plants including oil and gas production facilities --- Part 2: Data model standard is used for modeling the data of expanded (full) descriptions of engineering objects, supporting the integration of data from various information systems of the life cycle of engineering objects. It is important for the introduction of 4D extensionalism concepts, which saves thinking through transforming a large number of relationships between objects into part-whole relationships if these objects are represented not as objects in space (3D) but as objects in space-time (4D).
• The public document NIST PWG Cyber-Physical Systems (CPS) Framework Release 1.0 (2016) clarifies the description methods for cyber-physical systems, introduces a classification of aspects for important characteristics of systems/objects of interest of project roles.
• The public document Guide to the Systems Engineering Body of Knowledge (SEBoK):2023 gives us the definition of a successful system and many other definitions of the system approach.

To reiterate: Most of these standards and public documents do not yet take into account the changes in the past five years in the methods of modern systems engineering and other methods of the intelligence stack, so our course does not fully adhere to these standards (previous versions of the course, corresponding to the previous generation of systems thinking, were more in line), although it maintains continuity. Thus, the standards universally give a reference to the life cycle of the system as a one-time passage of work through life cycle methods/working processes. In modern systems thinking, the concept of "continuous everything" is used instead: methods of creating and developing a system that take into account the constant development of the system as a continuous creation of new versions of the system, not a one-time creation of the system, leading it "from birth to death", as in biology. Our course reflects this shift to methods of "continuous everything" in engineering.

We guaranteed the universality of our version of system thinking by actually using it in a variety of projects - engineering, managerial, starting new activities, pedagogical, cultural, artificial intelligence, research, etc. (not only projects done by system engineers of the world but also projects of the course authors, and projects of numerous graduates of previous versions of the course). The course with its modern version of system thinking is not just a result of academic work with texts, it is a result of numerous trials of the proposed version of system thinking in real projects.