Hans Gert Graebe / Leipziger Gespraeche /
The series of Interdisciplinary Discussions at the Institute of Computer Science of the Leipzig University is supported by the Institute for Applied Computer Science (InfAI), the LIFIS - Leibniz Institute for Interdisciplinary Studies, the MINT-Network Leipzig and the Research Academy Leipzig.
The laws of development of technical systems are a central building block of the TRIZ methodology. In his book "Wings for Icarus" (1980), Altshuller leaves no doubt that the eight development laws formulated there in chapter 6 are laws (закон), and argues why they are significant for reasonable engineering action. Today, researchers are no longer so convinced of the significance of these findings and distinguish between laws (закон), regularities (закономерность), trends (тренд), tendencies (тенденция) and development lines (линия развития).
Is such a distinction due to a conceptual confusion resulting from the transfer of the concept of law from scientific methodology to the methodology of engineering action, or is it after all an essential modification of early theoretical approaches of Altshuller? M.S. Rubin (2018) emphasizes that "the fundamental difference between development laws and trends" – which he defines as "the main tendency of a change" – "is obvious and these terms should be clearly distinguished". V.M. Petrov (2020) would rather distinguish laws and regularities, A.L. Lyubomirsky and S.S. Litvin (2018) speak basically about trends, Koltze/Souchkov (2017) distinguish 5 laws and 10 development lines, in Souchkov's TRIZ Glossary v. 1.2 only trends are mentioned.
On the other hand, it is clear that it is wise not to wipe these experiences of human action off the table and to take them into account when planning own actions, even if these laws are not "proven" with the authority of scientific rigor. Especially since that rigor is itself under scrutiny at the latest with T.S. Kuhn's "Structure of Scientific Revolutions".
In our interdisciplinary discussion we want to get to the basics of this conceptual confusion and want better to understand,
Hans-Gert Gräbe, Jan 4, 2021
The TRIZ methodology can be applied not only to technical systems, but also to more general systems, including the TRIZ methodology system itself.
Solve the following task:
Investigate whether this system is contradictory and, if so, solve the contradiction using the TRIZ methodology.
The following solution is proposed:
The contexts (KA) and (KB) thus need to be specified more precisely, especially with regard to their difference concerning socially stabilising justification processes. This is now simple:
We made already clear in the announcement for our Interdisciplinary Discussion that we wanted to focus less on the validity of one or another law of development of technical systems that are formulated and prioritised in the TRIZ body of knowledge in one way or another, but rather better to understand what is the position of such a complex of statements in the TRIZ theory corpus and how this position can be justified in more detail.
This was the topic already of our seminar in the winter semester, in which we studied approaches of different TRIZ schools to laws of development in more detail. We had already noticed differences in the notion of "law" in particular within science itself – for example between mathematicians and physicians. Nadine Schumann addressed this topic in her presentation in more detail.
However, the main discussion focused once again (after our seminar in the winter semester 2019/20) on the fundamental question of which concept of system (in the singular or in the plural) should be used when arguing about the laws of development of technical and "non-technical" systems. "Non-technical" is put here in quotes, since for modern managemental, cultural, economic and socio-ecological systems it is the aim to be controlled using similar engineering-technical principles, in which a reality check takes place in feedback loops between "reasonable" modelling as description form and practical realisation as execution form.
We started with the presentation by Nikolay Shpakovsky, who diagnosed a hierarchy of system terms already in TRIZ theory itself – a clear distinction should be made between
The question of increasing complexity can be studied particularly well in the software field, which was the focus of the presentations by Hans-Gert Gräbe and Stelian Brad. In the last 50 years, the levels at which abstraction, modelling and programming have taken place has changed several times in this field. In the 1970s, punched card and tape systems with direct addressing of memory operations and processor-specific assembly languages were still widespread. The problem of excessive complexity that arose there was solved by the introduction of programming languages at a higher level of abstraction, which required three essential conceptual ingredients:
These standardisations in the use of computer language tools are the result of an extensive process of exchange and discussion by an open source community whose roots go back to the 1980s. Open source is important here not for ideological reasons, but for purely functional ones – the experiences of others have to be studied, evaluated and generalised to put the puzzle together. The development needs are inherently collaborative in nature, and the exclusions and delimitations associated with secrecy and IPR have a completely counterproductive effect. After 2000, these engineering requirements had spread into management circles, and Henry Chesbrough is credited "inventing" in 2003 the term "open innovation" with the title of his book of the same name. However, the attempt to transfer this cultural paradigm to the culturally completely different entrepreneurial "world" has not really succeeded so far, as the rapidly changing concepts of Innovation 2.0 to 4.0 (Stelian Brad, slide 16) show.
That world of common programming standards, however, has led to a new world of confusion after 2000 – is it worth writing every programme from the scratch or are there options for re-using what already exists? The new confusion was not only about finding out what already exists, but also about how easy it is to put things together that were originally not intended to work together. This problem of software component architectures and ways to solve it were addressed by Hans-Gert Gräbe in his presentation. He discussed ways of shaping component worlds that are build up around special composition concepts (CORBA was discussed as an example), but did not address the fact that this way the world of programmers is further parcelled out in the process. Whereas before the worlds of components were divided along the different programming languages that ceased components not to be compatible with each other, now it is the worlds of different platform concepts within one and the same programming language. Height of abstraction and thus mastery of a higher degree of complexity is achieved through specialisation – not through domain-centred specialisation, but through further specialisation and refinement of concepts and tools.
With the .NET concept, there are now weighty approaches to bring these worlds, which are drifting apart, closer together again. The description of associated management and process experiences is increasingly drawing on the concept of a (technical, energetic, software-technical, etc.) ecosystem. This is where the vision of a "culture of polycentric agile strategic alliances" (Stelian Brad, slide 17) meets the "triumph of anarchism" and the "death of copyright", as Eben Moglen predicted already in 1999.
Hans-Gert Gräbe, 11.02.2021