Reasoning around systems engineering and comments on "Richard Hamming: Chapter 28. Systems Engineering"

I tried to comment on the article by Richard Hamming: Chapter 28. Systems Engineering ” through his understanding of the problems of“ system engineering ”and taking into account the“ modernity ”, as well as related EA / BPM.

Excerpts from the original are shown in quotations, from other sources - in italics. Plus, the reasoning around systems engineering.
')
System engineering or Systems engineering (SE) is also a well-known area, as well as BPM (Business Process Management) and EA (Enterprise Architecture). Finding where SE ends and EA and BPM begin is difficult. All these three areas were “very developed”, especially in the marketing plane.

Any “big and complex” design should be based on SE. Designing an enterprise (and this is a complex system), a description of the enterprise architecture is not SE? The SE standards often use both “enterprise” and “architecture”. There is even a separate area of Enterprise Systems Engineering (ESE)

There are stories (tales) AS THE ARCHITECTURE OF THE ENTERPRISE COMPLETES SYSTEM ENGINEERING

For simple systems, as a rule, BPM is not used, which means that “the whole BPM” is also about SE, and in the SE standards it is constantly referred to as “modeling” and “processes”.
Thus, it is difficult to imagine an EA or BPM without the “appendage” of the SE: in total, we get the trinity of EA-BPM-SE.

Since SE is the design of everything “big and complex”, then by “definition” it intersects with almost everything known from “Best Practice” & xxBOK, including “SE & PMBOK”, “SE & ITSM”, but we will limit ourselves to this “troika” ", And taking into account what was stated in my cycles criticizing EA and BPM:

Enterprise Architecture vs alchemy enterprises
Business Processes: How Everything is Launched and Confused (BPM)

Key conclusion: If we consider EA and BPM as alchemy, and the SE does not refute their approaches, but rather “complements”, and often “duplicates and repeats”, then we can question the assertion that SE is an engineering discipline.

The problem of modern SE is the same as for EA and BPM - there are no detailed published examples of their approbation. Almost all projects are closed through the NDA, the DSP and the "military secret", there are no step-by-step examples of the project. But a lot of earning on SE associations, a lot of marketing, courses, sales, etc.

Little about SE

Systems engineering is an interdisciplinary approach that defines the complete set of technical and managerial efforts that are required to transform a set of customer needs and expectations and constraints into effective solutions and support these solutions throughout their life cycle (ISO 24765).
sewiki.ru

From the book "Systems Engineering for Dummies" by IBM

Systems engineering is an interdisciplinary approach to the creation of large integrated systems that meet a specific set of economic and technical requirements.
In the aerospace and defense industries, system engineering has been in use for a long time, and many of the knowledge gained through empirical knowledge has been applied in other areas.

Wiki Systems engineering
- very sparingly.

However, as Wiki Systems Engineering

Given that the Soviet school of systems engineering / systems engineering was not inferior to the western at that time.

For some reason, the primacy of the SE is given to the USA (debatable question):
According to the legend, system engineering first appeared as a method of conducting work in the US military industry, when it was necessary to cross two highly complex engineering projects: an atomic project to create nuclear weapons and a project to create ballistic missiles needed to deliver these weapons. There were no heads of “general designers” who could cope with the solution of this problem, and it was necessary to invent methods of coping with the complexity of such a super-project.
System engineering thinking

I doubt that Soviet similar projects did not use the same SE-approaches.

SE is about the design, implementation and maintenance of systems, and complex systems. The process of problem solving by systems engineering methods includes problem statement, finding fundamental technical solutions, system modeling, optimization, architecture, manufacturing and launch, trial operation, as well as analyzing the effectiveness of the resulting product (“system” type products).

And, what is very important - this approach, above all, protects the interests of the development consumer (customer), and not the consultant or developer. In any case, it was originally intended.

Systems Engineering Standards

A visual reflection of the tasks of the SE can be considered (conditionally) the picture (as well as the tasks of the PMBOK): Project “Tarzanka”

1. Start

In the first three paragraphs, “Chapter 28. Systems Engineering”, through “The man watched how the cathedral was built,” the simple truth is said: “You cannot see the forest for the trees.” This is a typical situation where people concentrate on particulars and do not see the “whole”. A lot has been written about this. Something I have:
3.5 Forests, trees, leaves
can be divided into two tasks (categories): the task of describing a “forest” (processes in a “large cage”, a view from a bird's-eye view) and sufficiently detailed “processes-trees”

They demonstrate narrow views in their work and rarely, if ever, associate it with the more general goals of the system.

Such narrowness of views is the main characteristic of the bureaucrat.

Rather, not a “bureaucrat”, but a highly specialized specialist. Indeed, attempts to optimize a “separate section” do not always lead to an improvement in the operation of the “system as a whole”.

Systems engineering is an attempt to always keep the main goals in mind and understand what each local action is done for and how it affects the overall result.

Those. ability to see both “forest” and “trees”, to understand the laws of development (life) of “forest” and completely different laws (life) of “trees”, and each “tree” has its own laws.

Actually, this is a mechanism for moving from a large scale to a small scale and back.

Naturally, I soon realized that the greatest value from the new machines can only be learned by scientists themselves when working directly.

I project this idea into our time as the need to involve the business users themselves “directly” to describe and optimize their business processes without using IT specialists (BPM specialists, EA architects and other alchemists) and programmers.

This was discussed in the article Business processes: How everything is started and confused. Chapter Three General BPM Classification and BPMS Philosophy
Over the years, the desire (dream No. 2) has not been extinguished - to find a simple way of modeling processes directly by their participants (involved in the process) without involving BPM specialists “in drawing squares and circles”, as well as performing the processes thus constructed. Hence, strong craving (hope) for the BPMS format

The commitments in each case were: (1) a direct contribution, (2) a long-term contribution, and (3) a very long-term contribution. I also understood that under clauses (2) and (3) one of my functions in the research department was not so much a solution to existing problems as developing methods for solving problems, expanding the range of possibilities and teaching others what I was able to find so that they could continue to apply, continue and improve the results of my efforts.

This is what I am trying to convey in the EA cycle of Enterprise Architecture vs Enterprise Alchemy, i.e. show that the transformation of existing approaches to EA and BPM should be aimed at:

not so much a solution to existing problems ...

those. not the development of a short-term description of EA, which is also closed according to NDA and DSP, i.e. purely monetarization of this direction. And it is very debatable that the problems are really “solved”, since The often unsuccessful (failed) BPM \ EA \ SE project is presented as successful, but the truth cannot be known.

how much by developing methods for solving problems, expanding the range of possibilities and teaching others to ...

this is possible only through open discussion and not so much “problem-solving methods” - methodologies and mysterious frameworks, but demonstrations with concrete examples, testing theoretical “Best Practice” and publishing practical “Best Practice”. Unfortunately, this is not the case in modern EA and BPM and SE.

... what I was able to discover so that they could further apply, continue and improve the results of my efforts.

Many practitioners of EA and BPM and SE are only interested in personal gain, but the development of the direction in general, or rather the transition from “alchemy” to “chemistry” - few people. The business of EA and BPM and SE is prosperous: consulting, coaching, tools, etc., but as far as practice and the “theory of Lenin” are concerned, we have zero: “There is nothing more practical than a good theory”. There is no evidence in the public domain of practicality, nothing at all from the practice of EA and BPM and SE - no.

All "practical", i.e. All examples are either commercial or state secrets. Who said that the methodologies and the projects carried out on them are successful? Based on what? And with what benefit?

However, later I realized that I should pay attention not only to the needs of the Research Department, but also to all the needs of Laboratories.

Then it was AT & T, the Country outside AT & T, the scientific and engineering communities, and, ultimately, the whole world. Thus, I had obligations to myself, my department, division, company, parent company, country, world of scientists and engineers, and every inhabitant of the planet.

Such obligations and more to our fellow citizens. Especially those who either practice SE or teach others SE methods. Especially those responsible for the development of domestic SE.

With regard to the theory of SE and to our country: after the collapse of GOST, modern similar organizations (such as state institutions, including Rosstandart, Roskokachestvo, etc.) are focused on monetization (through certification, technical regulations, etc.), regulation, etc. but not on the development of science and engineering practices, including the SE.

This is all to the questions: standardization, unification, typification, free exchange of best practices. Domestic SE is GOST series 34.xxx and many of 15.xxx and 2.xxx.

The obligation of their execution remained in the past, but at that time it provided a powerful potential, first of all, in the production of military systems (GOST RV 15.xxx and 2.xxx.).
The maximum that is being done now is translations of foreign GOSTs.

Own (domestic) methodological developments in these areas are zero.
Why do we need it today? Although, once our country was a pioneer in these industries, at least in approaches to standardization and unification to the design of complex systems.

That's right - we do not need this, because we have:

a) is full of Western developments - even for the most part and related to alchemy, but this is not essential for monetization;
b) there is also a lot of “oil and gas” that everyone (at least, many) gives enough “bread and circuses”. When there is a lot of “bread and circuses” the developmental stimulus atrophies.

I am convinced that EA and BPM and SE can also be presented and thoroughly formalized as approaches to coding information. And these areas will someday become real scientific and engineering disciplines.

In system engineering, it is very easy to say the right words, and many people have learned to speak them when asked questions on this topic, but as in many sports such as tennis, golf or swimming, doing everything you need is generally difficult. Therefore, system engineers should be judged not by what they say, but because they end up doing and producing. There are many people who talk about a good game, but in fact can not play it.

I would develop the idea further - “system engineers should be judged not by what they say, but” by the result.
And where is the domestic avia, auto - prom, where is the domestic "SE-prom" (development 34.xxx), where is at least something domestic from engineering, system engineering? We are only able to translate "Western alchemy", resell Western "komplektukha" and sculpt systems from it (integrated), which is in IT, that everywhere: 80% of the superjet and modern Lada are imported parts and technologies.

Of course, according to this criterion, it is necessary to judge not only engineers, but also leaders and all citizens (with the tacit consent of which all of this), but here — engineers who are responsible for “big systems” and for domestic “system engineering” - first of all . I didn’t want to talk about politics, but it follows from the quotes from Hamming: “to judge what they ultimately do and produce.” And what really produce? Produce mainly their Western colleagues.

The first rule of system engineering

If you optimize the components, then most likely, the system performance will be corrupted.

The problem with the grounding of a differential analyzer is somehow not entirely obvious to me. It is rather a technical defect.

I would give another example, not very significant, but in a different direction: we remember the old toy - Digger. Played - played, everything was fine.

Then new computers appeared and ... it became impossible to play them, although their architecture was compatible. Due to a significant increase in speed - “poor Digger” was instantly “eaten”: the new system worked very quickly, because it is very "well" optimized computing power of the computer.

Over time, programs like “moderators” appeared for such games, that is, in order to play it was necessary to “hang up the ballast” on performance to compare it with the performance of old machines. Conclusion: sometimes an “anti-optimizer” tablet should be added to the optimizer tablet.

Another example of optimization: some craftsmen forced the engines on production cars. After this, the "axle" (transmission), especially the "grenades" on front-wheel-drive cars, "vomited." Of course, optimization should be complex, taking into account the “weak link” in the overall system (chain).

Although in this case, the event can be conventionally attributed to the "optimization", it is simply an increase in power, in the first case - calculations, in the second torque.

These are examples when the principle does not work: “not to spoil the porridge with butter”: in complex systems it does not always work.

Dental before the exam - a waste of time.

Did not quite understand the criticism. In general, the main purpose of the learning process is training. Training and development of human memory (increasing its RAM), thinking process (computational power of the CPU and DSP brain). Examples of ontologies, conceptual devices. It simply allows an analogy for practical tasks. Tasks are different - approaches to solving the same (system-wide).

Very little (almost nothing) of the studied is applied in practice - this is probably the norm of any training. But this is according to the principle: “it is hard to learn, it is easy in battle”. In an instant, cavalry may become obsolete and be replaced by tanks, but the elements of tactics (defense breakthrough, bypass from the flank) will remain the same.

By the way, the issue of training in domestic universities is often a paradox: losers achieve a brilliant career (go to the tops), and the honors pupils “wipe their pants” with engineers (ordinary employees).

Systems engineering is a process that is difficult to follow, so it’s easy to get lost in the details!

Yes, it is true, but only - for the time being these areas: SE, EA, BPM - are at the level of development of "alchemy". When this becomes a real science and there will be detailed and substantiated (proven) and tested hikes, then it will be “easy to follow,” even to a beginner.

According to the “primer” - I don’t know which one: with the primer SE, EA or BPM (or it all collapses in one direction), it will be possible to build any automated control system or enterprise step by step. Comparison with alchemy relates more clearly to EA and BPM than to SE, SE — after all, it is more advanced compared to them, primarily due to standardization.

Although the SE has already been imposed "paw marketing." The key problem of SE (I repeat) is the absence, as well as for EA and BPM, of published examples of the implementation of SE methodologies (projects).

As a result, if you look at the whole, there are big gaps in learning Mathematics. We practically do not touch (1) an important method of mathematical induction, (2) after a brief mention in connection with quadratic equations in algebra, we almost completely ignore any mention of complex numbers until that fateful day when complex eigenvalues ​​and eigenfunctions appear, and a poor student gets acquainted with two new complex concepts at the same time and, naturally, this confuses him, (3) briefly mentions the useful method of undetermined coefficients, (4) are almost completely ignored, the proof lstva impossibility, (5) is ignored discrete mathematics, (6) no efforts are being made to bring the reflections of students from training examples to important concepts applicable in the real world.

I am sure that similar problems existed in the USSR. On the one hand, Soviet education was famous for its more “integrated approach” (“wide view”) as compared with the highly specialized “western” one. But, on the other hand, this also led to an even greater distance from the "real world."

About modern national education I will say this: right now in the country the emphasis is placed on "concepts applicable in the real world." Only the “real world” in the country is not an industrial era, therefore the concepts of “accounting and marketing” are in fashion.

In the country, “economists and accountants are like non-cut dogs”, schools and universities of marketing, etc. While science and engineering turned out to be on the “curb”, so our satellites “fall like flies,” and nobody even discusses domestic planes, cars, computers, and telephones (doesn't believe).

Does not discuss seriously, i.e. only at the level of marketing, state propaganda (a monstrous mechanism), investment in the "right trough", public relations of individuals and projects, as a rule, private-public.

On engineering specialties, instead of scientific disciplines, frank alchemy is often taught. About teaching alchemy:
“Over time, on the covers of such textbooks and books, the inscription“ Alchemy Manual ”will suddenly appear, and some are already able to discern the still vague outlines of such an inscription. habrahabr.ru/post/345948

That’s why:

... many people know what to say, but not many can actually put it into practice when the time comes to act in the real world. Most of you can not!

It cannot, because future engineers were taught marketing and alchemy. A systems approach, system analysis is an obligatory attribute of any “Concept and strategy” in colorful consultants booklets, but in reality it’s just a “management trick”.

Mentioning about “They had a production line, ...” is about an industrial conveyor, etc. (G. Ford), apparently, has no direct relation to the SE. Although any design is actually the same design pipeline.

Moreover, if it is properly organized, the requirements for competencies and the "creativity" of workers on such a pipeline for the production of "ACS and enterprises" will be significantly reduced, while improving the quality and minimizing the design time.

Flexibility in design provides not only an opportunity to better cope with the changes that will inevitably arise after the installation of the system, but also contributes to your own work in the form of small changes that inevitably occur both in the later design stages and during field tests of the system. I did not understand how much change there could be during the tests, before taking part in the field test of the Nike project on the Kwajalein Islands.

A big mistake in the act of acceptance tests of a large system to make a record: "There are no errors." It is correct to point out: “no errors were found at the testing stage,” because they necessarily are, only they have not yet been found and not eliminated.

Even the presence of the letter E1 and the subsequent letters n (GOST 2.103—2013) for prototypes of the system does not guarantee the absence of errors. Rapid changes in parallel to the design and documentation (Flexibility in design) is the norm in cascade design (although this is for some reason attributed only to “flexible” agile) during construction and during production.

Second rule

Part of the design of system engineering - preparing for changes to get through them successfully and not to reduce the performance of other parts.

This thesis was developed into separate modern directions “Change Management”, “Requirements Management”, in some particular cases, for example, ITIL - “Release Management”, etc.

As I wrote earlier, the half-life of design approaches is 15 years - half of the ideas that you learn now will be useless after 15 years.

Doubtful thesis. Projecting on myself: I was much more given the study of approaches to the development of military systems (ACS) and building GOST and SNIP, which I studied 20 years ago than the modern literature about the same, only in a wrapper "EA \ BPM" and with "marketing chips "," business goals ", etc.

Good technical literature over time becomes less and less, but the main problem - it (the needle) is lost in the "haystack", formed by marketing junk and replicated throughout the Internet. The growing “like a snowball” shaft of marketing and alchemy, unconfirmed by the practice of theories and conjectures, is a modern reality.

Instead, I would like to see the same volume of archive (repository) of real examples, projects, approbations and results of a detailed analysis of the implemented systems using these methodologies and frameworks.

In general, I can hardly imagine how a person who did not read the national GOST standards 34.xxx can understand the content of ISO / IEC on SE: they are very much written “generally” and ambiguously.
If a qualitative theory is developed, then it will be "immortal" and claimed.
Although it can (should) develop, but not with a change of course by 180 degrees.

By the way, at the same time I compared the design stages in the GOSTs at the Automated Control System (24.xxx, 34.xxx) and in the construction (21.xxx) and others (ESKD-ESPD), stages in the ARIS methodology and something else (I don’t remember already). And it all came down to one thing:

1) pre-project (advance design, concept, etc.)
2) draft design, technical project, working draft
3) testing, acceptance, implementation

In different methodologies - different terms, but the essence is surprisingly the same (the classical cascade), including within the specified stages. And regardless of the scale: we build a radio station, tank, building, ACS, enterprise.

This “classic cascade” is actually the basis of the “systems approach” to the design of complex systems.

Interestingly, these very “different methodologies”, in which the same SE principles are indicated, can relate directly to the SE, or to EA and BPM. For example, we discuss the design stages of TOGAF in the comments to Enterprise Architecture vs the alchemy of an enterprise. Part 2. Nowhere is easier: simple framework and simple enterprise.

So why such a zoo methodologies?
We are talking about "serious products", I believe that the use of agile (as an alternative to the cascade), etc. “As a basis” in the development of a tank or an aircraft, a nuclear reactor or systems of the “dead hand” type - no one would ever think.

Third rule

The more precisely you meet the specifications, the worse the performance will be at overload.

This is an element of "optimization". For a departure from optimization - in the direction of "improving reliability", safety margin and performance, etc. - you need to "pay", pay "non-optimization". If we want to have a margin of "strength", including a margin of productivity, then optimization is better not to put priority.

A thinner case makes a product cheaper and lighter, but less impact resistant (with the same material) and protected. Therefore, houses and bridges should be built with a margin of safety.
All optimization is a compromise management. You can save "on matches" and build exactly according to specified requirements, but lose the main quality.

... I believed that small tasks were relatively more important than large ones.

This is a continuation of the thesis "For the trees of the forest do not see the forest" In general, this thesis is one of the main ones in the SE and is often repeated, see, inter alia, the book “Systems Engineering for Dummies” from IBM.

By optimizing "every tree", you can ruin the whole forest. If only because some trees will become very large (“local optimization of individuals”) and will be closed with the shadow of all the others that will destroy them, i.e. “To achieve global optimization of the whole system” will not work.

Westerman, like me, believes that while the client may be aware of some of the symptoms, he may not understand the real reasons for them. And this is silly, trying to cure only the symptoms. Thus, while system engineers should listen to a client, they should also try to extract a deeper understanding of the phenomenon from him. Therefore, the job of a system engineer is to define in a deeper sense what the problem is and how to move from symptoms to real causes.

This resulted in various branches, for example, in ITSM: “Call Management”, “Incident Management”, “Problem Management”, etc. These are methods for linking different consequences (incidents) to one cause (problem).

Causal relationships and the behavior of elements in a complex system are not obvious, and they identify entire directions to identify these relationships, for example, Configuration Management, when through a visual representation (picture) of the relationships of elements, one can get closer to understanding the problem.

Westerman believes that, apparently, the art of systems engineering is best studied in a team that includes both old and new faces. At the same time, he says that more experienced colleagues should be gradually removed from the process and introduce new people to the team. I do not know how to convey my personal experience of the "lone wolf". I can only talk about what I did and how I behaved in certain situations.

And I’m talking about the same thing: it’s enough to publish specific projects on SE, EA, BPM and show where the guides “what and how to do” (standards, frameworks) were taken from and how these same standards and frameworks were applied, what problems arose and how resolved. Just "just tell" and show a specific detailed real or fictional example.

But let me clarify again. Systems engineering should be built on a solid basis of classical simplification to specific problems with a specific solution.

« », (.. , ) .. – SE, , « ».
SE? ISO/IEC 15288
Systems Engineering Body of Knowledge (SEBoK)
( ).

, «» ( ) ( ).

(GOST 2.711-82). In this lies the detailing of the system for the elements: products for individual sub-products - components, which in turn are products (perhaps even products of the “complex system” type, some purchased, etc.).

You go into the office of the chief designer, and he has almost all the 6x3 wall weighs only one "Fission scheme" and with fairly small elements (several hundred). This is to Hamming saying:

Systems engineering is an attempt to always keep the main goals in mind and understand what each local action is done for and how it affects the overall result. However, there is not one particular big picture here.

« », «» «» .

«» — «D.1.3 » «» ISO/IEC 15288, «» 1982 . , «» SE, 2., 34., 15..

, « » — ( ). — () .

, : , — , , , , . , . , , - !

() ERP, .. : « , : . ».

– , SkyNet.

As an example of an in-depth understanding of the system and its problems, I want to consider the project of Nike guided missiles.

I was confident that the dawn of system engineering "there" (USA) and systems engineering "here" (USSR) fell on the period of the Cold War. After the “warming” in our country, it generally died and disappeared as a domestic “Best Practice”, and there it was transformed into a marketing tool (in general, the leader in this nomination is ISO 9000). Apparently nothing mobilizes a person as much as a threat to its survival.

Systems engineering is definitely an exciting profession that is hard to practice.

, – SE. SE , , , «» .

( ) SE : « », (, ) . , : « », , «» — .

SE : « », .

Practicing “in full” system engineering can only be seen in the defense industry, but there is a completely different level of technology used, and the recent slogan “import substitution” (read elementary industrialization) is apparently already buried. Therefore, to talk about post-industrialization is simply ridiculous, we are still (or rather already) in the “pre-industrialization”.

What is SE

Systems engineering – , « 2018» ? «».

SE — . ? , . . . SE , , ( , ? To be « », roadmap №2 framework «1917»).

SE, « ».

SE « » « », () – « ».

As a rule, “detail” and “program” are not included in the category “system”. Something difficult to distinguish in this category is, for example, an “airplane” or a “large program” (ERP), especially as objects like the automated control system and “enterprise” are real “systems”.

Just like the PMBOK, it doesn’t matter what projects to implement on it, and for the SE it’s actually not so important which products of the “system” type to build and implement on it.
Although systems such as "airplane", "ACS" and "enterprise" - should be designed for different branches of the SE (the principle is common, but there is a specificity).

Due to the common design of any automated control systems, there was an association within the framework of one GOST 34.xxx approaches to designing automatic control systems of various classes and simply “automated systems”.

, «» SE, , , , , . , « », .
, - ?
« » , SE. , , «», .

Conclusion

\ , , – « », . . , : ERP, CRM, .. , « » .

, , – - , « ». , («»), , «».

, «»: , , , , « », «» (), , , (, , «»), .

, « », SE, .

SE

, () . – - .. (, ) .

, « ». -, , .. — , « » . , () .

SE , (.. , ), ( , ).

« », — , – , ( ..), .

The ratio of logic: logic from the "paper instruction", sewn into the program of logic (software algorithm) and logic, sewn into the "skull box" of the contractor, determines the "level of automation", "level of formalization", including the "level of detail of the EA description ". SE is aimed at minimizing “creativity” (control of “liberty”) and building well-regulated processes for designing and maintaining complex systems. Clear rules of design and implementation.

If in simple systems all this is not so critical, then in complex, especially critical ones, this is simply a necessary condition. Managing "complexity" requires a clear and simple conceptual apparatus and simple steps to implement the process, no matter how complex the system we have designed.

SE ( ), (BPM). , SE, .

, SE , BPM, , , , . , ( ) 20 , 10 , , 10 .

SE

, . « » « », , SE, , , .

, – ? SE , , .. . , 0,1% . , – « » RFP, — « ».

( ) , , «», . () , ( ), , – . .

( , , , , ) .

« » , «» « : 28. », - , , - «» ( «» , « -»), .

, bipiem