System Realization, Definition and Description

In the systems approach, it is very important to be adequate in our thinking: to

understand whether we are talking about the physical reality of our world, whether
we are tied to it, or just fantasizing about some abstract world of ideas. If we want to
reliably change the physical world according to our designs, if we are talking about
human activity, we need to somehow ensure that all our reasoning is tied to the
physical world, that we are ultimately dealing with physical reality61.
The adequacy of systems thinking is ensured by the fact that when we speak of a
system, we mean a system realization (the same root as real, literally speaking of
existence in reality). The system is always understood as a concrete system
realization in the physical world—an individual, unique physical object. For example,
it is Apple company (all its buildings, facilities and employees at the moment when
they are working there), a fuel pump with serial number #12345 installed on aircraft
engine #5678, a performance of the Irish dance on the stage of the Huston theater
on the evening of October 24, 2020.
How do we know that a particular system realization exists in the physical world?
There are many philosophical criteria for this, and we will choose the most
"scientific" of them all. We will consider that in the physical world there are only
those objects which occupy some place, a volume of some fancy form in our space-
time, accepting Einstein's idea about existence of a physical world in four-
dimensional space-time.
Thus, a particular system has a certain extent in space (i.e., size, length, width,
height, radius) and in time (i.e., there is a moment when it begins to exist and a
moment when it will end to exist). For fields or energy, too, it is possible to define a
place in space-time; the physical subtleties of such an approach are not important for
us yet.
This system also has changing states. Systems change as they interact with the
systems around them, which are also in the physical world, and within them the
subsystems interacting in them change. Everything in the world of systems is
physical, everything is real.
Thus, we clearly distinguish between a system realization occupying the volume in
physical space-time, and a system definition (don’t confuse it with "dictionary
definitions"!)—information about the system realization.
Information has no place in the real world, you cannot say that the number "300"
which determines the height in meters of the system (realization) "Eiffel Tower"
system is somewhere in the real world and has its own length-width-height. If you
point to this number "300" and say that it exists and has its own volume, then you
are not pointing to the number itself, but to the medium which encodes this number
by its form (paint particles or transparency of material or something else). Thus, it is
not "300" as a number is occupying a place, not part of the definition of the Eiffel
Tower (the number 300 describes the Eiffel Tower), but a physical/material object of
a piece of (system) description of the Eiffel Tower, i.e., a medium with
information/definition written on it.
Description is an abstract definition recorded on some physical storage medium.
More detailed relations between the physical object being described, abstract
concepts (what is written about the object by signs), and modifications of media as
signs are studied in the course of ontology/analytical philosophy. In systems thinking
all this is used, but woe betide you if you do not understand this material well and
confuse a car as a System-of-Interest and a photograph as a carrier document
defining this car. A photograph is material, but its materiality is important only as a
possibility to carry on the definition of a physical object-car, the materiality of
carriers of information should not confuse us—it is not the material realization of the
system!
The screen or paper of a photograph, or even the computer memory with the file of
the photograph, are the media, not the "photograph" itself as the information on it!
To tear up a paper photograph (the system description) is not to tear up the person
displayed in the photograph (the system realization), nor even to tear up the image
of the person in that photograph (the definition of the system), for it can persist on
hundreds of other carriers. It is absolutely the same action to turn off a screen with a
photo, or to erase a file with a photo (it is not as symbolic as tearing a paper photo,
but it is essentially the same thing. Abstract objects don't burn, their representation
on media is usually easy to copy, and the destruction of a document, even if
electronic, is not the destruction of the object described by the document, and often
it is not the disappearance of the documented definition available on many copies of
the document). Concept of "1" by and large does not even depend on font and other
display features, it is abstract, it can be expressed in many ways, in many sign styles.
And remember, there are no concepts in the physical world; they are abstract.
Information models (once called blueprints in the last century) are abstract, they are
documented in many copies, and they describe the system realization, that is, the
physical world.
System definitions are easy to distinguish from system realizations and system
documents—they do not occupy a place in the physical world, they have no volume
and coordinates in this world, they are abstract, "ideal", immaterial as the opposite
of the material/physical. Systems and system descriptions (documents about
systems) are material, they occupy space in the physical world.
People are ultimately interested in system realizations, and they are only interested
in definitions and description of the system only because without them the system
realization is difficult to make, especially when we are talking about systems created
by many people.
The distinction of realization, definition, description of the system is needed in order
to prevent common mistakes of people who play the role of developers in system
development projects, among other things:
When people don't even think about creating a system, they just write another
"concept". We need to check whether the concept defines something that exists in
reality, rather than just defining the creation of description and avoiding a definition
of the system realization.
When information developers think their System-of-Interest is
information/description. No, their System-of-Interest is the system realization.
Without the system realization we shouldn’t even get started to work with a
definition of it and a description of that definition. Without the intention of making
the system, we are talking about "artistic definitions", in which there can be any
mistakes.
Developers of program source code (this is also a definition of a system realization)
also think that their responsibilities end when they have turned in the description
(source code with any number of bugs) to the version control system (the medium is
the external memory of the version control computer). No, and no: their System-of-
Interest is a running program (changing its state! Programs’ variables are changing
their state in computer memory! It's a physical process!), not the source code on any
of its media.
Manager, who has developed a plan of action (a definition of the system of works,
existing in the form of the system description in the project management program),
the system realization for him will be a system of works, not this plan itself (and the
System-of-Interest, most likely—the system that is created in the course of these
works).
...and such mistakes of "definition instead of creation" are numerous, and one should
always pay attention to them. In particular, if we are talking about the work of an
analyst, the probability of getting a "definition" as the final result, but not a "change
of the physical world" that does not go out into the physical world, grows. Engineers
change the world, analysts (by definition!) do not change the world and it is
necessary to check whether there is still a "syntheticist" in the project, to seek the
realization from him. If the project ultimately does not change the physical world,
then it can be omitted, because nothing in the world will change!
The result of the work of a nuclear power plant designer is ultimately the realization
of a nuclear power plant, not the paper description of its construction or even the
information model of a nuclear power plant in a dozen computers. The result of the
choreographer's work is ultimately the dance itself (performed at a specific time in a
specific physical place in the universe), not the definition of the dance in the heads of
the dancers, or even a document about the dance as a piece of paper with a
definition of the dance. This is despite the fact that the designer himself does not
build nuclear power plants, but only defines/describes them, and "choreographer" in
its original meaning is also a "describer" of the dance (from the Greek χορεία—round
dance, round dance + γράφω—to record, write. The original meaning of
choreography is not the composition and staging of dances, but the art of recording a
dance).
People do not walk on a map, but on a territory. A map is just a definition of a
territory, which can be represented in different documented descriptions (electronic
or paper or plastic), and this is true for all definitions and description, not just
geographic maps.
A cocktail card is not a cocktail, you don't drink it. The map is in the world of
information, even if it shows pictures of actual cocktails. Information does not occupy
space-time; it is an abstract object, not a concrete one, even if it cannot be imagined
without a medium. A map does not occupy space-time. It cannot be "tapped", it
cannot be "pointed at", just as you cannot tap "the number 300", but you can only
tap "an image of the number 300" on some medium.
If a map is said to occupy space/volume in space-time, then we are not talking about
the map itself as an informational, abstract object, but about the material medium of
the map—paper and ink. The objects drawn on the map don't exist; you can only tap
and point on a piece of paper (or an area of the screen, if it's a screen, or sections of
magnetic memory, if it's magnetic memory), not the objects displayed on the map. A
map-on-the-medium describes some systems realizations (or other definitions that
will eventually still have to somehow logically link into the physical world—otherwise
you can't check their non-fantasy). The cocktail map in this case is not a system, but
only the system description/documentation, and the information on it is the system
definition.
Definitions
But why do we need definitions if we can't use them? We need them for the thinking
that we use to transfer experience from one systems creation project to others.
Thinking does not take place for individual systems, but for sets of systems at once.
Development (conception, design) is always carried out not for specific instances of
systems, but "in general", for a set of similar systems.
A set (a mathematical object, other names for a set are class, type or kind) is an
abstraction. In mathematics, a set of one object is not equivalent to that one object:
the properties of the set are different from the properties of the object itself in that
set.
In systems thinking it is the same: we are interested in individual concrete systems
realizations in our physical world, but we think in classes of systems, in sets of them.
Thinking grasps something common in all situations, thinking does not happen for
specific systems about which we know different facts. Thinking happens for
classes/types/sets/kinds of systems/systems realizations/systems instances. And, of
course, sets are easy to change: to change abstract objects you don't need to spend
energy dragging the substance of system realization, you only need to spend energy
to change the substance for signs realization, which is immeasurably less.
Information technology works with definitions, so these are the first candidates for a
mistake. You can figure out that a picture of a person is not the person in it. It's a
little harder to figure out that the table with temperature of a rocket engine data on
a piece of paper is a definition of the rocket engine, and the piece of paper itself is
not important. But if we are talking about a small database which describes the
behavior of the rocket engine in a series of tests—here comes a perplexity, because
the database itself seems to be some kind of system. No, this database is a definition
of the rocket engine, just in a less familiar form, not on paper. The ability to
reconstruct the described object in physical reality is a key skill for anyone who
encounters modern information technology.
This does not mean that at some point we will not be interested in the software
system as a physical object. It will be, just as a paper book concerns the typographer.
But we are not discussing the plot of the book with the typographer. Likewise, with
the data center administrator, who ensures the physical existence of a computer
program, we do not discuss its "plot". Be interested not in the program itself, be
interested in the system realizations that the program describes, changes that the
authors of the program want to influence. And then you can judge whether the
authors of the program have managed to implement their idea. If it's an online shop
software, then it describes real physical products that are in the store of the shop
and potentially coming to you, coming to you in the physical world. If it doesn't, then
there are questions for the program. The program itself is not needed, it is only
needed to change the physical world using the definitions it contains. Don't be fooled
by the physicality of what's going on in the printing house, the physicality of what's
going on in the data center. Keep your attention on the physicality of what is
described by the media.
For this you have to have an outlook and an applied skill/mastery. If you make an ERP
system (enterprise resource planning), then you must understand: these are all very
different definitions of the flow of resources (resources are raw materials, semi-
finished products of different degrees of processing and assembly, final products,
"stuck" in an enterprise that produces something—all these are physical objects that
occupy space-time). Here the ERP system exists as an information model, a modern
"pen-and-paper" reflecting the state of this resource flow. Its only purpose is to
account for these resources in order to maximize the throughput of these resources
through the enterprise (because the more raw materials pass through the enterprise
and finished products come out, the greater will be the counter cash flow). If you do
not take into account decisions on the physical changes in the flow of resources
(ordering new batches of raw materials, loading this or that equipment, using this or
that warehouses, shipment on certain contracts), then there is no use to create the
ERP program with all its databases, the physical world is not going to change anyway!
Photo/project/definition is always of something, ERP does a "picture" (shot) of the
flow of resources of the enterprise as a system realization. The system realization we
are interested in is not a realization of the ERP system itself as a realization of the
"picture". It is most likely as trivial as a book realization—they are all more or less
similar, a couple of hundred glued pages with particles of paint on them. The only
difference is in the content of the books, so it is with software—the realizations of
software are similar, the only difference is in the content of the software, what the
software reflects in the physical world, what it describes! The system realization in
the case of ERP software is the flow of enterprise resources, a physical object. If you
know nothing about this physical object, you will be unsuccessful, no systems
thinking will help you. A photographer who knows nothing about how to take
pictures in the outside world, but is great at processing pictures—he will not be a
successful photographer. Systems thinking helps those who know their domain to
think. And those who don't know their domain, nothing will help them. They will
describe strange things, make random changes in the physical world, or not touch
the physical world at all with their fantasies. That's not so bad. Kittens don't change
much in the physical world, but they are always fed and groomed. People, if they
don't bite, will always be fed, too, regardless of the outcome of their work.
Look for system realizations, systems thinking is about the physical world, although it
deals with definitions. But definitions are nothing, and what they define is
everything. All definitions are made only to change what is defined in the physical
world!
How to Come to an Agreement: Do Not Generalize, but Specify
If one person mentioned the president of the United States and another mentioned
Joe Biden, did they mean the same person? And if other people mentioned the
president of the United States and George Washington, did they mean the same
person? In engineering, too, you need a rigid logic for such reasoning. Is the P-101
pump described by one person in the piping diagram, and the model PDR-15-NSH-12
pump described by another person in the installation specification—the same pump?
And the PDR-15-HSH-12 pump installed in the turbine hall with serial number
RKS456/4—how does it relate to the first two? How to define this in "the exocortex"
so that you will not confuse yourself and others?
Even Descartes (1596-1650) wondered: how do we even understand what people are
saying about the same object if they see very different properties in it (that is, they
assign it to very different classes)? Say, one engineer talks about a high-performance
system, another about an explosive system, a manager about a profitable one, and a
financier about a cheap one? How do we know we're talking about the same system
here? Descartes' answer to such questions is still used to this day62: if the places in
space (and today we speak not only of space, but also of space-time, considering the
extent in time as a "Cartesian coordinate" as well), of two objects coincide, then they
are one and the same object. It doesn't matter what primary or secondary properties
and entities different people have seen in the object/system, or what applications
they need the object/system for. It doesn't matter if the places in space-time that
different people with different role concerns in a given situation have the same or
different names.
If we are talking about the same space-time place, then we are talking about the
same system realization. If I talk about food, you talk about an apple, she talks about
a commodity, he talks about a green physical body weighing 150 grams, and we all
point to the same place/volume in space-time, then we are talking about the same
object. If someone points in the physical world (in space-time!) to a butterfly with
wings and says "butterfly", and someone else points in the physical world to a time-
varying and space-moving egg-caterpillar-chrysalis-butterfly object and says
"butterfly", then these two have a chance of understanding each other.
It is important that the "move toward understanding" here is toward concreteness (a
system realization, the physical world), not toward "definition" (i.e. attributing what
kind of objects to their kind—"Aristotle's definition"). During negotiations, when you
request a definition of the term or insist on your version of definition, you can lose
your focus on the purpose of the meeting. You can stop any terminological disputes
by providing examples of realizations in the physical world. If we in the handbook of
systems thinking give a glossary and provide a set of definitions, understanding of the
material will worsen: the formality of the statement will rise, and connection with
the physical world will decline.
If we didn't require that all reasoning, all definitions of systems that people make, be
ultimately tied to system realizations, then we would have no way to check whether
people were talking about the same things or different things. Moreover, there
would be huge problems with verifying whether people are talking about the real
world, or expressing good wishes, or just fantasizing, or even deliberately not
wanting to bring their thoughts to reality. The emphasis on the fact that definitions
and description of the system are about the system realization in the physical world
(rather than definitions) allows one to ignore to some extent the differences in the
terminology people use—for in the end one can always check whether people are
referring to the same concept in different terms, or different ones: even if we are
talking about abstract concepts, one can always point to examples from the real
world.
This does not mean abandoning definitions: definitions are needed to transfer
knowledge about some places in the physical world (system realization) to many such
places (classes of systems). definitions of systems support abstract thinking, but
ultimately it is the activity that decides everything: system realizations in the real
world. Definition helps keep attention on important considerations about the
physical world, but no more than that. The physical world is central, systems thinking
keeps attention on it, and systems thinking uses the concern of system realization for
this purpose.
Composition Relation
The main relationships in systems (systems realizations) are part of, or composition.
Engineers often refer to this as system breakdown. In systems, the main thing is
system breakdowns. The levels of this breakdown are the system levels. Breakdowns
are performed by attention, nothing in the physical world is broken on purpose! If
you break a butterfly into wings, body, legs and antennae, it does not mean that you
have torn the wings, legs and antennae from the body: no, you have simply
highlighted in the living butterfly those parts with your attention! Moreover, you also
highlighted out the butterfly itself with attention as part of its environment!
The main move in breakdowns is from the part to the whole. The part is clearly
visible, perfectly distinguishable, but the whole often has to be sought. Systems
thinking is therefore called holistic/whole-oriented.
The wing and fuselage are parts of the airplane, the fuel pump is part of the engine.
The wing (all molecules of the wing) occupies part of the entire volume of the
airplane, i.e. part of the place it occupies in the physical world/space-time, the fuel
pump occupies part of the engine. All the molecules of the fuel pump are part of the
molecules of the engine—molecules are defined as such small places in the physical
world. If we are talking about some nanocoatings with thickness of a couple of
molecules, we can repeat the reasoning going to some quarks—nuances with
quantum indeterminacy are not important here, the principle of reasoning about
parts of the physical world is important.
If we accept that all systems exist not just in physical space, but in space-time, then
all talk about different states of the system or its different roles turns into talk about
parts in time. For example, an egg is simply a part of a butterfly in time: there is no
other "butterfly" that takes the place of an egg in the physical world, while the
butterfly is going through a stage of "egg".
Thus system states or roles (periods of time when the system performs a role) can be
handled as separate objects, they can be given separate names. A butterfly in the
"egg" stage is called an "egg". Mr. Bob Smith in the state of illness is called "patient"
and the "patient" here is simply the role/state of Mr. Bob Smith.
It is convenient to imagine system realizations as "worms" in time, in which their
place in the physical world passes some trajectory in time/"unfolding in time".
In this approach, events are three-dimensional "slices" of the system at some point in
time, a kind of three-dimensional pictures. Before the event there was one state/role
of the system, and after the event there is another state/role. In addition, the system
itself appears at some point in time, and at some point in time it disappears. The
woman-acrobat in the figure is going through different events (getting off the ground,
landing), defined by her poses at those points in time. These poses are like "three-
dimensional photographs" and there are events separating different states
"somersault", "preparation for a somersault", "alignment after landing".
For example, in pose running63, the event is the "running pose"—the runner's entire
body at a certain point in time. The "running pose" is the key to proper running; the
entire running turns out to be based on the event of assuming the proper pose.

Definitions of very complex systems (from microprocessors with their state diagrams
to enterprises with their operating procedures) often rely on an event structure
associated with them. The easiest way to find out something about an unfamiliar
system is to ask what events are associated with it. In enterprise information system
development, this method is called "event storming"64 (similar to "brainstorming").
We can also talk about complex events that take some non-zero time when viewed
"under the magnifying glass". When one speaks of such complex events, one
considers them in the context of such large stretches of time in which the duration of
the most complex event can be neglected. Thus, speaking of tomato ripening, we can
distinguish the tomato itself as a whole, and its three complete parts in time/state—
the green tomato, the reddening event (the transformation of the green tomato into
a red tomato), and the red tomato. In most cases when we talk about a tomato we
can disregard the time of the red tomato event and all the intermediate states: we
are interested in green and red tomato states, objects "green tomato" and "red
tomato", but "intermediate tomato" doesn't interest us, so we consider it just an
event.
Here is a space-time map from Chris Partridge's book "Business Objects: Re-
Engineering for Re-Use"65 which illustrates this:
The event of "World War II" also lasted many years, but when considering the "pre-
war world" and the "post-war world" this event is considered past "instantaneously"
as just a "picture of the world" at the moment when there was a war going on.
In the mentioned book one can read a lot of interesting things about this approach to
describing the world (for those who deal with data modeling in terms of creating
corporate information systems the knowledge of this book is mandatory), in which a
great variety of relations between objects are reduced to the key for systems
thinking part-whole relation in the physical world—state, event, role all turn out to
be just parts of the system. Systems thinking is, first of all, thinking about parts and
the whole, the relation of composition/breakdown/is_part_of.
What is there to be confused about? Surprisingly, natural language provides a wealth
of material for confusion. For example, we might say that roughness is part of the
rich experience of perceiving a table. There are several pitfalls here: roughness is not
a physical object. The rich experience of perception is not a physical object.
Therefore, all the molecules of roughness would not be among the molecules of the
perceptual experience. But the word "part" was used, and it doesn't sound odd to
one’s ear! Here is the source of the confusion: inattentive (untrained in systems
thinking) people don't hold the part-whole relationship in the physical world to
multiple levels. They confuse the part-whole relation with the classification relation.
Tigers are a part of animals. The word "part" here does not mean that all molecules
of tigers as an object are included in all molecules of animals as an object! No, we are
talking about abstract objects/mathematical sets/classes. The emergence of such
"parts" need to be tracked and eliminated, these are errors in systems thinking. Parts
are always physical parts, physical objects singled out by attention from the whole-
environment of those parts. I have a never-failing hand and an endless kindness to
students. You can't say it's the parts! If you can say that all the molecules of my hand
are part of my molecules, you can't say that the molecules of kindness are part of my
molecules. Don't get confused!
A separate source of confusion is to first confuse the system realization and its
definition, and then to speak of the parts of the definition as a part of the system.
Thus, the mustache on my photograph can be recognized as part of me. But it is not:
all the paint molecules that make up the mustache in my picture are not among the
molecules that make up me as a whole! This is a confusion between the mustache
and the description of the mustache, the mustache and the definition of the
mustache! Bridge description is not part of a railroad bridge! Molecules of
description (whether they are information models on servers in a data center, or in
the old fashioned way, a couple of truckloads of dead trees with paint particles) are
not part of the bridge molecules. A bridge and its parts (supports, roadway, etc.) are
one thing, and description for a bridge is not part of the bridge, it's just a description
for the bridge. The description is not part of the bridge, nor does it interact with
other parts of the bridge as a physical object!
Test yourself to see if you can refrain from everyday use of the words "part" and
"whole", limit yourself to the physical world for the relationship, hold the physicality
of the breakdown to several levels up and down from the system that is the focus of
your attention. If you have broken down your definition into three parts, that is not a
system breakdown! It's just that you've broken your definition into three parts of
something. These parts don't interact with each other either; the definitions are
passive and not in the physical world. It's not about the system realization, it's not
about system breakdown, it's about something else.
Holes
The object "hole" in language is defined as something that does not exist, a "hole". In
a bagel, a hole is the place where there is no dough. But in the engineering world, a
hole exists as a separate concrete object in the physical world: it can be made
(drilled), it can be lined with some kind of coating. A well is a hole in the ground; oil
workers often call it a "hole" in slang: it is valuable precisely because there is nothing
in the well, so you can pump oil or gas through it. A "hole" is a hole in a solid wall
through which a pipe can be passed (this hole is often lined with something).
If we remember that a hole occupies a certain volume, a certain place in space-time,
then we can give it a name (engineers do so) and discuss some technological
operations with it—manufacturing, accounting, checking, repairing, "tuning".
Moreover, this is a good criterion for determining whether such a "hole" should be
given a name: if there is any operation with such "hole", then for accounting and
verification of such operation it would be better for a hole to have a special name. A
hole occupies a place in space-time, therefore it is presented in the physical world.
The "working cavity" in the compressor is also "hole", the working space in the
pipeline is also a "hole". It is easy to think about them, imagining this space filled with
gas or liquid molecules, or even vacuum: physical substance is not important here. It
is important, how to think about it, and to think about places in the physical world,
areas/volumes of space-time.
An intermission is a part (in time) of a concert or performance, when there is no
performance. One can reason about the intermission in the same way as about
engineering holes, but it will not be a spatial part, but a part in time of the
performance or concert as a material object, a system realization. "The climax of the
performance" can also be represented as quite a material part: it is the temporal (in
time) part of the performance in which the maximum emotional intensity is achieved.
It is all the objects of the performance (all the molecules of the composition of the
performance of objects—artists, props, spectators) at some point in time.
The same can be done with strange objects that need to be accounted for by name
(because you need to do something with them), but which are difficult to distinguish
as separate from the physical object—for example, welds. A weld has to be designed,
then it has to be made, then it has to be checked regularly. This means that an
instance of a weld must have an individual name, it is a specific physical object that
occupies a place in the physical world. If one understands that a weld is just a place in
space (and time!), then there is no problem in thinking about such an object: it is as
much a part of the system as a pipe proper, or a gear, or a hole. They can have their
parts (although there are no molecules there, but there is a place in space that
molecules could occupy!), they enter as parts into other material objects, they can
have definitions.
Works and Actions
System states change, and considering parts and whole material objects makes it
possible to talk about changes—that is, to discuss
actions/processes/works/procedures/activities simply as sets of interacting
systems/systems realizations/things-in-the-physical-world as parts of a whole
change/process. The process is usually named a verb or a verbal noun (there are a lot
of nuances, but we'll discuss that in the second half of the handbook/course).
"Hammering a nail" in this case can easily be thought of simply as an enumeration of
the physical objects participating/interacting/interchanging their characteristics in
the time period corresponding to this hammering—i.e. "nailing consists of a nail, a
hammer, a board, a carpenter". And the participation relation in
changes/actions/processes/procedures/activities is simply a specialization of the
composition relation (part_of).
It is very difficult to detect the "process of nailing", the processes-as-changes-
themselves are invisible, but it is very easy to detect the mutually changing nail,
hammer, board, and carpenter. It's a little harder to detect them if the role of the
hammer is played by a stone, and the role of the board is played by the wall, and the
role of the carpenter is played by yourself (and so you forget to include yourself in
the process), and only the nail remains a nail. This reduction of "processes" to
material objects, interchangeable in the course of their interaction, remains a reliable
method for looking for works, actions, practices, processes, functions, services, and
other behavior in the physical world. Look in the world for not verb-designated
actions, look for noun-designated objects that somehow behave in interaction, that
manifest their behavior in the world.
In many graphical modeling languages, arrows with rhombuses at the end mean the
composition relation, with the whole where there is a rhombus and the part where
there is no rhombus. The yellow "chevron sideways" is a stylized arrow, meaning that
something changes over time, it represents a "process". And the blue circles mean
the physical objects involved in the process. The blue circles are parts of the process.
Thus, a particular performance (instance, process) of a "dance" begins to exist at
some point in time and ceases to exist at some point in time—processes are not
eternal, just like any physical objects. The dance here is a whole system and includes
for the time of its performance all dancers (people playing the role of a dancer, in the
state "dancer" from the beginning to the end of the dance), a fragment of four-
dimensional floor supporting them (boards playing the role of the floor for the time
of existence of the room), and also a volume of air with vibrations in it, for in these
vibrations is music for the dance. So the engineer who thinks about the dance in this
way can think about the source of air vibrations, and include the MP3 player
(smartphone in a role of the player) and the audio system (the role of the audio
system can play either fixed amplifiers and audio speakers of the club, or portable
speakers) in the dance.
Dance is a process/action/activity, but we can think of it in much the same way as we
can think of a "machine", a "car", a "hole". And we can clarify what "dance" is by
giving examples of its realizations rather than by appealing to terms (which often
leads to long and fruitless "arguments about terms"). It is possible to think about the
most different subjects (including processes!) in more or less the same way, and this
greatly saves thinking.
By the dance thereby, as by any other system realization, it is possible to
conventionally "tapping", it can be "put in a wheelbarrow", it can be conventionally
"pointed at"—it just happens to be the physical things-parts of the dance involved in
it. The conditionality here is that physical objects in systems can be inaccessible, too
small, too hot—it doesn't matter, it's just that we're talking about the physical world,
discussing something embodied, not abstract/ideal/informational. The convention
with processes here is that there are many different parts involved, and it's hard to
imagine how you "bang" them all as they interact. You just have to understand that
all these very different changing physical/material objects are presented in the
physical world, they are neither definitions nor neiser description. Processes are
physical, and systems-processes differ little in their consideration from systems-
things (and the reverse is also true: systems-things differ little in their consideration
from systems-processes, they somehow behave in their interaction with their
environment, or their parts somehow behave in their interaction with each other).
Even the activities of an enterprise can be "tapped on". Although the activity of an
enterprise is much more complicated than a dance, by and large it is not so different
from a dance, where people, equipment, buildings and facilities, raw materials and
semi-finished products interact in the course of this activity. These are the ones you
can tap on. The enterprise exists in our world. Despite its process nature, it is
possible to work with it as a "thing", although it consists of so many other things
involved in its activity.
The systems (including processes, including work) of an enterprise, and including the
organizational processes66 of an enterprise thereby become quite "physical", non-
abstract, spatio-temporally extended, easy to imagine, easy to detect from their
definitions, easy to describe. To begin with, you simply have to list the physical
objects that make up the organizational process, and it will immediately become
clear whether you understand this organizational process in the same way as other
people in the enterprise. But you can't "define", you can't define organizational
processes by defining some classes of operations/procedures for them, this will only
lead to a dispute about the terms. And you can't consider regulations of
organizational processes as processes themselves: regulations only describe the
process! You can't "tap" a regulation (on a screen, or paper, or even computer
memory), but you can tap a regulation-on-the-media, a regulation document, a
process description. And it is to tap on a completely different object than the
organizational process/work defined by the regulations.
We will often cite dance as an example of a system—dance is of a process nature, it is
not as trivial to think about as pumps or cars. But dance is still much simpler than
enterprise, so it's easier to think about dance than enterprise. And it is not without
reason that one of the classic books by Peter Senge (1999) on systems thinking for
enterprises is called "The Dance of Change"67.
Don't Overuse the Systems-as-a-Process
The fact that there is a thought trick of representing some dynamic system-process in
the physical world by enumerating the objects involved, should not lead you to look
everywhere for these processes and make them systems. If a child gets a hammer in
his hands, all the objects in the house turn into nails. If you saw the dance and
activities of an enterprise as systems, that doesn't mean that everything has to be
represented as systems-processes! A banana is a banana, not a ripening banana! A
hammer is a thing, not always "hammering a nail"!
It is very difficult for people to work with processes in their minds, so we need your
attention to avoid drow systems-processes from their environment, instead strive to
work with systems-things, simple material objects, rather than "participation
systems' ' with additional process thinking around them.
Yes, if you work with "dance", it is a normal system realization—it is well supported
by thinking without additional reasoning, it is generally accepted. But if instead of a
loaf-of-bread-product you suddenly begin to define a system realization "eating
bread", then there is something wrong, you clearly overdid it. Bread will be the
system realization, the practice of eating this bread (with or without butter) can be
associated with it. But to make eating itself a System-of-Interest is very suspicious;
you would be uncomfortable thinking of such an object. After all, behavior is
associated with some object, it doesn't make itself the protagonist in thinking. There
are things, they behave somehow. It's not good to imagine everything as behavior
with some interacting things hidden inside of it.
Yes, there is an engineering tradition that simply encourages thinking about
everything-anything-as processes. And objects that are participants in these
processes appear in such thinking only by complicity with these processes. But then
you're going to have tremendous difficulty communicating in such projects with all
the other non-engineering participants, for whom such a tradition is unfamiliar. So
check yourself: do you really need to define "process" or "function" as the system
realization? Isn't it too radical to see "dance" in everything at once?
Computer Programs
A program as a system is a thing, a physical object, it occupies space-time, it is
material. You can "tap" on a running program (a program process in a computer), you
can poke your finger at it! A running program is the physical part of a computer that
performs the computations of that program as it runs.
A program as a physical object has different states (which represent the physical
states of RAM and processor registers) at run-time, and the computer is occupied by
physical processes/changes/interactions of its constituent parts during computation.
These processes in the computer occupy some place in the physical world: the space
in which the interacting parts of the computer are located, and the time during which
the program (that is, the parts of the computer within it) performs the computation:
Once again: a program should be considered a system realization only when it is
actually run and working, doing what it does for the sake of what it was written. This
is rather counterintuitive, but the source code of a program is not a program, but
only a definition of the program; the source code of a program in a version control
system or simply in a file on a storage medium is only the description of the program.
The program is what reflects the state of the program at the moment of its
execution.
So programmers who think that their engineering work is finished at the moment of
writing the source code—these programmers are deeply wrong, and this is a typical
mistake. A whole DevOps68 movement came out of recognition of this mistake—
programmers recognized that they should not only perform the role of program code
developers (Development), but also support the program operation on working
servers (Operations).
Source code is a definition of a program (it is done in classes like any design, one
source code describes many possible instances of a program), and before using it, it
must be manufactured: compiled, assembled, placed in the RAM of the desired
computer (possibly framed in some container beforehand) and transfer control to it.
Thus a program as a system is a process, and we are interested in the process that
runs on the right computer (or computers—for example, client or cloud), at the
moment when the program works and fulfills its function, its purpose. Clearly, it's
usually a long way from the source code to a working program like this.
The mistake programmers make when they think their source code is a program is
exactly the same kind of mistake designers and constructors make when they think
their system is the information models (formerly drawings) and other design and
engineering documentation they develop. A map is not a territory, menus are not
eaten, drawings do not fly, and source code does not store the values of its variables
at run-time69.
Another mistake is to think of a program as a System-of-Interest, not just a definition
of a System-of-Interest. A program is like a book: we are most often not concerned
with the book, or even with the content of the book (the book text itself), but with
what the book text describes. We care about the worlds described in the book, but
not about the beauty of the writing itself (well, except for "real geeks" if we are
talking about fiction, writing for the sake of writing). It is the same with programs: we
care about part of the world described by programm, but not about the program
itself (no more than the book and its text do). If you have a dry-cleaning order
software, then you care about clothes that will go from dirty to clean, about the
money you'll be charged, about options for transporting things to and from the dry-
cleaning. The programmer cares about the program, but that's his own business:
everyone else cares about how the program will handle the actual dry cleaning
situation, and the programmer should care about that too. If the program is
outstanding as a software, but the dry cleaning will not be possible with it, then this
is a failure of the project! Information technology—they are just about definitions,
look for the physical world behind them, the changes that matter!
Another mistake is to include only the software, but not the entire service that does
some meaningful work. In corporate software development, customers expect the
results of this development not so much the correct operation of the computer, but
the correct operation of the part of the organization that this computer must
support: the people in the organization must work together with the software
according to a certain organizational algorithm. Software doesn't work without
people; you have to show the work of software with people. This joint flow of people
and computers is usually called a workflow, although it is often called organizational
process/procedures. The program-in-development is most often only a part of the
target organizational process. And remember, it is hard for people to think about
processes (including organizational processes, workflows). So the program here will
be part of the unit/service/provider that will make the necessary changes in the
physical world. The program itself will be the personal business of the programmer or
a small team of programmers, it is reckless to hold it in the epicenter of attention as a
full-fledged system realization.
The matter is further complicated by the fact that programs as information objects
(information carriers/storage, including all their databases) can be lined up in long
chains, in which on the basis of one definition programs or programs-with-people
change other definitions, then another—and only at the end of such a long chain
does the desired change of the world come. You can describe yourself for a long
time, describe where to get your money, your intentions, write down the
intermediate results of decision-making by all kinds of other programs and people in
your computer and/or phone, but only at the end of a long chain of ordering air
tickets you will be physically let on the plane: hundreds of very different programs,
some of them known to you and some even unknown, are triggered to get that result
in the physical world. If that result doesn't happen, all those programs and people
have worked for nothing. So don't be lazy to untwist all these "definitions of
definitions", all the long chains of programs and programs-with-people until you get
to the changes in the physical world for the sake of which everything is done. And
then make sure the physical world is all right. Yes, it's hard, but systems thinking
forces you to turn your attention in that direction. This is important, the output of
software in the physical world—it matters, if there will be no reliable and expected
changes in the physical world, then the software development project need not to be
done at all, after all in the physical world nothing will change!
In order for the client to get the result of the organizational process, this program
must be configured, some data must be given to it, and employees must be trained
to work with it. And the work of the entire organizational structure/organizational
unit/service/provider as a whole (including the program assigned to this
organizational structure) must be verified, not so much the work of the program
itself. No one cares about the payroll software, but the payroll itself (you can think of
it as dividing some heap of physical gold into parts intended for distribution to
employees)—and if there is no payroll, programmers will have hard time to explain
that everything is fine with their program, and that all the other employees who fill
out the fields of this program incorrectly and press the wrong buttons are in the
wrong. Program development projects often have parts for working with people
(learning how to work with the program: you have to "make" those parts of people
who will be able to do something useful with the program) and data with which the
program will work. Don't skip these parts! They are physical, they need to be
"design" and then "make": people need to be trained (and develop ways to do it, and
ways to test results of training), additional software to set up (and check if everything
is set up).
How do we find the real System-of-Interest that programmers eventually
manufacture? For even a working program turns out to often work with definitions
and documented definitions of some other system than the real system that changes
the physical world!
It is simple: you should not look at the program itself, but at the data of this program
(often they are stored in some database). The data describes some system—most
often it will be the System-of-Interest in the project! This is what the system
realization is which concerns all the people around the development! It doesn't work
100% of the time, but it can be a good starting point for finding a System-of-Interest
when there are a lot of programmers around.
If we are talking about a business trip accounting program, the System-of-Interest is
what is described by its data, and will be changed (created, destroyed) as a result of
the program. This is a business trip. Yes, the business trip is a process/work, but it is
quite clear how to describe and account for it on the computer. To do this, you
simply need to account for all the inputs to the business trip (participation/part-
whole/composition relationship)—people as business travelers, tickets (travel
documents, with different nuances of media relationship for those documents), etc.
If we are talking about a program for a CNC machine tool, the System-of-Interest is
the part described by the data from that program. The program describes the
operation of the machine, and the machine is needed to produce the part. The goal is
the part, the money from it, and everything else is just a chain leading to that goal. So
you have to be careful with programs as System-of-Interest. We will discuss this in
more detail when we discuss the project Systems-of-Interest.
Even in the software world (and the whole world is slowly becoming a software
world) there may be such strange system realization as sessions—training sessions,
or game sessions. For example, a game session consists of a player in the game state,
a game server that remembers the state of the game world, running on the phone
game program, which is controlled by the player on the one hand and the game
server (via the Internet) on the other. All these objects mutually changing states are
the game session. Business people will be happy with this definition of the System-of-
Interest, for they sell these game sessions, and increase sessions’ total time! Note
that none of the other systems mentioned here will not be enough to fully describe
what is happening: neither the player himself while playing, nor the server software,
nor the software in the phone, nor the payment system software (payment is usually
just for game sessions, with slight variations!).
There is often confusion when software is a "marketplace". Not only is the software
of this "marketplace" considered a System-of-Interest, but they also ignore the data
for this software, all the people serving this marketplace, all the customers of this
marketplace, all the possible intermediaries and providers who work with this
marketplace in order to end up with an system realization that someone will agree to
pay for. No one is going to pay for "Marketplace", it's just one of the parts that will
allow you to make money: a marketplace makes something that people need. For
example, a marketplace can make a "delivery": it is some product (thing!) that is in
space right on the doorstep of the place where this very delivery is intended. This
one "delivery" is the System-of-Interest, it is paid for, it is embodied in the physical
world, it is manufactured, and everything else is just a chain of definitions, other
systems leading to that System-of-Interest. "Delivery" will benefit customers, and
everything else will only benefit the sellers-developers, by exchanging software for
money.
Can we assume that all the typical cases of System-of-Interest related to software are
listed here? No! The world is extremely diverse, there are innumerable different
types of System-of-Interest, new business models appear every day, new types of
System-of-Interest appear with these business models. The physical world is
changing in a more and more sophisticated way, and systems thinking allows you not
to get confused in this sea of definitions and pay attention to the main thing: what is
changing in the physical world, what is the system realization, what is the goal of the
whole big (not just your small part) project, what people will agree to pay for.
All this reasoning is easily transferable from the world of algorithms to the world of
data. Forty years ago there were not even personal computers (the first appeared in
1980), and twenty years ago it was still thought that the world would be taken over
by complex algorithms that would cunningly process relatively simple data in
databases. Today it turns out that modern software is shifting toward working with
simple algorithms on complex data. As complexity shifts from algorithms to data, the
systems approach is becoming of interest not only to software engineers but also to
data engineers. We should never forget that data are ultimately definitions of some
systems, but the moment they are processed by some program, they themselves
become part of that program's system, they change their state, they can disappear,
they behave like a "thing". That is, the data for processing by a program must also be
"made" from primary definitions. And when we are interested in how to get useful
results from data, then, as in the case of programs, we must learn how to make them
from raw data—and we, by analogy with DevOps let's talk about DataOps70.
Systems thinking is thereby needed by both programmers and data scientists:
because of the deepening division of labor, these are no longer the same thing,
although they are significantly related. Systems thinking will help software engineers,
data engineers, data center administrative engineers, and managers of all these
multiple roles to negotiate among themselves, as well as with other enterprise
employees and the customers for whom they work. Software systems (while program
operation), data systems (while data operation) are all systems; systems thinking
applies just as much in the world of software as it does in the world of hardware
systems, or organizational systems. It is just necessary not to emphasize too much
the programmer part, all the time remember the subordinate role of software and
the primacy of the physical world—and then everything in the project will be fine.
What about the people who work with the programs? Very often the system
realization that people who are interested in a project will be some part of the
organization that has to do some work—issue a loan, accrue a salary, make a
part/pieca. And if it turns out that the program works correctly, but the people in the
organization can't work with it, then the work of the program won't be counted as
correct either. What good is a payroll program if people can't work with it? If
programmers want to get paid for their part of the work, they need to be sure that
someone is working with people as well, and the customer will receive a joint system
of people and programs (as well as data for this program, which can be a separate
problem and may require separate performers). First, the accrued salary,
manufactured quality part will be counted as a result; then the work of the unit
leading to these essential results will do, and after that within that unit work, the
software results.
Roughly the same reasoning that you do about computer programs can be done for
training people. Books, videos are only definitions of what one would like to get after
training. The purpose of training is a part of the human brain operation that turns on
at the moment it enters the target environment (by analogy to a computer program)
and performs the computation/thinking that the training was intended to do. The
brain is a calculating machine, and the books read and videos watched only give a
definition of what will be required of the brain in terms of the physical process (with
changes of states!) of thinking in it in accordance with the results of training.

The only thing is that we do not need to talk about neurons and their learning, this is
clearly not the level of detail that is discussed in learning. But representing the result
of learning as a part of the brain trained to work under the target conditions makes
us think both about what this learning looks like in the physical world (the brain part
must be located somewhere at the moment of learning!) and about how the work of
the result of learning as a system looks like in the physical world: there must be a
corresponding physical environment. For example, at this moment a person may be
in a machine shop, amidst the terrible rattle of the surrounding machines. Will the
trained part of the brain turn on without an additional reminder? Will it produce,
without error or omission, the thinking that it has been taught in that environment?
How long will it take? What happens before that point, what will happen after that
point? Going to the physical system (the part of the brain that is ready to act/think)
turns out to be productive for the learning situation as well. There are many
definitions in learning, but they are not the main thing. The main thing here is the
resulting physical object with its prescribed properties.
What is the System-of-Interest for the bridge project? The bridge, of course! But to
build a bridge, you have to create an organization that will design it, then create an
organization that will deploy the construction of the bridge, then conduct the work of
that construction organization (several thousand people in an open field!), and only
then get the pleasure of the bridge. It's all a long chain of enabling systems. And if
they are so long in the case of simple physical systems like the bridge, in the case of
software, they can be significantly longer. Imagine, for example, any of the
programming projects, of which there are many as part of building a bridge. Why do
they exist? Why this whole software thing? So that eventually there is a bridge! Here
is systems thinking that requires tracing the entire chain from the software used in
the construction project to the bridge itself. And if it turns out that the software
doesn’t help bridge anyhow, then it will mean that this software does not need to be
written at all.
Systems thinking will check that you are not doing unnecessary work. Systems
thinking makes you think about it all at the beginning, not at the moment of non-
signing of acceptance certificates for a "software creation" project. Usually nobody
needs the software itself, they are only needed as parts of some other system—and
you have to make sure that the development of these other systems as a whole goes
first, and programs are only parts of these systems or parts of the systems that make
these System-of-Interest—you have to deal with all the chains that lead to reality, to
the physical world. Don't confuse the photograph and the object depicted in the
photograph, the book and the living world described in the book, the software and
the real world described and changed by the software.