Role as Part of a System or Activity
As you already know, the concept of “role” is not limited to people. The executor/performer of a role can be not only a person, but even a “stone.” Now, let’s go further and say that roles do not belong to a person, as is commonly assumed. In systems thinking, a role is considered as part of a system or an activity.
A role refers to a functional object. The concept of “functional object” relates to the consideration of a “system”: when we say[1] that a certain system interests us as a functional object, it means we are interested not in its physical embodiment, but specifically in the role-based (or functional) behavior of the system.
For example, earlier we discussed the role of a hammer, and therefore considered separately the physical object and the system, both called by the same word—“hammer.” And if we need the role of a “hammer,” it means there is some supersystem or process in which the function of driving nails is required.
Of course, we can consider a physical object (even a person) and say that it can play certain roles. For example, a stone can play the role of a hammer or a paperweight, and a person can play the role of a manager or a driver. However, we do not say that the role of a hammer or paperweight is inside or is a part of the stone. In the same way, we do not say that the role of manager, driver, or father is inside a person.
Whenever we talk about a role, at the next step we must consider as part of what this role should be further examined, and which method it implements in order to produce a specific work artifact. And if we are talking about a system (not a project), we can speak of a role-based or functional breakdown. For example, a driver is part of the “driver+vehicle” system.
We can discuss a system from different perspectives, and one such perspective is the functional or role-based one. In this view, we focus on the system as a functional object—that is, as performing a certain role. This is the primary way of considering a system as a “black box.” Such an approach means we are interested not in the system’s structure, but in its role-based behavior.
A system as a “black box” presents its role-based (functional) behavior outwardly, while a system as a “transparent box” draws our attention to how it is organized internally. You will become familiar with the “transparent box” perspective in Section 6, “Systems Modeling.”
When we operate with word-concepts, we direct our attention. Each concept “highlights” something specific. We cannot consider the world in its entirety, and even a system is difficult to fully examine, as we lack the computational capacity. But we can focus on something specific within the whole system. For example, the subject of interest might be cost. At the same time, the very concept of “subject of interest” is connected to the entire system, and by discussing one aspect, we do not lose connection with the whole. ↩︎