System-of-interest in software development projects
How can one find the target system out of all possible systems, the system that programmers ultimately create, the system whose creation will be considered a project success ("everyone is satisfied, no one is offended")? Even a working program often turns out to be working with descriptions and documentation of a different system than the real system that changes the physical world — one must stretch the thought further down the chain until finding the system that actually changes something in the physical world, not just in descriptions!
To begin with, one simply needs to go through the list of errors from the previous section. Although there may be many more errors, this short list usually significantly advances understanding. For instance, assuming that your program is a digital twin, then you need to find a physical twin, and the system will consist of digital and physical twins, thus changing and adjusting the project: handing over the program will not be an unconvincing demonstration of the program working alone (but developers just want a demonstration of the program working rather than anything beyond that: "paper will bear everything," a detached software free to fantasize its results, it is very easy to show the success of fantasies), but by demonstrating the proper functioning of the physical twin under the management of the digital twin — this is much more difficult, but this will be the real success of the project, and payment will be made for this. On the other hand, when it comes to a rocket or a bridge, or even a patient in a hospital, the physical twin is obvious. But how do you find it when it comes to a web of objects and their relationships in a company? What can be a physical twin there?
The very first intellectual move that will help you find the physical twin — is to look not at the algorithm (described by the source code) but at the data of this program (often found in some database). This data describes some system (including processes of this system, that is, changes in the states of the system) — more often than not, this system will be the physical twin. It is precisely this system described by the data of your program that will be the embodiment of the system that all the people involved in the development will be concerned about! This intellectual move does not work in 100% of cases, but it can be a good starting point in the search for the target or "our" system, especially when there are many programmers around. In a weaker version, this same move is good for information objects (reports, models, databases, etc.): what do these objects describe, what system? It is the system of interest, while the information object is only of interest mainly to the development team, others care only because of their involvement in the system described by that object.
If we are talking about a business trip accounting program, then the target system is what is described by its data, and as a result of the program's operation, it will change (be created, destroyed). This is a business trip. Yes, a business trip is like "traveling and staying for the trip participant," but it is made up of different objects that make up the higher system in which this trip takes place (like a "dance performance" made up of a dancer dancing) and it immediately becomes clear how to describe it and account for it on a computer. For this, you just need to take into account all the components of the business trip (relationship of participation/part-whole/composition) — people in the role of travelers, tickets as descriptions of trips ("travel documents," with various nuances of the relationship to paper and electronic media for these documents), often hotels are also included here, as well as their descriptions — payment documents for accommodation, luggage with its payment and documented descriptions ("baggage receipts"), etc.
And here one must not make a mistake because "business trip" is called by different agents different processes::behaviors or events::system (and you need to determine this further — do you consider it processes, or systems?):
- The sender on a business trip (conditionally: "supervisor") refers to work that needs to be done somewhere in another city as a "business trip." Part of this work — initially the agent needs to get to that city, but that does not matter much.
- The "business traveler" agent considers a "business trip" not so much the result of work (it is simply the "result of work"), but rather the "trip": flight by plane, bus ride, hotel stay, meals.
- The "accountant" as an agent considers a "business trip" not so much the entire "trip," but rather the "financial part of the trip": not just any travel, but only that which will need to be compensated. For example, the travel to the city will be paid for, but the rides within the city will not be, and the "business traveler" considers all of this "business trip."
Since different agents perceive a business trip as different processes or systems — you simply need to give them different names (for example, "remote work," "business trip," "financial part of the business trip"), and teach different agents to use these names to avoid confusion in the conversation. And then ask yourself: the software that helps "arrange business trips" — does it help create which of these three systems?! Of course, these will be completely different software applications, or parts of one software, working as digital twins (or shadows, or models) for different target systems: some help the supervisor with "remote work," others help the business traveler with the "business trip," and the third — help the accountant with the "financial part of the business trip." There is a suspicion that for all so-called administrative processes, there are no less than three such considerations, that's why it is difficult to develop software for enterprise administration: everyone gets confused due to the failure to distinguish different systems under the same names! If you identify different objects (pairs: systems and their behaviors) in the physical world (4D extensionalism) and give them different names along the way — confusion stops, and all project participants quickly come to an agreement among themselves.
If we are talking about a program for a CNC machine, then the target system is the detail described by the data of this program. The program describes the operation of the machine, and the machine is needed to obtain the detail. The goal — the detail, the money from it, and everything else is just a chain leading to this goal. If the program works well but the detail comes out poorly — there will be no money. So, with programs (including craftsmanship like "program for people and AI agents" and even personality as the combination of all kinds of expertise of one agent), caution must be exercised when considering programs as target systems. We will discuss this in more detail in our course when discussing project target systems.
In the world of software (and the whole world is slowly becoming a world of software, especially considering the neural network software of modern AI systems and the software in people's heads: personality is software on the organism's hardware), there can be such strange incarnations of a system as sessions — study sessions, or game sessions. For example, a game session consists of the player in the game state, the game server that remembers the state of the game world, the game program running on the player's phone, which is controlled by the player on the one hand and the game server (via the internet) on the other. All of these objects, mutually changing states, make up the game session. All the employees of a gaming company will be happy with this definition of the target system because gaming companies sell these game sessions, increasing their total time! Note that none of the other systems mentioned here will be sufficient for a complete description of what is happening in a company that trades computer games on its servers: neither the player in the game state, nor the server software, nor the software on the phone, nor the payment system software. Payments are usually made precisely for game sessions, with minor variations, and unless you describe the working object "for which they pay" — discussions with the business people of the company will not stick together!
Confusion often arises when software represents a "marketplace." Not only is the software of this "marketplace" considered the target system, but it also disregards the data for this software, all the people serving this marketplace, the clients of this marketplace, all possible intermediaries and providers who work with this marketplace to eventually obtain such an embodiment of the system for which someone will agree to pay. No one will pay for the "marketplace," it is just one of the parts that will allow earning: the marketplace manufactures what is needed by the people around it, and the target system will be what is needed by these people, and whether it is manufactured by hand or by a marketplace — it doesn't matter.
For example, a marketplace can manufacture "delivery." "Delivery" is not about the process of delivery but a certain product (a thing!) located on the threshold of the place where this very delivery is intended. This "delivery"::system at the moment of its use, that is, "the customer takes the purchased product in hand"::"usage process" (emphasis: not the delivery::process, but the final state of the physical world: delivery::system as "goods handed over"::state and the processes of transporting the goods to the owner and handing over the goods into possession) is the target system, for which payment is made, it is embodied in the physical world, it is manufactured, while everything else — it's just chains of descriptions in a "marketplace" and other systems creating this target. "Delivery" will bring irreplaceable benefits to customers, and everything else will bring irreplaceable benefits only to various developers — they will receive money from customers for the delivery received on time. Note that we did not write here "delivered on time," as it implies "delivery::work::behavior," "done" usually refers to work. However, there is also the expression "done" with systems, for example, "the artist completed the painting for the holidays" means that he completed all the work to create the painting for the holidays. So, "delivered on time" could also be understood as "completed all the work to create the delivery on time." You can speak in very different ways, if you follow the types. If you do not follow the types — you will confuse both yourself and others.
Usually, when discovering the target system, some interesting assumptions are made within 30-40 minutes of discussion. However, after a week or two, these assumptions need to be clarified, and it is usually not possible to quickly determine the target system. For example, marketplaces as providers of a service for manufacturing "delivery" from "goods" for some reason do not work out if only "delivery" is considered the target system created by the marketplace, because transportation goes in both directions: it is a "supply against payment" (the deal ends when there has been both a financial transaction and a delivery of the goods). The marketplace is needed only when it guarantees financial arrangements for both the supplier and the buyer for this very "supply against payment." Without this guarantee, "simply Google" does an excellent job of mutual search for buyers and sellers, and there is no significant competitive advantage over "simply Google," which is why the "marketplace" remains a utopian idea. So, it is essential to be very attentive to what constitutes the target system in the project: the success of the project is directly related to the choice of the target system.
Can it be considered that all typical cases of target systems related to software are listed here? No! The world is extremely diverse, and there are countless different types of target systems, new business models emerge every day, with these business models come new types of target systems. The physical world is changing more and more sophisticatedly, and systems thinking allows not to get lost in this sea of descriptions and to pay attention to the main thing: what changes in the physical world, what is the embodiment of the system, what is the goal of the entire large (not just your small part) project, for what people will be willing to pay.
All these considerations can easily be transferred from the world of algorithms to the world of data. Just forty years ago, there were not even personal computers (the first one appeared in 1980), and twenty years ago, it was still believed that sophisticated algorithms that cleverly process relatively simple data in databases will take over the world. Today, it turns out that modern software is moving towards working with simple algorithms on complex data. Even in AI algorithms, this principle has worked: the simplest neural network algorithms on complex data they manage to achieve tremendous success, provided that there is a lot of computational power to execute these simple algorithms (a bitter lesson from Sutton[1]).
As complexity in algorithms shifts to data, systems thinking is becoming of interest not only to engineer-programmers but also to data engineers. One must never forget that data is ultimately descriptions of some systems. Even in large language models, their data is a description/representation/presentation of our material world as a system, only in a compressed model form — the result of the process of knowledge/learning. But at the moment of processing them with a program, they themselves become part of the system of that program, changing their state, disappearing, behaving like a "thing." That is, the data for processing by a program also needs to be "manufactured" from initial descriptions. And when we are interested in how to get a useful result from the data, just as in the case of programs, we must learn to manufacture them from the source data — and akin to DevOps, we will talk about DataOps by analogy.
Systems thinking is therefore necessary for programmer-engineers, data engineers, data-center administrators, managers of all these numerous roles to come to an agreement among themselves and help find and train all those employees dealing with this software and data of those people affected by this software and data. Software systems (during program operation), data systems (during data use), personalities, and craftsmanship within them — all these are systems, in the world of software, systems thinking is applicable no less than in the world of hardware systems, or living systems, or organizational systems. There is a need to not highlight specifically the programming part (software engineering and data engineering), always remembering the subordinate role of software and the primacy of the physical world which is described and changed by software, both in computers and in the heads, also by the data of this software — and when everything in the project of creating information systems then will be in order.