Concept of practice
Like for any other systems, a key aspect of describing creation systems is the functional/role aspect. First of all, interest lies in answering the questions "why is it needed?" and "how does it work?". Functions as the targeted behavior of creators are called practices. Somewhere along the long chain of creation, some alpha necessary for creating the target system was transformed by a creator from one state to another. The creator as an organizational unit performed a service, altering work products, and for the alpha, the organizational role of this unit served the function of changing the required alpha (functions are always about "why it is needed"). This function in the details of its execution becomes a practice, a "way of working".
A method is usually synonymous with a practice, but more often in applied engineering and management it is a set of practices that allow achieving significant changes in the alphas of the project (for example, "chaos engineering engineering method/practice" - a set of practices for planning outages of various equipment for some time to see how the system copes with it, providing greater reliability. Or the method of constructing concrete buildings and structures using climbing formwork).
This understanding of "method" specific to classical engineering and management expects some completeness in reaching the alpha into a final state. In near-philosophical and humanitarian circles, the word "method" is practically equivalent to the terms "practice/activity/work/engineering", but in professional literature "all practices are equal, but a method is more equal" (a way of working to achieve a certain end result, end states of some alpha, not just any result).
Today, in addition to the word "practice", the term "process" is also used - over the past five years, the word "process" has ceased to always mean deployment in physical time/construction of work out of "procedure steps" and has acquired a shade indicating a functional aspect of work, deployment in logical time. Therefore, the word "process" is used not only in work management (where a process is a sequence of work), but also in lifecycle management, as a synonym for the term "practice" or "method." For example, today the "engineering justification process" means not just step-by-step work on justifying the success of the system, but a method of engineering justification as a set of practices needed for engineering justification (using the practice of "formal methods", where the practice name includes the word "method" as a synonym for practice/process/activity, as well as practices of expert assessment, conducting bench tests, security/safety case practices, and overall justification/assurance case practices, etc. - see the section on engineering justifications in the Systems Engineering course).
Very often, the term "activity" or even narrower "work" is used to talk about the execution of the practice by roles, where the performers possess domain competencies in the field of human activity (engineering, management, investments and technological entrepreneurship, healthcare, law enforcement, cultural construction, political societal reorganization, etc). According to this terminological tradition, engineering practices are called "engineering activity" or "engineering work," and configuration management practice is called "configuration management activity." It is incorrect to say that these are "professions" since it often refers to someone's ability/skill/mastery to change the state of alphas in real-life projects, rather than only "work in the profession." However, it should be recognized that "practices" and "professions" are close words, but discussing practices is more convenient than "professions." In principle, you can talk about "professional practices" as those whose cultural conditioning is conscious, and in which one can gain mastery at educational institutions focused on "professional training." But the concept of "profession" is also rapidly changing today; we avoid speaking about "profession" as a lifelong occupation in a particular area of human activity, it is now dying out, and people simply acquire expertise in various practices. Mastery in a practice/activity provides the opportunity, with the resources and assignments (organizational capability), to perform the work of that practice, without necessarily "being a professional." In theatrical metaphor, it is "knowing the role well and having experience performing it." At the same time, one can talk about "professional performance of a practice," meaning simply the qualitative completion of work according to the practice, the level of mastery. A music amateur may win a competition by inspiration, but his mastery is unstable: the next day he may perform poorly due to a lack of inspiration. A professional will always achieve some result, even in the most unfavorable conditions; they will not make novice mistakes, and their work is stable. A professional musician with a headache and family problems, sitting on an uncomfortable chair, will perform a concert, even if it is "mediocre," while an amateur in such conditions often cannot perform at all. So professionalism is "about people," and "practices/methods" are about what needs to be done.
For example, presentation preparation practices - many people prepare presentations, all of them have a certain level of proficiency in preparing presentations, but not all are ready to consider themselves "professional presenters."
The practice as an alpha (it also changes its states during the project! At first, it is not used in the project, work is not done on it, and nobody knows about it at all, but then work is carried out on it) has two important sub-alphas: theories/explanations (this is inculcated in the minds of workers and in computer memory), and supporting this discipline, technologies (that is, tools/work products/artifacts/production facilities - and it is deployed in the organizational unit that performs the practice).
In this context, the practice (behavior) is not "composed" of discipline and technology; they are not "part-whole" relationships, but another connection: advancing the sub-alpha "discipline" through its creation and mastery states advances the alpha "practice" as the corresponding behavior. Advancing technology in terms of its readiness for use advances the possibility of practicing something using that technology; it also advances the practice. This relationship is not about a whole-part relationship for behavior, but an alpha-sub alpha relationship.
Discipline refers to "scientific discipline" or "academic discipline," meaning a theory (fundamental/transdisciplinary or applied), a model, or an approach/framework. Discipline defines the main objects of attention/alphas/functional objects necessary for thinking about the subject area/domain. Actors-performers-roles are taught discipline, then they will play project roles that require mastery of that discipline.
Technology are the tools/means of production supporting the discipline and the materials they use. Modern practices do not involve work only with "bare brain"; they usually use tools to support the brain's work or the work of a group of brains in the organization (exocortex/"database": from paper and pencil to complex software), as well as to support work on changing the surrounding physical world (engineering practice includes not only a description of how to process metal parts/engineering discipline but also the technology of lathe work before, and the technology of working with CNC machines/centers now - knowledge of tools and how to use them/technology is part of practice). Sensors and measuring equipment also fall into technology. Therefore, in addition to discipline, attention is given to necessary tools and materials used by them. For example, in the project management practice/method, project management software is usually used, such as MS Project or Primavera. So, apart from deciding which project management discipline option to use, a decision also needs to be made on the specific software to be used to support the chosen project management discipline. Then follows the formula: "instill discipline in the mind, deploy technology in the workplace", meaning, teach people in the organizational unit the project management discipline (or use people who already have this mastery) and teach them how to use the technology. In the workplace of these people, deploy the technology itself, which means project management software. Together, we get "acquired practice". Next, simply empower these people with "mastery inside and tools outside" to use this practice in their work and give them the opportunity to spend time on project management practice (rather than, for example, process management or case management), and the result is the organizational capability of project management.
Discipline should be supplemented with instructions on how it is supported by tools - technology. In the dance practice/method (we avoid the word "dance" to strictly refer to behavior, to practice) - the technology in dancing is the technology of working with the body, the tool for dancing is the body, but not only. For example, turns in folk/rural dance styles are often done with stepping by bare feet on rough floors (soil, asphalt), while in urban ones - rotating the soles on smooth indoor floors. In addition to good floor quality for practicing, a music source is needed, and for partner dances, a partner is also needed: another body, and the dancer's choreography becomes part of the dance performance. Just knowledge of dance theory/discipline is not enough; instructions on how to use the human body to implement that knowledge, what type of floor covering is required, and how to interact with the music (in addition to the discipline, the technology is definitely a part of the practice). Sensors and measuring equipment also fall into technology. Therefore, the need for memorization: "in practice, discipline is absorbed by the performer's mind and turns into mastery, while technology is deployed at the execution site and turns into tools and materials - and then you need political will to follow the discipline and use the technology".
Practice - first of all, the role/functional behavior of the creator as an organizational role/functional object. Thinking about functional objects is difficult and counterintuitive, implicitly assuming the presence not only of the system itself but also of its environment (function is the behavior required of a functional object from its environment). Thinking of organizations/enterprises/organizational units as entities implementing the roles of practices and engagement practices is not easy; this requires some time to learn. Teaching thinking about practices and roles in creation as practices and roles in systems engineering (normative methodology, not just about thinking about activities/practices but also about how to conduct activities/practices: which objects to keep in mind, what to consider in your actions for changing the world) is done in the Systems Engineering course, and about practices and roles in the creation of creator organizations is covered in the Systems Management course. In the methodology course, we only give initial ideas about practices/activities/work with a focus on discipline and ignore the technology of working with practices as objects (methodology is the discipline about practices themselves!), although we clearly specify that the methodology practice mainly involves different modelers for modeling used methods for creating and developing systems in projects.
Additionally, it needs to be remembered that practices are often culturally conditioned. The practice of "hammering nails" and the role of "nail-hammerer" are hardly culturally conditioned today; it is clearly a subset of carpentry work/practice/labor. The work role of a carpenter performing carpentry work might be culturally conditioned. However, if you need to design a method of creating a specific system where simple nail hammering is needed to fasten two wooden planks together, then you don't need all of carpentry; you can consciously separate the sub-practice of "hammering nails" and the role of "nail-hammerer" (or even the role of "fastener" for the practice/method of "nailing" as a subset of carpentry work). You can do anything as long as you know what you're doing.
If an ATM breaks down, the person responsible for performing all the necessary tasks, some of which the ATM performed, is sought: the ATM does not play a project role, nor does it play an organizational role. Only people and their organized groups, that is, with clear authorities and responsibilities in managing labor and capital, can play organizational roles, making role decisions (a hammer makes no decisions!). But when you are unsure whether people or machines will make decisions (not yet completed modular synthesis, just functional decomposition/analysis), you can certainly talk about the "nail hammerer" performing the practice of "hammering nails" - without going into details, a living or non-living constructive object/organizational unit/role will perform the actual work of that practice. Increasingly, the organizational unit is seen as much equipment and the people attached to it (an excavator with an excavator operator), rather than people with the equipment attached to them (an excavator operator with an excavator attached). By and large, this is a matter of preference in perspective. If you need to see what work is performed, the excavator is more important; if something goes wrong, you will have to negotiate with the excavator operator. If something major goes wrong, you will search for people behind the excavator with the excavator operator much like you would find people behind a broken ATM: whether the "nail driver" is broken, the "nail hammerer" is broken, or both - is no longer important; you need to find the one who will "fix" them, the creator (or at least the supervisor who will issue that "political will" - allow you to act according to the practice you need and allocate resources and time to the excavator operator and the excavator for that purpose, fuel for the excavator and its consumables for maintenance).
Furthermore, practices should be culturally nuanced. The practice of "hammering nails" and the role of "nail hammerer" is unlikely to be culturally nuanced today; it is clearly a subset of carpentry work/practice/labor. The work role of a carpenter performing carpentry work might be culturally nuanced. However, if you need to design a method of creating a specific system where simple nail hammering is needed to fasten two wooden planks together, then you don't need all of carpentry; you can consciously separate the sub-practice of "hammering nails" and the role of "nail hammerer". The practice of "hammering nails" is a role playing the hammering nails or even the role of "fastener" for the practice/method of "nailing" as a subset of carpentry work. You can do anything as long as you know what you're doing.
The practice - the behavior execution of the organizational role by its function - exists in the world only at the moment when work is done on it (by the assigned organizational unit responsible for this role, carrying out this practice). Until the moment of actual work practice execution, it is simply an organizational capability, meaning the practice allocated to it - loaded already in the minds of performers with knowledge in the discipline and unfolded and tested toolkit, plus having the authorities to perform the necessary tasks for the practice and the available resources - that is, it is about the organizational capability of performing a certain practice (work according to some method) in an organization.
The practice can be realized in various scenarios/plans/work sequences. The organizational role/functional/project role of a system demonstrating a practice as the behavior of this organizational role can be performed by various organizational units as constructive objects carrying out this organizational role.
The practice of nail hammering can be carried out when there is a need in creating a wooden system by either the crew of carpenters themselves or an experienced guest worker. Both these different organizational units (the crew of carpenters and the guest worker) can perform the organizational role/project role of "nail hammerer" demonstrating the behavior/practice of "hammering nails." And if nails are started to be hammered by an automaton, not people? The reasoning remains the same: the role of the "nail driver" becomes part of some larger human organizational role.
When an ATM malfunctions, the person responsible for all the tasks, some of which the ATM performed, is sought: the ATM does not play a project role, nor does it play an organizational role. Only people and their organized groups, with clear authorities and responsibilities in managing labor and capital, can play organizational roles, making role decisions (a hammer makes no decisions!). But when you are unsure whether people or machines will make decisions (not yet completed modular synthesis, just functional decomposition/analysis), you can certainly talk about the "nail hammerer" performing the practice of "hammering nails" - without going into details, a living or non-living constructive object/organizational unit/role will perform the actual work of that practice. Increasingly, the organizational unit is seen as much equipment and the people attached to it (an excavator with an excavator operator), rather than people with the equipment attached to them (an excavator operator with an excavator). By and large, this is a matter of preference in perspective. If you need to see what work is performed, the excavator is more important; if something goes wrong, you will have to negotiate with the excavator operator. If something major goes wrong, you will search for people behind the excavator with the excavator operator much like you would find people behind a broken ATM: whether the "nail driver" is broken, the "nail hammerer" is broken, or both - is no longer important; you need to find the one who will "fix" them, the creator (or at least the supervisor who will issue that "political will" - allow you to act according to the practice you need and allocate resources and time to the excavator operator and the excavator for that purpose, fuel for the excavator and its consumables for maintenance).
You should also be aware of the types of concepts hiding behind the terms in your speech (practice or organizational unit), and understand metonymies. However, this is a general advice for thinking about not only practices/activities/work, but also a broader thinking practice. The usefulness and importance of controlling types and dealing with metonymy in thinking is discussed in the theory of concepts and ontology, which are parts of the intellectual stack.