Relations of creation
The concept of creating a metaphorical graph can be illustrated by a diagram:
In the diagram, the target system (denoted by a red circle, the "origin" for system descriptions) is located in its system environment, i.e., it is part of the supra-system of the target along with other systems. The supra-system is denoted by an encompassing circle in the environment, which includes other circles with subsystems within them - systems in the environment of the target with their subsystems. It is important to note that the target system undergoes techno-evolution. It has its own subsystems (circles within the red circle). Each level of grouping parts within a system (represented as smaller circles within their encompassing larger circles, on multiple nested levels) is called a system level. The system level of subsystems of the target system - three circle-subsystems within the circle of the target system, two circles around the target, and the target system itself within the supra-system - represents the system level on which the target system is located. We do not detail the specific system levels further but simply indicate separate supra-systems.
The target system exhibits its external properties to the supra-system "as it happens" during its operations. This is indicated by the term "phenom here." The term run-time is often used in software engineering to denote the time of functioning/operation of a ready system. However, in the diagram, it is represented by another equally common term - Ops-time, the time when system operators work when the system is in a functioning state.
Target systems are not created and developed on their own. They are created and developed by creators who employ visionary, development, architecture, DevOps, and other methods. The creation systems include agents with their tools. Agents in the narrow sense (autonomous intelligent reasonable agents) are depicted as circles with "faces," and their clearly non-living equipment (from a screwdriver to a data center) is represented as circles without faces. Organizations are depicted as composed of intelligent agents and their equipment and tools. It is worth noting that during operations, some agents from the diagram enter the environment (for example, a user::external-role-from-computer-system enters its operational environment, unlike a computer factory, which will be the creator of the computer and will be considered during creation/dev-time).
These creators create and develop (often by simply modifying the state rather than creating from scratch - like painting, adjusting, adding features, repairing) target systems, subsystems, and supra-systems of target systems. Creators in various project roles have diverse emergent characteristics of various systems at different system levels. Therefore, they try to design and predict the success of the target system based on emergent characteristics by making "smart mutations" during system development. In this process, they collectively edit the memome of the system during its creation and development. This is indicated by the term "meme here" during the creation time (we omitted the term "and development" for brevity, but development is often as important as creating MVP), opposite the term "phenom here."
Techno-evolution, like biological evolution, involves "species development," not just the growth/production of one organism/"product specimen." At each step of techno-evolution, there is a design project of the current generation of the product/system with a level of detail sufficient for production (e.g., instructions for a CNC machine, as well as assembly robot instructions in machine CNC language and robot). This design project itself embodies inventive ideas by developers (how functional objects are implemented by constructive items, how they are arranged in space, how much they cost), akin to genetic information in biology which is stored in the genome inside the target organism (but in genetic engineering also in the memory of creators, e.g., in laboratory computers). In techno-evolution, the analogue of the genome - the memome - is stored with the creators. The target system is then created with its features already in place: the memome generates the phenom, just like in biology.
The terms used for creation and development time in software engineering - dev-time (from "development"), often design time. When looking at creators, we do not consider the working/operating target system, but rather the system at the moment of its creation (conceiving/strategizing its use, designing, manufacturing, introducing it as an MVP, followed by incremental flow of functional and structural development). Other methods of creation time (engineering justifications, architectural decisions) are also present, but they are also omitted for brevity. The main idea is that the focus is on the course/time of creation, dev-time, rather than ops-time. Creation systems and systems from system levels within and outside the target system are considered at different times/realms, reflected by the dashed vertical red line from which creation relationships intersect with arrows.
There is a time for cooking borscht (creators - cooks), there is a time for eating borscht (the target system - borscht), wherein examples include the situation of lunch serving, the interaction of mouth-tongue-teeth while eating, and the stomach during digestion - these are all ops-time, while dev-time entails changing the state of fresh vegetables, raw meat, and water by the borscht creators in the kitchen, until the final state of "borscht in a bowl, ready for consumption." There is the time of rocket assembly, and there is the time of the rocket's flight. The work of engineers with the rocket is completely different from the work of astronauts on a flying rocket. In systems thinking, it is essential to clearly distinguish the time being discussed, where the main focus is on the operation/working of the system (all functional descriptions are within it). However, there is also the time of creating the system (all constructive descriptions are within it), which is not the main focus but is still important.
Of course, there are challenges and commonalities in viewing this time, known as the DevOps problem - when system developers/creators are not connected to operators/users, leading to a system that is unusable. This problem is primarily addressed through organizational measures, but today technical measures are often involved as well: operators and even users are completely replaced by robots, a concept known as NoOps. In any case, in systems thinking, the primary focus is not on considering everything happening in development and usage as belonging to one physical time frame, but rather on distinguishing between the "logical" times of creation (development, design, construction, implementation, enabling - where creators' work methods are central, and the target system is passive, not yet ready for operation) and the time of operation (run, operation, use - the functions/methods of the target system itself, with creators no longer actively involved).
One could discuss digital twins in this context, where their main role is automated management, replacing the operator in adjusting parameters of an operational target system, either by automation or a composite system involving humans (manipulating physical controls or components in the real-world setting) and an informational control system (indicating actions to adjust controls and components, such as the need to replace unreliable components - managed by predictive analytics software, for example, for maintenance based on state). Digital twins operate during usage, not during creation.
The relationships between systems in the environment (target, supra-system, systems within the supra-system comprised of components from the near environment, etc. - whenever the term environment is mentioned, always keep in mind that it refers to the "operational environment"/"operations environment," related to operational times) and their creators also involve creation relationships (development, design, construction, implementation, enabling), where one creator/system describes and/or modifies another system. These relationships represent the whole chain of creation, from creators' creation sequence to the target system. These creation sequences constitute a graph of creation, typically a directed acyclic graph.
Creation relationships are not part-whole relationships! Enabling/construction is not composition/part_of! The pot in which borscht is cooked is not a pot as part of borscht, or borscht as part of the pot! It is the pot for creating borscht!
Now, mark any of the circles in this diagram that your small team (possibly just yourself) will be dealing with as part of a larger project team - this will be "our system" (system-in-hand, engineered system, MySystem, OurSystem). Repeat all considerations for the target system for our system - without ever forgetting the target system and the relationships between our system and the target system!
Feeling overwhelmed? Document all these systems in a text editor or another modeling tool, similar to how a chess player notates a chess game. Think not just "mentally", but think about the text, outline, or table!
System thinking involves using models/descriptions, where attention should be held not in the thinker's mind but in documents (today - electronic, including informational and simulation models, yesterday - paper documents). Thinking is always about written thought and written modeling!
Our diagram of the creation graph (a form of representation where squares or circles of object symbols are connected by arrows to represent relationships) is used in the course solely for explaining a small, unchanging set of concepts not tied to specific projects. It will not be modified during the project as it contains very few details. This illustration is for educational purposes, not a working tool for system modeling. We do not recommend diagrammatic modeling in operational projects, but we require mandatory system modeling in projects in the form of texts, outlines, and tables: formats that are easy to edit/change, search through, and expand without fear of getting lost in complex connections.
Systematic documentation is crucial in system thinking. Attention that is managed without records is managed unreliably. People are forgetful, so document/write down everything (absolutely everything)!
Detailed information on how to model changes of important objects in the project will be explained in the course "Methodology."