1) Einführung
So um 1960 haben wir noch kräftig programmiert, in FORTRAN und kaufmännisch in Cobol. Das klingt antik, war es auch. Was wir da taten, nannte man später Spaghetti- Programmieren. Wir produzierten Programmcodes, die wir nach einer gewissen Zeit selber nicht mehr verstanden. Das waren Jugendsünden. Es war aus dem Bauch heraus programmiert. Eine Besserung trat erst ein, als 1970 Dijkstras „On structured programming“ erschien. Sein weltberühmter Beitrag 1968 „Go To considered harmful“ (später ein bekannter Slogan) war dem 70-er Aufsatz vorangegangen. Das wilde Herumspringen in Programmen wurde verboten. Das soll man nicht mehr tun. Es gab also zum ersten Mal in der Programmierung ein „Nicht-Sollen“. Zum ersten Mal trat in der Programmierung somit eine ethische Komponente in Erscheinung, weil von einem Nicht-Sollen (Verbot) gesprochen wurde. Im englischen Wort für „sollen“, also für „should“ ist das deutsche Wort „Schuld“ direkt herauszuhören. „You should do it“ heißt somit auf Deutsch „Du schuldest, das zu tun“ oder in unserem Falle „ Du schuldest, strukturiert zu programmieren“. Wenn du das nicht tust, dann lädst Du eine Technische Schuld auf Dich“. Technische Schuld ist das Messen am technisch „Gesollten“. Heute wird der Begriff häufig leider nur mit Software in Verbindung gebracht.
2) „Technische Schuld“ im Sturm der Digitalisierung
Was vor 60 Jahren geschah, wird wahrscheinlich wieder geschehen, wenn nicht gegengesteuert wird. Die bange Frage lautet: „Werden wir eine Spaghetti-Digitalisierung bekommen?“, d.h., hier ein bisschen und dort ein bisschen herum digitalisieren, und das dann stolz der Bevölkerung vorzeigen, um Beifall zu erheischen. Das taten wir früher auch mit unserer „Spaghetti- Mahlzeiten“, die sogar im ersten Augenblick schmeckten, wie alle Sünden das tun. Die Gefahr besteht, dass man 2035 von Digitalisierungssünden sprechen wird.
Verlangt wird eine methodische Digitalisierung mit Struktur ganz im Sinne Dijkstras, der sich auch tief mit dem Begriff der Nachhaltigkeit (sustainability) auseinander gesetzt hat. Mit Dijkstras „The next fifty years in computing“ werden wir uns wieder der Wichtigkeit des Begriffs „Nachhaltigkeit“ bewusst, wenn wir an die Aufgabe unserer Lehrer (educators) denken, die Schüler mit Lehrprogrammen ausbilden, die noch in 50 Jahren berufstätig sein können, wenn wir alle jetzt Erwachsenen nicht mehr sind. „In fifty years we all are dead“ hat John Maynard Keynes einmal gesagt. Wir sind besorgt, weil wir nicht umhin können, „in tiefster Seele kollektiv zu fühlen“, wie der Philosoph Karl Jasper (1883 – 1996) das im Zusammenhang mit der verwandten Politischen Schuld formulierte.
Wir leben nicht in Einzeldigitalisierungen z.B. im Fahrkartenwesen, sondern in ganzen Prozessen. Mahnend tritt uns der Amerikanische Qualitäts-Ingenieur Eduard Deming (1900- 1993) gegenüber, wenn er sagt: „If you can’t describe what you are doing as a process, you don’t know what you are doing“. Es muss in Zusammenhängen gedacht werden, lautet die Forderung Demings.
Prozesse sind hochkomplexe Abläufe in Organisationen, die man aus verschiedenen Aspekten betrachten kann. Z.B. ist der technische Aspekt der Mittelbereitstellung völlig unterschiedlich vom fachlichen Aspekt der Ziel-Erreichung. Der technische Aspekt betrifft die IT-Abteilung und der fachliche Aspekt die Fachabteilungen. Eine Vermengung ist unzulässig und führt zu Spaghetti-Prozessen als Sündenfall für die Nachwelt. Und wieder hilft uns Dijkstra weiter mit seinem Begriff „separation of concern“, oder auf Deutsch, die „Trennung von Anforderungen“. Bloß nicht alles gleichzeitig sehen, sondern trennen, was auch schon im Blog ausgiebig beschrieben wird. Wir laufen Gefahr, in ein Digitalspaghetti hinein zu laufen. So etwas Ähnliches hatten wir doch schon einmal.
Wir sind wieder einem Sturm von Änderungen ausgesetzt, einem Sturm, insbesondere was unsere technischen Belange angeht. Wir haben eine Furcht, wie in der Vergangenheit durch oberflächliche Entscheidungen technische Schuld auf uns zu laden. Aber ein Spezifizieren wird es immer geben. Wir haben es mit Prozess-Spezifikation zu tun. Und die gängige Sprache hierfür ist heute BPMN (Business Process Model and Notation). Sollte es z.B. in 50 Jahren kein BPMN als Prozess-Spezifikationssprache mehr geben, dann gibt es Übersetzer von BPMN in die neue zukünftige Sprache X. Die Verarbeitung eines in BPMN spezifizierten Processes geschieht in einer BPMN – Process Engine . Volker Stiehl weist zu Recht darauf hin, dass hier eine Analogie zur Datenbank-Welt vorliegt. Eine Process Engine entspricht einer Datenbank und BPMN spielt dann die Rolle von SQL. Wenn es in Zukunft, in 50 Jahren also, kein BPMN mehr geben sollte, dann brauchen wir eben eine X – Process Engine.
In seinem Beitrag „ Nachhaltige Prozessautomatisierung: Process Engine als Infrastruktur“ von März 2024 beschreibt Volker Stiehl nachdrücklich den methodischen Ansatz der Prozessdigitalisierung auf der durch Dijkstra geschaffenen klassischen Informatik- Basis des „separation of concerns“. Natürlich greift er zurück auf seinen „Prozessgesteuerten Ansatz“ mit der strikten Trennung von technischer IT und fachlichem Tun in den Abteilungen, die Geld verdienen müssen. Natürlich ist das strukturiert und nicht wild, aber alles auf BPMN- Basis und die dazu gehörige Process Engine.