Concerns and interests ​

In systems thinking, the reasoning usually follows the system mantra, which has many different wordings, but it all comes down to considering a working system in its environment first (usage concept), then what to make it from (system concept), and how to make this system with what methods (engineering methods), then who could execute these methods (creators-engineers), then who could create these creators (creator-organizers of engineers), and so on in the creation graph. In any case, at some point in defining the important objects of attention in the project, the participants::roles are guided by a culturally conditioned understanding of which objects are most likely to change their state during the project, based on knowledge of how a typical engineering method of creating different types of systems is structured. Essentially, all our courses tell exactly how in a project the systems thinker enters not at all with zero knowledge of what is happening in the project (which he hasn't really seen yet) and what could be happening there at all.

For example, it is assumed that at each step of increasing the functionality of the developed system (continuous development implies not a one-time creation of the system, but creating and developing the system with gradual enhancement of its functionality), the possibility of creating the next increment of the system will be realized, described in the usage concept, then the system concept will be adjusted, then the system concept will be detailed in the project/design with sufficient accuracy to produce the increment, then the parts of the new increment will be manufactured, the system will be assembled and debugged "in physics", verified, put into operation with the new increment, if problems are found, it will be removed from operation with a transition to the previous version, decommissioned (operator work, monitoring), and so on - for each type of system, there will be something similar, although the terminology may vary significantly (for example, the term "mastery production" will not be used, it will be discussed about "mastery training").

In any case, the project expects a set of objects that will change their states during the project. This change of states is carried out by some working methods. For example, the system concept is developed with the involvement of developers (their subject of interest - functional decomposition and set of constructs as affordances for subsystems as functional objects) and architects (their interest is that the system is built from constructs with optimal autonomy, since it affects numerous architectural characteristics - and this often contradicts the proposals of some groups of developers). Developers' typical interest is fast introduction of new functionality now ("quick and dirty solution"), architects' interest is quick introduction of new functionality in the future (minimizing technical/architectural debt). This is discussed in more detail in the course "Systems Engineering", but now it is important that there are working methods for development and for architectural decision-making, which in some way consistently move through the states of the object "system concept", and this movement occurs throughout the project, considering the continuous development of the system and the release of new versions of the system with new and new increments implementing new functionality.

The movement through the states of some objects that change during the project, as well as ways of modeling this movement, will be considered in the methodology course. What objects and how they move through states will be discussed in engineering courses (systems engineering, personality engineering, systems management). In these engineering courses, the roles performed by engineering (managerial, educational, promotional, etc.) working methods will be considered. Each of these working methods requires an agent performing the corresponding role to pursue some interests.