Alphas and artifacts/products
The OMG Standard Essence[1] proposes a special type of functional objects for monitoring project state changes - Alpha. Alpha is the object of attention, the functional/role nature of which corresponds to the area of interest "how the project works" (not how the target system works, but the project, i.e., the enabling systems). If we want to think coherently about how the project works, how the target system is created and then developed by the creators during their work, we need to focus attention on alphas, not on arbitrary objects.
The same OMG Essence standard for products/modules that physically implement alphas suggests the name Work Product/Artifact (work product, artifact, i.e., an object of artificial origin). A product/artifact/module is what we work on, what the project is "built" from, what can be found in the surrounding world. Although it is difficult to imagine physical realizations of some alphas as "products" (for example, the alpha "external project roles" is realized by living people, it is difficult to think of them as "work products"), the meaning remains: even if "products" are living people, you need to work on them, change their states during the project.
For example, in the course of the project, Vasiliy Pupkin must take on the role of the customer's financial specialist and in response to the question "to be or not to be?" say "to be!" and sign the documents. The alpha "external project role of financial specialist" as a sub-alpha of the alpha "external project roles" is needed to track the progression of Vasiliy Pupkin in taking on the role, his work in this role. It prompts keeping Vasiliy Pupkin attentive to this role, guiding him through the stages: he learns that he needs to be a financial specialist in the project, he agrees, he gets involved in the work, he cooperates, meaning he is already working on the project. The project team gradually moves him through these states, because without the team's work, Vasiliy Pupkin will go to drink beer and will not focus on the project, he will forget about it. The team remembers that they need to work on the fact that external project roles will be played by someone, and they carry out work for this purpose.
Alpha differs from the functional objects we have encountered before in the sense that it can also be an abstract object - some description of a system, a model. To understand the state of such an alpha, the description must be documented. How to understand if the usage concept is ready? Look at the documents where it is recorded! These documents will be work products/artifacts, they will serve as evidence of the state of the alpha. The state of the alpha changes during the project, and this can be recognized by looking at the state of the work products. Work products in all projects are different, while alphas remain more or less the same, with minor variations - this saves a lot of mental effort. The external role of "financial specialist," responsible for budget allocation and execution for the purchase of the target system, will be present in almost all projects, but in one project, Anna Pavlovna may monitor its fulfillment, in another Vasya Pupkin, and in a third, Vitaliy Viktorovich. Thinking about all of them is organized in the same way, in terms of alpha/functional object/external project role, rather than in terms of these different role-playing individuals.
But alphas can also be functional parts of systems, realized in life by constructive parts (modules/products/items/details) of system embodiments. In this case, we judge the state of the alpha by the state of the constructive parts embodying the system, which play the role of these alphas. How to understand in what state the "nail hammer" is? Look at the work product fulfilling its role: a stone or a microscope. This work product can go through many different states: being not yet chosen (before modular synthesis), being chosen and not yet purchased, being purchased, being assembled, being tested in operation. We look at the stone or microscope and talk about the state of the alpha "nail hammer." The alpha helps keep the project team focused on changing its state: as the team works, the "nail hammer" will first not be designed, then designed, then implemented in the physical world, then functioning in the system. This progress will be kept in mind; these state changes will be monitored.
Alphas do not necessarily indicate changes in the states of the target system specifically during the project. No, they can also indicate changes in the states of the environment systems, as well as those of the enabling systems. Systems thinking applies to all systems, and the target system is just a system at the origin, the main object of attention. However, attention is also maintained on other systems, and alphas help in this.
Examples of alphas: system realization (usually the target system, emphasizing its physicality, tracking the degree of readiness/realization in the physical world), system description (in real life, changes in the system description can be tracked through various work products/documents, including records in databases), system activities (this relates to the runtime of the embodied system, as the creator's system activities - this is another alpha! The state of activities is indicated by some Gantt chart or a list of tasks from the issue tracker).
Yes, these alphas are dealt with in the practices of commerce/marketing, systems engineering at the relevant level (not all of which are even referred to as classical engineering), organizational management (team engineering, customized to a certain working method), and operational management (resource allocation for work and ensuring that the work is actually carried out). Agents as team members, executing roles for all required practices/activities in the project, move these main alphas through their states during the project.
The state of the alpha as a role/functional object can be judged by observing the artifacts/work products/modules/role players playing that alpha's role. Observing the state of Prince Hamlet by watching Vasiliy Pupkin::agent at the moment, he plays the role (and only at that moment, and only in that part where Vasiliy Pupkin plays that role!).
Alphas should not be confused with artifacts/work products/actors: alphas (roles!) are the functional objects of the project (describing "how the project works," project time), while the work products and performers of work roles/actors are constructive objects ("what the project consists of," development time).
In the OMG Essence standard, they are depicted with different icons: the alpha resembles the Greek α, and the work product/artifact resembles a sheet of paper with a folded corner.
The standard was mainly developed for information system developers; hence, an artifact/work product is depicted as a sheet of paper - documentation. However, we understand that for alpha descriptions (models) - this is documentation, including electronic. And for other alphas (e.g., teams) - they could be living people, "organizational units." Alphas are roles, functional objects.
Even after modifications for better alignment with systems engineering (not just software engineering), alphas from OMG Essence are quite rugged as formalization (unfortunately!), but these nuances are not that important. The key here is to remember: alphas are drawn from "theory," from scientific, engineering, entrepreneurial (strategizing, product promotion, etc.), cultural (dance, for example), legal, medical, and other problem-solving and applied reasoning practices. In other words, alphas are loaded into the mind as types of important objects of attention in the project to answer the question "how the project works." And the artifacts/work products playing the role of these alphas can be found in real life. The primary skill of an intelligent person is to know the alphas "inside the head" as important types of objects and to be able to assess the state of alphas based on artifacts/products "in the surrounding context" that fit the alpha in terms of the meta-model or even a more general meta-meta-model.
In life, there isn't a single word from the texts of our courses, while in the course texts, there isn't a single word from the life around you - the courses mainly talk about alphas as important objects to track in the project, types of objects in the meta-meta-model, and in life, there are specific work products specific to each company where one can easily understand their types of meta-model classified as types of the meta-meta-model from our courses in transdisciplinary methods of thinking in the intellect-stack. This is a key point for understanding systemic thinking, crucial for understanding the way it is used - how the thinking techniques described in our course (theory) relate to the success of practice/work/engineering as changes in the real world: how the success of changing the world depends on modeling the correct features of this world, the correct properties of this world, the correct objects in this world.
You know that you need to find an object of a certain type of meta-meta-model (let's say, "our system"), and you look for an object of a certain type from the domain area (say, this will be "the mastery of coherence":: "our system"), and you also need to find this object itself ("Vasya's mastery of coherence"::"the mastery of coherence"). If you couldn't find it, then you didn't understand something - think, investigate, experiment, show an active life attitude. Systems thinking shows you what to focus on. But creativity is expected from you: guesses, actions (both mental and in the physical world) for their justification/assurance.
There is also the reverse scenario: you find that in the project, an important object X::of a type from the domain. And you determine its type from the meta-meta-model (fundamental knowledge, part of which is knowledge of systems thinking). Thinking in terms of the meta-meta-model, you understand what to ask next, what to do next, what errors are possible, and how to avoid them.
In any case, you are active: you work with the system descriptions of your project/models of the world and with the world itself - target systems, your systems, systems in the environment, creating systems along their long chains. Work - this is changing states. Alphas are needed specifically to track state changes!