Physical and Functional Objects
Let's clarify the difference between a role and a project role.
A project role is always performed by a person or an agent, not by an inanimate object like a stone, which has no intention. The concept of "role" can be used not only in relation to an agent. After all, a role is a functional object, and its executor/performer is some kind of physical object. This object can be either an agent or a non-agent without intention.
Let's look at the example of a taxi. In a taxi, the role of the driver can be performed by a person, or by a robot with artificial intelligence (this is a subtle point, and soon we may be talking about the intentions of AI). In the first case, we refer to a project role to emphasize the involvement of a human. But if we say, "there is a driver role in a taxi," we allow for the possibility that the executor/performer of this role could be either a person or an inanimate object.
It's important to clearly understand the distinction between:
- physical object: this could be a person, AI, or another inanimate item. Note that when we talk about a physical object, we are indicating that there is something that exists in the physical world. We know nothing about what role this physical object might perform[1]. The main thing we know when we call it a physical object is that it exists in 4D (three-dimensional space and time).
- functional object: this is the role. In the example above, it's the driver role. When we talk about a functional object, we are focusing on the fact that there is not just a physical object, but a role. That is, not just a person, but a driver with a certain level of mastery. In this context, what matters to us is the behavior of this functional object, not which physical object will play this role[2];
- role-based or functional behavior. We say that a functional object has a certain role-based or functional behavior, meaning the system is viewed as a "black box"[3]. For example, for the driver role, this behavior is called driving the vehicle.
This division into physical object, functional object (role), and role-based behavior is an important technique in systems thinking.
For example, first we recognize that we need the function of hammering nails. The function is the behavior. This function is assigned to the role of "nail hammerer," and only then is an executor/performer assigned to that role. This does not necessarily have to be a physical hammer[4], the one lying in my garage. The required "nail hammerer" role could be played by a microscope in a laboratory or a stone I see outside my window[5].
This is also how engineers design systems. First, they determine which functions are needed, and based on this function-behavior, they name the system, giving it a functional name or role. Only after that do they determine the modules or physical objects that are best suited for these functional roles.
The role-based approach is the same for an agent and for a "hardware" inanimate system, if we are considering them as executors/performers of certain roles. In this case, the agent's behavior is called role-based behavior, while the behavior of a "hardware" system is called a system function. Although it is also acceptable to talk about the role-based behavior of a vehicle, and that would not be a mistake.
However, there are deeper differences. For example, to get a person to take on the required role, you need to persuade them in some way, whereas you don't need to persuade a microscope to play the role of a hammer[6]. That's why, in systems involving people, leadership practice comes to the forefront. Its essence is to ensure that a person steps into the required role at the right time and performs it well, efficiently, and with satisfaction. A leader knows how to put a person into a role. The method of systems leadership is about helping another person step into a specific role. Assigning "hardware" systems to a role is done using standard engineering methods and based on physical theories.
For example, a person in the role of manager might, during an operational meeting, reprimand an employee for failing to complete a task, and this is all within the scope of management practice. However, the same person in the role of leader might have a heart-to-heart conversation with the employee in the evening to find out what caused the problems.
Another difference is that a "hardware" system does not have a role interest; only a project role does. To create a successful system, you first identify the interested project roles, and then their role interests. Human behavior is determined by the concept of "intention," while a role has a "preference."
There is simply a stone. This is a typical physical object. Its function is not at all clear. But if someone wants to do something, they need a specific function. For example, they need to hammer a nail or hold down papers on a desk so they don't scatter. In that case, we are no longer talking about a stone, but about functional objects—a hammer or a paperweight. The fact that it is a stone becomes less important. ↩︎
Combining the physical object with the functional one will be necessary when creating the system, but we must be able to focus our attention on these two entities separately. And be able to discuss them separately. ↩︎
Here, we are not concerned with the internal structure. The structure of the system (as a transparent box) will be discussed in more detail in Section 6, "Systems Modeling." ↩︎
Remember that in culture, instead of "nail hammerer," people say "hammer." In fact, the term "hammer" has become culturally established, just as the term "driver" is widely used. In culture, functional objects are constantly given certain terms. You don't need to say "vehicle operator," you can just say "driver." Likewise, you don't need to say "nail hammerer," you can just say "hammer." So, a hammer is a functional object, and a physical object could be a stone, a microscope, or a hammer. But here, "hammer" is meant as a specific tool, as a physical object. ↩︎
Here, it is specifically emphasized that we are talking about particular objects—a microscope and a stone, not some abstract instances. ↩︎
More precisely, all "persuasion" is prescribed in formal engineering methods. And if the calculations are correct, it is impossible for a hardware system to avoid performing its assigned role. ↩︎