Jusletter IT

Die Optimierung der Arbeitsausführung führt zur Spezialisierung und in der Folge zum Entstehen von Expertengemeinschaften, die eigene Fachsprachen und Wertesysteme entwickeln. Dabei gehen Ganzheitlichkeit und geteilte Intentionalität¹ verloren. Dies macht es schwierige, Probleme zu lösen, die nach mehreren Fachexpertisen und vielleicht sogar einem ganzheitlichen Ansatz verlangen. Davon insbesondere betroffen ist die interdisziplinäre Forschung.

Das Scheitern von Interdisziplinarität ist insbesondere und exemplarisch in anwendungsorientierten IKT F&E-Projekten² zu beobachten. Fast kein von der EU-Kommission finanziertes Projekt wird nach Beendigung der Finanzierung weitergeführt und findet den Weg zur praktischen Anwendung. Die wenigen Ausnahmen finden fast ausschließlich eine neue EU-Finanzierung, schaffen es also auch nicht, privatwirtschaftliche Relevanz zu erreichen. Dies obwohl mittlerweile die selbständige Weiterführung der F&E-Aktivitäten Ziel der EU-Förderungen ist und die Qualität des Weiterführungsplans ein wesentliches Auswahlkriterium bei der Projektevaluation darstellt. Das Interesse an den Resultaten bleibt in Wirtschaft, Verwaltung und Gesellschaft trotzdem gering.

Unsere Erfahrungen mit zahlreichen anwendungsorientierten IKT F&E-Projekten – als Forscher, Projektleiter oder Gutachter – legen die These nahe, dass die IKT F&E Forschungsförderung der EU deshalb so geringe Nachhaltigkeit besitzt, weil sie sich die Projekte erstens schwer tun, substanzielle Resultate liefern, und zweitens noch schwerer tun, die Resultate effektiv zu vermitteln (falls es tatsächlich welche gibt). Letzteres hat zur Folge, dass trotz besonders fairer Evaluationsverfahren manche EU IKT F&E Projekte ein echter Rückschritt bezüglich früher durchgeführten Projekten aus dem gleichen Forschungsprogramm sind, ohne dass es jemand auffällt. Der Grund für das institutionelle Versagen der Forschungsförderung liegt in der Inkompatibilität von wissenschaftlich disziplinären und von interdisziplinären Werthaltungen.

Ursache und Kern des Problems ist, dass Vertreter unterschiedlicher Disziplinen sich gegenseitig nicht verstehen. Deshalb arbeiten sie in IKT F&E-Projekten selten effektiv zusammenarbeiten. Häufig findet in diesen Projekten ein nur oberflächlich koordiniertes nebeneinander her Arbeiten in disziplinären Gruppen statt. Die dabei in den einzelnen disziplinären Gruppen bearbeiteten Probleme besitzen selten Relevanz für das Lösen des Gesamtproblems. Obendrein sind sie auch für die Bearbeiter nur beschränkt interessant, weil die Ergebnisse in ihrer Disziplin schwer publizierbar sind, was dazu führt, dass die einzelnen Fachgruppen wie im Niemandsland herumirren und selbst intern nicht zusammenarbeiten. Output sind typischerweise Dissertationen, an die eine vorgebliche Interdisziplinarität als Zusatzwert angeklebt ist. Geradezu bizarr wird es, wenn nach dem Motto «develop once, cash several times» eine Lösungen gleichzeitig für mehrere teil-drittmittelfinanzierte Projekte entworfen wird, die oberflächlich ähnlich scheinen, in der Sache aber grundverschiedene Anforderungen stellen. In solchen Multiprojekt-Konstrukten kommt zur (gesteigerten) Multi-Disziplinarität eine Multi-Kontextualität hinzu, in der jedwedes Committment zu Werten mangels Lebbarkeit verloren geht. Als Gutachter hat man den Eindruck, dass einem eine Wanderung von der Liftstation zur Terrasse des danebenliegenden Bergrestaurants als Hochgebirgstour verkauft wird, mit der Begründung, dass dieser Weg mit High Heels schon gefährlich genug ist.

Der Verlust jedwedes «Qualitätsanstands» ist aber kein individuelles Problem von faulen Forschenden oder projektgierigen Forschungsverantwortlichen (auch wenn es diese bei manchen Wissenschaftlern gibt), sondern Folge der Finanzierungsbedingungen einerseits (die hier nicht das Thema sind) und der Arbeitsbedingungen für die Forscher anderseits, die durch die Struktur der Projektpläne bestimmt werden. Der typische Arbeitspläne für ein interdisziplinäre IKT F&E-Projekte stellen auf Problemebene Kompromisse dar, die primär der Formwahrung gegenüber dem Sponsor dienen («Wir arbeiten interdisziplinär.»), aber alle disziplinären Teams auf eigene Reisen durch das Niemandsland des Zwischendisziplinären führen: Jede beteiligte Disziplin macht ihre eigene, separate «Interdisziplinarität» (bzw. interdisziplinäres Setting), die mit den «Interdisziplinaritäten» der anderen beteiligten Disziplinen im Kern wenig zu tun haben. Gestaltungsprinzip dabei ist eine monadische «Unser-Lösungsbeitrag»-Idee, die davon ausgeht, dass eine Gesamtlösung herauskommt, wenn jeder seinen Teil macht. Diese Idee ist gar nicht prinzipiell falsch, mindestens wird sie durch unsere Projekterfahrung nicht widerlegt. Das viel grundlegendere Problem ist, dass in der Regel niemand seinen Teil macht, weil ja die disziplinäre Orientierung im selbstgewählten interdisziplinären Setting verloren gegangen ist. Ganz abgesehen davon, dass der selbst ohne Interaktion mit den anderen Disziplinen gewählte «Unser-Lösungsbeitrag» selten etwas mit dem Praxisproblem zu tun hat, das durch interdisziplinäre Zusammenarbeit gelöst werden sollte.

Die untauglichen Kompromisse auf der Problemebene – man zeigt sich interdisziplinär, obwohl man es nicht ist – führt auf der Lösungsebene zu meist in jeder Hinsicht untauglichen Artefakten, bei denen es nicht weiter erstaunt, dass kein Investor aus der Wirtschaft sie weiterentwickeln will. Meist sind sie oberflächlich zusammengekleistertes Stückwerk, das in seinen Einzelteilen nur reproduziert, was allgemein schon vorher bekannt war. Doch dieses Stückwerk ist nicht das Ergebnis einer unfähigen Ausführung des Arbeitsplans, sondern vielmehr die logische Konsequenz des Arbeitsplans an und für sich. Dieser Arbeitsplan ist seinerseits Folge einer miserablen Aufgabeninterpretation, die ihrerseits das Ergebnis einer fehlenden, konsistenten, transdisziplinär kohärenten und multidisziplinär akzeptierten Auflösung der Interessensgemengelage in den Projekten ist. Das Problem entsteht durch ein Nicht-Definieren eines für alle beteiligten verbindlichen, gemeinsamen, interdisziplinären Arbeitsszenarios.

Besonders frustrierend zu beobachten ist, dass der konkrete Praxiskontext der anwendungsorientierten IKT F&E nicht etwa beflügelt, sondern blockiert. Interdisziplinarität scheitert auch dort, wo sie echte Praxisprobleme lösen will, weil in der Wissenschaft Praxisbezug weder publikations- noch karriererelevant ist. In der Folge passiert dort, wo vermeintliche Innovation gefördert wird, häufig nur ein monadisches Anwenden des eigenen Disziplinen-Wissens innerhalb von eng begrenzten Teilproblemschachteln, die verglichen mit der grundlagenorientierten Forschung der jeweiligen Disziplin meist recht geringe Herausforderung für die Kreativität der Forschenden darstellen. Abgesehen davon, dass sie für das bearbeitete praxisnahe Probleme meist ohne grösseren Belang sind. Nur eine transdisziplinäre Auflösung der disziplinären Gemengelage kann dies ändern, aber die empirische Erfahrung zeigt, dass dies ex ante kaum möglich ist.

Interessant sind deshalb jene Projekte, die bescheidene Erfolge darstellen. Im Projekt FASME – Facilitating Administrative Services for Mobile Europeans wurde beispielsweise im Jahr 2000 eine POA³ für organisations- und länderübergreifendes E-Government entwickelt, wie sie Jahre später zur Norm wurde⁴. Dies gelang im Wesentlichen dadurch, dass transdisziplinär gearbeitet wurde, für den Preis, dass sämtliche ursprünglichen Projektpläne über den Haufen geworfen werden mussten. In Folge des transdisziplinären Arbeitens wurde aus dem ursprünglich zur Finanzierung eingegebenen anwendungsnahen Projekt für systemnahe Software ein Projekt zu interorganisationalen Unternehmensarchitekturen⁵. Das auf Ganzheitlichkeit ausgerichtete Zusammenwirken der unterschiedlichen Disziplinen-Vertreter formulierte neue Fragestellungen und neue Lösungen, die trotz grosser struktureller Einfachheit wesentliche neue Erkenntnisse lieferten. Einige der beteiligten Projektbeteiligten konnte diese in ihren Disziplinen gewinnbringend verwerten, auch wenn sie aus a priori nicht-technischen Disziplinen kamen⁶, für andere war die Forschung persönlich ein Irrweg, weil sie nicht die ursprünglichen Ziele erreichte, sondern in einem anderen als dem anvisierten Forschungsbereich Resultate lieferte.

FASME zeigt exemplarisch, dass eine Zusammenarbeit der Disziplinen die Probleme auf Problem- wie auf Lösungsebene wesentlich verändern und aus langweiligen multidisziplinären Projekten spannende transdisziplinäre Projekte machen kann – dass aber genau diese Transformation auch häufig als Versagen interpretiert wird. Anders formuliert: Projekterfolg in interdisziplinären Settings ist oft nur um den hohen Preis der inhaltlichen Transformation möglich, die auch als Versagen interpretiert werden kann. Nur wenige Projekte zahlen diesen Preis. Die meisten finden sich mit dem Abarbeiten der ursprünglichen Pläne ab, deren Scheitern aus wissenschaftlicher Sicht als neue Erkenntnis interpretiert wird.

Die Hamletsche Frage lautet: Will ein Projekt es wagen, seine ursprüngliche Mission zu erfüllen und dafür die Transformation der inhaltlichen Pläne in Kauf nehmen, oder zieht es vor, plangemäss zu scheitern. Fast alle Projetteams entscheiden sich für das Nicht Sein, obwohl(sic!) radikale Innovation im kulturfreien interdisziplinären Kontext es viel leichter hat als im monodisziplinären Wissenschaftskontext mit etablierten kulturellen Erwartungen der Peers, die über Publikationen entscheiden. Die Präferenz für das plangemässe Scheitern hat allerdings zahlreiche Ursachen: Man will nach wie vor publizieren (und das geht nur disziplinär), das Arbeiten in der Offenheit eines interdisziplinären Settings ist schwieriger als im Rahmen der disziplinären Settings, einmal getroffene Fehlkompromisse auf der Problemebene werden ungern aufgegeben, et cetera – und vielleicht vor allem anderen: transdisziplinäres Denken ist viel schwer kommunizierbar, schwer vermittelbar. Im interdisziplinären Projektteam selber wie auch nach aussen. Zwischen den Disziplinen im Projektgesamtteam blockiert das Unverständnis und die Geringschätzung der Werte der anderen Disziplinen, nach aussen blockiert die scheinbare Banalität der entstehenden Lösungen im Rahmen eines echt transdisziplinären Herangehens. Der disziplinäre Schutz fällt in der Aussenkommunikation weg, weil anstelle des Methodenzaubers Inhalte getreten sind, die jeder zu verstehen glaubt.⁷

Studiert man einzelne Fallbeispiele, so zeigt mindestens in Einzelfällen ein Paradoxon: Das interdisziplinäre scheitert zwar faktisch am nicht stattfindenden interdisziplinären Dialog, aber die Fehler, die dieser interdisziplinäre Dialog beseitigen müsste, liegen in eigendisziplinärem Versagen im Kontext der monadisch selbstgewählten interdisziplinären Settings der verschiedenen disziplinären Teams. Dieser komplizierte Satz meint: Würde jede Disziplin sich selber beherrschen, dann wären die meisten interdisziplinären Projekte auch ohne Dialog zwischen den Disziplinen erfolgreich! Der schiere Umstand, dass disziplinäres Denken in einem interdisziplinären Setting stattfinden muss, wirft die Disziplinen schon aus der Bahn. Wie universell dieses Paradoxon auftritt, müsste empirisch untersucht werden. Es legt aber die These nahe, dass disziplinäres Denken in der Praxis nur dort erwartbar ist von Fachexperten, wo es Standardvorgehensmethoden gibt. Die Nutzung der interdisziplinären Freiheit für Innovationen würde demzufolge im Grunde am Fehlen von Standardvorgehensmethoden scheitern.

Zusammenfassend: Unterschiedliche Disziplinen haben – nicht nur, aber auch bei IKT F&E-Projekten – unterschiedlicher Werte und unterschiedlicher Begriffssysteme. An diesen Unterschieden scheitert eine gegenseitige Verständigung beim gemeinsamen multidisziplinären Problemlösen fast immer. So werden aus Hilflosigkeit unkoordiniert Teillösungen entwickelt, die sich nicht zu einer Gesamtlösung kombinieren lassen, aber für sich selber ebenfalls kaum interessant sind. Der Kern des Problems ist aber das Versagen des disziplinären Denkens, das im interdisziplinären Setting teilweise (nicht gänzlich natürlich) auf sich selber vergisst, weil es ohne Vorgehensmethoden auskommen muss. Zudem erweisen sich transdisziplinäre Forschungsresultate als kaum als Erfolg vermittelbar, was die Motivation dazu wesentlich reduziert. Gesucht wäre deshalb eine generisch anwendbare Vorgehensmethode im interdisziplinären Kontext, das zugleich auch die Vermittelbarkeit von Resultaten effektiv unterstützt.

In vielen anwendungsorientierten IKT F&E-Projekten tauchen rechtliche Fragen auf, denn die entwickelten Lösungen müssen selbstverständlich rechtskonform sein.⁸ Aus konventioneller, monodisziplinärer Informatikers-Sicht betrachtet geht es dabei primär darum, dass die Informatiker die rechtliche Anforderungen verstehen und beschreiben können müssen, um ihr Lösungsdesign danach zu richten. Diese extradisziplinäre Herausforderung, dass Informatiker die rechtliche Perspektive verstehen müssen, tritt konkret beim Ermitteln der rechtlichen Anforderungen an die Lösungen auf, d.h. im rechtlichen Requirements Engineering. Dabei müssen Gesetze und Verordnungen in Anforderungsbeschreibungen für organisatorische und technische Lösungen bzw. Umsetzungen übersetzt werden. Diese Anforderungsbeschreibungen sollen für die Entwickler verständlich sein und ihre Erfüllung soll überprüfbar sein. Im Idealfall findet eine Übersetzung der Rechtssprache in die Sprache von Organisation und Technik statt: Insbesondere wird dabei aus einer Beschreibung von dem, was rechtlich vorgegeben ist, eine von dem was technisch der Fall sein soll. Um die Rechtskonformität einer technischen Lösung zu validieren, kann dann ein Zweischrittverfahren angewendet werden: Die rechtliche Anforderungsbeschreibung wird in Bezug auf ihre rechtliche Adäquatheit validiert (dass die rechtlichen Anforderungen korrekt und umfassend beschrieben sind) und die entwickelte technische Lösung wird gegen die Anforderungsbeschreibung validiert (dass die Anforderungsbeschreibung tatsächlich erfüllt ist).

Das Formulieren der rechtlichen Anforderungsbeschreibungen verursacht grosse Probleme, vor allem, weil die heute im Requirements Engineering verwendeten Modellierungsansätze⁹ nicht dafür entworfen wurden. Sie orientieren sich einerseits an den Nutzungsperspektiven und anderseits an den wichtigsten technischen Perspektiven. Und sie sind gut geeignet, um zwischen Nutzungsperspektive und technischem Design zu vermitteln, nicht aber für die Vermittlung zwischen rechtlicher Perspektive und Design. Die einzige Möglichkeit, rechtliche Anforderungen mit den etablierten Instrumenten zu beschreiben, ist, die rechtliche Perspektive auf die Nutzungs- und die Designperspektive zu projetzieren. Dabei besteht das Risiko, einerseits unvollständige oder nicht adäquate und anderseits hinzugegebene imaginäre rechtliche Anforderungen zu generieren.

Eine besondere Herausforderung beim Umgang mit rechtlichen Anforderungsbeschreibungen stellt die kreative Freiheit bei der Umsetzung von Gesetzen durch die Verwaltung dar, die z.B. den Einsatz von Prüflisten für Anforderungsbeschreibung zweifelhaft macht, weil die Gestaltung dieser Prüflisten zu einer willkürliche Auswirkung auf die Organisationsformen hätte.¹⁰ Dazu kommt die Vielfalt der Möglichkeiten der technischen Unterstützung der organisatorischen Implementierung von Gesetzen. Es gibt also sehr unterschiedliche korrekte technische Lösungen. Aber auch die Anforderungsbeschreibung steht in keiner eins-zu-eins Beziehung zu den technischen Umsetzungen, sondern lassen vielfältige technische Umsetzungsvarianten zu. Rein theoretisch sollte eine rechtliche Anforderungsbeschreibung alle in Bezug auf die gesetzliche Ausgangslage zulässigen technischen Implementierung zulassen, nicht mehr und nicht weniger, nur dann ist sie optimal. Aber selbst wenn dies gelingt, gibt es noch das grosse Problem der Verständlichkeit. Neben korrekten, aber unverständlichen rechtlichen Anforderungsbeschreibungen gibt es auch solche, die korrekt, aber aufgrund der Formulierung präjudizierend sind, oftmals abhängig von der Engineering-Kultur der Verantwortlichen für die technische Umsetzung. Instrumente für rechtliches Requirements Engineering zu bauen ist also eine grosse Herausforderung.

Die obige Diskussion deutet die grundsätzlichen Schwierigkeiten bei der Berücksichtigung rechtlicher Aspekte an. Doch es gibt noch mehr: Das skizzierte Modell des Requirements Engineering ist nur eine vereinfachte Darstellung. In der Praxis ist häufig die Iteration der Anforderungsbeschreibung im Laufe des Designprozesses notwendig. Immer dann, wenn der Designprozess auf Schwierigkeiten oder nicht antizipierte Möglichkeiten stösst, ist es angebracht, nochmals über die Anforderungsbeschreibungen zu gehen und diese allenfalls zu überarbeiten, denn das WAS und das WIE sind im Engineering nicht völlig trennbar. Wer bei der Formulierung des WAS die Optionen und jeweiligen Kosten für das WIE völlig aussen vor lässt, nimmt in Kauf, die Kosten und das Risiko, bei der Implementierung zu scheitern, sinnlos zu erhöhen.

In vielen Fällen stellt sich nun als Folge der Designarbeit aber heraus, dass rechtliche Änderungen die Kosten beträchtlich reduzieren oder/und den Nutzen beträchtlich steigern würden. In solchen Fällen ist es oft sinnvoll, darüber zu verhandeln, ob kleinere Rechtsänderungen, die im Recht selber nur lokale Seitenwirkungen entfalten, nicht möglich wären. Das ist nur eine theoretische Überlegung, sondern es gibt auch Praxisbeispiele dafür, dass die Verhandlung zwischen Rechtsexperten und Informatik-Spezialisten eine zentrale Rolle in Entwicklungsprojekten spielen kann, z.B. wenn im Fall von Problemen mit der Bearbeitungsdauer von kritischen Transaktionen.¹¹

Auch ein iteriertes Vorgehen im Engineering mit mehrmaliger Überarbeitung der Anforderungsbeschreibungen hat einen grundsätzlicher Nachteil: Es gibt eine stark dominierende Lead-Disziplin, die Informatik. Das Design entsteht aus der Brille der Informatik und das ist suboptimal, wie andere hierarchische Vorgehen auch. Weder die Ableitungslogik «Recht → Organisation → Technik» noch ihre Umkehrung liefern optimale Lösungen, weil die Dominanz einer Perspektive es wahrscheinlich macht, dass die anderen Fachdisziplinen unter ihrem Wert geschlagen und unzureichend berücksichtigt werden. Die empirische Erfahrung zeigt, dass organisationsgetriebene Projekte ebenso scheitern wie technikgetriebene Projekte. Rechtsgetriebene Projekte im eigentlichen Sinn gibt es kaum, aber viele gesetzliche Verordnungen die organisatorisch oder/und technisch ins Leere laufen. Der Grund ist immer der gleiche: Das Wissen der anderen Disziplinen wird entweder gar nicht berücksichtigt oder mindestens zu wenig verstanden. Zwischen Lead- und Follower-Disziplinen entsteht kein echtes Zusammenspiel – mit vielfältig unerfreulichen Folgen. Nicht nur, dass wichtige Einschränkungen des Lösungsraums übersehen werden, was zur Folge hat, dass untaugliche Lösungen entwickelt werden. Sondern auch der effektive berücksichtigte Lösungsraum enthält meist viel weniger Optionen als es gibt.

Aus rechtsinformatischer Informatiksicht wären Instrumente zum rechtlichen Requirements Engineering wünschenswert, die eine echte Vermittlerrolle zwischen Rechtsperspektive und technischer Designperspektive einnehmen könnten – eine Vermittlerrolle in beiden Richtungen, die das Entwickeln rechtskonformer Lösungen ebenso umfassend unterstützt wie Rechtsanpassungen, ohne dabei zulässige Lösungen willkürlich auszuschliessen. Vermitteln meint hier viel mehr und viel weniger als übersetzen. Es sollte Informationen in einem andersdisziplinären Kontext nutzbar machen. Auch dort, wo ein umfängliches Übersetzen aufgrund unterschiedlicher Begriffssysteme nicht möglich ist. Auch dort, wo ein Teilübersetzen in Form eines Ableitens von Einschränkungen und Aufträgen mangels teleologischer Perspektive nur zu eingeschränktem Verständnis oder bisweilen zu echten Missverständnissen führt. Solche Vermittlungs-Instrumente würden zwar nichts an der grundsätzlichen Dominanz der Informatiker ändern, immerhin aber diesen Informatikern ein qualitativ hochwertiges Arbeiten ermöglichen.

Aus transdisziplinärer Rechtsinformatik-Sicht wären darüber hinaus Instrumente wünschenswert, die ein ganzheitliches Herangehen an die Problemstellung und an das Lösungsdesign ermöglichen würden. Wobei aus psychologisch-praktischer Sicht diese Instrumente eine Form des Zusammenarbeitens ermöglichen sollten, bei der alle Fachdisziplinen-Vertreter sich als Besitzer der Lösung fühlen und über die ganze Dauer des F&E-Prozesses involviert bleiben. Letzteres ist von kritischer Bedeutung, weil die Erfahrung zeigt, dass ein transdisziplinärer, ganzheitlicher Lösungsentwurf auf Architekturebene nicht garantiert, dass diese Eigenschaften von der entwickelten Software «geerbt» werden. Denn Projekte, die ab einem gewissen Zeitpunkt für längere Zeit in die Hände einer Disziplin gelegt werden, tendieren dazu, monodisziplinär zu verkommen. Beispielsweise, wenn ein rechtskonformes Architekturdesign zu einer rechtsverletzten Software-Implementierung führt, weil einzelne Architekturaspekte von den Software-Ingenieuren wegen mangelnder Eleganz verworfen und gegen coolere Alternativlösungen ausgetauscht werden.

Gerade in der interdisziplinären Zusammenarbeit ist eine altmodische Kontrolle der Resultate durch alle Disziplinen ein Muss für erfolgreiches Arbeiten – allerdings eine Kontrolle, die an eine vorgängige aktive Beteiligung geknüpft ist und nicht nur nachgängig erfolgt. In letzterem Fall führt die Kontrolle nur zu interdisziplinären Feinseligkeiten. Im ersteren (wenn das Projekt gut geführt wird) zu einem gemeinsamen Lösungsbesitz. Wünschbar wären also Instrumente, die zwischen Juristen, Organisationsexperten und Informatikern geteilte Resultate, genauer geteilte Artefakte, liefern – je fassbarer, desto besser. Die zweitbeste Lösung wären Vermittlungs-Instrumente für ein von der Informatik gesteuertes rechtliches Requirements Engineering.

Wir haben oben mehrere grundsätzliche Probleme der interdisziplinären Zusammenarbeit in der angewandten IKT-Forschung identifiziert: die unzureichende Aufgabenformulierung als Folge des gegenseitigen Nichtverstehens und der fehlenden Vermittlung. In der Literatur wie im Kollegengesprächen tauchen dazu immer drei Lösungsvorschläge auf

• Eine klare lineare Hierarchie der Disziplinen
• Das Definieren von Schnittstellen
• Das Erfinden einer gemeinsamen Sprache

Alle drei Wege sind so beliebt wie problematisch.

Wenn eine lineare Hierarchie aufgesetzt wird, in der jeweils eine Disziplin für die nachfolgende Aufträge formuliert, wird dies im besten Fall den effektiv betrachteten Raum der Lösungsoptionen verkleinern, vermutlich aber auch notwendige Anforderungen verschwinden lassen. Weil etwas, das für die übernächste Disziplin relevant ist, für die Zwischendisziplin sehr wohl irrelevant sein kann. Notwendig ist also in jedem Fall, dass eine Disziplin die Vorgaben aller Vorgängerdisziplinen mit berücksichtigt. Betrachten wir dazu die beliebte «theoretische» E-Government-Ableitungskette

<< Politischer Wille → Gesetze und
Verordnungen → Verwaltungsaufgaben →Aufbauorganisation → Prozesse → Technische Lösungen → Einsatzkonzepte >>

die in der Praxis meist die verkürzte Form

<< Gesetze → Prozesse → Software >>

 annimmt (u.a. weil Software häufig als Lösung angesehen wird). Im Fall einer Ableitung, die nur die mit Pfeilen hier bezeichneten Ableitungen berücksichtigt, kennt das Design der Einsatzkonzepte nur die technische Lösung (und weiss nicht, warum die so ist, wie sie ist), während es im Fall, dass die transitive Hülle der kausalen Ableitungen gebildet wird (sprich alle logischen Vorgänger mit berücksichtigt werden), es die meisten Vorgaben von allen Designschritten hat, aber seinerseits von allen anderen Entwicklungsschritten ignoriert wird. Klar ist, dass das zweite Vorgehen korrektere Lösungen liefert, als das erste. Aber es ist auch einsichtig, dass der effektive Lösungsraum extrem verkleinert wird, durch die Kaskade an Designentscheiden, die die Perspektiven der nachfolgenden Designentscheidungen ignorieren. Wenn in einem Schritt zufällig eine Variante unter mehreren gleichwertig scheinenden ausgewählt wird, kann dies aus der Perspektive eines späteren Schritts die schlechtestmögliche sein. Man kauft sich in diesem Fall grosse Nachteile für null Vorteil ein. Aber auch ein kleiner Vorteil bei der Designentscheidung in einem früheren Schritt kann von einem daraus folgenden grossen Nachteil für die Perspektive eines späteren Schritts negativ überkompensiert werden. So kann z.B. ein schöneres Organigramm zum Millionenloch werden. Das hierarchische Konzept erweist sich so als Geldverbrennungsmaschine, deren einziger Mehrwert darin besteht, dass das Ego der für vorne (bzw. oben) liegende Design zuständigen Entscheidungsträger gestärkt wird.

So weit, so problematisch in einer idealen Welt, in der in jedem Einzelschritt exakte rationale Entscheidungen möglich sind. Im wirklichen Leben sind die Probleme grösser, weil die Ableitungen, wie z.B. in der obigen E-Government-Pseudo-Logik, nicht präzise sein können, da die verwendeten Begriffssysteme inkompatibel und nicht übersetzbar, meist sogar explizit inkompatibel sind. Auch ohne diese Inkompatibilität ist eine völlige Konsistenz der Perspektiven deshalb kaum möglich, weil es in den einzelnen Disziplinen nicht selten inhärente Widersprüche hat: Z.B. können die für den Anwendungsbereich relevanten Gesetze in sich widersprüchlich sein. Selbst die beste Ableitungsarbeit produziert also nicht nur rational zulässige Willkür mit eventuell grossen Folgen für spätere Designschritte, sondern zusätzlich auch noch Unschärfen, die im Nachfolgenden Verwirrung stiften. Dies insbesondere dann, wenn eine nachfolgende Designperspektive einen schärfen Blick auf einen Aspekt eines vorgängigen Designentscheids hat als die Disziplin, die den Designentscheid gefällt hat. Es ist durchaus denkbar, dass Informatiker rechtliche Verordnungen in Bezug auf einen einzelnen Aspekt korrekter interpretieren als Geschäftsprozessverantwortliche in der Verwaltung – insbesondere dann, wenn für sie dieser Aspekt eine viel grössere Relevanz hat als für die Prozessverantwortlichen. Sie werden in diesem Fall durch eine hierarchische Ableitungslogik gezwungen, etwas zu implementieren, was einen inhärenten Widerspruch in sich trägt, der sich aber erst in ihrer Perspektive zeigt (und der eventuell ohne Nutzung der Informatik gar nicht existieren würde).

Man kann es auch anders formulieren: Luhmann hatte unrecht, als er die Technik für irrelevant erklärte: Es mag zwar gleichgültig sein, ober der Überbringer einer Nachricht auf einem Schimmel oder ein Schecken sitzt, aber es wird ziemlich vieles anders, wenn die Nachricht über das Internet vermittelt wird. Und so, wie die Pferdegeschwindigkeit einst die Aufbauorganisation der öffentlichen Verwaltung Frankreichs prägte (was zeigt, dass der Gesetzgeber auch früher schon die Technik berücksichtigte), so muss auch heute die IKT mit berücksichtigt werden, wenn es um die Organisation der öffentlichen Verwaltung geht. Und zwar nicht nur im E-Government, sondern in der ganzen Rechtsinformatik.

Unabhängig von solchen Analysen der logischen Defizite hierarchischen Gestaltens gibt es auch schwerwiegende psychologische Defizite. In einer hierarchischen Beziehung zwischen Teams unterschiedlicher Disziplinen ist das Zustandekommen eines geeigneten Informationspush unwahrscheinlich. Weder «von oben» noch «von unten» wird in der Regel brauchbar kommuniziert: Die Vertreter der übergeordneten Disziplin liefern häufig Aufträge, statt zu informieren und den Vertreter der untergeordneten Disziplin wird aufgrund der hierarchischen Logik gar kein Recht für einen Informationspush zugestanden. Frustration führt in der Folge zum Ausbleiben von Rückmeldungen und Rückfragen: Es scheitert also auch der Informationspull. Die Folge sind Häufungen von Fehlinterpretationen.

Leider scheitert der simple Informationspull auch dort, wo eine Disziplin alle übrigen dominiert und die Vertreter dieser Disziplin die Bereitschaft zum Nachfragen besitzen und sogar Aufträge explizit in Form eines Informationspull vergeben. Dies liegt daran, dass das Wissen fehlt, Fragen zu stellen, die aus Sicht der angefragten Disziplin vernünftig scheinen. Die Folge ist, dass Antworten geliefert werden, die für die dominierende Disziplin irrelevant sind. (Oder dass Beschwerden und Kritik an den Ideen der dominierenden Disziplin geäussert werden, um die Frage gar nicht beantworten zu müssen.) Aus genuiner IKT-Lösungsdesigner-Perspektive zeigt sich beispielsweise folgendes Bild: Ein Lösungsdesigner hat in der Regel zwar gelernt mit Anwenderperspektiven umzugehen, aber weder Erfahrung noch spezielle Instrumente, um mit der rechtlichen Perspektiven umzugehen. Deshalb tut er sich mit dem Informationspull sehr schwer. Ohne Informationspush der anderen Disziplinen ist er hilflos. Dieser Push findet aber in einem hierarchischen Setting selten statt.

Zusammenfassend: In der Praxis ist es egal, ob die Technik im Lead ist, und den Rechtsexperten Aufträge vergibt, die rechtlichen Anforderungen zu spezifizieren, oder ob aus der rechtlichen Perspektive organisatorische Anforderungen und aus diesen das technische Design abgeleitet wird. Das Ergebnis ist in beiden und auch vergleichbaren anderen Fällen sehr häufig ungenügend.

Schnittstellen spielen in der IKT eine zentrale Rolle. Sie sind das zentrale Instrument, um das Zusammenspiel unterschiedliche Komponenten oder Teilsysteme zu ermöglichen. Sie erlauben es, das Design von komplexen IKT-Systemen in überschaubare Teilaufgaben zu erledigen. Sie erlauben es weiters, das WAS vom WIE zu trennen. Und sie ermöglichen Vernetzung im grossen Stil. Was liegt also näher, als auch für die Zusammenarbeit unterschiedlicher Fachdisziplinen in einem IKT-F&E-Projekt Schnittstellen zu definieren – das heisst genauer, Vorgaben für «Deliverables» zu machen, mit denen sich die disziplinären Arbeitsgruppen gegenseitig beliefern. Scheinbar kann die logische Problematik der hierarchischen Beziehungen dadurch entschärft werden, dass die Empfängerseite exakte Vorgaben über das zu Liefernde macht (wie das bei einer Schnittstelle der Fall ist) und eventuell kann auch die psychologische Problematik dadurch entschärft werden, dass in beiden Richtungen über eine bidirektionale Schnittstelle geliefert wird.

Die Erfahrung gerade im Kontext von EU IKT F&E-Projekten zeigt leider, dass im Normalprojekt alle diese Schnittstellen scheitern. Das oben skizzierte Informationspull-Problem schlägt zu. Alle disziplinären Projekten liefern in der Regel extradisziplinär Unbrauchbares – mindestens so lange, wie es nicht gelingt, erstens Bereiche überlappenden Wissens zu etablieren und zweitens einen intensiven Dialog in den entstehenden gemeinsamen Wissensbereichen rund um die Schnittstellen zu etablieren. Erst dann, wenn die Schnittstelle nicht mehr trennt, sondern eingebettet ist in geteiltes Wissen und in praktizierten Dialog, kann sie ihre Aufgabe erfüllen. Solch einen Bereichen nennen wir «Kollaborationszone». Erst dann wenn die Schnittstelle keine Schnittstelle mehr ist, sondern nur eine formale Definition eines Milestones mit einem Deliverable im Kontext einer etablierten Kollaborationszone, erst dann funktioniert sie. Fast jeder andere Versuch, z.B. durch besonders gute Vorgaben für die «Deliverables» auf Empfängerseite zu garantieren, dass Nützliches geliefert wird, scheitert. Nur die wissens- und dialogbasierte Kollaborationszone ändert etwas am «Schnittstellenspiel».

Allerdings sind selbst etablierte Kollaborationszonen etwas Diffuses und vor allem etwas Flüchtiges. Sie benötigen zum Entstehen wie zum Bestehen etwas zugleich Symbolisches und Konkretes, das sie repräsentiert – gerade weil sie mehr sein sollen, als jede konkrete Schnittstellenspezifikation je sein könnte. Formale Wissensdokumentationen zur «Materialisierung» des geteilten Wissensbereichs wären vorstellbar, sie haben sich in der Praxis aber – bisher – immer als völlig illusorisch erwiesen.¹² Eine Sprache wäre wünschenswert, wir werden sie im nächsten Unterkapitel erläutern, warum auch dies keine realistische Option ist. Gut fassbare, geteilte Vorlösungsartefakte sind hingegen bisweilen ein gut geeignetes Instrument, um eine «Kollaborationszone» zu etablieren und die Schnittstellenprobleme zu überwinden – vor allem, wenn sie einfach und schrittweise in Besitz genommen werden können von den Vertretern der beteiligten Disziplinen. Das oben zitierte FASME-Projekt verwendete das Szenario des Umzugs in Europa als Vermittlungsartefakt. In der Forschung zu künstlicher Intelligenz ist üblich, Roboter als Vermittlungsartefakte einzusetzen, die von allen gemeinsam entwickelt werden.¹³

Zusammenfassend: Schnittstellen zwischen Juristen und Informatikern funktionieren in der Regel in keiner der beiden Richtungen.¹⁴ Gleiches gilt für Schnittstellen zwischen Organisationsspezialisten und Informatikern. Echte Zusammenarbeit über Disziplinengrenzen hinweg verlangt das Schaffen einer Kollaborationszone, die sich über gemeinsames Wissen der kooperierenden disziplinären Teams definiert. Diese muss aber fassbar manifestiert werden, andernfalls die Zusammenarbeit und ihre Erfolge sich schnell verflüchtigen.

Eine praktische Möglichkeit zur «Materialisierung» von Kollaborationszonen sind die genannten Boundary Objects¹⁵, die zwischen Disziplinen vermitteln, zwischen denen keine Übersetzung möglich ist.¹⁶ Sie stellen die oben angesprochenen Vermittlungsartefakte dar. Es kommt dabei aber sehr darauf an, ob es sich um eine statische bzw. punktuelle Vermittlung handelt, oder die Vermittlung in einem gemeinsamen Entwicklungsprozess. Statische Vermittlung genügt beispielsweise in Museen, punktuelle Vermittlung tritt unter anderem in konsekutiven Designprozessen auf¹⁷. Wie oben begründet, ist solch ein konsekutives Arbeiten im Rechtsinformatikkontext kaum realisierbar. Hier braucht es entwickelbare Boundary Objects, wie sie z.B. der oben zitierte COG besitzt.

Statt eines entwickelbaren Boundary Objects ist es möglich, eine Folge von Boundary Objects zu verwenden, die für sich statisch oder auch entwickelbar sind. Wir sprechen in diesem Fall von einem Boundary Object Lebenszyklus. Es empfiehlt sich, diesen Lebenszyklus bewusst so zu gestalten, dass schrittweise die Tiefe der Zusammenarbeit gesteigert wird. Besonders vielversprechend ist es bei einem IKT F&E-Projekt, mit gemeinsamen Diskussionen über ein Alltagsthema zu beginnen, das dem Projekt zu Grunde liegt. Dieses Alltagsszenario sollte allen praktisch verständlich sein aber komplex genug, dass es für alle beteiligten Disziplinen auch fachlich relevant ist. Dann können anhand des Szenarios die fachdisziplinären Denkweisen für die Spezialisten der anderen Disziplinen erklärt werden. Die Beschäftigung mit dem Alltagsszenario als ersten Boundary Object sollte zu einem zweiten Boundary Object hinführen, der sich schrittweise verfeinernde Architektur, zu der auch die rechtliche Anforderungsbeschreibung gehört. Die Architektur führt dann ganz natürlich zu einem dritten Boundary Object, dem evolutionären Software-Prototypen im gemeinsamem «Besitz», wobei die Etablierung des gemeinsamen «Besitzes» eine grosse Herausforderung darstellt, aber für einen Projekterfolg unerlässlich ist. Es bedarf hier ganz besonderer «Trucs», um die natürliche exklusive Zuordnung der Software-Prototypen in die Welt der Informatik zu unterbinden. Beispielsweise dadurch, dass die anderen Disziplinen ins praktische Testen involviert werden oder dass Teile der Konfiguration auf hoher Abstraktionsstufe von ihren Vertretern selbst erstellt werden.

Disziplinen zeichnen sich durch eine gemeinsame Sprache und gemeinsame Werte aus. Das vorhanden Sein eines etablierten und von allen ähnlich verstandenen Begriffssystems schafft die Basis für eine gute Verständigung, d.h. für ein gegenseitiges Verstehen der Problembeschreibungen und der Lösungsbeschreibungen. Die gemeinsamen Werte helfen, sich über die Bedeutung von Problemen und den Wert von Lösungen zu einigen und diese Einigung wiederum hilft, das gemeinsame Begriffssystem effektiv für die Verständigung zu nutzen. Es braucht also beides: ein gemeinsames Begriffssystem und geteilte Werte, um gut zusammenzuarbeiten. Dafür muss beides nicht hundertprozentig vorhanden sein, 60% genügen jeweils auch. Deshalb scheint es natürlich zu sein, interdisziplinäre Projekte damit zu beginnen, dass eine gemeinsame Teilsprache definiert wird. Vorstellbar und explizit wünschenswert wäre sogar die Schaffung einer Rechtsinformatiksprache.

Das Problem ist nur, ohne gemeinsames Wissen – d.h. ohne ein ähnliches Verständnis von Zusammenhängen – ist es nicht einmal dann realistisch möglich, eine gemeinsame Sprache ex ante zu entwickeln, wenn die jeweiligen Begriffssysteme kompatibel sind. Denn die Beziehungen zwischen Begriffssystemen sind in komplexeren Fällen durch einen theoretischen Diskurs kaum fassbar. In der Praxis wird weder die Ungleichheit des gleich Benannten, noch die Gleichheit des unterschiedlich Benannten, verstanden. Gemeinsames Wissen muss sich auf etwas beziehen, das fassbar ist, damit es sich entwickeln kann. Ist das, worauf sich das gemeinsame Wissen bezieht, nur ein Dialog über die Entwicklung einer gemeinsamen Sprache, so ist die Verankerung sehr diffus. Obendrein ist ein Entwickeln einer gemeinsamen Sprache, das sich aus dem Dialog über eine gemeinsame Sprache ergibt, selbstreferenziell. Ein Erfolg des Vorhabens, aus dem Nichts eine gemeinsame Sprache zu entwickeln, ist deshalb auch dann mehr als unwahrscheinlich, wenn es um das Zusammenführen gut kompatibler Begriffssysteme geht.

Im Fall von Recht und Informatik sind die Begriffssysteme und die dahinter liegenden Werte aber sogar sehr verschieden. Eine gemeinsame Sprache theoretisch zu konstruieren ist deshalb praktisch ausgeschlossen, solange kein gemeinsames Wissen existiert, dass auf etwas referenziert, das Echtweltbezug hat. Wenn überhaupt, kann eine Vermittlungssprache nur aus erfolgreicher Zusammenarbeit beim Lösen von Echtweltproblemen entstehen. Sie kann das Ergebnis des Zusammenarbeitens und der Etablierung einer Kollaborationszone in einem Projekt sein, nie aber der erste Schritt. Und als Ergebnis erinnert sie dann meist an den typisch Mischmasch der im Alltag entsteht, wenn Menschen mit unterschiedlichen Sprachen länger miteinander zu tun haben und keine gemeinsam gut beherrschte Drittsprache haben.

Ex post die entstandene Sprache mittels einer Ontologie zu formalisieren wäre möglich, geschieht aber selten bis nie. Für ein absolviertes Projekt bringt es keinen Vorteil und die Rechtsinformatik Community hat sich bisher dafür nicht interessiert. Bislang gab es kaum Versuche, die unterschiedlichen formalisierten Ontologien, die in den letzten Jahren als Kerninhalt von drittmittelfinanzierten Projekten entstanden, auch nur in Beziehung zueinander zu setzen – geschweige denn, die ad hoc Dialekte zu kombinieren. Es ist obendrein mehr als zweifelhaft, dass die erfolgreichen Projektkooperationen zu kohärenten ad hoc Dialekten geführt haben. Da viele Projekte in Sprachlosigkeit verharren und bei den wenigen interdisziplinär erfolgreichen Projekten die Kontaktpunkte zwischen den Disziplinen je nach Projekt sich stark unterscheiden, dürfte es sehr schwierig sein, die resultierenden Dialekte zu kombinieren. Ohne Versuch sowieso.

Solange es keine etablierte Rechtsinformatik-Sprache und Werte gibt, ist es im konkreten Projekt jeweils wichtig, dass jeder Beteiligte die Denkwelt der anderen Disziplinen weitgehend versteht und plus/minus einiger Ungenauigkeiten und Missverständnisse in die eigene Denkwelt integriert. Dies setzt Dialog in einem konkreten Arbeitskontext voraus, der wiederum Wertschätzung für die Werthaltungen der anderen Disziplin voraussetzt. Die praktische Erfahrung zeigt, dass diese Wertschätzung selten spontan entsteht. Spontaner Respekt reicht aber aus, um im Laufe der Zusammenarbeit Interesse für das Denken der Andersdisziplinären zu entwickeln und darauf aufbauend echt transdisziplinäre Problemlösungen zu entwickeln.

Zusammenfassend: Es erscheint nach dem bisherigen Stand der Rechtsinformatik illusorisch, eine brauchbare Sprache für die Zusammenarbeit zwischen Juristen und Informatikern zu formulieren. Wenn dies überhaupt eines Tages gelingen soll, so braucht es dafür viel mehr an echt transdisziplinärer Kooperationserfahrung, die entsprechend auch intensiv in der Community ausgetauscht wird. Aus den unterschiedlichen, in erfolgreichen interdisziplinären Kooperationsprojekten entstandenen ad hoc Vermittlungsdialekten könnten langfristig so tatsächlich eine eigenes Begriffssystem und gemeinsame Werte entstehen.

Abstraktionen werden in vielen Bereichen von Forschung und Design eingesetzt, insbesondere in IKT F&E¹⁸. Sie ermöglichen das Herausgreifen spezieller Aspekte und stehen deshalb am Anfang jeder Disziplinenbildung. Sie ermöglichen die Kategorisierung bzw. Generalisierung und sind so in der Informatik die Basis jeder generischen Lösungsentwicklung bzw. der Zerlegung von Lösungen in Teilschritte. Und sie ermöglichen es, die Komplexität zu reduzieren, in dem man Teile zu einem grösseren Ganzen zusammenfasst und die Komplexität dieses grösseren Ganzen ausblendet, bzw. in der Informatik in eine Komponenten ausgelagert, auf die über Schnittstellen zugegriffen wird. Die Formen der Abstraktion sind sehr vielfältig: Geschichten Erzählen, Bilder Malen, Formeln Aufstellen, etc. Die damit verfolgten Ambitionen sind ebenfalls vielfältig. Meistens geht es aber darum, das Verständnis der komplexen Wirklichkeit oder komplexer Modelle zu ermöglichen und so einfachere Lösungen zu entwickeln.

Das grundsätzliche Vorgehen bei der Abstraktion zur Lösungsentwicklung ist ein Dreischrittverfahren. Im ersten Schritt wird die Wirklichkeit oder das vorhandene Modell auf ein neues konkretes Modell in einem gedachten Modellraum so abgebildet, dass dabei wesentliche problem- und lösungsrelevante Strukturen erhalten werden. Im zweiten Schritt wird dieses neue konkrete Modell «manipuliert», um das Problem auf der «Bühne» des Modellraums zu lösen. Dabei wird das neue konkrete Modell so umgeformt wird, dass einerseits die wesentlichen Struktureigenschaften erhalten bleiben und anderseits seine Lösung evident wird. Im dritten Schritt wird die erarbeitete Lösung zurück abgebildet auf die Wirklichkeit. Bei IKT F&E-Projekten wird als Wirklichkeit der Problemkontext mit der gedachten Lösungen genommen und das Dreischrittverfahren eventuell mehrmals hintereinander angewandt, wenn es sinnvoll scheint, die gedachte Lösung und der Problemkontext anzupassen (wie oben bei der Iteration der Anforderungsbeschreibung dargelegt).

Das beschriebene Verfahren macht insbesondere dann Sinn, wenn die Manipulationen im Modellraum einfacher sind als das Lösungsdesign in der Wirklichkeit. Typische Gründe dafür sind, dass der Modellraum weist geringe Komplexität aufweist als die Wirklichkeit, dass das Modell kognitiv für Menschen einfacher handhabbar und bearbeitbar ist, dass der Modellraum einen klaren Rahmen definiert, der sich positiv auf die Kreativität beim Lösungsentwurf auswirkt, dass das Experimentieren mit Modellmanipulationen einfacher und billiger ist als das Experimentieren in der Wirklichkeit, dass das Modell gut kommunizierbar ist und hilft, eine geteilte Intentionalität herzustellen, dass ein gemeinsames «Manipulieren» über Disziplinengrenzen hinweg möglich wird oder dass die «Manipulationen» an Maschinen delegiert werden können.

Interessant daran ist insbesondere die Unterstützung des interdisziplinären Arbeitens. Da Abstraktionen richtig angewandt durch das Reduzieren der Komplexität die wesentlichen Strukturen herausstellen, erleichtern sie, die Gemeinsamkeiten zwischen den Disziplinen zu erkennen und erweisen sich so als Boundary Objects zwischen den Disziplinen, die ein koordiniertes Design in unterschiedlichen Disziplinen ermöglichen. Der Raum der abstrakten Modelle wird so zu einer Kollaborationszone, in der die Gemengelage der unterschiedlichen Disziplinen aufgelöst werden kann, was zu einer Aufgabenseparation auf der Problemebene führt die in der Folge zu Teillösungen führt, die zusammen passen und integriert das ursprüngliche Problem transdisziplinär lösen (wenn auch eventuell um den Preis einer wesentlichen Transformation der ursprünglichen Projektpläne, wie oben ausgeführt). Die jeweils inkompatiblen handgestrickten «Interdisziplinaritäten» werden dabei durch eine gemeinsame Aufgabenteilung ersetzt und die eigentlichen Aufgaben können fokussiert im Rahmen der jeweiligen Disziplin gelöst werden. In passend gewählten Abstraktionsräumen kann somit wieder zusammengeführt werden, was durch die Abstraktion der disziplinären Spezialisierung einst die Gemeinsamkeit verloren hat.

Deshalb ist unsere These, dass die gesuchten Instrumente für das rechtliche Requirements Engineering im Kern passende Abstraktionen sein müssen, die der einfacheren Verständlichkeit wegen gut visualisierbar sind. Sie sollten es ermöglichen, dass die abstrakten Modelle der einzelnen Disziplinen zu einem Gesamtmodell der zu entwickelnden Lösung so zusammengeführt werden, dass die Zusammenhänge zwischen den Disziplinen sichtbar werden. Unsere aktuelle Forschung beschäftigt sich mit der Frage, wie Architekturmodelle beschaffen sein müssen, dass sie diese Anforderungen erfüllen.

---

 

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