Practice discipline and how to describe it.
The most important in practice is this "invisible" part: the discipline/theory/model of the subject area. Thinking "by discipline" (discipline of the mind, discipline of using theoretical concepts in thinking) of a person is not easy to verify, the use of disciplined (rather than wild, "amateur", "folk") thinking in activities is difficult to discuss, and describing the discipline of thinking in general is unclear how to do.
For example, methodology is also a practice. Engineers could, in theory, read about this discipline in textbooks written by practologists, who were written by philosopher-methodologists. But it didn't go that way at all. Moreover, when it became necessary to describe the practice of methodology itself, there was no way to record practices - there were no methodologies as practices for engineers at that moment!
Donald Firesmith mentioned that in the early 80s, he and his friends were involved in object-oriented programming, which was trendy and new at the time. One day, his boss called him and said, "your programming performance has become several times higher than that of others in our company lately. Teach them your work methods." Donald went back to his workplace to think about the new task, and realized that he didn't understand - what is this "work method" he should teach his colleagues? What happens during the execution of a programming project using object-oriented programming method? He understood that he was no longer working the same way as before he got acquainted with object-oriented programming, but how to describe this difference in work? Externally, it simply looked like "sitting and thinking, discussing what to think about with friends in the evenings," it was necessary to describe not so much the external behavior (what and how to write), but what was happening "in the minds" - and not just the behavior itself, but the "work method" that determines the rules of the behavior happening in the minds for many different programming projects.
So he and his friends began to develop a new discipline called "method engineering." Of course, the methodology and tradition of methodology, as well as considerations on general activity theory, were not familiar to him - he was not a philosopher! Therefore, he and his friends had their own guesses/hypotheses about what should be the main objects of methodology. It soon became clear that no method/work method could be transferred from the specific project in which it was developed to another project. The situation (technology and features of the target system in a specific project) changed all previously step-by-step recorded behavior-patterns. And then, method engineering was renamed to situational method engineering, to emphasize the fact that each work method depends on the situation, and between situations not the method as a pre-defined sequence of operations survives, but only some of its parts. In various schools of situational method engineering, these parts were called components, chunks, slices, fragments, etc. - mainly components were "artifacts" (working products - what we work on), processes, tools - there were many options. Languages of situational method engineering (that is, languages of the reinvented by methodologists methodology), each of which defined its own set of "method components," were formulated as standards, based on which descriptions of various methods were subsequently developed. There are tens of thousands of these engineering work methods (descriptions of how to start work on an engineering project and how to finish) - and then these practices need to be put into action.
"A visible" discipline can only arise through its modeling, through description. In fact, few people have proficiency/competence in working with the practices of disciplines, as subjects. This methodological mastery/competence: mastery in the practice of methodology, as a practice of creating and developing (including describing) various practices. This practice is dedicated to our course.
In engineers' attempts to somehow model their work methods, two generations of situational method engineering and the standards reflecting these generations have emerged. Legitimately, they can be called methodological standards that describe the practices of methodological modeling/method modeling/work/engineering/work processes/creation and development of systems:
the first, aimed at methodologists who needed to describe work methods and systematize these work methods. These were primarily the standards OPF, ISO 24744, and OMG SPEM 2.0. There was a desire for rigor in these standards, models were difficult to read. The second, aimed primarily at the convenience of description method users (engineers), not methodologists. So far, this generation of standards consists of the OMG Essence standard, whose version 1.0 was released in November 2014. It provided its set of objects aimed to describe the method of development and system evolution (language), one of the main concepts of which became the alpha as an object of attention to changes in a project, as well as an additional "example" from the main (kernel) seven alphas (opportunity, stakeholders, software system, requirements, team, work, work way), to which all other alphas should be referred to as sub-alphas.
In our course, we use a part of the language of the modern version of the OMG Essence standard as the main concepts of the methodology discipline, harmonizing it with the achievements of many other researchers-methodologists. But these seven main alphas are outdated, as they reflected not a methodology but were already a model of a popular method of creating and developing software systems at that time, including, for example, requirements (from this alpha, in modern software engineering, work products reflecting requirements have ceased to be developed in most projects over the past five years.)
Methodology (for engineers, this can still be "situational method engineering," as they rightfully believe that work methods are created and developed exactly as computer programs are created and developed - only programs run on computers, and methods work on people and their equipment) is a practice consisting of the discipline/theory/model of activity plus technologies for modeling the most different practices/methods/work/engineering/processes of the creation and development of systems.
What roles need mastery in methodology? Those who have to describe practices (both new and existing ones) that should teach practices, that should recognize outdated practices, and suggest replacing them with new practices (and for this to be able to compare practices, discuss practices).
Visionaries in terms of methods/practices are culture carriers, who determine the need to work with a certain practice. Regimens, standards, handbooks on various methods/practices are written by methodologists jointly with subject matter experts (SME, subject matter expert) in the relevant subject area, and in preparing course materials (textbooks, assignments), they are supplemented with methodologists (specialists in instructional design, their mastery is to find effective ways to explain the material, select tasks and exercises, and advise on ways to maintain motivation for learning). Of course, if someone considers teaching some practice as mastering it, it will be necessary to involve many different roles (we haven't even mentioned the role of a student, a teacher yet, but this is not the whole list); this is studied in more detail in the course "Mastery of Educating the Educated". So there is no education without methodology, no engineering without methodology: if someone is doing/labouring/practicing, it is always work "in such a way, not in another". And here methodology is needed to discuss the work method/practice, discuss the activity in its difference from other activities, discuss the techno-evolution of activities/work, discuss the division of labor.
A new discipline usually arises as a result of some fundamental research. Fundamental research implies proposing, testing, and improving hypotheses/proposals/guesses about new objects of attention and their relationships, the existence of which was not discussed before. For example, quantum computing as a discipline develops based on fundamental physical research in quantum physics. Later, technologies are added to this discipline: primarily the quantum computers themselves - and it turns into the practice of quantum computing (named after the discipline). The discipline of quantum computing introduces the concept of quantum information and units of its measurement qubit - these are new concepts that were first put forward as hypotheses. Quantum computing is equivalent to a regular computer (that is, universal by Turing's criteria: it can perform all computations that a Turing machine, or a human brain, can - the difference is only in the efficiency of calculations depending on the algorithms used).
Hypotheses (e.g., the existence of quantum information and operations with it) are checked by logic, and then verification experiments are conducted - to see whether in the expression of reality models/theories are more precise than other models/theories with different guesses. And if these guesses are more accurate, they are taken seriously. This support also includes technology. For example, hypotheses regarding atomic nucleus energy were supported by technology in the form of an atomic bomb ("discovery on the tip of an academician's pen" of the discipline, followed by the creation of technology for the practice/method of atomic explosions). Hypotheses regarding quantum computing in the discipline were supported by creating quantum computers technology.
The discipline can be applied, it emerges as a result of applied research, which is organized exactly like fundamental research in terms of research method: guesses, criticism, improvement of guesses, taking seriously (for a while! Since there will be new guesses, more accurate) those guesses that proved to be better compared to other guesses.
Alphas, the states of which change the practice in a project, also arise from guesses, their logical criticism, and improvements.
Monographs, standards, reference materials (work of a methodologist), and even textbooks (work of an instructional designer) on a wide variety of fundamental and applied disciplines with their alpha proposals for each subject area are abundant, there are many scientific articles, descriptions of practical experience are sufficient (there is no need to conduct experiments on your own, they have already been conducted, although the people who conducted them might not have called it an "experiment", they were "just working" using the concepts of a certain discipline). So, it is enough to select a certain set of alphas from already known literature, harmonize them, outline them in the form of a coursebook or a set of exercises - this is such a "meta-research," research based on materials of other research. A textbook is already a transition to the development (instructional design as a discipline to develop educational products), and this is a good form of the end result: discipline comes to life only after being "loaded" into someone's mind (although there is also a way of reviving it as a computer program using its concepts and executing fragments of its subject thinking in the exocortex). And then this discipline must be supported by technology.
In particular, the discipline/theory of methodology in the current course version was not invented from scratch as a result of fundamental scientific research, assuming some guesses about concepts that did not exist before. No, it was documented as culturally conditioned. The authors of the course identified the minimum set of concepts of the most diverse methodology schools, based on the concepts of a systems approach in its engineering version (the second generation of the systems approach) and further slightly adapted to the third version (consideration of non-scalability and some deanthropomorphization of the agent/IPU aspect - stepping beyond the agent as a pure "biological human.") The technology intended for this intellectual discipline assumes to be typical for cognitive disciplines: any modeler, starting from the "pen-and-paper" for low-formal text modeling, to universal modelers for tabular modeling like notion.so, coda.io (and maybe many other different modeler variations).
This set of methodological concepts and systems thinking concepts were presented as a not-too-educational "textbook text" (without tasks and exercises for modeling) - this was a methodological work for the methodology course. Then the course was developed (more detailed and understandable explanations were added, the most common "novice mistakes" were indicated, tasks, assignments for tabular modeling/"modeling thinking," assignments for reading literature and text-based modeling/"writing thinking" for keeping the brain engaged in thinking using the concepts of the course applied to real life), it was an instructional design work. During instructional work, materials from many disciplines were used, connections with many other courses were drawn: remember that in one course, several different disciplines may be covered. So in the methodology course, there are numerous references "back" to the systems thinking course and "forward" to the systems engineering and management courses.
During configuration and change management, configuration collisions were eliminated: both the course of methodology and its version of a methodology discipline are now aligned with all other courses of the System Management School program and the disciplines revealed in these courses, as well as all other courses and the versions of disciplines disclosed in them are coordinated with the methodology course. Changes in the course material go in two lines: changes in the current version of the methodology discipline (reflecting the world progress in the methodology) and changes in terms of material consistency with other courses of the SSM program. Of course, this describes not just "creating a course," but "creating and developing a course", corresponding to the third generation of the systems approach and modern systems engineering.
Practicing the description of a discipline of "how to do something" (for example, "how to work with methodology," "how to catch fish in tropical seas," "how to program quantum computers," "how to create a political party") - this is the practice of methodology (and the concept of practice/activity/work is its most important concept, it is defined exactly in it). It can be said that the practice of methodology is a fundamental/transdisciplinary practice, as well as the practice of ontology, the practice of rationality, the practice of scale-free systemic engineering, and other practices in the stack of intelligence.
The practice is described and documented in culture approximately as "a description in an encyclopedia" or "a description in a scientific monograph," "a description in scientific articles," a textbook is still a rework of an "encyclopedia" or "monograph" and "articles" into a textbook and a set of exercises, facilitating the understanding of existing knowledge of the discipline, and often, not just one discipline is covered in the course (for example, the course on systems thinking describes quite a few different fundamental practices at various levels of detail, including some parts of the methodology practice. In our Methodology course, the focus is mainly on the practice of methodology but with many references to systems engineering practice and practices of system management).
The technology of modelers in the methodology practice allows making models of practices/activities/work/engineering/methods. Thus, methodology can be considered a full-fledged practice: its content is loaded into the mind, and there is a need to unfold a modeler on-site: a tool for modeling methods/activities, and then you need to have the "political will" to involve the resources of agents acting in the roles of methodologists and the resources of modelers for practicing methodology (to eventually have an organizational capability to work on methodology and then perform methodological work for selected methods, for example, methods from our methodology course).
It is the discipline that determines with what technology it can be supported, not the technology (in this case, the modeler) determines the discipline. The disciplinary part carries the functional load in practice, and the entire practice on a specific enterprise is called by the discipline, not the whole practice, but some of its parts. Methodology is above all a discipline. And the modeler as a technology for the practice of methodology can be the same as for many other disciplines (how to model the creation and development of the target system, how to model the creation and development of the enterprise::founder, will be discussed in more detail in the systems engineering and management courses, and more detailed in applied courses on individual sub-practices of engineering and management).
The discipline in practice is relatively rare to change; often it is about a cycle of changes in 10-20 years, previously it was more frequent, but now it can be less. For example, the systemic approach is relatively stable, the knowledge of its current third version can last for ten to fifteen years, and the knowledge of the second version held for almost thirty years. However, the technologies change much more often. The modelers for the same systems approach shift their generations every four years (the average rate of changing generations in information technologies. For example, in 2019, a standard for describing the physical structure of the system for modeling physical systems SSP, system structure and parametrization, emerged, and in 2020, the first modelers supporting it appeared - the modeling technologies also change rapidly). But all these modelers in reality support the same, much more slowly changing discipline, not the whole discipline, but only some of its parts. SSP is more about physical simulation modeling/simulations of the functionality of technical systems. It is an instrument, rather, of even the first version of systems thinking, considering multilevel aspects only in functional system breakdown. So, even system-wise, this tool can be quite conditionally called, although the authors included the word "system" in the method's title. Always pay attention to the date of the used version of your discipline first, and only then to the date of technology release! Otherwise, you will get something like the most modern tool for supporting the theory of phlogiston.
One cannot rest after achieving mastery in a particular discipline. For example, the state-of-the-art (SoTA, "the best known at the moment") of the discipline is described in textbooks and courses five years after its appearance as a result of research, and another five years pass before it begins massive study in universities (the discipline does not enter educational programs immediately!) - and only ten years after graduation, you may find that you possess some very antiquated understanding of the discipline - with a twenty-year-old "freshness".
For instance, most of today's heat engineers, operations managers, company founders, athletes, teachers, politicians, etc., if they know the system approach, they most likely know its outdated first version (remember that in the systems thinking course we are now talking about the third version already with the non-scalability and deanthropomorphization of agents/creators!) That in this version there are no project roles, and the life cycle means if not the change in the state of the target system, then only the work of creators, but not practices as ways of creators' work and certainly not continuous system development, but one-time "meeting requirements."
Lean manufacturing was mentioned for the first time in an article in 1988, more than thirty years have passed since the appearance of this practice! You need to track not just the quite frequent changes in technology in practice, but also the rare changes in the discipline!
What to do with your education under these conditions is explained in the course "Education for the Educated" (brief advice there - focus on fundamental transdisciplinary practices in the intelligence stack, including methodology, which will allow you to track changes in technology and practices faster and grasp new versions of practices sooner).