Sub-alpha ​

Sub-alphas and their states are created by the team as needed when the team realizes that the level of control is insufficient, and attention needs to be given to the parts of the situation defined by the alpha. A sub-alpha is simply an alpha related to another alpha by the relationship "if the state of the sub-alpha progresses, then the state of the super-alpha progresses." Moreover, each alpha (including sub-alphas) may have their own sub-alphas, and one sub-alpha can be a sub-alpha for several alphas and sub-alphas. Examples of these sub-alphas can be found in the OMG Essence standard itself or in various literature (in particular, it is necessary to mention the developments by Ivar Jacobson International, where sets of alphas with their states and the control questions of these states are proposed for various practices, especially for agile methodologies).

Here is an example of the sub-alpha "contractor" for the alpha "team." This alpha (remember, a sub-alpha is also an alpha! Just like a subsystem is also a system, and a subcase is also a case) was prepared by the course author for a large company engaged in the construction of complex engineering objects, hence the specificity of its states (and pay special attention to the fact that the work here is considered to be done once, "old-school"):

• Acknowledged — justification for outsourcing exists; a plan for subsystem usage is in place; expectations for warranty service and repairs are outlined; understanding of operational technologies exists; delivery deadlines are defined; acceptance criteria for the results are established; evaluation of possible pricing is available.
• Selected — technical and commercial proposals have been received; negotiations with candidates have been conducted; technical and commercial proposals have been evaluated; the contractor has been selected by us.
• Engaged — risks related to currency, delivery times, quality, and others have been assessed; a contract with identified risks has been signed; an advance payment has been made; necessary documentation for the start of work has been transferred; notification of work commencement has been received; communication procedures between the team and the performers have been established.
• Work in Progress — work monitoring is established; requests from both sides are taken into account; requests from both sides are resolved in a timely manner; work schedules are being adhered to; the work technology matches expectations; communication between the team and the performer is uninterrupted.
• Work Accepted — notification of work completion has been received; tests have been conducted; there are no quality issues with the work (if there are issues, they have been formulated and resolved); successful test completion certificates have been signed; work results have been delivered to the site; documentation has been handed over; assembly work has been completed; commissioning work has been carried out.
• Work Closed — acceptance and handover certificate has been signed; funds have been transferred; there are no outstanding matters with the contractor; warranty and maintenance work are being carried out; documentation has been archived.

This description of the sub-alpha is a meta-model of the subject area, not a meta-meta-model from our "for all types of projects" course; it's just an example! For other projects and companies, there would be completely different states for entirely different types of interaction between the team and the contractor.

Regularly checking what has been and has not been done using such a checklist significantly reduces risks. Since people are not computers, one out of ten times simply due to distraction or the hope that someone else on the team will do an important task, the task does not get done. Referring to the checklist of alpha states can save the situation.

For all issues identified during the review of the alpha states as a checklist, task works are planned to address these issues, and resources are allocated in accordance with the accepted work management practice (for example, a tracker is used for documenting tasks, and the TameFlow practice is used to start the work). These tasks will advance the states of all alphas in their relationships towards the successful completion of the project, and new issues will be identified in a timely manner again using the project system scheme.

For example, if the work is accepted for the contractor alpha (the penultimate state of the alpha), then the work is closed (the last state of the alpha) only after signing the acceptance and handover certificate (the first question in the checklist). We generate a task to sign the certificate, record it in the tracker as a task, assign someone to complete the task. This work will not be forgotten, it's attention management. This is the essence of using the project system scheme, tracking the states of alphas and sub-alphas, going through checklists for these states. Where do the top-level alphas come from? From system thinking: what lies behind these alphas has been discussed in detail in our courses on hundreds of pages. System thinking deals with attention management in complex projects that change the physical world.

Now think about how you would model working with the "contractor" alpha from the current section, in a situation where new circumstances constantly arise, and work cannot be fundamentally carried out as a one-time requirement. How would you reorganize the organization of work with contractors in such conditions? What checklists would you create for this?

A multitude of sub-alphas appears when you start modeling the system: each individual model and their harmonized (without configuration collisions) combination represent a sub-alpha.

Digital twins —informational/digital models of systems (physical twins/embodiments of the system), existing throughout their life cycle, especially during operations.

If we move up to the system level from the digital twin, we get a digital twins network. If we move down to a lower level, we get a whole series of models using various description viewpoints at the operations stage (this is particularly emphasized compared to PLM models, often not reaching the operations stage), as well as a series of models at earlier stages of the life cycle (development, justification, commissioning, operation): all these mechanical, electrical, thermal, and other models.

Digital thread — a technology (tools and practices for federating-merging-integrating data, usually based on so-called semantic data models, which are quite prevalent in engineering), linking all these individual models together, as well as the digital twins of the environment and the physical twin. An old-school engineer would call it "lifecycle data integration" and would mention numerous PLMs (if it's not mechanical engineering, they'd mention "enterprise data bus"), while a modern manager would say "digital thread" and mention PLM, ERP, EAM, and even CRM (and everything else). And since "digital is the new information," they will notice that for a building or a bridge, in addition to a BIM (building information model), the digital thread will add the drone data, IoT sensors, and some anomaly detection AI for repair-by-condition. Old-school engineers continue to talk about "data management" or "data management," the language of the "digital thread" doesn't excite them, although managers love this metaphor.

So, if it's necessary to link together a multi-physics model (multiple physics models—mechanical, electrical, thermal, acoustic, etc.), engineers will talk about simulation data management (SDM) for simulation data management, while old-school managers prefer to talk about information management for simulation-based/multi-physics modeling (but they talk about it quite rarely; managers don't get to these nuances, they are more about the "thread").

Digital Engineering —creating the digital twin by intertwining various models of it with a digital thread, as well as its physical twin and the digital twins of the environment. Digital engineering is the realm of a digital engineer, and the knowledge of a digital engineer's role must be so broad (including engineering and IT as a whole) that their organizational role is often performed by teams/org units of several people and often by collectives of many org units. Another synonym for digital engineering is Model-Based Engineering (MBE).

Modern engineering projects are becoming more complex, and the number of objects of attention being simultaneously held is increasing, simple formalizations are becoming more complicated. This means that the number of sub-alphas is growing, and to keep all of them in focus, the exocortex needs to be used: a variety of computer models.

**Digital twins^[1] and digital threads^[2] have proven to be very convenient ways of talking about system modeling. This approach has spread from engineering to various other subject areas (in medicine, the talk is about a digital twin of the patient, in education about a digital twin of the student, and so on). The concept has become so ingrained that besides cyber-physical systems, people talk about digital twins at various scales: for all types of systems (material, cyber-physical systems, creatures, personalities, organizations, communities, society, humanity).

The main idea: track the states of these models, track the course of modeling, use sub-alphas of system description, and work with these sub-alphas in writing—record changes in their states in some universal modeler, and work on changing these sub-alphas (achieving certain states of the digital twin with various models) in the issue tracker. You probably already do this, but the main point here is to think about all these sub-alphas in exactly the same way, and act on them in exactly the same way (at least at the meta-meta-model level. Already at the meta-model level, all the words will be different, but this should not confuse you).