Functionality and mastery of the subject area ​

One common mistake in system development is ignoring the explicit modeling of the functional structure of the system: documenting the circuit diagrams, descriptions of interactions "how it works." In electronics and electrical engineering, as well as in continuous production (chemical and energy plants), it is usual to draw such circuit diagrams (often documented with diagrams) where either functions/processes/behavior or functional parts of the system are explicitly indicated.

However, this method of mandatory drawing of functional diagrams is not applicable to all types of systems. For example, in software engineering, it is not common to draw functional/flow diagrams in most projects, nor is it customary to provide similar text descriptions (even in pseudocode). That is, programmers think about the functionality of their programs, but for some reason, they do not create fundamental/conceptual schematics of how their programs work; they keep pieces of these fundamental schematics exclusively in mind - and therefore, these schematics do not reveal gaps, errors, or allow discussions about the functioning of their systems with colleagues. These schematics are not visible in the source code of programs: the programming paradigm usually does not involve a dedicated display of the functionality of program parts, plus this functionality is significantly obscured by the details of the description required to execute the code. In advanced software development circles, this is not the case, and functional descriptions (often obtained within the domain-driven design practice) are documented, but this is not yet an established culture/practice, more like a pleasant and rare exception from the general practice.

The failure to work with functionality is a typical mistake of the engineers and manager-marketers joining a project (someone brought a project! So there must have been marketers, salespeople, or just proactive engineers, so there will also be a need to evaluate the market! If the project was brought by an "engineer," this is what you call an engineer by position, but in fact, he acted as an organizer initiating the project). "Tech-entrepreneurs" or corporate managers engage with external project stakeholders and usually understand their needs, but no one is concerned with the usage concept, i.e., the primary usage scenarios of the target system. Usage scenarios include not only the happy path, i.e., the system behavior when everything goes well without surprises. But there are always surprises, and you need to address them in advance. In such cases, the designing engineer creates a modular construction "on the grow" (services that, in his opinion, can provide all kinds of functions without additional modifications to the product if needed in the future). For this, the engineer connects standardized interfaces based on common and simple standards with modular constructive elements, hoping that after eight iterations, everything will somehow settle itself concerning functionality (there will be feedback from unsatisfied clients!), and the project will ultimately be successful. However, this is not elegant, not lean: additional functionality is added, while the required functionality may not be present in the initial iterations. It is noteworthy that this is how the "broken telephone" works: some people talk to the client (who are not trained in system engineering), while others develop the system (who are trained but have no contact with the client - and therefore the system concept turns out to be poor).

The mistake of not including functional parts of the system in the system concept can also be easily identified: they do not reflect the subject area for which the target system provides a service. The service is named (as people involved in the target system do, not the supra system), but the function or functional part in the supra system (what the module does as part of the supra system) is missing. For example, in the concept of an information system of a store, only a "database" appears, not "prices of goods, discount provision rules, purchase history." It is clear that all this information must be stored somewhere, but it is not certain that in the database diagram drawn by the programmer immediately, the "database" (part, for example, may be fetched through the API of a service, and discount presentation rules may be stored in a configuration file or turn out to be an artificial neural network), and it is not guaranteed that there will only be "a database."

Now, feel the difference: the service "pressure increase" and the function "lifting water to higher floors," the service "strikes" and the function "hammering a nail," the service "calculations" and the function "calculating a calibration curve." Functional diagrams will contain the names of functional parts or functions, and modular/product diagrams, disguised as functional ones, will still contain the names of services and indicate standardized interfaces as places/channels for the provision of services.

Explaining to a programmer the necessity of making functional descriptions as part of the system concept is challenging because they think in terms of modules/products/frameworks/platforms that, in their opinion, are entirely universal and will support "any function." Any-Any? Remember that you must double-check any universal quantifier encountered in system descriptions - "every," "any," "each," "all," etc., and follow it with a question mark, doubting this universality. Universality, unfortunately, does not exist. But the disappointment will come not at the beginning of the project but closer to the end - when it turns out that there are no universal applied software systems, just as there are no universal "hardware," "human," "cultural," etc., systems.

The architecture (architectural solutions related primarily to modularization and organization of communication between modules to support acceptable values more or less similar for various architectural characteristics of systems) is recognized by the programmer, but the system concept - no, functional decomposition is done on a large scale "in the mind" and then immediately in the source code, the "working code," and this is a flaw in the working method.

Here is an example illustrating what happens with engineers working on a more straightforward "hardware" system - but of the same class as programs: apparently super-universal in form but quite specific and unique in content.

We have a task to perform the delicate chemical synthesis of dimethylfluoro-dimethylchloropentylbenzene titanium for pharmaceutical industry purposes. It is known that it is difficult to synthesize and there are many impurities released during synthesis, which can result in human casualties. Therefore, we will offer pharmacies such a pure product that people will not die from it, and marketing will be unique: through medical institution cleaners, who will distribute our leaflets to doctors and also have heartfelt conversations with patients standing in queues at doctors' offices. To obtain a pure dimethylfluoro-dimethylchloropentylbenzene titanium, we will use four steel reactors connected by 56mm diameter pipes, with the last pipe having a Teflon coating. The second reactor will be ordered from external contractors. The purity of the resulting dimethylfluoro-dimethylchloropentylbenzene titanium will be monitored by an independent expert service. All four reactors must pass a pressure endurance test at 156 atmospheres.

This description does not mention which impurities have the most harmful effects, how to obtain purity specifically from these impurities (not just any impurities - harmless ones do not cause problems), what raw materials are needed and if they are available, or if they need to be synthesized within the project, followed by chemical reactions starting with available substances - i.e., a detailed analysis of what happens in the reactors.

Now imagine an engineer who is told by marketers that he will have to solve a chemical synthesis task, but it is still unclear which one. And sometime later, but not right now, they will hire a chemist who will clarify everything. The engineer agrees and gets to work: he understands immediately that reactors and pipes will be needed. It is unclear how many reactors will be needed, as it is uncertain how many chemical reactions will take place in the synthesis. Therefore, it would be better to have more reactors. He chooses the number 4 as "not too little, but not too costly," assumes that this synthesis may involve a tricky endothermic reaction, but he is unlikely to design a reactor for such a reaction himself. So, he delegates the task of designing this "tricky reactor" to external contractors and writes about it openly. Even though the contractors asked about masses and temperatures, as nobody can provide an answer at the moment, the contract plans are made without discussing usage scenarios - but the contractors, of course, do not refuse the order, saying they will make "any reactor." The word "any" does not deter anyone, as there is no chemist who can determine what will happen in that reactor. There are only iron engineers, who are knowledgeable about steel brands and welding, and marketers, who interact with doctors and pharmacists.

In the case of iron projects, there also need to be iterations gradually refining descriptions based on additional information obtained in these iterations. In our example, following a detailed examination of the functional descriptions, the number of reactors will be adjusted, extra pipes will be removed, additional research will be conducted on the availability of inexpensive purity sensors on the market, a contractor who writes control software for opening-closing valves on reactors to control the synthesis based on sensor readings will be found, and so on.

First, understanding the functioning is necessary: what happens when the system is running/working (the word "functioning" is chosen specifically here! Interested in functions and functional parts! This is the concern of roles responsible for system operation!), not when it is assembled from placed constructive parts of products/modules/items/platforms. Subsequently, in the modular synthesis, you will still need to consider both constructive parts and placements. But all that comes later, for starters, a quality functional decomposition, functional/system analysis needs to be done.

Considering the functioning first and the construction later is a vital part of systems thinking: it is essential to discuss in detail why these constructions are needed and how they will work, and then consider what they will be made of.

For example, one can apply these thoughts to dancing. Just waving arms and legs (with a margin! The more extensive the gestures, the better!) will not satisfy anyone. Each gesture must be meaningful; for what purpose - what emotion is it conveying, what message do they want to send with that gesture, what to demonstrate. Then the gesture will be selected accordingly (sharp, smooth, elaborate, or short, by hand or foot - precisely for the required function, not "standard with countless variations due to parameterization"). If you do not need to bring your leg directly to your ear for your dance ("with a margin," preparation of classical ballet, a decade of training), you can save many years of life. Less universal gestures "per function," considering the area of the specific dance, are mastered much faster.

You cannot only think about constructions. The absence of thinking about functionality needs to be realized and rectified. This absence of functional thinking is noticeable only in the presence of systematic thinking - it directs your attention, primarily focusing it on the functionality of systems: what the system does in the supra system (the first question), what subsystems do in the system (the second question), only the third question concerns "what the system is made of."

Now carefully look at your current project: are functional considerations overlooked in it? If they are overlooked, remember: without subject matter experts of the supra system, and later the target system, its subsystems, and your system (if it is created from creation systems), you will not understand it. Communicate, communicate, communicate. Systems thinkers are transdisciplinary; they engage with project roles responsible for a wide range of practices.

    Text in en: