Functional analysis and modular synthesis
Each labor role, due to the specifics of its concerns, sees a detailed description of the system as a "transparent box," consisting of the types of elements it is interested in, allowing for discussions on its concerns. An operations manager, for example, is interested in "what it is made of" and the logistics of these modular parts to the assembly point, but is less concerned with "how it works" and the functionality of system components. Operations managers managing configuration in construction systems do not have the functionality of the system as their area of interest. Management is usually not about functionality; it is about logistics! It is about "on time, nothing lost, everything handed over, all the engineer's proposed work completed."
On the other hand, an engineer thinking about calculating the operating mode of a system first thinks about "how it works" (functional analysis) and then will necessarily address "what it is made of" (modular synthesis). However, modular synthesis comes later, once the engineer understands the specific operating modes, how the system will function during its operation, and what characteristics will be required of the modules.
It is essential to note that engineering always involves both functional/system analysis (system analysis - remember that systems are usually described primarily by their roles, functions) and modular synthesis. Therefore, our course focuses on complete systems thinking, giving equal attention to analysis and synthesis. This is not a course on system analysis! Those who are engaged only in analysis (functional/system or other types) are dreamers without a chance to change the world. The world needs physical change. For this to happen, certain physical modules/modular parts need to assume the roles of functional parts of the system, be physically assembled to start interacting - the system must be realized in the physical world.
This is the same reasoning as with actors in theatrical performances. If you only write plays, define roles and their behaviors well but do not think about the embodiment of these plays by actors (including robots, animals), then it can be considered mere literary literature, not drama. Actors will fly there, disappear into the air, deliver lines telepathically - if the thought does not translate into reality, anything goes! Playwrights and directors typically envision their plays living in reality. Thinking must be adequate, not lose touch with the physical world, not just float in the clouds. The results of thinking must be related to changes in the world; just explaining the world is not enough!
Therefore, a systems thinker inevitably identifies no less than four areas/fields/subjects of interest:
- Functional/role/analytical,
- Modular/constructive/synthetic,
- Spatial (the integration of functional and constructive within 4D extensionalism, the manifestation of implementation in that functional and constructive parts occupy the same space-time),
- Cost/economic/resource.
Analysis/decomposition is always just part of thinking! Beware of projects where it is unclear who makes decisions on synthesis! Synthesis changes the world, analysis does not! Decisions on synthesis change the world!
Who has the right to specify that a rocket will have three stages? That a company will have three divisions? That John Doe will play the role of Prince Hamlet? Definitely not analysts! They are engineers!
Of course, the "analyst" is a role, not a position. A person in the position of an "analyst" can well perform the role of a synthesizer/designer, making decisions on modular synthesis. However, it is better to name such a position held by a person who makes decisions on changing the world differently, an "engineer": people do not expect "analysts" to have authority to change the world. Typically, decisions regarding assigning constructive parts of the system to role/functional parts are made by design engineers, not analysts, who are now more often seen as the "broken telephone" between the outside world and the engineer making the decision. The yacht will sail as you name it. Rename the analyst to an engineer, and you will see how they start taking responsibility for the decisions made (not just for the analytical "understanding" and "identified issues"), and people around them will acknowledge these decisions, not just consider them as "recommendations from an analyst" for some engineer.
An enterprise engineer is also an engineer, although it is just a different word for the role of a manager. Systematic management is a specialization of systems engineering for an organizational system, so the enterprise engineer is a manager. Organizational designers and organizational architects/"enterprise architects" understand that essentially, they are engineers. Leaders (those who undertake organizational changes) take from them the concept of organization (important decisions regarding the implementation of organizational roles by organizational units) and organizational architecture and further "manufacture" the enterprise itself based on these descriptions, explaining organizational roles to people (functional description of the enterprise) at each position in the organizational structure (constructive description of the enterprise), and "facilitating cooperation" by creating an atmosphere where each employee comprehensively performs their roles, regardless of where their workplace is located (location description), and with whom employees interact, given the inevitability of productive conflicts of interests among the roles played by the employees.
These concepts of organization and architecture are taken by leaders from designers and architects, i.e., from "synthesizers" (not analysts, analysis is performed as needed by the people performing the role of designers and architects). And remember that some "department head" who organizes their department fulfills the role of a development manager and the architect of that department, and maybe many other roles (for example, the architect of the target system, the administrator for that department, etc. - the smaller the enterprise, the more roles the same performer plays).
And, of course, "functional analysis" and "modular synthesis" are only two aspects, but in analysis-synthesis, you need to deal with all (the main four, dividing work as a candidate for the next mandatory decomposition, and many more that you will have to do in the project). Systems thinking is about finding a suboptimal solution that satisfies all project roles. You will not achieve the optimum; there are always numerous suboptimal solutions of approximately the same quality based on SoTA ideas, you must guess at least some, choose one of them, and remember that this is multi-criteria optimization, optimization occurs simultaneously at many system levels, its basis is guesses/inventions, which have undergone numerous justifications - this is research from research and development, R&D. If you have managed to coordinate more deeply all the descriptions/decompositions of the designed system, there is a good chance that at the moment you will achieve success compared to all competitors.