Subject of Interest, Role Interest, or Preference
Let’s take a closer look at the concepts of “subject of interest” and “role interest” (preference). It’s important to remember that when we talk about a project role (where the executor is an agent), we automatically imply that this role has a specific subject of interest in the system—that is, there is something in the system that concerns it. Ultimately, systems thinking is less about the roles themselves and more about the system characteristics that roles require. Through roles and their methods, we can reach the characteristics of the system. You could say that a role is concerned with certain subjects of interest in the system that are important to it.
A subject of interest is a significant characteristic of a system, and it’s important to use this mental technique to distinguish between “the system” and “subjects of interest” during discussion. For example, a car as a system can be characterized by its cost, speed, color, design, and many other features[1]. The buyer is interested in the cost of the car, so we can say that their subject of interest is the price (or cost). Note that the subject of interest in the system belongs to the role, not to the agent (the executor of the role). John Doe or Andrew Smith, when acting as the buyer[2] have the same subject of interest in the price of the car.
At the same time, subjects of interest should not be confused with system functions. The functions of different systems may be unique, while subjects of interest are often common to many systems. For example, a chair and a table have different functions, but the subjects of interest in these systems may be called the same: cost, size, stability, reliability, and so on.
It’s also important to note that identifying and implementing key system characteristics is itself a separate subject of interest for the architect role. In other words, the work of a system architect specifically requires system characteristics. For example, an architect is interested in subjects of interest such as: reliability, security, stability, scalability, availability, continuity, performance, configurability, extensibility, reusability, localization, maintainability, portability, upgradability, and so on.
The architect works with these subjects of interest (identifying the most important ones), which are called architectural characteristics, and as a result, develops a structural solution[3] or a proposal for dividing the system into specific modules[4]. An architectural solution helps to divide the system into modules. You are not required to know architectural methods or to work as an architect, but you should understand the essence of architectural work from a systems thinking perspective: what the architect does and what their work artifact is. Similarly, you may not know how to do plumbing in your apartment, but you are well aware of what a plumber does, and you can even assign them a task and evaluate their work.
Many different roles may have the same subject of interest. However, the role interest for each of these roles may differ. That’s why another concept is introduced—preference[5]. This indicates what a particular role wants in relation to the subject of interest. Cost is of interest not only to the buyer but also to the seller, but their preferences or role interests are different. The subject of interest is the same, but the buyer prefers a lower price, while the seller prefers a higher one. Thus, the preferences (or role interests) of the roles differ, even though the subject of interest is the same.
When you identify a project role, you are simultaneously implying that there are certain subjects of interest. The names of project roles in culture are tied to subjects of interest in the system. The subject of interest for a manager in the “enterprise” system is deadlines, finances, budget, and so on. That is, the manager is not interested in the entire enterprise, but only in certain characteristics. Other roles are interested in other characteristics of the system[6]. You can also think of an interest as a variable, and a preference as its specific value.
Knowing the subjects of interest, like knowing the names of project roles, is part of general awareness. Most people have good practical awareness in the field of medicine. Some have much better awareness in medicine than in entrepreneurship, engineering, or management. You know that there are many different types of doctors, and you can even guess their subjects of interest. For example, you can distinguish a general practitioner from a pediatrician, and you understand what concerns an ENT specialist or a dentist. However, you are unlikely to be able to name even three roles in the “engineers” or “managers” category unless you have specifically studied this. That’s why, after studying systems thinking, it is essential to also study systems management and systems engineering[7].
A successful constructor needs to understand the roles and interests of project activities in general much better than in any particular field. Our educational program is specifically aimed at developing this general awareness.
The international standard ISO 42010 provides an approximate list of subjects of interest: functionality, attainability, usage, system purpose, system capabilities, system properties, known limitations, structure, behavior, effectiveness/performance, resource usage, reliability, protection, integrity and information security, complexity, ability to evolve, openness, parallelism in execution, autonomy, cost, schedule, quality of service, flexibility in use, flexibility in development, modifiability, modularity, management, inter-process communications, deadlocks, state changes, subsystem integration, data availability, privacy, legal compliance, rationale, organizational goals and strategies, user experience, maintainability, price acceptability, and ease of decommissioning and disposal. As you can see, this list is not exhaustive; different systems may have other characteristics (subjects of interest). ↩︎
Role executors may differ, but this mental technique allows us, at least briefly, to highlight what they have in common—namely, that they are interested in the price of the car. ↩︎
The system’s design as a “transparent box.” ↩︎
For more on this, see the course “Systems Engineering.” ↩︎
For example, by making decisions about the modularity of the system, the architect offers different ways to account for these preferences: the more/less of a certain subject of interest, the better. This becomes a matter of negotiation and compromise in the process of addressing the interests of project roles. Preference is often used as a synonym for “role interest.” ↩︎
A practice manager is interested in the methods and practices used in the enterprise. For example, this role will be interested in which IT program is used in the automotive design bureau: does it allow drawing models in 2D or 3D? ↩︎
These are broad transdisciplinary fields that will be useful to any specialist who wants to have a strong intellect. ↩︎