Descriptions
But why do we need descriptions, mental/ideal objects?! We are primarily interested in all kinds of descriptions:
- Symbolic/sign/linguistic descriptions, as opposed to connectionist/neural network descriptions. We need collective development, that is, the ability of multiple agents to access the same description for both corrections and familiarization. Symbolic descriptions are easy to detach (documentation), copy, and transmit during collective development. A description located in an agent's neural network is difficult to detach - there, instead of "copying, transmitting," there is "learning," a completely different mechanism of transmitting descriptions.
- Descriptions within the framework of a theoretical theory (objects and relationships, the work of slow thinking S2), rather than a prototype theory (work with metaphors and analogies, concept blending, the work of fast thinking S1). Formality of the description is needed to facilitate verification.
We need to document descriptions for (collectively organized) thinking: they help maintain focus on important objects in the physical world (documents/external memory help keep the attention of various system creator agents on the objects described in it). Additionally, these documented descriptions can be used for transferring experience from one project to another, if they describe not instances of the system but their type (a set of some kind/sort of systems). If you have created an information model of a stool, it will be an information model of not just one stool; you can produce a dozen stools based on this information model and use these ten stools in ten different projects.
When people talk about a "description," they most often mean a "documented description" or even a "document with a description." However, be wary: sometimes "description" does not necessarily mean that it is documented; sometimes there is a description (a concept, a mental object), but there is no document with this description (a physical object). When you hear "description," determine from the context what is meant: the actual description or a document with the description. In our course, we will also use "description" when it comes to a "document with a description." However, you must clearly distinguish between the description (a mental object), the document with the description (a physical object, usually with a sign description), and the system being described (sometimes through a chain of descriptions of descriptions, but ultimately - the system, that is, a four-dimensional piece delineated from the world's space-time by a boundary).
Thinking in the creation/construction of new systems, in learning and subsequent modification of existing/brownfield systems usually occurs not for individual instances of systems, but immediately for sets of systems, that is, for types of systems. Of course, it is possible to describe a specific instance of a system in a specific environment at a specific time (for example, recording pump breakdowns at a substation in a database or recording earthquakes in a database, or recording a patient's medical history, or events in a country's chronicle), but these are usually records of system operation time, not development time. Development (conception, design, manufacturing planning) is always conducted not for specific instances of systems but "in general," that is, for sets/types/classes of similar systems, even if it is about creating a single system (e.g., the Eiffel Tower or a new country).
A set/class/type/sort - this is a mathematical/mental/conceptual object. In mathematics, a set of one object is not equivalent to that one object: the properties of the set differ from the properties of the object in that set.
In systems thinking, the same applies: we are interested in specific systems embodied in our physical world, but we model them involving assigning types/classes. Our thinking captures something common in all situations; it does not occur for specific systems about which we know various facts. Thinking usually occurs for classes/types/sets/kinds/sorts of systems/embodiments_of_systems/instances_of_systems. And, of course, mental objects (sets, types) can be easily altered: changing abstract objects does not require expending energy on moving the material embodiment of the system, only energy is required to alter the material for embodying signs, which is significantly less.
Information technologies work with descriptions, so if you deal with computers and computer networks, be careful not to confuse a documented system description (an information model on some material medium) and the embodiment of the system. You can easily understand that a photograph of a person is not the person depicted in it. It might be a bit more challenging to grasp that a piece of paper with data about the temperature of a rocket engine is a description of the rocket engine, and the paper itself is not crucial here. But if we are talking about a small database describing the behavior of a rocket engine in a series of tests - that's where confusion may arise, as the database itself appears as a system to its developer, which may seem like the goal of their work, the target system, the embodiment of the system, a material/physical object and the result of the work. No, the database here is a documented description of the rocket engine, just not documented on paper. Even if we consider this database together with a software program for controlling the rocket engine and call it a digit twin[1], what will actually interest you is the behavior of the physical twin, that is, the rocket engine itself. And during the development of such a database and all the programs around it, the primary focus must be on the engine::physical twin::subsystem! Failure to keep the developer's focus on this engine may result in the database detaching with its content from the description of the real physical world, making it useless, or even harmful. The system will consist of two subsystems - the digital twin::software (still taken into account the hardware, software cannot exist without a computer) as one subsystem and the physical twin as another subsystem. If you do not understand the system you are working on and are only focused on one subsystem, you will encounter significant problems in the project: when the two subsystems start working together, the system will not function - and you will run out of money (or the money already paid may be taken back! Nothing works, why pay for it?!).
The ability to understand the system being described in physical reality, if you are shown a description in the form of some data structures documented on a computer - this is a key skill for everyone dealing with modern information technologies. If you have a CRM (customer relationship management) system, its databases precisely describe the clientele as a whole system in the real world, and the parts of the clientele - these are individual clients (possibly grouped into segments, but it is not necessary at the moment; what matters now is to understand that the clientele is a system in the real/physical world, and the computer-based CRM system relative to this clientele is roughly like a photograph of a person relative to that person, a document with a description that provides convenient means of viewing the document).
This does not mean that, at some point, the software system as a physical object will not be of interest. It will be, just as a printed book is of interest to a typographer. However, we do not discuss the plot of the book with a typographer. Similarly, with a data center administrator, who is essential for the physical existence of a computer program, we do not discuss the "plot" of the program. Focus on not just the program but the embodiments of the system that describe the data of the program, on changes in the physical world that the program authors want to influence (for example, in a CRM program, authors aim to impact the clientele, not just the contents of the database. If the CRM program does not affect the clientele as intended, it may not be used in the project at all, not be developed, or manufactured).
When you find the system described by software, you can judge how successful the program authors were in implementing their idea - how well the software helps do something with the system described in its data.
For instance, software for shopping in a store describes real physical products in the store and potentially coming to you in the physical world. The software influences these products.
If the software does not affect the state of the physical world, then questions arise. A computer program by itself is not necessary; it is needed solely to modify the physical world using the descriptions encapsulated in it. Do not be deceived by the physicality of what happens in the printing house, the physicality of what happens in the data center, the physicality of what happens with the courier. Keep your attention on the physicality of what is described by the information carriers.
Pay attention to the language your conversation partners use: if someone says they are writing a report and their task is to "submit the report," double-check: do they really think they described the work of a courier who "delivered a packet of documents"? This often involves "using the results of the report" for something that changes the physical world. If this context is absent in the conversation, your conversation partner is either lying, being deceitful, significantly mistaken, or poorly articulating the essence of their work - and you need to ask additional questions to understand what is happening with their work.
To do this, you need a breadth of knowledge and applied skill. If you are developing an ERP system (enterprise resource planning), you must understand: the ERP system documents and allows convenient viewing of various descriptions of the resource flow (resources - raw materials, semi-finished products of various processing and assembly levels, finished products, "stuck" in the company that produces something - all these are physical objects, things taking up space in space-time). The ERP system serves as an information model, a modern "pen and paper," external memory for the minds of company employees; it merely reflects the state of this resource flow, and the planning module will also reflect the future state of the resource flow in its outputs. The only goal of the ERP system is to account for the resources of the company to plan the maximum throughput of these resources within the company. The more that passes through the company - raw materials (real physical, not descriptions of raw materials!) and finished products (real physical!) - the greater the incoming cash flow (real money, think of it as piles of gold). If decisions about physical changes in the flow of resources are not considered (ordering new batches of raw materials, loading specific equipment, engaging certain warehouses, shipping as per specific contracts), then an ERP program with all its databases might not be needed, and the physical world would remain unchanged.
A photograph/project design/documented description and any other "information object" as a "carrier of information with information" - they always describe some system. An ERP program creates a "photograph" of the company's resource flow as a system embodiment. The system embodiment that interests us - it is not the embodiment of the ERP software itself as an embodiment of a "photograph." Most likely, it is simply the embodiment of a book - they all more or less resemble each other, a couple of hundred glued pages with particles of paint on them. The difference lies solely in the content of the book, so with the software - the embodiments of the software resemble each other; the difference lies solely in the software content, reflecting what the software impacts in the physical world, what it describes! The embodiment of the system in the case of ERP software - most likely, it is not the software itself, but the flow of company resources, a physical object. If the ERP software programmer believes that his task is not to alter in the company's resource flow but mainly the ERP software itself (and in the most severe cases of this error - the program code of the ERP software), the project is in trouble. Check if the software developers understand what changes they are making in the surrounding world through their software - and verify if those changes occur in the world, not just to verify if their software works! Yes, this also applies to you!
If you have no knowledge of the physical object that needs to be altered by your descriptions, you will be unsuccessful, and no amount of systemic thinking will help you. At some elusive moment, your work with descriptions will become entirely fantastical, detached from reality. Descriptions will not correspond to past, current, or future states of the world; they will be fairytale-like, utopian descriptions. In engineering projects, this is unacceptable; resources cannot be wasted on implementing utopias and fantasies!
Systems thinking helps those who know their subject area, and this knowledge extends to the physical world. But those who do not know their subject area and do not connect their thoughts to changes in the physical world will no longer benefit. They will describe strange things, implement random changes in the physical world, or not touch the physical world with their fantasies.
Of course, issuing fantasies instead of engineering work does not mean they will not be paid. Kittens change little in the physical world, but they are always fed and cared for. People (even robots, AI agents) will also always be fed if they do not bite; they will be fed regardless of the results of their work, even if the results dissociate from reality, do not bring about any changes in the world. But sometimes, such utopian works bring harm (if only because resources that could have been spent on something useful are wasted), even if these works themselves are well paid. So avoid detachment from reality!
Detachment from reality is always an issue, whether the work is paid or not. Base your work on changing something in the physical world, as that is the actual application of your thinking skills. Descriptions are useless on their own; they are valuable only in the context of ultimately describing some system in the physical world!