(Ein Architektur-Modell)

Vorbemerkung: Einer meiner praktischen Kollegen sagte mir mal, dass ein Informatiker, der über Architekturen (Anordnungen) schreibt und spricht, einem Kommunisten gleicht, der sich über wirtschaftliche Zusammenhänge auslässt: Oberflächlich und beschränkt. Das mag für den Kommunisten zutreffen. Allgemein stimmt das natürlich nicht. Der Kollege vergisst die wichtige Unterscheidung zwischen Orientierungswissen und Verfügungswissen (PDF 1), die auf Mittelstraß zurückgeht. Das Behandeln von Architektur-Modellen gehört zum Orientierungswissen. Das praktische Operieren in einer Architektur ist dem Verfügungswissen zuzuordnen. Es ist wie beim Wandern im Walde. Derjenige, der Kartenmaterial liest, bereichert sein Orientierungswissen, und derjenige, der munter fürbass schreitet, benutzt das Verfügungswissen über seinen Körper, um weiterzukommen. Beide Wissensarten bedingen sich gegenseitig, stehen aber orthogonal zueinander, d.h., wer sich nur orientiert, kann nicht verfügen, und wer nur verfügt, orientiert sich nicht. Wir stehen erst am Anfang des Themas „PM und IoT“. Also orientieren wir uns zunächst. Mal sehen, wohin dann später die Reise geht.

Es soll hier der Versuch unternommen werden,  die ablauf-organisatorische Welt eines Business Process Management (BPMN) mit den technisch bestimmten Abläufen  im Internet der Ding (IoT)  in einer Architektur zu vereinen. Die Frage entsteht sofort: Geht das überhaupt? Man schaue auf einen Bürobetrieb, in dem Geschäftsmodelle abgearbeitet werden, und auf einen Fabrikbetrieb mit viel Maschinentechnik, Handwerk und Robotik. Mundwerker hier, Handwerker dort (PDF2). Wegen der Heterogenität erkennt man, dass eine Vereinigung nicht trivial sein wird, obwohl beide Betriebe abstrakt gesehen der Ablauforganisation zuzurechnen sind.

1. Transformationale und Reaktive Systeme

In dem sehr bekannten Aufsatz von Harel und Pnueli „On the Development of Reactive Systems“ (PDF 3), der auch im Blog schon ausgiebig zur Debatte stand, wurde eine strikte Trennung von Transformationalen und Reaktiven Systemen jedweder Art vollzogen.

Bild 1: Transformationale und Reaktive System nach Harel/Pnueli (1985)

Wir zitieren aus unserem Blogbeitrag „ Wissenschaft und Wahrheit“:

„Transformationale Systeme, die in der Regel gelehrt werden, sind Input/Output-Systeme. Die Systeme sind algorithmen-orientiert. Während der Transformation können Extra-Informationen verlangt werden. Der Entwickler spricht von einem „Schwarzen Kasten“ (blackbox), in den er dann schrittweise durch Verfeinern Licht bringt. Entwickeln ist so gesehen ein Erhellungsvorgang.“

Und weiter:

„Ein reaktives System behandelt keine Transformation, sondern es versucht, wie Harel und Pnueli treffend sagen, „to maintain a certain ongoing relationship with its environment“. Das müsste doch unsere Umwelt-Politiker auf den Plan rufen. Nicht Algorithmen, sondern die Umgebung eines Systems stehen im Mittelpunkt des Interesses. Die Verbindung (relationship) mit der Umgebung geschieht über Ereignisse, eingehende oder Sensor-Ereignisse und ausgehende Aktor-Ereignisse oder Stellereignisse. Sensoren und Aktoren sind technische Geräte. Die Software-Systementwicklung interessiert sich nur für das Ereignis. Was ist ein Ereignis? Ganz einfach. Ein Ereignis ist der Abschluss eines Geschehnisses (Vorgangs). Wenn das Geschehnis läuft, gibt es noch kein Ereignis. Erst mit einem Abschluss ist das Ereignis da. Das Wunderbare für den Systementwickler ist, dass er sich auf das Ereignis konzentrieren kann. Wie es zustande kam, kann ihm gleichgültig sein. Der Systementwickler abstrahiert, er sieht das Ereignis invariant bezgl. seines Zustandekommens. Da haben wir sie wieder, die in IT-Systemen allgegenwärtige Abstraktion, die wir im Blog ausgiebig behandelt haben. In Bild 1 erkennen wir beim reaktiven System die Ereignisse e1, e2, e3, … als eingehende und ausgehende Pfeile, die wie Dornen aussehen, weshalb Harel und Pnueli nicht mehr von einer „black box“, sondern von einem „black cactus“ sprechen.“

Ganz wichtig in unserem Zusammenhang ist auch der Begriff „Komplex-Ereignis“. Komplex-Ereignisse sind meist logisch zusammengefasste Elementarereignisse. Z.B. kann man Ereignisse vom Typ E = {e₁, e₂,…} mit Ereignissen vom Typ F = {f₁, f₂,…} zu einem Komplexereignis E und F zusammenfassen, d.h., beide, ein e_i und (∧) ein f_j müssen eintreffen, damit  z.B. ein Aktor oder eine Stellgröße in Bewegung gesetzt werden kann. Wenn nur Elementar-Ereignisse e₁, e₂, e₃, … herein prasseln, passiert bei einem Komplex-Ereignis der konjunktiven Art   überhaupt nichts. Erst wenn ein weiteres Elementar-Ereignis  f₁ erscheint, kann ein e₁ ∧ f₁ „gefeuert“ werden, wie man sagt. Beide Ereignisse gelten dann im Ereignis-Management als verbraucht. Die noch nicht verbrauchten oder noch nicht gefeuerten Elementar-Ereignisse stehen in jeweiligen  Warteschlangen, die nach irgendeiner Disziplin, z.B. „first come, first serve“ abgearbeitet werden.

2. Bildung von Architekturen

Systeme in der Praxis sind weder rein tranformational noch rein reaktiv vorzufinden. Eine Straßenbahnfahrt von A nach B wir immer mal wieder z.B. durch unachtsame Fußgänger gestört und der Fahrer muss reagieren. Es gibt Vorkommnisse (incidences). Wir müssten in einem ersten Ansatz beide Systeme in Bild 1 zusammenschieben. Wir erhalten dann Bild 2:

Bild 2:  Ein kompliziertes, zusammengeschobenes „Realsystem“

Was haben wir von einer Annäherung an unsere vertrackte Wirklichkeit, wenn man diese nicht beherrscht? Die Antwort lautet:  Man lässt besser die Finger davon und versucht etwas Anderes. „Try something else“ sagen die Amerikaner ganz nüchtern und unverzagt.

Was uns Harel und Pnueli beigebracht haben, ist doch die Tatsache, dass da zwei Systeme von M existieren. Ein System, dass sich systematisch um den Fortschritt kümmert, wir nennen es M_S, und ein System M_B, das ein Verhältnis zu seiner Umgebung aufbaut, also ein Verhalten (behavior) an den Tag legt (wie der Straßenbahnfahrer, der vor einem Fußgänger stoppt). Das transformationale, systematische System M_S ist ein System des Prozess-Management, und das System M_B (B steht für Behavior), das reaktiv ist, gehört zum IoT, vollgestopft mit Sensoren, ereignisbildend, und Aktoren, ereignisverarbeitend, nebst einem umfangreichen Trigger-System (Event, Condition, Action, ECA), das als Regelwerk aufzufassen ist. Auch im BPMN stehen „rule tasks“ als Aktivitäts-Typen zur Verfügung, um ein Regelsystem gesondert aufzunehmen, was sich auf den System-Entwurf günstig auswirkt, weil Regeln im Änderungsdienst separat verwaltet werden müssen. Denn Regeln ändern sich laufend (man denke nur an Fiskal-Systeme des Staates), Prozesse hingegen selten.

Bei Harel und Pnueli stehen die Entwicklung von M_S und M_B senkrecht zueinander. Von einem Anfangspunkt schreitet man einer Diagonalen folgend zu einem Zielpunkt fort. Das geometrische Gebilde nennen sie dann „magic square“, sehr illustrativ.

Wer systematisch PM-Systeme baut, interessiert sich für ein Ziel, das erreicht werden sollte.  Er will ein M_S bauen.  Vorkommnisse (incidencies) interessieren ihn nur am Rande. Er nimmt sie zur Kenntnis, weil er es muss, aber nur abstrakt als Ereignis. Das Zustandekommen eines Ereignisses (z.B. ein Fußgänger, der auf Bahngeleise stolpert, wieso stolpert der?) ist ihm völlig gleichgültig. Er denkt invariant (unveränderlich) in Bezug auf die Erzeugung oder die Genesis des Ereignisses. So kommen wir dann in Bild 3 zu einer Oben-Unten-Anordnung von M_S und M_B. Das brockt uns das IoT, das Internet der Dinge ein, dass wir alles zusammen sehen müssen, um dann ein „divide et impera“ auszurufen.

Bild 3: M_S und M_B in einer Abstraktionshierarchie

Der systematische Fortschritt in der Prozessverarbeitung M_S verkehrt mit einem  „behavorialen“ System M_B über ein Verarbeitungssystem, das  „Complex Event Processing (CEP) “ genannt wird. Das ist eine beachtliche Erweiterung von dem, was man eine Verarbeitung von Elementar-Ereignissen nennt. Zwischen Ms und M_B stehen nur Ereignisse zur Debatte. Für das behavoriale M_B ist das systematische M_S eine Umgebung, wie alle anderen auch. Und aus der Sicht des  systematischen M_S ist das behavoriale M_B  wie alle anderen technischen Systeme zu betrachten, z.B. wie in PDA dargestellt, die vielen ERP-Systeme.

Was hier umgesetzt wird, ist die Dualität von Vorgang (Prozess) und Ereignis. Im Lexikon von Mittelstraß  lesen wir unter dem Stichwort „Ereignis“:

„Ein Ereignis gilt, in seinem Verlauf betrachtet, als Vorgang, ein Vorgang als Ganzes genommen, als Ereignis.“

Jetzt wird es richtig philosophisch. Und jetzt hören wir auf, dichterisch aber schließen wir   mit Goethe, einem Frauenkenner. Rätselhaft, was er sagt  am Ende von „Faust 2“; aber wenn man sich mit der „Ereignis/ Vorgang-Dualität“  befasst, wird es nach einer Weile verständlich, was der Dichter in seinem Olymp  mit seinen berühmten Versen meinen könnte:

„Alles Vergängliche
Ist nur ein Gleichnis;
Das Unzulängliche,
Hier wird’s Ereignis;
Das Unbeschreibliche,
Hier ist’s getan;
Das Ewig-Weibliche
Zieht uns hinan.