Alpha of system description ​

System description, along with system realization, relates to the area of interest of some (target or creator) system, engaged in by the engineers of that system, that is, engineers of the system-creator. If it's a target system, then it involves some applied engineers - "hardware" engineers, doctors, teachers - we consider them all as engineers. If it's about a system in the creation chain, then people there are engineers of the enterprise, that is, managers, but it could also be a "machine" or "software," and then we come back to the engineers in all their subject diversity.

As a standalone alpha of system description, it is only considered in the most general project discussions. For real tracking work on system description, it is necessary to immediately break it down into sub-alphas (usage concept, system concept, architecture, "work package" like a project with sufficient detail for production, and many other various models).

For different types of systems, sub-alphas of system description are named differently. For example, for information and "hardware" systems, they are called "architecture solutions," for an enterprise, they can be called "org-architectural solutions," and for a sports event, they will be called "rules."

The state of the alpha of system description is evidenced by documentation, the description is put under configuration management (so, there can be several variants of the system described, but only one of them can be implemented).

Here's a very generalized example of a set of states of the alpha of description for a "hardware" system. For other types of systems (say, you are involved in management, politics, breeding rare beetle species, or education), it is recommended to adapt these states. As usual, we replace the term "project organization" with the familiar "project team" or simply "team," but it could also be "project cooperation for the construction of a nuclear power plant" with thousands of teams in different creation chains. Keep in mind that we may not be talking about creating a complete description for an MVP system being created for the first time, but about describing an increment/modernization or a specific feature of the system (and, accordingly, it is not a complete description, but an increment - in this case, it is better to work with sub-alphas, but the alpha of system description is necessary as a checklist item to consider what descriptions are available and what sub-alphas are needed to track the status of individual specific descriptions/views).

The description of the system (or its increment) may have states:

• Conceived: external project roles and the team agree that the system will be made; system description methods are agreed upon; the method of coordinating private descriptions with external project roles is agreed upon; configuration management mechanisms of documentation are agreed upon.
• Coherent: private system descriptions are documented, and the documentation is available to the team and external project roles; the origin of descriptions is clear; descriptions are verified; conflicting descriptions are identified and addressed; the team understands the descriptions and agrees to implement them; the corresponding system expected from the descriptions is expected to be successful (interests of external project roles are taken into account).
• In use for manufacturing: a part of the team responsible for manufacturing the system considers that the system's descriptions are sufficient to start production; manufacturing practices based on these system descriptions are described and documented; problems arising during system manufacturing lead to refinement and updating of system descriptions.
• In use for assurance: all descriptions needed for engineering assurance of system success (assurance case) are available; tests, success criteria, and their conduct are defined; external project roles agree on the extent of the tests.
• In use for operations: the system description is used to collect information about the state of the operated system embodiment (digital twin); the system description, along with the digital twin information, is used to make decisions about maintenance, repairs, and system upgrading/evolution.
• In use for retirement: used to determine the retirement timing or decide on extending operations; demonstrates the absence of harmful effects (e.g., pollution of the environment) during retirement; used for planning and conducting decommissioning and/or recycling of the system embodiment.

The above states of the alpha of system description are so generic that they must be concretized for a real project - in terminology and the states themselves established for system description but also for sub-alphas.

Here's what the alpha of organization description in the creation chain could look like. The organization description (or its increment/organization changes) may have states:

• Conceived: the development team agrees that the project organization will be created. Organization description methods are agreed upon; the method of coordinating organization descriptions with external project roles of organizational development is agreed upon; configuration management mechanisms for organizational documentation are agreed upon.
• Coherent: organization descriptions are documented, and the documentation is available to the development team and engineering team; the origin of descriptions is clear; descriptions are verified; conflicting descriptions are identified and addressed; the development team and the engineering team of the target system understand the descriptions and agree to embody them; the organization corresponding to the descriptions is accepted by the development team as deserving of embodiment.
• In use for leadership: the engineering team organizing the team of managers considers that the system descriptions are sufficient to start creation; organizational practices based on these organization descriptions are themselves described and documented; problems arising during organizing the engineering team lead to refinement and updating of organization descriptions.
• In use for operations: the system description is used to collect information about the organization's state (digital twin); the organization description, along with the digital twin information, is used to make decisions on improvement (continuous improvements) and development.
• In use for adjournment: used to determine the dissolution timing of the organization or decide on continuing operations; it demonstrates the absence of harmful effects (e.g., providing certain services, still needed by external organizational project links at project-launch). It is used for planning and conducting dissolution or reprofiling activities.

The methodology relates to the passage of the alpha of system description (we have given an example of an alpha for the target system and for the organization of the engineering team of the target system, but there are many systems within creation chains and in the environment of systems in creation chains) and its sub-alphas of all planned states during the project, and this description needs to be made using some description/viewpoints methods, that is, to use various description practices with their disciplines and technology/modelers. Systems thinking says that the description should be done considering all system modeling requirements. Everything that the course of systems thinking covered about descriptions and modeling is essential for working with the system description alpha.

In general, in the description of creators, the sub-alpha description of the work method/way of working/creation and development method of the target system could be highlighted. Of course, for a specific project, it is recommended to adapt them (at least to rephrase them so that the description text is understood by the whole team and these states reflect the method as a whole or some increments/modernizations of the method. Essentially, the content of the "Systems Engineering" course is a very generalized/abstract description of the method of creating and developing various systems, the "System Management" course is also a quite abstract description of the method of creating organizational systems, and our "Methodology" course is devoted to description methods of methods as well. So, modeling the work method by defining alphas, their states, controlling questions that ensure achieving states as passing control events/milestones - this is a description of the method, and it can be considered as a sub-alpha of the organization description.

If your system concept (system description sub-alpha) does not include functional system descriptions like a "white box" but only lists a set of system modular elements and where they are located, the project will not be successful, but only bring failures. This also applies to organizational systems - if the organization concept does not include organizational roles but only organizational units and their locations, it is just a particular case of a system. Students whose system description alpha does not consider what was written in the "Systems Thinking" course about the minimum necessary breakdowns that need to be described (functional, constructive, allocations, cost - and that's a minimum), whose descriptions are mixed up for different systems (for instance, the constructive description of the target system is given, and the functional description of our system, which is somewhere in the creation chain - to the extent that it is impossible to understand which description describes which system), who have obvious configuration collisions (for example, given two lists of functional parts of some system, not even a target one, and these lists contain a different number of parts without indicating reasons for the discrepancy) - all such students will get two points when taking the exam, regardless of whether this exam is in a university or in real life (in real life, they will simply be fired or transferred to a less qualified job; sometimes they are heavily penalized for such mistakes). Systems thinking is the management of attention, and to avoid losing attention of yourself and the team, you need to use the modern practice of concentration: to focus attention conceptually (use types of high-level models to differentiate objects from the background), and then sustain that attention for a long time, using external information carriers - primarily computers. In projects, it is also collective systems thinking, supported by collective concentration. If you don't know how to describe the most important things in systems and securely document these descriptions - it's all bad, the attention of both individual and collective is scattered, problems are on the way.

If employees with scattered, non-systematic attention, which does not track what is important but only tracks the familiar based on past "work experience," come to projects, they will bring misfortune to that project.

Investors can be sympathized with: a project with employees so attentive to unimportant things and inattentive to important things poses great risks, and few will understand why everything is going so poorly, as everyone is working hard! However, projects go wrong mainly due to inattention to what is important, tangled attention, i.e., lack of systematicness, lack of concentration, and impracticality. To succeed, one should not only work a lot and hard but work a lot and hard on important objects, not on those that were thought of casually. The main alphas and their sub-alphas are these important objects, you cannot take your eyes off them throughout the project, they will constantly change states, sometimes reverting back, changing these states later than expected, and all of this needs to be tracked.