Jusletter IT

Es gibt sehr unterschiedliche Wege zum Verstehen der Bedeutung von Abstraktion in der Informatik. Jeder dieser Wege eröffnet eine Möglichkeit, das eigene Informatik-Weltbild zu überdenken, im Sinne der beliebten aber auch nützlichen «Re-Thinking XYZ» oder «Really Re-Inventing XYZ»-Aufsätze. Alle Wege haben dementsprechend ihren Wert und dieser Aufsatz strebt keine Auslegeordnung an. Er diskutiert exemplarisch vier Zugänge: Über Kommunikation (weil Kommunikation ein zentrales Praxisproblem der angewandten Informatik ist), über die Geschichte (weil diese für das Erlernen neuer Informatik-Technologien von zentraler Bedeutung ist), über das Lösungsdesign (weil bekanntlich grau alle Theorie und grün des Lebens goldner Baum) und über die transdisziplinäre Forschung (weil hier alle Übel und alle Rettungen zusammenkommen).

Wenn Menschen produktiv zusammenarbeiten sollen, müssen sie sich über ihre Arbeit verständigen können. Sind die Arbeitsinhalte komplex, benötigen sie dafür eine Sprache, die Dinge und Zusammenhänge benennen kann. In der Informatik war die Kommunikation lange schwierig, weil die geeigneten Sprachen dafür fehlten. Das stellte große Probleme für die Entwicklung von Informatiklösungen, für deren Nutzungsmanagement und für die Gestaltung von staatlichen Gesetzen und Verordnungen dar.

Die Umgangssprache ist wenig geeignet, um das Design von komplexer Software gut zu beschreiben, weshalb die Fach-Kommunikation schon unter Informatikern schwierig ist. Ein erfolgreiches Design verlangt aber in vielen Fällen auch die zwischenfachliche Kommunikation zwischen Informatikern, Fach-Kennern des Anwendungsbereichs, Rechtsexperten und Fach-Kennern psychologischer und sozialer Phänomene. Diese zwischenfachliche Kommunikation muss zwischen unterschiedlichen Denkmodellen in unterschiedlichen Fachdisziplinen vermitteln.

Das Fehlen geeigneter Sprachen behindert nicht nur Austausch, Vermittlung und Koordination, sondern es macht auch die individuelle Analyse- und Design-Arbeit schwierig bis unmöglich. So sehr auch die deutsche Kultur geprägt wurde durch das Ringen mit der Antinomie des Seins, möchten wir ex contrario einen Satz von Thomas von Aquin aus diesem Antinomie-Diskurs zitieren, um für eine pragmatische Nutzenperspektive auf Sprache als Analyse- und Design-Instrument zu werben: «Veritas est adaequatio rei intellectus.»! Dieser Satz lässt offen, was an wen angepasst werden soll und ist damit Vorbild für unser heutiges transdisziplinäres Streben nach guten Problemlösungen, die sich einer Definition dessen, was am Anfang ist, verweigern. Denn am Anfang aller anspruchsvollen Problemlösungen ist (per definitionem von anspruchsvoll) stets viel Unwissen und am Ende winkt (hoffentlich) ein Zuwachs von Wissen und höhere Ordnung, die den Kontext unseres Daseins verändert.¹ Für diesen Wissenszuwachs wie auch für die Weitergabe des Wissenszuwachs an andere sind sprachliche Instrumente von entscheidender Bedeutung.

In den letzten Jahren wurden diese Sprach-Instrumente entwickelt. Sie erlauben es, Architekturen zu beschreiben und zu vergleichen, und unterstützen heute eine Forschung nach dem Prinzip «Universalis in Re».². Die neuen Sprachen haben Forschung und Lehre allerdings noch zu wenig penetriert. Sie sind deshalb den meisten Akteuren im Kontext von Informatik-Anwendungen weitgehend unbekannt und führen häufig zu noch mehr Missverständnissen als die Umgangssprache: Entweder werden ihre Begriffe diffus umgangssprachlich interpretiert oder sie werden als so technisch empfunden, dass sie zu Aufmerksamkeitsblockaden führen.³ Arbeit an der Sprachentwicklung und Sprachverbreitung tut als not.

Die ersten Sprachen der Informatik waren und sind die Programmiersprachen, die Rechenanweisungen für eine Rechenmaschine formulieren können. Es sind die «natürlichen» Kunstsprachen der Informatik. Sie wurden und werden so entworfen, dass sie von Rechenmaschinen und Programmierern verstanden werden können. Wobei Verstehen für Rechenmaschinen bedeutet, dass sie Befehle ausführen, denn sie kennen kein inhaltliches Verständnis, und Verstehen für Programmierer bedeutet, dass sie den konkreten Befehl entschlüsseln können, aber auch nicht mehr. Die Informatik war also von Anfang an sprachbasiert und hat seit je viel Kreativität in das Design neuer, besserer Sprachen investiert. Was lange unterblieb war die Entwicklung von Sprachen zum Sprechen über komplexe Informatik-Lösungen.

In der Praxis tun sich Programmierer oft schwer, ihre eigenen Programme zu verstehen, die sie vor einiger Zeit geschrieben haben – und noch schwerer, die Programme anderer zu verstehen. Die Bedeutung, auf die die Symbole des Programmcodes referenzieren, erschließt sich für den menschlichen Programmcodeleser kaum (und für Maschinen eo ipso gar nicht). Dies ist nicht weiter verwunderlich, denn das Design der Programmiersprachen strebt in der Regel nicht Verständlichkeit an, sondern Programmiereffizienz oder/und Ausführungseffizienz. Es ist darauf ausgerichtet, dass Menschen Befehlsketten für Rechenmaschinen formulieren können, die diese dann schnell ausführen. Das schafft riesige Probleme, sobald Programmcode verändert werden soll.

Den Rechenmaschinen, die den Code ausführen, liegt das Prinzip der Turing-Maschine zugrunde. Das heißt: Sie sind großteils für eine sehr universelle Nutzung entworfen, bestehen aber nicht notwendigerweise aus physischer Hardware. Viele Programme werden für virtuelle Maschinen geschrieben. Diese sind selber Programme, die andere Programme ausführen können. Ihr Verhalten ist logisch exakt definiert. Aber ihr Zugriff auf Hardware-Ressourcen wird durch wieder andere Programme, das Betriebssystem und die systemnahe Software, kontrolliert. Das führt dazu, dass das reale Verhalten in den meisten Fällen nicht-deterministisch ist. Dabei entsteht Zufälligkeit nicht durch die Indirektionen per se. Ursache sind auch nicht primär die möglichen Hardwarefehler, sondern die situative Tatsache, dass meist mehrere Programme um die Hardware-Ressourcen konkurrieren und sich in die Quere kommen. Diese Konflikte um Ressourcen werden durch die Ressourcen- und Prozess-Verwaltung gelöst, was seinerseits zu Ressourcenbedarf für nicht produktive Tätigkeiten im Sinne der Programmausführung führt und dazu tendiert, wie jede Bürokratie, ein Eigenleben zu entwickeln. Das Ergebnis sind zufällige Phänomene, die bei mehrmaligem Programmdurchlauf nicht reproduzierbar sind. Eine Beschreibung der Eigenschaften von Programmen, die nur das wiedergibt, was logisch in einem Programm steht, greift folglich zu kurz. Das Zusammenspiel von Indirektionen (Programme laufen auf Programmen laufen auf Programmen) und Nebenläufigkeiten (viele Programme laufen gleichzeitig) führt zu Phänomenen und Ablaufeigenschaften der Programme, die aus der Programmlogik nur teilweise und mit extremen Aufwand direkt ableitbar sind, aber interessanterweise mit Heuristiken teilweise recht zuverlässig ableitbar sind. Wünschenswert wäre deshalb eine Form der Beschreibung der codierten Eigenschaften der Programme, die unter Anwendung der Heuristiken Schlussfolgerungen auf ihre Ablaufeigenschaften zulässt.

Beim Versuch, solche Beschreibungen zu finden, treffen wir leider sofort auf die nächste Schwierigkeit, auf die Divergenz zwischen theoretisch beabsichtigtem und real implementiertem Programm, das voll von Fehlern ist. Die Existenz dieser Fehler ist bekannt, der Ort nicht. Und alle Versuche, Fehler gänzlich auszuschließen, sind nach unseren bisherigen Erfahrungen bei komplexen Programmen zum Scheitern verurteilt. In dieser Situation hilft nur eine gute Programmierpraxis. Sie lebt mit den Fehlern, die zwar deterministische, aber nicht vorhersagbare Abweichungen von den geplanten Rechnungen liefern. Statt die Fehler auszumerzen, kontrolliert sie ihre Auswirkungen, weshalb man auch von defensiver Programmierung spricht. Das bedeutet nichts anderes, als dass Fehler lokal gemanagt werden, und deshalb für das Verständnis der größeren Zusammenhänge ignoriert werden können. Guter Code besitzt redundante Strukturen, die Fehler kompensieren und die Vorhersagbarkeit des Programmverhaltens erhöhen. Um entscheiden zu können, ob guter Code vorliegt oder nicht, benötigen wir eine Sprache, um darüber sprechen zu können. Und wir benötigen Messmethoden für die Code-Qualität, die auf abstrakten Darstellungsmethoden für Programme beruhen.

Das Beschreiben der Eigenschaften von Programmen bleibt auch damit eine schwierige Aufgabe. Denn die Applikationslandschaften sind vielerorts hochkomplex und zeigen vor allem ein dramatisches Komplexitätswachstum. Das Problem ist, dass aus lokaler Verstehbarkeit nicht globale Verstehbarkeit folgt⁴ – sprich, die Schwierigkeit liegt im Verstehen der größeren Sinnzusammenhänge. Insbesondere dann, wenn wir es mit hunderten oder tausenden Programmen zu tun haben, die auf verteilter Hardware laufen, miteinander wechselwirken und im Kontext einer größeren Organisation eingesetzt werden. Es ist sehr schwierig, die Wirkung einzelner Interventionen, sei es auf Hardware-, Software- oder Betriebsseite abzuschätzen. Lokal harmlose Probleme können sich zu verheerenden Wirkungen verketten. Kleine Fehler bei der Anforderungsspezifikation oder bei der Programmierung gewinnen in einem hochkomplexen Kontext das Potential, Weltkonzerne an den Rand des Untergangs zu bringen, wenn die Umstände sehr ungünstig sind. Die einzige Möglichkeit, Organisationen davor zu schützen, dass sie von ihrer IT ruiniert werden, ist, das Auftreten solcher ungünstiger Umstände systemisch zu verhindern. Dafür benötigen wir mehrere Sprachen. Denn das sichere Managen der Komplexität hat in aller Regel einen Preis, der in einer Beschränkung der realisierbaren Orientierung der Software-Funktionalität am Geschäftsnutzen besteht. Wir benötigen deshalb neben einer Spezialsprache für das technische Systemdesign auch eine Sprache für das Verhandeln zwischen Informatik-Abteilung und Geschäftsabteilung darüber, wie viel Gesamtsystem-Risiko ein konkret erzielbarer Geschäftsnutzen wert ist.

Die physische Verteilung von Applikationen ist ebenfalls ein relevantes Problem, weil die Kommunikation zwischen Hardware-Rechnern zwar sehr schnell, aber nicht unendlich schnell abläuft und so Raumzeitphänomene entstehen: Die verteilten Systeme kennen keine simplen «echten» Zustände mehr, sondern nur sogenannte zulässige Beobachtungen von Zuständen, die hätten auftreten können. Selbst die Beobachtung der tatsächlichen Ausführung der Programme liefert keine lineare Beschreibung der Abläufe in verteilten Rechensystemen. Für den Umgang mit Verteilungsphänomen benötigen wir deshalb formale Modelle und Instrumente, die uns es ermöglichen, sinnvolle Aussagen über Zustände um Abläufe zu formulieren, aus denen sich dann Systemeigenschaften ableiten lassen.

Diese Beobachtungen belegen in aller Kürze, dass das Erkennen und Beschreiben der Eigenschaften komplexer IT-Systeme, eine beträchtliche Herausforderung darstellt. Deshalb wird seit langem menschliche Sprache verwendet, um Programmcode um Erklärungen zu ergänzen, was das Programm tut: Programme werden mit natürlicher Sprache dokumentiert. Doch auch diese Dokumentationen beschreiben die Inhalte nur lokal. Sie ermöglichen es nicht, Interaktionen und gegenseitige Störungen einzelner Programme oder Programmteile zu beschreiben. Hierfür braucht es zusätzliche Darstellungsmethoden. Um die Konflikte auf Ebene der verteilten Programmausführung zu beschreiben hat man zum Beispiel eine Kausalitätslogik entwickelt.⁵ Ähnliches gibt es im Sicherheitsbereich. Die eigentliche Funktionalität von Programmen versucht man mit Zustandsmaschinen zu beschreiben, die definieren, was zulässiges Verhalten ist, bzw. was einzuplanende Fehlverhalten sind.⁶ In diesen Fällen versucht man, die Komplexität durch mathematische Formalisierungen in den Griff zu bekommen. Solchen Formalisierungen sind enge Grenzen gesetzt. Sie sind nur für wenige verständlich und ihre korrekte Anwendung stellt eine große Herausforderung dar.

In dieser Situation begab sich die Informatiker-Community in verschiedenen Kontexten auf die Suche nach alternativen Formen der Darstellung von Programmeigenschaften. Und zwar sowohl für den Soll-Fall, bzw. für Rahmenvorgaben, die von Software-Lösungen zu erfüllen sind, als auch für den Ist-Fall (also das, was tatsächlich implementiert ist). Auf dieser Suche entstanden verschiedene Sprachkonzepte: Sprachen zur Beschreibung von Anforderungen (Requirements Engineering), Sammlungen von typischen guten Lösungen (Patterns bzw. Muster) und typischen schlechten Lösungen (Antipatterns, bzw. Anti-Muster), sowie visuelle Darstellungsformen für das große Ganze (Architektur-Darstellungen auf verschiedenen Abstraktionsebenen).

Diese Darstellungsformen haben sich erfolgreich als Instrumente zum Umgang mit der hohen Komplexität von IT-Systemen etabliert. Sie werden für deren Design und Analyse angewendet. Vor allem aber ermöglichen sie eines: das Sprechen über IT-Lösungen!

Wie wir oben gezeigt haben, benötigen wir Abstraktionen und Sprachen um komplexe Sachverhalte der angewandten Informatik einfach verständlich für andere und auch für und selber darzustellen. Die Sprachen sollen die Gespräche unter Lösungsentwicklern vereinfachen und verkürzen. Ohne Anspruch auf eine Auslegeordnung haben drei Sprachbereiche zentrale Bedeutung: die Anforderungsbeschreibungen, die Lösungsmuster-Sprachen und Architekturdarstellungen.

Egal, ob für ein Problem eine Lösung entwickelt wird, oder – was häufig vorkommt – für eine Lösung ein Problem gesucht wird, ist das Verständnis des Problems mindestens im Kontext der angewandten Informatik ein heikles Problem für sich. Die Auftraggeber wie die späteren Nutzer wissen meist selber nicht, was sie brauchen. Das hängt damit zusammen, dass wir typischerweise unser unbewusstes Wissen (das berühmte Bauchgefühl) nicht abstrakt beschreiben können. Es ist darauf ausgerichtet, Richtiges und Falsches spontan erkennen zu können und spontan Pläne zu schmieden⁷, nicht aber, spontan Lösungsanforderungen für hochspezialisierte Handwerker zu formulieren. Es hängt aber auch damit zusammen, dass es schwer ist, sich etwas wirklich Neues vorzustellen, und entsprechend die Anforderungsbeschreibung gültige Annahmen über Design-Beschränkungen aus der Vergangenheit in die Zukunft fortschreibt. Wenn Auftraggeber oder Nutzer trotzdem akkurat genug wissen, was sie brauchen, so können sie in der Regel nicht so darüber sprechen, dass es Software-Programmierer verstehen. Das heißt, sie können einerseits ihren Wissenshintergrund und die von ihnen referenzierten Denkmodelle nicht kommunizieren und anderseits fehlt ihnen das Wissen darüber, welche Informationen für die Adressaten große Bedeutung haben (und wie diese üblicherweise Informationen verarbeiten). Und wenn sie es nichtsdestotrotz adäquat und adressatengerecht beschreiben können, liefert die Arbeit am Lösungsdesign meist neue Erkenntnisse zu Optionen, Risiken und Unmöglichkeiten, so dass die Beschreibung der Anforderungen an die Lösungen angepasst werden muss. Dazu kommt, dass jede Anforderungsbeschreibung typischerweise partiell inkompatible Lösungsbewertungskriterien enthält, deren Bedeutung sich erst bei der Design-Arbeit zeigt, und die Nachverhandlungen mit Auftraggebern oder Nutzern notwendig macht.⁸

Der erfolgversprechendste Umgang mit dem Problem des Problemverstehens besteht darin, den Kunden visuelle Prototypen zur Verfügung zu stellen, gleichzeitig aber auf Designerseite mit abstrakten Modellen der Anforderungen zu arbeiten, die jeweils einen spezifischen Teilaspekt darstellen⁹. Diese Modelle sollten möglichst viele Perspektiven auf das angestrebte Endprodukt und die Benutzerinteraktion damit beinhalten. Hierbei gilt: Mehr ist mehr, Multiperspektivität schlägt Ganzheitlichkeit. Abstraktionen helfen, ein In-der-Schachtel-Denken zu verhindern, bzw. ersetzen sie eine meist recht konkrete und enge Denkschachtel durch eine abstrakt definierte, die viel mehr Lösungsoptionen zulässt. Abstraktion erweitert den Lösungsraum, die Vielzahl der Perspektiven verhindert eine sinnlose Erweiterung. Wichtig ist, dass nicht die Abstraktionen direkt, sondern produkthafte Materialisierungen von ihnen (als visuelle oder teilfunktionale Prototypen) an die zukünftigen Nutzer zur Überprüfung der Richtigkeit der Anforderungen zurückgespielt werden. Wichtig ist auch, dass die Abstraktionen nicht diffus, sondern konkret, scharf und explizit formuliert werden. Sie müssen falsifizierbar sein. Die Erfahrung zeigt überdies, je höher der Abstraktionsgrad ist, desto wichtiger ist konkrete praktische Erfahrung mit abstrakten Darstellungsmethoden.

Insbesondere sollten natürlich auch rechtliche Anforderungen erhoben und – dies ist wesentlich – mit den unterschiedlichen Anforderungsbeschreibungen verknüpft werden. Findet diese Verknüpfung nicht statt, so ist das Risiko groß, dass die Lösungsentwickler die rechtlichen Anforderungen gar nicht zur Kenntnis nehmen. Wird sie umgekehrt konsequent umgesetzt, können die Regulierungsfolgen für das Lösungsdesign konkret identifiziert werden und es ist möglich, darzustellen, wie sich geänderte Regulierungen auswirken.

Im Laufe der Jahre sammelt jede Disziplin Erfahrungen über häufig vorkommende Lösungsmuster, sowohl auf der Ebene des Designs als auch der Designergebnisse. In der Architektur erkannte dies insbesondere Christopher Alexander¹⁰ und inspirierte damit die berühmte Gang-of-Four zu ihrem Buch über Design-Muster der objektorientierten Entwicklung,¹¹ das diese nach dem Schema «Name, Zweck, auch bekannt als, Motivation, Struktur, Anwendbarkeit, Teilnehmer, Interaktionen, Konsequenzen, Implementierung, Beispielcode, bekannte Verwendungen, verwandte Muster» beschreibt. Von da an verbreitete sich das Denken in bzw. Sprechen über Design-Muster über alle Etagen der Informatiker-Welt von den Programmieren bis zu den Projektmanagern.¹² Das Erfolgsgeheimnis der Muster-Vokabularien ist, dass sie die Kommunikation unter Experten stark vereinfachen und zugleich ein ideales Lehrmittel darstellen. Der Bezug zwischen Mustern und Rechtsaspekten wurde allerdings bisher kaum thematisiert. Die Folge ist, dass man nicht erwarten kann, dass Software-Entwickler beispielsweise verstehen, dass es rechtlich nicht immer gleichgültig ist, ob Prozesse im Front-Office oder im Back-Office verknüpft werden.

In der Informatik gibt es aber auch häufig auftretende, «typische», schlechte Lösungen. Sie werden gern mit «Praxis-ist-anders-als-Theorie»-Argumenten begründet und erweisen sich meist als extrem resistent gegenüber Qualitätssteigerungsprogrammen. Für zahlreiche Aufgaben im Informatikkontext sind in deshalb in den letzten Jahren Sammlungen von typischen Fehlern, sogenannten Anti-Mustern, angelegt wurden. Viele nutzen ein Beschreibungsschema der Art «Name, Bereich des Auftretens, Umbaumethode (Refactoring), typische Ursachen, auftretendes Kräfteungleichgewicht, anekdotische Evidenz, Hintergrund, allgemeine Form, Symptome und Konsequenzen, Variationen, Beispiele», sowie «Ausnahmen».^13,14 Der Wert der Anti-Muster-Kataloge besteht darin, dass sie Fehlverhalten benennbar machen und Verkomplizierungen zur Verteidigung von Fehlern behindern. Wer Anti-Muster implementiert lässt es an notwendiger Sorgfalt fehlen. Dementsprechend wäre es wünschenswert, Anti-Muster für die Umsetzung rechtlicher Anforderungen zu sammeln.

In vielen Bereichen von Architektur und Design ist es unumstritten, dass es für das tatsächliche Bauen oder Fertigen Skizzen und Pläne braucht. In der Informatik war dies lange umstritten. Häufig traf man Sätze wie «Entweder kann man programmieren, dann braucht man keine Architektur, oder man kann es nicht, dann hilft sie nicht» an. Die Einstellung änderte sich erst, als die hohe Komplexität die Agilität der Systeme zu bedrohen begann. Die Notwendigkeit, Ordnung in die gewachsenen Strukturen zu bringen¹⁵ trug wesentlich zum Umdenken bei. Das ungelöste Problem der Ausrichtung der IT auf den Geschäftsnutzen bei gleichzeitiger effektiver Nutzung der IT als Ermöglicher von Geschäftsinnovationen¹⁶ förderte die Entwicklung. Und in jüngster Zeit führt vor allem die rechtliche Compliance-Debatte zu mehr Popularität von Investitionen in explizite Architekturdokumentationen und die architekturgeleitete Reduzierung der Komplexität der Applikationslandschaften.

«Architekturen» im Informatik-Kontext sind abstrakte Darstellungen des sozio-ökonomischen Systems der Informatiknutzung. Dieses System kann eingebettet in einen 4-dimensionalen Darstellungsraum gedacht werden,¹⁷ der Stakeholder, Fachdisziplinen, Schlüsselideen und die zeitliche Entwicklung umfasst. Architekturen beschreiben Ausschnitte davon, z.B. die Applikations- und die Datenlandschaft oder das Zusammenspiel von Geschäftsprozessen und Applikationen. Sie können monodisziplinär genutzt werden, um das sozio-ökonomische System in einer Fachperspektive zu optimieren, aber sie unterstützen auch die transdisziplinäre Optimierung des Systems (wobei der Fall der Transdisziplinarität diesmal die Krönung der Multidisziplinarität darstellt).

Letztere stellt eine besonders große Herausforderung dar. Denn im Normalfall führen die unterschiedlichen Denkmodelle in den Köpfen der Vertreter unterschiedlicher Fachdisziplinen zu zahlreichen schweren Missverständnissen, die nicht selten als Hierarchiekonflikte ausgetragen werden. Typischer Ausgangspunkt ist, dass im Fall des Nicht-Verstehens der anderen Seite die Vorrangigkeit der eigenen Perspektive formuliert wird «Zuerst muss man …, dann erst kann man …». Solch ein Verhalten hat den verführerischen Vorteil, dass die andere Seite die (in der logischen Denkkette vorgeordnete) eigene Perspektive verstehen muss, man selber aber nicht die (in der logischen Denkkette nachgeordnete) Perspektive der anderen Seite verstehen muss. Es führt aber fast unausweichlich zu Machtkonflikten, die sinnvolle Lösungen meist blockieren. Manche Spezialisten für ERP-Software gehen beispielsweise davon aus, dass die organisationsinternen Regeln der Struktur ihres Software-Produkts folgen müssen – und umgekehrt gehen viele ausgebildete Betriebswirte davon aus, dass das Design der Geschäftsprozesse ohne Rückfrage in Bezug auf die technischen Möglichkeiten stattfinden kann¹⁸. Weit verbreitet ist auch die Annahme, dass die Designlogik im E-Government dem Ablaufmodell «1. Gesetze 2. Geschäftsprozesse 3. Technische Implementierung» folgen sollte. Solche hierarchischen Konzepte erhöhen aber die Risiken der Pfadabhängigkeit sehr stark und blockieren selbst dann noch Problembehebungen, wenn alle Beteiligten vom Scheitern des hierarchischen Vorgehens überzeugt sind.

Architekturdarstellungen treten in solchen Konfliktsituationen als Vermittler auf. Sie ermöglichen dass Menschen mit unterschiedlicher Fachexpertise sich verständigen können, ohne Expertise für das Gebiet des anderen zu besitzen, wobei sie sinnvollerweise dem Hierarchiekonflikt eine Gleichwertigkeit der unterschiedlichen Fachperspektiven gegenüberstellen. Das macht den Weg frei für eine Zusammenarbeit von Geschäfts- und IT-Abteilung, es liefert aber auch eine Basis für ein transdisziplinäres Komplexitätsmanagement und eine Analyse der Rechtskompatibilität. Zudem kann die schon bei den Anforderungsbeschreibungen angesprochene Lokalisierung der Auswirkungen von Regulierungen und Regulierungsänderungen weiter konkretisiert und in Regulierungsfolgekostenabschätzungen übersetzt werden. Eine nicht selten zu machende Erfahrung bei disziplinenübergreifender Zusammenarbeit ist, dass durch die abstrakte Perspektive von Architekturdarstellungen sich große Ähnlichkeiten in den Denkmodellen der Disziplinen zeigen.

Da Architektur-Management teuer ist, stellt sich trotzdem die Frage nach der Kosten-Nutzen-Verhältnismäßigkeit. In der Praxis wurden oft schlechte Erfahrungen gemacht: Ohne entsprechendes Fachwissen und Praxiserfahrung wird Architekturmanagement schnell zum Finanzloch. Wir meinen, dass «lieber sich gar nicht kümmern» keine valable Alternative ist. Eines von mehreren Argumenten ist Folgendes: Carl Schmitt ging davon aus, dass Ordnung und Ortung eine Einheit bilden, bzw. Ordnung Ortung voraussetzt. Durch die Virtualisierung wird aber ein Verorten von Geschehnissen in komplexen, verteilten Applikationslandschaften immer weiter verunmöglicht. Architekturdokumentationen bieten die Möglichkeit, die physische Verortung durch eine logische Verortung zu ersetzen und damit die rechtliche Analyse konsequent zu strukturieren. Zudem zeigt sie auf, wo die Kontrolle durch Überkomplexität verloren zu gehen droht und ermöglicht ganz generell Rechtsexperten mit einem Basiswissen in Informatik in den Designprozess frühzeitig zu integrieren. Dies wird zunehmend zu einem wesentlichen Vorteil und irgendwann zu einem Muss für informatiknutzende (also fast alle) Organisationen werden.

Gesprochene und geschriebene Sprache ist mächtig, um Präzision zu schaffen, aber nicht unbedingt geeignet, um Verständnis zu vermitteln. In den oben skizzierten Sprachformen spielen primär Vokabularien (z.B. zu Mustern und Anti-Mustern) eine Rolle, sofern es sich nicht um mathematische Modelle handelt. Die Muster selber, aber auch ihr Zusammenspiel und ganz generell größere Zusammenhänge werden am einfachsten und effektivsten durch visuelle Darstellungen kommuniziert, ganz ähnlich wie bei den «echten» Architekten. Visualisierung ist die zentrale Methode zur Darstellung von Abstraktionen, sie ist das zentrale Werkzeug zum Arbeiten mit Abstraktionen in der Informatik. Die oben angesprochene logische Ortung könnte man zwar natürlichsprachlich oder mathematisch vornehmen – in Bezug auf Sicherheitsaspekte ist letzteres sogar zur Verifizierung sehr empfehlenswert – aber ohne visuelle Darstellungen bleibt sie schwer vermittelbar, die Kommunikation darüber kann nur eingeschränkt stattfinden und entsprechend entstehen Risiken, dass Fehler passieren. Deshalb sind insbesondere für die Zusammenarbeit zwischen Informatikern und Juristen Visualisierungen von zentraler Bedeutung und deshalb ist insbesondere die Rechtsvisualisierung aus Informatikersicht eine wichtige Teildisziplin der Rechtsinformatik. Sie hat überdies den Vorteil, dass sie für beide Seiten keine natürliche Sprache ist, in der ihre Haupttätigkeit stattfindet, sondern eine zusätzlich hinzugelernte. Sogar die mangelnde Präzision von Visualisierungen erweist sich der Praxis meist als Vorteil, weil sie Verhärtungen in der eigenen Expertise blockiert. Präzisionsmängel sind nämlich viel einfacher korrigierbar als fehlendes gegenseitiges Verständnis.

Nachsatz: Eine Option, die bislang noch nicht genutzt wurde, sind multisensorische Darstellungen, die beispielsweise Architekturen sonifizieren oder auf Anfasseffekte setzen.

Was die Informatik für viele so mühsam und unattraktiv macht, ist die hohe Vielfalt von Programmiersprachen und Programmierwerkzeugen. Haben wir einerseits zu wenig abstrakte Sprachen, so gibt es andererseits zu viele konkrete. Diese werden im schnellen Takt auf den Markt geworfen. Man kommt mit dem Lernen kaum mehr nach. (Und ganz nebenbei schafft die scheinbare Leichtigkeit, mit der man Programmodule in verschiedenen Programmiersprachen heutzutage verbinden kann, verborgene Zukunftsrisiken, wenn sich die einzelnen Teile in unterschiedliche, nicht kompatible Richtungen entwickeln.) Das wirft die Frage auf: Wie kann man als Individuum in dieser Welt des ewigen lernen Müssens bestehen?

Die Antwort darauf ist, dass aus einer hohen Abstraktionsperspektive die Informatik die Wissenschaft des Komplexitätsmanagements ist. Es geht darum, einige wenige Grundtechniken des Komplexitätsmanagements immer weiter und weiter zu verfeinern. So kommt zwar immer wieder neu zu Erlernendes für Informatik-Lösungsentwickler auf den Markt, aber fast alles davon kann man als Weiterentwicklung bekannter Methoden sehen, was das Erlernen neuer Instrumente wesentlich erleichtert und beschleunigt. Wobei es sehr hilft, die Abstraktionsperspektiven explizit zu formulieren und als wiederkehrendes Reflexionskonzept zu nutzen.

Die vielleicht grundlegendste Idee der Informatik ist Komplexitätsmanagement durch Verbergen überflüssiger Information, auch Information Hiding bzw. Transparenz-Engineering genannt. Sie verallgemeinert das Prinzip «Teile und Herrsche!» Konkret führt sie dazu, dass das Problem des Gesamtsystemdesigns in überschaubarere Teilprobleme zerlegt wird, die es vom Rest des Systems über Schnittstellen nach dem Black-Box Prinzip (Ich muss wissen, WAS das System hinter der Schnittstelle tut, nicht aber WIE es das tut) trennt. Viele praktische Maturitätsziele der Informatik lassen sich darauf zurückführen, beispielsweise das Wiederverwenden von bereits entwickelten Bausteinen oder, seit einigen Jahren immer mehr im Fokus, die Industrialisierung der Software-Entwicklung. Man kann die Geschichte der Informatik als Geschichte des Information Hiding lesen, oder auch als Geschichte der Erhöhung des Abstraktionsgrades an und für sich (was auf das Gleiche hinausläuft, denn die Separation von WAS und WIE ist nichts anderes als das Hinaufsteigen auf der Abstraktionsleiter). Die Zielvision lautet dementsprechend seit langem unverändert, dass in Zukunft Anwendungsfachexperten ihre Applikationen ohne Informatikwissen selber programmieren, bzw. konfigurieren können. Es versteht sich von selbst, das diese Vision mit einschließt, dass dabei auch alle rechtlichen Compliance-Vorgaben mit formuliert werden können müssen, und zwar so, dass garantiert ist, dass die resultierende Software sie umsetzt.

Es gibt wenige Disziplinen, in denen die Unterschiede zwischen den besten, den durchschnittlichen und den schlechten Profis so groß sind wie beim Software-Programmieren. Ursache sind die Unterschiede in der Abstraktionsfähigkeit, in der Methodik¹⁹ und in der Bereitschaft, etablierte Muster-Lösungen (Algorithmen, Design-Muster, etc.) einzusetzen. Zu den Besonderheiten der Designtätigkeit zählt, dass die Verantwortung nicht gut auf Teams aufgeteilt werden kann und dass Prozesse in der Erstentwicklung kaum von Nutzen sind.²⁰ Design braucht, wie viele Autoren in den letzten drei Jahrtausenden es dargestellt haben, konzeptionelle Konsistenz, egal ob es sich um ein Kunstwerk, ein Haus, ein großes Software-Programm oder ein Betriebssystem handelt. Solche konzeptionelle Konsistenz entsteht nur durch einen kreativen Akt, der eine hohe Abstraktionsebene mit konkreten Details verbindet, der ein «Universalis in Re» im konkreten Einzelfall praktiziert. Das einzige, was bei diesem Akt hilft, ist das Fokussieren auf nützliche generische Designprinzipien und das Studium vieler erprobter Lösungsdesigns aus der Vergangenheit. Der Erfolg generischer Designprinzipien lebt dabei von den Abstraktionsfähigkeiten der Anwender. Entsprechendes gilt für das Studium alter Meisterwerke. Abstraktionsvermögen wirkt also als zentraler Ordnungsstifter, auf dessen Basis sich erst die eigentlich notwendige Kreativität richtig entfalten kann. Eine nicht unwichtige Bedeutung hat dabei die logische Denkdisziplin. Unsere Praxiserfahrung in F&E-Projekten ist beispielsweise, dass gerade die Zusammenarbeit zwischen Juristen und Informatikern entscheidend davon abhängt, wie diszipliniert die Informatiker mit Abstraktionsperspektiven umgehen.

Die Welt der angewandten Informatik ist noch wesentlich vielfältiger als die Informatik selber. Sinnvolle Forschung ist hier fast per definitionem multidisziplinär und verfolgt das Ziel, transdisziplinäre Lösungen zu entwickeln. Das führt zu zwei primären Herausforderungen: Wie kann ich ein multidisziplinäres Forschungsprojekt so aufsetzen, dass es ein Erfolg wird, obwohl sich Wissenschaftler verschiedener Disziplinen nicht verstehen? Wie kann ich langfristig mein Forschungsprogramm so gestalten, dass ich Wissen aufbaue, obwohl die Orientierung an Drittmittelfinanzierung dazu führt, dass F&E-Projekte in sehr unterschiedlichen Anwendungskontexten durchgeführt werden müssen?

Eine Antwort auf die erste Frage ist die Verwendung von so genannten Boundary Objects²¹, die zwischen Disziplinen vermitteln, zwischen denen keine Übersetzung möglich ist.²² Dabei empfiehlt es sich, einen Boundary Object Life Cycle bewusst so zu gestalten, dass schrittweise die Tiefe der Zusammenarbeit gesteigert wird. Beliebt ist es, vorab ein interdisziplinäres Vokabular zu definieren. Dies ist aber in der Regel unsinnig, weil allein auf der sprachlichen Ebene, ohne gemeinsames praktisches Forschungsarbeiten, selten sinnvolle interdisziplinäre Begriffssysteme entstehen. Viel erfolgversprechender ist es, mit gemeinsamen Diskussionen über ein Alltagsthema zu beginnen, das dem Forschungsprojekt zu Grunde liegt – möglichst ein Szenario, das allen praktisch verständlich ist, aber gleichzeitig für alle auch fachlich relevant ist, so dass fachdisziplinäre Denkweisen am Alltagsbeispiel sich für Spezialisten anderer Disziplinen erschließen. Diese Arbeit am Szenario sollte zu einer gemeinsamen Gestaltung einer sich schrittweise verfeinernde Architektur führen, die in einem evolutionären Software-Prototypen in gemeinsamem «Besitz» mündet. Beim Durchleben/arbeiten dieses Life Cycle entsteht in der Regel eine genuine neue Abstraktionsperspektive, die nicht selten dazu führt, dass extrem schwierige Probleme plötzlich recht banale Lösungen finden. Die Innovation besteht in solch einem Fall in der Erfindung einer neuen Abstraktion, die das Wissen unterschiedlicher Disziplinen zusammenführt.

Die zweite Frage ist noch anspruchsvoller. Drittmittelorientierung zerbricht scheinbar jede konsistente Forschungsorientierung – mindestens aber braucht es einen stetigen Dialog zwischen Forschungsorientierung und Drittmitteloptionen. In der Folge müssen die Resultate aus ganz unterschiedlichen Forschungskontexten möglichst konsistent integriert und verdichtet werden. Dies gelingt nur dadurch, dass die Forschungsresultate konsequent auf durch die Forschungsziele definierte abstrakte Perspektiven projiziert werden. Wobei die stetige Irritation durch neue Projekte in oft bislang unbekannten Kontexten als kreatives Störfaktor-Potential genutzt werden kann und im besten Fall zu empirisch und theoretisch robusteren Resultaten und sogar zu mehr Innovation führt. Die natürliche Forschungsmethode ist dementsprechend ein «Universalis in Re», das heißt eine Designforschung, die Konzepte auf einer hohen Abstraktionsebene entwickelt und dann im konkreten Kontext eines Projekts anwendet. Bei dieser Anwendung werden sie validiert und ihre Zurückspiegelung zur Abstraktionsebene führt eventuell zu einer Adaptierung der Konzepte oder ihrer theoretisch antizipierten Anwendungsbereiche.

Nachsatz: Gerade in der Forschung spielen die oben angesprochenen Visualisierungen eine zentrale Rolle. Bilder sind ein wesentliches Hilfsmittel, um einerseits Designmodelle fortzuschreiben und zu adaptieren und um anderseits logisch inkompatible Fach-Ontologien einander näher zu bringen. Der Anwendungsbereich geht aber über die reine Forschung hinaus. Auch Diskussionen über Regulierungsbedarf und Regulierungsoptionen lassen sich gut verständlich durch geeignete Visualisierungen verankern.²³

Es gibt keine einheitliche Informatikeinsatz-Theorie, kein großes Abstraktionseinsatz-Muster, sondern eine Vielzahl von lose-konsistenten Perspektiven auf Informatik, die die große Bedeutung von Abstraktionen für die Informatik und die angewandte Informatik illustrieren. Viele dieser Perspektiven, von denen wir einige exemplarisch vorgestellt haben, zeigen auch die große Bedeutung von Abstraktionen für die Zusammenarbeit zwischen Informatikern und Juristen auf. Die Rechtsinformatik-Forschung sollte gerade diese Perspektiven sich als Leitlinie für zukünftige Projekte und Programme nehmen, denn sie bieten ein sehr substanzielles Nutzenpotential, für die Praxis wie auch für Theorie und Philosophie.

Generell liegt die wesentliche Bedeutung von Abstraktionen darin, dass sie uns von willkürlichen, meist durch vergangene Erfahrungen oder Tradition bedingten Annahmen befreien, dass sie uns ein miteinander sprechen über komplexe Informatiklösungen ermöglichen und dass sie uns dabei unterstützen hochkomplexe soziotechnische Systeme als Ganzes zu begreifen, zu gestalten und zu kontrollieren. Dabei spielt die Versinnlichung durch Visualisierung eine zentrale Rolle. Visualisierung ist auch ein wesentlicher Vermittler in der Kommunikation zwischen Informatikern und Juristen, wobei es unserer Erfahrung nach eine Schwierigkeit ist, dass Informatiker häufig laxer mit visueller Präzision umgehen als Juristen.

Gerade in der interdisziplinären Forschung zu angewandter Mathematik entstehen entscheidende Fortschritte durch die Entwicklung neuer Abstraktionsperspektiven. In Zukunft wird es in Forschung und Entwicklung zu angewandter Informatik vor allem darum gehen, diese transdisziplinären Perspektiven systematisch weiterzuentwickeln, und die Denkmodelle der Informatik, der Organisationswissenschaft, der Rechtswissenschaft und weiterer Disziplinen zu vereinen.

 

---

 

Reinhard Riedl, Leiter E-Government Institut (EGI), Berner Fachhochschule

 

---