Areas of interest of the supra system, system-of-interest, creator ​

Areas of concerns/subjects of interest are proposed in the OMG Essence language standard for grouping attention objects in a project by major characteristics related to certain systems. They are so generalized that it was suggested to call them not concerns, but areas of interests. In the main/kernel objects, these were areas of interest in attention objects related to the customer, software system, and project endeavors. We keep the language of the standard, retain the concept of "areas of interests," but reject the proposed narrow understanding of these areas, changing the kernel.

An important characteristic/subject of interest is the theme of a role's concern, formalized by some description/viewpoint method, it is not "what the role wants to achieve." "What is wanted" - this will not be the characteristic itself, but the role's preferences for this characteristic, the interest in the subject of interest - roles can influence target characteristics in different directions, for this they use suitable description methods. And roles negotiate with each other regarding the implementation of their preferences in these important characteristics.

If all such characteristics/subjects of interest are generalized around certain important systems in the project (alphas), then three most important corresponding to the three types of systems would result (but you can confidently adapt the main areas of interest to your project, add additional areas of interest). In the section "Chains of creation" of the section "2. Not life cycle, including development," we have already given an example of such a representation: enterprise alphas broken down by main areas of interest of the supra-system, system of interest, and various creators in chains of creation. We also noted that all connections between alphas somehow lead to the target system. Let's repeat the diagram with creation chains ^[1]:

If it is a system-creator, then for each alpha, its sub-alphas of typical roles (applied engineering or managerial ones - explained in detail in the "Systems Engineering" and "System Management" courses) are given. If it is a group of agents/organizational units playing certain roles (e.g. clientele or simply "external project roles"), then sub-alphas are shown to track the states of individual agents. For example, in response to a question about the status of the clientele, you could say, "Clients 3, 5, 8 are in the process of renewing contracts, client 64 rejected our services yesterday, and we are doing additional work with him, clients 39, 40, and 35 are expected to pay, the rest are being serviced." At the same time, you have an alpha "clientele," because if it's not there, what are you developing? You are developing exactly the clientele, increasing the overall number of clients, increasing loyalty, calculating unit economics metrics^[2].

And now let's show a group of three alphas at each link in the creation graph on the diagram, add some additional details, just to assess the topology of the creation graph when we start to unfold it for tracking not only the systems themselves but also their descriptions and work ^[3]:

Each creation system in its area of interest has work performed in its completed state and its description (including its system description, but also the description of its operational methods, and work plans), and each listed alpha also includes sub-alphas that also need to be tracked in the project.

The diagram has grown to the point where it is practically unreadable. Immediately too small, too much information, too much time to adapt to your project's conditions - so we recall the material in the section "Project System Scheme Diagram," where it describes how to make lists and tables from all of this to work with. When we start considering the sub-alphas of all these alphas and further the states of all these alphas and sub-alphas, the graphic form will be completely unsuitable for work. So we engage in tabular modeling in universal modelers, detailed modeling is discussed in systems engineering and management courses.

In this creation chain diagram, it is clear that thinking about systems in creation chains is uniform, at least about creators and the target system. Ideally, thinking about supra-systems should be organized in the same way, but there are infinitely many of them surrounding the target system and creators of the Universe, so you need to track some specific important needs for the links in the creation chain of supra-systems and the needs of external (for creator teams in our project) project roles for creators of these supra-systems, and some subjects of interest may be quite atypical, for example, "project management capability" as in the original diagram. It is also difficult to understand the digital twin: you can argue for a long time who makes what system description for what time and what degree of system readiness is typically done and in our project, which allows the system to describe and build itself (if we make the creator, this cannot be discounted, sometimes we make hardware, sometimes even personality, or even organization, and from time to time we deal with communities and societies as target systems - but here the division of labor can always be used, dividing by roles and discussing each role of an individual agent separately). Do not be afraid to modify sets of alphas. Only you inside the project can decide which alphas you need to track. But in general, it is good to follow the proposed set of alphas and at least think: have you not forgotten to track their status, and if they do not fit your project, then what needs to be monitored in it to not miss anything important in thinking.

Every project organization (engineering of the target system, development project, foundation project) works/uses/exploits in its own time. The same time for discussing the creator will be the time of creating the target system and the time of work/operation/usage/functioning of the creator. Therefore, carefully consider which time is being discussed and use suitable descriptions for that time (constructive for the creation time, functional for usage time).

The planning of these operations/services of the target system is not always done by the target system itself (this can be done by an operator from the creator system), therefore, the planning on the relationship between the system realization and its operations on the diagram is put in parentheses. By and large, at the time of work/operation of the target system, it can plan (in advance or "on the fly") its operations itself, even the simplest systems can do this, such as a fuse in an electrical circuit that "triggers" exactly when needed, "plans its work on the fly." Nevertheless, some machines sometimes start themselves, but sometimes they are started externally, and then they work on their own. In each specific project, all this needs to be discussed and the system scheme adjusted to the specific situation. After all, the lack of scaling and deseanthropomorphism of thinking in the methodology is not very developed, thinking about systems as possessing different degrees of rationality (including systems with developed AI) people have not yet learned, and in each combination of scales and considering the huge variety of systems, there can be some peculiarities. It is important that you are not afraid to change both the main alphas and their sub-alphas, and the number of links in the creation chains, and to break down various operations along the creation chains.

The engineering of the production platform (modern DevOps/SRE approach to platform engineering), including the creation of enterprise administrative services, is not shown in these diagrams. But this is the case: the development platform engineer creates a "big machine" (in the case of a rocket, it's the rocket factory, in the case of software, it's the inner development platform, in the case of an enterprise system, it's the administrative services, see the systems engineering and management courses in more detail) and ensures its operation, and the target system is manufactured on it. You need to consider this when adapting the main alphas for your project. This is usually done by CTO/CIO role players (chief technology/information officers, in the modern world, the "machine park" has largely become the park of corporate information systems, and the "chief engineer" and the "chief IT engineer" are one and the same in terms of their tasks), and these production platform engineers should not be confused with engineers of the target system: one designs and operates the factory, and the other designs and operates the target system produced and tested in that factory. The presence of two engineering teams in fact is not shown in the diagram. However, there can be many developer teams for different parts of the system, and the architect::role should be implemented by one team (not one person! A team with their modelers!)::organizational unit for all teams performing developer roles. Be attentive in modeling applied engineering, it's not all as simple as in the example from this section. Attention will surely need to be paid to a large number of alphas in your project - and an immediate recommendation: write it down! Model it, make lists and tables, contemplate them, allocate time to it: it will pay off, you won't later spend hours and hours in various meetings to figure out all misunderstandings. These misunderstandings won't have a chance to arise!

Which alpha is the main one in the project system scheme? On the one hand, all alphas need to be tracked for changes in the project, not forgetting any. But the "main among equals" in the project system scheme (including variations with creation chains) is the system realization alpha, tying all reasoning on the scheme to physical reality, providing adequacy to the project, preventing detachment from reality. Attaching all the other alphas to the system realization alpha helps avoid detached-from-physical-reality reasoning, which may turn out to be fantasies. The system realization - this is the target system in its physical form, its creation is the project goal. When conducting negotiations with various roles in the project (internal and external), be sure to explicitly discuss the creation chain from you and them to the target system of the project. Bring these discussions to the point where it is clear what will be best for the target system (you will make it faster, prevent errors, make it cheaper for the team, and more desirable for external project roles, this is the subject of discussions-negotiations in the project).