Examples of system terminology
The story of the target system always begins with its description as a black box, while in fact you have to talk not so much about the target system itself, but about the suprasystem. And this is not accidental: the systemic approach starts with the system being defined by its role in the environment (role/functional object among surrounding systems), by its role behavior/function (changes in the states of systems in the environment conducted by the described system as a "black box").
From the boundary of the target system through the system levels upwards, to the environment, to the suprasystem --- this is the first cognitive move in systems thinking, this is the main imperative. No "division into parts," no "consists of," until you have clarified what the whole is used for, in which we are interested in the parts --- first this whole "is part of" and "is included in" and understanding what this whole does in its "suprasystem"!
Let's give an example of using systemic thinking terminology in describing a simple mechanical system with electrical elements --- a centrifugal pump.
The target system --- a centrifugal pump used in a pumping unit (suprasystem), which in turn is used in a pumping station (i.e. a suprasuprasystem --- a pumping station). Its role is pumping (to deliver water to the upper floors of a building), its action/function is to increase the pressure of the liquid. One of its subsystems is the rotor assembly (rotor with blades, which is a centrifugal pump).
One of the external project roles is the owner-operator of the pumping station. The need is uninterrupted water pressure coming out of the pumping station. The needs of external project roles most often describe suprasystems of various levels. Although they can also describe enabling systems, for example, "the need - for you to manufacture the pump within three days," but even here you can easily trace how "necessary for the suprasystem"---"otherwise our pumping station won't be able to start work on time."
The need for uninterrupted water pressure coming out of the pumping station is reflected in the architectural characteristic of the pump "mean time to failure" and gives cause to think about the emergency power source for the pump motor---but remember, both the emergency power source and the pump motor will also be in the suprasystem for this pump. The pump unit consists of the pump and the motor, shown in the picture is the pump unit, the pump in it is shown in green. The rest---the pump's surroundings, are part of the suprasystem. Here are the details:
- Pumping Station (suprasuprasystem)
- Pump Unit (suprasystem)
- Pump (system)
- Rotor Assembly as a rotor with blades (subsystem)
- Rotor (subsubsystem)
Usage concept: the centrifugal pump delivers pressure of up to 40 meters to the connected pipe, with a flow rate of up to 10,000 liters per hour. Architectural characteristic: mean time to failure of 5000 hours. No preferences in important characteristic values ("as much water flow as possible," "maximum mean time to failure"), as these are already agreed final values, the preferences of different roles are already taken into account. The usage concept and architectural characteristics describe the target system (referring to different times: operation time "in the moment," total operation time), preferences describe the "desires" of individual roles. They are about different objects: the usage concept reflects the system's success ("black box" description, reflecting agreements by role regarding their preferences), and preferences reflect roles. Roles are the creating systems, preferences characterize roles, not the target system. Roles will advance hypotheses about the system's success in their favor. For example, a design engineer demands a higher water flow for the pump "for assured performance with a margin," but then the total cost of ownership will be much higher---and the design engineer and the visionary engineer (responsible for whether it can be sold, or the whole project becomes unprofitable) agreed that up to 10,000 liters per hour will be enough, "the least bad solution."
Some systems in the immediate surroundings: motor, frame (they are part of the pump unit as suprasystems, but they are external to the pump), part of the pumping station, but not the pump unit, include electrical wiring, pipes.
Some creators: design bureau (designing the pump), factory (manufacturer of the pump), pump station designer and builder (they participated in creating: they chose this pump, purchased it, and installed it at the pump station), spanner (used to fasten nuts holding the pump to the foundation). It is unclear whether the pump unit was created by the pump station builders, or the pump was delivered as part of the pump unit (meaning the design bureau and the factory provided the pump unit), this needs to be further investigated.
Another example: electronics with islands of software---smartwatches.
To determine the suprasystem into which the smartwatches are included (during operation), we need to consider the Western Christian tradition of people's relationship with property. Personalities-as-immortal-souls are considered to own their own bodies, which are seen not so much as the person themselves, but as simply the carrier::hardware of their personality::software, an item owned by the personality. The personality::software owns their body::hardware/vehicle, it is their property, they belong to themselves, this is the expression of "free will." A person in the Christian tradition = a person-as-a-soul plus a body. This aspect of people is usually called self-possession. A person's possessions are simply seen as an extension of their biological body. No one can take a person's body or harm it, just as no one can take or harm their personal shirt, personal watch---they are considered as part of the person, literally (relation is_part_of/composition). This is considered "sacred private property." The body = the biological body plus other personal items and even plus the means of production (e.g., a machine-building plant) owned by the person.
By convention, we can thus consider the suprasystem for the smartwatches to be the very person-owner of these watches: the watches would be literally considered part of their body. For many items and tools, this is confirmed by neurophysiological experiments: individuals literally treat them as an extension of their body^[Brandon Keim, "Your computer really is a part of you", https://www.wired.com/2010/03/heidegger-tools). The brain controls the computer mouse as if it were truly an extension of the hand, an "exotele."
Another interesting system of this class, including people, is the household, which may include the owners themselves, the house, and household goods.
In systems of this kind, the people-agents included in them simultaneously play acting project roles and at the same time represent "just a body/organism" with which we work just as with other materials, i.e., considering its physical properties---sizes, humidity, strength, etc. The human as an agent is physical/biological/material, so they consist of muscles, bones, and other tissues. Systemic thinking takes into account both the reasonableness of the human agent in terms of playing a labor role and their materiality as a body.
In the example with smartwatches, the suprasystem is the person-owner of those watches, not as a person::software, but more as a person's body/organism with everything on them: shirt, shoes, watches. The human body in relation to the watches is in the system's environment.
The needs/interests of the person-owner as an external role (the owner of the body-with-the-watches): they must be informed of the exact time, but this list of their interests/needs remains largely open. The role of the watches is quite complex to formulate, as it involves a gadget with diverse behaviors, i.e., a multifunctional gadget.
The usage concept will relate not so much to the "watches" themselves as "timekeepers," but to the various assumed uses of them---these can be actual watches, as well as a radio, a music player, a heart rate monitor, and the smartwatches are expected not to cause discomfort (the skin of the hand as part of the body-in-the-watches environment!), they are expected to be successful if they are trendy at the time of sale, work without recharging for at least 20 hours, weigh no more than 80 grams, have an app store, and connect to an external computer (smartphone, tablet, desktop).
Systems in the environment---the hand, clothing (at least, the sleeve of a shirt or jacket), the charging device. The subsystem---protective screen (e.g., made from Gorilla Glass---procured separately from a contractor specialized in producing custom protective screens).
Creators of the smartwatches: design bureau, factory in China, store selling them in Europe. And if we consider the store as one of the creators in the role of "seller," then we can learn a lot about the smartwatches. The expected behavior of the store ("store with watches inside," what the owner of the store wants from the watches temporarily in their possession, these are stakeholder needs, needs for the target watches)---this translates easily into a hypothesis of convenient watch packaging for warehouse processing (a hypothesis! Perhaps this is not needed, or convenience will be incorrectly determined), colorful packaging and brochures for display in the store, as well as good advertising (i.e., the service of advertising is considered by the store as part of the product---without a certain level of advertising, a good store might simply not take the product for sale). And the watches-as-a-product/packaging-with-watches thus gain additional usage scenarios from the store to attract money from store visitors in exchange for the watches. In fact, here we introduce a new system "watches-as-a-product," packaging with watches, distinct from the watches themselves, and a new role "store visitor" (who can later become a buyer, or not, and the buyer may become a user of the watches later, but may or may not become one). The moment of using the watches::product, that is, the usage type operation "product"---sale, that is, "delivery in exchange for payment," and the moment of using the watches is---looking at the time, setting alarms, taking calls. Do not confuse the use of the product by the store and the use of the watches by their user! This is a mistake often made by "entrepreneurs from an accelerator": they are so enthusiastic about the idea of "selling" that they consider their "product" to be used not as a product but as a commodity! What will happen after the purchase---they don't care, for them the watches could be fundamentally non-functional, just a mock-up, as long as someone pays. This is a mistake: watches::product/system and watches::commodity---these are, in fact, different systems, they have different users, they involve different times (creation time, sale time, watch usage time), different roles of creators, different project team roles.
This is very important---to identify the various external project roles, determine their interests, define needs (harmonize acceptable and desired properties of the suprasystem by external project roles, sometimes even propose these properties---implementers of external project roles often do not know themselves what they want, or do not consider something they desire possible, and the developers of the target system may suggest something to them), and then derive a full usage concept from these needs, describing the behavior of the target system during usage. Sometimes it is even necessary to introduce a new system (in our case watches-as-a-product) and not confuse it with the target system (they have different times of use, different functions in relation to the environment, so important characteristics and structure are different).
The usage concept with numerous usage scenarios of various possibilities/features of the target (or any other) system will describe the system, help in defining its boundaries: what the system will do, and what the system won't do. For instance, these smartwatches will show the time, and these smartwatches will show the time and blood pressure (and from there, you can start thinking in the system concept of how to arrange everything so that there is an acceptable price for sale). In the case of watches-as-a-product, it is clear that the packaging, advertising brochures, and even advertised commercial entered data are part of the target system. But you can also include some additional application software with the watches. One can consider the app store for these watches to be a system creating some features/capabilities of the watches, but considering the packaging this way won't work.
This example shows that it is convenient to describe the (existing or planned) target system differently for different roles, and sometimes to even introduce additional systems into consideration. For the store, this very packaging-with-watches/advertising/watches-as-a-product will be the target: it needs to be envisioned (merchandising!), manufactured (procurement! Logistics!), and used (sold!). And what about the watches? Oh, they are not needed. What's needed is packaging-with-watches/product-with-watches!
Modern engineering often deals with cyber-physical systems that include sensors, actuators (usually various motors, but they can also be lighting devices, electric switches), and a computer (cyber-, control part) managing the entire system. An example of such a system could be a drone for aerial photography.
Suprasystem---construction site (unfinished building during its construction plus a set of creation systems deployed around the building, "building creation event"). One of the external roles in the project is the client-developer, whose need is control over the progress of construction. The drone photographer (determined by their role)---is the target system. The function/behavior of the drone---providing a stream of high-resolution photos of the building at interesting angles for the client-developer. Fragments of the usage concept: flight and photography duration of not less than 1 hour, the image of the construction site is captured with an optical resolution of not less than 20 MP, recharging between flights takes no more than 1 hour, the drone approaches the charging station on its own. Subsystem---camera, drone's subsystems (camera subsystems as drone subsystems)--- the lens and camera sensor. Systems in the operational environment: charging station, the construction site with its buildings, structures, and equipment (cranes), they may be considered as obstacles in the air (e.g., ropes suspended from a crane).
Creators of the drone-photographer---design bureau, manufacturing factory, store, repair workshop, and operational service with drone-photographer operator (this service upgrades the drone before and after each flight: checks, refuels, adjusts, cleans, repairs. Therefore, we consider this service not in the environmental systems but in the creation systems---it operates not during the usage/"bringing benefit"/operation/functioning of the drone).
Precisely the same narrative would be for less classical systems than traditional for engineering electro-mechanical ones (pump) and cyber-physical systems (drone, smartwatches) systems.
For instance, **mastery. Engineering of mastery is the subject of a separate course "Engineering of Personality" (personality---is the combination of the agent's mastery). In fact, this is a course on "mastery of creating mastery," for systemic thinking such creation chains are typical.
Let's take, for example, the mastery of systemic thinking---it is a target system that, during its operation, conducts thinking::calculation with systemic approach concepts, implemented this system is by certain components of the brain or a computer with an AI program, playing the role of this mastery (but we don't even know very precisely which brain parts or computer parts). Subsystems of the mastery of systemic thinking: thinking mastery about system levels, thinking mastery about creation chains. The suprasystem of the mastery of systemic thinking: intellect, as the general thinking mastery over all fundamental methods of the intellect stack (again, we understand that it is also implemented by some parts of the brain and/or computer of the agent, but we are not quite clear about which ones---this does not prevent us from reasoning about this mastery as a material object.
Moreover, this can be in the case of team systemic thinking, several brains and computers, and means of communication between them). Systems in the close environment of the mastery of systemic thinking: ontological thinking mastery, coherence mastery. The creator of the mastery---systemic thinking course (an online course as a program on data center servers and optionally course instructors---they can be there, but they may not be). The creators of the creator of the mastery, i.e. the creators of the systemic thinking course---the author of the textbook and model templates (Anatoliy Levenchuk), the dean's office (managers, programmers, operators) from the School of Systems Management with their LXP (learning experience platform) Aisystant.]