# Chat of the 17. Interdisciplinary discussion With comments by Hans-Gert Gräbe (HGG) ## Presentation of Nikolay Shpakovsky The notion of a system was introduced as modeling a problem ("mental image") of different complexity * as assembled device * as tool processing an object (SAO model, funtional model) * as potentially workable system * as system for a certain goal * as product producing system * as harmful system of Lenyashin [10:47] Kleemann : how can the approach of the x-factor grasp notions of development of a system? (relates to slide 36) HGG: The system has to be completed (law of completeness of the components of a TS), so development is completion of an incomplete system. [10:49] Igor Zadesenets : The question is what is directly? [10:50] Kirill Domkin : What is the difference between Engine and Energy Source? HGG: Energy source provides energy, engine transforms energy into useful energy. [10:52] Alexander Solodkin : let me ask verbally please. I have some doubt about introducing the product term. HGG: This remained unclear, but relates to my presentation. If the tool (or component) is considered completely functional and (only) the object carries state, then the "product" is the transformed object, i.e. the object now carrying a special state. The idea here is as in market terminology - the product is an object with special use value, we forget about the production of the use value (the way of production is abstracted in the exchange value, at least in an economic labour value theory). [11:00] Immanuel Thoke : @Kirill as I see it the Energy Source is the Input for the Engine to produce the output as the input for the transmission. [11:18] Andrey Trostyanskiy : Can the harmful system make a useful effect? HGG: As far as I understand TRIZ has no notion of life cycle of a technical system. This relates to the phase of maintenance and repair of a technical system already in use, the task is to transform it from a state with harm to a state without (that) harm. [11:19] Immanuel Thoke : states define a property of a system itself, whereas a product describes the outer view between given input and specific output, of course this state is achieved due to a certain input, but it doesn't describe how requirements have been matched by the system. [11:22] Stelian Brad : I would like to add something HGG: Another question was about the IFR. Alexander explained that this idea is similar to the idea of absolute truth and hence only useful in a very special mental setting. In a theory of adaptive systems this makes no sense. Stelian explained that this concept is also present in a slightly different meaning as "desirable state" in the systems notion of Russell Ackoff. [11:25] Immanuel Thoke : shouldn't we distinguish between ideal and realistic goals and absolute and relative goals? [11:40] Immanuel Thoke : ok what Alexander Solodkin said is very interesting. Yesterday I thought about following: Oneself cannot control itself, but it can control itselfs in perspective of different contradictory components with different ideal goals towards optimization between the parametric contradictions. [11:41] Igor Zadesenets : 1. Different IFR from different perspectives can be set. 2. IFR is only the tool for finding achievable results. ## Presentation of Nadine Schumann The main point was a distinction between different notions of law: * in the strict sense (pure causality as in Newton's mechanics) * scientific laws (statements based on repeated experiments or observations) * laws directly of incirectly based on empirical evidence Laws of development are of the third kind, based on heuristical principles as the foundation of interpretation. This was related to Wundt's account on psychical causality. Then the question of Trends of Development and Evolution of Technical Systems was discussed. The notion of evolution has a restricted meaning according to its historically biological origin and may be not appropriate in the context of technical systems. [12:17] Siegfried Weigert (ibw) : What is Law (In this context here): An "Item" that "always has been there" like mathematical/physical "laws" OR "A set of rules that has been defined by "lawyers"". HGG: That's an interesting question not discussed by Nadine. As far as I understood for her "law" has "always been there" but even "been there" has a multitude of interpretations (the notion of law differs even between mathematics and physics). The "lawyers' laws" as written rules are only a specific form of processual institutionalisations, many of the more genarl ones are informal but nevertheless binding, e.g. the "state of the art", in the sense that no one expects that you do _not_ follow these rules. If you do not follow the rules you have at least inconvenience in cooperation and may be socially punished in the worst case. This institutionalisation transforms practically proven to proven practices that get social binding quality. [12:22] Stelian Brad : I would like to have a comment Stelian just drawed on that distinction. The notion of law applies to two different settings: 1. describe how something evolves in an organic manner (descriptive) 2. laws as regulations to fight complexity (activity centered) [12:22] Kleemann : does that mean you have to start with a "product" and the circumstances? [12:24] Alexander Solodkin : I'd like to comment as well :) After Stelian :) Alexander emphasises that for the notion of law predictability is important and distinguishes laws from phantoms. [12:28] graebe : Some more questions: @Nadine: What is a lifeline of a system? @Stelian: What is a system that meets decisions? HGG: Lifelines I found first in (Altschuller 1979) but for me it remains mysterious until now what are the constitution principles that are used to line up technical systems in such lines. (TESE 2018) draws on "pragmatic S-curves" and it seems obviuos for me that they are drawn from commercial product catalogues, as explained in (Gräbe 2020a). Biological evolution is usually drwan in "evolution trees" and such a concept is presented also in (Shpakovsky 2010) for "technology evolution". But "technology evolution" and evolution of technical systems seem to be quite different topics. HGG: Stelian focused on the point that (management) systems are related to people and decision meeting processes. This aspect is, in my opinion, underestimated even in modern Business TRIZ concepts. In (Gräbe 2020b) I proposed to make a difference between systems for decision preparation and systems for decision meeting. They have very different characteristics as convergent an d divergent thinking (according to Guildord) have. [12:35] graebe : @Alexander: What is "human"? The individual or the mankind? Or something between (we call it cooperative action)? [12:35] Immanuel Thoke : what is meant by "exact"? What do mathematicians mean if they say "nearly ever"? [12:39] graebe : @Nadine: So this notion of "human" is as by Vernadsky - Scientific thought as planetary phenomenon? HGG: Nadine in her answer did not address the question about "lifelines" but the question "what is human". [12:40] Kleemann : it seems to me, that the problem that Nadine touched is the construction of dynamics and not of structures. Do you mean that this view of development has to be revised? [12:53] Ulrich Fritsche : = feature, property [12:56] Kleemann : then the question arises: can you model a pragmatic s-curve, which is non-linear. Is there more than one pragmatic s-curve possible? [12:57] graebe : I proposed a branching of the "s-curve" at its phase 3 in (Gräbe 2020a). [12:59] Immanuel Thoke : a classic approach would be geometric or physical linearization and representation of error rates in probabilites of these uncertainties. [13:01] Kleemann : @thoke: then you have the problem of linearity again. Maybe other mathematical or logical approaches, as fuzzy logic or patterns in chaotic processes. [13:09] Immanuel Thoke : yeah triz approach is again separation in time and space .. relying on quasi-stable phases where minor instabilities can be controlled by a dominating protocol. [13:10] Alexander Solodkin : may I add something? Alexander emphasises that development is not so easy in a biased world where you have to manage also dissent. He several times emphasises the management concepts realised within Toyota as a concept centered system of processes. Moreover he emphasises that the managerial style strongly depends on the context, in particular is different in stable and unstable times. For this point see also (Mann 2019). [13:13] Immanuel Thoke : that refers to the term of exacteness and scalability. [13:14] graebe : There is a good rule in open source: Raw consensus and running code. [13:21] Immanuel Thoke : (polemic question) so we handle the black spot i.e. in realization of climate change not knowing how to fix the system in time because it does not meet the actual requirements of the states, companies and people and hoping for better technologies in future that will fix this in time or rely on adaption of changing environment? HGG: As I understand it this is - roughly - the core of the program developed in (Shchedrovitsky 1981). Stelian: This is a difficult question since the particular circumstances and decisions influence many other particular circumstances. This requires to work and concentrate efforts on the non-technical conceptional frontier to stabilise the macrosystem. [13:28] Immanuel Thoke : yeah but we have also corona .. have you also experienced the quick change between cold and warm phases? [13:31] Immanuel Thoke : thanks for the vivid discussion so far ## Presentation by Hans-Gert Gräbe The presentation focused on developments in the area of software engineering that deeply changed during the last 15 years from a "programming from the scratch" to a component oriented production style. If 15 years ago the knowledge of a programming language was enough to produce valuable code nowadays additionally the knowledge of a framework (consisting of both a "glue code concept" and a wealth of available components) is required to be productive in coding. Within that development also new professions came up - the profession of a software architect (engineering platforms), a component developer (providing coding within a platform) and a component assembler (assembling larger systems from components). Such "larger systems" accompany "larger technical systems", and both are unique specimen as explained in (Gräbe 2020a) and - differently to components - not designed for direct reuse. Technological development thus moves from direct reuse of components to higher forms of abstraction and modeling. Such questions are not at all addressed in the traditional TRIZ theory about laws of evolution of technical systems. Stelian: Software systems are the highest complex systems and the most invisible systems. HGG: There are many concepts within software engineering to address this complexity, e.g. [ITIL](https://en.wikipedia.org/wiki/ITIL) or [SAM](https://en.wikipedia.org/wiki/Strategic_alignment). [14:14] Kleemann : can such a design be used for a non-linear s-curve approach. [14:22] Kleemann : structure to graph. interesting [14:35] Nadine : TRIZ is open enough to model that. this is the big advantage of the TRIZ method, or? it guarantees the flexibility of the Supersystem. [14:39] Igor Zadesenets : Question for Nikolay. What is the fundamental difference between Engine, transmission and so on and Control? May be they all are Control? HGG: In my opinion this chain is an expression of the "law of energy conductivity through the system", that can be rooted in the theory of dissipative systems. This theory claims that energy throughput through a system strongly relates to the structures within the system (as, e.g. for the Bénard cell). Hence energy dissipation within a system is required for both the supply of the required energy throughput for the components and the energy required to regenerate the functional structure of the system itself. [14:41] Immanuel Thoke : so chaos also arises from not knowing at which abstraction level causes a problem as an engineer with no transparent insight and sufficient debugging infrastructure have to deconstruct each level of abstraction to determine the error. HGG: If you take the Theory of Dynamical Systems and the notion of attactor as a generalisation of the notion of equilibrium, you have the notion of "deterministic chaos", i.e. attractors of systems described by relatively simple deterministic equations that have themselves complicated structure, even up to fractal buildings (strange attractors). So this is not necessarily a problem of not enough insight. [14:44] Igor Zadesenets : OK. And what is the fundamental difference between process and component? HGG: Whats about such an explanation? A component is a black box view on a process. [14:48] Immanuel Thoke : but it's hard to determine sideeffects in python due to unstrict typing especially if you use libraries you do not know. [14:50] Kleemann : in this cocept means modelling not directly using a model? [14:53] Nadine : Thats the concept of pragmatic information, or? in contrast to syntactic and semantic concepts of information. ## Presentation of Stelian Brad From the presentations: Innovation is more than an invention, it is not only a technical phenomenon but has to address the needs of a target group: Innovation ... a nonlinear, multiple-looped and agile process through which a novel idea is generated and then embedded into an elaborated viable solution that addresses a need of a given target group in a way that fits the group’s culture; thus, being wanted, affordable, valued-for-money and adopted. Systems have to be maintained, this may be very challenging due to * complexity - the behavior at the layer between deterministic and chaos, with high nonlinearity, where small changes in the value of some parameters lead to radical unexpected evolutions. * complicatedness - a system with intricately combined and involved parts such that it is very difficult to understand or analyze * dynamicity - a state of being in perpetual change, which makes dataset difficult to keep accurate. * abundance - a state of oversufficient quantity, thanks to technology (e.g. abundance in communications) Three concepts are important to conceptualize maintenance: * entropy → a state of disorder, uncertainty, randomness in the system, the level of possible combinations of the parts in the system. * equipotentiality → apparent capacity of any intact part of the system to carry out functions which are lost by the destructed parts. * equilibrium → state of balance relative to the forces acting in the system. These points were discussed on the current state of software development. [15:10] graebe : In Rubin's work I have found the concept of system capture several times. What role does this play in an environment with many systems? [15:14] graebe : Interactions (one-to-one) increase only quadratically, exponentially increases the number of relations = subsets of the set. HGG: This relates to slide 4. Exponential growth is a pure theoretical phenomenon, describing "natural" growth (y'(t)=c*y(t)) without limiting factor. Adding a limiting factor you get e.g. a logistic curve. For growth of networks the phenomenon of scale free networks was observed that develop not exponentially but following a power law. [15:15] Immanuel Thoke : does complexity increases unboundedly if we swap paradigms or does complexity patterns change? [15:18] graebe : In the theory of Dynamical Systems there is a notion of Steady state Equilibrium (that can move in space). How it relates to the 3 e on the slide? [15:23] graebe : Machine tool building vs. industrial plant engineering. HGG: It is one of the main observations from a practical point of view: the main task for recent software engineering is to organise digital support for already existing business processes. Digitization requires to "make things explicit" that existed so far in a less explicit form, so the hardware and software modeling has to be accompanied by an "orgware modeling" (a concept introduced by K. Fuchs-Kittowski, see (KFK 2020), in German). This has much to do with modeling and not so much with innovation, but within modeling formerly unnoticed contradictions (and unformalized implicit workarounds, the "social soft") pop up. This is the today business of semantic modeling, data analysts, business process modeling, organisational modeling, software architects and component assembler. As the design of large technical systems (plants) is unique since the Production management systems differ significantly even within the same company (we observed that for BMW), IT systems are unique specimen, too. From such a point of view the challenges to software engineering look quite different and it is just that view that is addressed in Szyperski's book (see my presentation). May the "software paradoxes" (slide 7) result from such a difference in viewing the topic? "See the growing popularity of Python or ROS (Robot Operating System) – huge libraries" (slide 9) - Python or ROS are very different things. If you look at the .NET framework then ROS is similar to the CLR, the "virtual machine" supplied by the Common Language Runtime required to integrate all components, written in different languages (e.g. in Python). But for different languages to work together the CLI (Common Language Infrastructure) is required. [15:31] Immanuel Thoke : in TRIZ there is a non-invasive alternative to the invasive intonation of breakthrough but this might be subjective as I see the examples - turning something inside out in order to move to abstraction level of the supersystem and integrate it in the system. [15:33] graebe : What's about "coopetition" (in German "Kooperenz" )? This notion was coined in discussions already 15 years ago. "Raw consensus and running code" is just about that. HGG: In the discussion the notion of "software ecosystem" played a significant role "defined as a set of businesses functioning as a unit and interacting with a shared market for software and services, together with relationships among them. These relationships are frequently underpinned by a common technological platform and operate through the exchange of information, resources, and artifacts." https://en.wikipedia.org/wiki/Software_ecosystem Such a "technical platform" is not a static thing but has to develop, serve the needs of the users of the platform, and has to be operated. It was just that topic explained in my presentation on the example of CORBA. Open Source movement developed such a platform with git, github, gitlab, CI (continuous integration), git development models etc. [15:37] graebe : But the Microsoft position depends on its internal development from the "Halloween Papers" 1998 to Open Sourcing .NET and the "Dotnet Foundation". [15:46] Immanuel Thoke : supply chain management often relys on coopetition - cooperation on infrastructure, competition on market prices [15:48] Alexander Solodkin : may I comment? HGG: Alexander emphasised that complexity requires cooperative actions and mentioned the work of Rapoport - I found (Rapoport 1977) - on that topic. Cooperative action played also an important role in our lecture for the students during the semester, but we emphasised on the importance of the interrelation of cooperative acton and common conceptual world. [15:57] Immanuel Thoke : referring back to climate change .. a breakthrough would be to see the ecosystem as a inner property of infrastructure of economic systems and marketing products not as a companies property but as a product of ecological process this may sounds trivial but household calculations works the other way around. [15:58] Igor Zadesenets : May I comment? HGG: Igor mentioned that we much deviated from the original topic and asked what's about the TRIZ laws of development of technical systems themselves. What is the state of art, what is their benefit etc. I commented that in two small writings. * http://mint-leipzig.de/2021-02-05/Laws.pdf * http://mint-leipzig.de/2021-02-05/Laws-State.pdf ## References * (Altschuller 1979) Genrich S. Altshuller. Creativity as an exact science. * (KFK 2020) Klaus Fuchs-Kittowski. Informationssystem-, Arbeits- und Organisationsgestaltung in Produktion und Verkehr – das Orgware-Konzept, die Paradoxie der Sicherheit, des Wächters, der Beherrschung großer Datenmengen. https://www.informatik.uni-leipzig.de/~graebe/Texte/Fuchs-20.pdf * (Gräbe 2020a) Hans-Gert Gräbe. Human and their technical systems. In Proceedings of the TRIZ Future Conference 2020, p. 399-410. https://hg-graebe.de/EigeneTexte/mts-20-en.pdf * (Gräbe 2020b) Hans-Gert Gräbe. TRIZ and Systemic Transitions. Submitted to TRIZ Reviews. https://hg-graebe.de/EigeneTexte/sys-20-en.pdf * (TESE 2018) Alexander Lyubomirskiy, Simon Litvin et al. Trends of Engineering System Evolution. ISBN 978-3-00-059846-3 * (Mann 2019) Darrell Mann. Systematic innovation in complex environments. In: Online Proceedings of the TRIZ Summit 2019 Minsk. https://triz-summit.ru/confer/tds-2019/articles/reports/ * (Rapoport 1977) A. Rapoport, O. Frenkel, J. Perner. Experiments with cooperative 2×2 games. Theor Decis 8, 67–92. https://doi.org/10.1007/BF00133087 * (Shchedrovitsky 1981) Georgi P. Shchedrovitsky. Principles and General Scheme of the Methodological Organization of System-Structural Research and Development. https://wumm-project.github.io/Texts/Principles-1981-en.pdf * (Shpakovsky 2010) Nikolay Shpakovsky. Tree of Technology Evolution. Forum, Moscow.