Sub-alpha ​

Sub-alphas are defined in relation to the main alpha as the alphas whose states progress towards their final state in the project can be considered as progressing the main alpha. This definition from the OMG Essence standard is not equivalent to the part-whole relationship, but it is very similar. If you make a leg of a chair (the embodiment sub-alpha of the system for the chair as the target system), then the whole chair becomes "more done."

The concept of using is a sub-alpha of system description: the more ready the concept of use, the more ready the system description (remember that the same concept of use, the same system description can be represented on different media by different methods, using even different notations - some degree of readiness of descriptions means their substantive readiness, not the degree of documentation! The degree of documentation is the degree of detail in the production of a work product, and the degree of readiness of the concept of use is about its content, regardless of the form in the work product/documentation).

The alpha of the system description can be represented passing states (remember that these states need to be adapted for different projects: for a musical, or pedagogical, or medical project system thinking is quite applicable, but many terms are better to be replaced or clarified the states):

• Conceived (clear what the system description will be)
• Coherent (the system description is created and coherent)
• Used for manufacturing (the description is used for manufacturing the system embodiment)
• Used for embodiment verification (the description is used for testing and validation)
• Used for operation (used by project roles for operating the system embodiment)
• Used for decommissioning (used for decommissioning and/or recycling of the system embodiment)

The concept of use as a sub-alpha of system description can be represented as passing states (these states are taken from the "requirements" alpha of OMG Essence, the English terms are from there, but remember that requirements engineering no longer exist, limited to creating a concept of use, where the main thing is the system description as a "black box" in the form of various use case scenarios):

• Conceived (internal project roles have agreed on the need for a new system to meet the needs of external project roles)
• Bounded- (the main function/purpose of the new system is clear)
• Coherent (the concept of use coherently describes the main usage scenarios, including significant characteristics of the new system)
• Acceptable (the concept of use describes a system that is acceptable both for internal and external project roles)
• Addressed (the system embodiment satisfies the concept of use to an extent where the system is accepted for operation by external project roles)
• Fulfilled (the system embodiment fully meets the concept of use, external project roles consider the system successful)

If the alpha of the concept of use passes through these states, it somehow advances through its states and the system description as a whole (the system description also includes architecture as a set of architectural solutions, and "work" as a working description with sufficient detail for system manufacturing). Of course, here it is important to note that the discussion is not necessarily about the entire system, but it could be about a specific feature of the system, or part of the concept of use that describes a more or less autonomous feature. However, these feature concept of use can be considered sub-alphas of the concept of use, second-level sub-alphas, because otherwise the concept of use as a sub-alpha of system description will simply stick in the "Addressed" state for the entire project duration, which will not characterize what is happening in the project. In such situations, sub-alphas are created in large projects at many levels: when something in the project is actively changing, is in different states, and as a whole, it cannot be said exactly what is happening.

Architecture is also a sub-alpha of system description: the more mature the architecture, the more described the system. "Work" (detailed models/drawings, and in the case of software, this is the source code, ready for compilation) is also a sub-alpha of system description.

The relationships between alphas and sub-alphas are determined by activities (not as part-whole relationships), but we think about these relationships similarly: if project roles, in implementing their preferences, progress sub-alphas through their states, they thereby progress the alpha of that sub-alpha. If project roles progress the whole alpha, then in fact, they are doing this by moving the different sub-alphas of that alpha.

The role description included in the system description answers questions about concerns. A project role may have several concerns. The role description allows describing the system to support a conversation with the project role on the subject/topic/area of interest, answering their questions on achieving their preferences in the interesting system characteristics. The result? A successful system: if stakeholders agree with the description, then the system embodiment that satisfies this description will most likely satisfy it. That is, the success of the system can often be determined when the system embodiments are not yet there, and there is only a description - the use of 3D information models, drawings, simulation models in engineering, notes in music, and any other records in design and construction is precisely aimed at this: to discuss in detail the implementation of the most diverse preferences in important characteristics/concerns for all roles in the project before the target system is embodied.

At the same time, we show project roles not descriptions, but documents/work products/artifacts: without information carriers, there is no way to present descriptions for discussion. So, first of all, all descriptions need to be documented, not kept in mind!

There are many descriptions: different project internal and external roles are interested in extremely different role descriptions/views of the system, and the important characteristics/concerns for very different roles are reflected in these views using a variety of role description/viewpoints, by which these views are made. And, of course, each description can be documented in different ways (for example, using different notations - numbers can be written with Arabic numerals, Roman numerals, in binary system), on different carriers.

All these numerous role/thematic/interest descriptions/views are sub-alphas of the system (full/comprehensive/for all roles/for all concerns) description. There are many more than the concept of use, the concept of the system, architecture, "work product." Here are financial models, physical simulation models, reliability forecasts, as well as numerous descriptions of what creation systems should do (for construction, this will be the POS, the construction organization plan - what builders should do during the construction of a building or structure): there are many descriptions, for an atomic station in paper form twenty years ago, there were several trucks of paper, and it was still not all the documentation!

The difference between a description and documentation is essential, but in life, they are often confused in speech: architecture (part of the system description) and architectural documentation (work products/artifacts/documents/files reflecting architectural solutions on some kind of information carrier). Very often the word "documentation" is omitted and readers are warned that it should be clear from the context - they are talking about architecture (system description) or architectural documentation (a set of work products/artifacts/documents/records with architectural decisions represented.)

In literature, the word "description" is often given not for an abstract object but for documentation, and in English, this would be called description. In systems engineering, our "system description" is system definition. In the Russian language, the word "definition" is confused with a dictionary definition, so we translated it more appropriately with the word "description," and description is also translated with the more appropriate Russian word "documentation." You should be able to navigate any terminology variation adopted in different fields of activity if you understand that there are always two different objects (ideal and reflected in information carriers) - they are simply denoted by different words accepted in different professional communities. For example, ontology is "ontological description" in our terminology; likewise, architecture corresponds to "architecture description." And ontology description (and in Russian literature, this could easily be translated as "ontological description" just as architecture description would be "architectural description") in our course will be an ontological documentation or documented ontology.

In the original ISO 42010, for example, a viewpoint is defined as role documentation/files, and a viewpoint is documentation/files of the description method, but in most parts of the standard, they are used as role descriptions, not documentation.

Words are essential (aside from words, we have nothing else), and unimportant (words usually do not mean what you think - you can't look up their meanings in a dictionary because there are many dictionaries, and language is living). Just carefully track the types of objects that are hidden behind suspicious terms, and everything will be fine. What terms are suspicious? Nearly all terms of systems thinking, including the term "system"! Often "system" is used in a colloquial sense, just to give scientific or engineering nature to what is being said, sometimes as a synonym for the word "object" - and not everyone using the word "system" is familiar with the systemic approach. "Concept of use," "architecture" are also likely to be used not as sub-alphas for the alpha of system description but in completely different meanings (for example, referring to documents named "concept of use" and "architecture").

A full system description is rather rare in life (although in projects there are always attempts to somehow gather many documents with different role descriptions together), more often, individual role descriptions of the system are found. Therefore, the view is usually translated simply as a "description," without indicating that it is role-based, but it is implied in its partiality; it only answers questions regarding part of the subjects of interest/important characteristics, and for answers on other subjects of interest, different views prepared with different description methods/viewpoints will be needed. The concept of use is also a description, and architecture is a description, and compliance with RAS and IFRS are descriptions, but each is not a full system description. You can advance the alpha of the system description through its states by advancing separate role descriptions/views corresponding to the states of individual sub-alphas, but there are quite a lot of these descriptions. What sub-alphas are most often tracked for the alpha of the system description?

Above all, the various roles in the project are interested in the states of developing functional descriptions, constructive/module/product descriptions, location descriptions, and cost descriptions as parts of the system concept, then more detailed descriptions, down to the "work product" with the level of detail sufficient for manufacturing or engineering justification, are of interest. But there may be a huge number of descriptions that interest very different labor roles in the project: for example, time synchronization of different contractors, ownership structures of environment parts, information flows, and so on. The more complex the system, the greater the number of descriptions (particular/role-based/on a specific topic) that can be expected. The important characteristics of systems for different people in roles are diverse, and system success is precisely determined by the completeness of their consideration/coordination of the values of these characteristics. You did not consider/did not coordinate the descriptions concerning, for example, frost resistance::concern - you did not get a successful system according to these descriptions. Or you did not consider/did not coordinate the different descriptions that show the system's behavior at different system levels - you also did not get a successful system.

An array of interests reflecting diverse description methods and prepared with these methods themselves, answering questions on preferences/interests, lies at the heart of systems thinking. Systems thinking postulates the existence of system descriptions ("they are important, they need to be done, even if it is very lazy and there is no time for it"), the need to explicitly specify methods of descriptions for them ("if you do not know what method you are using to describe something, it does not mean that you are describing it without a method, so think about the method and specify it"), the representation of descriptions in the physical world in the form of documents/files/artifacts ("do not keep descriptions in the chambers of your mind, make them readable by other people, with you being the first of these people, and these descriptions will help your biological brain be reliable in memory and attention retention"). Project documentation should reflect the values of important system characteristics in the project to maintain the attention on these characteristics of various project roles during discussions/agreements on preferences in these characteristics.

How to make these descriptions is explained in other disciplines: applied practices of systems engineering: classical and software engineering, education and coaching as personality engineering, management as organizational engineering/enterprise engineering, social engineering, and so on. For example, music is recorded in the form of a musical score in notation. How to make a score for a newly composed song? This is practical knowledge. In systems thinking, you only need to remember that if there is a "song," it must be in some way described. And this description must be documented. How exactly these descriptions are made (piano roll notation, or ancient Russian notation with hooks, or modern musical notation) is studied by applied disciplines. But if you have scores with notation, drawings, schedules, and organizational charts in your project, systemic thinking allows discussing all these individual descriptions without losing them - leaving the details of how exactly they are made and how to use them to applied disciplines. Systemic thinking is fundamental, penetrating all disciplines of thought based on the concepts of systemic approach. Knowledge of systemic thinking cannot replace knowledge of applied practices. Knowing that "there are always descriptions at a certain level of abstraction of meta-modeling, but they may not be concretized and documented" is not enough. You also need to know how to make these descriptions, i.e., you need to know the applied disciplines of classical and software engineering, management, medicine, law enforcement, political action, etc. Just systemic thinking for project work is not enough; you also need to master in the subject/applied expertise.