1.1.
Inhalt ^
[1]
Rechtsinformatik hat viele Stakeholder. Der Unternehmensarchitekt ist nur einer unter vielen. Dieser Beitrag beleuchtet dementsprechend nur einen kleinen Ausschnitt der Rechtsinformatik – nämlich die Rechtsinformatik, wie sie sich zeigt, wenn wir sie vom Blickwinkel der Unternehmensarchitekten aus betrachtet wird. Wir versuchen Antworten zu geben auf folgende Fragen: Was sind die Forschungsfragen der Rechtsinformatik aus der Perspektive des Unternehmensarchitekten? Woher kommen diese Fragen kommen? Wie lassen sie sich zu Themenkomplexen ordnen? Welche Herausforderungen sind damit verbunden? Wohin soll die Forschungsreise führen?
1.2.
Widmung ^
[2]
Dieser Beitrag ist Prof. DDr. Erich Schweighofer gewidmet. Er hat entscheidend zur Entwicklung der deutschsprachigen Rechtsinformatik beigetragen und zählt zu den ganz wenigen, die bedeutende wissenschaftliche Resultate in Rechtswissenschaften und in Wirtschaftsinformatik erzielt haben.
2.
Zweck, Struktur und Form von Unternehmensarchitekturen ^
[3]
Es gibt unterschiedlichste Frameworks zur Strukturierung des Unternehmensarchitekten-Universums. Diese Strukturierungen zu ordnen ginge über diesen Beitrag weit hinaus, zumal es neben theoretischen viele praktische Ansätze gibt und nicht jeder in diesen Kontext gehörende Ansatz sich selber das Label «Enterprise» aufgeklebt hat. Wir beschränken uns darauf, einige weithin etablierte Grundlagen zu skizzieren.
2.1.
Unternehmensarchitekturen als dauerhaft zu nutzende Werkzeuge ^
[4]
Unternehmensarchitekturen sind ein Instrument für das informationsorientierte Komplexitätsmanagement in Organisationen (die nicht notwendigerweise Unternehmen sein müssen). Sie ermöglichen es zu beschreiben, was wir über die Geschäftsarchitektur und die IKT-Architektur wissen und was wir darüber nicht wissen. Mit Geschäftsarchitektur ist dabei die «Architektur» der operativen Geschäftstätigkeit gemeint, insbesondere aber nicht nur die «Architektur» der Ablauforganisation. Der Begriff IKT-Architektur steht für die «Architektur» des Einsatzes von Informations- und Kommunikationstechnologie (IKT).
[5]
Die grosse Herausforderung des informationsorientierten Komplexitätsmanagements in Organisationen besteht darin, das natürliche Komplexitätswachstum im Informationsmanagement unter Kontrolle zu behalten, ohne die Weiterentwicklung der Organisation zu sehr einzuschränken. Ist das IKT-Einsatz sehr chaotisch, so geht es in einem ersten Schritt darum, den Technologiewildwuchs einzudämmen, um die Kosten zu senken. Erst in einem zweiten Schritt geht es danach darum, die Struktur der eingesetzten Technologie so zu vereinfachen, dass die Veränderungsflexibilität in geschäftlicher wie in technologischer Hinsicht möglichst hoch ist. In diesem zweiten Schritt kommt es typischerweise zu einer neuerlichen Steigerung der Technologiekosten, die allerdings durch den resultierenden Geschäftsnutzen dann gerechtfertigt ist, wenn eine Organisation flexibel sein will. (Besteht dieser Bedarf nicht, kann man auf den zweiten Schritt teilweise verzichten).
[6]
Die Implementierung neuer Geschäftsfunktionen und die Einführung neuer Technologien führt freilich dazu, dass jede erzielte Ordnung im Laufe der Zeit sich wieder in Chaos auflöst. Da ein Verzicht auf Veränderung selten bis nie eine Option ist, bleibt das informationsorientierte Komplexitätsmanagement so eine dauerhafte Aufgabe für jene Organisationen, deren Erfolg wesentlich von gutem Informationsmanagement abhängt.
[7]
Eine gute Unternehmensarchitektur ist ein Katalysator für die Organisationsweiterentwicklung. Sie fördert aber damit auch das Entstehen neuer Unordnung und bedarf dauerhafter Anstrengungen zu ihrer Instandhaltung.
2.2.
Die Bedeutung des «Gemeinsamen» ^
[8]
Damit Unternehmensarchitekturen das Komplexitätsmanagement unterstützen können, müssen sie eine Diskussionsbasis schaffen, indem sie beschreiben was IST, beziehungsweise was sein SOLL. Die Beschreibung der IST-Situation muss die Situation so widerspiegeln, dass Probleme erkannt und Problemlösungen entworfen werden können. Der Vergleich von SOLL und IST sollte zudem es ermöglichen, die Veränderungsrisiken zu identifizieren.
[9]
Das in der Praxis wichtigste Architektur-Darstellungskonzept ist, zu beschreiben, was in der ganzen Organisation (oder in einem grossen Teil der Organisation) der Fall ist. Man fokussiert sich in der Darstellung also auf das Gemeinsame und Universelle und lässt das Lokale und Spezielle aussen vor. Die zugrundeliegende Heuristik ist, dass die Ordnung umso grösser ist, je mehr Gemeinsames es gibt, das heisst je grösser die Homogenität des Systems ist.
[10]
Ziel ist es allerdings in der Regel nicht, maximale Ordnung zu schaffen, sondern optimale. Je nach Perspektive, beziehungsweise je nach den Anforderungen der Organisation an ihre IKT, ist der optimale Ordnungsgrad unterschiedlich hoch.
2.3.
Die Notwendigkeit unterschiedlicher Abstraktionen ^
[11]
Für unterschiedliche Führungs- und Managementzwecke muss die Unternehmensarchitektur Darstellungen mit unterschiedlichem Detailauflösungsgraf liefern. Sie sollte, umgangssprachlich formuliert, vertikale Zoom-Ins und Zoom-Outs unterstützen. Dabei gilt selbstverständlich, dass beim Zoon-In mehr Gemeinsames in Teilsystemen existiert als im ganzen System, beziehungsweise dass bei Zoom-Outs die Unternehmensarchitekturen ausdünnen.
[12]
Neben vertikalen Zoom-Ins auf Teilorganisationen oder technische Teilsysteme sollten aber auch aspektorientierte Zoom-Ins möglich sein, z.B. auf die Ablauforganisation, die IKT-Architektur oder das rechtlich vorgeschriebene Reporting.
2.4.
Multiperspektivität zur Unterscheidung von Schein und Sein ^
[13]
Zu den besonderen Schönheiten der Informatik verteilter Systeme zählt die Diffizilität des Kausalen. Wer naiv Phänomene in verteilten IKT-Systemen beobachtet, ohne die Kausalstrukturen korrekt zu konstruieren, beobachtet bisweilen Ereignisse, die es gar nicht gibt und/oder übersieht andere Ereignisse, die tatsächlich stattfinden. Grund ist, dass in diesen Beobachtungen die Kausalität verletzt wird.
[14]
Allgemeiner betrachtet sind diese inkorrekten Beobachtungen eines von vielen Beispielen, warum es in komplexen Systemen nie darum geht, maximale Transparenz zu schaffen (In der plötzlich Dinge sichtbar werden, die logisch unmöglich sind), sondern darum, eine optimale Transparenz zu schaffen, die obendrein möglichst so aufbereitet ist, dass sie einfach verarbeitet werden kann – insbesondere wenn die Informationsnutzer Menschen und nicht Maschinen sind.
[15]
Auch im Umgang mit Unternehmensarchitekturen besteht die Gefahr der Scheinbeobachtungen. Selbst dann, wenn die Architektur-Darstellungen korrekt sind, können sie leicht zu falschen Interpretationen führen, indem sie Phänomene in den Vordergrund der Wahrnehmung rücken, die mit den zu lösenden Problemen nichts zu tun haben. Ein Lehrsatz der Unternehmensarchitekten lautet deshalb, dass man so viele Darstellungen wie möglich nutzen sollte, um die Gefahr zu vermeiden, dass der Blick auf Nebensächliches verengt wird.
[16]
Anders gesagt: Multiperspektivität hilft, sich in der Welt von Schein und Sein des Informationsmanagements einer Organisation zurecht zu finden. Doch Multiperspektivität geht ihrerseits den Weg in Richtung maximale Transparenz und schafft so leider wieder neue Verirrungsmöglichkeiten. Deshalb sind Werkzeuge hilfreich, die den Umgang mit Multiperspektivität erleichtern.
2.5.
Metaperspektiven-Bilder als Erklärungsschlüssel zur Multiperspektivität ^
[17]
Ideal wären Werkzeuge, die künstlich intelligent für jedes Problem die richtige Perspektive auswählen. Leider gibt es diese nicht. Bei der Selektion der jeweils richtigen Perspektiven muss der Mensch auf seine natürliche Intelligenz und allenfalls Orientierungshilfen vertrauen. Ein besonders nützliches Werkzeug, sprich eine wirkungsvolle Orientierungshilfe im Umgang mit Multiperspektivität sind Metaperspektiven-Bilder.
[18]
Das wesentliche an ihnen ist, dass sie unterschiedliche Wirkungsbereiche nebeneinander stellen und in Beziehung zueinander setzen. Das heisst, sie erinnern den Betrachter daran, dass er eventuell mit einem ungeeigneten Frame of Reference arbeitet und sie zeigen auf, wie potentiell unterschiedliche Frames of Reference sich gegenseitig beeinflussen.
[19]
Neben generischen Mehrebenenbildern, die Grundsätzliches beschreiben, ist es auch möglich ein spezifisches Mehrebenenbild für eine Organisation anzufertigen. Vor allem die Charakterisierung der politischen Ästhetik eines Unternehmens (= die Identifikation des Beobachtbaren und des Gestaltbaren) damit ist oft hilfreich. Sie ermöglicht beispielsweise die Anwendung kulturellen Wissens, um Wirkungsmechanismen zu erkennen, die sich einer konventionellen Steuerung durch das Management entziehen. Obendrein löst sich der fiktive Klassenkampf zwischen politik- und ästhetikorientierter Betriebswirtschaftslehre und dem Transparenz-Engineering verteilter Systeme (in der Tradition von Andrew Tanenbaums Lehrbüchern) auf.
2.6.
Die Bedeutung des Visuellen ^
[20]
Wenn von Darstellungen und Bildern bisher die Rede war, so impliziert dies nicht zwingend eine Visualität. Die für Unternehmensarchitekturen wichtigen Bilder können auch durch Texte oder Formeln oder Plastiken entstehen. Vorstellbar wäre auch eine Sonifikation von Schlüsselideen der IKT-Architektur oder der Geschäftsarchitektur – oder auch eine Darstellung durch zeitgenössischen Tanz. Tatsächlich hat aber das Arbeiten mit visuellen (zweidimensionalen) Bildern Tradition in der Unternehmensarchitektur. Die Ästhetik dieser Bilder liegt im Inhalt, nicht in der Form, mit der Unternehmensarchitekten traditionell eher schlampig umgehen. (Die Bereitstellung von Software-Werkzeugen hat die formale Schlamperei leider oft sogar automatisiert). Hier besteht ein «ästhetisches» Verbesserungspotential.
[21]
Wichtiger als formale Ästhetik ist aber, dass die Medialität visuellen Gestaltens den Designprozess unterstützt, und nicht (etwa durch kompliziert zu bedienende Software) blockiert. Das Zeichnen per Hand ist deshalb (paradoxerweise) gerade für IKT-Architekten ein wichtiges Element im Architektur-Gestalten.
3.
Architektur-Arbeit, ihr Kontext und ihre Ziele ^
[22]
Unternehmensarchitekten sind in allererster Linie Zusammenführer verschiedener Sichten auf das Informationsmanagement einer Organisation. Sie sind Vermittler zwischen diesen Sichten und Erfinder von Lösungen, die in jeder wichtigen Hinsicht zufriedenstellend (aber nicht notwendigerweise optimal) sind. Ihre Arbeit hat sachliche wie soziale Aspekte und ist verwandt mit der Arbeit von Regisseuren, Choreografen und Dirigenten. Sie gehört zu jenen Tätigkeiten, bei denen Charisma hilfreich und für nachhaltige Erfolge sogar fast notwendig ist, weil es dabei um Leadership. Diese Leadership muss aber ähnlich wie bei den aufgezählten Künstlerberufen auf einem tiefen eigenen Verständnis der Zusammenhänge und auf einer eigenen Interpretation des Informationsmanagements der Organisation beruhen. Dies wirft freilich viele fragen auf, insbesondere jene nach der hierarchischen Einordnung: Ist es nicht die Aufgabe des CEO, die Rolle des Unternehmensarchitekten zu übernehmen? Wohl nicht, denn das würde die rolle des CEO überfrachten. Aber ganz offensichtlich ist hier noch viel Raum für Innovation in der Aufbauorganisation. Wir werden uns hier mit diesen Fragen nicht befassen und uns auf eine strukturierte Beschreibung des Kontexts der Architektur-Arbeit beschränken.
3.1.
Die Vier-Dimensionalität ^
[23]
Um die Architektur-Arbeit als Betrachter wie als Akteur besser verstehen zu können, ist es hilfreich, sie in einen vierdimensionalen Erklärungskontext einzubetten. Dies erleichtert auch, die Identifikation und das Verständnis der Überlappungsbereiche zwischen Unternehmensarchitektur und Rechtsinformatik.
3.1.1.
Die Stakeholder-Dimension ^
[24]
Eine Kernaufgabe der Unternehmensarchitekten ist das Stakeholder-Management. Gemeinhin ist die Intransparenz-Regel beliebt, dass das Stakeholder-Bild das einzige Dokument eines IKT-Projekts ist, das geheim bleiben muss. Ob dies wirklich sinnvoll ist, darüber lässt sich trefflich streiten. Klar hingegen ist, dass die unterschiedliche Stakeholder, ihre grundsätzlichen «öffentlichen» Rollen und ihre Perspektiven bekannt sein sollten und deshalb auch in der Unternehmensarchitektur dokumentiert werden sollten. Sonst besteht die Gefahr, die Weiterentwicklung des IKT Einsatzes für ein verbessertes Informationsmanagements gegen die «Stakeholder-Mauer» zu fahren. Sie hat zwar in der Regel komplexe Interaktionsstrukturen, ist aber bisweilen härter als jede gesetzliche Beschränkung.
3.1.2.
Die Fachperspektiven-Dimension ^
[25]
Unternehmensarchitekturen führen unterschiedliche Fachperspektiven zusammen – zuallererst die Geschäftsperspektive, die IKT-Perspektive und die juristische Perspektive, darüber hinaus aber auch potentiell andere Fachperspektiven wie z.B. die interne Kommunikationsperspektive (wenn sie als Führungsinstrument eingesetzt werden), die PR- und die Marketing-Perspektive, die politische und die volkswirtschaftliche Perspektive (etwa im E-Government), etc. Dabei hat die Geschäftsperspektive verschiedene Teilperspektiven, die nicht miteinander vermischt werden sollten – unter anderem die Werthaltung, das Geschäftsmodell und die Organisationsform. Ähnliches gilt für die anderen Fachperspektiven auch. Deshalb ist häufig eine zweistellige Zahl von Fachperspektiven zu berücksichtigen.
3.1.3.
Die Ideen-Dimension ^
[26]
Die Weiterentwicklung von IKT-Einsatz und Informationsmanagement folgt oft Schlüssel- oder Kernideen. Diese werden gemeinhin als Architekturmuster, respektive als Patterns bezeichnet. Patterns sind häufig gebrauchte, charakteristische Problemlösungen. Es gibt sie auf allen Abstraktions-, respektive Detaillierungsebenen. In den letzten Jahren sind auch viele Veröffentlichungen zu typischen, häufig wiederkehrenden falschen Problemlösungen entstanden, die als Anti-Patterns bezeichnet werden.
[27]
Patterns wie Antipatterns sind Bewohner des Raums der Ideen, der aber natürlich noch viel denkbare Architektur-Ideen umfasst. Jeder Unternehmensarchitekt hat seinen eigenen Ideenraum, den er hoffentlich lebenslang weiterentwickelt – im Austausch mit Kollegen, in realen Projekten und im Reflektieren eigener und fremder Projekte.
3.1.4.
Die Zeit-Dimension ^
[28]
Architekturen sind langlebig. «Die IKT-Architektur ist alt, die darin implementierte Geschäftslogik noch älter.» Lautet ein bekannter Satz – der so ganz nebenbei andeutet, dass gerade Teilaspekte wie die Geschäftsarchitektur eventuell Ideen aus sehr unterschiedlichen Geschäftsperioden zusammenführen, oder – frei nach Nestroys Schicksal als seltsamer Kutscher – zusammenfahren.
[29]
Solche historischen Schichten sichtbar machen zu können, würde den Umgang mit komplexen IKT um vieles erleichtern. Doch ist eine derartige historisierende Betrachtungsweise derzeit noch Zukunftsmusik. Immerhin sind meist Gegenwart und Zukunft durch IST-Architektur und SOLL-Architektur präsent. Eine Einteilung des Wegs vom IST zum SOLL erweist sich oft als hilfreich. Doch eine effektive Architekturarbeit sollte über solche Pläne in der Architekturentwicklung hinausgehen und ein Konzept der Förderung der Lernkurven bei den involvierten Akteuren beinhalten – oder auch, wir wollen die Welt nicht schöner färben als sie ist – ein Konzept für das Kaltstellen von destruktiv agierenden Akteuren, frei nach Kotters Pinguin-Prinzipien.
[30]
Doch sollte dieses Managen der Akteure mit der notwendigen Bescheidenheit geschehen. Komplexe Systeme können nicht einfach gezeichnet, gebaut, installiert und in Betrieb genommen werden. Denn sie basieren auf einem Zusammenwirken von Menschen und Maschinen. Damit die Maschinen erfolgreich funktionieren können, müssen ihre Nutzer ihre Benutzung lernen und sie müssen sich in der Benutzung als situativ geeignet erweisen. Das Lernen benötigt Zeit und möglichst auch Führung. Die Frage, was situativ geeignet ist, ist erst nach dem Lernen beantwortbar, weshalb also auch zwangsläufig die Unternehmensarchitekten Lernkurven durchlaufen müssen.
[31]
Doch auch damit ist es nicht getan. Da Software-Implementierungen so langlebig sind, ist ihre Nachhaltigkeit ein ganz wesentlicher Qualitätsaspekt. Nachhaltigkeit bedeutet freilich nicht ein möglichst langes Bewahren, sondern ein Schaffen von Zukunftsoptionen – und zwar von Veränderänderungsoptionen. Der zukünftige Veränderungswiderstand sollte möglichst gering sein, das heisst Veränderungen (von Geschäftslogik, Ablauforganisation, Technologien, Datenstandards, Implementierungen, etc.) sollten mit möglichst geringem Aufwand realisierbar sein. Um dies zu erreichen, sollten nicht nur wesentliche Gestaltungsmerkmale für reife IKT-Architekturen (und insbesondere für detaillierte Software-Architekturen) berücksichtigt werden, sondern zukünftiger Veränderungsbedarf sollte ganz generell richtig antizipiert werden.
[32]
Gutes Informationsmanagement ist nicht möglich, wenn Ressourceninseln bestehen, die nicht miteinander IKT-unterstützt vernetzt sind. Deshalb ist Ressourcenintegration ein Hauptziel, dessen Erreichung an der Unterbruchfreiheit der Vernetzung gemessen werden kann. Ressourcenintegration sollte aber nicht als Haupt- und Staatsaktion sui generis gesehen werden, sondern als Mittel zum Zweck – und der ist die Optimierung der Leistung der Organisation. (Wer Leistung in Zweifel zieht, wird früher oder später auch mit den Engineering-Traditionen der Informatik in Konflikt geraten – weshalb wir bei aller Legitimität einer politischen Antileistungshaltung diese Perspektive hier nicht diskutieren.)
[33]
Leistungsoptimierung kann in aller Regel nicht durch maximalen Einsatz der verfügbaren, integrierten Informationsressourcen entstehen, sondern durch den richtigen Einsatz – das heisst, durch das zur Verfügung Stellen der richtigen Ressourcen in der richtigen Weise. Genau dies hat das Transparenz-Engineering zum Ziel.
[34]
Eine genauere Analyse zeigt, dass es zwischen den drei skizzierten Zielkomplexen ein enges Zusammenspiel gibt, dessen Verständnis für die Arbeit des Unternehmensarchitekten essentiell ist. Doch die detaillierte Darstellung dieses Zusammenspiels ginge (wie andere Vertiefungen auch) weit über den Rahmen dieses Beitrags hinaus.
[35]
Wir machen es uns deshalb einfach: Das eigentliche, wahre und wahrhaftige Ziel der Unternehmensarchitekten-Arbeit ist die Optimierung der Transparenz in der Organisation. Cum grano salis lassen sich aus diesem Ziel die anderen beiden Ziele – und letztlich alle für die Unternehmensarchitekten primär wichtigen Ziele – ableiten.
3.2.
Das Transparenz-Ziel ^
[36]
Transparenz steht in der IKT traditionell für das Verbergen von unwichtigen Informationen (Information Hiding) und das gleichzeitige Bereitstellen der wirklich wichtigen Informationen. Dies verlangt eine saubere Strukturierung der IKT-Architektur in Tiers, Layers und Komponenten mit wohldefinierten, korrekt implementierten Schnittstellen. Vater des Strukturierens ist stets der Wille, das WAS vom WIE zu trennen, egal ob es um einen Gerätetreiber, einen Browser, eine Applikationskomponente oder um was auch immer geht.
[37]
Betrachtet man die Geschichte der Informatik, so erkennt man die fundamentale Rolle des Wunsches, das WAS vom WIE zu trennen. Sie spiegelt sich wieder in den stetigen Versuchen und dem wachsenden Erfolg, die Software-Entwicklung auf ein möglichst hohes Abstraktionsniveau zu heben, so dass (Wunschdenken) irgendwann Fachexperten selber ohne vertiefte IKT-Kenntnisse ihre Fachapplikationen entwickeln können – was aus Sicht der IKT einem besonders hohen (hier gleichzusetzen mit optimalen) Transparenz-Level entspricht.
[38]
Daraus lässt sich erahnen – eine vollständige Diskussion ginge weit über den Rahmen dieses Beitrags hinaus – dass hohe Transparenz gut passt zu einem aus Geschäfts- und Organisationsperspektive möglichst optimalen IKT-Einsatz. Die wirkliche Herausforderung für Unternehmensarchitekten besteht dementsprechend auch darin, das IKT-bezogene Transparenz-Engineering auf das Menschen-Maschinen-System als Ganzes auszudehnen.
3.3.
Die Erweiterung des Anwendungsbereichs für Transparenz-Engineering ^
[39]
Das Ausdehnen der Ziele und Methoden der Informatik auf ihren Anwendungsbereich mag manchen eine unzulässige Grenzüberschreitung scheinen. Sie ist zweifelsohne ein Verbrechen gegen die guten Sitten – allerdings ein vernünftiges. Grund ist, dass es universelle Probleme und Lösungsgrundsätze für das Informationsmanagement gibt, die für Maschinen wie für Organisationen gelten. Universelle Problem mit quasi «homomorphen» Lösungskonzepten in unterschiedlichen Anwendungsbereichen sind beispielsweise
- Organisation: Die Strukturierung von Organisationen, so dass überschaubare, gut führbare Bereiche entstehen, die die Orientierung erleichtern: Hier gibt es z.B. einen engen Zusammenhang zwischen funktionaler Organisation und Tier/Layer Strukturen (und auch zwischen Spartenorganisation und dem Einsatz von Domain Interfaces in CORBA) , sowie in gewisser weise zwischen der Matrix-Organisation und SOA-Architekturen (letzteres mindest in Bezug auf die resultierenden Probleme).
- Komponentisierung: Die Aufteilung der Logik auf unabhängige Komponenten mit klar definierter Interaktionsschnittstelle und semantischer Funktionsbeschreibung, so dass die eigentliche Realisierung der Funktion als Black Box erscheint: Hier gibt es z.B. eine enge Verwandtschaft zwischen der Transformationstheorie der Leistungsoptimierung und der Strukturierung von Software in Komponenten, welche dazu führt, dass der Enterprise Application «Turm» in der Turmschicht «Prozesse und Dienste» eine ähnliche Struktur aufweist, wie in den Turmschicht Applikationen.
- Verteilung: Die Verteilung von Daten, Bearbeitungsressourcen, Bearbeitungsintelligenz und Entscheidungskompetenzen in einem verteilten System, so dass unter Praxisrestriktionen optimale Entscheidungen getroffen werden können: Hier gibt es z.B. eine enge Verwandtschaft zwischen dem Subsidiaritätsprinzip der öffentlichen Verwaltung und der Event-Vorverarbeitung in Echtzeit-IKT-Systemen.
- Führung: Die Etablierung einer Führung, basierend auf Abstraktionen, die die Detailkomplexität verbergen und trotzdem eine inhaltliche Zielvorgabe und Zielerreichungsmessung ermöglichen: Hier gibt es z.B. nicht nur einen engen Zusammenhang zwischen zyklischen bzw. spiralförmigen Konzepten in der Politikgestaltung (Policy Cycle) oder Führung von Organisationen und der Ablaufgestaltung von Software-Projekten, sondern auch zwischen dem Herunterbrechen abstrakter Zielvorgaben des Topmanagements auf konkrete Arbeitsaufträge und der automatisierten Umsetzung von hochabstrakten «Policies» oder Eigenschaftsattributen.
[40]
Es gäbe noch einige Beispiele mehr, zumal in den letzten Jahren zunehmend die Informatik strukturprägend für die Organisationsgestaltung auftritt. Wenn etwa im E-Government die Trennung von Leistungserbringung und Leistungsvertrieb gefordert wird, ist das ganz offensichtlich durch 2-Tier Architekturmuster der Informatik inspiriert. Und wenn gar die Trennung von Ausführung, Kontrolle und Vertrieb gefordert wird, so kann man das als 3-Tier-Architektur ansehen. Etc.
[41]
Generell wird durch das Ausdehnen des Transparenz-Engineerings auf den Anwendungsbereich eine Reduktion der Komplexität durch eine methodische Systemzerlegung nebst einer Zusammenführung der resultierenden Teilsysteme über wohldefinierte Schnittstellen erreicht. Um eine höhere Abstraktion zu erreichen, sind ergänzend Ontologien notwendig, die möglichst in der Laufzeitumgebung eingebaut sein sollten.
4.
Die resultierende Sicht auf die Rechtsinformatik ^
[42]
Aus der Beschreibung der Arbeit von Unternehmensarchitekten ergibt sich ein «natürlicher» und tatsächlich recht enger Bezug zur Rechtsinformatik. Die Rechtsinformatik-Expertise zählt zu den Kernkompetenzen des Unternehmensarchitekten. Zudem lassen sich im Unternehmensarchitekten-Universum wichtige Forschungsfelder der Rechtsinformatik definieren.
4.1.
Die Beziehung der Unternehmensarchitekten zur Rechtsinformatik ^
[43]
Für die Unternehmensarchitekten ist es zuallererst wichtig, die fachdisziplinäre Perspektive der Rechtsinformatik in ihrer Arbeit zu berücksichtigen. Das bedeutet konkret, sie müssen imstande sein, die Rechtskonformität der Architektur verifizieren zu können, beziehungsweise potentielle Konflikte der Architektur mit existierenden Gesetzen und Regulierungen identifizieren zu können.
[44]
Um dies tun zu können, müssen die von ihnen verwendeten Architekturdarstellungen für eine Rechtskonformitätsprüfung geeignet sein. Das heisst, sie müssen einen passenden Abstraktionsgrad und einen passenden Detaillierungsgrad aufweisen. Zudem sollten sie für Rechtsinformatiker gut lesbar sein, um deren Expertise bei der Validierung und Verifizierung der Architekturen hinzuziehen zu können.
[45]
Daneben sind aber Rechtsinformatiker auch wichtige Stakeholder, insofern es darum geht, auf die Rechtssetzung sinnvoll einzuwirken. Das gilt insbesondere für das E-Government, das durch das öffentliche Recht wesentlich bestimmt ist, ist aber auch in der Wirtschaft oft notwendig. Gerade wenn Gesetze aus Zeiten stammen, in denen die heutigen Technologien noch nicht existierten, ist manchmal der Versuch, auf eine Anpassung von Gesetzen und Verordnungen hinzuwirken, sinnvoller, als Gesetze wieder Geschäfts- und IKT-Logik vollumfänglich zu implementieren.
[46]
Manche Unternehmen haben sich in der Vergangenheit auch bewusst und ohne je dafür kritisiert zu werden, für eine schwerwiegende Gesetzesverletzung im Architekturdesign entschieden. Bisweilen sind Parlament, Regierung und Behörden gar nicht auf dem Laufenden über etablierte wirtschaftliche Umgehungspraktiken. Dies zeigt umgekehrt, dass auch die Unternehmensarchitekten für die Rechtsinformatiker ein wichtiger Partner sind. Diesen Kontakt intensiver zu pflegen, könnte helfen, das Problembewusstsein für Gesetzesverstösse – oder auch für den Bedarf nach Überarbeitung von Gesetzen – zu schärfen. Beispielsweise könnte es Diskussionen zur anstehenden Regulierung der digitalen Identität befördern.
[47]
Darüber hinaus – und am besten aufbauend auf engen Kontakt mit den zuständigen Behörden – gilt es für Unternehmensarchitekten, die Rechtsentwicklung gerade bei der Gestaltung der zeitlichen Perspektive richtig zu antizipieren. Je zentraler die Rolle der IKT für die Geschäftstätigkeit in einer Branche wird, desto mehr rücken Regulierungen ins Blickfeld der Architekturarbeit. Nicht zuletzt sollten Unterschiede in den nationalen Regulierungen in Software so implementiert werden, dass der Austausch eines kleineren Softwaremoduls genügt, um Software in einem anderen Land einsetzen zu können. Dies stellt beispielsweise in der Finanzinformatik eine der aktuell grössten Herausforderungen dar.
[48]
Schliesslich und endlich verdient die Rechtsinformatik auch im Raum der Ideen mehr Beachtung. Gerade im Bereich des Datenschutzes lassen sich Patterns und Anti-Patterns gut identifizieren. Zudem ist die Diskussion der Rechtsinformatik-Aspekte verschiedener genereller Architektur-Patterns und Anti-Patterns gut geeignet, grundsätzliche rechtliche Fragestellungen exemplarisch zu thematisieren und zwischen Unternehmensarchitekten und Rechtsinformatikern zu diskutieren.
4.2.
Die Rechtsinformatik-Probleme und offenen Fragen der Unternehmensarchitekten ^
[49]
So natürlich auch der Bezug der Architektur-Arbeit zur Rechtsinformatik ist, so schwierig ist doch die Zusammenarbeit. Zu verschieden sind Informatik und Rechtswissenschaft. Die Regulatoren, die in die Unternehmensarchitekturen eingreifen, etwa mit SOX, sind sich dessen oft kaum bewusst. Und Unternehmensarchitekten, die aus der Informatik kommen, tun sich oft sehr schwer mit der Vorstellung, Architektur-Ideen könnten nicht rechtskonform sein. Metaperspektiven Bilder könnten hier auf beiden Seiten Problembewusstsein schaffen, wenn es sie denn gäbe. Hier wie an vielen anderen Ecken, Enden und Wurzeln gibt es grossen Forschungs- und Entwicklungsbedarf.
[50]
Grosse offene Fragen an die Rechtsinformatik aus Sicht der Unternehmensarchitekten gibt es aber mehr: sowohl auf inhaltlicher Ebene als auch im Bereich der Darstellungsmethoden und im Bereich der Designmethoden. Die Theaterphrase «Der Vorhang zu und alle Fragen offen.» würde hier daran scheitern, dass man die vielen Fragen kaum mit dem Vorhang zudecken kann.
[51]
Inhaltlich tauchen vor allem im Transparenz-Engineering immer wieder neue Fragen auf: Welche Information muss ich wem wann zur Verfügung stellen, beziehungsweise zur Verfügung stellen können? Was fordert hierbei die Gesetzeslage? Das ist quasi die Mutter aller Fragen. Sie hat neben der «Tagseite» des Informationsbereitstellens (inklusive vorgängigen Informationssammelns) auch die «Nachtseite» des Informationslöschens. Die gesetzliche Anforderung sind für letztere teils unklar, teils bestehen gute Gründe, sie zu überprüfen und eventuell anzupassen.
[52]
Für die Geschäftsarchitektur und die Implementierung der Geschäftslogik ebenfalls wichtig ist die Frage, wie denn auf das verfügbar Werden von gewissen kritischen Informationen reagiert werden muss. (Dies ist ein Thema, das auch aus Sicht des Verbraucherschutzes intensiver diskutiert werden sollte.) Und für die Architekturgestaltung insgesamt ist es auch wichtig zu verstehen, wie Gerichte mit grundsätzlich nicht generierbaren Informationen umgehen: Konkret etwa, wie Gerichte Geschehen in virtuellen Speichern beurteilen (wenn der Ort von Information nicht lokalisierbar ist).
[53]
Das Auftauchen stets neuer offener Fragen wird durch Dreierlei getriggert: Einerseits kommen immer wieder neue, innovative Technologien in Anwendung, die entweder ganz neue Möglichkeiten der Informationsverarbeitung schaffen oder theoretisch existierende Möglichkeiten für viel grössere Benutzerzahlen als in der Vergangenheit nutzbar machen. Andererseits wächst die Komplexität der existierenden Unternehmensarchitekturen durch die Implementierung neuer Geschäftsfunktionen stetig an. Schliesslich und endlich führt die wachsende verfügbare Rechenkapazität zusammen mit Erfolgen bei der Anwendung künstlicher Intelligenz dazu, dass Informationen, die bislang unberechenbar waren, berechenbar werden und so existierende Regulierungen in Frage stellen.
[54]
Im Bereich der Darstellungsmethoden fehlen etablierte Standardsichten auf (= standardisierte Darstellungsmethoden für) die IKT-Nutzung und das Informationsmanagement einer Organisation, die eine rechtliche Validierung und Verifizierung erlauben würden. Dabei geht es auch, aber nicht nur ums IAM (Identity and Access Management). Inkompatibilitäten mit geltendem Recht sind unter anderem auch bei den Ablaufstrukturen möglich, von der Geschäftslogik und dem Handling von Geschäftsinformationen ganz zu schweigen. Wie die Schnittstelle des Artefakts Unternehmensarchitektur für Rechtsinformatik-Spezialisten aussehen sollte, wurde bislang kaum erforscht. .Auch zum Einbezug von Rechtsinformatikern in Architektenteams gibt es bislang kaum Best Practices.
[55]
Im Bereich der Designmethoden bestehen vor allem im E-Government und im E-Business Bedarf nach Methoden, die ein Ableiten von Geschäftsarchitekturen aus Gesetzen unterstützen und eine Regulierungsfolgenabschätzung auf Ebene des operativen Geschäfts von Behörden, respektive Unternehmen, und der benötigten IKT-Dienste möglich machen. Die Lösungsansätze waren bislang bescheiden erfolgreich. Sie klaffen derzeit paradigmatisch sehr weit auseinander: von der Anwendung künstlicher Intelligenz bis hin zur Beschränkung auf die methodische Anforderungsspezifikation.
5.
Zusammenfassung und Ausblick ^
[56]
Die Forschungsfragen kommen aus der Notwendigkeit heraus, das Transparenz-Engineering bei der der Integration unterschiedlichster Ressourcen rechtskonform zu gestalten. Die drei wichtigsten Themenkomplexe sind dabei: Inhaltliche Gestaltung von Transparenz, Methoden zur Darstellung der rechtlichen Architektursicht als Teil der Unternehmensarchitektur und Designmethoden für rechtsgetriggerte Veränderungen der Unternehmensarchitektur. Der Fortschritt bei Hardware, Software und deren Anwendung fördert zudem das Entstehen von neuem Regulierungsbedarf.
[57]
Die vielleicht grösste Herausforderung besteht darin, das unterschiedliche Denken von Informatikern, Juristen (und natürlich den jeweiligen Geschäftsbereich-Spezialisten) zusammenzuführen, um transdisziplinäre Lösungen entwickeln zu können. Hier könnte die Rechtsvisualisierung grosse Dienste leisten, da visuelles Darstellen zu den Kernkompetenzen von Unternehmensarchitekten gehört.
[58]
Bislang zu wenig Beachtung fand in der Forschung wie in der Praxis die Auseinandersetzung mit der Zeitdimension der Architekturarbeit. Auch das Zusammenspiel von fachlogischen Aspekten und sozialen Aspekten wäre tiefere Untersuchungen wert. Wie überhaupt mehr empirische Forschung sehr wünschenswert wäre, auch wenn sie eine enge und insofern allenfalls problematische Zusammenarbeit zwischen Universitäten und Hochschulen auf der einen Seite und der Wirtschaft und Behörden auf der anderen Seite erfordert.
[59]
Wichtig wäre vor allem anderen aber, dass die aktuelle und zukünftige Forschung in Form von Modellen das Handwerkszeug liefert, um rechtliche Aspekte des Transparenz-Engineerings im Rahmen der Unternehmensarchitekturentwicklung sachlich konstruktiv über Disziplinengrenzen hinweg diskutieren zu können.
Reinhard Riedl,Leiter Forschung und Dienstleistungen, Berner Fachhochschule,, Fachbereich Wirtschaft und Verwaltung,Morgartenstrasse 2c, Postfach 305, 3000 Bern 22, CH,Reinhard.riedl@bfh.ch ,http://wirtschaft.bfh.ch
Reinhard Riedl,Leiter Forschung und Dienstleistungen, Berner Fachhochschule,, Fachbereich Wirtschaft und Verwaltung,Morgartenstrasse 2c, Postfach 305, 3000 Bern 22, CH,Reinhard.riedl@bfh.ch ,http://wirtschaft.bfh.ch
