Project roles and system descriptions ​

The scheme in thinking is not a diagram, but simply a set of concepts and relationships between them, it is a support for attention in thinking (a framework, "what to think about," what to keep in mind, a checklist of important things). More details about schemes, diagrams, texts, and various other types of descriptions are discussed in the course "Modeling and Coherence."

The entire text of our course provides a "big scheme of systems thinking" - a set of concepts of systems thinking interconnected by relationships. For some parts of this set of concepts and their relationships (schemes), we provided not only text describing them but also diagrams: a graphical representation of the scheme as a graph, where concepts are depicted as nodes, and the graph's edges represent relationships between concepts. There was a diagram for project roles, and we have just reviewed a diagram for system description.

Experience has shown that students do not perceive individual schemes from the systems thinking course as parts of one "big scheme." If you mention "project role," they immediately recall preferences but forget that the role performs a practice (which is mentioned in other paragraphs!). If you mention "important characteristics," they immediately recall preferences but forget that the role description/view answers questions about this characteristic precisely to understand what is happening with the preference, and the subject of interest is reflected/framed by the role method of description/viewpoint (which is in a completely different section of our course!).

The problem is that all concepts of the intellect stack (including methodological and systems thinking concepts) are applied together in reasoning, not in fragments. If you think about something important (remember that concepts of cognitive disciplines provide a checklist of what needs to be considered in a given situation), then think also about something important related by known relationships from cognitive disciplines to what you have already thought about. If you recall a project team member and their job role::type (applying the type from our course!), then also recall their subject of interest/important system characteristic::type, and their preference in the characteristic::type, but also remember their practice::type, role description::type, and its description method::type! What to "recall" here? Remember that in your reasoning, you need objects of these types and find these objects in real life! If you can't find them - ask questions, you'll get unexpected answers! This list of "what needs to be considered" is not that long: in life, so many things flash, howl, and shake in a project, distracting attention, that focusing attention on these understandable and familiar thought processes regarding objects of the subject area/objects in life guided by relationships between types of these objects taken from fundamental interdisciplinary thinking disciplines saves a huge amount of time.

Here is an example of a "company system diagram," which is good only for demonstrating a set of systems thinking, systems engineering, and management concepts applied to enterprise engineering (this diagram is detailed in the "Systems Management" course).

After examining this diagram^[1] (if you can't read anything there due to the small font, this is the problem with most large diagrams on small screens!), when a role::type of an object in the subject area comes to mind (say, when looking at Aristarkh Vladimirovich::actor, it comes to mind that he is an engineer-architect::role), do you now not only have the desire to think about his subjects of interest and preferences in them but also have the desire to think about architectural practices? The desire to think about description methods that establish agreements for descriptions used in architecture (e.g., ADR as architecture decision records) to support a substantive conversation with Aristarkh Vladimirovich as an engineer-architect? Not a fact. Much text that demonstrates examples of reasoning will help more here. The neural network trains better with the use of words rather than looking at pictures: humanity gained civilization after learning to write, pictures are not enough to convey knowledge.

It should also be noted that the "picture" itself contains very little knowledge; it still has to be described in hundreds of pages of text. It is not a fact that such a picture clarifies anything additionally: the more concepts and relationships a diagram contains, the less readable, understandable, and usable it is. And if it is broken down into parts - then thinking is also broken down into parts, it no longer has the integrity of the entire discipline. And we return to the initial question: how to connect well-grasped pieces about roles and their preferences in important characteristics in thinking with another well-grasped piece about roles and their description methods reflecting important characteristics of the system.

The biggest disaster would be if such a diagram is used in organizational work at the enterprise: it will be like a painting by a good artist - pleasant to look at, but very difficult to make corrections, so these corrections will not be made, and the diagram will soon diverge significantly from reality, becoming perpetually outdated. All models in systems thinking must be easily changeable and put under configuration management (there should always be an answer to the question of who changed what and when). Diagrams are significantly worse than texts in formal languages and worse than tables in this regard. Therefore, in real life, we use tabular modeling instead of diagrams: system thinking (by tabular) modeling, and examples - these are tasks for modeling in our course.

In any case, it is important to understand that the set of concepts as types of objects from life gradually and sequentially presented in the course, which are defined by disciplines of the intellect stack (including systems thinking), represents a certain "big scheme of the systemic method of description." The absence of a diagram as a graphical representation of the scheme for such a "big method description scheme" does not mean anything. You can safely consider that the entire course simply describes such a huge diagram textually, in which all concepts mentioned in the course are connected by some relationships, but there will be no diagrams-images for all of them; such a picture is useless.