Das Wissensportal für IT-Professionals. Entdecke die Tiefe und Breite unseres IT-Contents in exklusiven Themenchannels und Magazinmarken.

SIGS DATACOM GmbH

Lindlaustraße 2c, 53842 Troisdorf

Tel: +49 (0)2241/2341-100

kundenservice@sigs-datacom.de

Der Foerster und die Softwarearchitektur

Moderne Softwarearchitekturen benötigen ein gutes Verständnis für die Kommunikationsprozesse in sozialen Systemen. Eine Erklärung und praktische Perspektive darauf liefert ein Konzept des Physikers Heinz von Foerster.
Author Image
Gerrit Beine

Author


  • 29.10.2021
  • Lesezeit: 5 Minuten
  • 79 Views

Bei der Entwicklung von Softwarearchitekturen, insbesondere für große fachliche Problemstellungen, hat es sich bewährt, eine Zerlegung in fachliche Bausteine vorzunehmen. Methodische Ansätze wie Domain-Driven Design verfolgen diesen Weg sehr stringent und projizieren die fachlichen Domänen als Bounded Contexts in die Softwarearchitektur. Das Ergebnis sind in vielen Fällen Architekturstile wie Microservices oder Self-Contained Systems. Diese Herangehensweise hat für die Entwicklung von Software immense Vorteile, insbesondere in Hinblick auf Flexibilität, Verständlichkeit und die Möglichkeit, das Verhalten der Software zu testen.

Triviale Maschinen programmieren

Solche Architekturstile basieren auf zwei fundamentalen Prinzipien: Sie gehen von einer fachlichen Zerlegung aus und sie erzeugen eine technische Lösung, bei der jedes einzelne Teilsystem fachlich zustandslos und damit idempotent ist – die gleiche Anfrage erzeugt immer die gleiche Reaktion des Teilsystems. Solche Systeme, die über keinen inneren Zustand verfügen, hat Heinz von Foerster als triviale Maschinen bezeichnet. Solche trivialen Maschinen können formal als Funktion beschrieben werden wie in Abbildung 1 dargestellt. Technologisch ist das nicht ganz so einfach. Die Teilsysteme der Software haben zwar keinen fachlichen Zustand, werden aber mithilfe von Frameworks, Bibliotheken und anderen technischen Bausteinen erzeugt. Während der Ausführung der Software sind diese Bausteine zustandsbehaftet. Beispiele dafür sind die Prüfung von Autorisierungen oder die Anwendung bestimmter Konfigurationen. Diese Zustandsabhängigkeit lässt sich von den Softwarekomponenten bis in die Hardware auf allen Ebenen nachvollziehen.

Abb. 1: Bei der trivialen Maschine führt ein konkreter Eingabewert x immer zum gleichen Ausgabewert y

Pfadabhängigkeit in Entscheidungsräumen

Fachliche Prozesse, wie sie in den meisten Organisationen existieren, basieren darauf, dass während ihres Verlaufs verschiedene Entscheidungen über den Gegenstand des Prozesses getroffen werden. Dieser Gegenstand kann beispielsweise der Antrag auf einen Passierschein sein, der von verschiedenen Fachabteilungen geprüft wird, bevor es zu einer finalen Entscheidung kommt. In einem solchen Prozess befinden sich die beteiligten Fachabteilungen in einem Entscheidungsraum.

Der Entscheidungsraum einer Fachabteilung wird durch eine Vielzahl von Faktoren beeinflusst. Zum einen ist da der persönliche Ermessensspielraum, den Organisationen zugestehen müssen, um überhaupt handlungsfähig zu sein, zum anderen gibt es natürlich einen formalen Entscheidungsrahmen, den die Organisation ihren Abteilungen vorgibt. Dazu kommen dann Ereignisse von außen, die dazu führen, dass eine Fachabteilung beginnt, ihre Entscheidungen anders zu treffen.

Daraus entsteht eine Vielzahl an Kombinationsmöglichkeiten und es kann passieren, dass zwei identisch ausgefüllte Anträge zu unterschiedlichen Entscheidungen führen, insbesondere in Grenzfällen. Der Zustand des einzelnen Antrags am Ende des Prozesses hängt also nicht nur von den eingegebenen Werten ab, sondern auch noch von anderen Faktoren. In der Organisationstheorie wird das als Pfadabhängigkeit bezeichnet. Pfadabhängigkeit bedeutet hier, dass das Ergebnis eines Prozesses nicht nur von den Daten abhängt, die in den Prozess hineingehen, sondern auch von den Zuständen der verarbeitenden Einheiten. Heinz von Foerster bezeichnet solche Einheiten als nicht-triviale Maschinen.

Die einfachste nicht-triviale Maschine nach Heinz von Foerster besteht aus einem veränderlichen Zustand sowie zwei Funktionen. Beide Funktionen der nicht-trivialen Maschine hängen vom Eingabewert und dem Zustand der Maschine ab. Abbildung 2 veranschaulicht den Aufbau einer solchen nicht-trivialen Maschine und ihre möglichen Reaktionen auf Eingabewerte. Es wird klar, dass jeder Computer in diesem Sinne eine nicht-triviale Maschine ist. Die oben genannten Softwarearchitekturen sind also Wege, eine triviale Maschine durch die Kombination nicht-trivialer Maschinen zu simulieren.

Abb. 2: Bei nicht-trivialen Maschine hängt der Ausgabewert y nicht nur vom Eingabewert x, sondern zusätzlich noch vom inneren Zustand z ab. Dieser Zustand ist veränderlich, sodass die Ergebnisse der nicht-trivialen Maschine eine Pfadabhängigkeit aufweisen, die durch eine zweite Funktion beschrieben wird

Kommunikation und nicht-triviale Maschinen

Der moderne Ansatz, Software beherrschbar zu machen, besteht darin, sie möglichst als triviale Maschinen zu implementieren. Damit folgt die Softwarearchitektur dem Ideal des EVA-Prinzips. Nach Heinz von Foerster wäre alles andere auch Unsinn, da der Versuch, die Wirkungs- und Zustandsfunktion durch testen zu ermitteln, transcomputational ist, also praktisch nicht analytisch zu ermitteln.

Organisationale Prozesse sind aber als Teil von Organisationen nicht-triviale Maschinen. Diese aus trivialen Maschinen zu konstruieren, ist die Leistung von Softwarearchitektur. Die Herausforderung dabei ist, dass es keinen analytischen Weg gibt, nicht-triviale Maschinen durch Versuchsreihen von Tests von außen zu verstehen. Es ist praktisch nicht möglich, durch Kombination von Eingabewerten und die Beobachtung der Ausgabewerte darauf zu schließen, welche Operationen im Inneren der Maschine – eben der Organisation – ausgeführt werden. Da der analytische Weg praktisch ausgeschlossen ist, bleibt nur der, über Heuristiken anforderungsgerechte Softwarearchitekturen zu entwickeln. Basis dieser Heuristiken ist eine Beobachtung der Kommunikationsereignisse in der Organisation, um diese nachzuvollziehen. Die Kommunikation in einer Organisation ist Erzeugerin, Ergebnis und Abbild der Eingabewerte und Zustände, die in und zwischen den nicht-trivialen Maschinen, aus denen diese Organisation besteht, auftreten.

Auf dieser Grundlage lässt sich die Kommunikation zwischen den Architekturbausteinen der Software entwerfen und die beobachteten Zustände aus den Organisationseinheiten als Teil dieser Kommunikation implementieren.
Es leuchtet ein, dass Softwaresysteme, die diesen Weg gehen, Kriterien wie Wartbarkeit und Adaptierbarkeit in der Zukunft gut erfüllen können. Denn die Nichtvorhersagbarkeit der nicht-trivialen Maschine macht die Adaptierbarkeit für die Zukunft zwingend notwendig. Der Preis dafür ist, dass die Architektinnen und Architekten dieser Softwaresysteme Expertise darin aufbauen müssen, wie Kommunikation in sozialen Systemen funktioniert.

Weitere Informationen

[Sim06] F. B. Simon, Einführung in Systemtheorie und Konstruktivismus, Carl Auer Verlag, 2006

. . .

Author Image

Gerrit Beine

Author
Zu Inhalten
Gerrit Beine ist Trainer und Berater bei INNOQ. Er arbeitet am liebsten an der Schnittstelle zwischen Softwarearchitekturen und Organisationen und verbindet Informatik mit Soziologie und Organisationsforschung.

Artikel teilen

Nächster Artikel
Fonts & Co.