Generischer Architektursichten: Erzeugung und Visualisierung kontextspezifischer Sichten am Beispiel serviceorientierter Architekturen

Thorsten Spies Generische Architektursichten

GABLER RESEARCH Information Engineering und IV-Controlling Herausgegeben von Professor Dr. Franz Lehner, Universität Passau (schriftführend), Professor Dr. Stefan Eicker, Universität Duisburg-Essen, Professor Dr. Ulrich Frank, Universität Duisburg-Essen, Professor Dr. Erich Ortner, Technische Universität Darmstadt, Professor Dr. Eric Schoop, Technische Universität Dresden

Die Schriftenreihe präsentiert aktuelle Forschungsergebnisse der Wirtschaftsinformatik sowie interdisziplinäre Ansätze aus Informatik und Betriebswirtschaftslehre. Ein zentrales Anliegen ist dabei die Pflege der Verbindung zwischen Theorie und Praxis durch eine anwendungsorientierte Darstellung sowie durch die Aktualität der Beiträge. Mit der inhaltlichen Orientierung an Fragen des Information Engineerings und des IV-Controllings soll insbesondere ein Beitrag zur theoretischen Fundierung und Weiterentwicklung eines wichtigen Teilbereichs der Wirtschaftsinformatik geleistet werden.

Thorsten Spies

Generische Architektursichten Erzeugung und Visualisierung kontextspezifischer Sichten am Beispiel serviceorientierter Architekturen Mit einem Geleitwort von Prof. Dr. Stefan Eicker

RESEARCH

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Universität Duisburg-Essen, 2010

1. Auflage 2011 Alle Rechte vorbehalten © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011 Lektorat: Stefanie Brich | Anita Wilke Gabler Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.gabler.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8349-2854-2

Geleitwort Eine bzw. die entscheidende Weichenstellung für die Softwareentwicklung war zweifelsohne der Ansatz des Softwareengineering, wie er 1968 auf der legendären NATO-Konferenz in Garmisch entwickelt wurde: Softwareentwicklung sollte nicht länger ein weitgehend unstrukturierter/künstlerischer Prozess sein, sondern sich vielmehr an den Ingenieurdisziplinen orientieren. Ein enormer Aufwand ist seitdem in die Entwicklung adäquater Vorgehensweisen, Methoden und Werkzeuge investiert worden. Zu einem nicht unerheblichen – allerdings insgesamt eher unbefriedigenden – Teil haben die entwickelten Ansätze den Weg in die Praxis gefunden. Die sich durch ihren Einsatz ergebenden Vorteile sind aber durch die rasant gestiegene Komplexität der Anforderungen an die IT-Systeme und die zwangsläufig im gleichen Maße gestiegene Komplexität der Systeme überwiegend „aufgebraucht“ worden. Als Folge können Softwareentwicklungsprojekte insbesondere abhängig von der Komplexität des zu realisierenden Systems vielfach ihre Ressourcenvorgaben nicht einhalten bzw. scheitern sogar in Gänze; zudem verursachen die realisierten Systeme hohe Wartungskosten. Eine wesentliche Rolle bei der Beherrschung der Komplexität von Softwaresystemen spielen die Software-Artefakte, die für die Realisierung und das Management eines Systems entwickelt werden. Sie dokumentieren die zu berücksichtigenden Aspekte des Systems und dies aus den verschiedenen Perspektiven auf das System. Zudem bilden sie die Grundlage für die Kommunikation zwischen den verschiedenen Stakeholdern des Systems. Insbesondere mit der Einführung serviceorientierter Architekturen (SOA) hat sowohl die Anzahl und Ausrichtung der Stakeholder als auch die Komplexität der abzubildenden Artefakte weiter zugenommen. Dies ergibt sich u.a. daraus, dass bei SOA im Fokus der Betrachtung nicht mehr das einzelne Softwaresystem, sondern alle Systeme eines Bereichs eines Unternehmens bzw. sogar alle Systeme des Unternehmens stehen. Eine wesentliche Voraussetzung zur Beherrschung von SOA ist, dass jedem Stakeholder jeweils genau die Informationen zur Verfügung gestellt werden können, die er benötigt, und dies in einer geeigneten Darstellungsform. Folgerichtig macht Herr Spies die Forschungsfrage zum Gegenstand seiner Dissertation, wie im Kontext serviceorientierter Architekturen und der damit verbundenen Vielzahl unterschiedlicher Interessen (Concerns) und Perspektiven die adäquate Informationsversorgung der Stakeholder gewährleistet werden kann. Als Lösung entwickelt Herr Spies in seiner Arbeit den Ansatz der Generischen Architektursichten auf SOA-basierte Systeme. Diese Sichten werden unter Berücksichtigung von Relevanzkriterien unterschiedlicher System/Umwelt-Konstellationen kontextspezifisch erzeugt und stellen die jeweils relevanten Aspekte dar. Das den Sichten zu Grunde liegende Modell umfasst „Profile“, die die Kombination von spezifischen Aufgaben und Rollen reprä-

VI

Geleitwort

sentieren, „Informationen“, die quasi die rein technischen Aspekte der SOA erfassen, sowie den „Kontext“, der im Ergebnis die Verbindung zwischen Profil und Information herstellt. Bei der Entwicklung des Generischen Sichtenkonzepts gelingt es Herrn Spies, die unterschiedlichen zu berücksichtigenden Teilkonzepte zu identifizieren, zu strukturieren und zu integrieren. Dabei bindet er bestehende bewährte Konzepte für das Architekturmanagement ein bzw. ergänzt sie geeignet, sofern es erforderlich ist. Die Entwicklung erfolgt unter Berücksichtigung der Charakteristika und der Anforderungen komplexer Systeme. Zur visuellen Präsentation der Sichten entwirft Herr Spies eine dreidimensionale Darstellungsform. Zwar abstrahiert das Generische Sichtenkonzept grundsätzlich von der Darstellungsform; Herr Spies hat jedoch von Beginn seiner Überlegungen zu den Sichten an auf 3-DDarstellungen fokussiert, und es ist ihm gelungen, ein innovatives Visualisierungskonzept zu gestalten, das den Ansatz der Generischen Sichten perfekt abrundet. Die Arbeit besticht jedoch nicht nur durch die ausgeprägte Innovationsfähigkeit ihres Autors. Sie ist zudem geprägt von einer klar strukturierten Vorgehensweise sowie von einer perfekten Sachkunde, die Herr Spies im Bereich des Themas der Arbeit besitzt bzw. sich in Bezug auf benötigte Ergebnisse und Denkansätze aus anderen Gebieten auch teilweise zusätzlich systematisch erarbeitet hat. Zudem führt Herr Spies den Leser virtuos auch durch die anspruchsvollsten Themen seiner Arbeit. Insgesamt erfüllt die Arbeit die Anforderungen/Informationsbedürfnisse ganz unterschiedlicher Leser. Insbesondere kann sich der IT-Manager einen hervorragenden Überblick über das Architekturmanagement – gerade im Zusammenhang mit serviceorientierten Architekturen – und die Einbindung des Architekturmanagements in das strategische Informationsmanagement verschaffen. Wissenschaftler im Bereich des Softwareengineering werden u.a. an der Auseinandersetzung mit der Erklärung der Komplexität bei der Entwicklung und beim Management betrieblicher Anwendungssysteme interessiert sein; diese Auseinandersetzung beschränkt sich nicht auf die spezifische Diskussion in der Literatur, sondern bezieht mit der soziologischen Systemtheorie, systemischen Denkansätzen und der Management-Kybernetik auch die Diskussion der Komplexität in anderen wissenschaftlichen Disziplinen ein. Beide genannten Lesergruppen sowie auch Praktiker im Bereich der Softwareentwicklung und SOA werden durch den entwickelten Ansatz der Generischen Sichten und ihrer dreidimensionalen Darstellung fruchtbare Impulse für die Beherrschung von SOA erhalten.

Prof. Dr. Stefan Eicker

Vorwort Trotz eines enormen Aufwands, der in den vergangenen Jahrzehnten in die Erforschung und Entwicklung von Vorgehensweisen, Methoden und Werkzeugen investiert wurde und nach wie vor wird, bleibt das Management betrieblicher Anwendungssysteme aufgrund einer immer weiter steigenden Komplexität von ressourcen- und kostenintensiven Prozessen geprägt. Demgegenüber stehen eine schnell wachsende Nachfrage nach Software und neuen Funktionalitäten, die Forderung nach immer kürzeren Entwicklungszyklen mit höheren Qualitätsanforderungen sowie sinkende oder bestenfalls gleich bleibende Budgets bei den Investitionen in Softwaresysteme. Das vorliegende Buch setzt sich intensiv mit der Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme auseinander und eröffnet mit der Entwicklung des Generischen Sichtenkonzepts neue Möglichkeiten, zu einer Verbesserung der Beherrschbarkeit von Komplexität beizutragen. Der Fokus ist dabei vor allem auf den Bereich des Architekturmanagements im Kontext serviceorientierter Architekturen (SOA) gerichtet. In der Auseinandersetzung mit der Komplexitätsproblematik werden unterschiedliche wissenschaftliche Disziplinen und Theorien herangezogen und auf deren Komplexitätsverständnis zurückgegriffen. Dabei stehen insbesondere die allgemeine Theorie sozialer Systeme von Luhmann, systemische Denkansätze und die Management-Kybernetik im Vordergrund der Betrachtungen, um die bei der Entwicklung und beim Management betrieblicher Anwendungssysteme relevanten sozialen Systeme und deren Komplexität zu erklären. Das Generische Sichtenkonzept liefert einen Ansatz, der durch die Erzeugung und Visualisierung kontextspezifischer Sichten auf SOA-basierte Systeme zu einer erhöhten Informationsversorgung von Stakeholdern sowie einer besseren Informationsverarbeitung – insbesondere in Bezug auf Aspekte der Kommunikation – beiträgt. Kontextspezifische Erzeugung bedeutet in diesem Zusammenhang, alle relevanten Aspekte in Bezug auf die Fragestellungen (Concerns) eines Stakeholders „on demand“ und „just in time“ zur Verfügung stellen zu können. Im Hinblick auf die Visualisierung von Sichten werden insbesondere der Einsatz von 3-DDarstellungsformen, -Techniken und -Technologien diskutiert und untersucht. Als Proof-ofConcept sowie zur Evaluation des Konzepts dient ein Prototyp, mit dessen Hilfe Informationsbedarfe beschrieben und Generische Sichten erzeugt sowie dreidimensional visualisiert werden können. Das Buch richtet sich sowohl an Theoretiker als auch an Praktiker. Das vorliegende Generische Sichtenkonzept stellt aus theoretischer Sicht eine innovative Ausgangsbasis für zahlreiche weitere Forschungsarbeiten, insbesondere im Bereich der Architekturforschung, zur Verfügung. Mit seinem stark anwendungsorientierten Fokus und allgemeingültigen Charakter bietet es gleichzeitig den Freiraum für unternehmensspezifische Anpassungen und Implemen-

VIII

Vorwort

tierungen und ermöglicht es somit, ein nachhaltiges Architekturmanagement im praktischen Umfeld zu unterstützen. Die vorliegende Arbeit entstand während meiner Tätigkeit als Doktorand am Lehrstuhl für Wirtschaftsinformatik und Softwaretechnik des Instituts für Informatik und Wirtschaftsinformatik und des Instituts paluno – The Ruhr Institute for Software Technology der Universität Duisburg-Essen. Zum Entstehen und Gelingen meiner Dissertation haben viele Menschen in meinem Umfeld beigetragen, denen ich an dieser Stelle ganz herzlich danken möchte. Mein aufrichtiger Dank gilt insbesondere meinem Doktorvater Professor Dr. Stefan Eicker, der mir große Freiheiten für meine Ideen und die inhaltliche Gestaltung meines Themas ließ, mir ein hervorragendes wissenschaftliches Umfeld bot, die Arbeit stets förderte und mir durch seine zahlreichen Ratschläge immer eine große Hilfe war. Des Weiteren danke ich Professor Dr. Reinhard Jung von der Universität St. Gallen für seine umfassende Unterstützung, die motivierenden Gespräche und die Übernahme des Zweitgutachtens. Herzlich bedanken möchte ich mich bei meinen (teilweise ehemaligen) Kolleginnen und Kollegen beider Institute, der Fakultät Wirtschaftswissenschaften und anderer Fakultäten der Universität Duisburg-Essen, die mich in den unterschiedlichen Phasen der Dissertation vielfältig unterstützt haben und mir immer wieder wertvolle Denkanstöße gaben. Mein persönlicher Dank gilt insbesondere Jessica Neuhaus, Annett Nagel, Margret Hering, Widura Schwittek, Michael Beul, Tim Gottschalk, Dr. Stefan Malich, Thomas Hofmann, Dirk Schwarze, Peter Schuler, Jens Peter Schuler und Thomas Baumeister für die motivierenden Worte, die ausgezeichnete Zusammenarbeit und das tolle Arbeitsumfeld sowie die vielen Anregungen durch unsere zahlreichen fachlichen Diskussionen. Außerdem bedanke ich mich bei den wissenschaftlichen und studentischen Hilfskräften André Diermann und Roman Barski sowie meinen ehemaligen Diplomanden Malte Goddemeier, Christian Kahl, Florian Witteler und Stefan Sockel. Spezieller Dank gebührt meiner Familie und meinen Freunden, die mich stets unterstützt und in meinem Vorhaben immer wieder bestärkt haben. Insbesondere danke ich meinen Eltern Gudrun und Axel Spies dafür, dass sie mir alles Notwendige für das Gelingen meiner Promotion mit auf den Weg gegeben haben. Ihre Erziehung, ihr Rückhalt und ihre uneingeschränkte Förderung meiner Ausbildung haben das Entstehen dieser Arbeit erst ermöglicht. Mein größter Dank gilt meiner zukünftigen Frau Julia, die mich mit ihrer Liebe, ihrer Geduld und ihrem Verständnis immer unterstützt und durch alle Höhen und Tiefen meiner Promotion begleitet hat. Thorsten Spies

Inhaltsverzeichnis Abbildungsverzeichnis ........................................................................................................ XIII Tabellenverzeichnis ........................................................................................................... XVII Abkürzungsverzeichnis....................................................................................................... XIX 1 Einleitung ............................................................................................................................ 1 1.1 Problemstellung und Motivation.................................................................................... 1 1.2 Zielsetzung und Forschungsfragen ................................................................................ 3 1.3 Forschungsmethode ....................................................................................................... 5 1.4 Aufbau der Arbeit .......................................................................................................... 8 2 Grundlagen und Begriffe ................................................................................................. 13 2.1 Betriebliche Informations- und Anwendungssysteme ................................................. 13 2.2 Informationsmanagement ............................................................................................ 17 2.2.1 Ziele und Aufgaben des Informationsmanagements .......................................... 17 2.2.2 Informationsangebot und Informationsbedarf .................................................... 19 2.3 Architekturen ............................................................................................................... 20 2.3.1 Architekturbegriff ............................................................................................... 21 2.3.2 Unternehmensarchitektur ................................................................................... 23 2.3.3 Architekturmodelle und -Frameworks ............................................................... 27 2.3.4 Architekturmanagement im Rahmen des IM ..................................................... 34 2.4 Computergestützte Visualisierung ............................................................................... 35 2.4.1 Grundlegendes Verständnis der Visualisierung ................................................. 35 2.4.2 Ziel und Zweck der Visualisierung .................................................................... 37 2.4.3 Anforderungen an die Visualisierung ................................................................. 37 2.4.4 Visualisierungspipeline ...................................................................................... 38 2.4.5 Visuelle Variablen .............................................................................................. 40 2.4.6 Softwarevisualisierung ....................................................................................... 41 2.5 Verwandte Arbeiten ..................................................................................................... 45 2.5.1 Bauhaus-Projekt ................................................................................................. 46 2.5.2 Software- und Systemkartographie .................................................................... 49 2.5.3 Zusammenfassung der vorgestellten Ansätze .................................................... 53 3 Serviceorientierte Architekturen .................................................................................... 55 3.1 Grundlagen serviceorientierter Architekturen ............................................................. 55

X

Inhaltsverzeichnis

3.1.1 SOA-Definitionen............................................................................................... 56 3.1.2 SOA-Prinzipien .................................................................................................. 59 3.1.3 SOA-Erfolgsfaktoren .......................................................................................... 60 3.1.4 SOA- und Unternehmensarchitekturen .............................................................. 61 3.2 Bestandteile und Ebenen serviceorientierter Architekturen......................................... 63 3.2.1 Services............................................................................................................... 64 3.2.2 Servicetypen ....................................................................................................... 65 3.2.3 SOA-Abstraktionsschichten ............................................................................... 67 3.3 Governance im Kontext serviceorientierter Architekturen .......................................... 73 3.3.1 Einordnung und Abgrenzung der SOA-Governance .......................................... 74 3.3.1.1 Corporate Governance............................................................................ 74 3.3.1.2 IT-Governance ....................................................................................... 75 3.3.1.3 Architecture Governance........................................................................ 78 3.3.1.4 SOA-Governance ................................................................................... 79 3.3.2 SOA-Governance-Ansätze ................................................................................. 82 3.4 SOA-Rollen.................................................................................................................. 85 3.4.1 Rollen-Framework nach Kajko-Mattson et al. ................................................... 86 3.4.2 Rollen nach Bieberstein et al. ............................................................................. 90 3.4.3 SOA-spezifische Rollen nach Erl ....................................................................... 92 3.5 Zusammenfassung........................................................................................................ 95 4 Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme ......................................................................................................... 97 4.1 Einführung in die Komplexitätsproblematik ............................................................... 97 4.1.1 Analogie zum Städtebau ................................................................................... 100 4.1.2 Der Faktor Mensch ........................................................................................... 101 4.1.3 Forderung nach systemischen Ansätzen ........................................................... 102 4.2 Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien ........................................................................................... 106 4.2.1 Systembegriff ................................................................................................... 106 4.2.2 Komplexität und Hierarchie ............................................................................. 108 4.2.3 Soziologische Systemtheorie ............................................................................ 108 4.2.3.1 „Neue“ Systemtheorie .......................................................................... 109 4.2.3.2 Komplexität, Selektionszwang und Kontingenz .................................. 111 4.2.3.3 Soziale Systeme.................................................................................... 113 4.2.4 Systemische Denkansätze ................................................................................. 117

Inhaltsverzeichnis

XI

4.2.5 Management-Kybernetik .................................................................................. 121 4.3 Softwareevolution und Komplexität .......................................................................... 124 4.4 Komplexität softwaretechnischer Systeme ................................................................ 126 4.4.1 Arten von Komplexität ..................................................................................... 128 4.4.2 Komplexitätsmaße ............................................................................................ 130 4.5 Zwischenfazit ............................................................................................................. 132 4.5.1 Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme ........................................... 132 4.5.2 Probleme der Informationsverarbeitung im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme ..................................... 135 5 Sichtenkonzepte .............................................................................................................. 139 5.1 Architekturbeschreibung und -dokumentation .......................................................... 139 5.2 Softwarearchitektursichten ........................................................................................ 142 5.2.1 Kruchten „4+1“-Sichtenmodell ........................................................................ 142 5.2.2 SEI‘s „Views and Beyond“ .............................................................................. 144 5.3 Unternehmensarchitektur- und SOA-Sichten ............................................................ 149 5.4 Sichtendilemma.......................................................................................................... 154 6 Generische Sichten ......................................................................................................... 163 6.1 Zielsetzung und Definition ........................................................................................ 163 6.2 Prämissen ................................................................................................................... 164 6.3 Anforderungen ........................................................................................................... 166 6.4 Modell Generischer Sichten ....................................................................................... 167 6.4.1 Profile ............................................................................................................... 168 6.4.1.1 Profildimensionen ................................................................................ 170 6.4.1.2 Parametrisierung von Dimensionsausprägungen ................................. 174 6.4.1.3 Regelsystem zur Einschränkung der Kombinationsmöglichkeiten von Dimensionen und Dimensionsausprägungen ................................ 174 6.4.1.4 Profiltypen ............................................................................................ 175 6.4.2 Information ....................................................................................................... 176 6.4.3 Kontext ............................................................................................................. 179 6.4.3.1 Dimension-Element-Matrix ................................................................. 179 6.4.3.2 Mapping und Kontextgenerierung ....................................................... 181 6.4.4 Darstellung (Visualisierung) ............................................................................ 182 6.4.4.1 Mapping und Transformation............................................................... 183 6.4.4.2 Visuelle Konzepte ................................................................................ 187

XII

Inhaltsverzeichnis

6.5 3-D-Darstellungen Generischer Sichten .................................................................... 192 6.6 Prozessperspektive bei der Verwendung Generischer Sichten .................................. 198 6.7 Generische Sichten im Kontext von ISO/IEC 42010 IEEE Std 1471-2000 .............. 200 7 Prototypische Realisierung ............................................................................................ 205 7.1 Entwurf und Implementierung des Prototyps ............................................................ 205 7.2 Konfigurationsmöglichkeiten .................................................................................... 209 7.3 Einsatz und Verwendung des Prototyps .................................................................... 214 8 Schlussbetrachtung ......................................................................................................... 223 8.1 Zusammenfassung der Ergebnisse ............................................................................. 223 8.2 Reflexion der Arbeit aus Sicht der zugrunde gelegten Forschungsmethodik ............ 225 8.3 Ausblick ..................................................................................................................... 227 Literatur ................................................................................................................................ 231 Anhang .................................................................................................................................. 255 A.1XML-Schema-Definition des Dimensionssystems .................................................... 255 A.2XML-Konfiguration des Dimensionssystems............................................................ 256 A.3XML-Schema-Definition der Profile ......................................................................... 257 A.4XML-Beispielkonfiguration eines Profils.................................................................. 258

Abbildungsverzeichnis Abbildung 1: Prozessmodell der Design Science Research Methodology (DSRM) .............. 7 Abbildung 2: Aufbau der Arbeit ............................................................................................. 9 Abbildung 3: Generelle Struktur eines Informationssystems ............................................... 16 Abbildung 4: Aufgaben- und Aufgabenträgerebene eines IS ............................................... 17 Abbildung 5: Modell des IM nach Krcmar ........................................................................... 19 Abbildung 6: Informationsbedarf und Informationsversorgung ........................................... 20 Abbildung 7: Teilbereiche der Unternehmensarchitektur..................................................... 25 Abbildung 8: Überblick über verschiedene Teilarchitekturen .............................................. 25 Abbildung 9: Mehrstufige Architektur von Aggregationshierarchien .................................. 27 Abbildung 10: Struktur der TOGAF-Dokumentation............................................................. 31 Abbildung 11: TOGAF Architecture Development Cycle ..................................................... 33 Abbildung 12: Stufen einer Visualisierungspipeline .............................................................. 39 Abbildung 13: Integriertes Referenzmodell für die Visualisierung ........................................ 40 Abbildung 14: Visualisierungsansätze (a) Cone Tree und (b) CodeCity ............................... 45 Abbildung 15: Viewpoints bei der Architektur-Recovery in Bauhaus ................................... 47 Abbildung 16: Prozess der Komponenten-Recovery in Bauhaus ........................................... 48 Abbildung 17: Visualisierung zur Unterstützung der Architektur-Recovery in Bauhaus ...... 49 Abbildung 18: Betrachtungsebenen der Software- und Systemkartographie ......................... 50 Abbildung 19: Beispiel einer Clusterkarte mit Standorten und betriebenen Anwendungssystemen .................................................................................... 51 Abbildung 20: Generierung von Visualisierungen unter Verwendung von Modelltransformationen ................................................................................. 52 Abbildung 21: Screenshot des SyCaTool-Werkzeugs ............................................................ 53 Abbildung 22: Rollen und Operationen einer SOA ................................................................ 65 Abbildung 23: Abstraktionsschichten nach Erl ...................................................................... 69 Abbildung 24: Unterteilung der Service Interface Layer in weitere Subschichten ................ 70 Abbildung 25: Metamodell zur Instanziierung der SOA Solution Reference Architecture .................................................................................................... 71

XIV

Abbildungsverzeichnis

Abbildung 26: Schichten der Open Group SOA Referenzarchitektur .................................... 72 Abbildung 27: Übersicht des COBIT-Frameworks ................................................................ 77 Abbildung 28: Konzeptionelle Struktur des Architecture Governance Frameworks der Open Group .................................................................................................... 78 Abbildung 29: Beziehungen der unterschiedlichen Governance-Ebenen .............................. 80 Abbildung 30: Vereinigung der Architecture und SOA-Governance..................................... 81 Abbildung 31: Beziehung unterschiedlicher Governance-Typen ........................................... 81 Abbildung 32: SOA Governance Model................................................................................. 83 Abbildung 33: SOA Governance and Management Model .................................................... 84 Abbildung 34: SOA-Governance-Lebenszyklus .................................................................... 85 Abbildung 35: Gruppen und Rollen nach Kajko-Mattson et al. ............................................. 87 Abbildung 36: Rollen im Lebenszyklus von Services ............................................................ 93 Abbildung 37: Wissenschaftliche Ursprünge einer Komplexitätswissenschaft ..................... 99 Abbildung 38: Vertreter der Grundlagen einer Komplexitätswissenschaft ............................ 99 Abbildung 39: Unterscheidung von Systemtypen ................................................................ 107 Abbildung 40: Analytisches und systemisches Denken ....................................................... 121 Abbildung 41: Konzeptionelles Modell zur Architekturbeschreibung ................................. 141 Abbildung 42: Das „4+1“-Sichtenmodell ............................................................................. 143 Abbildung 43: Zusammenhänge zwischen Viewtypes, Styles und Views ........................... 145 Abbildung 44: Template für ein View Packet ...................................................................... 148 Abbildung 45: Sichtübergreifende Dokumentation .............................................................. 149 Abbildung 46: Unternehmensarchitektur als schichtübergreifende Sicht von aggregierten Artefakten ................................................................................ 150 Abbildung 47: TOGAF Core Content Metamodel und zugehörige Viewpoints .................. 152 Abbildung 48: Concerns, Viewpoints, Views und Artifacts im Lebenszyklus .................... 157 Abbildung 49: Sichten, Metadaten, Daten und Artefakte unterschiedlicher Abstraktionsschichten ................................................................................... 158 Abbildung 50: Überdeckungsverhältnis zwischen Views und Stakeholder-Concerns ......... 159 Abbildung 51: View-Provider vs. View-Consumer.............................................................. 161

Abbildungsverzeichnis

XV

Abbildung 52: Übersicht des Generischen Sichtenmodells .................................................. 168 Abbildung 53: Lebenszyklus von SOA-Elementen .............................................................. 171 Abbildung 54: Zuordnung von Abstraktionsschichten und SOA-Elementen....................... 172 Abbildung 55: Domänen und SOA-Elemente ...................................................................... 173 Abbildung 56: Service Management Information Model ..................................................... 178 Abbildung 57: Mapping von Profilen und Daten/Metadaten ............................................... 181 Abbildung 58: Beziehungen syntaktischer und semantischer Elemente auf Typ- und Instanzebene ................................................................................................. 184 Abbildung 59: Konzept multipler Subsichten....................................................................... 188 Abbildung 60: Konzept der Informationshierarchie ............................................................. 189 Abbildung 61: Information on Demand am Beispiel eines Services .................................... 189 Abbildung 62: Konzept der Filterung ................................................................................... 190 Abbildung 63: Konzept der Aggregation .............................................................................. 191 Abbildung 64: Konzept des Kontexts und Detail auf sichtinterner Ebene ........................... 192 Abbildung 65: 3-D-Darstellung mehrerer SOA-Schichten................................................... 194 Abbildung 66: 3-D-Entwurf eines Beispielprozesses, der Services und Komponenten ....... 195 Abbildung 67: Navigation im 3-D-Entwurf des Beispielprozesses, der Services und Komponenten ................................................................................................ 197 Abbildung 68: Prozesslandschaft mit horizontalen Nebelclustern ....................................... 198 Abbildung 69: Generische Sichten als Teil eines evolutionären Prozesses .......................... 200 Abbildung 70: Generische Sichten und ISO/IEC 42010 IEEE Std 1471-2000 .................... 201 Abbildung 71: Kernkomponenten des Prototyps .................................................................. 206 Abbildung 72: Zentrale Klassen der Komponenten des Prototyps ....................................... 208 Abbildung 73: XML-Schema-Definition des Dimensionssystems....................................... 210 Abbildung 74: XML-Schema-Definition des Regelsystems ................................................ 211 Abbildung 75: XML-Schema-Definition der Profilkonfiguration ........................................ 212 Abbildung 76: XML-Schema-Definition zur Konfiguration der Visualisierung Generischer Sichten ...................................................................................... 213 Abbildung 77: Auszug der XML-Schema-Definition zur Konfiguration visueller Schichten....................................................................................................... 214

XVI

Abbildungsverzeichnis

Abbildung 78: Profilkonfiguration des Service-Designers (a) ............................................. 216 Abbildung 79: Profilkonfiguration des Service-Designers (b) ............................................. 216 Abbildung 80: Visualisierung einer Generischen Sicht auf Basis der Profilkonfiguration des Service-Designers (a) ............................................. 218 Abbildung 81: Visualisierung einer Generischen Sicht auf Basis der Profilkonfiguration des Service-Designers (b) ............................................. 218 Abbildung 82: Visualisierung einer Generischen Sicht auf Basis der Profilkonfiguration des Geschäftsprozessarchitekten (a) ............................. 220 Abbildung 83: Visualisierung einer Generischen Sicht auf Basis der Profilkonfiguration des Geschäftsprozessarchitekten (b) ............................. 220 Abbildung 84: Visualisierung einer Generischen Sicht auf Basis der Profilkonfiguration des Geschäftsprozessarchitekten (c) ............................. 221

Tabellenverzeichnis Tabelle 1:

Überblick über das Zachman Enterprise Framework 2 .................................. 28

Tabelle 2:

3-D Stärken und Schwächen ........................................................................... 44

Tabelle 3:

Das serviceorientierte Paradigma im Zachman Framework ........................... 61

Tabelle 4:

Dimensionen einer Servicetypisierung ........................................................... 66

Tabelle 5:

Rollen der Gruppe SOA Support .................................................................... 88

Tabelle 6:

Rollen der Gruppe SOA Strategy and Governance ........................................ 89

Tabelle 7:

Rollen der Gruppe SOA Design and Quality Management (Teil 1) .............. 89

Tabelle 8:

Rollen der Gruppe SOA Design and Quality Management (Teil 2) .............. 90

Tabelle 9:

Rollen der Gruppe SOA Development and Evolution ................................... 90

Tabelle 10:

Existierende Rollen mit SOA-spezifischen Verantwortlichkeiten ................. 91

Tabelle 11:

Neue SOA-spezifische Rollen ........................................................................ 92

Tabelle 12:

SOA-spezifische Rollen nach Erl ................................................................... 94

Tabelle 13:

Denkmuster in der Managementtheorie........................................................ 120

Tabelle 14:

Unterschiede zwischen dem analytischen und systemischen Ansatz ........... 120

Tabelle 15:

Viewpoint Spezifikationen der OASIS Reference Architecture Foundation for SOA ..................................................................................... 153

Tabelle 16:

Dimension-Element-Matrix .......................................................................... 180

Tabelle 17:

Auswahl und Parametrisierung der Dimensionsausprägungen für die Profilkonfiguration des Service-Designers im Kontext des Szenarios ......... 215

Tabelle 18:

Auswahl und Parametrisierung der Dimensionsausprägungen für die Profilkonfiguration des Geschäftsprozessarchitekten im Kontext des Szenarios ....................................................................................................... 219

Abkürzungsverzeichnis ABB .......... Architectural Building Block ADM......... Architecture Development Method ARIS ......... Architektur integrierter Informationssysteme BI .............. Business Intelligence BIS ............ Betriebliches Informationssystem BITKOM .. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien BPMN....... Business Process Modeling Notation CIM .......... Common Information Model COBIT ...... Control Objectives for Information and Related Technology CSS ........... Cascading Style Sheets DMTF ....... Distributed Management Task Force DSRM....... Design Science Research Methodology EA............. Enterprise Architecture EMF .......... Eclipse Modeling Framework ETL........... Extraktion, Transformation, Laden GET .......... Graphical Editor Toolkit GUID ........ Globally Unique Identifier HCI ........... Human Computer Interaction IEEE ......... Institute of Electrical and Electronics Engineers IM ............. Informationsmanagement IEC ........... International Electrotechnical Commission IS .............. Informationssystem ISACA ...... Information Systems Audit and Control Association ISO ........... International Organization for Standardization IT .............. Informationstechnologie ITGI .......... IT Governance Institute ITIL .......... IT Infrastructure Library

XX

Abkürzungsverzeichnis

ITPMF ...... IT Portfolio Management Facility JAXR ........ Java API for XML Registries KPI ........... Key Performance Indikator OASIS ...... Organization for the Advancement of Structured Information Standards OCL .......... Object Constraint Language OECD ....... Organisation of Economic Cooperation and Development OGC ......... Office of Government Commerce OMG......... Object Management Group QoS ........... Quality of Service RM ............ Reference Model RM-ODP .. Reference Model of Open Distributed Processing RuleML .... Rule Markup Language SEI ............ Software Engineering Institute S3 .............. Service-Oriented Solution Stack SGMM ...... SOA Governance and Management Model SLA .......... Service Level Agreement SO ............. Serviceorientierung, Service Orientation SOA .......... Serviceorientierte Architektur, Service Oriented Architecture SOAP ........ Simple Object Access Protocol SOC .......... Service Oriented Computing SOE .......... Service Oriented Enterprise SOM ......... Semantisches Objektmodell SOP........... Service Oriented Platform SOSE ........ Service Oriented Systems Engineering TI .............. Technische Infrastruktur TOGAF..... The Open Group Architecture Framework UDDI ........ Universal Description Discovery & Integration ULS .......... Ultra-large-scale UML ......... Unified Modeling Language

Abkürzungsverzeichnis

W3C ......... World Wide Web Consortium WfMC....... Workflow Management Coalition WSBPEL .. Web Services Business Process Execution Language WSDL....... Web Services Description Language WWW....... World Wide Web XML ......... Extensible Markup Language XPDL ....... XML Process Definition Language XSD .......... XML-Schema-Definition XSL .......... Extensible Stylesheet Language XSLT ........ XSL Transformation

XXI

1 1.1

Einleitung Problemstellung und Motivation

Die Entwicklung und das Management von Softwaresystemen sind und bleiben aufgrund einer immer weiter steigenden Komplexität von aufwändigen und kostenintensiven Prozessen geprägt. Demgegenüber stehen eine schnell wachsende Nachfrage nach Software und neuen Funktionalitäten, die Forderung nach immer kürzeren Entwicklungszyklen mit höheren Qualitätsanforderungen sowie sinkende Budgets bei den Investitionen in Softwaresysteme. Der Erfolg bei der Entwicklung und dem Management von Softwaresystemen ist in erster Linie davon abhängig, inwieweit die zunehmende Komplexität beherrscht werden kann. Der Umgang mit Komplexität wird in diesem Zusammenhang schon seit Jahrzehnten, insbesondere im Bereich des Software Engineering, untersucht und erforscht. Die Forschung zielt dabei auf eine kontinuierliche Verbesserung bestehender Methoden, Techniken und Werkzeuge bzw. auf die Entwicklung neuer, innovativer Ansätze ab, um der steigenden Komplexität entgegen zu wirken und die Nachhaltigkeit von Softwaresystemen sicherzustellen. Die Verbesserung von Methoden, Techniken und Werkzeugen durch die Entwicklung von Standards, Frameworks und Best Practices trägt u.a. zu einer besseren Unterstützung des Managements betrieblicher Anwendungssysteme bei. Dies betrifft insbesondere das Architekturmanagement, das Infrastrukturmanagement, das Qualitätsmanagement und das Management der Entwicklungsprozesse. Moderne Entwicklungsprozesse sowie der Einsatz etablierter Methoden, Techniken und Werkzeuge helfen, den Umgang mit der Komplexität zu erleichtern. Umgekehrt steigt jedoch die Komplexität durch den wachsenden Umfang und die Integration von Softwaresystemen sowie durch die sich immer schneller ändernden Umweltbedingungen, und dies sowohl aus technischer als auch aus fachlicher Sicht. Unternehmensanwendungen, die eng an die Organisation, die Prozesse und das Geschäftsmodell von Unternehmen gekoppelt sind, müssen eine hohe Anzahl unterschiedlicher Anforderungen erfüllen. Nach Krafzig et al. sind Einfachheit, Flexibilität, Wartbarkeit, Wiederverwendbarkeit und die Entkoppelung von Funktionalität und Technologien wichtige Eigenschaften, die moderne Unternehmenssoftwarearchitekturen aufweisen müssen, um die Agilität und Effizienz von Unternehmensanwendungen zu verbessern (Krafzig et al. 2007, S. 27f.). Serviceorientierte Architekturen (Service-Oriented Architectures, SOAs) bieten Konzepte, die es erlauben, Unternehmensanwendungen mit den zuvor genannten Eigenschaften zu realisieren und flexible Systemlandschaften zu schaffen. Die wachsende Verbreitung serviceorientierter Architekturen ist nicht zuletzt auf die steigende Akzeptanz von Web Services und XML-Technologien zurückzuführen, mit denen technologieunabhängige Dienste mit wohl definierten Schnittstellen bereitgestellt werden können. Ein zusätzlicher Vorteil der Serviceorientierung besteht darin, dass sowohl fachliche als auch technische Perspektiven und T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

2

Einleitung

Blickwinkel innerhalb einer Unternehmensorganisation berücksichtigt werden. Somit wird im Rahmen der Serviceorientierung ein stärkerer Fokus auf ein effektives Business-ITAlignment gelegt. Neben den vielfältigen Vorteilen existieren jedoch auch Nachteile, Problemfelder und neue Herausforderungen, die durch die Einführung und Adaption serviceorientierter Architekturen entstehen. Zu beobachten ist, dass auch bei serviceorientierten Architekturen die Komplexität nicht zuletzt durch den Zugewinn an Flexibilität in der Regel noch steigt. Insbesondere auf organisatorischer Ebene und beim Management von serviceorientierten Architekturen tragen Charakteristika wie z.B. die geographische Verteilung, Dezentralisierung, emergentes Verhalten, der Mensch als Teil des Systems, ein hoher Integrationsgrad und die kontinuierliche Evolution zu einer erhöhten Komplexität bei. Lewis et al. sehen vor allem durch das Einbinden externer Consumer und Provider einen Zuwachs an Komplexität bei den Wartungsprozessen in serviceorientierten Umgebungen (Lewis et al. 2008, S. 143). Strnadl erwähnt, dass IT-Führungskräfte einen erheblichen Zuwachs an Komplexität feststellen, wenn es um die Umsetzung von SOA-Initiativen geht (Strnadl 2007). Technologien, Geschäftsprozesse, Geschäftsfunktionalität, Integration und Wartung sind dabei Elemente mit Auswirkung auf die Komplexität, die Unternehmensprojekte gefährden und die Agilität eines Unternehmens einschränken können (Krafzig et al. 2007, S. 253). In einer Umfrage der InformationWeek Research im September 2006 gaben von 278 befragten Business Technology Professionals 55% einen Zuwachs von Komplexität in ihren IT-Umgebungen durch SOAProjekte an (Ricadela 2006). Insbesondere im Gegensatz zu sogenannten Insellösungen, die in sich geschlossene Systeme darstellen, besitzen serviceorientierte Systeme keine klar definierten Systemgrenzen. Das bedeutet, dass nicht nur technologisch – d.h. bei der Implementierung von Diensten auf Basis unterschiedlicher Plattformen – ein umfangreicheres Wissen und Verständnis über das Gesamtsystem gefordert ist. Durch ein verstärktes Business-IT-Alignment ist auch aus fachlicher Sicht ein systemweites und domänenübergreifendes Wissen und Verständnis zwingend erforderlich. Darüber hinaus ist es entscheidend, Aspekte der Kommunikation bei einer wachsenden Anzahl an Stakeholdern (Akteuren) und Kommunikationswegen stärker zu berücksichtigen. Abhängig von verschiedenen Stakeholdern und deren Perspektiven existieren zahlreiche Sichten auf ein Gesamtsystem, mit denen unterschiedliche Aspekte betrachtet, dokumentiert und kommuniziert werden. Im Bereich des Architekturmanagements ist das Konzept der Sichten ein fundamentales Prinzip, um unterschiedliche Blickwinkel und Sichtweisen von Stakeholdern zu berücksichtigen und zu dokumentieren (Clements et al. 2002, S. 13). Die Sichten ermöglichen die Betrachtung spezifischer Aspekte eines Systems unabhängig voneinander und tragen somit zu einer Verbesserung des Verständnisses und einer besseren Beherrschbarkeit

Zielsetzung und Forschungsfragen

3

der Komplexität bei. Dabei ist zu beachten, dass nicht eine Sicht alleine die Architektur eines Systems repräsentiert, sondern alle Sichten zusammen die Architektur kommunizieren (Clements et al. 2002, S. 13; Bass et al. 2003, S. 35). Die Fokussierung eines Stakeholders auf bestimmte Aspekte (Separation of Concerns) ist und bleibt ein zentrales Prinzip bei dem Entwurf und der Entwicklung eines Systems. Die Fokussierung auf einen Aspekt bedeutet dabei nicht, dass ein anderer Aspekt ignoriert wird, sondern vielmehr, dass er aus dem gewählten Blickwinkel keine Relevanz besitzt (Dijkstra 1982). Jedoch ist es heutzutage notwendig, unterschiedliche Denkprozesse beim Management und bei der Evolution großer Systeme zu berücksichtigen. Neben dem analytischen Denken auf Basis von Kausalketten und Ursache-Wirkungsprinzipien wird das Systemdenken, d.h. Dinge in einem Gesamtkontext zu betrachten, immer häufiger erforderlich. Dies liegt insbesondere an Eigenschaften komplexer sozio-technischer Systeme, wie z.B. Eigendynamik und Emergenz, Multidimensionalität, Offenheit und Dezentralisierung (Masak 2007, S. 310). Zudem wird der Mensch ein integraler Teil des Systems. In diesem Zusammenhang gilt es zu berücksichtigen, welche Arten von Systemen Gegenstand der Betrachtung sind, wie sich diese Systeme konstituieren und welches Komplexitätsverständnis dabei zugrunde gelegt wird. Unter der Berücksichtigung evolutionärer Gesichtspunkte ist es daher durchaus denkbar, dass Aspekte zu einem bestimmten Zeitpunkt im Lebenszyklus eines Systems ignoriert werden, da sie für keinen der in diesem Zeitpunkt gewählten Blickwinkel Relevanz besitzen. Dies schließt aber nicht aus, dass ignorierte Aspekte zu einem anderen Zeitpunkt der Evolution des Systems aus einem bis dahin nicht gewählten Blickwinkel relevant werden. Das Dilemma, das sich somit aus einer Menge dokumentierter Sichten ergibt, ist, dass diese zwar Aspekte fokussieren, die im Kontext ihrer Entstehung von Relevanz sind, Aspekte, die in anderen Kontexten zu anderen Zeitpunkten relevant werden, jedoch nicht oder nur teilweise berücksichtigen. Dies birgt die Gefahr, dass trotz einer Vielzahl dokumentierter Sichten erhebliche Defizite bei der Informationsverarbeitung entstehen können und somit die Betrachtung relevanter kontextspezifischer Aspekte mit Bezug auf das Gesamtsystem nicht oder nur mit erheblichem Aufwand möglich ist. Von dieser Problematik sind – insbesondere bei serviceorientierten Architekturen – nicht mehr nur einzelne Personenkreise, sondern alle Stakeholder betroffen, die in Entwicklungs- und Managementprozesse SOA-basierter Systeme involviert sind. 1.2

Zielsetzung und Forschungsfragen

Das Ziel der vorliegenden Arbeit liegt in der Entwicklung eines Konzepts, das eine Erzeugung kontextspezifischer Sichten auf SOA-basierte Systeme ermöglicht und somit zu einer erhöhten Informationsversorgung von Stakeholdern sowie einer besseren Informationsverarbeitung – insbesondere in Bezug auf Aspekte der Kommunikation – beiträgt. Das Konzept

4

Einleitung

soll demnach einen Beitrag zur Verbesserung eines nachhaltigen Architekturmanagements leisten und dadurch die Beherrschung von Komplexität im Rahmen der Entwicklung und des Managements betrieblicher Anwendungssysteme unterstützen. Die zentrale Forschungsfrage, die sich im Zusammenhang mit der Zielsetzung ergibt, besteht darin, wie im Kontext serviceorientierter Architekturen und der damit verbundenen Vielzahl unterschiedlicher Interessen (Concerns1) und Perspektiven eine bessere Informationsversorgung der Stakeholder auf der Basis von Architektursichten gewährleistet werden kann. Darüber hinaus lassen sich aus dem Ziel der Arbeit weitere Forschungsfragen als Teilziele ableiten: x

System- und Komplexitätsverständnis: Welche Arten der Systembildung müssen im Rahmen der Entwicklung und des Managements betrieblicher Anwendungssysteme unterschieden werden? Welche Systeme liegen im Fokus des Lösungsansatzes und welches Komplexitätsverständnis muss diesen zugrunde gelegt werden?

x

Abbildung von Concerns: Wie muss ein übergeordneter Rahmen zur Abbildung und Beschreibung von Concerns im Kontext serviceorientierter Architekturen gestaltet werden?

x

Informationsbedarf: Wie lässt sich aus einer Vielzahl unterschiedlicher Perspektiven und Concerns der Informationsbedarf identifizieren und spezifizieren, um entsprechende Daten und Metadaten erfassen zu können?

x

Daten und Metadaten: Auf welche Art und Weise müssen Daten und Metadaten erfasst, beschrieben und bereitgestellt werden, um auf deren Basis kontextspezifische Sichten erzeugen zu können?

x

Kontext: Wie lassen sich Daten und Metadaten in Bezug auf spezifische Concerns analysieren und aggregieren, um relevante Aspekte in einen Kontext zu bringen und zur Verfügung zu stellen?

x

Darstellung: Welche Mechanismen müssen für die Visualisierung von Sichten zur Verfügung gestellt werden, so dass sich die für einen Kontext relevanten Aspekte adäquat darstellen lassen?

Ein entscheidender Faktor bei der Entwicklung des Konzepts liegt darin, die unterschiedlichen Aspekte der einzelnen Fragestellungen ganzheitlich zu betrachten. Nur durch die ganzheitliche Betrachtung der unterschiedlichen Aspekte kann eine adäquate Informationsversorgung gewährleistet werden, die der Vielseitigkeit von Interessen in serviceorientierten Archi-

1

Der Begriff „Concern“ wird in Anlehnung an die Terminologie des ISO/IEC 42010 IEEE Std 1471-2000Standards verwendet (siehe dazu Kapitel 5.1)

Forschungsmethode

5

tekturen gerecht wird und zu einem besserem Verständnis sowie der Beherrschbarkeit von Komplexität beiträgt. Zur Überprüfung des Konzepts wird die Entwicklung eines Prototyps angestrebt, der zum einen als Proof of concept dienen soll, um die technische Machbarkeit des Konzepts aufzuzeigen. Zum anderen soll der Prototyp dazu beitragen, Aussagen in Bezug auf den Einsatz und Nutzen des theoretischen Gesamtkonzepts treffen zu können. 1.3

Forschungsmethode

Die Wirtschaftsinformatik wird als eine anwendungsorientierte Forschungsdisziplin verstanden, die mit ihrer Interdisziplinarität, insbesondere durch ihre Einordnung zwischen den Mutterdisziplinen Betriebswirtschaftslehre und Informatik, ein breites Forschungsspektrum abdeckt (Frank 2007, S. 155; Heinrich et al. 2007). Zur Entwicklung von Lösungsansätzen werden neben Erkenntnissen aus der Betriebswirtschaftslehre und der Informatik auch Erkenntnisse weiterer Disziplinen, wie bspw. den Ingenieurswissenschaften, der Systemtheorie, der Kybernetik, den Informationswissenschaften oder der Soziologie, herangezogen (Heinrich et al. 2007, S. 106ff.; Teubner 1999, S. 3). Erkenntnisgegenstand der Wirtschaftsinformatik ist die Rolle des informationstechnischen Artefakts im sozialen Kontext (Becker 2008, S. 6), d.h. „Informationssysteme in Wirtschaft und Gesellschaft, sowohl von Organisationen als auch von Individuen.“ (Österle et al. 2010, S. 3) Auf den betrieblichen Kontext bezogen, untersucht die Wirtschaftsinformatik die Entwicklung, Einführung, Nutzung und Wartung betrieblicher Informationssysteme sowie den für ihre Nutzung bedeutsamen Handlungskontext (Frank 2007). Informationssysteme werden dabei als soziotechnische Systeme verstanden, die „aus Menschen (personellen Aufgabenträgern), Informations- und Kommunikationstechnik (maschinellen Aufgabenträgern) und Organisation (Funktionen, Geschäftsprozessen, Strukturen und Management) sowie den Beziehungen zwischen diesen drei Objekttypen“ (Österle et al. 2010, S. 3) bestehen2. Die Wirtschaftsinformatik ist im deutschsprachigen Raum sowie in einigen europäischen Ländern gestaltungsorientiert ausgerichtet (Lange 2006; Wilde und Hess 2007; Winter 2008), d.h., sie ist von einer konstruktionsorientierten Forschung durch die Konstruktion und Beurteilung von Artefakten geprägt. In einem Memorandum zur gestaltungsorientierten Wirtschaftsinformatik (Österle et al. 2010) wird diese Ausrichtung bestärkt. Die Verfasser des Memorandums treten darin für eine gestaltungsorientierte Wirtschaftsinformatik ein, wobei aber ausdrücklich auch eine verhaltensorientierte Forschung (Behaviorismus) akzeptiert und ein Methodenpluralismus begrüßt werden. Handlungsanleitungen zur Konstruktion und zum 2

Eine genauere Betrachtung des Informationssystembegriffs wird in Kapitel 2.1 vorgenommen.

6

Einleitung

Betrieb von Informationssystemen sowie Innovationen in den Informationssystemen werden dabei als die Erkenntnisziele3 einer gestaltungsorientierten Wirtschaftsinformatik angesehen (Österle et al. 2010, S. 3). Konstrukte (Konzepte, Terminologien, Sprachen), Modelle, Methoden und Instanzen (Implementierung konkreter Lösungen als Prototypen oder produktive Informationssysteme) stellen die Ergebnistypen dar (Österle et al. 2010, S. 4). Im anglo-amerikanischen Raum entspricht die Wirtschaftsinformatik dem Information Systems Research (ISR), das jedoch bei gleicher inhaltlicher Ausrichtung vom Forschungsansatz des Behaviorismus, also einer verhaltensorientierten Forschung, geprägt ist (Frank 2007, S. 163; Becker 2008, S. 7; Österle et al. 2010, S. 1; Schauer und Frank 2007). Dabei wird das Ziel verfolgt, Eigenschaften von Informationssystemen und des Verhaltens von Benutzern mit der Aufstellung bzw. empirischen Überprüfung von Hypothesen und Theorien zu beobachten und somit Ursache-Wirkungs-Zusammenhänge zu entdecken. Das Informationssystem wird demnach als Phänomen analysiert (Österle et al. 2010, S. 4). In den letzten Jahren hat auch im Information Systems Research ein Forschungszweig mit der Bezeichnung Design Science Research zu einer höheren Akzeptanz gestaltungsorientierter Forschung beigetragen (Becker 2008, S. 7f.; Österle et al. 2010, S. 2). Diskussionen zum Design Science bzw. Design Science Research wurden im Rahmen der DESRIST Konferenzen4, in großen IS-Konferenzen sowie in IS-Journals aufgegriffen und geführt (vgl. (Winter 2008)). Viele der Design Science Research Beiträge verweisen dabei auf die Arbeiten von Simon (Simon 1969), Nunamaker et al. (Nunamaker et al. 1991), Walls et al. (Walls et al. 1992), March & Smith (March und Smith 1995) und Hevner et al. (Hevner et al. 2004). Winter merkt an, dass zahlreiche Beiträge zur Rechtfertigung der gestaltungorientierten Ausrichtung, zur Typologie von Artefakten und zu spezifischen Problemlösungen geleistet, Aspekte bezüglich der Rigorosität jedoch nur unzureichend standardisiert wurden (Winter 2008). Als Beispiel nennt er den Mangel an allgemein akzeptierten Referenzmethoden für eine konstruktionsorientierte Forschung. Auch Becker betont, dass an Forschungsvorhaben der gestaltungsorientierten Wirtschaftsinformatik strenge Maßstäbe gelegt werden müssen (Becker 2008). Der Erkenntnisprozess sollte daher idealtypisch in Iterationen mit folgenden Phasen verlaufen (Österle et al. 2010): Analyse, Entwurf, Evaluation, Diffusion. Vorschläge zu Forschungsmethoden, die unterschiedliche Phasen eines Forschungsprozesses berücksichtigen, werden bspw. von March und Smith

3 4

Siehe auch Heinzl et al. (Heinzl et al. 2001), die in einer Delphie-Studie zentrale Erkenntnisziele der Wirtschaftsinformatik identifizieren. Siehe http://desrist.org/

Forschungsmethode

7

(March und Smith 1995), Hevner et al. (Hevner et al. 2004), und Peffers et al. (Peffers et al. 2008) unterbreitet. Die vorliegende Arbeit ist der gestaltungsorientierten Wirtschaftsinformatik zuzuordnen. Betrachtungsgegenstand ist das betriebliche Informationssystem, wobei der Fokus auf serviceorientierte Architekturen, das damit verbundene Architekturmanagement sowie die in diesem Kontext beteiligten Stakeholder und eingesetzten technologischen Komponenten gerichtet wird. Die Forschungsfragen und die zu erarbeitenden Ergebnisse betreffen die genannten Erkenntnisziele und die Artefakte in Form eines Konzepts und eines Prototyps entsprechen den zuvor angeführten Ergebnistypen. Als Forschungsmethodik wird der problemzentrierte Ansatz der Design Science Research Methodology (DSRM) von Peffers et al. (Peffers et al. 2008) aufgegriffen und dieser Arbeit zugrunde gelegt. Abbildung 1 zeigt das Prozessmodell des DSRM-Ansatzes, bestehend aus sechs Hauptaktivitäten, an denen sich die vorliegende Arbeit orientiert.

ProblemCentered Initiation

ObjectiveCentered Solution

Design & Development Centered Initiation

Demonstration Find suitable context Use artifact to solve problem

Evaluation Observer how effective, efficient Itearate back to design

Communication

Disciplinary Knowledge

Show importance

What would a better artifact accomplish?

Artifact

Metrics, Analysis Knowledge

Define problem

Design & Development

How to Knowledge

Nominal process sequence

Define Objectives of a Solution

Theory

Identify Problem & Motivation

Inference

Process Iteration

Scholarly publications Professional publications

Client/ Context Initiated

Possible Research Entry Points

Abbildung 1: Prozessmodell der Design Science Research Methodology (DSRM) Quelle: (Peffers et al. 2008, S. 54)

x

Identifikation und Motivation des Problems: Die Aktivität umfasst die Definition eines spezifischen Forschungsproblems. Die Problemstellung und deren Relevanz werden im Laufe der Arbeit sukzessiv herausgearbeitet. Dazu werden Erkenntnisse und Diskussionen aus Wissenschaft und Praxis aufgegriffen, die Problemstellung erklärt und auf den State-of-the-Art der Problemstellung und verfügbarer Lösungsansätze eingegangen.

x

Definition der Zielsetzung: Auf Basis der Problemstellung werden das Ziel der Arbeit und die daraus abgeleiteten Forschungsfragen definiert. Teilziele in Bezug auf den Lösungsansatz werden im Laufe der Arbeit weiter konkretisiert.

x

Entwicklung und Entwurf: Als Artefakte werden im Rahmen dieser Forschungsarbeit ein Konzept und ein Prototyp entwickelt und entworfen. Den Schwerpunkt des Kon-

8

Einleitung

zepts bildet ein Modell. Die vier Kernbereiche des Modells sowie die Schnittstellen zwischen diesen Bereichen liefern einen konzeptionellen Rahmen für die Implementierung des Prototyps. Der Prototyp dient als Proof of concept und stellt durch seine Konfigurationsmöglichkeiten ein Instrument zur Verfügung, mit dem das abstrakte Konzept in konkreten Anwendungskontexten instanziiert werden kann. Der Nutzen und die Anwendbarkeit des Konzepts werden mithilfe deduktiver Argumentationen begründet. Da in Bezug auf einzelne Teilkonzepte in der Literatur Lösungsansätze bzw. Lösungsvorschläge vorzufinden sind, wird auf dieses vorhandene Wissen zurückgegriffen bzw. daran angeknüpft und in das Gesamtkonzept integriert. x

Demonstration: Das entwickelte Konzept wird mithilfe des Proof of concept-Prototyps im Rahmen von Workshops und Präsentationen mit Unternehmensvertretern (anwendende Unternehmen und Werkzeughersteller) demonstriert. Das durch die Demonstration entstehende Feedback liefert wichtige Anhaltspunkte, die in die Verfeinerung der Teilkonzepte und die Weiterentwicklung des Prototyps einfließen.

x

Evaluation: Die Evaluation erfolgt auf Basis abgeleiteter Szenarien, anhand derer eine Überprüfung des Konzepts vorgenommen und Erkenntnisse über den Nutzen des Konzepts sowie den Einsatz des entwickelten Prototyps in Bezug auf reale Anwendungskontexte erlangt werden können. Die Szenarien werden auf Basis der verwendeten Literatur und unter Berücksichtigung des Feedbacks aus der Demonstration abgeleitet.

x

Kommunikation: Die Ergebnisse der Forschungsarbeit werden in wissenschaftlichen Publikationen (Konferenzbeiträge, Research Reports) sowie durch die Veröffentlichung der vorliegenden Arbeit kommuniziert.

Die vorliegende Arbeit und die darin erzielten Ergebnisse werden in einer Schlussbetrachtung anhand der zuvor dargestellten Aktivitäten der zugrunde gelegten Forschungsmethodik reflektiert. 1.4

Aufbau der Arbeit

Abbildung 2 veranschaulicht den Aufbau der vorliegenden Arbeit. Im zweiten Kapitel werden die Grundlagen der Arbeit erarbeitet und präzisiert. Zunächst erfolgt eine Diskussion und Abgrenzung der Begriffe des betrieblichen Informationssystems und des betrieblichen Anwendungssystems. Anschließend wird in die Thematik des Informationsmanagements eingeführt, wobei die Ziele und Aufgaben sowie die Informationswirtschaft die Schwerpunkte bilden. Des Weiteren setzt sich die Arbeit intensiver mit der Architekturthematik auseinander. Gegenstand der Betrachtungen bilden in diesem Zusammenhang das Verständnis des Architekturbegriffs sowie die Unterscheidung unterschiedlicher Architekturtypen. Darüber hinaus werden Architekturmodelle und -Frameworks vorgestellt und näher auf die Rolle des Architekturmanagements im Rahmen des Informationsmanagements eingegangen.

Aufbau A der Arbeit

9

Abbildung A 2: Auffbau der Arbeit

Im Anschluss ddaran wird in das Thema der computergestütz c zten Visualisierrung eingeführt,, wobei w neben allggemeinen Grundlagen und weiterführenden Koonzepten das Foorschungsgebiett der d Softwarevisuualisierung näheer betrachtet wiird. Abschließennd werden verw wandte Arbeitenn unterschiedliche u r Forschungsbeereiche betrachteet, die bestimmtte Aspekte der in dieser Arbeitt aufgestellten a Forrschungsfragen behandeln und somit s Anknüpfuungspunkte liefeern können. Das D dritte Kapitel betrachtet diee Thematik der Serviceorientierrung (SO) und serviceorientiers ter Architekturenn. Zunächst wirdd ein Überblick über die Grunddlagen serviceoriientierter Archi-tekturen gegebeen. Darin werdeen neben den Vorteilen einerr SOA unterschhiedliche SOA-Definitionen, D -P Prinzipien und -Erfolgsfaktoren n sowie die Zussammenhänge zwischen z Unter-nehmensn und seerviceorientierteen Architekturen n diskutiert. Annschließend wirdd der Fokus auff die d Bestandteile und Ebenen serrviceorientierter Architekturen gerichtet. g Weitere Schwerpunk--

10

Einleitung

te bilden die SOA-Governance und die Definition von SOA-Rollen, denen im Zuge von organisatorischen Veränderungen bei der Einführung und dem Betrieb serviceorientierter Architekturen eine wichtige Bedeutung zukommt. Das dritte Kapitel schließt mit einer Zusammenfassung der Ergebnisse. Das vierte Kapitel setzt sich mit der Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme auseinander. Hierzu werden zunächst Diskussionen in der Literatur aufgegriffen und thematisiert. Im Anschluss daran wird auf das Komplexitätsverständnis unterschiedlicher wissenschaftlicher Disziplinen und Theorien eingegangen. Dabei stehen die soziologische Systemtheorie, systemische Denkansätze und die ManagementKybernetik im Vordergrund der Betrachtungen. Darauf folgend wird die Komplexität im Rahmen der Softwareevolution und in Bezug auf softwaretechnische Systeme näher betrachtet. In einem Zwischenfazit wird abschließend die allgemeine Theorie sozialer Systeme Luhmanns verwendet, um die Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme und die damit verbundene Komplexität zu erklären. Darauf aufbauend werden Frage- und Problemstellungen bezüglich der Informationsverarbeitung und Informationsversorgung diskutiert. Der Fokus der Betrachtungen wird dabei mit Blick auf die Zielsetzung und die Forschungsfragen dieser Arbeit zunehmend auf das Architekturmanagement gerichtet. Im fünften Kapitel wird zunächst auf die Architekturbeschreibung und -dokumentation softwareintensiver Systeme im Rahmen des Architekturmanagements eingegangen. Anschließend werden Sichtenkonzepte bzw. Sichtenmodelle aus den Bereichen der Software- und Unternehmensarchitekturen sowie serviceorientierter Architekturen vorgestellt. Abschließend werden die Erkenntnisse und Fragestellungen des vierten Kapitels aufgegriffen, um Problemstellungen bestehender Sichtenkonzepte bei Architekturbeschreibungen und -dokumentationen zu untersuchen und zu diskutieren. Die Ergebnisse der Untersuchungen des vierten und fünften Kapitels bilden im sechsten Kapitel die Basis für die Entwicklung eines Lösungsansatzes zur Erzeugung kontextspezifischer Sichten auf SOA-basierte Systeme: das sogenannte Generische Sichtenkonzept. Im Mittelpunkt steht dabei das Generische Sichtenmodell, in dem die notwendigen Teilkonzepte zur Erzeugung Generischer Sichten erarbeitet werden. Darüber hinaus wird ein 3-D-Entwurf zur Darstellung Generischer Sichten vorgestellt und die Verwendung Generischer Sichten aus einer Prozessperspektive diskutiert. Abschließend wird das Generische Sichtenkonzept im Zusammenhang mit dem im ISO/IEC 42010 IEEE Std 1471-2000-Standard definierten Framework betrachtet. In Kapitel 7 werden Aspekte des Entwurfs und der Implementierung eines Prototyps vorgestellt, der im Rahmen dieser Forschungsarbeiten als Proof of concept entwickelt wurde. Zu-

Aufbau der Arbeit

11

dem wird auf den Einsatz und die Verwendung des Prototyps in konkreten Anwendungskontexten am Beispiel von Szenarien eingegangen. Im letzten Kapitel werden die Ergebnisse der vorliegenden Arbeit zusammengefasst und anhand der Forschungsmethodik reflektiert. Darüber hinaus wird ein Ausblick gegeben, der weiteren Forschungsbedarf identifiziert und die Potenziale des Generischen Sichtenkonzepts für andere Anwendungsbereiche beleuchtet.

2

Grundlagen und Begriffe

In diesem Kapitel werden grundlegende Begriffsdefinitionen, Terminologien, Themenfelder und Ansätze beschrieben, die im Kontext dieser Arbeit wichtig sind und einen Bezugsrahmen bilden. Nach einem Überblick über das Begriffsverständnis betrieblicher Informationssysteme und der Einordnung bzw. Abgrenzung vom Begriff des Anwendungssystems (Kapitel 2.1) wird in die Thematik des Informationsmanagements eingeführt (Kapitel 2.2). Für diese Arbeit wichtige Schwerpunkte bilden in diesem Zusammenhang die Ziele und Aufgaben des Informationsmanagements (Kapitel 2.2.1) und die Bedeutung der Begriffe Informationsangebot und Informationsbedarf (Kapitel 2.2.2). Anschließend erfolgt eine Auseinandersetzung mit der Architekturthematik (Kapitel 2.3), die die Definition des Architekturbegriffs (Kapitel 2.3.1) und die Betrachtung der Unternehmensarchitektur sowie deren Teilarchitekturen einschließt (Kapitel 2.3.2). Darüber hinaus werden exemplarisch zwei Architektur-Frameworks vorgestellt (Kapitel 2.3.3), um im nachfolgenden Kapitel serviceorientierte Architekturen am Beispiel dieser Frameworks in die allgemeine Architekturthematik einordnen zu können. Zudem wird auf das Architekturmanagement im Rahmen des Informationsmanagements (Kapitel 2.3.4) eingegangen. Im Anschluss daran wird in das Thema der computergestützten Visualisierung eingeführt. Dabei wird neben allgemeinen Grundlagen (Kapitel 2.4.1 - 2.4.3) und weiterführenden Konzepten (Kapitel 2.4.4 und 2.4.5) das Forschungsgebiet der Softwarevisualisierung näher betrachtet (Kapitel 2.4.6). Zum Abschluss des Kapitels werden verwandte Arbeiten unterschiedlicher Forschungsbereiche betrachtet (Kapitel 2.5), die bestimmte Aspekte der in dieser Arbeit aufgestellten Forschungsfragen behandeln und somit Anknüpfungspunkte liefern können. Der allgemeine Systembegriff wird erst später in der Arbeit im Zusammenhang mit komplexen Systemen und dem damit verbunden Komplexitätsverständnis diskutiert (Kapitel 4.2.1). Dies gilt ebenfalls für den Informationsbegriff, der im Rahmen der soziologischen Systemtheorie bzw. der Theorie sozialer Systeme Luhmanns genauer betrachtet wird (Kapitel 4.2.3.3). Dem Informationsbegriff wird dabei die klassische Formulierung von Bateson zugrunde gelegt, die Information als „a difference which makes a difference“ (Bateson 2000, S. 315) beschreibt. Bezüglich des Informationsbegriffs existieren nach wie vor kontroverse Auffassungen. Für Diskussionen, die das Verständnis und die Verwendung des Informationsbegriffs unterschiedlicher wissenschaftlicher Disziplinen und Theorien aufgreifen, sei bspw. auf (Klemm 2003; Rechenberg 2003; Hesse et al. 2008; Janich 2006) verwiesen. 2.1

Betriebliche Informations- und Anwendungssysteme

Da im Kontext serviceorientierter Architekturen der übergeordnete Betrachtungsgegenstand betriebliche Informationssysteme (BIS) sind, wird zunächst ein Überblick über das Begriffs-

T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_2, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

14

Grundlagen und Begriffe

verständnis von Informationssystemen gegeben. Der Begriff Informationssystem (IS) wird in der Literatur abhängig von der eingenommenen Sichtweise unterschiedlich interpretiert. Viele Veröffentlichungen im Bereich der Wirtschaftsinformatik verwenden den Begriff Informationssystem5 im Sinne eines technischen Systems zur Informationsverarbeitung oder als Synonym für betriebliche Anwendungssysteme (Teubner 1999, S. 20; Jung 2006, S. 11). Bspw. versteht Dern unter einem Informationssystem bzw. einer Geschäftsanwendung oder einem Geschäftssystem die „Menge fachlicher und infrastruktureller Softwarebausteine, welche die Durchführung von Kern- und Serviceprozessen unterstützen und die so zusammenspielen, dass die Außensicht eines abgegrenzten, eigenständigen Systems in Form wohldefinierter Schnittstellen (Interfaces) entsteht.“ (Dern 2006, S. 17) Demnach sieht er in der Anwendungslandschaft (Informationssystemlandschaft, IS-Landschaft) „die gewachsene Gesamtheit aller Informationssysteme eines Unternehmens“, die „zur Unterstützung der Durchführung von Geschäftsprozessen betrieben wird.“ (Dern 2006, S. 17) Es existieren jedoch auch zahlreiche Publikationen, die im weiteren Sinne Menschen/ Personen, Organisationsstrukturen, betriebliche Aufgaben und Prozesse sowie Technik und Anwendungssysteme in einem Informationssystem zusammenfassen (Grochla 1975; Mertens et al. 2001, S. 47; Krcmar 2005; Ferstl und Sinz 2006; Hansen und Neumann 2009, S. 131f.). In diesem Zusammenhang wird häufig auch von Informationssystemen gesprochen, d.h. das Gesamtinformationssystem wird in mehrere Sub-Informationssysteme zerlegt (Krcmar 2005, S. 26). Die Teilsysteme liegen abhängig vom Anwenderfokus und den unterstützten Aufgaben in verschiedenen Ausprägungen vor und lassen sich unterschiedlich klassifizieren. Nach Krcmar lassen sich bspw. betriebliche und überbetriebliche sowie branchenspezifische und branchenneutrale Informationssysteme unterscheiden (Krcmar 2005, S. 26). Eine ähnliche Klassifizierung nehmen auch Hansen und Neumann mit der Einteilung in interne (innerbetriebliche IS) und außenwirksame (zwischenbetriebliche IS und Konsumenten-IS) Informationssysteme vor (Hansen und Neumann 2009, S. 138ff.). Den Ausführungen zum Profil der Wirtschaftsinformatik der Wissenschaftlichen Kommission der Wirtschaftsinformatik zu Folge sind Informationssysteme „soziotechnische (MenschMaschinen-) Systeme, die menschliche und maschinelle Komponenten (Teilsysteme) umfassen und zum Ziel der optimalen Bereitstellung von Information und Kommunikation nach wirtschaftlichen Kriterien eingesetzt werden.“ (WKWI 1994, S. 80f.)

5

Eine Auswahl unterschiedlicher Begriffsdefinitionen stellen Ferst und Sinz in (Ferstl und Sinz 2006, S. 9f.) gegenüber.

Betriebliche Informations- und Anwendungssysteme

15

Nach Hansen und Neumann besteht ein Informationssystem „aus Menschen und Maschinen, die Informationen erzeugen und/oder benutzen und die durch Kommunikationsbeziehungen miteinander verbunden sind.“ (Hansen und Neumann 2009, S. 131f.) Aufbauend auf dieser Definition unterstützt ein betriebliches Informationssystem „die Leistungsprozesse und Austauschbeziehungen innerhalb eines Betriebs sowie zwischen dem Betrieb und seiner Umwelt.“ (Hansen und Neumann 2009, S. 132) Als rechnergestütztes Informationssystem bezeichnen sie ein System, „bei dem die Erfassung, Speicherung, Übertragung und/oder Transformation von Information durch den Einsatz der Informationstechnik teilweise automatisiert ist.“ (Hansen und Neumann 2009, S. 133) Eine noch umfassendere Sicht nehmen Ferstl und Sinz bei ihrer Definition des Begriffs betriebliches Informationssystem ein: „Das IS eines Gegenstandsbereiches (eines Unternehmens, eines Unternehmensbereiches, einer Behörde) ist dessen gesamtes informationsverarbeitendes Teilsystem.“ (Ferstl und Sinz 2006, S. 2) Demnach ist jedes IS „Teilsystem umfassenderer Systeme und enthält selbst wiederum Teilsysteme.“ (Ferstl und Sinz 2006, S. 5) Heinrich et al. unterscheiden Menschen, Aufgaben und Techniken als die drei wesentlichen Elemente oder Komponenten eines Informationssystems und beschreiben diese wie folgt (Heinrich et al. 2007, S. 15f.): x

Menschen: Individuen und Gruppen, die an der Konstruktion, Einführung, Nutzung und dem Betrieb von Informationssystemen beteiligt sind oder wesentlich von diesen berührt werden.

x

Aufgaben: Einzelprobleme oder Problembereiche in Wirtschaft und Verwaltung, durch die Leistungsanforderungen an Informationssysteme entstehen.

x

Informations- und Kommunikationstechniken: Einzeltechniken und integrierte Techniksysteme (Hardware, Software, Programmiersysteme).

Abbildung 3 zeigt die generelle Struktur eines Informationssystems, das durch den Fokus auf die drei zuvor genannten Komponenten auch als Mensch-Aufgabe-Technik-System (MATSystem) bezeichnet wird (Heinrich et al. 2007, S. 15). Im Vordergrund dabei stehen aber weniger die einzelnen Komponenten, sondern vielmehr die Beziehungen zwischen den Komponenten sowie die Methoden und Werkzeuge zur Konstruktion, Einführung, Nutzung und zum Management von MAT-Systemen. Ferstl und Sinz nehmen eine ähnliche Unterscheidung von Komponenten eines betrieblichen Informationssystems vor, ordnen diese aber unterschiedlichen Ebenen zu (Ferstl und Sinz 2006, S. 3f.): einer Aufgabenebene und einer Aufgabenträgerebene (siehe Abbildung 4). Zu den Komponenten der Aufgabenebene zählen Informationsverarbeitungs-Aufgaben {A1,A2,…} und deren Informationsbeziehungen. Unterschieden werden Lenkungsaufgaben und Durchführungsaufgaben. Die Aufgabenträgerebene bilden eine Menge von Aufgabenträ-

16 1

Grunddlagen und Begriffee

gern g (maschinellle Aufgabenträäger {R1,R2,…}} und personellle Aufgabenträgger {P1,P2,…})) und u deren Komm munikationsbeziiehungen. Die beiden b Ebenen sind s über Zuorddnungsbeziehun-gen g zwischen Auufgaben und Auufgabenträgern miteinander m verrbunden, wobei Aufgaben auto-matisiert m von Reechnern und nichht-automatisiert von Personen durchgeführt d werrden können.

Abbildung A 3: Gen nerelle Struktur eiines Informationssystems Quelle: Q (Heinrich ett al. 2007, S. 16)

Betriebliche B Anw wendungssystem me werden als au utomatisierte Auufgabenträger der Aufgabenträ-gerebene g verstannden und sind somit s als Teil eiines Informationnssystems zu beetrachten (Ferstll und u Sinz 2006, S. 4f.). Anwenndungssysteme setzen sich auss Hardware-Systtemen, System-software s und Annwendungssoftw ware zusammen und sind „speziiell auf einzelnee Aufgaben oderr Aufgabenbereich A he eines IS zugeeschnitten.“ (Feerstl und Sinz 20006, S. 5) Heinrrich und Stelzerr sind s ähnlicher A Auffassung und definieren ein Anwendungssys A stem als „Teil eines e Informati-onssystems, o dass zur Unterstüttzung einer besstimmten Aufgaabe eingesetzt wird“ und diee „Kombination „ von Anwendungssprogramm oder -programmen und zugehörigeen Daten“ bildett (Heinrich und Sttelzer 2009, S. 269). 2 Stahlknecht S undd Hasenkamp unnterscheiden zw wischen Anwenddungssystemen im i engeren undd im m weiteren Sinnne (Hasenkamp und Stahlknechht 2004, S. 204fff.): „Im engerenn Sinn handelt ess sich s bei einem Anwendungssyystem um die Gesamtheit G allerr Programme, die d als Anwen-dungssoftware d fü für ein konkretees betriebliches Anwendungsgebiet entwickelt,, eingeführt undd eingesetzt e werdeen, und um die zugehörigen Daaten, die in unteerschiedlichen Formen F der Da-tenorganisation […] bereitgesteellt werden.“ (H Hasenkamp und Stahlknecht 20004, S. 204) Im m weiteren w Sinn vverstehen sie unnter Anwendunggssystemen, weenn bei deren Entwicklung E diee Entscheidungen E über Fragen derr Hardware, derr Systemsoftware und/oder der Kommunikation K n eingeschlossen e w werden, die dannn das Basissysstem des Anweendungssystems bilden (Hasen-kamp k und Stahlkknecht 2004, S. 205). In dieser Arbeit werden die Beegriffe Informatiionssystem bzw w. betriebliche Innformationssys-tem in Anlehnunng an das Verstäändnis von Heinnrich et al. (Heinnrich et al. 2007)) und Ferstl undd

In nformationsmanagement

177

Sinz S (Ferstl undd Sinz 2006) veerwendet. Betrieebliche Anwenddungssysteme werden w demnachh als a eine Komponnente von Inform mationssystemen n verstanden.

Abbildung A 4: Auffgaben- und Aufgaabenträgerebene eines e IS Quelle: Q (Ferstl und Sinz 2006, S. 3)

2.2 2

Informaationsmanagem ment

In der Literatur existieren verschiedene Definitionen des Beggriffs Informatioonsmanagementt (IM) (z.B. (Krcm mar 2005, S. 499; Ferstl und Sin nz 2006, S. 73; Heinrich und Stelzer S 2009, S.. 12; 1 Mertens et al. a 1998, S. 1722; Picot et al. 20 003, S. 144; Zarrnekow et al. 20004, S. 4)). Diee unterschiedliche u n Sichtweisen der d Autoren und d deren differennzierte Betrachtuungen in Bezugg auf a die Ziele unnd Aufgaben dess Informationsm managements baasieren jedoch auf a einem ähnli-chen c Grundversttändnis (vgl. (Baaumöl 2009, S. 20ff.)). 2 2.2.1 2

Ziele und u Aufgaben dees Informationsm managements

Nach N Ferstl undd Sinz ist das Innformationsmannagement „für die d Gestaltung und u den Betriebb des d automatisierrten Teils des beetrieblichen Info formationssystem ms zuständig.“ (Ferstl ( und Sinzz 2006, 2 S. 73) Siee betrachten das Informationsmaanagement aus Sicht des Gesam mtunternehmenss und u sehen darin eine betrieblichhe Querfunktionn mit dem Sachzziel der Planung, Steuerung undd Kontrolle K des auutomatisierten Teils T des IS (Feerstl und Sinz 2006, 2 S. 73ff.). Der Aufgaben-komplex k des IM M wird in strateggische, taktische und operative Aufgaben A eingeeteilt (Ferstl undd Sinz S 2006, S. 75):

18

Grundlagen und Begriffe

x

Strategisches IM: Aspekte mit langfristigem Planungshorizont, die sich auf das Sachziel „Gestaltung des IS beziehen“ und das gesamte Unternehmen bzw. das gesamte IS betreffen.

x

Taktisches IM: Umsetzung der strategischen Vorgaben und Realisierung der maschinellen Komponenten eines IS (Gestaltung der Anwendungssysteme und Realisierung der Rechner- und Kommunikationsinfrastruktur).

x

Operatives IM: Organisation der Aufgabendurchführung mit kurz- und mittelfristigem Planungshorizont.

Als Formalziele des IM nennen Ferstl und Sinz die Wirtschaftlichkeit der Aufgabendurchführung durch Einhaltung von Kosten-Nutzen-Relationen sowie den Zielerreichungsgrad der Sachziele des IM, der mithilfe qualitativer und quantitativer Merkmale ermittelt wird (Ferstl und Sinz 2006, S. 76). Auch Heinrich und Stelzer unterscheiden zwischen Sach- und Formalzielen des IM (Heinrich und Stelzer 2009, S. 39ff.). Das generelle Sachziel sehen sie darin, „das Leistungspotenzial der Informationsfunktion durch Schaffung, Aufrechterhaltung und Weiterentwicklung einer geeigneten IT-Infrastruktur in Unternehmenserfolg umzusetzen und damit die Erreichung der strategischen Unternehmensziele zu unterstützen bzw. die Zielerreichung erst zu ermöglichen (IT als Enabler).“ (Heinrich und Stelzer 2009, S. 39) Als generelles Formalziel des IM nennen sie wie Ferstl und Sinz Wirtschaftlichkeit durch die Einhaltung von Kosten-NutzenRelationen. Krcmar sieht das Informationsmanagement als einen Teilbereich der Unternehmensführung an. Er definiert Informationsmanagement wie folgt: „IM ist das Management der Informationswirtschaft, der Informationssysteme, der Informations- und Kommunikationstechniken sowie der übergreifenden Führungsaufgaben. Das Ziel des IM ist es, im Hinblick auf die Unternehmensziele den bestmöglichen Einsatz der Ressource Information zu gewährleisten. IM ist sowohl Management als auch Technikdisziplin und gehört zu den elementaren Bestandteilen der Unternehmensführung.“ (Krcmar 2005, S. 49) Das von Krcmar entwickelte Referenzmodell des IM (siehe Abbildung 5) gliedert die Managementaufgaben nach Handlungsobjekten, die auf drei Ebenen (Information, Anwendungen und Technik) verteilt sind. Die Managementaufgaben werden ebenenübergreifend durch Führungsaufgaben des Informationsmanagements begleitet. Krcmar betont in diesem Zusammenhang jedoch, dass sich die Gestaltung des IM nicht nur auf die ebenenübergreifenden Führungsaufgaben reduzieren lässt, sondern in allen vier Gruppen zusätzlich Gestaltungsaufgaben betrachtet werden müssen (vgl. (Krcmar 2005, S. 47ff.)).

In nformationsmanagement

199

Abbildung A 5: Modell des IM nach Krcmar K Quelle: Q (Krcmar 2005, S. 47)

2.2.2 2

Inform mationsangebot und u Informationnsbedarf

Die D zentrale Fraggestellung des IM I im Bereich der d Informationsswirtschaft ist Krcmar K zu Folgee „die „ nach dem Gleichgewicht G z zwischen Inform mationsangebot und u Informationnsbedarf.“ (Krc-mar m 2005, S. 5) Picot P et al. definnieren Informationsbedarf als „die „ Art, Mengee, und Qualität der Informatio-nen, n die eine Person zur Erfülluung ihrer Aufgaaben in einer besstimmten Zeit benötigt.“ b (Picott et e al. 2003, S. 81) Dabei untersscheiden sie zwiischen objektiveem und subjektiivem Informati-onsbedarf, o die inn der Regel vonneinander abweicchen, so dass deer subjektive ann den objektivenn Informationsbeddarf angenähert werden muss. Objektiver O Inforrmationsbedarf wird w durch einee in nformationsorieentierte Analysee der zu erfüllen nden Aufgaben bestimmt und gibt g an, „welchee Art A und Menge an Informationeen ein Entscheid dungsträger zurr Erfüllung seineer Aufgabe ver-wenden w sollte.“ (Picot et al. 20003, S. 81) Sub bjektiver Inform mationsbedarf hiingegen beziehtt sich s auf den Beddarf, den ein Enntscheidungsträgger aus seiner persönlichen p Sicchtweise zur Er-füllung f von Aufg fgaben als relevaant betrachtet. Der D subjektive uund der objektive Informationsbbedarf, die in derr Regel voneinaander abweichenn und u nur eine besstimmte Schnittm menge besitzen, stützen sich auuf das Informatioonsangebot (sie--

20

Grundlagen und Begriffe

he Abbildung 6). Die Informationsnachfrage bildet dabei eine Teilmenge des Informationsbedarfs. Die Informationsversorgung wird jedoch nur in dem Bereich erreicht, in dem Informationsnachfrage und Informationsangebot zusammenfallen. Der tatsächliche Informationsstand ist dann der Teil der Informationsversorgung, der sich mit dem objektiven Informationsbedarf überschneidet (vgl. (Picot et al. 2003, S. 81)).

objektiver Informationsbedarf

Informationsstand

Infonachfrage

subjektiver Informationsbedarf

Informationsangebot

Abbildung 6: Informationsbedarf und Informationsversorgung Quelle: (Picot et al. 2003, S. 82)

Das Begriffsverständnis von Picot et al. wird in vielen Veröffentlichungen im Bereich der Wirtschaftsinformatik übernommen oder als Basis für die Begriffsanalyse verwendet (siehe z.B. (Jung 2006, S. 51; Mertens et al. 2001, S. 238f.; Krcmar 2005, S. 59f.; Heinrich und Stelzer 2009, S. 419)). Auch diese Arbeit orientiert sich an dem Vorschlag von Picot et al.. Ein weiterer Aspekt, der für diese Arbeit von Bedeutung ist, wird von Krcmar in Bezug auf den Informationsbedarf ergänzend angeführt: Er spricht von individuellen Informationsbedarfsprofilen, in denen der Informationsbedarf aus den Ergebnissen der Informationsbedarfserhebung für unterschiedliche Nutzergruppen aggregiert werden kann (Krcmar 2005, S. 59). Demnach dient ein Profil der Definition des Informationsbedarfs auf Basis individueller Kriterien. 2.3

Architekturen

Als Grundlage für das Architekturverständnis im Kontext serviceorientierter Architekturen wird im Folgenden der Architekturbegriff näher betrachtet. Um serviceorientierte Architekturen später in die Architekturthematik einordnen zu können, wird ein Überblick über den Bereich der Unternehmensarchitektur gegeben sowie Architekturmodelle bzw. Architektur-

Architekturen

21

Frameworks am Beispiel des Zachman Enterprise Frameworks und des Open Group Architecture Frameworks (TOGAF) vorgestellt. 2.3.1

Architekturbegriff

Im Laufe der letzten Jahrzehnte sind im Umfeld der Informationstechnologie verschiedene Disziplinen entstanden, die den Architekturbegriff abhängig vom jeweiligen Bezugsrahmen und den Betrachtungsgegenständen (z.B. Daten, Informationen, Softwareelemente, Anwendungssysteme, Technologien, Infrastrukturen, Geschäftsprozesse, Organisationsstrukturen, Unternehmensstrategien) aus unterschiedlichen Perspektiven verwenden und kontrovers diskutieren. Die unterschiedlichen Architekturdisziplinen beschreiben Prinzipien und Methoden zur Erstellung und Beschreibung diverser Architekturtypen, wie z.B. Systemarchitekturen, Softwarearchitekturen, IT-Architekturen, Informationsarchitekturen, Geschäftsarchitekturen oder Unternehmensarchitekturen. Aufgrund der zahlreichen unterschiedlichen Sichtweisen und der breiten Anwendung des Architekturbegriffs existiert bis heute weder disziplinübergreifend noch innerhalb der einzelnen Disziplinen ein einheitliches Begriffsverständnis. Dies ist bspw. an den zahlreichen Definitionen im Bereich der Softwarearchitekturen auszumachen. Die Website des Software Engineering Institute (SEI) der Carnegie Mellon Universität6 listet mehr als 200 Definitionen für den Begriff der Softwarearchitektur, die in diversen Veröffentlichungen erschienen sind oder von der Softwarearchitektur-Community beigetragen wurden. Shaw und Garlan, die neben vielen anderen Forschern die Disziplin der Softwarearchitektur seit Anfang der 1990er mitgeprägt haben (vgl. (Kruchten et al. 2006)), definieren die Architektur eines Softwaresystems wie folgt: „The architecture of a software system defines that system in terms of computational components and interactions among those components.“ (Shaw und Garlan 1996, S. 3) Während sich das damalige Architekturverständnis im Bereich der Softwarearchitekturforschung noch primär auf den Aufbau einzelner Softwaresysteme bezog (Keller 2007, S. 15) und der Fokus auf Softwarekomponenten gerichtet war, wird der Begriff heute umfassender betrachtet. Zudem wird, wie Dern anmerkt, in Bezug auf die gesamte Anwendungslandschaft eines Unternehmens nicht nur von einer Architektur7, sondern von mehreren Architekturen gesprochen (Dern 2006, S. 1f.).

6 7

http://www.sei.cmu.edu/architecture/start/definitions.cfm Dern verwendet in diesem Zusammenhang nicht den klassischen Begriff der Softwarearchitektur, sondern den Begriff der IT-Architektur.

22

Grundlagen und Begriffe

Im Bereich der Wirtschaftsinformatik wird der allgemeine Architekturbegriff aufgrund unterschiedlicher Sichtweisen (betriebswirtschaftliche und technische Sicht) sehr weit gefasst. Bspw. verstehen Heinrich und Stelzer unter der Architektur eines Systems dessen Organisation, „welche sich in den Komponenten und deren Beziehungen zueinander sowie zum Systemumfeld manifestiert.“ (Heinrich und Stelzer 2009, S. 63) Zudem kann die Architektur auch die Gestaltungsprinzipien und Konstruktionsregeln umfassen. Die drei grundlegenden Funktionen, die Architekturen übernehmen, sind nach Heinrich und Stelzer die Beschreibungs-, Kommunikations- und Gestaltungsfunktion (Heinrich und Stelzer 2009, S. 62f.). Ein ähnliches Begriffsverständnis haben Ferstl und Sinz, die Architekturen im IT-Umfeld in Analogie zur Architekturlehre im Bauwesen betrachten. Demnach umfasst die Architektur eines Informationssystems oder Anwendungssystems „dessen Bauplan im Sinne einer Spezifikation seiner Komponenten und ihrer Beziehungen unter allen relevanten Blickwinkeln sowie die Konstruktionsregeln für die Erstellung des Bauplans.“ (Ferstl und Sinz 2006, S. 447) Im Gegensatz zu Heinrich und Stelzer sehen Ferstl und Sinz die Konstruktionsregeln jedoch als festen Bestandteil der Architektur an. Nach Sinz (Sinz 2002) besitzen Architekturen sowohl einen Beschreibungsaspekt (Modellsystem mit Modellebenen und Sichten) als auch einen Konstruktionsaspekt (Konstruktionsregeln zur Erstellung des Modellsystems in Form von Methoden, Architekturmustern oder Architekturstilen). Jung hingegen widerspricht dieser Auffassung und argumentiert, dass Konstruktionsregeln zwar von großer Bedeutung sind und expliziert werden sollten, in der Praxis jedoch auch „gewachsene“ Architekturen vorzufinden sind, „die nicht das Ergebnis eines von Konstruktionsregeln geleiteten Entstehungsprozesses sind.“ (Jung 2006, S. 55) Eine weitere Definition des Architekturbegriffs liefert der internationale Standard ISO/IEC 42010 IEEE Std 1471-2000 (ISO/IEC und IEEE 2007), mit dem im Bereich des Systems und Software Engineering eine Empfehlung zur Architekturbeschreibung und -dokumentation softwareintensiver Systeme erarbeitet wurde. Laut ISO/IEC 42010 IEEE Std 1471-2000 ist eine Architektur: „The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.“ (ISO/IEC und IEEE 2007, S. 3) Die vorliegende Arbeit orientiert sich an dem Architekturverständnis des ISO/IEC 42010 IEEE Std 1471-2000-Standards, da mit der Definition die Absicht verfolgt wird, die Verwendung einer Vielzahl unterschiedlicher Begriffsdefinitionen durch die Identifikation gemeinsamer grundlegender Elemente abzudecken: „This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physi-

Architekturen

23

cal, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains.“ (ISO/IEC und IEEE 2007, S. 14) 2.3.2

Unternehmensarchitektur

Der Begriff Unternehmensarchitektur (engl. Enterprise Architecture) ist in Wissenschaft und Praxis weit verbreitet (vgl. (Aier et al. 2008)) und es existieren zahlreiche wissenschaftliche Publikationen (z.B. (Krcmar 1990; Frank 1994b; Ferstl und Sinz 1995; Lankhorst 2009)) sowie Publikationen aus dem Praxisumfeld (z.B. (Dern 2006; Keller 2007; Zachman 1987; Schekkerman 2004; The Open Group 2009c)) zu diesem Thema. Lankhorst bspw. versteht unter einer Unternehmensarchitektur bzw. einer Enterprise Architecture ganz allgemein „a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise’s organisational structure, business processes, information systems, and infrastructure.“ (Lankhorst 2009, S. 3) Eine detailliertere Beschreibung, was unter einer Unternehmensarchitektur bzw. Enterprise Architecture zu verstehen ist, liefert Shekkerman. Er sieht in der Enterprise Architecture „a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organisation structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks. In a large modern enterprise, a rigorously defined framework is necessary to be able to capture a vision of the "entire organisation" in all its dimensions and complexity. Enterprise Architecture (EA) is a program supported by frameworks, which is able to coordinate the many facets that make up the fundamental essence of an enterprise at a holistic way.“ (Schekkerman 2004, S. 13f.) Das allgemeine Begriffsverständnis der zuvor zitierten Autoren ist nur exemplarisch gewählt, spiegelt aber im Wesentlichen das Verständnis des Verfassers dieser Arbeit wider. Eine tiefergreifende Diskussion zum Begriffsverständnis wäre im Rahmen dieser Arbeit nicht zielführend. Für einen systematischen Überblick und den aktuellen Stand des Themas Unternehmensarchitektur in Literatur und Praxis sei daher auf den Beitrag von Aier et al. (Aier et al. 2008) und die dort genannten Quellen verwiesen. Sie schaffen darin einen Literaturüberblick zu Verständnis, Abbildung in Modellen und Nutzungsszenarien von Unternehmensarchitekturen sowie eine empirische Untersuchung zu Verständnis, Abbildung und Nutzung von Unter-

24

Grundlagen und Begriffe

nehmensarchitekturen in der Praxis. Des Weiteren diskutieren sie die Unterschiede und Gemeinsamkeiten in Literatur und Praxis. Aus den zahlreichen Publikationen im Bereich der Unternehmensarchitektur ist eine Vielzahl an Gesamtarchitekturansätzen, -modellen und -Frameworks hervorgegangen, die mit unterschiedlichen Zielsetzungen entwickelt wurden. Zu nennen sind bspw. das Architekturmodell von Krcmar (Krcmar 1990), das Semantische Objektmodell (SOM) (Ferstl und Sinz 1995), das ARIS-Konzept (Architektur integrierter Informationssysteme) (Scheer 2001), der Business Engineering Ansatz (Österle 1995), die Architekturpyramide von Dern (Dern 2006), das Zachman Framework (Zachman 1987) oder das Open Group Architecture Framework (TOGAF) (The Open Group 2009c). Einen detaillierten Überblick bzw. eine Gegenüberstellung unterschiedlicher Ansätze geben z.B. Schekkerman (Schekkerman 2004) sowie der zuvor erwähnte Beitrag von Aier et al. (Aier et al. 2008). Durch die Vielzahl verschiedener Ansätze unterscheidet sich neben dem allgemeinen Begriffsverständnis auch das Verständnis bezüglich der betrachteten Gestaltungsobjekte. Aier et al. stellen fest, dass bei der Detaillierung der entworfenen Unternehmensarchitekturmodelle zwei Dimensionen unterschieden werden können: Der Umfang bzw. die Breite der betrachteten Gestaltungsobjekte und das Granularitätsniveau der beschriebenen Gestaltungsobjekte (Tiefe der Architektur) (Aier et al. 2008, S. 294). Abhängig von den betrachteten Gestaltungsobjekten können verschiedene Architekturtypen unterschieden werden, die sich als Teilarchitekturen in das übergeordnete Konzept der Unternehmensarchitektur einordnen lassen. Ein Architekturtyp umfasst laut Jung „die Komponententypen sowie die Regeln, die zur Konstruktion von Architekturen mit vorgegebenen Eigenschaften anzuwenden sind (Konstruktionsregeln). Die Konstruktionsregeln geben vor, wie Komponenten (Ausprägungen von Komponententypen) mit Blick auf die angestrebten Eigenschaften miteinander in Beziehung zu setzen sind.“ (Jung 2006, S. 55) Je nach Architekturansatz, -modell oder -Framework fällt auch das Verständnis bezüglich der Teilarchitekturen bzw. Architekturtypen, die Art und Weise, wie diese Architekturtypen zu integrieren sind, und wie Abhängigkeiten zwischen den Teilarchitekturen über verschiedene Abstraktionsebenen hinweg beschrieben werden können, unterschiedlich aus. Abbildung 7 zeigt eine Einordnung von Teilarchitekturen, die Engels et al. (Engels et al. 2008, S. 78f.) in Anlehnung an die Veröffentlichungen und das Verständnis von Dern (Dern 2006), Lankhorst (Lankhorst 2009) und Keller (Keller 2007) vornehmen. Demnach umfasst die Unternehmensarchitektur Prinzipien und Methoden, um Geschäfts- und IT-Architektur eines Unternehmens zu entwerfen und umzusetzen und stellt deren Zusammenhang her. Artefakte der Geschäftsarchitektur, die anhand der Geschäftsstrategie und Wertschöpfungskette gestaltet werden, sind Geschäftsprozesse, Geschäftsservices, Geschäftsobjekte und die Organisation eines Unternehmens. Die IT-Architektur umfasst die Informationssystem-Architektur

Architekturen A

255

(IS-Architektur) und die Archiitektur der tech hnischen Infrasttruktur (TI-Archhitektur). Dabeii beschreiben b die Artefakte der IS-Architektur I die d Strukturieruung der Anwenddungslandschaftt aus a fachlicher S Sicht und die Artefakte A der TII-Architektur diee technischen Plattformen P undd Systemsoftwarek S komponenten.

Abbildung A 7: Teillbereiche der Unteernehmensarchiteektur Quelle: Q (Engels et aal. 2008, S. 78)

Den D Versuch, vverschiedene Arrchitekturtypen in Zusammenhhang zu bringenn, unternehmenn auch a Heinrich uund Stelzer (Heiinrich und Stelzzer 2009, S. 64ff.), ohne sich dabei d jedoch auff konkrete k Ansätzze zu beziehen (ssiehe Abbildungg 8). Dabei werdden die Architekkturtypen (Ova-le) den wesentlicchen Inhalten voon Architektureen (Rechtecke) zugeordnet, z wobbei Überlappun-gen g der Architekkturtypen zu erkkennen sind.

Geschäftsm modell

Betriebliche Aufgaben A

Aufbau- und Ablauuforganisation

Anwendungsprogram mme & Daten

Unternehmensarchitektur

Unternehmenssstrategie

Geschääftsarchiteektur

Anwendunggsarchitektuur Inform mationssystemarchiteektur

Technische Infrrastruktur

Softwarearchitektur

Datenarchitektur

techn. Infrastrukkturarchitektur

Abbildung A 8: Übeerblick über verscchiedene Teilarchiitekturen Quelle: Q (Heinrich unnd Stelzer 2009, S. 64)

Neben N der Unterrnehmensarchiteektur, die Heinriich und Stelzer als umfassendstten Architektur-ty yp verstehen, beeschreiben die beiden b Autoren die in Abbildunng 8 dargestellteen Teilarchitek-tu uren wie folgt (H Heinrich und Sttelzer 2009, S. 64f.): 6

26

Grundlagen und Begriffe

x

Geschäftsarchitektur: Beschreibung der Organisation eines Unternehmens, ihre wesentlichen Komponenten, Ressourcen und deren Beziehungen sowie Austauschbeziehungen des Unternehmens mit seiner Umwelt. Die Beschreibung umfasst zudem die zentralen Kundengruppen und Leistungen des Unternehmens, die betrieblichen Aufgaben und Aufgabenträger, Lieferanten, Wettbewerber und Kooperationspartner sowie die Informationsflüsse und Leistungsstrukturen.

x

Anwendungsarchitektur: Beschreibung der Funktionalität und Zusammenhänge der Anwendungssysteme im Unternehmen.

x

Informationssystemarchitektur: Beschreibung der informationstechnischen Infrastruktur, der Daten und Anwendungsprogramme, der unterstützten Aufgaben und der benötigten Aufbau- und Ablauforganisation.

x

Softwarearchitektur: Beschreibung der Komponenten eines Softwaresystems sowie deren Beziehungen und Schnittstellen.

x

Datenarchitektur: Beschreibung der wesentlichen Daten und ihre strukturelle Beziehung, der Datenbanken und der Data-Warehouse-Systeme.

x

Technische Infrastrukturarchitektur: Beschreibung der technischen Komponenten (z.B. Hardware, Betriebssysteme, Kommunikationseinrichtungen) und deren Beziehungen.

Eine weitere Einordnung unterschiedlicher Teilarchitekturen nehmen Winter und Fischer (Winter und Fischer 2006) vor. Den Autoren zufolge werden in den meisten Enterprise Architecture Frameworks folgende Teilarchitekturen bzw. Ebenen einer Unternehmensarchitektur unterschieden (Winter und Fischer 2006, S. 31; Schelp und Winter 2009, S. 252f.): x

Geschäftsarchitektur

x

Prozessarchitektur

x

Integrationsarchitektur

x

Softwarearchitektur

x

Technologie- (oder Infrastruktur-) Architektur

Die Teilarchitekturen bilden in Anlehnung an die Theorie hierarchischer, mehrstufiger Systeme von Mesarovic et al. (Mesarovic et al. 1970) gemeinsam eine mehrstufige Architektur von Aggregationshierarchien (siehe Abbildung 9). Auf jeder der fünf Ebenen werden die Aggregationshierarchien zur Darstellung der Artefakte auf den unterschiedlichen Aggregationsstufen verwendet. Eine einheitliche Abgrenzung und Einordnung der verschiedenen Architekturtypen ist aufgrund der unterschiedlichen Begriffsverständnisse sowie synonymer oder homonymer Begriffsanwendungen in Literatur und Praxis jedoch nicht vorzufinden. Für weitreichendere Diskussionen und eine tiefergreifende wissenschaftliche Auseinandersetzung mit der Thema-

Architekturen

27

tik wurde bereits auf die entsprechenden Quellen verwiesen. Der Überblick bezüglich der Begriffserklärungen und der Einordnung unterschiedlicher Architekturtypen ist im Rahmen dieser Arbeit ausreichend. Im Verlauf der Arbeit wird daher von dem zuvor dargelegten Verständnis ausgegangen. Bus ine ss Archi tecture

Proce ss Architecture

Integ ration Architecture

Software Architecture

Techno logy Architecture

Abbildung 9: Mehrstufige Architektur von Aggregationshierarchien Quelle: (Winter und Fischer 2006, S. 31)

2.3.3

Architekturmodelle und -Frameworks

Wie im vorigen Kapitel bereits erwähnt, sind zahlreiche unterschiedliche Architekturgesamtansätze, -modelle und -Frameworks für die Entwicklung von Unternehmens- bzw. Informationssystemarchitekturen publiziert worden. Im Folgenden werden stellvertretend für andere Ansätze zwei Frameworks vorgestellt, auf die im Laufe der Arbeit wieder eingegangen wird. Das von Zachman 1987 veröffentlichte Framework for Information Systems Architecture (Zachman 1987) wurde 1992 in einer weiteren Publikation (Sowa und Zachman 1992) erweitert und formalisiert und ist seitdem als The Zachman Framework bekannt. Zum jetzigen

28

Grundlagen und Begriffe

Zeitpunkt liegt es als The Zachman Enterprise Framework 2 vor, wobei sich die fundamentalen Konzepte des ursprünglichen Frameworks nicht verändert haben8. Das Zachman Enterprise Framework basiert auf einer 6x6-Matrix (siehe Tabelle 1). Diese stellt mit dem Fokus auf unterschiedliche Perspektiven und Fragestellungen einen Ordnungsrahmen für Anwender bei der Betrachtung von Unternehmensarchitekturen zur Verfügung. Im Folgenden werden die Zeilen und Spalten kurz betrachtet (vgl. (Schekkerman 2004, S. 133f.; Sowa und Zachman 1992). What Inventory

How Process

Where Network

Who Organization

When Timing

Why Motivation

Scope Strategists Business Executive Leaders System Architects Technology Engineers Component Technicians Operations Workers Tabelle 1: Überblick über das Zachman Enterprise Framework 2 Quelle: In Anlehnung an (Zachman 2008))

Die Zeilen der Matrix repräsentieren die Perspektiven unterschiedlicher Rollen:

8

x

Scope: Beschreibt den Anwendungs- bzw. Geltungsbereich aus Sicht der Strategieverantwortlichen, um die Größe, Kosten und Funktionalität des Systems abschätzen zu können.

x

Business: Darstellung der Geschäftsobjekte und -prozesse sowie die Art und Weise, wie sie miteinander interagieren.

x

System: Beschreibt die Datenelemente und Funktionen auf Systemebene, sowie die Verteilung der Systemkomponenten, die als Grundlage für die Verwaltung der Geschäftsobjekte und Ausführung der Geschäftsprozesse dienen.

x

Technology: Betrachtet die Entwürfe, in denen die Systemebene verfeinert und auf konkrete Programmiersprachen, Hardware oder andere Technologien übertragen wird.

Für eine Übersicht der Evolution des Zachman Frameworks siehe http://www.zachmaninternational.com/ index.php/ea-articles/100-the-zachman-framework-evolution

Architekturen

29

Dabei müssen die Rahmenbedingungen und Restriktionen der zugrunde liegenden Werkzeuge, Technologien und Plattformen berücksichtigt werden. x

Component: Betrachtet die Detailentwürfe für einzelne Systemkomponenten aus Sicht von Entwicklern, ohne dass diese den übergeordneten Kontext oder die Struktur des Gesamtsystems kennen müssen.

x

Operations: Stellt das operative System aus Sicht der Nutzer dar.

Die zentralen Fragestellungen nach dem Was, Wie, Wo, Wer, Wann und Warum werden in den Spalten der Matrix abgebildet: x

Inventory (What?): Welche Daten werden verarbeitet? Beschreibt die Entitäten auf den unterschiedlichen Abstraktionsebenen (Perspektiven) des Unternehmens. Dazu zählen bspw. Geschäftsobjekte, Stamm- und Bewegungsdaten, Datentabellen und Felddefinitionen.

x

Process (How?): Wie werden diese Daten verarbeitet? Stellt die Funktionen auf den unterschiedlichen Abstraktionsebenen dar. Beispiele sind Geschäftsprozesse, Anwendungs- oder Hardwarefunktionen.

x

Network (Where?): Wie sind die Komponenten verteilt? Beschreibt Aspekte der Verteilung, wie z.B. Standorte und Verbindungen.

x

Organization (Who?): Wer sind die Aufgabenträger? Stellt die Personen und deren Beziehungen im Unternehmen dar. Bei dem Entwurf der Unternehmensorganisation werden bspw. die Aufgabenverteilung, Rollen und Verantwortlichkeiten beschrieben.

x

Timing (When?): Wann werden welche Ereignisse ausgelöst? Stellt die zeitliche Abfolge von Ereignissen dar, um Leistungskriterien und Qualitätsstufen hinsichtlich der Unternehmensressourcen festlegen zu können.

x

Motivation (Why?): Was sind die Ziele und Beweggründe? Beschreibt die Motivation des Unternehmens und berücksichtigt damit die Ziele und Beweggründe der unterschiedlichen Perspektiven.

Die einzelnen Zellen bzw. Aspekte, die sich aus den Zeilen und Spalten ergeben, sind eindeutig voneinander abgrenzbar. Für jede Zelle können verschiedene Techniken9, wie z.B. Flow Charts, Struktur- oder Entity-Relationship-Diagramme, zur Beschreibung der entsprechenden Sachverhalte eingesetzt werden (vgl. (Sowa und Zachman 1992)). Im Rahmen der offiziellen Definition des Zachman Frameworks (Zachman 2008) wird explizit darauf hingewiesen, dass es sich bei dem Framework nicht um eine Methodologie (Pro9

Die Webseite http://www.zachmanframeworkassociates.com/Standards/protected/Enterprise-FrameworkStandards bietet die Möglichkeit durch das Zachman Framework zu navigieren und die Zelldefinitionen im Einzelnen zu betrachten. Eine Anmeldung auf der Webseite ist erforderlich.

30

Grundlagen und Begriffe

zess), sondern um eine Ontologie (Struktur) zur Beschreibung des Unternehmens handelt. Im Gegensatz dazu stellt das von der Open Group entwickelte TOGAF (The Open Group Architecture Framework) (The Open Group 2009c) eine detaillierte Methode zur Architekturentwicklung dar. Die erste TOGAF-Version wurde 1995 entwickelt und basierte auf dem Technical Architecture Framework for Information Management (TAFIM) des US Department of Defense (DoD). Aktuell liegt das Framework in der Version 9 vor. TOGAF befürwortet die Terminologie des ISO/IEC 42010 IEEE Std 1471-2000, ist aber nicht strikt daran ausgerichtet. So wird bspw. die Architekturdefinition des ISO/IEC 42010 IEEE Std 1471-2000 in TOGAF angeführt. Dem Architekturbegriff werden jedoch abhängig vom Kontext zwei unterschiedliche Bedeutungen beigemessen (The Open Group 2009c, S. 9): 1. „A formal description of a system, or a detailed plan of the system at component level to guide its implementation.“ 2. „The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.“ Bezüglich der zuvor angesprochenen Architekturdisziplinen bietet TOGAF Unterstützung für die folgenden Teilarchitekturen einer Unternehmensarchitektur (The Open Group 2009c, S. 10): x

Geschäftsarchitektur

x

Datenarchitektur

x

Anwendungsarchitektur

x

Technologiearchitektur

Das TOGAF-Framework setzt sich aus verschiedenen Teilkonzepten zusammen, die miteinander integriert sind. Die TOGAF-Dokumentation ist in sieben Hauptteile strukturiert (siehe Abbildung 10), in denen diese Konzepte detailliert erläutert werden (vgl. (The Open Group 2009c, S. 4f.)): x

Teil I (Introduction): Der erste Teil stellt eine Einführung in die Schlüsselkonzepte der Unternehmensarchitektur im Allgemeinen und des TOGAF-Ansatzes im Speziellen zur Verfügung. Er umfasst zudem die Definitionen von Begriffen, die im Rahmen von TOGAF verwendet werden, sowie Versionshinweise mit Details über Änderungen zwischen der aktuellen und den vorherigen Versionen von TOGAF.

x

Teil II (Architecture Development Method): Der zweite Teil stellt den Kern von TOGAF dar. Er beschreibt die TOGAF Architecture Development Method (ADM), bei der es sich um einen iterativen Ansatz zur Entwicklung von Unternehmensarchitekturen handelt.

Architekturen A

311

Abbildung A 10: Stru uktur der TOGAF F-Dokumentation Quelle: Q (The Open G Group 2009c, S. 4))

x

Teil III (A (ADM Guidelinees and Techniqu ues): Der dritte Teil beinhaltet eine Sammlungg von Richhtlinien und Tecchniken, die bei der Umsetzungg von TOGAF und u der TOGAF F ADM einngesetzt werdenn können.

x

Teil IV (A (Architecture Coontent Framewo ork): Im vierten Teil wird das TOGAF T Contentt Framewoork beschrieben,, welches ein strrukturiertes Mettamodel für Arcchitekturartefak-te, die V Verwendung wiederverwendbareer Architektur-B Building Blocks und eine Über-sicht typiischer Architekttur-Deliverabless beinhaltet.

x

Teil V (E Enterprise Contiinuum & Tools)): Der fünfte Teeil diskutiert geeeignete Taxono-mien undd Werkzeuge zuur Kategorisierun ng und Speicherrung der Ergebnnisse von Archi-tekturakttivitäten im Unteernehmen.

x

Teil VI (T TOGAF Referennce Models): Deer sechste Teil sttellt eine Auswaahl an Architek-turreferennzmodellen zur Verfügung. Diiese beinhaltet die d TOGAF Fouundation Archi-tecture (technisches Referenzmodell) und u das Integraated Informationn Infrastructuree Referencce Model (III-RM M).

x

Teil VII (Architecture ( Caapability Frameework): Der siebbte Teil diskutieert die Organisa-tionsstrukkturen, Prozessee, Fähigkeiten, Rollen und Verrantwortlichkeiten, die benötigtt

32

Grundlagen und Begriffe

werden, um „Architektur“ als Funktion im Unternehmen zu etablieren und zu betreiben. Das Architecture Capability Framework stellt entsprechende Referenzmaterialien zur Verfügung, an denen sich bei der Etablierung und beim Betrieb orientiert werden kann. Wie bereits erwähnt und in Abbildung 10 dargestellt, bildet die TOGAF Architecture Development Method den Kern von TOGAF. Die ADM integriert andere Elemente und Konzepte von TOGAF, um den Geschäfts- und IT-Anforderungen bestmöglich zu entsprechen. Die Basisstruktur der ADM bildet der Architecture Development Cycle (siehe Abbildung 11), welcher aus zehn verschiedenen Phasen besteht, die jeweils in weitere Schritte unterteilt sind (The Open Group 2009c, S. 49ff.). Der gesamte Prozess, die einzelnen Phasen und die Schritte innerhalb der Phasen werden iterativ durchlaufen, wobei für jede Iteration neue Entscheidungen getroffen werden müssen. Im Folgenden wird eine grobe Übersicht über die einzelnen Phasen gegeben (vgl. (The Open Group 2009c, S. 49-209)): x

Preliminary Phase: Beschreibt die Vorbereitung und Initiierung der Aktivitäten, die benötigt werden, um die neue Geschäftsarchitektur entsprechend der Geschäftsvorgabe auszurichten. Dies beinhaltet die Definition eines organisationsspezifischen Architektur-Frameworks und die Definition von Prinzipien.

x

Phase A (Architecture Vision): Beschreibt die Initialphase des Architecture Development Cycle. Sie beinhaltet Informationen über die Definition des Geltungsbereiches, die Identifizierung von Stakeholdern, die Erstellung der Architekturvision und die Einholung von Genehmigungen.

x

Phase B (Business Architecture): Beschreibt die Entwicklung der Geschäftsarchitektur zur Unterstützung der vereinbarten Architekturvision.

x

Phase C (Information Systems Architectures): Beschreibt die Entwicklung der Informationssystemarchitekturen im Rahmen von Architekturprojekten, einschließlich der Entwicklung von Daten- und Anwendungsarchitekturen.

x

Phase D (Technology Architecture): Beschreibt die Entwicklung der Technologiearchitektur im Rahmen eines Architekturprojektes.

x

Phase E (Opportunities & Solutions): Begleitet die Erstplanung der Realisierung und die Identifikation von Projekten, Programmen oder Portfolios, die einen Beitrag zum Erreichen der definierten Zielarchitektur leisten. Die Architekturen von Phase A bis D werden dabei für die Entwicklung einer Serie von sogenannten Übergangsarchitekturen verwendet, die den inkrementellen Fortschritt von der Baseline-Architektur zur Zielarchitektur zeigen.

x

Phase F (Migration Planning): Dient der Erarbeitung von Implementierungs- und Migrationsplänen, mit denen einige oder alle der identifizierten Übergangsarchitekturen aus Phase E realisiert werden können.

Architekturen A

x

333

Phase G (Implementatiion Governancee): Stellt Mögliichkeiten der Überwachung Ü inn Form vonn Governance- und u Managemen nt-Funktionen zur Verfügung. Sichert S die Kon-formität mit m der festgeleggten Architekturr bei Projektvorrhaben.

x

Phase H (Architecture Change C Manageement): Definierrt Vorgänge, mit denen die Än-ungen) im Rahm men der Architekkturentwicklungg derungenn (Geschäfts- unnd Systemänderu beobachttet und verwaltet werden könnenn.

x

Requirem ments Managem ment: Betrachtet den Prozess dees Architekturannforderungsma-nagemennts während der gesamten ADM M.

Abbildung A 11: TOGAF Architecturee Development Cyycle Quelle: Q (The Open G Group 2009c, S. 544)

Die D einzelne Beetrachtung der anderen a Teilkon nzepte, die zuvoor bei der Vorsttellung der TO-GAF-Struktur G geenannt wurden, würde über den n Rahmen der Arbeit A hinausgehhen. Insofern seii

34

Grundlagen und Begriffe

für eine detaillierte Beschreibung der Konzepte auf die bereits referenzierte TOGAFDokumentation (The Open Group 2009c) verwiesen. 2.3.4

Architekturmanagement im Rahmen des IM

Von den zahlreichen Aufgaben des Informationsmanagements steht im Rahmen dieser Arbeit das Architekturmanagement im Vordergrund, welches u.a. die zentralen Herausforderungen beim Management von Informationssystemen fokussiert. Nach Krcmar zählen dazu die Gestaltung der Daten und Prozesse von Informationssystemen, der Lebenszyklus einzelner Anwendungen sowie die Gestaltung der gesamten Systemlandschaft (Krcmar 2005, S. 103). Das Architekturmanagement ist eine Managementdisziplin und verantwortlich für die Planung, Entwicklung, Nutzung und Pflege der Architektur10 (Niemann 2005, S. 23). Müller definiert das Architekturmanagement im Bereich der Informationstechnologie wie folgt: „Das Management von IT-Architekturen umfasst alle Aspekte der Erstellung, Pflege, und des Einsatzes von IT-Architekturmodellen. Neben der technischen Umsetzung kümmert sich das ITArchitekturmanagement auch um die Etablierung geeigneter Organisationsstrukturen und Prozesse für die Durchführung des IT-Architekturmanagements im Unternehmen.“ (Müller et al. 2009, S. 225) Das allgemeine Ziel des IS-Architekturmanagements ist es, die klassischen Aufgaben des Informationsmanagements zu unterstützen (Schelp und Winter 2009, S. 258), um somit eine geeignete Informationsinfrastruktur zur wirtschaftlichen Erreichung der strategischen Unternehmensziele zu schaffen und aufrechtzuerhalten (Heinrich und Stelzer 2009, S. 39ff.). Das IS-Architekturmanagement verfolgt somit keine zusätzlichen Ziele, sondern versucht mit seinen untergeordneten Zielen (vgl. (Hafner und Winter 2005, S. 632; Hafner 2006, S. 90f.)), wie z.B. dem Erhalt der Flexibilität, Transparenz und Konsistenz, der Anforderungsintegration, der Situationsorientierung oder Standardisierung, die bestehenden Ziele zu unterstützen (Schelp und Winter 2009, S. 258; Hafner et al. 2004, S. 58). Durch die kontinuierliche Integration neuer technischer und fachlicher Herausforderungen leistet das IS-Architekturmanagement einen indirekten Beitrag, „um Kosten/Profitabilitäts-, Qualitäts-, Flexibilitätsund zeitliche Anforderungen des Unternehmens wie des allgemeinen Informationsmanagements zu erreichen.“ (Schelp und Winter 2009, S. 258)

10

Niemann bezieht sich in seinen Ausführungen konkret auf Unternehmensarchitekturen.

Computergestützte Visualisierung

35

Aus den Zielen des Architekturmanagements und den damit verbundenen Anforderungen11 ergeben sich verschiedene Aufgabenbereiche. Hafner und Winter (Hafner und Winter 2005, S. 643) unterscheiden folgende Aufgabenbereiche des Architekturmanagements12: x

Architekturführung: Ermittlung strategischer Anforderungen, Beurteilung bestehender Ist-/Soll- und Zielarchitekturen, Entwicklung von Architekturprinzipien und Messung der Architekturverbreitung und -effektivität.

x

Architekturentwicklung: Identifikation weiterer Anforderungen und Verwaltung der Anforderungen. Entwicklung, Integration und Verwaltung von Architekturartefakten.

x

Architekturkommunikation: Identifikation von Interessengruppen und Erfassung des Informationsbedarfs hinsichtlich der Architektur. Zielgruppengerechte Kommunikation relevanter Architekturartefakte.

x

Architekturvertretung: Beratung und Unterstützung von strategischen und operativen IT-Projekten in Architekturfragen.

Niemann führt an, dass das Architekturmanagement bezüglich der Aufgaben eine strategische und eine operative Dimension besitzt (Niemann 2005, S. 24). Das strategische Architekturmanagement umfasst die Dokumentation, Analyse und Planung der Architektur, das operative unterstützt die Umsetzung der strategischen Maßnahmen. 2.4

Computergestützte Visualisierung

Vor dem Hintergrund einer kontextspezifischen Erzeugung von Sichten auf serviceorientierte Architekturen nimmt die Visualisierung zur Darstellung unterschiedlicher Aspekte einer SOA eine wichtige Rolle ein. Aus diesem Grund wird zunächst auf das grundlegende Verständnis sowie auf das Ziel und den Zweck der Visualisierung eingegangen. Zudem werden die grundlegenden Anforderungen an die Visualisierung diskutiert. Anschließend wird die sogenannte Visualisierungspipeline beschrieben, die einen mehrstufigen Prozess zur Generierung von Darstellungen aus abstrakten Daten darstellt. Im Anschluss daran werden visuelle Variablen vorgestellt, die bei der Abbildung von Daten auf graphische Elemente zur Kodierung von Informationen verwendet werden können. Abschließend wird das Forschungsgebiet der Softwarevisualisierung näher betrachtet. 2.4.1

Grundlegendes Verständnis der Visualisierung

Die Visualisierung ist ein facettenreiches und vielfältiges Forschungsgebiet, das in vielen unterschiedlichen Wissenschafts- und Forschungsdisziplinen, wie z.B. der Astronomie, Meteo-

11 12

Für eine Aufstellung grundlegender Anforderungen an das Management der IS-Architektur vgl. (Hafner 2006, S. 91f.). Vgl. auch (Schelp und Winter 2009, S. 263f.)).

36

Grundlagen und Begriffe

rologie und Kartographie, der Medizin, der Psychologie, den Kognitions- und Kommunikationswissenschaften, den Ingenieurwissenschaften, der Informatik und der Architektur untersucht wird. Aus informationstechnischer Sicht definieren Card et al. (Card et al. 1999) den Begriff der Visualisierung wie folgt: „The use of computer-supported, interactive, visual representations of data to amplify cognition.“ (Card et al. 1999, S. 6) Unter Kognition verstehen Card et al. in diesem Zusammenhang die Aneignung und Verwendung von Wissen. Im Gegensatz zu seiner ursprünglichen Bedeutung, ein visuelles Bild im Gedächtnis zu erzeugen, drückt der Begriff der Visualisierung heute vielmehr die graphische Repräsentation von Daten oder Konzepten aus (Ware 2004, S. 2). Mit Verweis auf einen von McCormick, DeFanti und Brown erarbeiteten Bericht (McCormick et al. 1987), in dem die Aufgaben und Ziele der Visualisierung unter Zuhilfenahme von Computertechnik - gleichzeitig wird der Begriff des „Visualization of Scientific Computing“ geprägt - formuliert werden, messen Schumann und Müller (Schumann und Müller 2000) der Visualisierung nach wie vor zwei zentrale Aufgaben bei: „Sie soll zum einen Ergebnisse präsentieren und damit das Verständnis und die Kommunikation über die Daten und die zugrunde liegenden Modelle und Konzepte erleichtern. Zum anderen soll sie die Analyse der Daten unterstützen, indem die Bilder so aufgebaut werden, dass der Betrachter in der Lage ist, nicht nur zu sehen, sondern auch zu erkennen, zu verstehen und zu bewerten.“ (Schumann und Müller 2000, S. 2) Neben der wissenschaftlich-technischen Visualisierung (Scientific Visualization), die typischerweise Objekte oder Konzepte der physikalischen Welt repräsentieren, wird die Informationsvisualisierung (Information Visualization) als ein weiteres Teilgebiet der Visualisierung angesehen (Card et al. 1999, S. 6f.; Schumann und Müller 2000, S. 341; Teyseyre und Campo 2009, S. 88). Mit der Informationsvisualisierung wird die Anwendung von Visualisierungstechniken zur Repräsentation von abstrakten Daten, „die keinen physikalischen Bezugsrahmen vorgeben und somit häufig keinen Orts- oder Zeitbezug besitzen“ (Schumann und Müller 2000, S. 341), bezeichnet (Card et al. 1999, S. 6f.; Schumann und Müller 2000, S. 341). Dabei kann es sich bspw. um Finanzdaten, Geschäftsinformationen, Sammlungen von Dokumenten oder abstrakten Konzeptionen handeln (Card et al. 1999, S. 7). Card et al. erweitern ihre Definition des allgemeinen Visualisierungsbegriffs (s.o.) um den Aspekt abstrakter Daten und definieren die Informationsvisualisierung wie folgt: „The use of computer-supported, interactive, visual representations of abstract data to amplify cognition.” (Card et al. 1999, S. 7) Einsatz findet die Informationsvisualisierung in vielen unterschiedlichen Themengebieten, vor allem aber in Bereichen wie Information Retrieval, Data Mining, World Wide Web

Computergestützte Visualisierung

37

(WWW), elektronische Bibliotheken und Human-Computer Interaction (HCI) (Schumann und Müller 2000, S. 342; Chen 2004, S. 1). In der Regel wird dabei das Ziel verfolgt, innerhalb sehr großer abstrakter Datenmengen Strukturen zu erkennen, wobei sich die Ziele der Benutzer in Bezug auf diese Daten jedoch nicht einfach quantifizieren lassen (Keller und Tergan 2005, S. 7). 2.4.2

Ziel und Zweck der Visualisierung

Schumann und Müller sehen ein wesentliches Ziel der Visualisierung in der Erleichterung der Analyse, des Verständnisses und der Kommunikation von Modellen, Konzepten und Daten (Schumann und Müller 2000, S. 5). Zwar beziehen sie sich dabei auf die wissenschaftlichtechnische Visualisierung (Scientific Visualization), jedoch lässt sich die Zielsetzung in Bezug auf andere Bereiche der Visualisierung verallgemeinern und somit auch auf diese übertragen. Die Visualisierung wird zum einen zu Analysezwecken, zum anderen zu Präsentationszwecken eingesetzt (vgl. (Schumann und Müller 2000)). Bei der Analyse unterscheiden Schumann und Müller zwischen der explorativen und der konfirmativen Analyse. Die explorative Analyse erlaubt eine interaktive und ungerichtete Suche nach Informationen und Strukturen. Im Vorfeld der Suche existieren keine Hypothesen über die vorhandenen Daten, ihre Strukturen und Eigenschaften, so dass erst die Darstellung Hinweise zur Formulierung einer Hypothese gibt. Die konfirmative Analyse hingegen verfolgt das Ziel, aufgestellte Hypothesen mithilfe der Visualisierung zielgerichtet zu überprüfen und zu verifizieren. Nach der Analyse der Daten dient die Visualisierung der Präsentation und Kommunikation von Ergebnissen, wobei sich die dargestellten Fakten von anderen Anwendern ohne Probleme identifizieren und verstehen lassen müssen. Eine ähnliche Unterscheidung der Zweckmäßigkeit von Visualisierungen nehmen auch Chen et al. (Chen et al. 2008, S. 4f.) vor, indem sie „Präsentationsgraphiken“ („Presentation Graphics“) und „Untersuchungsgraphiken“ („Exploratory Graphics“) voneinander abgrenzen. Präsentationsgraphiken besitzen statischen Charakter und fassen die darzustellenden Informationen in einer einzelnen aussagekräftigen Graphik zusammen. Untersuchungsgraphiken hingegen dienen der Suche nach Ergebnissen und sollten daher schnell und informativ sein. 2.4.3

Anforderungen an die Visualisierung

Die Anforderungen an die Visualisierung sind von unterschiedlichen Einflussfaktoren, welche die Qualität einer Visualisierung bestimmen, abhängig. Zu diesen Einflussfaktoren zählen Schumann und Müller (Schumann und Müller 2000, S. 8f.) zufolge x

die Art und Struktur der Daten,

x

das Bearbeitungsziel bei der Visualisierung,

x

das Vorwissen des Anwenders/Betrachters,

38

Grundlagen und Begriffe

x

die visuellen Fähigkeiten und Vorlieben des Betrachters,

x

übliche Metaphern des Anwendungsgebietes/Konventionen,

x

die Charakteristika des Darstellungsmediums.

Hinsichtlich dieser Einflussfaktoren unterscheiden Schumann und Müller drei grundlegende Anforderungen, die eine Visualisierung erfüllen muss (vgl. im Folgenden (Schumann und Müller 2000, S. 9ff.)): Expressivität, Effektivität und Angemessenheit. Auch Mackinlay diskutiert Fragestellungen der graphischen Gestaltung von Visualisierungen auf Basis der Kriterien Expressivität und Effektivität (Mackinlay 1986). Die Expressivität oder auch Ausdrucksfähigkeit ist die Fähigkeit einer Visualisierung, die darzustellenden Daten möglichst unverfälscht zu repräsentieren. Abhängig von der Struktur und Art der Daten können unterschiedliche Visualisierungstechniken gewählt werden, die das Expressivitätskriterium als Grundvoraussetzung für die Erfüllung der Qualitätsanforderungen einer Visualisierung einhalten. Die Visualisierungstechnik, die in Bezug auf „die Fähigkeiten des Betrachters und die charakteristischen Eigenschaften des Ausgabegerätes unter Berücksichtigung der Zielsetzung und des Anwendungskontexts“ (Schumann und Müller 2000, S. 11) eine optimale Darstellungsalternative schafft, genügt dann dem Effektivitätskriterium. Die Angemessenheit einer Visualisierung bezieht sich letztendlich auf den Aufwand und die Kosten zur Durchführung des Visualisierungsprozesses, d.h. welcher Rechen- und Ressourcenaufwand für die Generierung einer Darstellung notwendig ist. Eine Visualisierung ist demnach angemessen, wenn die Aufwand-Nutzen-Relationen ökonomisch vertretbar sind. Insofern ist die effektivste Visualisierung nicht notwendigerweise auch die angemessenste. 2.4.4

Visualisierungspipeline

Um aus abstrakten Daten eine Darstellung generieren zu können, muss ein mehrstufiger Prozess durchlaufen werden, der als Visualisierungsprozess bzw. als Visualisierungspipeline bezeichnet wird (Ware 2004, S. 4f.; Schumann und Müller 2000, S. 15; Mackinlay 1986, S. 111). Dieser Prozess bzw. diese Pipeline beschreibt, ausgehend von den Rohdaten bis hin zur Bildgenerierung, die Abfolge aller für eine Visualisierung notwendigen Schritte. Die einzelnen Schritte einer solchen Pipeline sind in der Literatur nicht einheitlich festgelegt. Nach Schumann und Müller umfasst eine Visualisierungspipeline (siehe Abbildung 12) drei wesentliche Schritte (vgl. (Schumann und Müller 2000, S. 15ff.)): die Datenaufbereitung (Filtering), Datenabbildung (Mapping) und Bildgenerierung (Rendering). Diese werden im Folgenden exemplarisch vorgestellt.

Computergestützte Visualisierung

Daten

Filtering

39

Mapping

Rendering

Bild

Abbildung 12: Stufen einer Visualisierungspipeline Quelle: (Schumann und Müller 2000, S. 15)

Datenaufbereitung (Filtering): Den Ausgangspunkt für eine Visualisierung bilden die Rohdaten. Diese müssen für die weiteren Visualisierungsschritte aufbereitet werden, etwa durch die Strukturierung, die Vervollständigung oder Reduktion und das Filtern der Daten. Als Ergebnis dieses Schritts liegen dann die sogenannten aufbereiteten Daten vor (Schumann und Müller 2000, S. 15f.). Datenabbildung (Mapping): Im anschließenden zweiten Schritt der Visualisierungspipeline werden die zuvor aufbereiteten Daten auf geometrische Primitive und deren Attribute abgebildet (Daten-zu-Geometrie-Abbildung). Darüber hinaus werden die Primitive in Beziehung zueinander gesetzt. Die Durchführung dieses Schrittes hat wesentlichen Einfluss auf die Expressivität und Effektivität einer Darstellung (Schumann und Müller 2000, S. 16). Bildgenerierung (Rendering): Der dritte und letzte Schritt der Visualisierungspipeline realisiert eine Abbildung der Geometriedaten in Bilddaten. Die zuvor verarbeiteten Informationen werden dementsprechend durch visuelle Elemente repräsentiert. Die Form der Darstellung kann je nach Anwendungsfeld variieren. Das Ergebnis der Bildgenerierung wird als Bildausgabe auf einem Ausgabegerät angezeigt (Schumann und Müller 2000, S. 16f.). Um die im vorherigen Kapitel angeführten Anforderungen im Kontext der Visualisierungspipeline berücksichtigen zu können, führen Schumann und Müller in Anlehnung an Robertson und De Ferrari (Robertson und De Ferrari 1994) ein integriertes Referenzmodell für die Visualisierung (siehe Abbildung 13) ein, das den Nutzer der Visualisierung explizit berücksichtigt (Schumann und Müller 2000, S. 20ff.). Der Nutzer hat demnach die Möglichkeit, die einzelnen Schritte der Visualisierungspipeline zu kontrollieren und somit direkten Einfluss auf die Visualisierung und deren Expressivität und Effektivität zu nehmen.

40 4

Grunddlagen und Begriffee

Abbildung A 13: Inteegriertes Referenzzmodell für die Vissualisierung Quelle: Q (Schumann und Müller 2000, S. S 21)

2.4.5 2

Visuellle Variablen

Der D zweite Schrritt der Visualisiierungspipeline, das Mapping, stellt s mit der Wahl W von graphi-schen s Elementenn und Attributeen und der Ausswahl einer geeeigneten Darsteellungsform denn Kernprozess K derr Visualisierung dar (Schumannn und Müller 20000, S. 125). Warre unterscheidett zwei z grundlegennde Bestandteilee der Visualisieerung (Ware 2005, S. 29): visuuelle Strukturenn und u eine Menge von Symbolen. Strukturen kön nnen bspw. in Form F von Kartenn oder verschie-denen d Arten vonn Graphen darggestellt werden. Bei Symbolen kann es sich z.B. z um Wörter,, symbolische s Forrmen, Icons oderr Glyphen handeln. Im Rahmen der von Bertin (Beertin 1974; Bertiin 1982) entwicckelten graphiscchen Semiologiee werden w acht visuuelle Variablen identifiziert, diee bei der Abbilddung von Datenn auf graphischee Elemente E zur grraphischen Koddierung von Info formationen verw wendet werden können. Dabeii unterscheidet u Beertin zwischen Variablen des graphischen g Billdes und trenneenden Variablenn (Bertin 1982, S. 186f.). Zu den Variablen V des grraphischen Bildes zählen: x

x-Dimennsion der Ebene

x

y-Dimennsion der Ebene

x

Größe

x

Helligkeiitswert

Die D trennenden Variablen V für grraphische Bilderr sind: x

Muster

x

Farbe

x

Richtungg

x

Form

Computergestützte Visualisierung

41

Die Vorteile bezüglich der Variationsmöglichkeiten von visuellen Konstruktionen durch die Verwendung der Variablen beschreibt Bertin folgendermaßen: „Die unendlich große Vielfalt der graphischen Konstruktion ergibt sich dadurch, dass jede beliebige Komponente einer Information durch jede beliebige der acht visuellen Variablen transkribiert werden kann, wobei allerdings mindestens eine Dimension der Ebene ausgenutzt werden muss.“ (Bertin 1982, S. 186) Die visuellen Variablen definieren somit einen Satz atomarer Bausteine zur Konstruktion visueller Repräsentationen (Moody 2009, S. 761). Die visuellen Variablen beziehen sich auf statische zweidimensionale Darstellungen. Da insbesondere bei der computergestützten Visualisierung auch dynamische und dreidimensionale Darstellungen immer stärker in den Fokus gerückt sind, sollten die ursprünglichen Variablen um zusätzliche Variablen, wie z.B. die dritte Dimension, Perspektive oder Animation, ergänzt werden. Je nachdem, welche Charakteristika die darzustellenden Daten aufweisen, sollte vor der Abbildung auf graphische Elemente überprüft und festgelegt werden, welche Variablen sich für die Kodierung der Daten eignen, um somit die Anforderungen einer effektiven Visualisierung erfüllen zu können. 2.4.6

Softwarevisualisierung

Die Softwarevisualisierung als ein Teilgebiet der Informationsvisualisierung soll dazu beitragen, ein besseres Verständnis für Softwaresysteme durch deren graphische Repräsentation zu schaffen (Teyseyre und Campo 2009, S. 87f.; Graþanin et al. 2005, S. 221; Panas et al. 2003; Balzer et al. 2004, S. 261; Balzer und Deussen 2005, S. 1; Staples und Bieman 1998, S. 96). Sie wird zur Darstellung unterschiedlicher statischer oder dynamischer Aspekte (Struktur und Verhalten) sowie der Evolution von Software eingesetzt (Balzer et al. 2004, S. 261; Staples und Bieman 1998, S. 3; Diehl 2003, S. 257; Diehl 2007, S. 3f.). Der Fokus der Softwarevisualisierung liegt dabei weniger auf der Konstruktion von Software, sondern vielmehr auf der Analyse von Programmen und deren Entstehungsprozessen (Diehl 2003, S. 257). Visuelle Metaphern sollen diesbezüglich helfen, beim Betrachter mentale Bilder, sogenannte Mental Maps (Dwyer 2001, S. 2; Franck et al. 1995, S. 23; Koschke 2002, S. 148) bzw. mentale Modelle (Spence 2001; Petre et al. 1998, S. 473f.; Storey et al. 1997), zu erzeugen (Graþanin et al. 2005, S. 221; Diehl 2003, S. 257f.; Franck et al. 1995, S. 23; Misue et al. 1995, S. 186f.). Price et al. definieren den Begriff der Softwarevisualisierung wie folgt: „Software Visualization is the use of the crafts of typography, graphic design, animation, and cinematography with modern human-computer interaction and computer graphics technology to facilitate both the human understanding and effective use of computer software.“ (Price et al. 1998, S. 4) Eine weitere Definition liefern Knight und Munro und heben den Aspekt der Komplexitätsreduktion hervor: „Software visualisation is a discipline that makes use of various forms

42

Grundlagen und Begriffe

of imagery to provide insight and understanding and to reduce complexity of the existing software system under consideration.” (Knight und Munro 1999, S. 5) Die Softwarevisualisierung findet in unterschiedlichen Bereichen Anwendung. Dazu zählen bspw. die Animation von Algorithmen, das Software Engineering, Softwarearchitekturen, nebenläufige Programmausführung, statische und dynamische Visualisierung von objektorientiertem Code, Fehlerdiagnosen, Debugging und der Anforderungsanalyse (Graþanin et al. 2005). Umfassende Zusammenstellungen von Forschungsarbeiten, in denen je nach Anwendungsgebiet unterschiedliche visuelle Konzepte, Visualisierungstechniken, Verständnisstrategien und Werkzeuge entwickelt und untersucht wurden, liefern (Diehl 2007; Diehl 2002; Stasko et al. 1998; Zhang 2003). Bei der Softwarevisualisierung werden sowohl zweidimensionale als auch dreidimensionale Darstellungsformen verwendet. Im Bereich der Forschung wurden in den letzten Jahren viele dreidimensionale Visualisierungsansätze und Werkzeuge entwickelt und deren Vorteile gegenüber zweidimensionalen Ansätzen untersucht und diskutiert. Eine umfassende Übersicht über Ansätze, Techniken und Werkzeuge der 3-D-Softwarevisualisierung liefern Teyseyre und Campo (Teyseyre und Campo 2009). Dennoch sind bei der Modellierung bzw. der Visualisierung von Softwaresystemen nach wie vor zweidimensionale Darstellungen vorherrschend. So werden bspw. in der Architekturentwicklung Modelle in Form von zweidimensionalen Diagrammen entworfen. Der wohl bekannteste und am weitesten verbreitete Ansatz ist die Unified Modeling Language (UML) (Balzer et al. 2004, S. 262). Eine starke Verbreitung und eine hohe Akzeptanz sind die wesentlichen Vorteile der UML (Dwyer 2001, S. 77). Die UML (OMG 2009) beinhaltet eine Sammlung zweidimensionaler Diagramme, die für die Modellierung und Visualisierung von Softwaresystemen verwendet werden können. Durch die Vielzahl der verschiedenen Diagramme können alle Aspekte und damit das gesamte darzustellende System abgedeckt werden (Dwyer 2001, S. 77). Allerdings ist die UML, wie auch andere zweidimensionale Ansätze, nur bedingt zur Visualisierung großer Softwarestrukturen geeignet (Balzer et al. 2004, S. 262; Dwyer 2001, S. 77). Dies hat mit generellen Problemen der Visualisierung zu tun, auf die nachfolgend eingegangen wird. Mit der Größe eines Softwaresystems wachsen auch der Umfang und die Komplexität der zugehörigen visuellen Darstellungen. Mit deren zunehmender Größe ist vor allen Dingen das Layout der Darstellungen immer schwieriger adäquat zu gestalten, weil immer mehr Elemente und deren Beziehungen mit einbezogen werden müssen (Staples und Bieman 1998, S. 114; Dwyer 2001, S. 77; Ware et al. 1993, S. 612). Dieses zentrale Problem ergibt sich hauptsächlich aus der Zweidimensionalität der Darstellung vieler Ansätze. Vor allem hierarchische und geschichtete Strukturen, wie sie bei Softwaresystemen häufig zu finden sind, beanspruchen in 2-D-Darstellungen sehr viel Platz (Dwyer 2001, S. 77). Außerdem kommt es bei einer Vielzahl von Elementen in der Regel zu Überschneidungen von Relationen. Darüber hinaus exis-

Computergestützte Visualisierung

43

tieren mehrere Modelle bzw. Darstellungen eines Softwaresystems auf unterschiedlichen Abstraktionsebenen, wodurch sich die Details größerer Systeme zwar relativ gut darstellen lassen, der Gesamtkontext (Big Picture) allerdings verloren geht und möglicherweise nicht alle relevanten Elemente auf einmal darstellbar sind (Staples und Bieman 1998, S. 114). Infolgedessen sehen Gil und Kent die mangelnde Verknüpfung der verschiedenen Darstellungen/Diagramme und den damit verbundenen Verlust der Gesamtsemantik als einen der größten Schwachpunkte von Modellierungssprachen wie UML (Gil und Kent 1998, S. 106). Ein weiteres Problem besteht darin, dass die hohe Anzahl der Elemente ab einem gewissen Grad die Menge der vom Benutzer verarbeitbaren Informationen übersteigt und es somit zum sogenannten Information Overload (Informationsüberladung) kommt (Graþanin et al. 2005; Staples und Bieman 1998, S. 114). Ein Information Overload ist die Folge mangelnder Skalierbarkeit, wie sie bei vielen existierenden Ansätzen und Werkzeugen zu finden ist (Staples und Bieman 1998, S. 114; Marcus et al. 2003, S. 27). Skalierbarkeit kann in diesem Zusammenhang als die Fähigkeit verstanden werden, Softwaresysteme unterschiedlicher Größe gleichermaßen gut darstellen zu können. Zur Vermeidung eines Information Overload existieren grundsätzlich zwei Möglichkeiten. Die erste Möglichkeit besteht darin, eine Gesamtsicht des Systems zu erstellen. In diesem Fall muss aber, sobald die Anzahl der Elemente des Softwaresystems steigt, die Anzahl der einzelnen Elemente verringert oder müssen Elemente zusammengefasst werden. Dies ist jedoch mit einem Verlust von Semantik verbunden (Staples und Bieman 1998, S. 114). Bei der zweiten Möglichkeit wird lediglich ein Ausschnitt des Systems visualisiert und damit die Anzahl der Elemente verringert, die gleichzeitig dargestellt werden. Der Nachteil hierbei besteht darin, dass der Kontext des betrachteten Ausschnittes durch die Fokussierung verloren geht. Durch den Einsatz dreidimensionaler Darstellungen wird versucht, den Einschränkungen zweidimensionaler Darstellungen entgegenzuwirken. So sieht bspw. Stasko Bedarf in einer zusätzlichen räumlichen Dimension und führt an: „By adding an extra spatial dimension, we supply visualization designers with one more possibility for describing some aspect of a program or system.“ (Stasko 1992, S. 4) Bezüglich der Wirksamkeit dreidimensionaler Darstellungen stellt Dwyer mit Verweis auf die Ergebnisse wissenschaftlicher Studien fest, dass sie das Verständnis besser fördern als 2-D-Darstellungen (Dwyer 2001, S. 78), auch wenn nicht alle empirischen Untersuchungen in diesem Punkt identische Ergebnisse zeigen (Balzer et al. 2004, S. 2). Teyseyre und Campo zählen, ebenfalls mit Verweis auf wissenschaftliche Studien und Experimente, die größere Informationsdichte, eine bessere Interpretierbarkeit großer Graphenstrukturen, eine natürlichere Darstellung assoziierter realer Konzepte, eine klarere Wahrnehmung von Substrukturen und Beziehungen sowie die Komposition mehrerer 2-DDarstellungen zu einer 3-D-Darstellung zu den Vorteilen dreidimensionaler Darstellungen (Teyseyre und Campo 2009, S. 89).

44

Grundlagen und Begriffe

Als Nachteile dreidimensionaler Darstellungen gelten vor allem der erhöhte Rechenaufwand, die komplexere Implementierung sowie Orientierungsprobleme und Schwierigkeiten bei der Adaptierung durch den Benutzer (Teyseyre und Campo 2009, S. 89f.). Vielen Benutzern fehlen die entsprechenden Erfahrungswerte im Umgang mit 3-D-Darstellungen, so dass zusätzliche Interaktionsmöglichkeiten und mehr Freiheitsgrade zu Orientierungsproblemen als auch zu Schwierigkeiten bei der Navigation führen. Darüber hinaus kann das Auftreten von Verdeckungen zu Wahrnehmungsproblemen bei den Benutzern führen. Tabelle 2 fasst die Stärken und Schwächen dreidimensionaler Darstellungen zusammen. Mit der Entwicklung moderner Hardware und neuer Techniken findet die 3-D-Graphik in Visualisierungsansätzen und -werkzeugen zunehmend Anwendung (Teyseyre und Campo 2009, S. 87). Ein prominentes Beispiel einer Visualisierungstechnik zur Darstellung hierarchischer Informationen in 3-D ist der am Xerox PARC entwickelte Cone Tree-Ansatz von Robertson et al. (Robertson et al. 1991), mit der bis zu 1000 Knoten auf zehn Ebenen und einem Verzweigungsfaktor von 10 ohne das Auftreten von Störeffekten angezeigt werden können. Stärken

Schwächen

x

Höhere Informationsdichte

x

Hoher Rechenaufwand

x

Integration lokaler und globaler Sichten

x

Komplexere Implementierung

x

Komposition mehrerer 2-D-Sichten in einer 3-DSicht

x

Adaptierfähigkeit der Benutzer in Bezug auf 3-D-Metaphern und speziellen Geräten

x

Unterstützt die Wahrnehmung des menschlichen visuellen Systems

x

x

Vertrautheit, Realismus und wirklichkeitsgetreue Darstellungen

Schwierigkeiten der Benutzer den dreidimensionalen Raum zu verstehen und darin zu interagieren

x

Verdeckungen

Tabelle 2: 3-D Stärken und Schwächen Quelle: (Teyseyre und Campo 2009, S. 90)

Andere Ansätze, sowohl abstrakter visueller Repräsentationen, wie Graphen, Bäume oder geometrische Formen, als auch wirklichkeitsbezogener Repräsentationen (real-world Metaphor), sind bspw. Geons (Irani und Ware 2003), Vizz3D (Panas et al. 2005), Hierarchical Net 3D (Balzer et al. 2004), sv3D (Marcus et al. 2003; Maletic et al. 2003), rube Framework (Hopkins und Fishwick 2002), Bloom Visualization System (Reiss und Renieris 2003) oder CodeCity (Wettel und Lanza 2007). Abbildung 14(a) und Abbildung 14(b) zeigen exemplarisch den Cone Tree- und den CodeCity-Ansatz.

Verwandte V Arbeitenn

455

Abbildung A 14: Visu ualisierungsansätzze (a) Cone Tree und u (b) CodeCity Quelle: Q (Robertson et al. 1991) und (W Wettel und Lanza 20007)

2.5 2

Verwan ndte Arbeiten

Gegenstand G diesses Kapitels sinnd verwandte Arbeiten A unterschhiedlicher Forscchungsbereiche,, die d bestimmte Aspekte A der in dieser Arbeit aufgestellten a Forschungsfragen behandeln undd somit s Anknüpfunngspunkte lieferrn können. Im Bereich der Software- und Enterprise E Arch hitekturen liegt der d Fokus verw wandter Arbeitenn auf a dem Archittekturmanagemeent und der Arrchitekturentwiccklung. Verschiiedene Arbeitenn (Winter und Fisccher 2006; Egyeed 1999; Murphhy et al. 2001; Medvidovic M et all. 2003; Steen ett al. a 2004; Frank 1995b) betrachtten in diesem Zusammenhang Z insbesondere Aspekte A der Mo-dellierung, d die m mit Fragestellunngen bezüglich der Konsistenzz von Architektuursichten sowiee deren d Integratioon verbunden siind. Andere Arrbeiten (Kazmann und Carriere 1998; Lei undd Medvidovic M 20001; Koschke 20000; van Deursenn et al. 2004) hinngegen legen deen Schwerpunktt im m Bereich des Reengineeringss und der Arch hitektur Recoverry auf die Rekoonstruktion undd Extraktion E von Architektursichhten, um ein bessseres Verständdnis über die Architektur A einess Systems S zu erlanngen. Im Bereich der Software- und Systemvisualisiierung fokussierren verwandte Arbeiten A vor al-lem die automattische Generieruung von Visualiisierungen, die zu z einem besserren Verständniss und u einer besserren Darstellung von Informatioonen über softwareintensive Systeme beitragenn sollen. s Im Rahm men solcher Forrschungsarbeiten n werden häufiig entsprechendde Analyse- undd Visualisierungsw V werkzeuge implementiert. Beisp piele für verwaandte Arbeiten aus a diesem For-schungsbereich s s sind das Bauhauus-Projekt (Koschke 2002), die Dali Workbencch (Kazman undd Carriere C 1998), das Generic Sof oftware Exploration Environmeent (GSEE)(Favree 2001), die Ar--

46

Grundlagen und Begriffe 13

chitecture-Based Analysis of CompUter Systems (ABACUS ) (Denford et al. 2002), der Sotograph14 (Bischofberger et al. 2004) und die Software- und Systemkartographie bzw. das SyCaTool (Buckl et al. 2007; Wittenburg 2007; Matthes 2008). Ansätze, die zur Darstellung von Softwarestrukturen und -architekturen 3-D-Visualisierungen untersuchen und verwenden, sind bspw. Vizz3D (Panas et al. 2005), Software Landscapes (Balzer et al. 2004), das rube Framework (Hopkins und Fishwick 2002) oder CodeCity (Wettel und Lanza 2007). Im Folgenden werden zwei der zuvor genannten Ansätze näher vorgestellt: Das BauhausProjekt und das Projekt Software- und Systemkartographie. Zwar beziehen sich die Forschungsprojekte nicht auf den Bereich serviceorientierter Architekturen, sie verfolgen aber dennoch ähnliche Forschungsziele. 2.5.1

Bauhaus-Projekt

Im Rahmen des Bauhaus Projektes werden Reverse Engineering-Techniken erforscht, die der Unterstützung des Programm-Verstehens von Legacy Code dienen. Bauhaus unterstützt sowohl Maintenance-Aufgaben, die ein Programm-Verstehen „im Kleinen“ erfordern, als auch Reengineering-Aufgaben, die Wissen über die gesamte Architektur eines Systems verlangen und somit mehr an das Programm-Verstehen „im Großen“ gerichtet sind (Koschke 2002, S. 139). Bei der Analyse von Systemen werden drei unterschiedliche Abstraktionsebenen betrachtet (Koschke 2002, S. 139). Beim sogenannten Lower Level wird der Quellcode mit allen notwendigen Details syntaktischer und semantischer Informationen sowie von Kontroll- und Datenflussinformationen dargestellt. Der Middle Level hingegen enthält nur globale Informationen, wie z.B. globale Variablen, Funktionen, benutzerdefinierte Typen und deren Beziehungen, die vom Quellcode extrahiert werden können. Der Architectural Level enthält Informationen über die Architektur. Neben der Analyse von Quellcode liegt der Fokus von Bauhaus auf der Wiederherstellung von Architekturbeschreibungen (Koschke 2002, S. 139ff.). Dabei wird sich an den Terminologien und den Konzepten des ISO/IEC 42010 IEEE Std 1471-2000-Standards (ISO/IEC und IEEE 2007) (siehe Kapitel 5.1) orientiert. Die Architektur-Recovery mit Bauhaus ist ein halbautomatischer Prozess. Einerseits wird auf Analyseergebnisse tieferer Abstraktionsebenen (Lower Level und Middle Level) zurückgegriffen. Die Analyseergebnisse werden durch die Extraktion von Informationen aus dem Quellcode vollautomatisch in Form von Links auf den

13 14

Siehe auch http://www.avolution.com.au/products.html Siehe auch http://www.hello2morrow.com/products/sotograph

Verwandte Arbeiten

47

ursprünglichen Quellcode und eines Ressourcengraphen geliefert. Andererseits werden diese Ergebnisse durch Benutzerinteraktionen um konzeptionelle Informationen angereichert. Ein Schwerpunkt der Architektur-Recovery in Bauhaus ist die Identifikation wiederverwendbarer Komponenten. Dabei wird sich an drei Viewpoints (siehe Kapitel 5.1) orientiert, die in Abbildung 15 dargestellt werden. Base Viewpoint:

parameter of type Physical Module Viewpoint: call *

*

*

return type

*

local object of type

Subprogram *

*

0 .. 1

* * references

part type *

part of

Type * of type

*

*

*

1

*

Module

*

Primitive *

*

0..1

enclosing Conceptual Component Viewpoint:

Record Component same expression actual parameter of references

*

enclosing * * 1

{OR}* part of of type

*

Object * *

*

part of

Component *

Primitive *

*

Abbildung 15: Viewpoints bei der Architektur-Recovery in Bauhaus Quelle: (Koschke 2002, S. 141)

Sichten, die dem Base Viewpoint entsprechen, können direkt aus dem Quellcode extrahiert werden und dienen als Input für weitere Analysen. Auf Basis dieser Analysen werden wiederum Sichten erstellt, die dem Physical Module oder Conceptual Viewpoint entsprechen. Die Identifikation von Komponenten unterliegt einem iterativen und halb-automatischen Prozess (siehe Abbildung 16), der aus den folgenden vier Schritten besteht (Koschke 2002, S. 142f.; Koschke 2000, S. 315ff.): 1. Im ersten Schritt wählt ein Benutzer verschiedene Analysetechniken, die vollautomatisch ausgeführt werden. 2. Im zweiten Schritt verwenden die ausgewählten Analysetechniken die Base View mit den bereits extrahierten Programminformationen als Input. Als zusätzlicher Input dient die sogenannte User View, die bereits identifizierte Komponenten beinhaltet. Im ersten Iterationsschritt enthält die User View noch keine Informationen. 3. Mithilfe der unterschiedlichen Analyseanwendungen werden Component Views erzeugt, die im dritten Schritt auf Basis bestimmter Metriken, wie der Anzahl von Elementen, Kohäsion, etc., bewertet werden können. Die verschiedenen Component Views können zudem auf unterschiedliche Art und Weise miteinander kombiniert werden.

48

Grundlagen und Begriffe

4. Die kombinierten Component Views werden im vierten Schritt von dem Benutzer validiert. Dabei kann der Benutzer Komponenten in Teilen oder als Ganzes verwerfen oder aber zusätzliche Entitäten zu existierenden Komponenten hinzufügen. Komponenten, die vom Benutzer akzeptiert werden, werden Teil der User View. Durch den inkrementellen Einsatz von Analysen werden in jedem Iterationsschritt erneut Analysetechniken ausgewählt und miteinander kombiniert, um weitere Komponenten zu finden. Wenn in Bezug auf eine konkrete Fragestellung ausreichend Komponenten gefunden wurden oder aber keine weiteren Komponenten mehr identifiziert werden können, endet der Prozess. C source code

extraction

analysis selection

base view

analysis application

view 1

view 2

metric assessment

analyses

user view

view n

view combination

view

validation

Abbildung 16: Prozess der Komponenten-Recovery in Bauhaus Quelle: (Koschke 2002, S. 144)

Die Softwarevisualisierung spielt im Rahmen dieses iterativen halb-automatischen Prozesses eine wichtige Rolle, da sie die Benutzerinteraktion bei der Erfassung von Komponenten unterstützt (Koschke 2002, S. 143ff.). Der Benutzer muss im Rahmen der Architektur-Recovery in der Lage sein, die dargestellten Informationen schnell zu erfassen und gleichzeitig zu bewerten, welche zusätzlichen Informationen notwendig sind, die durch die bereits durchgeführten Analysen noch nicht berücksichtigt wurden (Koschke 2002, S. 143ff.). Bauhaus stellt un-

Verwandte V Arbeitenn

499

terschiedliche V Visualisierungsm möglichkeiten zuur Verfügung, diie je nach Aufgabe und Art derr Analyse A eingeseetzt werden könnnen. Abbildung g 17 zeigt eine Visualisierung, V die zur Darstel-lu ung der Ergebniisse eines hierarrchischen Clusteering verwendett wird und den Benutzer B bei derr Validierung V unteerstützt.

Abbildung A 17: Visu ualisierung zur Un nterstützung der Architektur-Recov A very in Bauhaus Quelle: Q (Institute foor Software Technology, University off Stuttgart 2006)

2.5.2 2

Softwaare- und Systemkkartographie

Die D Software- und Systemkarrtographie ist ein e Forschungspprojekt der Forschungsgruppee Software S Engineeering betriebliccher Information nssysteme (sebiss) an der Techniischen Universi-tät München15. Z Ziel der Softwarre- und Systemkkartographie ist es, e mithilfe versschiedener Sich-ten und Betrachhtungsebenen koomplexe System me darzustellen und damit die langfristige l Ge-staltung s und Beewertung von Anwendungslan A ndschaften zu unterstützen u undd zu verbessernn (Lankes et al. 20005, S. 1444; Laankes et al. 2007 7, S. 115). 15

Siehe http://www wmatthes.in.tum.de//wikis/sebis/syca

50 5

Grunddlagen und Begriffee

Durch D drei grunndlegende Betraachtungsebenen der Software- und u Systemkarttographie (siehee Abbildung A 18) ssoll im Rahmenn des Enterprisee Architecture Management M einne ganzheitlichee Sicht S auf die Annwendungslandsschaft eines Un nternehmens erm möglicht werdenn (Lankes et al.. 2005, 2 S. 1445ff.; Lankes et al. 2007, 2 S. 115ff.). Die D oberste Betrrachtungsebene (Warum?) berüücksichtigt die Unternehmensz U iele, Strategien,, gesetzliche g Regeelungen und Geeschäftsregeln, bei b denen sich durch d Änderunggen Auswirkun-gen g auf die Anw wendungslandschhaft ergeben kön nnen. Die mittleere Ebene (Was??) betrachtet diee Geschäftsprozes G se und Geschääftsobjekte einess Unternehmenss, bei denen siich Änderungenn direkt d auf die unnterstützenden Systeme S der Annwendungslandsschaft auswirkenn. Die Realisie-rung r und Untersstützung der Geeschäftsprozessee und Geschäftsoobjekte durch Innformationssys-teme sind Gegenstand der unteersten Ebene (W Wie?), auf der unterschiedliche u e Technologien,, Softwarearchitek S kturen und Schnnittstellen zwischen den Anwenndungssystemenn betrachtet wer-den. d

Abbildung A 18: Betrachtungsebenen der Software- und d Systemkartograp phie Quelle: Q In Anlehnunng an (Lankes et al. 2005, S. 1446)

Für F die graphiscche Repräsentatiion von Informaationen bezüglicch der drei Betrachtungsebenenn werden w bei der Software- undd Systemkartogrraphie sogenannnte Softwarekaarten verwendett (Buckl et al. 20007; Wittenburg 2007; Matthes 2008; Lankes et al. 2005; Lankkes et al. 2007)..

Verwandte Arbeiten

51

Dabei wird sich an Techniken und Gestaltungsmitteln der Kartographie orientiert. Wittenburg definiert den Begriff der Softwarekarte folgendermaßen: „Eine Softwarekarte (Software Map) ist eine graphische Repräsentation der Anwendungslandschaft oder von Ausschnitten dieser. Eine Softwarekarte setzt sich zusammen aus einem Kartengrund und den auf dem Kartengrund aufbauenden Schichten, die verschiedene Merkmale visualisieren.“ (Wittenburg 2007, S. 56) Mithilfe des Kartengrunds wird die Verortung von Elementen vorgenommen. Dazu werden bestimmte Merkmale von Informationssystemen als Dimensionen ausgewählt und zur Bildung des Kartengrunds verwendet (Lankes et al. 2005, S. 1450). Mit den auf dem Kartengrund aufbauenden Schichten können Informationen gefiltert und die Informationsdichte gesteuert werden (Wittenburg 2007, S. 83f.; Matthes 2008, S. 532f.).

SoCaStore Hosting Map

Munich

Creation Date: 2006-12-31 Contact: EA-Group Hamburg

Garching

London

Online Shop (100)

Human Resources System (700)

POS System (Germany/Munich) (1600)

Product Shipment System (Germany) (400)

POS System (Germany/ Hamburg) (1620)

Inventory Control System (200)

Monetary Transactions System (Great Britain) (350)

Customer Complaint System (1900)

Monetary Transactions System (Germany) (300)

Business Traveling System (1000)

Worktime Management (Germany/Munich) (1800)

Fleet Management System (900)

Price Tag Printing System (Germany/ Hamburg) (1720)

Data Warehouse (800)

POS System (Great Britain) (1650)

Customer Satisfaction Analysis System (2000)

Accounting System (500)

MIS (1300)

Price Tag Printing System (Germany/ Munich) (1700)

Document Management System (1100)

Worktime Management (Germany/ Hamburg) (1820)

Supplier Relationship Management System (1200)

Price Tag Printing System (Great Britain) (1750)

Costing System (600)

Financial Planning System (1400)

Campaign Management System (1500)

Customer Relationship Management System (2100)

Worktime Management (Great Britain) (1850)

Legend Map Symbols & Visual Variables A B (1)

Location A Business Application B with Id 1

Visualization Rules A B (1)

„A“ hosts „B (1)“

nesting

Abbildung 19: Beispiel einer Clusterkarte mit Standorten und betriebenen Anwendungssystemen Quelle: (Wittenburg 2007, S. 89)

Der Kartengrund kann je nach Kartentyp variieren. Ein Kartentyp definiert dabei den Aufbau einer Softwarekarte (Lankes et al. 2007, S. 128). Bezüglich des Aufbaus einer Softwarekarte existieren Kartentypen, bei denen die Verortung von Elementen auf dem Kartengrund einer festgelegten Semantik entspricht und Kartentypen, die einen Kartengrund ohne Verortung besitzen (Lankes et al. 2007, S. 129). Als Typen von Softwarekarten mit einer Verortung auf dem Kartengrund lassen sich Clusterkarten, kartesische Karten und Graphlayout-Karten unterscheiden (Matthes 2008, S. 529). Abbildung 19 zeigt ein Beispiel einer Clusterkarte mit Standorten und den dort betriebenen Anwendungssystemen. Neben der Erarbeitung theoretischer Konzepte bildet die automatische Generierung von Softwarekarten einen Schwerpunkt im Rahmen des Forschungsbereichs der Software- und Sys-

52 5

Grunddlagen und Begriffee

temkartographie. Die automatissche Generierunng von Softwareekarten basiert auf einer Tren-nung n zwischen den visualisiertten Inhalten und d der Visualisieerung einer Sofftwarekarte. Zurr Überführung Ü sem mantischer Inhaalte in die Symbbolik einer Softtwarekarte wird der Ansatz derr Modelltransform M mation (Buckl ett al. 2007, S. 4ff.; 4 Wittenburg 2007, S. 130fff.; Lankes et al.. 2007, 2 S. 131f.) verwendet, beii dem mithilfe von Transform mationsvorschriftten semantischee Modelle M in sym mbolische Modellle transformierrt werden (siehee Abbildung 200). Symbolischee Modelle M sind daabei Instanzen eiines Visualisierungsmodells, mit m dem die Konnzepte von Soft-warekarten w abgeebildet werden. Semantische Modelle hingegenn basieren auf eiinem Informati-onsmodell, o mit ddem Klassen vonn Elementen, deeren Eigenschaft ften und Beziehuungen festgelegtt werden. w Im Traansformationsmodell werden auf a Ebene des Informations- und Visualisie-rungsmodells r diie Transformatioonsvorschriften definiert. Einee gemeinsame Sprache S für dass Informationsmoddell und das Visualisierungsm V modell bildet das d Metamodell, wodurch diee Transformation T vvereinfacht wirdd.

Abbildung A 20: Gen nerierung von Visualisierungen unter Verwendung voon Modelltransforrmationen Quelle: Q (Wittenburgg 2007, S. 132)

Im Rahmen dess Forschungsproojekts SyCaToool16 (zuvor SoC CaTool) wurde ein Repository-gestütztes g Werkzzeug entwickeltt, mit dem für Modelle M einer Annwendungslandsschaft Software-karten k erzeugt w werden können (Buckl et al. 200 07, S. 7ff.; Witteenburg 2007, S. 173ff.; Matthess 17 2008, 2 S. 534f.). Das Werkzeug wurde auf Basis der Eclipse Plattform P , dem m Eclipse Mode-18 19 ling Framework (EMF) und deem Graphical Ed ditor Toolkit (G GET) implemenntiert. Den Kernn des d Werkzeugs bbilden eine Repoository-, eine Trransformer-, einne Layouter- undd eine Renderer--

16 17 18 19

Siehe http://www wmatthes.in.tum.de//wikis/sebis/sycato ool Siehe http://www w.eclipse.org Siehe http://www w.eclipse.org/modelling/emf/ Siehe http://www w.eclipse.org/gef/

Verwandte V Arbeitenn

533

Komponente. K A Abbildung 21 zeeigt einen Screeenshot der Benuutzeroberfläche des SyCaTool-Werkzeugs. W

Baumansichtt des semantischen Modells M

Diagrammfläche zur z Daarstellung von Softw wareund Systemkarten n

Navigationssbereich

Eigenschateen des ausgewäh hlten Elements

Abbildung A 21: Screenshot des SyCaT Tool-Werkzeugs Quelle: Q (Software E Engineering betrieblicher Informationsssysteme (sebis), Technischen Univerrsität München 2010) 2

2.5.3 2

Zusam mmenfassung derr vorgestellten Ansätze A

Wie W bereits erw wähnt, werden inn den verschied denen Arbeiten und Ansätzen unterschiedliche u e Teilaspekte T in B Bezug auf die inn dieser Arbeit formulierten Foorschungsfragenn behandelt. Diee Ergebnisse E dieseer Arbeiten traggen zur Beantwo ortung bestimmtter Fragestellunggen bei, die dass Konzept K der Arcchitektursichten, die Analyse voon Architekturen oder deren Viisualisierung im m Kontext K softwareeintensiver Systteme betreffen. Die D beiden vorggestellten Projekkte greifen in Bezug B auf ihre Forschungsziele F mehrere dieserr Aspekte A auf undd wurden daherr näher beschrieeben. Mit Blickk auf das Forschhungsziel dieserr Arbeit A werden eiinige Aspekte jeedoch gar nicht oder o nur unzureeichend bzw. mitt einem anderenn Fokus F betrachtett. Ein wesentlichher Unterschied besteht darin, dass d der Fokus dieser d Arbeit auff

54

Grundlagen und Begriffe

die Erzeugung von Architektursichten im Kontext serviceorientierter Architekturen gerichtet ist und somit die dort herrschenden Rahmenbedingungen berücksichtigt werden müssen. Ein vergleichbarer Ansatz im Bereich serviceorientierter Architekturen ist bislang nicht vorzufinden. Durch den Fokus auf das Reengineering und die Architektur-Recovery im Rahmen von Wartungsprozessen werden mit dem Bauhaus-Projekt lediglich spezifische Rollen (Maintainer, Auditoren) adressiert, so dass in erster Linie die Concerns und Kontexte von Stakeholdern dieser Zielgruppen berücksichtigt werden. Eine phasenübergreifende Anwendung im Rahmen von Management- und Entwicklungsprozessen, die eine weitaus größere Menge an Stakeholdern berücksichtigen müsste, wird mit diesem Ansatz nicht verfolgt. Darüber hinaus dienen Quellcode-Artefakte als primäre Input-Ressourcen zur Durchführung von Analysen. Der in dieser Arbeit verfolgte Ansatz greift für Analysen zur Sichtengenerierung auf ein zentrales Repository zu, über das Daten und Metadaten aus unterschiedlichen Artefakten aggregiert und verwaltet werden können. Im Rahmen der Software- und Systemkartographie wird durch den Fokus auf Enterprise Architekturen ein weit reichender Anwendungsbereich betrachtet und somit eine breitere Zielgruppe beteiligter Stakeholder berücksichtigt. Eine Abbildung der zahlreichen unterschiedlichen Stakeholder-Concerns wird jedoch nicht explizit in den Ansatz der Modelltransformation zur Visualisierung von Anwendungslandschaften aufgenommen. Des Weiteren liegt der Schwerpunkt auf der Visualisierung in Form von Softwarekarten, so dass die Darstellungsmöglichkeiten durch die Einhaltung spezifischer Gestaltungsregeln einem vorgegebenen Gestaltungsrahmen unterliegen. Der in dieser Arbeit verfolgte Ansatz hingegen abstrahiert von einer konkreten Darstellungsform bei der Visualisierung. Zwar wird der Fokus auf die Verwendung dreidimensionaler Darstellungen gerichtet, die Entscheidung, welche Art der Darstellungsform zur Visualisierung serviceorientierter Architekturen eingesetzt wird und welchen Gestaltungsregeln diese unterliegt, wird jedoch offen gehalten.

3

Serviceorientierte Architekturen

In den folgenden Kapiteln wird in die Thematik der Serviceorientierung (SO) und serviceorientierter Architekturen (SOA) eingeführt. Zunächst wird ein Überblick über die Grundlagen serviceorientierter Architekturen gegeben (Kapitel 3.1). Dieser umfasst neben der Darstellung von Vorteilen einer SOA, die Auseinandersetzung mit unterschiedlichen SOA-Definitionen, die Betrachtung von SOA-Prinzipien und -Erfolgsfaktoren sowie die Diskussion über Zusammenhänge zwischen Unternehmens- und serviceorientierten Architekturen. Anschließend wird der Fokus auf drei Themenfelder gerichtet, die die Basis für die folgenden Grundvoraussetzungen bei der Entwicklung des Konzepts bilden: x

Einheitliches Verständnis der Bestandteile und Ebenen serviceorientierter Architekturen (Kapitel 3.2).

x

Möglichkeiten der Steuerung des Informationsmanagements, der Informationsversorgung und Informationserfassung zur Deckung des Informationsbedarfs von Stakeholdern im Rahmen einer SOA-Governance (Kapitel 3.3).

x

Möglichkeiten der Identifikation von Informationsbedarfen von Stakeholdern auf Basis von Rollenbeschreibungen (Kapitel 3.4).

3.1

Grundlagen serviceorientierter Architekturen

Zu den Eigenschaften, die eine moderne Enterprise Softwarearchitektur aufbringen muss, um die Agilität und Effizienz zu verbessern, zählen Einfachheit, Flexibilität und Wartbarkeit, Wiederverwendbarkeit und die Entkopplung von Funktionalität und Technologie (Krafzig et al. 2007, S. 27f.). Die serviceorientierte Architektur ist ein Architekturparadigma, das sowohl im Bereich der Informationstechnologie als auch in der Geschäftswelt signifikante Beachtung erfahren hat (Estefan et al. 2009, S. 9). Der Nutzen einer SOA wird vor allem in der Erhöhung der Agilität und der Senkung von Kosten gesehen (BITKOM 2009, S. 12f.). Voraussetzung für die Erhöhung der Agilität sind bspw. flexiblere Kombinationsmöglichkeiten von Softwarebausteinen zur Unterstützung von Geschäftsprozessen. Des Weiteren können durch neue wettbewerbsfähigere und dynamische Geschäftsmodelle eine schnellere Time-to-Market erreicht werden, ohne sich dabei zu stark auf einzelne Anbieter beschränken zu müssen. Einfluss auf eine höhere Agilität wird zudem auch durch eine starke Ausrichtung der IT am Geschäft bzw. der stärkeren Zusammenarbeit zwischen IT- und Fachabteilungen erreicht. Bezüglich der Kostensenkung wird bspw. die Wiederverwendung von Services zur Vermeidung redundanter Entwicklungen angeführt. Weitere Punkte sind das Outsourcing bestimmter IT-Services, die sich nicht auf das Kerngeschäft eines Unternehmens beziehen, und einfachere Änderungen ITgestützter Prozesse. Auch Krafzig et al. betrachten die SOA-Vorteile, die zur Steigerung der

T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_3, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

56

Serviceorientierte Architekturen

Agilität der Systeme der Enterprise IT beitragen, auf unterschiedlichen Ebenen. Sie fassen diese wie folgt zusammen (Krafzig et al. 2007, S. 251ff.): x

Bessere Wiederverwendbarkeit

x

Kosteneinsparungen auf Geschäftsebene und Einsparungen von IT-Kosten

x

Technologieunabhängigkeit

x

Evolutionärer Ansatz

x

Effizienterer Entwicklungsprozess

x

Feedback auf unterschiedlichen Ebenen

x

Geeignete Geschäftsinfrastruktur

x

Risikoabschwächung

Ähnliche Vorteile nannten die Befragten der Studie SOA Check 2009 (Martin et al. 2009). In der Studie wurden 111 Personen aus Unternehmen in Deutschland, der Schweiz und Österreich u.a. dazu befragt, welche strategischen Ziele das Unternehmen mit der Einführung einer SOA verfolgt20. Am häufigsten genannt wurden die Steigerung der Flexibilität (27%), die Optimierung der Prozesse (21%), eine Verkürzung der Time-to-Market (14%), die Steigerung des Innovationsgrades (8%) und die Steigerung der Produktivität (7%) (Martin et al. 2009, S. 16). Den zahlreichen Vorteilen, die mit der Einführung einer SOA erzielt werden können, stehen jedoch auch Schwierigkeiten und Risiken gegenüber. Bspw. diskutiert Erl neben den Vorteilen typische Fehlannahmen über serviceorientierte Architekturen und die Probleme, die bei einer SOA-Adaption auftreten können (Erl 2005, S. 56ff.). Er nennt u.a. die Berücksichtigung von Unterschieden beim Aufbau einer SOA gegenüber traditionellen Architekturen, Mängel bei der Standardisierung, Versäumnisse bei der Aufstellung von Übergangsplänen oder die Nicht-Berücksichtigung SOA-spezifischer Performance- und Sicherheitsanforderungen. 3.1.1

SOA-Definitionen

Der Begriff SOA wurde von Gartner bereits 1996 (siehe (Schulte und Natis 1996; Schulte 1996)) beschrieben und verwendet (Natis 2003, S. 2). Heute existieren in der Literatur zahlreiche Definitionen, die sich aufgrund der diversen Auffassungen über serviceorientierte Architekturen in bestimmten Aspekten überlappen, in anderen Aspekten jedoch deutlich unterscheiden (Melzer 2007, S. 11). Viele der Definitionen fokussieren insbesondere die technischen Aspekte einer Architektur (Bieberstein et al. 2005, S. 4), obwohl für das Ziel eines verbesserten Business-IT-Alignments vor allem auch geschäftliche bzw. fachliche Aspekte im Mittelpunkt stehen sollten (Brown et al. 2008, S. 17). Im Folgenden werden einige der Defini20

Zu nennen waren die drei subjektiv wichtigsten Ziele.

Grundlagen serviceorientierter Architekturen

57

tionen exemplarisch vorgestellt, um einen Überblick über die Breite des Begriffsverständnisses zu geben. Krafzig et al. verstehen SOA weder als eine Technologie noch als einen Technologiestandard, sondern vielmehr als ein technologieunabhängiges, High-Level-Konzept, das ArchitekturBlueprints zur Verfügung stellt (Krafzig et al. 2007, S. 30). Sie definieren SOA aus einer technischen Perspektive: „Eine Serviceorientierte Architektur (SOA) ist eine Softwarearchitektur, die auf den folgenden Schlüsselkonzepten basiert: Anwendungs-Frontend, Service, Service-Repository und Service-Bus. Ein Service besteht aus einem Vertrag, einer oder mehrerer Schnittstellen und einer Implementierung.“ (Krafzig et al. 2007, S. 77) Eine weitere technische Definition liefern Melzer et al.: Ihrem Verständnis nach handelt es sich bei einer SOA um „eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht.“ (Melzer 2007, S. 11) Im Kontext der Web Service Architecture (W3C 2004a) versteht das W3C unter einer SOA „a form of distributed systems architecture”, die typischerweise über die Merkmale der logischen Sicht, der Nachrichtenorientierung, der Beschreibungsorientierung, der Granularität, der Netzwerkorientierung und der Plattformunabhängigkeit charakterisiert wird. Abweichend von den bisher technisch geprägten Definitionen beschreibt die Definition von Starke und Tilkov SOA aus der Unternehmenssicht als ein Konzept zur Organisation flexibler Geschäftsprozesse: „Eine serviceorientierte Architektur (SOA) ist eine Unternehmensarchitektur, deren zentrales Konstruktionsprinzip Services (Dienste) sind. Dienste sind klar gegeneinander abgegrenzte und aus betriebswirtschaftlicher Sicht sinnvolle Funktionen. Sie werden entweder von einer Unternehmenseinheit oder durch externe Partner erbracht.“ (Starke und Tilkov 2007, S. 12) Die Autoren fügen hinzu, dass jenseits aller Technologien beim Konzept der SOA Services im Mittelpunkt stehen und es daher vorstellbar ist, eine SOA in einem Unternehmen zu etablieren, in dem kein einziger Computer vorhanden ist. Eine sehr abstrakte und allgemeingültige Beschreibung einer SOA liefert die Organization for the Advancement of Structured Information Standards (OASIS). In ihrem SOAReferenzmodel wird folgendes Verständnis einer serviceorientierten Architektur zugrunde gelegt: „Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. It is natural to think of one person’s needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent’s requirements being met by a computer agent belonging to a dif-

58

Serviceorientierte Architekturen

ferent owner. There is not necessarily a one-to-one correlation between needs and capabilities; the granularity of needs and capabilities vary from fundamental to complex, and any given need may require the combining of numerous capabilities while any single capability may address more than one need. The perceived value of SOA is that it provides a powerful framework for matching needs and capabilities and for combining capabilities to address those needs.“ (MacKenzie et al. 2006, S. 8) Neben den technisch geprägten Definitionen auf der einen Seite und den allgemeingültigeren auf der anderen Seite sind in der Literatur aber auch verschiedene Definitionen vorzufinden, die sowohl fachliche als auch technische Aspekte berücksichtigen. So definiert bspw. der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) eine serviceorientierte Architektur als ein Konzept, „welches das Geschäft und die IT eines Unternehmens nach Diensten strukturiert, die modular aufgebaut sind und flexibel zur Umsetzung von Geschäftsprozessen kombiniert werden können. Die IT-spezifischen Bestandteile des Konzepts werden durch eine IT- bzw. Systemarchitektur umgesetzt, welche auf lose gekoppelten und voneinander unabhängigen Services beruht, deren Interoperabilität auf offenen Standards beruht.“ (BITKOM 2009, S. 7) Auch Heutschi reflektiert in seiner Definition fachliche und technische Aspekte und betont die Mehrschichtigkeit einer SOA: „Eine SOA ist eine mehrschichtige, verteilte Informationssystem (IS)-Architektur, die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt und dabei bestimmte Designprinzipien berücksichtigt.“ (Heutschi 2007, S. 22) Mit dem Ziel, einen Konsens bezüglich des Verständnisses der Serviceorientierung und serviceorientierter Architekturen zu schaffen, wurde am 23.10.2009 in Rotterdam das SOAManifest von 17 international bekannten Autoren der SOA-Community erarbeitet und verabschiedet21. Darin ist folgendes Verständnis einer SOA niedergelegt, welches aufgrund des geschaffenen Konsenses auch im Rahmen dieser Arbeit übernommen wird: „Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.“ (Arsanjani et al. 2009) Die Ziele, die mit der Anwendung des serviceorientierten Paradigmas verfolgt werden, sind dem SOA-Manifest zufolge, einen kontinuierlich nachhaltigen Geschäftswert für Organisationen zu schaffen, die Agilität und Kosteneffizienz zu steigern und dies in Einklang mit den fachlichen Bedürfnissen zu bringen. Dabei werden die folgenden Priorisierungen vorgenommen (Arsanjani et al. 2009): 21

Vgl. hierzu die deutsche Website des SOA-Manifest (http://www.soa-manifest.de/) und die Kommentare von Nicolai M. Josuttis.

Grundlagen serviceorientierter Architekturen

x

Business value over technical strategy

x

Strategic goals over project-specific benefits

x

Intrinsic interoperability over custom integration

x

Shared services over specific-purpose implementations

x

Flexibility over optimization

x

Evolutionary refinement over pursuit of initial perfection

59

Die verschiedenen Definitionen bringen die unterschiedlichen Schwerpunkte zum Ausdruck, mit denen serviceorientierte Architekturen betrachtet werden können. Masak schlägt vor, abhängig vom Schwerpunkt und den zu untersuchenden Aspekten folgende weitere Begriffe zu unterscheiden (Masak 2007, S. 10): x

Service Oriented Computing (SOC): Der Bau von Services.

x

Service Oriented Architecture (SOA): Die aus der Nutzung von Services resultierende Architektur.

x

Service Oriented Platform (SOP): Die Infrastruktur für den Einsatz und die Entwicklung von Services.

x

Service Oriented Systems Engineering (SOSE): Die Vorgehensweise zum Bau und Einsatz von Services.

x

Service Oriented Enterprise (SOE): Die Struktur der servicenutzenden und -erzeugenden Organisation.

3.1.2

SOA-Prinzipien

Bei dem Aufbau, der Gestaltung und der Umsetzung einer SOA ist es wichtig, bestimmte Prinzipien einzuhalten, die abhängig vom zugrunde liegenden SOA-Verständnis und den damit verbundenen Charakteristika einer SOA auf unterschiedlichen Ebenen betrachtet werden können. Bspw. werden im zuvor erwähnten SOA-Manifest neben den beschriebenen Zielen und Priorisierungen grundlegende Prinzipien beschrieben, die organisatorische, soziale, technische und fachliche Aspekte berücksichtigen. Dazu gehören z.B. Prinzipien wie organisatorische Veränderungen, die Ausrichtung von Services bezüglich der fachlichen Anforderungen und Ziele, die Reduktion impliziter und die Publikation externer Abhängigkeiten oder die Organisation von Services in oder anhand zusammenhängender und verwaltbarer Funktionseinheiten (vgl. (Arsanjani et al. 2009)). Neben diesen allgemeinen und übergeordneten Prinzipien sind in der Literatur diverse Beiträge über Designprinzipien zur Gestaltung serviceorientierter Architekturen und Services vorzufinden. Heutschi merkt an, dass ein Vergleich der Designprinzipien verschiedener Autoren aufgrund unterschiedlicher Prioritäten und Detailgrade, inhaltlicher Unterschiede bei gleicher Begriffsverwendung sowie inhaltlicher Gemeinsamkeiten bei unterschiedlicher Benennung schwerfällt (Heutschi 2007, S. 30). Für einen Vergleich identifiziert Heutschi grundlegende

60

Serviceorientierte Architekturen

Designprinizpien auf Basis von SOA-Charakterisierungen aus Wissenschaft und Praxis (vgl. (Heutschi 2007, S. 193ff.)), die er in vier Klassen zusammenfasst (Heutschi 2007, S. 30ff.): x

Schnittstellenorientierung o Abstraktion von der Serviceimplementierung o Umfassende, einheitliche Servicespezifikationen o Stabile, gemanagte Servicekontrakte

x

Interoperabilität o Technische Schnittstellenstandardisierung o Fachliche Schnittstellenstandardisierung o Verwendung offener und verbreiteter Industriestandards

x

Autonomie und Modularität o Hohe Servicekohäsion und schwache logische Kopplung o Lose gekoppelte Kommunikation

x

Bedarfsorientierung o An Geschäftskonzepten orientierte, grobe Servicegranularität o Generalisierung der Serviceleistung

Die Analyse neun verschiedener Quellen zeigt im Vergleich, dass die Abstraktion von der Serviceimplementierung, einheitliche Servicespezifikation und die technische Standardisierung am häufigsten genannt werden, worin Heutschi einen Indikator für die Bedeutung dieser Designprinzipien sieht (Heutschi 2007, S. 45ff.). Weniger wichtig dagegen erscheinen z.B. die fachliche Standardisierung oder die Servicegeneralisierung. 3.1.3

SOA-Erfolgsfaktoren

Die erfolgreiche Einführung und der Betrieb einer SOA sind von einigen entscheidenden Faktoren abhängig. In (BITKOM 2009, S. 16ff.) werden wichtige Erfolgsfaktoren diskutiert, die auf Basis von Erfahrungswerten und Empfehlungen aus der Praxis identifiziert wurden. Ein grundlegender Erfolgsfaktor ist neben der Anwendung von Methoden des Änderungsmanagements die ganzheitliche Betrachtung der Ausrichtung und Wertschöpfung eines Unternehmens. Darüber hinaus sollte zur Einführung einer SOA ein kleines überschaubares Projekt initiiert werden, das sich an dem großen Gesamtbild orientiert und schnell umzusetzen ist. Im Rahmen der ersten Projekte ist insbesondere der Einsatz erfahrener Mitarbeiter von besonderer Bedeutung. Weitere ebenso wichtige Erfolgsfaktoren sind eine iterative Bewertung des Nutzens, die Einführung einer SOA-Governance, ein Masterplan für den Aufbau der Infrastruktur, die Verwendung von Standards und standardkonformer Produkte beim Aufbau der SOA-Plattform sowie die Kooperation zwischen den Fachbereichen und der IT. Um die Relevanz unterschiedlicher Erfolgsfaktoren bewerten zu können, wurde von Durst und Daum eine Studie (Durst und Daum 2007) durchgeführt, in der mittels einer qualitativen

Grundlagen serviceorientierter Architekturen

61

State-of-the-Art-Analyse und einer Expertenbefragung 15 Erfolgsfaktoren identifiziert und im Rahmen einer quantitativen Erhebung auf Basis einer Online-Befragung weiter validiert und detailliert wurden. Darunter ist u.a. ein Großteil der bereits zuvor genannten Erfolgsfaktoren, wie z.B. die Aufstellung einer SOA-Governance, die Forcierung der Zusammenarbeit zwischen Fachseite und IT oder das inkrementelle Vorgehen und die Nutzung einer Pilotimplementierung, wiederzufinden. Acht der 15 identifizierten Erfolgsfaktoren wird der Studie zufolge eine sehr hohe Relevanz beigemessen (Durst und Daum 2007, S. 23f.). Dabei ist der mit Abstand wichtigste Erfolgsfaktor die Verankerung der SOA-Initiative in der Unternehmens/IT-Strategie (98,4 %), gefolgt von dem Vorliegen fachlicher Voraussetzungen (95,1 %) und der Forcierung der Zusammenarbeit zwischen Fachseite und IT (94,3 %). 3.1.4

SOA- und Unternehmensarchitekturen

In Kapitel 2.3 wurde als Grundlage für das Architekturverständnis im Kontext serviceorientierter Architekturen der allgemeine Architekturbegriff, der Bereich der Unternehmensarchitektur sowie Architekturmodelle und -Frameworks am Beispiel des Zachman Enterprise Framework und des Open Group Architecture Frameworks (TOGAF) betrachtet. Die beiden Frameworks werden an dieser Stelle noch einmal aufgegriffen, um die Zusammenhänge zwischen serviceorientierten Architekturen und Unternehmensarchitekturen zu veranschaulichen.

SOP

SOA

SOC

Component Technicians

SOE

System Architects Technology Engineers

Who Organization

When Timing

Why Motivation

SOC

Where Network

SOE

Business Executive Leaders

SOE

Scope Strategists

How Process

SOC

What Inventory

Operations Workers Tabelle 3: Das serviceorientierte Paradigma im Zachman Framework Quelle: (Masak 2007, S. 25)

Eine Darstellung der Serviceorientierung aus Sicht des Zachman Frameworks nimmt bspw. Masak vor (Masak 2007, S. 23ff.). Er verwendet dazu die zuvor abgegrenzten Begriffe SOE, SOC, SOA und SOP und ordnet diese in die Matrix des Zachman Frameworks ein. Tabelle 3 zeigt, dass die meisten Zellen des Zachman Frameworks durch die Serviceorientierung betrof-

62

Serviceorientierte Architekturen

fen sind. Masak merkt an, dass am hohen Grad der Überdeckung des Zachman Frameworks durch die Serviceorientierung deutlich wird, „wie fundamental der Eingriff durch die Serviceorientierung in allen Bereichen der Organisation und Software ist.“ (Masak 2007, S. 26) Auch im Rahmen der aktuellen TOGAF-Version wird die Verwendung von TOGAF zur Definition und Governance serviceorientierter Architekturen explizit betrachtet (The Open Group 2009c, S. 249ff.). Dabei werden insbesondere die Faktoren bezüglich der Adaption und Einführung einer SOA im Unternehmen, die Zusammenhänge und Gemeinsamkeiten der SOA- und TOGAF-Terminologie sowie die Definition und Struktur von Service-Verträgen diskutiert. Das SOA-Konzept wird im Rahmen von TOGAF als Architekturstil verstanden, mit dem Zweck, den Geschäftsbetrieb und die Zusammenarbeit zwischen verschiedenen Geschäftsbereichen zu vereinfachen. Die Disziplin der Unternehmensarchitektur stellt für den SOAKontext Tools und Techniken zur Verfügung, die dazu beitragen, die entwicklungstechnische und geschäftsgetriebene Perspektive einer SOA enger und nachhaltiger miteinander zu verbinden. Dabei werden insbesondere nicht-technische Herausforderungen bei SOA-Adaptionen adressiert. Die Unternehmensarchitektur bildet somit eine Grundlage für serviceorientierte Organisationen und unterstützt diese in folgenden Punkten (The Open Group 2009c, S. 253f.): x

Stärkere Vernetzung der SOA-Stakeholder, wobei sichergestellt wird, dass die Bedarfe aller Stakeholder erfüllt werden und jeder Stakeholder sich des entsprechenden Kontexts bewusst ist.

x

Bindeglied zwischen IT- und Geschäftswelt, mit dem IT-Kosten gegenüber dem Geschäftswert gerechtfertigt werden können.

x

Unterstützung bei Fragen der Service-Entwicklung und der -Wiederverwendung.

x

Unterstützung bei Fragen des Service-Designs und der Plattform-Interoperabilität.

x

Bereitstellung eines Repository zur Speicherung und Wartung entwurfsbezogener Informationen.

Weitere Betrachtungen und Diskussionen über den Bereich der serviceorientierten Architektur im Zusammenhang mit Unternehmensarchitekturen und TOGAF liefert das SOA Source Book der Open Group (The Open Group 2009b). Der Fokus ist dabei auf die IT-Komponente der Unternehmensarchitektur und die strategische Entwicklung der Unternehmens-IT gerichtet, bei der SOA als eine spezielle Konstruktionstechnik eingesetzt wird. Neben allgemeinen SOA-Grundlagen, einem SOA-Reifegradmodell, SOA Building Blocks, einer SOAReferenzarchitektur und der SOA-Infrastruktur wird im SOA Source Book die Verwendung von TOGAF für die Entwicklung von SOA-Lösungen oder einer gesamten UnternehmensSOA vertieft. Einen Schwerpunkt bilden dabei Überlegungen in Bezug auf die einzelnen Phasen der Architecture Develompment Method (siehe Kapitel 2.3.3) bei der Anwendung ser-

Bestandteile und Ebenen serviceorientierter Architekturen

63

viceorientierter Prinzipien. Des Weiteren werden unter Berücksichtigung von TOGAF der Aufbau einer Informationsarchitektur für serviceorientierte Architekturen, die Adressierung von Stakeholder-Concerns im Kontext serviceorientierter Architekturen sowie Konzepte der SOA-Governance (SOA-Governance-Framework, SOA-Governance-Referenzmodell, SOA Governance Vitality-Methode) diskutiert. Am Beispiel der beiden Frameworks wird deutlich, dass Konzepte der serviceorientierten Architektur und der Unternehmensarchitektur gemeinsam zur Strukturierung der Enterprise IT eingesetzt werden können und sich in vielen Aspekten ergänzen. Rosen et al merken diesbezüglich an, dass eine Unternehmensarchitektur nicht vorhanden sein muss, um eine SOA erfolgreich aufzubauen; ist diese aber bereits im Unternehmen etabliert, sollte sie den Aufbau einer SOA unterstützen und mit ihr integriert werden (Rosen et al. 2008, S. 46). 3.2

Bestandteile und Ebenen serviceorientierter Architekturen

Eine SOA besitzt zahlreiche Elemente und Schichten, die je nach Ausprägungsform bzw. Evolutionsstufe einer SOA variieren. Krafzig et al. differenzieren bspw. zwischen einer grundlegenden SOA, einer vernetzten SOA und einer prozessfähigen SOA (Krafzig et al. 2007, S. 103ff.), wobei eine vollständige prozessfähige SOA im Gegensatz zur grundlegenden SOA neben einer Basis-Schicht und einer Enterprise-Schicht eine Zwischenschicht und eine Prozess-Schicht (siehe Kapitel 3.2.3) umfasst. Erl hingegen unterscheidet zwischen einer einfachen (primitive) SOA, die eine Basistechnologie-Architektur darstellt, und einer zeitgemäßen (contemporary) SOA, die die einfache SOA um viele Charakteristiken und Aspekte (z.B. Quality of Service, offene Standards, Verwendung von Abstraktionsschichten) erweitert (Erl 2005, S. 40f.). Ähnlich unterscheiden Papazoglou und van den Heuvel zwischen einer konventionellen und einer erweiterten SOA (Papazoglou und van den Heuvel 2007). Die erweiterte SOA ergänzt die Konzepte der konventionellen SOA um zusätzliche logische Ebenen, mit denen multi-dimensionale Aspekte nach dem Prinzip der Separation of Concerns über die Definition spezieller Konstrukte, Rollen und Verantwortlichkeiten berücksichtigt werden können. In Wissenschaft und Praxis werden die Elemente einer SOA auf unterschiedlichen Abstraktionsschichten betrachtet. Die Beschreibungen der unterschiedlichen Elemente, wie z. B. Domänen, Services, Geschäftsprozesse, Aktivitäten, Applikationen, Komponenten, Nachrichten oder Schnittstellen reichen von der Definition abstrakter Metaentitätstypen (vgl. bspw. (Heutschi 2007, S. 189ff.)) über die Identifikation konkreter SOA-Artefakte (vgl. bspw. (Engels et al. 2008, S. 101ff.) bis hin zu umfassenden SOA-Referenzmodellen und -architekturen (Estefan et al. 2009; The Open Group 2009b; Rosen et al. 2008, S. 73ff.; Arsanjani et al. 2007; The Open Group 2009a), in denen die Elemente und ihre Beziehungen mit unterschiedlichem Abstraktions- und Detailgrad abgebildet werden.

64

3.2.1

Serviceorientierte Architekturen

Services

Das grundlegende Konzept bzw. Element einer SOA ist der Service. Der Servicebegriff ist im IT-Umfeld weit verbreitet. Bspw. definiert der IT Infrastructure Library (ITIL) Standard V3 (Office of Government Commerce (OGC) 2007) im Bereich des IT-Service-Managements einen Service wie folgt: „A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific cost and risk.” (Office of Government Commerce (OGC) 2007, S. 40) Im Bereich der serviceorientierten Architektur ist die Verwendung des Service-Begriffs vom jeweiligen SOA-Verständnis bzw. den verschiedenen SOA-Definitionen (siehe Kapitel 3.1.1) abhängig. Heutschi bspw. verbindet den Service-Begriff insbesondere mit softwaretechnischen Aspekten: „Ein Service stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Applikationen über ein Netzwerk einen standardisierten Zugriff auf Anwendungsfunktionen anbietet.“ (Heutschi 2007, S. 22) Ähnlich technisch geprägt ist das Verständnis von Krafzig et al., die unter einem Service eine Software-Komponente verstehen, die eine ganz bestimmte Funktion besitzt und in der Regel ein Geschäftskonzept höherer Ebene einkapselt (Krafzig et al. 2007, S. 78). Dabei besteht ein Service aus Daten und Geschäftslogik sowie Schnittstellen und ihren Beschreibungen. Das W3C liefert eine allgemeinere Service-Definition und sieht einen Service als abstrakte Ressource, die eine Leistungsfähigkeit zur Durchführung von Aufgaben darstellt: „A service is an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities. To be used, a service must be realized by a concrete provider agent.” (W3C 2004b) Ähnlich dem Verständnis des W3C sieht die OASIS einen Service als einen Mechanismus, der Zugriff auf eine oder mehrere Leistungen erlaubt, wobei explizit angeführt wird, dass die konsistente Ausführung bestimmten Bedingungen und Policies unterliegt: „A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (MacKenzie et al. 2006, S. 12). Die Funktionsweise bezüglich der Bereitstellung, Suche und Interaktion von Services wird auf Basis eines Dreieckmodells (Masak 2007, S. 101ff.; Erl 2005, S. 75; Melzer 2007, S. 12ff.; W3C 2004a; Zhang et al. 2007, S. 89f.) abgebildet, in dem sich drei Rollen identifizieren lassen: Service Provider, Service Consumer und Service Registry. Abbildung 22 zeigt eine typische Darstellung des Dreieckmodells, mit der das Zusammenspiel der an einer SOA beteiligten Rollen veranschaulicht wird.

Bestandteile B und Ebbenen serviceorienttierter Architekturen

655

Abbildung A 22: Rolllen und Operation nen einer SOA Quelle: Q (W3C 20044a)

Ein E Service wirdd demnach durcch einen Servicee Provider zur Verfügung V gesteellt. Ein Servicee Consumer C greiftt über eine Serviice-Schnittstellee auf die Leistunngen des Servicees zu, wobei derr Service S Consum mer dem Servicee Provider nicht bekannt sein muss. m Die Schnitttstelle wird beii der d Verwendungg von Web Seervices auf Bassis der Web Services S Descripption Languagee (WSDL) (W3C 2001) beschrieeben. Die Impleementierung deer Service-Funkktionalität bleibtt dem d Service Connsumer dabei inn der Regel verb borgen. Um das Auffinden vonn Services zu er-leichtern, könneen Services vom m Service Prov vider bei einer Service S Registry ry veröffentlichtt werden. w Für die Registrierung und u das Auffindden von Web Seervices steht bsppw. der standar-disierte d Verzeichhnisdienst (Registry) Universall Description, Discovery D and Inntegration (UD-DI) D (OASIS 20004) zur Verfüguung. Der Servicce Consumer hat somit die Möglichkeit, M einee Suchanfrage S nacch bestimmten Services S an die Registry R zu stelleen. 3.2.2 3

Servicetypen

Services S besitzenn eine Menge sppezifischer Chaarakteristika (Maasak 2007, S. 999f.; Erl 2005, S.. 291ff.; 2 Rosen et al. 2008, S. 53fff.; Marks und Bell B 2006, S. 39ff.; Josuttis 20008, S. 39ff.), wiee z.B. z lose Koppluung, Interoperabbilität, dynamiscche Discovery, Komponierbarkkeit, Autonomiee oder o Wiederverw wendbarkeit. Daarüber hinaus laassen sich anhannd verschiedeneer Dimensionenn unterschiedliche u Servicetypen bzw. Servicem modelle voneinander abgrenzenn. Rosen bspw.. unterscheidet u vieer Servicedimennsionen (Rosen et al. 2008, S. 60f.): Scope, Ownership, O Gra-nularity n und Connstruction. Er merkt m an, dass jeeder Service besstimmte Aspektee dieser Dimen-sionen s besitzt. Z Zudem lassen siich Servicetypenn nach Art des Nutzens (Rosenn et al. 2008, S.. 70f.; 7 Josuttis 20008, S. 95f.), nacch Art der Zugriiffsberechtigungg (lesende und schreibende Ser-vices) v oder nachh fachlichen Asppekten unterscheeiden (Josuttis 20008, S. 96ff.).

66

Serviceorientierte Architekturen

Typisierungsdimensionen

Ausprägungen Service-Ziel

Gemanagte Schnittstellen

Geltungsbereich

Domänenintern (Private)

Beschaffungsstrategie

Interne Erstellung/ Kooperation

Technologiereduktion

Wiederverwendung

Domänenüber-greifend (Public) Übergang

...

Unternehmensübergreifend

Externer Bezug (OutTasking)

Kommerzialisierung

Art der Funktion

Technisch / Infrastruktur

Geschäftlich

Fachliche Granularität

Querschnittsfunktion

Prozess-aktivität

Komposition

Atomarer Service (Application-Service)

Kompositions-Services (Enterprise Service)

Synchron

Request/ Response

Interaktionsstil

Entität/ Geschäftsobjekt

Asynchron

Geschäftsprozess

Notification

Tabelle 4: Dimensionen einer Servicetypisierung Quelle: (Heutschi 2007, S. 172)

Einen Überblick über mögliche Unterscheidungsdimensionen und ihre Ausprägungen (siehe Tabelle 4) zur Typisierung von Services, die in Fallbeispielen und in der Literatur identifiziert wurden, gibt auch Heutschi (Heutschi 2007, S. 172ff.). In der Literatur werden zahlreiche unterschiedliche Servicetypen bzw. Servicemodelle differenziert, wobei diese nicht immer explizit nach bestimmten Dimensionen voneinander abgegrenzt werden. Insofern können bestimmte Servicetypen auch Aspekte mehrerer Dimensionen besitzen und lassen sich daher mehreren Dimensionen zuordnen. Krafzig et al. unterscheiden zwischen vier Serviceklassen (Krafzig et al. 2007, S. 86ff.): Basis-Services, Zwischenservices, prozesszentrierte Services und öffentliche UnternehmensServices. Während es sich bei Basis-Services um einfache datenzentrierte oder logikzentrierte Services handelt, können Zwischenservices in Technologie-Gateways, Adapter, Fassaden und funktionalitätsergänzende Services unterteilt werden. Prozesszentrierte Services hingegen kapseln die Prozesslogik der Geschäftsprozesse des Unternehmens. Öffentliche Unternehmensservices wiederum werden mit anderen Unternehmen oder Partnerorganisationen gemeinsam genutzt. Erl spricht bei der Klassifizierung von Services nicht von Servicetypen, sondern von Servicemodellen. Er unterscheidet zwischen drei grundlegenden Servicemodellen, wobei die Bezeichnungen der Servicemodelle in seinen Veröffentlichungen variieren: Application Services, Business Services und Process Services (Erl 2005, S. 337ff.) bzw. Utility Services, Entity Ser-

Bestandteile und Ebenen serviceorientierter Architekturen

67

vices und Orchestrated Task Services (Erl 2007, S. 43ff.). Im Folgenden werden in Anlehnung an (Erl 2007, S. 43ff.) verschiedene Services kurz erläutert, die auf den zuvor genannten Servicemodellen basieren. Application bzw. Utility Services stellen wiederverwendbare Querschnittsfunktionen, wie z.B. Logging, Benachrichtigungen oder Fehlerbehandlung, zur Verfügung. Die Logik dieser Services hat somit keinen Geschäftsbezug. Weitere Bezeichnungen für Application Services sind Infrastructure Services oder Technology Services. Business bzw. Entity Services hingegen sind auf das Geschäft ausgerichtete Services, deren funktionaler Kontext von einer oder mehreren verwandten Geschäftsentitäten abgeleitet wird. Sie werden auch als Entity-centric Business Services oder Business Entity Services bezeichnet. Process bzw. Task Services wiederum sind Business Services, deren funktionaler Kontext direkt mit spezifischen übergeordneten Aufgaben oder Prozessen assoziiert ist. Im Gegensatz zu Entity Services kapseln Task Services Geschäftsprozesslogik mit einer Abfolge bestimmter Schritte, wodurch deren Wiederverwendbarkeit geringer ausfällt. Neben Process Services wird auch die Bezeichnung Task-centric Business Services verwendet. Task Services, die eine konkrete Geschäftsprozessdefinition repräsentieren und auf einer Orchestrierungsplattform gehostet werden, werden Orchestrated Task Services genannt. Weitere Bezeichnungen dafür sind Business Process Services oder Orchestration Services. Für die Beschreibung und Implementierung solcher Process Services bzw. Orchestrated Task Services stehen Sprachen wie die Web Services Business Process Execution Language (WSBPEL) (OASIS 2007) oder die XML Process Definition Language (XPDL) (Workflow Management Coalition (WfMC) 2008) zur Verfügung. Neben den zuvor genannten grundlegenden Servicemodellen nennt Erl weitere davon abgeleitete Servicemodelle, wie bspw. Hybrid Services, die sowohl Applikations- als auch Geschäftslogik beinhalten, oder Wrapper Services, die für Integrationszwecke eingesetzt werden. Ein Überblick über alle von Erl beschriebenen Servicemodelle ist (Erl 2005, S. 718ff.) zu entnehmen. Weitere Abgrenzungen, die den von Krafzig et al. und Erl beschriebenen grundlegenden Servicetypen bzw. Servicemodellen ähneln, werden bspw. von Masak (Masak 2007, S. 112ff.), Rosen et al. (Rosen et al. 2008, S. 70f.), Josuttis (Josuttis 2008, S. 81ff.) und Allen (Allen 2006, S. 72ff.) vorgenommen. 3.2.3

SOA-Abstraktionsschichten

Die verschiedenen Servicetypen stehen miteinander in Beziehung und sind darüber hinaus an weitere Elemente einer SOA gekoppelt (Geschäftsprozesse, Komponenten, Daten, Rechnerknoten, etc.). Die Strukturierung der Elemente und deren Beziehungen, wie z.B. die Komposi-

68

Serviceorientierte Architekturen

tion von Services, erfolgt auf Basis unterschiedlicher Abstraktionsschichten (Masak 2007, S. 93f.; Erl 2005, S. 280ff.; Bieberstein et al. 2005, S. 86ff.; Zhang et al. 2007, S. 108f.; Josuttis 2008, S. 82ff.; Krafzig et al. 2004, S. 99ff.), die jeweils bestimmte Aspekte der Gesamtstruktur einer SOA abdecken. Zwar werden von den verschiedenen Autoren zum Teil unterschiedliche Bezeichnungen für die Abstraktionsschichten gewählt, das Grundverständnis in Bezug auf die elementaren Schichten hingegen ist sehr ähnlich. So werden in fast allen der oben genannten Veröffentlichungen Unterteilungen in Bezug auf Geschäftsprozesse, Services, Komponenten und operative Systeme vorgenommen. Die Anzahl elementarer Schichten ist dabei vom gewählten Abstraktionsgrad, dem jeweiligen Fokus auf bestimmte Aspekte und den damit verbundenen Verantwortlichkeiten abhängig. In der Regel werden diese Schichten noch in weitere Subschichten unterteilt. Im Folgenden werden SOA-Abstraktionsschichten nach Krafzig et al, Erl und der Open Group exemplarisch vorgestellt, um einen Überblick über deren mögliche Ausprägungen zu geben. Krafzig et al. verwenden die in Kapitel 3.2.2 genannten Serviceklassen, um eine konzeptionelle Gesamtstruktur innerhalb einer SOA zu beschreiben, die durch vier Schichten dargestellt wird (vgl. im Folgenden (Krafzig et al. 2007, S. 99ff.)). Die Enterprise-Schicht ist die höchste SOA-Schicht und enthält Anwendungs-Frontends und Unternehmens-Services, die Endpunkte für den Zugriff auf die SOA repräsentieren. Die Endpunkte dienen sowohl Kommunikationszwecken als auch einer unternehmensübergreifenden Integration. Während die ProzessSchicht prozesszentrierte Services beinhaltet, enthält die Zwischenschicht Zwischen-Services, die als Technologie-Gateways, Adapter oder Fassaden dienen. Die Basis-Schicht ist nach dem Verständnis von Krafzig et al. die unterste Schicht einer SOA und setzt sich aus den BasisServices zusammen. Diese stellen die Geschäftslogik und Daten bereit. Bei den von Krafzig et al. beschriebenen Abstraktionsschichten werden ausschließlich Servicetypen als Strukturelemente betrachtet. Erl hingegen unterscheidet drei grundlegende Abstraktionsschichten, die neben Services auch andere Elemente einer SOA umfassen (vgl. im Folgenden (Erl 2005, S. 280ff.)): eine Business Process Layer, eine Service Interface Layer und eine Application Layer. Abbildung 23 zeigt die verschiedenen Schichten und ihren Aufbau. Die Business Process Layer implementiert die fachlichen Anforderungen einer Unternehmensorganisation. Sie ist in verschiedene Geschäftsprozesse unterteilt, welche die unterschiedlichen Anforderungen, einschließlich der damit verbundenen Einschränkungen, Abhängigkeiten und externen Einflüsse, abbilden. Die Service Interface Layer stellt Konzepte zur Verfügung, um Unternehmenslogik zu repräsentieren, zu modellieren und zu kommunizieren. Sie besteht aus Diensten, auf die aus anderen Schichten zugegriffen werden kann. Dienste modularisieren die Unternehmenslogik und

Bestandteile B und Ebbenen serviceorienttierter Architekturen

699

ih hre Bestandteilee. Sie stellen, wie w zuvor erläuteert, in sich geschhlossene Einheitten dar, die spe-zifische z Leistunggen zur Verfüguung stellen. Die D Application Layer implemeentiert Workflow ws in Form von eigen- oder fremdentwickeltenn Softwaresysteme S en. Diese Softw waresysteme exisstieren innerhalbb der IT-Infrastrruktur eines Un-ternehmens undd unterliegen deen gegebenen Sicherheitsbeschrränkungen, techhnischen Fähig-keiten k und mögliichen Herstellerrabhängigkeiten.

Abbildung A 23: Absstraktionsschichteen nach Erl Quelle: Q (Erl 2005, S S. 282)

Die D drei Layer können in weiitere Abstraktioonsschichten (Suubschichten) unnterteilt werdenn (siehe Abbildunng 24). Auf Ebeene der Service Interface Layeer identifiziert Erl E drei primäree Schichten, S mit denen d unterschiiedliche Konfigurationsszenarieen erstellt werdden können (Erll 2005, 2 S. 347ff.). Solche Konfiggurationsmöglicchkeiten bieten den Vorteil, einne SOA bei derr Vielzahl V an Servvicemodellvariattionen besser zu u strukturieren. Sie gliedern sicch in eine Appli--

70 7

Serviceorienttierte Architekturenn

cation c Service L Layer, eine Businness Service Laayer und eine Orrchestration Serrvice Layer (Erll 2005, 2 S. 336ff.).

Abbildung A 24: Untterteilung der Servvice Interface Layyer in weitere Subsschichten Quelle: Q (Erl 2005, S S. 337)

Ein E Konfiguratioonsszenario bezüüglich der Serviice Interface Layyer wäre bspw. der Einsatz vonn Process P Servicess innerhalb der Orchestration Service Layer, die Task-centriic Business Ser-vices v innerhalb dder Business Serrvice Layer zusaammenfassen. Diese D wiederum bilden Kompo-sitionen s aus Utillity Application Services innerhaalb der Applicattion Service Layyer. Die Processs Services S stellen somit ihre Funnktionalität übeergeordneten Geeschäftsprozesseen der Businesss Process P Layer zzur Verfügung, während w die Uttility Applicationn Services bspw w. Funktionalitätt der d Backend-Syssteme kapseln. In der Open Grooup Reference Architecture A Fouundation for SO OA werden in Annlehnung an diee Arbeiten A von Arrsanjani et al. (A Arsanjani et al. 2007; Arsanjanni 2004; Arsanjani et al. 2007)) fünf f horizontale und vier vertikkale Schichten unterschieden, u w welche in ihrer Gesamtheit G auchh als a Service-Orieented Solution Stack S (S3) bezeeichnet werden (Arsanjani et al. a 2007). Dem m Aufbau A der Schiichten liegt ein Metamodell (sieehe Abbildung 25) 2 zugrunde, auf a dessen Basiss

Bestandteile B und Ebbenen serviceorienttierter Architekturen

711

die d SOA-Referennzarchitektur füür eine konkrete Lösung instanziiert werden kannn. Eine Schichtt besitzt b dem Mettamodell zufolgge eine Menge an a Komponenten, wie z.B. Arcchitectural Buil-ding d Blocks (AB BBs), Architektturentscheidung gen und Interakttionen zwischenn Komponentenn und u zwischen Scchichten22.

Abbildung A 25: Mettamodell zur Instaanziierung der SO OA Solution Refereence Architecture Quelle: Q (The Open G Group 2009a, S. 177)

Mit M jeder Schichht sind sowohl logische als au uch technische Aspekte A verbunnden (The Openn Group G 2009a, S.. 15). Logische Aspekte sind, neben n den zuvorr genannten Arcchitectural Buil-ding d Blocks (AB BBs), Architektuurentscheidungeen und Interaktionen, z.B. Alterrnativen als Ba-sis s für die Archiitekturentscheiddungen oder Keyy Performance Indikatoren I (KP PIs). Technischee Aspekte A hingegeen beziehen sich auf die Realiisierung der loggischen Aspektee unter Verwen-dung d von Technoologien, Standarrds und Produktten. Abbildung A 26 lieefert eine Überssicht über die neeun logischen Schichten der Oppen Group SOA A Referenzarchitek R ktur. Die horizoontalen Schichteen implementieeren die funktioonalen Anforde-rungen, r währendd die vertikalenn Schichten un nterstützende Fuunktionen in Beezug auf nicht-funktionale f Aspekte, wie Sicheerheit, Verfügbaarkeit, Skalierbaarkeit, Governannce, Integration,, etc., e zur Verfüguung stellen. Diee fünf horizontalen Schichten reepräsentieren zuudem Interessenn aus a Sicht von Seervice Providernn und Service Co onsumern. Eine Schicht ist nichht ausschließlichh von v der unmitteelbar tieferliegeenden Schicht abhängig. a So kann k die Consuumer Interfaces--

22 2

Für eine genauerre Beschreibung dees Metamodells und d der einzelnen Eleemente sei auf (Arssanjani et al. 2007;; The Open Groupp 2009a) verwiesen.

72 7

Serviceorienttierte Architekturenn

Schicht S direkt mit m der Servicees-Schicht interragieren, falls bspw. b die Businness Processes-Schicht S erst zu eeinem späteren Zeitpunkt Z realisiert wird (The Open O Group 20099a, S. 17).

Abbildung A 26: Sch hichten der Open Group G SOA Referrenzarchitektur Quelle: Q (The Open G Group 2009a, S. 188)

Im Folgenden w werden die Schicchten in Anlehnuung an (The Oppen Group 2009a, S. 19ff.) kurzz erläutert: e x

Schicht 1 - Operationall Systems: Die Schicht erfasst die neue und alte Organisati-onsinfrasstruktur, einschließlich der Ak kteure, die für die Unterstützzung der SOA-Lösung benötigt b werden.

x

Schicht 2 - Service Com mponents: Die Schicht S enthält Softwarekompoonenten, die diee Implementierung bzw. Realisierung vo on Services berreit stellen. Daabei werden diee Konform mität mit den inn der Servicesch hicht festgelegten Servicevertrrägen sowie diee Ausrichtuung der Implem mentierung an den Servicebeschrreibungen sicherrgestellt.

x

Schicht 3 - Services: Diee Schicht bestehht aus allen Services, die innerrhalb einer SOA A definiert werden. Sie ennthält die Servicebeschreibungenn (Assets der Entwurfszeit E undd der Gescchäftsarchitekturr sowie Beschreeibung der Serviiceverträge für die d Laufzeitum-gebung) und u dient als Coontainer für die Implementierunng der Services.

x

Schicht 4 - Business Processes: P In seerviceorientierteen Umgebungenn wird die Ge-schäftsfuunktionalität mitthilfe von Geschhäftsprozessen realisiert. r Die GeschäftsprozesG se enthallten Service-Orrchestrierungen und -Komposittionen, besitzenn die Fähigkeit,, menschliiche Interaktionnen einzubinden n und unterstüttzen langlebige Transaktionen..

Governance im Kontext serviceorientierter Architekturen

73

Vor allem die Komposition und Choreographie von Services der dritten Schicht werden in der Business Processes-Schicht definiert. Sie umfasst demnach die Abbildung von Prozessen, Kompositionsmethoden und Building Blocks, um lose gekoppelte Services unter Berücksichtigung der Geschäftsziele zu Prozessen zu aggregieren. Datenund Kontrollflüsse werden dabei für die Interaktion zwischen Services und Geschäftsprozessen verwendet.

3.3

x

Schicht 5 - Consumer Interfaces: Die Consumer Interfaces-Schicht stellt Möglichkeiten zur Verfügung, um Endanwendern unter Berücksichtigung spezifischer Präferenzen IT-Funktionen und Daten bereitzustellen (z.B. über bestimmte Kanäle, Portale oder Rich Clients). Es können somit schnell Multi-Channel-Frontends für Geschäftsprozesse und Composite Applications erstellt werden, um auf Marktänderungen zu reagieren. Zudem dient diese Schicht auch als Schnittstelle für die Kommunikationen zwischen Applikationen.

x

Schicht 6 - Integration: Mit der Integrationsschicht werden Möglichkeiten zur Mediation, Transformation sowie zum Routing und Transport von Service Requests zur Verfügung gestellt. Darüber hinaus wird eine Unterstützung für gemeinsame Geschäftsregeln angeboten, um sicherzustellen, dass diese über alle Schichten der Architektur hinweg angewendet werden.

x

Schicht 7 - Quality of Service: Die Quality of Service-Schicht stellt Prozesse bezüglich des Service-Lebenszyklus bereit, mit denen sichergestellt werden kann, dass die definierten Policies und nicht-funktionalen Anforderungen eingehalten werden. Dazu gehört das Monitoring und Aufzeichnen entsprechender Service-Metriken sowie die Überwachung der Compliance von nicht-funktionalen Anforderungen in Bezug auf die Servicequalität und Policies.

x

Schicht 8 - Information: Die Informationsschicht umfasst Überlegungen bezüglich der Informationsarchitektur, der Datenarchitektur, Business Intelligence und des Metadatenmanagements.

x

Schicht 9 - Governance: Die Governance-Schicht umfasst die SOA-Governance (siehe Kapitel 3.3) und deckt den gesamten Lebenszyklus von Services bzw. SOA-Lösungen ab. Es steht ein Portfolio-Management zur Verfügung, mit denen alle relevanten Aspekte (z.B. Service Level Agreements (SLAs), Performanz, Sicherheit, Monitoring) der Services bzw. SOA-Lösungen verwaltet werden können. Die Governance-Schicht hat Einfluss auf alle anderen Schichten der SOA-Referenzarchitektur. Governance im Kontext serviceorientierter Architekturen

Im folgenden Kapitel werden zunächst die Bedeutung der Governance im Unternehmensumfeld behandelt und ihre unterschiedlichen Ausprägungsformen vorgestellt. Nach einer kurzen Einführung in die Corporate, IT- und Architecture Governance wird dargestellt, wie sich die

74

Serviceorientierte Architekturen

SOA-Governance in diese einordnen bzw. von diesen abgrenzen lässt (Kapitel 3.3.1). Anschließend wird konkret auf die SOA-Governance eingegangen und es werden unterschiedliche Ansätze vorgestellt (Kapitel 3.3.2). 3.3.1

Einordnung und Abgrenzung der SOA-Governance

Allgemein wird unter Governance ein Steuerungs- und Reglungssystem zur Überwachung, Durchsetzung und Regulierung von geltenden Richtlinien, Regeln oder Gesetzen verstanden (Brown et al. 2008, S. 12). Als geeignete Mittel zur Überwachung der Umsetzung strategischer Unternehmensziele nennen Starke und Tilkov die Definition und Anwendung von Organisationsstrukturen, Rollen, Prozessen und Metriken (Starke und Tilkov 2007, S. 285). Im Unternehmensumfeld ist die Governance auf unterschiedlichen Ebenen angesiedelt, d.h. es existieren hierarchische Governance-Strukturen, die miteinander in Beziehung stehen und sich ergänzen. Die SOA-Governance wird häufig als ein Aspekt bzw. als eine Spezialisierung oder Querschnittsfunktion innerhalb der IT-Governance angesehen (BITKOM 2009, S. 61f.; Brown et al. 2008, S. 12ff.; Starke und Tilkov 2007, S. 285; Malinverno 2006, S. 4; Bloomberg 2007, S. 3; Schelp und Stutz 2007, S. 69). Die IT-Governance wiederum bildet eine Teildisziplin der Corporate Governance. Weitere Unterscheidungen bezüglich der Governance werden bspw. im Rahmen des IT-Architekturmanagements vorgenommen. Die Open Group unterscheidet in ihrem Architekturframework TOGAF Version 9 neben der Corporate und IT-Governance eine Technology und Architecture Governance (The Open Group 2009c, S. 671). Die Corporate, IT- und Architecture Governance werden im Folgenden kurz erläutert und die Beziehung zur SOA-Governance aufgezeigt. 3.3.1.1

Corporate Governance

Eine Definition der Corporate Governance geht aus dem sogenannten Cadbury Report hervor: „Corporate governance is the system by which companies are directed and controlled.” (Cadbury 1992, S. 15) Die OECD (Organisation of Economic Cooperation and Development) greift die Definition des Cadbury Reports bei der Formulierung von Corporate GovernanceGrundsätzen auf und beschreibt sie folgendermaßen: „Corporate-Governance-Praktiken gehören zu den zentralen Voraussetzungen für die Verbesserung von wirtschaftlicher Effizienz und Wachstum wie auch für die Stärkung des Anlegervertrauens. Sie betreffen das ganze Geflecht der Beziehungen zwischen dem Management eines Unternehmens, dem Aufsichtsorgan, den Aktionären und anderen Unternehmensbeteiligten (Stakeholder). Die Corporate Governance liefert auch den strukturellen Rahmen für die Festlegung der Unternehmensziele, die Identifizierung der Mittel und Wege zu ihrer Umsetzung und die Modalitäten der Erfolgskontrolle. Ein gutes Corporate-Governance-System sollte dem Aufsichtsorgan und der Unternehmensleitung die richtigen Anreize zur Verfolgung der im Interesse des Unternehmens und seiner

Governance im Kontext serviceorientierter Architekturen

75

Aktionäre liegenden Ziele geben und eine wirkungsvolle Überwachung erleichtern.“ (OECD 2004, S. 11) Folgende Charakteristika einer „guten“ Corporate Governance werden von Naidoo angeführt (Naidoo 2002, S. 157f.): x

Disziplin: Eine Verpflichtung des Senior Managements, allgemein als ordnungsgemäß und angemessen anerkannte Verhaltensregeln zu befolgen.

x

Transparenz: Erlaubt Außenstehenden die Analyse unternehmerischer Handlungen, wirtschaftlicher Grundsätze und nicht-finanzieller Aspekte in Bezug auf das Unternehmensgeschäft.

x

Unabhängigkeit: Einführung von Mechanismen zur Minimierung oder Vermeidung potenzieller Interessenkonflikte.

x

Zurechenbarkeit: Identifizierung von Individuen oder Gruppen innerhalb der Organisation, die für ihre Entscheidungen und Handlungen zur Verantwortung gezogen werden können.

x

Verantwortlichkeit: Das Board muss sich in seiner Verantwortung für das Unternehmen verantwortlich gegenüber allen Stakeholdern verhalten.

x

Gerechtigkeit: Es muss ein ausgewogenes Interessensgleichgewicht hergestellt und aufrecht erhalten werden (z.B. gegenüber Minderheiten).

x 3.3.1.2

Soziale Verantwortung: Das Unternehmen ist sich seiner sozialen Verantwortung bewusst und setzt hohe Prioritäten in Bezug auf ethische Standards. IT-Governance

Mithilfe der IT-Governance werden die weiter gefassten Grundsätze der Corporate Governance reflektiert. Der Fokus ist dabei auf das Management und die Verwendung von IT zur Erreichung der Unternehmensziele gesetzt. Weill und Ross definieren IT-Governance als „... specifying the decision rights and accountability framework to encourage desirable behaviour in using IT.“ (Weill und Ross 2004, S. 2) Im Sinne einer effektiven IT-Governance müssen die drei folgenden Fragestellungen im Mittelpunkt stehen (Weill und Ross 2004, S. 10): x

Welche Entscheidungen müssen getroffen werden, um ein effektives Management und eine effektive Verwendung von IT sicherzustellen?

x

Wer sollte diese Entscheidungen treffen?

x

Wie werden diese Entscheidungen getroffen und überwacht?

Zu den Schlüsselentscheidungen der IT-Governance zählen nach Weill und Ross Entscheidungen in Bezug auf IT-Grundsätze, IT-Architektur, IT-Infrastruktur, Geschäftsanforderungen sowie IT-Investitionen und IT-Priorisierungen (Weill und Ross 2004, S. 27).

76

Serviceorientierte Architekturen

Das IT Governance Institute (ITGI) macht mit seiner Definition die Bedeutung der ITGovernance als Führungsaufgabe deutlich: „IT-Governance liegt in der Verantwortung des Vorstands und des Managements und ist ein wesentlicher Bestandteil der Unternehmensführung. IT-Governance besteht aus Führung, Organisationsstrukturen und Prozessen, die sicherstellen, dass die IT die Unternehmensstrategie und -ziele unterstützt.“ (IT Governance Institute 2003, S. 11) Das von der ITGI entwickelte COBIT-Modell (Control Objectives for Information and Related Technology) stellt IT-Verantwortlichen ein Framework und Werkzeug zur Überwachung der IT und somit zur Unterstützung der Geschäftsziele in Einklang mit den IT-Zielen zur Verfügung. COBIT ist prozessorientiert und definiert IT-Aktivitäten in einem generischen Prozessmodell, das in vier Domänen mit 34 Prozessen unterteilt ist. Abbildung 27 zeigt eine Übersicht des COBIT-Frameworks. Unter Berücksichtigung der in COBIT adressierten IT-Governance-Domänen liefern Fröhlich und Glasner eine weitere Definition für IT-Governance: „IT Governance umfasst prinzipielle Regelungen zu Entscheidungsrechten, Rollen und Verantwortlichkeiten sowie zur Organisation der IT, die sich jeweils auf die Domänen Strategic Alignment, Value Delivery, Resource Management, Risk Management und Performance Measurement beziehen.“ (Fröhlich und Glasner 2007, S. 29) Neben COBIT hat sich in der Praxis vor allem der von der OGC entwickelte ITIL-Standard als IT-Governance-Ansatz durchgesetzt und verbreitet. Im Gegensatz zu COBIT liegt der Fokus von ITIL aber weniger auf der Überwachung der IT, sondern vielmehr auf dem ITService-Management. Mithilfe einer Sammlung von Best Practices werden notwendige Prozesse zum Betrieb einer IT-Infrastruktur und zur Leistungserbringung der IT im Unternehmen identifiziert und beschrieben. Für eine tiefere Auseinandersetzung mit der IT-Governance-Thematik sei an dieser Stelle auf die Arbeiten (Weill und Ross 2004; Fröhlich und Glasner 2007; Rüter et al. 2006; Johannsen und Goeken 2007) und die Webseiten der Information Systems Audit and Control Association23, des IT Governance Institute24 sowie des Office of Government Commerce25 verwiesen.

23 24 25

Siehe http://www.isaca.org Siehe http://www.itig.org Siehe http://www.itil-officialsite.com

Governance G im Konntext serviceorientierter Architekturenn

Abbildung A 27: Übeersicht des COBIT T-Frameworks Quelle: Q (IT Governaance Institute 2009, S. 26)

777

78 7

Serviceorienttierte Architekturenn

3.3.1.3 3

Archhitecture Governnance

Die D Architecturee Governance unterstützt das un nternehmensweite Managemennt und die Über-wachung w von Unnternehmensarchhitekturen und anderen a Architeekturen. Sie umffasst die folgen-den d Punkte (Thee Open Group 20009c, S. 674): x

Einrichtuung eines System ms zur Überwacchung der Erstelllung und des Monitorings M allerr Architektturkomponentenn und -aktivitätten sowie zur Sicherstellung S e einer effektivenn Einführuung, Umsetzung und Evolution von Architektuuren innerhalb einer Organisati-on.

x

ms, das die Einhaltung internerr und externer Standards S sowiee Einrichtuung eines System geltenderr Verpflichtungeen sicherstellt.

x

Einrichtuung von Prozessen, die ein efffektives Manageement im Rahm men festgelegterr Einflussggrößen unterstüttzt.

x

Entwickllung von Praktikken, die eine Zuurechenbarkeit zu z klar definierteen Stakeholdernn oder Gruuppen innerhalb und außerhalb einer e Organisatioon sicherstellen.

Abbildung A 28: Kon nzeptionelle Struk ktur des Architectu ure Governance Frameworks F der Open O Group Quelle: Q (The Open G Group 2009c, S. 6776)

Zur Z Unterstützunng der Architecture Governance hat die Open Group ein Archhitecture Gover-nance n Frameworrk definiert, das zur Identifizierrung der notwenndigen Prozesse und Organisati--

Governance im Kontext serviceorientierter Architekturen

79

onsstrukturen beiträgt und die damit verbundenen Verantwortlichkeiten wirksam erläutert, kommuniziert und verwaltet. Abbildung 28 zeigt eine Übersicht der konzeptionellen Struktur des Architecture Governance Frameworks. 3.3.1.4

SOA-Governance

Wie bereits erwähnt, wird die SOA-Governance häufig als ein Aspekt bzw. eine Spezialisierung der IT-Governance angesehen. In Wissenschaft und Praxis existiert keine einheitliche Definition für SOA-Governance. Es wird vielmehr auf Definitionen der IT-Governance oder der Architecture Governance zurückgegriffen und in diesem Zusammenhang der spezielle Charakter der SOA-Governance beschrieben. Nach Biske ist SOA-Governance „[...] the combination of people, policies, and processes within your organization that will ensure that the desired behaviors of your strategic SOA initiative are achieved. It includes the traditional areas associated with IT Governance, which is the selection and funding of IT projects.“ (Biske 2008, S. 16f.) Auch Brown et al. verstehen SOA-Governance als eine Erweiterung der IT-Governance, wenn der Grad der Serviceorientierung im Unternehmen steigt. Dies betrifft vor allem die Zuweisung von Entscheidungsbefugnissen, Policies und Messwerten im Zusammenhang mit Services, Prozessen und ihrem Lebenszyklus. SOA-Governance fokussiert daher insbesondere den Lebenszyklus von Services, Metadaten und Composite Applications in einer serviceorientierten Architektur (Brown et al. 2008, S. 17f.). Malinverno‘s Beschreibung fällt ähnlich aus. Er sieht die Aufgabe der SOA-Governance innerhalb eines IT-Governance-Frameworks in der Identifikation von Entscheidungsbefugnissen, die bspw. für die Definition und Modifikation von SOA-basierten Geschäftsprozessen, erforderlichen Service Levels, Anforderungen an die Service Performance oder Zugriffsrechten notwendig sind (Malinverno 2006, S. 4). Ein weiterer Aufgabenbereich der SOAGovernance ist es, festzulegen, wie wiederverwendbare Services definiert, entworfen, aufgerufen, ausgeführt und gewartet werden. Auch Kohnke et al. sehen IT-Governance-Ansätze als Ausgangsbasis für den Aufbau einer SOA-Governance. Gleichzeitig sprechen sie jedoch die Grenzen der IT-Governance im SOAUmfeld an (Kohnke et al. 2008, S. 408f.). So ist die IT-Governance bspw. stark auf Bereiche der IT-Abteilungen und die IT-Infrastruktur fokussiert, während die SOA-Governance unternehmensweite Services in den Mittelpunkt setzt. Zudem erfordert SOA ein hohes Wissen über Geschäftsprozesse, wodurch die Fachbereiche stärker eingebunden und auch innerhalb der Fachbereiche neue Rollen definiert werden müssen. Bei der IT-Governance liegt der Schwerpunkt jedoch mehr auf der IT-Leistungserstellung als auf Geschäftsprozessen. Nach Marks und Bell bezieht sich die SOA-Governance auf die Organisation, Prozesse, Richtlinien und Metriken, die für ein erfolgreiches Management einer SOA notwendig sind

80 8

Serviceorienttierte Architekturenn

(Marks und Belll 2006, S. 248). Die Aufgabenn der SOA-Goveernance sehen sie s vor allem inn (Marks und Belll 2006, S. 248f.): x

Schaffunng einer Gesamtüübersicht und eiines übergreifennden Managemennts der SOA.

x

Definitioon von Architektturstandards, En ntwicklungsrichhtlinien und spezzifischen Polici--

x

Bestimm mung von Service-Verantwortliichkeiten (Budggetierung von Prozessen, P Ver-antwortuung für Wartung, Infrastrukturm management, etc..) innerhalb der Organisation.

x

Definitioon der Service-E Entwicklung und d des Lebenszykklusmanagementts.

es, die übber den gesamteen Service-Lebennszyklus durchggesetzt werden.

Bloomberg B verssteht SOA-Govvernance im en ngeren Sinne als a eine Anweendung der IT-Governance G in B Bezug auf die Governance G von SOA-Initiativenn (Bloomberg 2007, 2 S. 11). Im m weiteren w Sinne hingegen positiioniert die SOA A-Governance sowohl s die IT-Governance alss auch a die Architeecture Governaance im Kontext von serviceorrientierten Archhitekturen (siehee Abbildung A 29).

Abbildung A 29: Bezziehungen der unteerschiedlichen Goovernance-Ebenen n Quelle: Q (Bloombergg 2007, S. 12)

Bloombergs B Einnschätzung zu Folge werden die Architecturre Governance und die SOA-Governance G jedooch zu einem serviceorientierteen Ansatz der Architecture A Goovernance inein-ander a übergehenn (siehe Abbilduung 30), je meh hr sich SOA-Beest Practices als Standardansatzz für f die Organisattion von IT-Resssourcen durchseetzen (Bloomberg 2007, S. 12).

Governance G im Konntext serviceorientierter Architekturenn

811

Abbildung A 30: Verreinigung der Arch hitecture und SOA A-Governance Quelle: Q (Bloombergg 2007, S. 12)

In der OASIS R Reference Archittecture Foundatiion for SOA (Esstefan et al. 20009, S. 91f.) wirdd die d SOA-Governnance auf einer Ebene E mit der IT T-Governance und u anderen Govvernance-Typenn betrachtet, b zwiscchen denen Abhhängigkeiten beestehen und die untereinander koordiniert k wer-den d müssen (siehhe Abbildung 31). Alle Govern nance-Typen follgen dabei allgeemeinen überge-ordneten o Governnance-Prinzipienn, besitzen aber jeder für sich spezielle s Aufgabbenbereiche undd Verantwortlichk V keiten. Bezüglichh der SOA-Gov vernance werdeen drei Kernbereeiche betrachtett (Estefan et al. 20009, S. 92): x

SOA Infrrastructure: Hilffsmittel, mit denen die Verwenndung von Servvices ermöglichtt und unterrstützt wird.

x

SOA Inveentory: Anfordeerungen an einen n Service, die es erlauben, inneerhalb der Infra-struktur aauf ihn zuzugreiifen.

x

Participaant Interaction: Konsistente Erw wartungen, dennen alle Beteiliggten entsprechenn müssen.

Abbildung A 31: Bezziehung unterschieedlicher Governan nce-Typen Quelle: Q (Estefan et aal. 2009, S. 92)

82

Serviceorientierte Architekturen

Zusammenfassend lässt sich festhalten, dass die SOA-Governance spezielle Aspekte zur Steuerung und Überwachung einer SOA im Unternehmen mit Ausrichtung auf die Unternehmensziele fokussiert und die Corporate und IT-Governance dementsprechend erweitert. Zudem herrscht ein allgemeiner Konsens darüber, dass die SOA-Governance für den erfolgreichen Betrieb und das Management einer serviceorientierten Architektur essenziell ist. Zu den übergeordneten Zielen einer SOA-Governance zählen in Anlehnung an Arbeiten unterschiedlicher Autoren: x

Schaffung neuer SOA-spezifischer Kompetenzen und Strukturen in den IT- und Fachabteilungen durch veränderte Rollen, Aufgaben und Entscheidungsprozesse, die die Transparenz und Konformität serviceorientierter Architekturen sicherstellen (Schelp und Stutz 2007, S. 69; Kohnke et al. 2008, S. 410).

x

Verbesserung des Business-IT-Alignments durch Vermeidung klassischer Interessenskonflikte zwischen IT und Fachbereichen und eine durchgängige Prozessunterstützung (Starke und Tilkov 2007, S. 285; Bloomberg 2007, S. 8; Kohnke et al. 2008, S. 409f.).

x

Beherrschung der Komplexität und Evolution einer serviceorientierten Architektur (Schelp und Stutz 2007, S. 66 u. 69; Kohnke et al. 2008, S. 409).

x

Überwachung und Optimierung von SOA-Initiativen unter Berücksichtigung von Wertschöpfungsaspekten und wirtschaftlichem Nutzen (BITKOM 2009, S. 61; Starke und Tilkov 2007, S. 285; Bloomberg 2007, S. 8).

x

Unterstützung des gesamten Service-Lebenszyklus (Estefan et al. 2009, S. 91; BITKOM 2009, S. 62; Starke und Tilkov 2007, S. 285; Marks und Bell 2006, S. 248).

3.3.2

SOA-Governance-Ansätze

Im Bereich der SOA-Governance existieren verschiedene Auffassungen über die Konzeption von SOA-Governance-Ansätzen und deren konkrete Umsetzung in der Praxis. Dies spiegelt sich insbesondere in der Terminologie, den Strukturen, der Ausrichtung und dem Umfang einzelner Modelle oder Frameworks wider, mit denen die grundsätzlichen Fragestellungen der Governance nach dem Was, Wer und Wie in Bezug auf serviceorientierte Architekturen beantwortet werden sollen. So fassen bspw. Kohnke et al. strukturelle, prozessuale und mitarbeiterbezogene Handlungsfelder zu einem SOA-Governance-Modell zusammen (Kohnke et al. 2008, S. 410). Schelp und Stutz stellen in ihrem SOA-Governance-Modell SOA-Management-Aktivitäten SOAspezifischen Organisationsstrukturen gegenüber (siehe Abbildung 32), um Abhängigkeiten identifizieren und Zuständigkeiten und Kompetenzen der SOA-spezifischen Rollen und Aktivitäten eindeutig und transparent festlegen zu können (Schelp und Stutz 2007, S. 69ff.).

Governance im Kontext serviceorientierter Architekturen

83

SOA Governance Model SOA Management Activities

SOA Organizationa l Structure

Implement SOA

SOA Strategy

-SOA Enablement

-Strateg y, Roadmap

-SOA Portfolio Management

-Principles&Guideline s,

-SOA Service Design

Standards, Rules

-SOA Service Build

SOA Organizational Structure

Manage SOA

-SOA Organization

-SOA Repository

-SOA Roles

-SOA Maintenance

-SOA Matrix of Competencie s and

-SOA Funding

Responsabilities

Control SOA SOA OperationalStructure

-SOA Controlling -SOA Service Level Management

-SOA Processes

-SOA Qualit y Management

-SOA Lifecycle

-SOA Risk&Securit y Management What?

How?

Who?

Abbildung 32: SOA Governance Model Quelle: (Schelp und Stutz 2007, S. 70)

Andere Autoren liefern weit umfangreichere SOA-Governance-Ansätze und -Modelle, die die Definition und Einführung von Policies, Organisationstrukturen, Aufgaben, Zuständigkeiten und Prozessen sowie die daraus resultierenden Abhängigkeiten behandeln (Brown et al. 2008; Rosen et al. 2008, S. 449ff.; Marks und Bell 2006, S. 243ff.; Biske 2008). Zudem besitzen diese Ansätze durch ihre Ausrichtung auf Phasen des SOA-Lebenszyklus oder durch die Definition eigener Governance-Lebenszyklusmodelle einen sehr operativen Charakter, um die Planung, Einführung und den Betrieb der SOA-Governance zu unterstützen. Auf eine detaillierte Ausarbeitung der Unterschiede und Gemeinsamkeiten der Ansätze wird in dieser Arbeit verzichtet, da es für die Entwicklung des Konzepts ausreichend ist, darzustellen, dass mit der SOA-Governance die notwendigen Rahmenbedingungen zur Steuerung und Überwachung einer serviceorientierten Architektur geschaffen werden können. Aus diesem Grund wird stellvertretend für andere Ansätze nur noch kurz auf den Ansatz von Brown et al. (Brown et al. 2008) eingegangen, der ein umfassendes Framework für die Definition, das Design und die Umsetzung einer SOA-Governance darstellt. Für eine Vertiefung der einzelnen Ansätze sei auch an dieser Stelle wieder auf die zuvor genannten weiterführenden Referenzen verwiesen.

84 8

Serviceorienttierte Architekturenn

Abbildung A 33: SOA A Governance and d Management Model Quelle: Q (Brown et aal. 2008, S. 26)

Abbildung A 33 zzeigt die Kernkkomponenten dees SOA Governnance and Management Modell (SGMM). Es bildet einerseits die d vier grundleegenden Governnance-Prozesse ab, andererseitss die d „governed“ Prozesse, P die im m Service-Leben nszyklus gesteuuert und verwalttet werden müs-sen. s Die vier gruundlegenden Goovernance-Prozeesse sind: Complliance, Communnication, Excep-tion/Appeals undd Vitality. Wähhrend die governned Prozesse errstellt oder moddifiziert werden,, werden w Metrikenn und Messpunkkte identifiziert sowie Zeitpunktte der Evaluieruung von Policiess und u Standards zuur Feststellung ihrer i Einhaltungg bzw. Nicht-Einnhaltung festgeleegt. Das Modelll wird w mit entspreechenden Mechhanismen umgessetzt und von einer e Organisationsstruktur, diee mit m den notwenddigen Kompetennzen ausgestattett ist, ausgeführt.. Zur Z Einführung einer SOA-Goovernance sowie zur Messungg und Verbesserrung der SOA-Governance-Pro G zesse schlagen Brown et al. einen Vier-Phasenn-Lebenszykluss vor (siehe Ab-bildung b 34), bei dem jede Phasee iterativ durchlaaufen und wiedeerholt wird und somit die Mög-lichkeit besteht, auf Basis von Rückkopplungeen eine Verbesserung der Prozeesse zu erzielenn (Brown et al. 2008, S. 219ff.).

SOA-Rollen S

855

Abbildung A 34: SOA A-Governance-Leebenszyklus Quelle: Q (Brown et aal. 2008, S. 221)

3.4 3

SOA-Roollen

Die D SOA-Goverrnance-Thematikk zeigt, dass durch d die Einfühhrung einer serrviceorientiertenn Architektur A orgaanisatorische Veränderungen V i Unternehmenn notwendig siind. So müssenn in bspw. b neue Kom mpetenzen aufgeebaut, Rollen, Verantwortlichke V eiten und Zustäändigkeiten fest-gelegt g und die Schnittstellen sowie s die Kom mmunikationswegge zwischen orrganisatorischenn Einheiten E integriiert oder neu deffiniert werden. Im Kontext der SOA-Governannce und im Zussammenhang miit den organisattorischen Ände-rungen r sehen Scchelp und Stutz eine Notwendig gkeit darin, SOA A-spezifische Rollen R und Akti-vitäten v einheitlicch festzulegen und deren Zusttändigkeiten unnd Kompetenzenn eindeutig undd trransparent zu ddefinieren (Scheelp und Stutz 20007, S. 71). Wiie die folgendenn Ausführungenn zeigen z werden, existiert in Wisssenschaft und Praxis jedoch kein k Konsens über ü einheitlichee Rollendefinition R nen bzw. eine Sttandardisierung SOA-spezifischher Rollen und Aktivitäten. A Fer-ner n ist auch die Bildung von Gremien G bei der Etablierung einner SOA-Governnance nicht ein-heitlich h definierrt. Die Arbeitenn und Ansätze reichen r von einnfachen Rollenbbeschreibungen,, über ü Rollendefinnitionen, bis hin zu umfangreiichen Rollenmoodellen oder SO OA-spezifischenn Organisationsstr O rukturen (z.B. (S Strnadl 2007; Bieberstein et al. 2005; 2 Brown et al. 2008; Rosenn

86

Serviceorientierte Architekturen

et al. 2008; Erl 2007; Allen 2006; Biske 2008; Balzer 2004; Tilkov 2007; Kajko-Mattsson et al. 2007)). Nachfolgend werden exemplarisch die Arbeiten von Kajko-Mattson et al. (Kajko-Mattsson et al. 2007), Bieberstein et al. (Bieberstein et al. 2005) und Erl (Erl 2007) vorgestellt und ein Überblick über die beschriebenen Rollen gegeben. Die drei Arbeiten stellen eine umfangreiche Beschreibung SOA-spezifischer Rollen zur Verfügung, zeigen aber zugleich stellvertretend für alle genannten Ansätze die Unterschiede bezüglich des Abstraktionsniveaus und der Vollständigkeit bzw. Unvollständigkeit, die aus den jeweiligen Perspektiven (z.B. in Bezug auf Prozesse, Strukturen oder Methoden) und den darin betrachteten Aspekten resultieren. 3.4.1

Rollen-Framework nach Kajko-Mattson et al.

Kajko-Mattson et al. stellen ein Rollen-Framework für die Entwicklung, Evolution und Wartung SOA-basierter Systeme vor (Kajko-Mattsson et al. 2007). Der Schwerpunkt liegt auf der Identifikation SOA-spezifischer Rollen, die für das Management serviceorientierter Architekturen notwendig sind. Den Ausgangspunkt für die Definition SOA-spezifischer Rollen bilden zum einen traditionelle Rollen und zum anderen die Identifikation von Auswirkungen SOA-basierter Systeme auf bestehende Entwicklungs-, Evolutions- und Wartungsprozesse. Als Herausforderungen und Aufgaben bezüglich einer SOA-Infrastruktur werden u.a. die Auswahl von Standards und Produkten, die Bereitstellung von Infrastrukturservices sowie die Dokumentation und der Support genannt. Die Anwendungsentwicklung ist auf ein einheitliches und transparentes Verständnis der Infrastruktur zur Ermittlung, Komposition und Verwendung von Services angewiesen. Dies gilt ebenso für die Service Provider, die zudem die Anforderungen potenzieller Service-Nutzer verstehen müssen, um Services angemessen beschreiben und publizieren sowie eine akzeptable Quality of Service (QoS) sicherstellen zu können. Das Rollen-Framework stellt unter Berücksichtigung der Eigenschaften, Aufgaben und Herausforderungen serviceorientierter Systeme eine erweiterbare Menge identifizierter Rollen bereit, die in vier übergeordnete Gruppenkategorien und weitere Untergruppierungen eingeteilt wurden. Abbildung 35 zeigt eine Übersicht der Gruppen und Untergruppen sowie der zugeordneten Rollen, die nachfolgend kurz erläutert und in Anlehnung an (Kajko-Mattsson et al. 2007) tabellarisch zusammengefasst werden.

SOA-Rollen S

877

Abbildung A 35: Gru uppen und Rollen nach Kajko-Matttson et al. Quelle: Q (Kajko-Matttsson et al. 2007)

Die D Gruppe SOA A Support leisteet Unterstützung g für die bereitggestellten SOA-bbasierten Syste-me. m Sie ist in diee weiteren Ebennen SOA Front-E End Support, SO OA Back-End Suupport und Tra-ditional d Back-Ennd Support unteerteilt, die für daas Problem-Repoorting und die Bearbeitung B vonn Änderungsanträg Ä gen zuständig siind. Tabelle 5 faasst die Rollen dieser d Gruppe zuusammen.

88

Serviceorientierte Architekturen SOA Front-End Support

Rolle

Beschreibung/Zuständigkeiten

Support Personell

o

Support von Kunden bei operativen Geschäftsprozessen

o

Annahme von Problemberichten und Änderungsanträgen in Bezug auf Geschäftsprozesse

o

Eskalation und Monitoring von Problem- und Änderungsberichten

Business Process Support Engineer

o

Bestätigung gemeldeter Probleme bei Geschäftsprozessen

o

Identifikation von Workarounds

o

Eskalation und Monitoring von Problem- und Änderungsberichten

Rolle

Beschreibung/Zuständigkeiten

Business Process Assistant

o

Erstanalyse eingehender Problemberichte und Änderungsanträge

o

Zuweisung von Anträgen an Implementierungs-Teams

Business Process Manager

o

Management der Geschäftsprozessteams

o

Analyse der Problemberichte und Änderungsanträge

o

Validierung notwendiger Änderungen mit der SOA Design-Gruppe

SOA Back-End Support

Service Developer

o

Zuweisung von Entwicklungs-, Wartungs- und Evolutionsaktivitäten

o

Entwicklung von Services, Wartungs- und Evolutionsaktivitäten Traditional Back-End Support

Rolle

Beschreibung/Zuständigkeiten

Interface Developer

o

Design der Schnittstellen zu vorhandenen Systemen

o

Implementierung und Test der Schnittstellen

Tabelle 5: Rollen der Gruppe SOA Support Quelle: In Anlehnung an (Kajko-Mattsson et al. 2007)

Die Gruppe SOA Strategy and Governance ist zur Erfüllung der SOA-Gesamtstrategie für das Management und die Governance der SOA-basierten Systeme verantwortlich. Sie muss daher sicherstellen, dass die Geschäftsanforderungen auf strategischer, taktischer und operativer Ebene erfüllt werden. Zudem besitzt die Gruppe die Verantwortung und Befugnis, Geschäftsprozesse unternehmensweit zu priorisieren. Tabelle 6 fasst die Rollen dieser Gruppe zusammen.

SOA-Rollen

89 SOA Strategy and Governance

Rolle

Beschreibung/Zuständigkeiten

SOA Strategy Manager

o

Erstellung und Entwicklung der SOA-Unternehmensstrategie zur Unterstützung der Geschäftsanforderungen

SOA Governance Manager

o

Erstellung und Entwicklung von Richtlinien und Verfahren für die Entwurfszeitund Laufzeit-Governance

SOA Process Manager

o

Erstellung und Entwicklung der Entwicklungs-, Wartungs- und Evolutionsprozesse

SOA Measurement Manager

o

Definition prozessübergreifender Messverfahren und -Modelle für Entwicklungs-, Wartungs- und Evolutionsprozesse

o

Monitoring und Steuerung der Messverfahren

o

Rückmeldung an andere Organisationsmitglieder

SOA Security Manager

o

Erstellung, Monitoring und Steuerung von Sicherheitsrichtlinien und strategische Pläne für alle SOA-basierten Systeme

SOA Technology Scout

o

Vorgabe technischer Weisungen für die SOA-Implementierung

o

Förderung einer effektiven Einführung von Produkten, Standards und Prozessen

o

Einschätzung technologischer Trends

Tabelle 6: Rollen der Gruppe SOA Strategy and Governance Quelle: In Anlehnung an (Kajko-Mattsson et al. 2007)

Die Gruppe SOA Design and Quality Management ist verantwortlich für die Modellierung und Architektur von Geschäftsprozessen, die Integration von Geschäftsprozessen zusammen mit der Sicherstellung der Interoperabilität und Qualität, das Service Repository Management und die Administration von SOA-basierten System-Releases. Tabelle 7 und Tabelle 8 fassen die Rollen dieser Gruppe zusammen. SOA Design Rolle

Beschreibung/Zuständigkeiten

Business Process Architect

o

Entwurf der Geschäftsprozessarchitektur und ihrer Komponenten

o

Entscheidungsbefugnis bei wichtigen Architekturänderungen an Geschäftsprozessen

o

Analyse von Geschäftsanforderungen und Transformation in Architekturkomponenten

Business Process Orchestrator

o

Modellierung und Orchestrierung von Geschäftsprozessen

Service Designer

o

Entwurf von Services

o

Zuordnung von Services und Geschäftsprozessen

Tabelle 7: Rollen der Gruppe SOA Design and Quality Management (Teil 1) Quelle: In Anlehnung an (Kajko-Mattsson et al. 2007)

90

Serviceorientierte Architekturen SOA Quality Assurance

Rolle

Beschreibung/Zuständigkeiten

Business Process Integrator

o

Integration von Geschäftsprozesskomponenten und Sicherstellung ihrer Interoperabilität

Business Process Tester

o

Test der Geschäftsprozesse

o

Validierung der funktionalen und nicht-funktionalen Anforderungen

Rolle

Beschreibung/Zuständigkeiten

Service Librarian

o

Verantwortung für das Service Repository

o

Sicherstellung der ordnungsgemäßen Veröffentlichung und Pflege von Servicedaten

o

Kontrolle über Releases und Dokumentation der SOA-Infrastruktur und der verfügbaren Services

SOA Administration

Release Manager

Tabelle 8: Rollen der Gruppe SOA Design and Quality Management (Teil 2) Quelle: In Anlehnung an (Kajko-Mattsson et al. 2007)

Die Gruppe SOA Development and Evolution ist verantwortlich für wichtige Entwicklungen und Änderungen, die von kleinen Teams nicht bewältigt werden können, sondern eine Projektorganisation erfordern. Tabelle 9 fasst die Rollen dieser Gruppe zusammen. SOA Development und Evolution Rolle

Beschreibung/Zuständigkeiten

SOA Project Manager

o

Management und Monitoring von Projekten

o

Definition und Umsetzung von Projektplänen

SOA Project Member

o

Projektteilnehmer mit unterschiedlichen Rollen

Tabelle 9: Rollen der Gruppe SOA Development and Evolution Quelle: In Anlehnung an (Kajko-Mattsson et al. 2007)

3.4.2

Rollen nach Bieberstein et al.

Die Schaffung einer adäquaten Organisationsstruktur ist nach Bieberstein et al. eine der kritischen Herausforderungen bei der Umsetzung einer serviceorientierten Architektur (Bieberstein et al. 2005, S. 64). Während Unternehmen mit wenig Erfahrung im SOA-Bereich starken Widerständen gegenüber Veränderungen ausgesetzt sind und dadurch die Geschäftstransformation nur schwer an den Geschäftsanforderungen ausgerichtet werden kann, gelingt es erfahrenen Unternehmen hingegen über Geschäftsbereiche und Rollengrenzen hinaus eine interdisziplinäre Koordination zu etablieren. Bieberstein et al. wählen zur Beschreibung von Zuständigkeiten und den benötigten Kompetenzen das Rollenkonzept, da Rollen den Entwicklungsphasen bei der Projektdurchführung

SOA-Rollen

91

zugeordnet sind und im Gegensatz zu einzelnen Stellenbeschreibungen einen höheren Abstraktionsgrad besitzen (Bieberstein et al. 2005, S. 76). In ihrem Modell unterscheiden sie zwischen bereits vorhandenen Rollen und neuen SOAspezifischen Rollen. Die existierenden Rollen (siehe Tabelle 10) wurden dabei um SOAspezifische Aspekte erweitert, die neuen Rollen (siehe Tabelle 11) hingegen im Rahmen von SOA-Projekten identifiziert. Existierende Rollen Rolle

Beschreibung/Zuständigkeiten

IT Project Manager

o

Management- und Führungsverantwortung für das Projektteam

o

Definition und Tracking von Projektplänen

o

Festlegen der Projektstrukturpläne

o

Sammlung funktionaler Anforderungen von Geschäftsnutzern

o

Bereitstellen von Domänenwissen für das Projektteam

Architect

o

Entwicklung der logischen und physikalischen Struktur der Gesamtlösung und ihrer Komponenten

Developer

o

Entwicklung und Testen der Software

Security Specialist

o

Definition und Implementierung von Sicherheitsrichtlinien

System and Database Administrator

o

Installation und Wartung der technischen Infrastruktur

Service Deployer

o

Installation der Entwicklungsartefakte

o

Generierung von Stubs und Skeletons für die Zielumgebung aus WSDL und Installation mit der Serviceimplementierung

o

Mapping und Handler-Konfiguration durch servicespezifische DeploymentDeskriptoren

Service Integration Tester (Quality Assurance)

o

Durchführung verschiedener Teststufen (Integrations-, Belastungs- und Akzeptanztests)

o

Definition von Testfällen für die Interoperabilität und Konformität von Services

Toolsmith

o

Entwurf und Implementierung projektspezifischer Skripte, Generatoren und anderer Hilfsmittel

Knowledge Transfer Faciliator

o

Schnittstelle zu Fachexperten und technischen Ausbildern

SOA Project Manager

o

Planung kurzer Entwicklungszyklen

o

Schaffung neuer Akzeptanzmodelle

o

Ermittlung angemessener Service-Level-Agreements (SLA)

o

Verwaltung und Monitoring der Plattforminfrastruktur

o

Management der Geschäfts- und Service-Level-Agreements innerhalb der SOA

Business Analyst

SOA System Administrator

Tabelle 10: Existierende Rollen mit SOA-spezifischen Verantwortlichkeiten Quelle: In Anlehnung an (Bieberstein et al. 2005, S. 78f.)

92

Serviceorientierte Architekturen Neue SOA-Rollen

Rolle

Beschreibung/Zuständigkeiten

SOA Architect

o

Mediator zwischen Geschäfts- und IT-Welt

o

Transformation von Ideen und Konzepten des Geschäftsbetriebs in Begriffe und Konzepte der IT-Infrastruktur

o

Durchgängiger Entwurf der Service-Requester und -Provider

o

Untersuchung und Darstellung nicht-funktionaler Service-Anforderungen

Service Modeler or Designer

o

Definition von Service-Schnittstellenverträgen und Nachrichten-Schemata

Process Flow Designer

o

Untersuchung von Möglichkeiten expliziter, deklarativer Serviceorchestrierungen (Aggregationen, Kompositionen)

o

Fokus liegt auf der technischen Beschreibung von Prozessflüssen zur Unterstützung der Geschäftsprozesse

o

Entwicklung der Service-Schnittstellen und -Implementierung auf Seite des Providers

o

Entwicklung von Service-Aufrufcode auf Seite des Requesters

o

Vermittlung zwischen Service-Modeler und Process-Flow-Designer

o

Breite Basis an technischem Wissen im Bereich der Anwendungsintegration, der SOA-Systeme, der Geschäftsprozesse und der Anwendungsentwicklung

o

Komposition komplexer Systeme aus verfügbaren Services

o

Verifikation der einwandfreien Zusammenarbeit zwischen allen entwickelten Provider- und Requester-Implementierungen

o

Sicherstellung der Konformität von Service-Interoperabilität mit bestehenden Industriestandards

UDDI Administrator

o

Definition des Customizings generischer UDDI-Datenmodelle

UDDI Designer

o

Planung, Entwurf und Aufbau einer UDDI-Registry zur Veröffentlichung von Services

Service Governor

o

Validierung und Auswahl geeigneter Geschäftsservices für das Unternehmen

o

Identifikation der Service-Owner

Service Developer

Integration Specialist

Interoperability Tester

Tabelle 11: Neue SOA-spezifische Rollen Quelle: In Anlehnung an (Bieberstein et al. 2005, S. 80f.)

3.4.3

SOA-spezifische Rollen nach Erl

Erl sieht die Notwendigkeit neuer SOA-spezifischer Rollen durch die verschiedenen Anforderungen der Auslieferung, Bereitstellung und Wartung von Services, Service Inventories und Service Implementierungen auf Basis serviceorientierter Technologien begründet (Erl 2007, S. 488f.). Wie auch bei Bieberstein et al. (Bieberstein et al. 2005) sind die von Erl beschriebenen Rollen verschiedenen Entwicklungsphasen zugeordnet, wobei sich die Phasen bei Erl speziell auf den Lebenszyklus von Services beziehen (siehe Abbildung 36).

SOA-Rollen S

933

Abbildung A 36: Rolllen im Lebenszyk klus von Services Quelle: Q (Erl 2007, S S. 490)

Des D Weiteren istt der Fokus bei der Rollenbesch hreibung auf diee von Erl vorgesstellten Service-entwurfsprinzipi e ien (Erl 2007) gerichtet, durchh deren Anwenndung Organisaationsstrukturen,, Projektlebenszyk P klen und Prozeesse sowie die damit verbundeenen Verantworrtlichkeiten undd Prioritäten P beeinnflusst werden. Die D Beschreibun ng ist daher nur auf Rollen bescchränkt, die sichh speziell s auf die Anwendung seerviceorientierteer Entwurfsprinzzipien beziehenn. In Tabelle 122 werden w die von Erl identifiziertten Rollen und ihre Zuständigkkeiten zusammennfassend darge-stellt. s

94

Serviceorientierte Architekturen

Rolle

Beschreibung/Zuständigkeiten

Service Analyst

o

Definition von Servicekandidaten, Servicefähigkeitskandidaten und Servicekompositionskandidaten

o

Koordination und Führung von Architekten und Business-Analysten im serviceorientierten Analyseprozess

o

Technischer Service-Entwurf unter Berücksichtigung von Servicekandidaten

o

Ausarbeitung und Verwendung von Designstandards und -konventionen

o

Bereitstellung von Serviceverträgen und Entwurf von Servicelogik

o

Verantwortung der Governance für einen oder mehrere spezifische Services

o

Erweiterung und Wartung der Servicelogik

o

Schutz der Integrität des Servicekontexts und der zugehörigen Funktionsgrenzen (z.B. bei Anforderungskonflikten)

o

Veröffentlichung bzw. Verbergung von Informationen über Serviceentwürfe

o

Dokumentation von Service-Profilen

o

Verantwortung der Governance von Umgebungen, in denen Services als Web Services bereitgestellt werden

o

Erstellung und Standardisierung von Schemata

o

Anpassung und Erweiterung vorhandener Schemata auf Basis neuer Geschäftsanforderungen

o

Positionierung der Schemata als standardisierte und zentralisierte Teile von Service Inventories

o

Policy-Management

o

Definition und Wartung von Policies für Web Service-Verträge

o

Installation, Administration und Wartung von Service Registries innerhalb der SOA-Infrastruktur

o

Qualitätssicherung der Registry-Inhalte (Standards und Konventionen für Metadaten)

Technical Communications Specialist

o

Verfeinerung initialer Serviceprofilentwürfe und der zugehörigen Metadaten

o

Verantwortung für ein standardisiertes Vokabular im Rahmen der technischen Kommunikation

Enterprise Architect

o

Verfassen und Bereitstellen von Unternehmensdesignstandards

o

Festlegung der erforderlichen Infrastruktur

o

Evaluation von Sicherheitsrisiken bei individuellen Einsatzmöglichkeiten von Services

o

Definition von Service Inventory Blueprints

o

Definition und Verwaltung domänenspezifischer Service Inventories

o

Verantwortung für die Evolution und Durchsetzung von Entwurfstandards

o

Durchführung von Audits bei Lösungsvorschlägen von Serviceentwürfen

Service Architect

Service Custodian

Schema Custodian

Policy Custodian

Service Registry Custodian

Enterprise Design Standards Custodian

Tabelle 12: SOA-spezifische Rollen nach Erl Quelle: In Anlehnung an (Erl 2007, S. 491ff.)

Zusammenfassung

3.5

95

Zusammenfassung

In den vorangegangenen Kapiteln wurden zunächst die Grundlagen serviceorientierter Architekturen behandelt. Dabei wurden die Vorteile serviceorientierter Architekturen dargestellt, unterschiedliche SOA-Definitionen diskutiert, Erfolgsfaktoren und Prinzipien betrachtet und die Zusammenhänge zwischen Unternehmens- und serviceorientierten Architekturen aufgezeigt. Die einzelnen Punkte geben nur einen groben Überblick über die Grundlagen des SOAThemenkomplexes. Auf eine weitere Vertiefung der SOA-Grundlagen wurde bewusst verzichtet, da dies aufgrund der beträchtlichen Breite und Tiefe des Themenfeldes weit über den Rahmen dieser Arbeit hinausgehen würde. Von daher sei auf einige der bereits angeführten Quellen (Krafzig et al. 2007; Masak 2007; BITKOM 2009; Erl 2005; Bieberstein et al. 2005; Starke und Tilkov 2007; Heutschi 2007; Rosen et al. 2008; Josuttis 2008; Erl 2007; Allen 2006) verwiesen, in denen die Grundlagen serviceorientierter Architekturen detaillierter behandelt werden. Die Auseinandersetzung mit den Bestandteilen und Ebenen einer SOA hat gezeigt, dass bei der Planung, dem Entwurf und dem Betrieb einer serviceorientierten Architektur zahlreiche unterschiedliche Aspekte und Dimensionen berücksichtigt werden müssen. Dies wurde am Beispiel des Services und den verschiedenen Möglichkeiten der Servicetypisierung verdeutlicht. Die unterschiedlichen Perspektiven auf eine SOA drücken sich auch in der Strukturierung der Elemente und Beziehungen auf Basis unterschiedlicher Abstraktionsschichten aus, mit denen jeweils bestimmte Aspekte der Gesamtstruktur einer SOA betrachtet werden können. Auch wenn bei den verschiedenen Darstellungen der Abstraktionsschichten oftmals nur einzelne Dimensionen oder bestimmte Aspekte fokussiert werden, so zeigen die Diskussionen in der Gesamtheit, dass es sich bei einer SOA aufgrund der zahlreichen zu berücksichtigenden Aspekte und Interessen um ein multidimensionales Konstrukt handelt. Gleichzeitig weisen die unterschiedlichen Betrachtungsweisen in Bezug auf die Bestandteile und Ebenen einer SOA viele Gemeinsamkeiten auf, auf die zur Etablierung eines einheitlichen Verständnisses im Unternehmen als Ausgangsbasis zurückgegriffen werden kann. Bezüglich der SOA-Governance-Thematik herrscht ein allgemeiner Konsens darüber, dass SOA-Governance für den erfolgreichen Betrieb und das Management einer serviceorientierten Architektur essenziell ist. Die SOA-Governance adressiert spezielle Aspekte zur Steuerung und Überwachung einer SOA im Unternehmen mit Ausrichtung auf die Unternehmensziele. Dabei wird sie als eine Erweiterung der Corporate und IT-Governance oder aber als zusätzlicher Governance-Typ angesehen. Die konkrete Umsetzung einer SOA-Governance kann, wie die verschiedenen Frameworks zeigen, sehr unterschiedlich ausfallen. Da die Governance als eine der zentralen Führungsaufgaben des Informationsmanagements angesehen wird (vgl. Kapitel 2.2.1), stehen auch mithilfe der SOA-Governance Möglichkeiten der Steuerung des Informationsmanagements, der Informationsversorgung und Informationserfassung zur De-

96

Serviceorientierte Architekturen

ckung des Informationsbedarfs von Stakeholdern im Kontext serviceorientierter Lösungen zur Verfügung oder können geschaffen werden. Die Betrachtung SOA-spezifischer Rollen hat gezeigt, dass in Wissenschaft und Praxis zahlreiche unterschiedliche Rollendefinitionen existieren. Dies ist vor allem auf die gewählte Perspektive und das damit verbundene Abstraktionsniveau bei der Identifikation, Beschreibung und Definition von Rollen zurückzuführen. So richten einige Arbeiten den Fokus stärker auf die Integration mit klassischen Rollen und Prozessphasen, andere Arbeiten hingegen legen den Schwerpunkt auf SOA-spezifische Lebenszyklen und Entwurfsprinzipien. Auf den Kontext einzelner Unternehmen bezogen, stellt sich die Auswahl eines geeigneten Abstraktionsniveaus und eine Standardisierung SOA-spezifischer Rollen und Aktivitäten ohnehin schwierig dar, da die Organisationsstrukturen, Funktionen, Verantwortlichkeiten und Kompetenzen von Unternehmen zu Unternehmen stark variieren. Bei näherer Betrachtung der drei vorgestellten Arbeiten ist jedoch auch zu erkennen, dass die unterschiedlichen Rollen bezüglich ihrer Verantwortlichkeiten und Kompetenzen viele Gemeinsamkeiten aufweisen. Auch wenn die Einführung einer serviceorientierten Architektur und die davon betroffenen Organisationstrukturen sehr unternehmensspezifisch sind, so liefern die unterschiedlichen Ansätze dennoch eine Orientierungshilfe, welche Rollen notwendig sind, mit welchen Zuständigkeiten und Kompetenzen diese Rollen ausgestattet und welche Informationsbedarfe bezüglich der Aufgaben und Interessen von Stakeholdern, die die Rollen ausfüllen, gedeckt werden müssen. Auf Dauer wäre es im Bereich der SOA-Governance jedoch sicherlich hilfreich und auch wünschenswert, eine einheitliche Pattern-Sprache zur Beschreibung von Rollen und einen entsprechenden Pattern-Katalog zu schaffen, um die Anzahl bereits identifizierter Rollen konsolidieren und neue Rollen erfassen zu können. Damit ließen sich insbesondere Redundanzen bei Funktionen, Verantwortlichkeiten und Kompetenzen der Rollen vermeiden, wenn es zu einer konkreten Anwendung bzw. Auswahl von Rollen in einem Unternehmen kommt. Des Weiteren könnte auch die Integration mit vorhandenen Rollen gezielter erfasst und somit die Koordination von Schnittstellen und Kommunikationswegen besser abgestimmt werden. Einen Ansatz in diese Richtung liefert Allen, der in (Allen 2006, S. 246) einen Katalog mit 13 Schlüsselrollen – klassifiziert nach Responsibilities, Skills, Inter-working, Sub-roles – bereitstellt.

4

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Dieses Kapitel beschäftigt sich mit der Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme, was im Sinne des Informationsmanagements (vgl. Kapitel 2.2.1) die Gestaltung und den Betrieb des automatisierten Teils des betrieblichen Informationssystems betrifft. Zunächst wird die Komplexitätsproblematik bei der Entwicklung und dem Management betrieblicher Anwendungssysteme anhand von Diskussionen in der Literatur aufgegriffen und thematisiert (Kapitel 4.1). Im Anschluss daran wird auf das Komplexitätsverständnis unterschiedlicher wissenschaftlicher Disziplinen und Theorien eingegangen (Kapitel 4.2). Im Vordergrund dabei stehen die soziologische Systemtheorie, systemische Denkansätze und die Management-Kybernetik. Darauf folgend wird die Komplexität im Rahmen der Softwareevolution (Kapitel 4.3) und in Bezug auf softwaretechnische Systeme (Kapitel 4.4) näher betrachtet. Die Ausführungen sollen verdeutlichen, welche Spannweite und Dimensionen der Komplexitätsbegriff heutzutage besitzt. Darüber hinaus können Frageund Problemstellungen, die die Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme betreffen, auf Basis der Erkenntnisse anderer wissenschaftlicher Theorien und Ansätze betrachtet und untersucht werden. In einem Zwischenfazit (Kapitel 4.5) wird abschließend die allgemeine Theorie sozialer Systeme Luhmanns verwendet, um die Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme zu erklären. Die Theorie sozialer Systeme dient demnach als Erklärungsansatz, wodurch der Entwicklung und dem Management betrieblicher Anwendungssysteme das Komplexitätsverständnis dieser Theorie zugrunde gelegt wird. Darauf aufbauend werden Frage- und Problemstellungen bezüglich der Informationsverarbeitung und Informationsversorgung diskutiert, wozu auf Erkenntnisse systemischer Denkansätze und der Management-Kybernetik zurückgegriffen wird. Der Fokus der Betrachtungen wird dabei zunehmend auf das Architekturmanagement gerichtet, um im nachfolgenden Kapitel das Konzept der Architektursichten unter Berücksichtigung der in diesem Kapitel geschilderten Problem- und Fragestellungen weiter zu analysieren. 4.1

Einführung in die Komplexitätsproblematik

Die Komplexitätsthematik wird sowohl in der wissenschaftlichen Literatur als auch von Fachleuten aus der Praxis immer wieder aufgegriffen. Kaum ein Beitrag, bei dem die Komplexität der Entwicklung und des Managements von betrieblichen Anwendungssystemen eine Rolle spielt, lässt Aussagen darüber vermissen, dass sie immer komplexer und mächtiger werden. Tiefgreifende und weiterführende Diskussionen sowie differenzierte Untersuchungen über die Ursachen sowie die Beherrschung von Komplexität bei der Entwicklung und dem Manage-

T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

98

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

ment heutiger betrieblicher Anwendungssysteme sind jedoch selten oder werden unzureichend erarbeitet. Malik, der sich mit dem Management von komplexen Systemen und der ManagementKybernetik beschäftigt, merkt an, dass die zu untersuchenden Sachverhalte selten unter Einbezug ihrer vollen Komplexität behandelt werden (Malik 2008, S. 167). Seine Aussage bezieht sich zwar auf einen allgemeineren Kontext, dem der Systemtheorie und evolutionärer Systeme, hat aber im Zusammenhang mit betrieblichen Anwendungssystemen durchaus auch seine Gültigkeit. Die späteren Diskussionen zeigen, dass das Management im Zusammenhang mit betrieblichen Anwendungssystemen häufig allein auf das Management technischer Systeme reduziert wird. Die Wechselwirkungen, die durch die Kopplung mit sozialen Systemen entstehen, werden jedoch außer Acht gelassen oder nicht ausreichend berücksichtigt; dies betrifft dann natürlich auch den Aspekt der Komplexität. Des Weiteren sorgt der Komplexitätsbegriff als solcher für Unklarheit, da er in zahlreichen verschiedenen Disziplinen auf unterschiedlichsten Ebenen verwendet wird. Mit unterschiedlichen Sichten von Komplexität, die sich auf komplexe Systeme im Allgemeinen beziehen, setzt sich Simon in The science of the artifical (Simon 1996) auseinander. Das Interesse an Komplexität und komplexen Systemen hat zahlreiche unterschiedliche wissenschaftliche Bereiche und Theorien hervorgebracht. Simon nennt u.a. Holismus und Reduktionismus, die Kybernetik und die allgemeine Systemtheorie, Katastrophen- und Chaostheorie sowie genetische Algorithmen und zelluläre Automaten (Simon 1996, S. 169ff.). Bandte gibt an, dass sich die Komplexitätswissenschaft erst in ihrer Entstehungsphase befindet und noch keine präzise Definition oder Etablierung des Komplexitätsbegriffs vorliegt (Bandte 2007, S. 47). Die Arbeit von Bandte liefert einen detaillierten Überblick über die wissenschaftlichen Ursprünge (siehe Abbildung 37) und deren Strukturierung sowie über die Forscher unterschiedlicher Disziplinen (siehe Abbildung 38), die sich mit Komplexität befassen, auch wenn er zum Ausdruck bringt, dass seine Analysen nicht den Anspruch auf Vollständigkeit erfüllen können.

Einführung in die Komplexitätsproblematik

99 System Dynamics

Dynamische Systeme Fraktale Geometrie

Allgemeine Systemtheorie

Nichtlineare dynamische Systeme Chaostheorie

Physik „Evolutionäre Bilologie“

Künstliches Leben Boolesche Netzwerke Genetische Algorithmen

Kybernetik Künstliche Intelligenz Informationstheorie

Komplexitätswissenschaft

Informatik Neuronale Netze Spieltheorie

Synergetik

Abbildung 37: Wissenschaftliche Ursprünge einer Komplexitätswissenschaft Quelle: (Bandte 2007, S. 48) Künstliches Leb en/ Künstliche Intelligenz

Mathematik Ray

M ain zer

Chaostheorie

C o nw ay

Biologie

(Lang ton ) (H .A . S im on)

C ra m er

Schus ter Lo ren z D awk in s

C asti

E b eli ng (K au ffm a n )

Spieltheorie

von N eu m an n/ M o rg en ster n

R ied l (K au ffm an )

J.H . A rg yris (H o llan d)

W iene r

B on a be au

Sten g er s H ak en Jan tsch

(H olland )

S elten

Prig o g in e/ N ico lis

(Lan g ton)

J. M ayna rd S m ith Sche llin g R apo po rt

M atu rana / V arela

Physik/ Chemie

W a ld ro p

V .L . S m it h

G ell-M an n

(A x elr od )

H ofstad er

(C ap ra ) P olan y i

W ein b erg (A shby , B eer)

Systemtheorie

B ou lding

W h iteh ea d

Fo rre ster

(F.B . S im o n ) (A shby , B eer) (C ap ra ) vo n B ertalan ffy A rth u r (G o m ez) Lissa ck (A x elro d ) H ey lig h en M cC u lloc h Stacey v o n Fo ers ter v on H aye k W iene r W eav er K ieser (A sh by, B eer)

Kybernetik

M ayu ram a

St. G aller Schu le U lrich , M alik, Probs t, (G o m ez )

K elly Seng e

Systemtheoretisch -kybe rnetische M anagementlehre

G old stein Lien in g

Philosophie W eick D ö rn er

(F .B . Sim on ) B aecke r

C arley

Psychologie

Pe rro w Lu h m an n

M ü n ch ene r S ch ule (K irsch et al.) (H .A . Sim o n)

(W atzlaw ick)

Bühl

K ap p elho ff

B ar na rd

Soziolo gie

W irts chaftswissenschaften

Abbildung 38: Vertreter der Grundlagen einer Komplexitätswissenschaft Quelle: (Bandte 2007, S. 50)

100

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Durch die Vielschichtigkeit und Heterogenität des Komplexitätsbegriffs ist es notwendig, bei der Erforschung neuer Lösungsansätze ein einheitliches Verständnis von Komplexität zu schaffen, um die Ansätze mit dem richtigen Fokus und Bezugsrahmen entwickeln zu können. Unter einem einheitlichen Komplexitätsverständnis ist hier aber weniger das Verständnis im Rahmen einer übergeordneten Komplexitätswissenschaft gemeint, sondern vielmehr wie Komplexität in einem gewählten Kontext zu verstehen ist. Die Komplexitätswissenschaft sollte jedoch als Ausgangsbasis dafür dienen. Darüber hinaus ist es erforderlich, das richtige Bewusstsein und Verständnis im Umgang mit den sich ändernden Rahmenbedingungen und Eigenschaften großer Anwendungssysteme zu entwickeln. Dies betrifft nicht alleine das serviceorientierte Paradigma, sondern vielmehr alle Paradigmen und darauf aufbauenden Systeme, die einen höheren und weiter steigenden Grad an Komplexität besitzen. Ferner bedeutet es, dass es notwendig ist, Erkenntnisse darüber zu erlangen, wie sich Systeme unter heutigen Rahmenbedingungen konstituieren und von ihrer Umwelt abgrenzen, um sie unter dem Gesichtspunkt der Komplexität besser verstehen und beherrschen zu können. Ursachen für die steigende Komplexität sind u.a. in den heute typischen Eigenschaften von Softwaresystemen, den wachsenden Geschäftsanforderungen, organisatorischen Veränderungen, neuen und wechselnden Paradigmen sowie veränderten Entwicklungs- und Managementmethoden zu finden. Auch das serviceorientierte Paradigma hat sicherlich seinen Teil dazu beigetragen. Masak nennt einige Eigenschaften, in denen sich aktuelle von traditionellen Softwaresystemen unterscheiden (Masak 2007, S. 297ff.). Große Organisationsysteme bspw., die sich schon alleine durch ihren Umfang und ihre Größe von traditionellen Systemen unterscheiden, sind dezentral im Einsatz und der Entwicklung und werden von einer großen Anzahl verschiedener Stakeholder mit unterschiedlichen Interessen genutzt. Zudem unterliegt das Gesamtsystem einer kontinuierlichen Evolution, welches emergentes Verhalten aufweist und eine Eigendynamik entwickelt. Der Mensch wird ein integraler Bestandteil und ist somit Teil eines soziotechnischen Gesamtsystems. 4.1.1

Analogie zum Städtebau

Die geänderten Rahmenbedingungen und Charakteristika sind Anlass dafür, dass in Diskussionen zur Komplexitätsbewältigung und zum Management von Anwendungssystemen oder Systemlandschaften in verschiedenen wissenschaftlichen Bereichen, sei es z.B. die Unternehmensmodellierung, die IT-Governance bzw. im speziellen die SOA-Governance, das Software Engineering, das Architekturmanagement oder die Softwarevisualisierung, vermehrt der Vergleich zum Städtebau herangezogen wird (Engels et al. 2008; Wettel und Lanza 2007; Matthes 2008; Dern 2009; Longepe 2003). Die Analogie zur Städteplanung ist hilfreich bei

Einführung in die Komplexitätsproblematik

101

der Entwicklung neuer Lösungsansätze, da insbesondere auch soziale, dynamische und evolutionäre Aspekte berücksichtigt werden. Masak bspw. merkt an, dass, anders als bei der Gebäudearchitektur, die Form einer Stadt nicht im Vorhinein durch eine Spezifikation geregelt ist, sondern ein Produkt vieler Individuen ist und sich permanent unter dem Einfluss diverser treibender Kräfte wandelt (Masak 2007, S. 298). Ein wichtiger Punkt im Vergleich zum Städtebau ist, dass das Wissen über das Design eines Gebäudes für den Entwurf und das Wachstum einer Stadt relativ unwichtig ist. Ähnlich ist es bspw. bei hochintegrierten Softwaresystemen, da es sehr schwierig ist, aus einzelnen deterministischen Komponenten oder Services eine Aussage über das Verhalten des Gesamtsystems zu treffen. Masak führt an, dass sich große Softwaresysteme – in diesem Fall verweist er auf Ultra Large Scale-Systeme (ULSSysteme) – wie ökologische Systeme entwickeln und „eine Gemeinschaft von untereinander abhängigen und konkurrierenden Subsystemen in einer komplexen und sich verändernden Umgebung sind.“ (Masak 2007, S. 298) Matthes nennt unterschiedliche Charakteristika, die sich Stadt und Anwendungslandschaft teilen. Zu ihnen zählen unter anderem, dass sie vernetzte und offene Systeme von teilautonomen und aktiven Systemen sind, sowie lebendig, häufig wachsend, zeitlich unbeschränkt und der Mensch ein integraler Bestandteil ist (Matthes 2008, S. 528). Des Weiteren werden weder Städte noch Anwendungslandschaften „auf der grünen Wiese“ geplant, so dass beide einem natürlichen Wachstum unterliegen, das sich an gegebenen Strukturen und kurzfristigen Zielen orientiert. Insofern ist es wichtig, die grundlegenden Ordnungskriterien und existierende langlebige Strukturen zu berücksichtigen (Engels et al. 2008, S. 66f.). 4.1.2

Der Faktor Mensch

Bei den zuvor genannten Charakteristika und der Analogie zum Städtebau wird deutlich, dass Software und deren technologiezentrierte Entwicklung nicht alleine den Fokus der Betrachtung von Komplexität bilden können. Vielmehr sind es die Umwelt, die Organisation, die Menschen, die Entwicklungsprozesse und die softwaretechnischen Lösungen, die den Betrachtungsgegenstand in Zusammenhang mit Komplexität ausmachen. So sind es bspw. Qualitäts- oder Prozessmodelle, die immer stärker in den Fokus der Wissenschaft und Praxis geraten sind, um geeignete Ordnungsrahmen zu schaffen und der steigenden Komplexität entgegenzuwirken. Nicht selten werden dabei vermehrt soziale, soziotechnische oder psychologische Aspekte betrachtet und analysiert. DeMarco und Lister bspw. vertreten die These, dass die größten Probleme in der Softwareentwicklung bzw. im DV-Management durch den Faktor Mensch entstehen, d.h. keine technologischen, sondern soziologische Probleme sind (DeMarco und Lister 1999, S. 5). Auch Hamilton führt an, dass „ein Drittel aller Probleme in Projekten fachlich-methodisch begründet ist, während die restlichen zwei Drittel aus dem sozial-emotionalen Bereich stammen.“

102

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

(Hamilton 2006, S. 84) Er sieht die Dynamik eines Softwareprojektes ausschließlich durch Faktoren beeinflusst, die sich aus dem Wechselspiel der direkt am Projekt beteiligten Personen ableiten. Somit wird der Faktor Mensch zur treibenden Kraft, wodurch vielfach die ingenieursmäßige Planung ebenfalls dynamisiert wird oder gar komplett fehlschlägt (Hamilton 2006, S. 66). Es handelt sich demnach weniger um den Einsatz falscher Prozessmodelle oder Technologien, sondern um soziale und kommunikative Probleme der beteiligten Menschen und Organisationen untereinander, die sich durch psychologische und politische Aspekte, wie Macht- und Besitzansprüche, Prestige, Anerkennung oder Autorität, erklären lassen. Die psychologischen Prozesse innerhalb von Projektteams können einen sehr viel stärkeren Einfluss auf ungewollte Eigendynamik haben, als bspw. empfindliche Schnittstellen der unterschiedlichen Phasen im Entwicklungsprozess (Hamilton 2006, S. 70). Hamilton betont, dass neben der prozessualen Sicht mit definierten Regularien und Prozessen die Erstellung und Aufrechterhaltung eines ausbalancierten Sozialsystems, mit entsprechend fachlichen sowie psychologisch-sozialen Qualifikationen bei den Mitarbeitern, notwendig ist (Hamilton 2006, S. 84). Die Einführung einer SOA beeinflusst sämtliche Bereiche eines Unternehmens: Mitarbeiter, Verfahren, Prozesse, Organisation und Technologien. Der Paradigmenwechsel birgt die Gefahr, sozio-organisatorische Veränderung im Rahmen von SOA-Initiativen nicht richtig einzuschätzen. Die erfolgreiche Umsetzung einer SOA und deren Evolution sind aber stark von sozialen und organisatorischen Aspekten abhängig. Die Praxis hat den Bedarf erkannt, den Risiken mit geeigneten Mitteln entgegenzuwirken. Einer Studie von IDC zu Folge, bei der acht große IT-Dienstleister untersucht wurden, nehmen Change-Management-Maßnahmen, die soziologische und organisatorische Herausforderungen bei großen SOA-Initiativen adressieren, mittlerweile eine kritische Rolle ein, um den Erfolg nachhaltig zu gewährleisten (Hedin 2007). Der Faktor Mensch wird somit zu einer der Kernkomponenten, da mit der Einführung großer, unternehmensweiter SOA-Implementierungen, Organisationen mit einem vollkommen neuen, serviceorientierten Ökosystem konfrontiert werden. Nach Einschätzungen von Hedin wird der Bedarf an SOA-spezifischen Change Management-Maßnahmen in den nächsten Jahren stetig steigen. 4.1.3

Forderung nach systemischen Ansätzen

Hamilton setzt sich mit der Dynamik und Komplexität im Softwarebau auseinander und stellt sowohl sozio-technische als auch psychologische Fragestellungen sowie Themen wie systemisches Denken, Holismus, Emergenz, Systemtheorie und Kybernetik in den Fokus seiner Betrachtungen (Hamilton 2006, S. 135). Er betont, dass für die Betrachtung von Wechselwirkungen zwischen den einzelnen Elementen eines Systems reduktionistische Ansätze, d.h. die Beschreibung einzelner Elemente, zu Problemen, Missinterpretationen und unvollständigen Lösungen führen und daher ein ganzheitlicher Umgang mit der Thematik auch im Software-

Einführung in die Komplexitätsproblematik

103

bau vonnöten ist. Der Vorteil einer ganzheitlichen Betrachtung liegt darin, dass sich in Bezug auf das Gesamtsystem umfassendere Implikationen ableiten und somit systemweite Entscheidungen treffen lassen. Des Weiteren fordert Hamilton „eine komplexe, multilinear vernetzte, hoch assoziative Denkweise, bei der nicht nur das Projekt, sondern gleichermaßen der gesamte Kontext wie auch die beteiligten Menschen in ihren Wirkungszusammenhängen berücksichtigt werden.“ (Hamilton 2006, S. 135) Auch wenn Bemühungen zu erkennen sind, sich den Problemen und Herausforderungen in Bezug auf die Komplexität zu stellen, muss hinterfragt werden, ob überhaupt grundlegende Mechanismen und Denkweisen existieren, um den gewachsenen Anforderungen, Ideen und Konzepten neuer Paradigmen gerecht zu werden. Dies betrifft insbesondere Versuche, bestehende oder adaptierte Methoden, Konzepte und Vorgehensweisen auf System- und Umwelttransformationen anzuwenden, die jedoch bei Weitem nicht die gewünschte Wirkung im Umgang mit geänderten Rahmenbedingungen erzielen können, weil sie im Kern traditionellen Denkweisen unterliegen. Es gilt demnach die Reichweite angewandter Mechanismen im Auge zu behalten, um deren Wirkung in Bezug auf die adressierten Problemstellungen richtig beurteilen zu können. Zudem sollten die Probleme und Herausforderungen stets in einem ganzheitlichen Kontext betrachtet werden, um beurteilen zu können, welche Wirkung eine Vielzahl von Teilmechanismen in Bezug auf das Ganze entfaltet. Infolgedessen können dann auch Aussagen darüber getroffen werden, ob Einzelmechanismen ineinander greifen oder neue Mechanismen notwendig sind, mit denen die Wirkungszusammenhänge eines Gesamtsystems und dessen Evolution bewertet und kontrolliert, sowie die Komplexität beherrscht werden können. Hamilton bspw. sieht eine Notwendigkeit darin, „dass Bereiche wie Kybernetik, Informationstheorie sowie allgemeine Systemtheorie, insbesondere mit ihren Implikationen für die Praxis, in geeigneter Form Zugang finden zum realen Softwarebau.“ (Hamilton 2008, S. 34) Er merkt an, dass es weniger um die Übernahme von nicht alltagstauglichen Theorien geht, sondern vielmehr um die Frage, welche Aspekte dieser Bereiche einen Beitrag leisten können, den Softwarebau effizienter zu gestalten. Des Weiteren äußert er den Verdacht, dass durch den Fokus auf reale EDV-technische Probleme, Fragestellungen, die zu einer Zeit, als die Grundlagen der modernen Informatik entstanden sind, sehr wohl von Bedeutung waren, heutzutage nicht mehr die nötige Beachtung geschenkt wird (Hamilton 2008, S. 34). Es ist nicht verwunderlich, dass durch zunehmend schnellere Entwicklungszyklen und Lösungen die Zeit für Kommunikation, Reflexion, Analysen von Wechselwirkungen und die Betrachtung größerer Zusammenhänge immer weiter eingeschränkt werden. Auf Dauer wird es somit immer schwieriger, Probleme im Lebenszyklus und der Evolution eines Systems zu vermeiden. Insbesondere die Gefahr, dass Wirkungszusammenhänge intransparent bleiben

104

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

und nicht erkannt bzw. verstanden werden, kann zu einer schwer kontrollierbaren Eigendynamik mit erheblichem Einfluss auf die Nachhaltigkeit des Systems führen. Im Kontext von serviceorientierten Architekturen führt Masak an, dass mit zunehmender Abhängigkeit und schnellerem Wachstum der IT-Systeme Fragestellungen in Richtung der Überlebensfähigkeit solcher Systeme in den Vordergrund rücken (Masak 2007, S. 30). Serviceorientierten Systemen schreibt Masak eine starke Ähnlichkeit zu natürlichen oder sozialen Systemen zu, wodurch Fragestellungen nach Selbsterhalt, Selbstorganisation und Selbstreproduktion des jeweiligen Systems sowie die Auseinandersetzung und der Einsatz der Systemtheorie immer interessanter werden. Viele der in eine SOA gesetzten Erwartungen und Hoffnungen konnten aufgrund von fehlender Disziplin, fehlendem Erfahrungswissen, falschem Verständnis und einer bis heute anhaltenden stark technologiezentrierten Denkweise nicht erfüllt werden. Dies hatte zur Folge, dass zahlreiche SOA-Initiativen von Beginn an zum Scheitern verurteilt waren. Lewis et al. diskutieren generelle Missverständnisse, die bei der Entwicklung serviceorientierter Systeme zu Problemen und Fehlentscheidungen führen (Lewis et al. 2008). Die Steigerung der Komplexität durch SOA wird u.a. auf das verstärkte Business-ITAlignment zurückgeführt, welches bei SOA-Adaptionen als fundamentale Herausforderung angesehen wird (The Open Group 2009c, S. 252). Aber auch bei Organisationen mit einer gut aufeinander abgestimmten Geschäfts- und IT-Welt existieren signifikante Unterschiede zwischen SOA-Landschaften und traditionellen IT-Landschaften, die neue Herausforderungen und Komplexität hervorrufen. Die Erhöhung der Geschäftsflexibilität und -agilität durch das Auflösen siloartiger Geschäftsfunktionen und Applikationen in Services schlägt sich in einer IT-Landschaft nieder, die weitaus feingranularer ist und entsprechend verwaltet werden muss. So nimmt bspw. die Anzahl an Services im Vergleich zu klassischen Applikationen um ein Vielfaches zu, was eine Komplexitätssteigerung bei deren Verwendung und Interaktion nach sich zieht und somit neue Herausforderungen in Bezug auf x

das Verstehen der Beziehung zwischen Technologie- und Service-Portfolios,

x

SLA-Definitionen, Governance und Impact Management,

x

Tracing von Geschäft und IT,

x

Kommunikation, Abstimmung und Semantik,

x

Plattformen und Interoperabilität,

x

Performance und Optimierung

erzeugt (The Open Group 2009c, S. 252). Für den effektiven Betrieb einer SOA ist daher ein wesentlich höherer Grad der Formalisierung in Bezug auf das Verständnis der IT-Landschaft mit einer expliziten Einbindung der unterstützten Geschäftswelt notwendig. Ohne ein solches Verständnis besteht das Risiko, dass die Möglichkeiten serviceorientierter Architekturen zu

Einführung in die Komplexitätsproblematik

105

folgenden, nicht gewünschten Eigenschaften einer IT-Landschaft führen (The Open Group 2009c, S. 253): x

Verbreitung ungeplanter, falsch ausgerichteter Services mit unangemessener Granularität.

x

Unfähigkeit bei der Beurteilung von Wechselwirkungen und zu hohe Ausgaben bei der Infrastruktur und einer schlechten Quality of Service.

x

Zahlreiche kostenintensive und nicht-interoperable Technologie-Stacks, mit dem Ergebnis, dass Services stark an Implementierungsdetails gekoppelt sind und aufgrund eines komplexen Service Managements hohe Betriebskosten entstehen.

x

Unfähigkeit potenzieller Service Consumer Services für die Wiederverwendung zu identifizieren, mit dem Resultat redundanter Funktionalität, des Mangels an Transparenz und erhöhter Integrationskomplexität.

Im Januar 2009 löste Anne Thomas Manes von der Burton Group eine Debatte unter Experten und Analysten aus, als sie SOA für „tot“ erklärte (Manes 2009). Natürlich muss eine solche Aussage relativiert und sehr differenziert betrachtet werden. Als eine zentrale Ursache für das Scheitern von SOA-Projekten sieht Manes vor allem den zu starken Fokus auf technologische Fragestellungen. Bei erfolgreichen SOA-Initiativen ist SOA immer als ein Aspekt einer Transformation verstanden worden, bei dem es nur einen kleinen Teil eines größeren Ganzen darstellt (Manes 2009). Im SOA-Umfeld existieren Ansätze und Methoden, die sich insbesondere in Bezug auf die Entwicklungsprozesse und das Management mit den zuvor geschilderten Problemstellungen und Forderungen auseinandersetzen. Die in Kapitel 3.3 betrachtete SOA-Governance ist ein Beispiel dafür, dass erkannt worden ist, wie wichtig Regelwerke bzw. geeignete Kontroll- und Steuerungsstrukturen sind, um die nötige organisatorische Disziplin (wie z.B. die Kontrolle des Lebenszyklus, die Einhaltung rechtlicher Regularien, einheitliche Qualitätsstandards, die Anpassung der Organisationstrukturen) bei der Entwicklung und dem Management serviceorientierter Systeme zu schaffen. Auch der Managed Evolution-Ansatz (Murer et al. 2008) der Credit Suisse wurde im Zuge der Modernisierung von Altsystemen zur Serviceorientierung als Evolutionsstrategie entwickelt, um der Architekturerosion (funktionale und Daten-Redundanz, enge Kopplungen und Abhängigkeiten sowie die unkontrollierte technologische Divergenz) sehr großer Informatiksysteme entgegenzuwirken. Die Managed Evolution berücksichtigt sowohl technische als auch ökonomische Anforderungen und sieht in der Durchführung von beherrschbaren risikogesteuerten Evolutionsschritten ein zentrales Grundprinzip. Die Autoren betonen aber in ihrem Beitrag, dass für die Beantwortung der Frage nach einer finanziell optimalen Strategie

106

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

zur Evolution großer Informatiksysteme das theoretische Fundament sowie eine systematische und praktische Empirie fehlen (Murer et al. 2008). In Bezug auf die Komplexität und das Management serviceorientierter Architekturen ist festzustellen, dass auch bei diesen Ansätzen eine direkte Auseinandersetzung mit pragmatischen Aspekten aus den Bereichen der Systemtheorie und Kybernetik sowie die Betrachtung unterschiedlicher Denkweisen weitestgehend ausbleiben. Hamilton betont, dass es für die zunehmend komplexeren Softwarelösungen in Zukunft nicht mehr ausreicht, „deren Entwicklung und Aufbau als Konstrukt reiner Logik und ihre Herstellung ausschließlich als einen rein ingenieurmäßigen Prozess zu betrachten.“ (Hamilton 2008, S. 33) 4.2

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

Im Folgenden werden Theorien und Wissenschaften vorgestellt, die sich mit komplexen Systemen, deren Evolution sowie deren Management auseinandersetzen. Im Vordergrund dabei stehen die Systemtheorie, systemisches Denken und die Kybernetik. Insbesondere die Systemtheorie mit ihrer Nähe zur Kybernetik leistet einen erheblichen Beitrag zur Entstehung einer Komplexitätswissenschaft (Bandte 2007, S. 67). Da im Rahmen der vorherigen Diskussionen soziale Aspekte bei der Entwicklung und dem Management betrieblicher Anwendungssysteme immer wieder angeführt wurden, wird in Bezug auf die Systemtheorie der Fokus auf die Theorie sozialer Systeme Luhmanns gerichtet. Nach der Darstellung von Unterschieden zwischen dem Systemdenken und der klassischen analytischen Denkweise wird die Bedeutung von Komplexität im Bereich des Managements im Kontext der ManagementKybernetik betrachtet. Zunächst folgt jedoch ein kurzer Überblick, wie der Systembegriff im Allgemeinen verstanden wird und welche Charakteristika komplexe Systeme besitzen. 4.2.1

Systembegriff

Der Begriff System geht auf das griechische(-lateinische) Wort sýstƝma „das aus mehreren Teilen zusammengesetzte und gegliederte Ganze“ zurück (Anonym 2006). Allgemein ist ein System ein konkretes (reales, wirkliches) oder ideelles Ganzes, dessen Teile strukturell oder funktional miteinander in Beziehung stehen bzw. ein Prinzip oder eine Ordnung, nach der etwas aufgebaut oder organisiert wird (Anonym 2005). Im Rahmen wissenschaftlicher Theorien geht der Systembegriff auf die vom Biologen Ludwig van Bertalanffy verfasste allgemeine Systemlehre zurück und wurde zudem durch die von N. Wiener begründete Kybernetik und die von C. E. Shannon begründete Informationstheorie geprägt (Anonym 2005). Als komplexe Systeme werden, allgemein gefasst, Objekte bezeichnet, „die aus einzelnen Teilen (Elementen, Komponenten) bestehen, wobei die Anordnungen der Teile, ihre Wechselbeziehungen, die Teile selbst und/oder das Gesamtverhalten kompliziert sind“ (Anonym 2005). Nach Wilke bezeichnet ein System – wenn es im Sinne von komplexem System ver-

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

107

wendet wird – „einen ganzheitlichen Zusammenhang von Teilen, deren Beziehungen untereinander quantitativ intensiver und qualitativ produktiver sind, als ihre Beziehungen zu anderen Elementen.“ (Wilke 1987, S. 176) Des Weiteren sind komplexe Systeme durch die Merkmale Selbstorganisation, Grenzerhaltung, Selbstreferenz und Generativität charakterisiert. Um unterschiedliche Systeme unter dem Gesichtspunkt der Komplexität abgrenzen und spezifizieren zu können, nimmt Bandte eine Unterteilung in vier unterschiedliche Systemtypen vor

z. B. Nichtlinarität,Dynamik

(siehe Abbildung 39). Er unterscheidet mit Bezug auf ihre Charakteristika einfache, beziehungsreich komplizierte, dynamisch komplizierte und komplexe Systeme (Bandte 2007, S. 94f.). Dynamisch kompliziertes System

Komplexes System

Beziehungsreich kompliziertes System

Einfaches System

z. B. Vielzahl, Varietät, Emergenz Abbildung 39: Unterscheidung von Systemtypen Quelle: (Bandte 2007, S. 93; Ulrich und Probst 1995, S. 109)

Bandte schreibt im Rahmen seiner Untersuchungen komplexen Systemen die Eigenschaften Überlebenssicherung, Dynamik, Vielzahl und Varietät, Pfadabhängigkeit, Rückkopplung, Nichtlinearität, Offenheit, begrenzte Rationalität, Selbstorganisation, Selbstreferenz, Emergenz und Autopoiesis (siehe Kapitel 4.2.3) zu. Die anderen Systemtypen besitzen im Gegensatz dazu lediglich die Eigenschaften Überlebenssicherung, Dynamik und eingeschränkt auch eine Vielzahl und Varietät der Systemelemente (Bandte 2007, S. 92).

108

4.2.2

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Komplexität und Hierarchie

Simon vertritt die These, dass die Theorie der Hierarchie ein Mittel zur Konstruktion nichttrivialer Theorien komplexer Systeme ist (Simon 1996). Er führt an, dass empirisch gesehen, ein großer Anteil komplexer Systeme, die in der Natur zu beobachten sind, hierarchische Strukturen aufweisen. Simon ist der Ansicht, dass Hierarchie eines der zentralen Strukturierungsschemata darstellt, das Architekten von Komplexität zur Verfügung steht. Den Begriff komplexes System definiert Simon (Simon 1996, S. 183f.) nicht formal, sondern führt an, dass ein komplexes System in seinem Verständnis aus einer großen Anzahl von Teilen mit vielen Interaktionen besteht. Er bringt zudem zum Ausdruck, dass das Ganze mehr als nur die Summe seiner Teile ist; oder pragmatischer ausgedrückt, die Eigenschaften der Teile und die Gesetzmäßigkeiten ihrer Interaktion es nur schwer zulassen, Schlüsse über die Eigenschaften des Ganzen zu ziehen. In seinem Beitrag The architecture of complexity (Simon 1996, S. 184ff.) diskutiert Simon vier Aspekte von Komplexität. Der erste Aspekt bezieht sich auf die Häufigkeit, mit der Komplexität in Form von Hierarchie auftritt, also komplexe Systeme sich aus einer Hierarchie von Subsystemen zusammensetzen. Der zweite Aspekt diskutiert die Beziehung zwischen der Struktur komplexer Systeme und der Zeit, die sie benötigen, um aus evolutionären Prozessen hervorzugehen. Der dritte Aspekt untersucht die dynamischen Eigenschaften hierarchisch organisierter Systeme und zeigt, wie sie in Subsysteme zerlegt werden können, um deren Verhalten zu analysieren. Der vierte Aspekt behandelt die Beziehung zwischen komplexen Systemen und ihren Beschreibungen. 4.2.3

Soziologische Systemtheorie

Mit der Systemtheorie und unterschiedlichen systemtheoretischen Ansätzen wird der Versuch unternommen, komplexe Systeme, Zusammenhänge und Sachverhalte verstehen und erklären zu können. Die Systemtheorie ist eine interdisziplinäre Wissenschaft, deren Begriffe in unterschiedlichen Bereichen, wie z.B. der Biologie, Chemie, Physik, Philosophie, Informatik, Ingenieurswissenschaften, Soziologie oder Wirtschaftswissenschaften, Anwendung finden. Der Begriff der Allgemeinen Systemtheorie geht auf den Biologen Bertalanffy zurück und wurde von ihm maßgeblich geprägt (von Bertalanffy 1949; von Bertalanffy 1976). Er formulierte eine Theorie der Selbstregulierungsfähigkeit offener biologischer Systeme, die – entgegen den in den Naturwissenschaften üblichen analytisch-deduktiven Verfahren und damit verbundenen Betrachtungen von Einzelphänomenen – diese Phänomene in ihrer Vernetzung beschreibt. Die Allgemeine Systemtheorie wurde durch einen Paradigmenwechsel und durch die Entwicklung und Erweiterung unterschiedlicher Ansätze, wie z.B. der Kybernetik, der soziologischen Systemtheorie oder der Theorie komplexer Systeme, zu einer Neuen Systemtheorie weiterentwickelt.

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

109

Da zuvor insbesondere soziale Aspekte im Rahmen der Entwicklung und des Managements betrieblicher Anwendungssysteme angesprochen wurden, wird im Folgenden näher auf die soziologische Systemtheorie Niklas Luhmanns eingegangen, der seine Untersuchungen der allgemeinen Theorie sozialer Systeme widmet und soziale Systeme als komplexe Systeme von Kommunikationen beschreibt. Luhmanns Ansatz ist neben der Soziologie auch in der Psychologie und Managementtheorie von großer Bedeutung (Sanders und Kianty 2006, S. 265f.). 4.2.3.1

„Neue“ Systemtheorie

Luhmann, der neben Talcott Parson als einer der wichtigsten Vertreter der soziologischen Systemtheorie gilt, beschreibt bezüglich des Paradigmenwechsel, dass auf Ebene der Allgemeinen Systemtheorie hin zu einer „Neuen“ Systemtheorie zwei Schübe auszumachen sind (Luhmann 1987, S. 22). Im Ersten löst sich die Systemtheorie vom Paradigma des Ganzen und seiner Teile und wird durch die Differenz von System und Umwelt ersetzt. Die Systemdifferenzierung wird als die Wiederholung der Differenz von System und Umwelt innerhalb von Systemen verstanden, wobei sich das Gesamtsystem selbst als eigene Umwelt für eigene Teilsystembildungen benutzt. Der zweite Schub umfasst die Unterscheidung von geschlossenen und offenen Systemen gefolgt von der Theorie selbstreferentieller und autopoietischer Systeme. Durch die Theorie selbstreferentieller Systeme und der Autopoiesis wird die klassische Unterscheidung von geschlossenen und offenen Systemen ersetzt durch die Kombination von operationeller Geschlossenheit und Umweltoffenheit des Systemaufbaus (Luhmann 1987, S. 64). Der Begriff der Autopoiesis oder Autopoiese wurde von den beiden Neurobiologen Maturana und Varela (Maturana und Varela 1990) geprägt und bedeutet „selbsterzeugend“ oder „selbstreproduktiv“. Autopoietische Systeme besitzen die Eigenschaft der Selbst(re)produktion, d.h., sie können sich aus den Elementen und durch die Elemente, aus denen sie bestehen, selbst produzieren und reproduzieren. Dabei besitzt ein System eine bestimmte Operationsweise und grenzt sich mit diesen Operationen von seiner Umwelt ab (operative Geschlossenheit). Bei sozialen Systemen bedeutet es, dass Kommunikation die Möglichkeit für weitere Kommunikation schafft. Die Fähigkeit zur Selbstreferenz sagt aus, dass ein System Beziehungen zu sich selbst herstellen kann, sich also selber identifiziert und von anderem unterscheidet (Differenz von Selbst- und Fremdreferenz). Mithilfe der Selbstbeobachtung (Einführung der System/Umwelt-Differenz in das System) ergibt sich dann die Möglichkeit, Umwelteinflüsse im System aufzunehmen und durch interne Operationen zu verarbeiten, um somit die Anschlussfähigkeit der autopoietischen Reproduktion zu ermöglichen. Als Ausgangspunkt jeder systemtheoretischen Analyse dient, wie bereits zuvor erwähnt, die Differenz von Systemen und Umwelt. Zur Differenz von Umwelt und System führt Luhmann an, dass Systeme nicht nur gelegentlich und nur adaptiv sind, „sie sind strukturell an ihrer

110

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Umwelt orientiert und könnten ohne Umwelt nicht bestehen. Sie konstituieren und sie erhalten sich durch die Erzeugung und Erhaltung einer Differenz zur Umwelt, und sie benutzen ihre Grenzen zur Regulierung dieser Differenz.“ (Luhmann 1987, S. 37) „Die Umwelt ist konstitutives Moment dieser Differenz, ist also für das System nicht weniger wichtig, als das System selbst.“ (Luhmann 1987, S. 289) Dadurch entstehen Wechselwirkungen zwischen unterschiedlichen Systemen, da aus der Sicht eines Systems alle anderen Systeme dessen Umwelt darstellen: „Jede Änderung eines Systems ist Änderung der Umwelt anderer Systeme; jeder Komplexitätszuwachs an einer Stelle vergrößert die Komplexität der Umwelt für alle anderen Systeme.“ (Luhmann 1987, S. 243) Die System/Umwelt-Differenz ermöglicht es, Umweltdifferenzierung und Systemdifferenzierung voneinander zu unterscheiden (Luhmann 1987, S. 256ff.). Die Umweltdifferenzierung bezieht sich auf die Beobachtung der Umwelt durch das System, wodurch es stimuliert und limitiert wird. „Jedes System hat in seiner Umwelt mit anderen Systemen zu rechnen. Je nachdem, wie tiefenscharf die Umwelt aufgenommen werden kann, erscheinen in ihr mehr und verschiedenartigere Systeme. Verfügt das System, von dem wir ausgehen, über die Fähigkeit zu verstehen, kann es die Systeme in seiner Umwelt aus deren Umwelt begreifen. Es löst damit die primär gegebenen Einheiten seiner Umwelt in Relationen auf. Dann erscheint dem System seine Umwelt als differenziert in verschiedene System/Umwelt-Perspektiven, die sich wechselseitig überschneiden und insofern insgesamt die Einheit der Umwelt repräsentieren.“ (Luhmann 1987, S. 256f.) Durch die Systemdifferenzierung hingegen wiederholt sich die Systembildung in Systemen, d.h. innerhalb von Systemen kann es zu weiteren Ausdifferenzierungen von System/Umwelt-Differenzen kommen. Für das Gesamtsystem bedeutet dies wiederum, dass es für jedes Teilsystem eine spezifische „interne“ Umwelt darstellt. „Interne Differenzierungen schließen an die Grenzen des bereits ausdifferenzierten Systems an und behandeln den damit eingegrenzten Bereich als eine Sonderumwelt, in der weitere Systembildungen folgen können.“ (Luhmann 1987, S. 259) In Bezug auf die Systemdifferenzierung merkt Luhmann an, dass es verschiedene Tendenzen gab, Systemdifferenzierung als Hierarchie zu beschreiben26 (Luhmann 1987, S. 38f.). Zwar spricht er der Hierarchisierung Rationalitätsvorteile zu, sagt aber zugleich mit Verweis auf den Städtebau, dass es sich um eine unrealistische Annahme handle, da es allein um die Ausdifferenzierung von Teilsystemen, also das „transitive Verhältnis des Enthaltenseins im Enthaltensein“ (Luhmann 1987, S. 38) geht. Auf Ebene der allgemeinen Theorie sozialer Systeme ist die Unterscheidung zwischen Differenzierung und Hierarchisierung notwendig; in Hierarchisierung sieht Luhmann in diesem Zusammenhang einen Sonderfall von Differenzierung, 26

Luhmann verweist dabei auch auf die in Kapitel 4.2.2 angeführten Arbeiten von Simon.

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

111

die die Beobachtung des Systems erleichtert. Er fügt jedoch hinzu, dass nicht davon ausgegangen werden kann, dass die Evolution Komplexität zwangsläufig in die Form von Hierarchie bringt (Luhmann 1987, S. 38f. u. 404). Wenn sich unter der Berücksichtigung dieser Aussagen noch einmal die Analogie zum Städtebau (siehe Kapitel 4.1.1) vor Augen geführt wird, wird deutlich, dass die Hierarchisierung als eine der Grundprinzipien zur Komplexitätsreduktion bei der Entwicklung und dem Management von Anwendungssystemen insbesondere unter dem Gesichtspunkt sozialer Aspekte äußerst differenziert und kritisch betrachtet werden sollte. 4.2.3.2

Komplexität, Selektionszwang und Kontingenz

Zur Einführung des Begriffs der Komplexität wird neben der System/Umwelt-Differenz die Differenz von Element und Relation unterschieden (vgl. im Folgenden (Luhmann 1987, S. 41ff.)). Ein Element ist dabei eine für ein System nicht weiter auflösbare Einheit. Luhmann merkt an, dass erst diese Unterscheidung es sinnvoll macht, dass mit Zunahme der Differenzierung oder mit einer Änderung von Formen der Differenzierung die Systemkomplexität zunehme. Nimmt die Anzahl der Elemente zu, so wird irgendwann ein Punkt erreicht, an dem es nicht mehr möglich ist, jedes Element zu jedem anderen in Beziehung zu setzen. Luhmann definiert Komplexität daher folgendermaßen: „Als komplex wollen wir eine zusammenhängende Menge von Elementen bezeichnen, wenn aufgrund immanenter Beschränkungen der Verknüpfungskapazität der Elemente nicht jedes Element jederzeit mit jedem anderen verknüpft sein kann.“ (Luhmann 1987, S. 46) Demnach drückt sich Komplexität in Selektionszwang und dieser wiederum in Kontingenz aus („auch anders möglich sein“), d.h., dass ein komplexer Sachverhalt auf selektierten Relationen zwischen Elementen beruht, obwohl auch andere Relationierungen möglich gewesen wären. Anders ausgedrückt, macht, ausgehend vom System, die Vielfalt möglicher Entscheidungen dessen Kontingenzspielraum aus. Die Vielfalt von Umweltereignissen hingegen erscheint aus der Sicht des Systems als die Komplexität seiner Umwelt (Wilke 1987, S. 22). Luhmann merkt an, dass die Frage nach der Realisierung von Beziehungen zwischen Elementen nicht aus der Komplexität selbst abgeleitet werden kann, sondern sich auf jeder Ebene der Systembildung aus der Differenz von System und Umwelt ergibt. Das Problem der System/Umwelt-Differenz aber lässt sich durch den Komplexitätsbegriff erklären (Luhmann 1987, S. 47f.). Das Problem liegt darin, dass ein System hinsichtlich seiner Umwelt eine Komplexitätsunterlegenheit aufweist und somit ein Komplexitätsgefälle vorliegt – das System besitzt nicht die gleiche Varietät wie seine Umwelt, die jedoch notwendig wäre, um auf jeden Zustand der Umwelt reagieren zu können (siehe Requisite Variety in Kapitel 4.2.5). „Jedes System hat sich gegen die überwältigende Komplexität seiner Umwelt zu behaupten, und jeder Erfolg dieser Art, jeder Bestand, jede Reproduktion macht die Umwelt aller anderen Systeme komplexer.“ (Luhmann 1987, S. 250) Eben diese Unterlegenheit muss durch Selektions-

112

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

strategien und Ordnung ausgeglichen werden. In diesem Zusammenhang führt er an, dass sich der Selektionszwang des Systems schon aus seiner eigenen Komplexität ergibt, die Auswahl der Ordnung in der Relationierung seiner Elemente hingegen aus der Komplexitätsdifferenz zur Umwelt (Luhmann 1987, S. 48). Eine wichtige Funktion bezüglich der Komplexitätsthematik und der Ausdifferenzierung von Systemen nimmt neben der Konstitution systemeigener Elemente die Bestimmung von Systemgrenzen ein. Systemgrenzen übernehmen die Funktion der Stabilisierung des Komplexitätsgefälles, für die jedoch nur das System selber Strategien entwickeln kann (Luhmann 1987, S. 53f.). Dabei werden Elemente entweder dem System oder dessen Umwelt zugerechnet, Relationen hingegen können auch zwischen System und Umwelt existieren. „Eine Grenze trennt also Elemente, nicht notwendigerweise auch Relationen; sie trennt Ereignisse, aber kausale Wirkungen lässt sie passieren.“ (Luhmann 1987, S. 52) Luhmann merkt bezüglich der Systemdifferenzierung an, dass sie zwangsläufig zur Komplexitätssteigerung des Gesamtsystems führt, umgekehrt aber auch nur dadurch ermöglicht wird, „wenn das Gesamtsystem mehr und verschiedenartigere Elemente konstituieren und über schärfer ausgewählte Relationen verknüpfen kann.“ (Luhmann 1987, S. 261f.) Wie zuvor erwähnt wird durch Systemdifferenzierung die Gesamtsystembildung in sich selbst wiederholt. „Das Gesamtsystem wird rekonstruiert als interne Differenz von Teilsystem/Teilsystemumwelt, und dies für jedes Teilsystem auf je verschiedene Weise. Je nach interner Schnittlinie ist das Gesamtsystem dann mehrfach in sich selbst enthalten. Es multipliziert seine eigenen Realität.“ (Luhmann 1987, S. 262) „Deshalb ist Systemdifferenzierung ein Verfahren der Steigerung von Komplexität – mit erheblichen Konsequenzen für das, was dann noch als Einheit des Gesamtsystems beobachtet werden kann.“ (Luhmann 1987, S. 38) Luhmann verweist aber auch darauf, dass die Systemdifferenzierung nicht nur zu einer Steigerung von Komplexität führt, sondern auch neue Formen der Reduktion von Komplexität ermöglicht. „Jedes Teilsystem übernimmt, wenn man so sagen darf, einen Teil der Gesamtkomplexität, indem es sich nur an der eigenen System/Umwelt Differenz orientiert, mit dieser aber das Gesamtsystem für sich rekonstruiert. So kann das Teilsystem sich durch die Voraussetzung entlastet fühlen, dass viele Erfordernisse der Gesamtsystemreproduktion anderswo erfüllt werden. Seine Abhängigkeit vom Gesamtsystem wird entsprechend gedoppelt: es selbst ist ein Teil des Gesamtsystems und zugleich abhängig von der internen Umwelt und so auf anderem Wegen ebenfalls vom Gesamtsystem.“ (Luhmann 1987, S. 262) Luhmann verweist unter dem Gesichtspunkt der Reduktionsnotwendigkeit auf eine Komplexität im zweiten Sinne, die in einem Maß für Unbestimmbarkeit oder für Mangel an Informationen zu sehen ist. „Komplexität ist, so gesehen, die Information, die dem System fehlt, um seine Umwelt (Umweltkomplexität) bzw. sich selbst (Systemkomplexität) vollständig erfassen und beschreiben zu können (Luhmann 1987, S. 50f.). Er führt an, dass die Unterscheidung

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

113

der beiden Komplexitätsbegriffe zeigt, „dass Systeme ihre eigene Komplexität (und erst recht: die ihrer Umwelt) nicht erfassen und doch problematisieren können. Das System produziert ein und reagiert auf ein unscharfes Bild seiner selbst.“ (Luhmann 1987, S. 51) Ein weiterer Aspekt, den Luhmann betrachtet, ist die Zeit. Er führt an, dass der Zusammenhang von Komplexität und Selektion keine Zustandsbeschreibung ist, sondern Zeit der Grund für Selektionszwang in komplexen Systemen ist, „denn wenn unendlich viel Zeit zur Verfügung stünde, könnte alles mit allem abgestimmt werden.“ (Luhmann 1987, S. 70) Sobald etwas Bestimmtes passiert, kann auch etwas anderes passieren, so dass keine Einzeloperation eine volle Kontrolle über ihre Bedingungen gewinnen kann. Des Weiteren muss sich ein System bezüglich des Komplexitätsgefälles auf Risiken einstellen, die dadurch zustande kommen, dass ein System seiner Umwelt zu einem bestimmten Zeitpunkt nicht entspricht, da es auf eine vollständige Synchronisation verzichten muss (Luhmann 1987, S. 72). 4.2.3.3

Soziale Systeme

Luhmann sieht nicht Menschen sondern Kommunikationen als kleinste Elemente sozialer Systeme, die permanent vom System produziert werden, um sich selber zu steuern und anschlussfähig zu bleiben. Der Mensch stellt in diesem Sinne kein System dar, sondern besteht aus mehreren getrennt operierenden Systemen (organische, neuronale und psychische Systeme), bei denen es keine übergreifende autopoietische Einheit gibt (Kneer und Nassehi 2000, S. 66). Soziale Systeme sind autopoietische Systeme, die sich durch die Anschlussfähigkeit von Kommunikation an Kommunikation in einem rekursiven Prozess reproduzieren. Sie operieren in Form von Kommunikation und grenzen sich durch die Einschränkung geeigneter Kommunikation von ihrer Umwelt ab. Soziale Systeme sind, genau wie psychische Systeme, Sinn konstituierende und verwendende Systeme. Sie orientieren sich in Form von Sinn an Komplexität und vermitteln über Sinngrenzen – soziale Systeme operieren sinnhaft in Form eines geschlossenen Kommunikationszusammenhangs – ihre System/Umwelt-Differenz (Luhmann 1987, S. 265; Kneer und Nassehi 2000, S. 75). Auch wenn der Mensch über sein Bewusstsein nicht als Auslöser von Kommunikation verstanden wird – psychische Systeme kommunizieren nicht miteinander, sie produzieren Gedanken; sie sind an Kommunikation beteiligt, aber bringen sie nicht ursächlich hervor – so wird Kommunikation jedoch ständig durch Bewusstseinssysteme irritiert (Kneer und Nassehi 2000, S. 70). Das Verhältnis zwischen Kommunikation und Bewusstsein wird als strukturelle Kopplung bezeichnet. Strukturell gekoppelte Systeme sind aufeinander angewiesen, was in Bezug auf soziale und psychische Systeme bedeutet, dass es keine Kommunikation ohne Bewusstsein und kein Bewusstsein ohne Kommunikation gibt, beide Systeme aber dennoch Umwelt füreinander bleiben (Kneer und Nassehi 2000, S. 71).

114

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Kommunikation versteht Luhmann als Synthese dreier Selektionen, als die emergente Einheit aus Information, Mitteilung und Verstehen (Luhmann 1987, S. 196ff.). Die Selektion entspricht dabei der Auswahl von Möglichkeiten, d.h. es werden Informationen aus einem Horizont an Möglichkeiten ausgewählt, für die wiederum verschiedene Mitteilungsmöglichkeiten (Schrift, Sprache, etc.) zur Verfügung stehen und auch die mitgeteilte Information kann wieder auf unterschiedliche Art und Weise verstanden werden (Kneer und Nassehi 2000, S. 81). Es handelt sich demnach um eine Kommunikation, „wenn eine Informationsauswahl, eine Auswahl von mehreren Mitteilungsmöglichkeiten und eine Auswahl von mehreren Verstehensmöglichkeiten getroffen wird.“ (Kneer und Nassehi 2000, S. 81) Die ersten beiden Selektionen (Information und Mitteilung) werden in diesem dreistelligen Selektionsprozess einem Sender („Alter“) zugeordnet, die dritte Selektion (Verstehen) einem Empfänger („Ego“). Dadurch, dass erst bei der Synthese aller drei Selektionen von Kommunikation gesprochen wird, wird gleichzeitig ausgeschlossen, „dass Kommunikation als das Resultat des Handelns eines Individuums aufgefasst wird.“ (Kneer und Nassehi 2000, S. 81f.) An Kommunikationen schließen sich weitere Kommunikationen an, was als Anschlusskommunikation oder vierte Selektion bezeichnet wird und eine neue Kommunikationseinheit darstellt (Berghaus 2004, S. 97ff.). Das Verstehen einer Mitteilung wird auf zwei unterschiedliche Arten betrachtet. Zum einen muss eine Mitteilung als solche verstanden werden, was der dritten Selektion der ersten Kommunikationseinheit entspricht. Zum anderen muss die Mitteilung inhaltlich vom Sinn her verstanden werden, d.h. ein Sinnangebot des Senders kann angenommen oder abgelehnt werden. Diese Art des Verstehens wird bereits der Anschlusskommunikation zugerechnet und entspricht somit der ersten Selektion der nächsten Kommunikationseinheit. Kommunikation darf Luhmann zufolge nicht mit der Übertragung von Nachrichten oder Informationen gleichgesetzt werden (Luhmann 1987, S. 193ff.). Anders als bspw. in der Informationstheorie von Shannon und Weaver (Shannon und Weaver 1949), in der Kommunikation als ein zweistelliger Prozess (Sender-Empfänger-Modell) angesehen wird, kommt dem Informationsbegriff in der Theorie Luhmanns eine andere Bedeutung zu. Luhmann bezieht sich beim Informationsbegriff auf die in Kapitel 2 angeführte Definition von Bateson und sieht in Information „nichts anderes als ein Ereignis, das eine Verknüpfung von Differenzen bewirkt – a difference that makes a difference.“ (Luhmann 1987, S. 112) Anders ausgedrückt kommt eine Information immer dann zustande, „wenn ein selektives Ereignis (externer oder interner Art) im System selektiv wirken, dass heißt Systemzustände auswählen kann.“ (Luhmann 1987, S. 68) Luhmann erläutert dies folgendermaßen27: „Eine Information, die sinnge27

Vgl. dazu auch (Luhmann 2009, S. 127ff.)

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

115

mäß wiederholt wird, ist keine Information mehr. Sie behält in der Wiederholung ihren Sinn, verliert aber ihren Informationswert. Man liest in der Zeitung: die DM sei aufgewertet worden. Wenn man dasselbe dann in einer anderen Zeitung nochmal liest, hat diese Aktivität keinen Informationswert mehr (sie ändert den eigenen Systemzustand nicht mehr), obwohl sie strukturell dieselbe Selektion präsentiert. Andererseits geht die Information, obwohl sie als Ereignis verschwindet, nicht verloren. Sie hat den Systemzustand geändert, hat damit einen Struktureffekt hinterlassen, und das System reagiert dann auf diese geänderten Strukturen und mit ihnen.“ (Luhmann 1987, S. 102) Zwar knüpft Luhmann an den Informationsbegriff von Shannon und Weaver (Shannon und Weaver 1949) an, indem er Information als Selektion von Möglichkeiten auffasst (Luhmann 1987, S. 195; Luhmann 2009, S. 128). Diese Selektion obliegt in Luhmanns Kommunikationsmodell jedoch nicht der Senderseite, sondern kann nun auf der Empfängerseite lokalisiert werden (Klemm 2003, S. 273). Information wird also vielmehr von einem Beobachter konstituiert (Berghaus 2004, S. 78f.), d.h. sie wird systemintern erzeugt und liegt nur innerhalb von Systemen vor (Luhmann 2009, S. 129). Die Umwelt von Systemen enthält demnach keine Informationen, sondern ist nach Luhmann „ein unermessliches Potential für Überraschungen, ist virtuelle Information, die aber Systeme benötigt, um Informationen zu erzeugen, oder genauer: um ausgewählten Irritationen den Sinn von Information zu geben.“ (Luhmann 1997, S. 46) Das bedeutet, dass Informationen nicht in der Welt vorhanden sind und daraus in ein System übertragen werden können, sondern ein Informationswert vom System zugeschrieben wird (Berghaus 2004, S. 59). Genauso wenig werden Informationen von System zu System übertragen. Dem System liegen also nur Irritationen, Rauschen, Pertubationen, Reizungen und Störungen aus der Umwelt vor (Berghaus 2004, S. 59), welche vom System nach dem Prinzip des „order from noise“ (vgl. (von Foerster 1993)) in Ordnung transformiert werden kann (Luhmann 2009, S. 119). Des Weiteren unterscheidet Luhmann zwischen Kommunikation und Handlung. Er sieht die Notwendigkeit der Unterscheidung darin, „dass Kommunikation nicht direkt beobachtet, sondern nur erschlossen werden kann.“ (Luhmann 1987, S. 226) Handlungen hingegen sind beobachtbar und Voraussetzung für die Anschlussfähigkeit von Kommunikation. „Kommunikationssystemen steht es frei, über Handlungen oder über etwas anderes zu kommunizieren; sie müssen jedoch das Mitteilen selbst als Handeln auffassen, und nur in diesem Sinne wird Handeln zur notwendigen Komponente der Selbstreproduktion des Systems von Moment zu Moment. […] Erst durch die Handlung wird die Kommunikation als einfaches Ereignis an einem Zeitpunkt fixiert. Auf Basis des Grundgeschehens Kommunikation und mit ihren operativen Mitteln konstituiert sich ein soziales System demnach als Handlungssystem.“ (Luhmann 1987, S. 227) Somit wird Kommunikation durch Handlungen reduziert, da als Verknüpfungsstellen für Relationierungen nur Handlungen und nicht volle kommunikative Ereignisse die-

116

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

nen, also „von den Komplexitäten des vollen kommunikativen Geschehens absehen kann.“ (Luhmann 1987, S. 232) Durch die Reduktion kann soziales Geschehen personenorientiert aufgefasst werden, indem Kommunikation als Mitteilungshandlung einzelnen Personen zugerechnet wird. Soziale Systeme bilden somit Identifikationspunkte, an die weitere Kommunikation anknüpfen kann (Kneer und Nassehi 2000, S. 88f.). Zum Ordnen dieser Handlungen eines sozialen Systems werden Strukturen benötigt. Eine Struktur besteht in der Selektion einer Einschränkung der im System zugelassenen Relationen und die damit verbundene Kontingenz gibt einer Relation zwischen Elementen Strukturwert. Von der Struktur sind die Prozesse zu unterscheiden, die dadurch zustande kommen, dass konkrete selektive Ereignisse zeitlich aufeinander aufbauen und aneinander anschließen (Luhmann 1987, S. 73ff.). Unter Einbezug der Zeitdimension wird Handlung von Luhmann als Ereignis interpretiert und der Strukturbegriff „durch seine Funktion, die autopoietische Reproduktion des Systems von Ereignis zu Ereignis zu ermöglichen“ (Luhmann 1987, S. 388), weiter eingeschränkt. Diese Verknüpfung von Handlungsereignissen bzw. die Reproduktion von Handlungen erfordert die Vorgabe und kontinuierliche Reaktivierung von Erwartungsstrukturen (Luhmann 1987, S. 390ff.). Das bedeutet, dass sich Kommunikation durch das Wechselspiel von Erwartungen, die durch Einschränkung des Möglichkeitsspielraums entstehen, erneuert, also Anschlusskommunikation ermöglicht wird. Des Weiteren spricht Luhmann von Erwartungserwartungen, um Situationen mit doppelter Kontingenz ordnen zu können. „Soziale Relevanz und damit Eignung als Struktur sozialer Systeme gewinnen Erwartungen aber nur, wenn sie ihrerseits wieder erwartet werden können.“ (Luhmann 1987, S. 411) Im Zusammenhang mit Erwartungen und Handlungen führt Luhmann den Begriff der Entscheidung ein: „Von Entscheidung soll immer dann gesprochen werden, wenn und soweit die Sinngebung einer Handlung auf eine an sie selbst gerichtete Erwartung reagiert.“ (Luhmann 1987, S. 400) Das bedeutet, dass Entscheidungen als auf Erwartung reagierende Handlungen verstanden werden können, also als Handlungen, die Erwartungen erwarten und diese durch Selektion erfüllen können oder auch nicht (Schaffung der Alternative von Konformität oder Abweichung). Luhmann unterscheidet drei Abstraktionsebenen der Systembildung, die dem Vergleich verschiedener Möglichkeiten, Systeme zu bilden, dienen. Die erste Ebene bezieht sich auf Systeme im Allgemeinen und untergliedert sich in der zweiten Ebene in Maschinen, Organismen, soziale und psychische Systeme. Soziale Systeme wiederum werden auf der dritten Ebene in Interaktionen, Organisationen und Gesellschaften unterteilt (Luhmann 1987, S. 16). Unter Gesellschaft versteht Luhmann das umfassende Sozialsystem, das alles Soziale, d.h. die Gesamtheit aller aufeinander bezogenen Kommunikationen, einschließt (Luhmann 1987, S. 555ff.; Luhmann 1997, S. 78ff.). In der Gesellschaft bilden sich über funktionale Differenzie-

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

117

rung Teilsysteme wie das Wirtschaftssystem, das Rechtssystem oder das politische System, die als Funktionssysteme bezeichnet werden. Interaktionssysteme hingegen schließen alles ein, was als anwesend behandelt werden kann, d.h. Kommunikationen, die über die wechselseitige Wahrnehmung von Anwesenden bezogen werden (Luhmann 1987, S. 560ff.; Luhmann 1997, S. 813ff.). Sie verlangen demnach eine physische Anwesenheit von Kommunikationspartnern. Organisationssysteme verlangen, wie auch Funktionssysteme, keine Kommunikation unter Anwesenden. Sie sind im Gegensatz zu Funktionssystemen aber adressierbar. Wie auch alle anderen sozialen Systeme bestehen Organisationen aus Kommunikationen, knüpfen eine Mitgliedschaft aber an bestimmte Bedingungen (Einhaltung von organisatorischen Regeln), von denen sie einen Eintritt oder Austritt abhängig machen. Organisationen entstehen und reproduzieren sich durch die Kommunikation von Entscheidungen und das System wird auf dieser Operationsbasis operativ geschlossen. „Alle Entscheidungen des Systems lassen sich mithin auf Entscheidungen des Systems zurückführen.“ (Luhmann 2006, S. 63) Entscheidungsprämissen (Entscheidungsprogramme, Kommunikationswege, Personaleinsatz) bilden dabei die Strukturen von Organisationen, die den Entscheidungsraum einschränken, ohne jedoch künftige Entscheidungen festzulegen (Luhmann 2006, S. 222ff.). Durch die unterschiedlichen Möglichkeiten der Systembildung entsteht keinesfalls eine völlige Trennung der Systeme, sondern sie sind vielmehr ineinander verschachtelt. In der Gesellschaft existieren zahlreiche Organisationen, die Teilsysteme von ausdifferenzierten Teilsystemen der Gesellschaft sind (Wirtschaft, Politik, Recht, etc.). Gleichzeitig sind eine unüberschaubare Anzahl von Interaktionssystemen Teilsysteme der Gesellschaft (Kneer und Nassehi 2000, S. 43; Kieser und Ebers 2006, S. 432). Die Gesellschaft ist jedoch mehr als die Summe aller Organisations- und Interaktionssysteme, da in der Gesellschaft eine Vielzahl von sozialen Handlungen auftritt, die nicht aus Organisationen oder Interaktionen hervorgebracht werden (Kneer und Nassehi 2000, S. 43). 4.2.4

Systemische Denkansätze

Die klassische analytische Denkweise auf Basis von Ursache-Wirkungs- bzw. Kausalzusammenhängen hat sich insbesondere in Ingenieursdisziplinen und im Zusammenhang mit kleinen linearen Systemen als ein erfolgreiches Mittel zur Komplexitätsreduktion etabliert. Bei komplexen Systemen mit den bereits beschriebenen Charakteristika (siehe Kapitel 4.2.1) ist jedoch eine systemische Denkweise erforderlich, die ganzheitliche und dynamische Aspekte berücksichtigt (Senge 2006, S. 88). „Durch die Disziplin des Systemdenkens können wir die grundlegenden „Strukturen“ von komplexen Situationen erkennen und zwischen Veränderungen mit starker und geringer Hebelwirkung unterscheiden.“ (Senge 2006, S. 89) Das Systemdenken bezeichnet Senge als integrative und übergreifende fünfte Disziplin (Senge 2006, S. 21), die die vier Kerndisziplinen personale Kompetenz (personal mastery), mentale Modelle (mental models), gemeinsame Vision (shared vision) und Teamlernen (team learning) zu einer

118

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

ganzheitlichen Theorie und Praxis zur Gestaltung einer lernenden Organisation zusammenfügt. Als Ursache für Probleme im Umgang mit komplexen Systemen sehen Dörner u.a. Ökonomietendenzen, „durch die der Denkende dazu bewogen wird, bestimmte Denkschritte einfach auszulassen oder aber sie soweit wie möglich zu vereinfachen.“ (Dörner 2003, S. 310) Eine weitere Ursache ist in dem Auslassen von Problemen im Denkprozess zu sehen. Probleme, die nicht unmittelbar sichtbar sind, werden häufig ignoriert. Sie spielen in komplexen dynamischen Systemen jedoch eine wichtige Rolle, „da sie sich erst als Neben- oder Fernwirkungen des eigenen Handelns ergeben können.“ (Dörner 2003, S. 313) Im Zusammenhang mit den unterschiedlichen Denkweisen spricht Senge von zwei unterschiedlichen Arten von Komplexität, der Detail- und der dynamischen Komplexität (Senge 2006, S. 91ff.). Die Detailkomplexität ist durch eine Vielzahl an veränderlichen Größen gekennzeichnet. Dynamische Komplexität hingegen beschreibt Senge folgendermaßen: „Eine dynamische Komplexität liegt vor, wenn dieselbe Handlung kurzfristig völlig andere Auswirkungen hat, als langfristig. Auch wenn eine Handlung sich an einer Stelle des Systems auf eine bestimmte Weise auswirkt, in einem anderen Teil des Systems jedoch ganz andere Auswirkungen hat, handelt es sich um einen Fall von dynamischer Komplexität.“ (Senge 2006, S. 92) Er sieht in dem Systemdenken ein grundsätzliches Umdenken, d.h. die Wahrnehmung von Wechselbeziehungen anstelle linearer Ursache-Wirkungs-Ketten sowie die Wahrnehmung von Veränderungsprozessen anstelle von Schnappschüssen (Senge 2006, S. 94), und somit ein Mittel im Umgang mit dynamischer Komplexität. Dabei spielt das Konzept des „Feedback“ eine entscheidende Rolle, um Wechselbeziehungen und Veränderungsmuster erkennen zu können (Senge 2006, S. 94). Viele dieser Muster und Wechselbeziehungen bleiben im Rahmen von Systemanalysen (z.B. Simulationen) jedoch unerkannt, da sie sich auf die Detailkomplexität, also auf eine Unmenge an Variablen und komplexen Detailanordnungen, konzentrieren (Senge 2006, S. 93). Bei der Unterscheidung der Komplexitätsarten betont Senge die Bedeutung des Verständnisses der dynamischen Komplexität für das Management: „In den meisten Managementsituationen liegt die wahre Hebelwirkung in einem Verständnis der dynamischen Komplexität, nicht der Detailkomplexität.“ (Senge 2006, S. 92) Einer detaillierten Betrachtung von Einflussmöglichkeiten und Auswirkungen der grundlegend unterschiedlichen Denkansätze im Bereich des Managements und der Managementtheorie widmet sich auch Malik (Malik 2008, S. 32ff.). Er sieht die Beherrschung von Komplexität als das Grundproblem von Management, wenn es im Sinne von Gestalten und Lenken einer Institution im Allgemeinen oder von soziotechnischen Systemen betrachtet wird und nicht rein als Management von Wirtschaftsunternehmen (Malik 2008, S. 33). Bei der Managementtheorie werden zwei grundlegend verschiedene Ansätze oder Theorietypen unterschieden, mit denen das Problem der Komplexitätsbe-

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

119

herrschung gelöst werden kann: der konstruktivistisch-technomorphe und der systemischevolutionäre Ansatz (Malik 2008, S. 33). Beim konstruktivistisch-technomorphen Ansatz gilt die Maschine als Basisparadigma sowie die Grundvorstellung, dass eine Maschine bis in alle Einzelteile durchgeplant, konstruiert und beherrscht werden kann, um die geforderte Funktion, Zuverlässigkeit und Effizienz zu erbringen. Dies setzt voraus, dass ein vollständiges Wissen über alle Details der Einzelteile und vollständige Informationen über deren Zusammenwirken vorhanden sind (Malik 2008, S. 34). Der zweite, systemisch-evolutionäre Ansatz hingegen besitzt als Basisparadigma die spontan, sich selbst generierenden Ordnungen nach Hayek (von Hayek 1980, S. 57ff.), die dadurch entstehen, dass ihre Elemente (Individuen) allgemeine Regeln des Verhaltens befolgen, ohne dass vorausgesetzt werden muss, dass sie diese Regeln kennen, nennen oder beschreiben könnten. Die dadurch entstehenden Regelmäßigkeiten ermöglichen es, sich zu orientieren, d.h. sein eigenes Verhalten mit dem Verhalten anderer auf Basis stabiler Erwartungen zu koordinieren und somit Komplexität, die aus der andernfalls bestehenden Unberechenbarkeit und Unvorhersehbarkeit des Verhaltens anderer entstehen würde, zu beherrschen (Malik 2008, S. 37). Der konstruktivistische Ansatz unterliegt der Vorstellung einer vollständigen Kontrollierbarkeit bis ins Detail, der evolutionäre Ansatz hingegen schließt eine vollständige Kontrolle und Beherrschung aus (Malik 2008, S. 41). Um die beiden Theorietypen klarer zu differenzieren und deren Konsequenzen aufzuzeigen, diskutiert Malik unterschiedliche Prämissen der beiden Typen (siehe Tabelle 13) und stellt sie einander gegenüber (Malik 2008, S. 44ff.). Malik spricht die Erfolge an, die in technologischer Hinsicht mit dieser Denkweise erzielt wurden, aber auch die Gefahr, die durch den Glauben an die Verallgemeinerungsfähigkeit dieses Paradigmas außerhalb der Ingenieurswissenschaften gegeben ist. So wird bei einem Scheitern eher nach Modifikations- und Weiterentwicklungsmöglichkeiten gesucht, als diesen Theorietyp gänzlich in Frage zu stellen (Malik 2008, S. 43). Malik führt an, dass versucht wird, eine systemische Realität mithilfe konstruktivistischer Methoden unter Kontrolle zu bringen. Wo auch immer dann mangelnde Kontrolle festgestellt wird, wird nicht versucht, dies auf ein prinzipielles Versagen des konstruktivistischen Denkschemas zurückzuführen, sondern auf einen momentan vorherrschenden Mangel konstruktivistischer Kontrolle, die jedoch in dieser Form dann noch verstärkt werden soll (Versagen von Regeln wird mit weiteren Regeln begegnet, auf Planungsfehler wird mit weiterer Planung reagiert, usw.) (Malik 2008, S. 42).

120

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme Konstruktivistisch-technomorph

Systemisch-evolutionär

Management…

Management…

1.

…ist Menschenführung

…ist Gestaltung und Lenkung ganzer Institutionen in ihrer Umwelt

2.

…ist Führung weniger

…ist Führung vieler

3.

…ist Aufgabe weniger

…ist Aufgabe vieler

4.

…ist direktes Einwirken

…ist indirektes Einwirken

5.

...ist auf Optimierung ausgerichtet

…ist auf Steuerbarkeit ausgerichtet

6.

…hat im Großen und Ganzen ausreichende Information

…hat nie ausreichende Informationen

7.

…hat das Ziel der Gewinnmaximierung

…hat das Ziel der Maximierung der Lebensfähigkeit

Tabelle 13: Denkmuster in der Managementtheorie Quelle: (Malik 2008, S. 44)

Eine ähnliche Gegenüberstellung der unterschiedlichen Denkweisen liefert Hamilton im Zusammenhang mit dem Management von Dynamik und Komplexität bei der Softwareentwicklung. Tabelle 14 zeigt die Unterschiede zwischen dem analytischen und systemischen Ansatz. Analytischer Ansatz

Systemischer Ansatz

Konzentration auf isolierte Elemente

Konzentration auf das Zusammenspiel der Elemente

Konzentration auf die Art des Zusammenspiels

Konzentration auf die Effekte des Zusammenspiels

Das Augenmerk liegt auf den Details

Das Augenmerk liegt auf der globalen Perspektive

Man ändert immer nur jeweils eine Größe am System

Es werden mehrere Systemgrößen gleichzeitig verändert

Jedes Element wird unabhängig betrachtet

Es wird das ganze System betrachtet

Der Vorgang ist reversibel

Der Vorgang ist nicht reversibel

Tabelle 14: Unterschiede zwischen dem analytischen und systemischen Ansatz Quelle: (Hamilton 2006, S. 112)

Des Weiteren unterbreitet Hamilton einen Vorschlag (siehe Abbildung 40) zur praktischen Anwendung des systemischen Denkens (Hamilton 2006, S. 112ff.). Über kausal-analytische Prozesse wird ein Thema in Unterthemen gegliedert (systematisches Denken), die durch bestimmte Muster zu einer verallgemeinerten Sicht zusammengefasst werden.

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

121

Vergleichen

Ähnliche Aspekte

Analyse

Ursprungsthematik

Synthese

Analyse

Synthese

verallgemeinerte Sicht (A)

abstrahierte Thematik

Systemischer Denkzyklus

Korrektur

(C)

Planen

wahrscheinlichste Sicht (D)

Systemisches Denken

Überprüfen

Sichten

(B)

(2)

Bearbeiten (1)

Deming-Zyklus als Basis für iterativ(3) inkrementelles Arbeiten

Abbildung 40: Analytisches und systemisches Denken Quelle: (Hamilton 2006, S. 113)

Dadurch, dass mehrere unterschiedliche Perspektiven auf ein Problem existieren, entstehen zahlreiche Sichten, die durch synthetisches Denken wieder zu einem größeren Ganzen (abstrahierte Thematik) zusammengesetzt werden. Kombiniert ergeben diese beiden Schritte ein systemisches Denken. Hamilton fügt hinzu, dass das systemische Denken in einen zirkulären Prozess eingebettet werden muss, um die Ursprungsthematik und die abstrahierte Thematik miteinander vergleichen und bewerten zu können (Hamilton 2006, S. 112f.). 4.2.5

Management-Kybernetik

Die Kybernetik (vom griechischen kybernétes = Steuermann abgeleitet) ist eine disziplinübergreifende Wissenschaft, die wie die Systemtheorie aus den Naturwissenschaften hervorging und Konzepte zur Steuerung und Regulierung von Systemen untersucht und erforscht. Erkenntnisse über Wechselwirkungen und Prozesse in biologischen Organismen und der Physik dienten als Grundlage, diese in der Kybernetik zusammenzuführen und gemeinsam zu betrachten. So wurden Gesetzmäßigkeiten in Steuerungs- und Regelungsvorgängen stabiler dynamischer Systeme, wie z.B. Technik, Biologie und Ökonomie, untersucht (Bandte 2007, S. 63ff.).

122

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Der Begriff der Kybernetik geht auf Norbert Wiener zurück, der ihn 1947 nach mehreren Macy-Konferenzen zum Thema zirkulärer Systeme mit Rückkopplungseffekten formulierte und 1948 in „Cybernetics: or, control and communication in the animal and the machine“ (Wiener 1948) veröffentlichte. Wiener untersuchte Systeme, die sich auf Basis der Rückkopplung selbst regeln und steuern. Populäre Vertreter und Pioniere im Bereich der Kybernetik sind neben Wiener vor allem Arturo Rosenblueth, Walter B. Cannon, Julian Bigelow, Warren McCulloch, Walter Pitts, John von Neumann, Ludwig von Bertalanffy, Claude Shannon, Warren Weaver, Margaret Mead, Gregory Bateson, Heinz von Foerster und Ross Ashby (vgl. (Malik 2008, S. 350). Zu den Erweiterungen und Anwendungsfeldern der klassischen Kybernetik zählen u.a. die Kybernetik zweiter Ordnung (Heinz von Foerster), die ManagementKybernetik (Stafford Beer), System Dynamics (Jay Wright Forrester), der radikale Konstruktivismus (Ernst von Glasersfeld) und die Autopoiesis (Francisco J. Varela und Humberto R. Maturana). Wie die Systemtheorie ist auch die Kybernetik durch eine disziplinübergreifende und ganzheitliche Denkweise charakterisiert. Bei beiden Wissenschaften ist es von besonderer Bedeutung, nicht nur statisch-strukturelle, sondern auch dynamisch-funktionale Aspekte erfassen und gestalten zu können (Malik 2008, S. 158; Vahs 2003, S.37). Die Entwicklung der kybernetischen Forschung wird in zwei Phasen unterteilt (vgl. (Maruyama 1963)): Kybernetik I (erster Ordnung) und Kybernetik II (zweiter Ordnung). Die Kybernetik erster Ordnung, oder auch die Kybernetik beobachteter Systeme (vgl. (Abramovitz und von Foerster 1995)), untersucht gleichgewichtserhaltende Systeme und stellt dabei die Stabilität solcher Systeme in den Mittelpunkt. Zur Erhaltung der Stabilität nimmt ein Beobachter durch die Vorgabe von Grenzen und Strukturen und mithilfe von Rückkopplungen steuernd Einfluss auf das System. Solche Systeme werden als isoliert von ihrer Umwelt und deterministisch angesehen. Die Kybernetik II, oder auch die Kybernetik von beobachtenden Systemen (vgl. (Abramovitz und von Foerster 1995)), fokussiert die Konstruktion von Modellen kybernetischer Systeme. Dabei wird der Einfluss des Beobachters auf das beobachtete System untersucht. Der Beobachter selbst wird daher nicht separat vom System betrachtet, sondern eine Abhängigkeit der Systembeschreibung vom Beobachter angenommen, was einer konstruktivistischen Auffassung entspricht (Bandte 2007, S. 64). Eine besondere Bedeutung kommt in diesem Zusammenhang der Selbstreferenz und der Selbstorganisation zu. Die zweite Phase der kybernetischen Forschung beschäftigt sich insbesondere mit Problemen der Instabilität, des Wandels und der Ko-Evolution. Im Gegensatz zur Kybernetik erster Ordnung wird Ungleichgewicht als Normalfall und Voraussetzung für den Wandel aufgefasst (Hafner 2006, S. 66; Bandte 2007, S. 64). Die Management-Kybernetik bzw. die systemtheoretisch-kybernetische Managementlehre orientiert sich sowohl an der Kybernetik als auch an der Systemtheorie und besitzt als wesent-

Komplexe Systeme aus der Sicht unterschiedlicher wissenschaftlicher Disziplinen und Theorien

123

liches Ziel den Entwurf eines evolutionären Managements, das sich von mechanistischen bzw. konstruktivistisch-technomorphen Denkweisen und einer darauf basierenden rationalen Organisationsgestaltung abgrenzt (Malik 2008, S. 39; Bandte 2007, S. 60; Kieser und Ebers 2006, S. 343). Die Management-Kybernetik erforscht Formen komplexer menschlicher Systeme, wie z.B. Unternehmensorganisationen und stellt somit einen Ansatz zur Komplexitätsbeherrschung in und zur Steuerung von Organisationen dar. Im Fokus stehen dabei Probleme wie Anpassungsfähigkeit, Flexibilität, Lernfähigkeit, Evolution, Selbstregulierung und Selbstorganisation (Malik 2008, S. 71). Ziel ist es, mithilfe kybernetischer Lenkungsstrukturen und Rückkopplungsschleifen soziale Systeme so zu organisieren und zu steuern, dass sie die Komplexität ihrer Umwelt, die aus permanenten Änderungen und der Änderungsgeschwindigkeit resultiert, bewältigen und ihre „Lebensfähigkeit“ sicherstellen können. Eine der Grundlagen bildet das von Stafford Beer entwickelte Modell des lebensfähigen Systems (Viable System Model) (Beer 1995). Im Folgenden wird kurz auf das der system-kybernetischen Managementlehre zugrunde liegende Komplexitätsverständnis am Beispiel des St. Galler Ansatz eingegangen. Unter Komplexität versteht Malik, neben Ulrich, Probst und Dyllick einer der bedeutendsten Vertreter des St. Galler Ansatzes (Kieser und Ebers 2006, S. 343), die Tatsache, „dass reale Systeme ungeheuer viele Zustände aufweisen können.“ (Malik 2008, S. 168) Komplexität kann quantifiziert und mithilfe des Begriffs der Varietät gemessen werden, den Malik folgendermaßen definiert: „Varietät ist die Anzahl der unterscheidbaren Zustände eines Systems bzw. die Anzahl der unterscheidbaren Elemente einer Menge“ (Malik 2008, S. 168). Seine Definition geht auf das von William Ross Ashby entwickelte Gesetz der Requisite Variety (Ashby 1956, S. 206ff.) zurück, welches einen zentralen Ausgangspunkt des St. Galler Ansatzes bildet. Das Gesetz besagt, dass nur Varietät durch Varietät zerstört werden kann. Für komplexe Systeme bedeutet es demnach im Sinne der Kybernetik, dass ein System mit gegebener Komplexität nur mithilfe eines mindestens ebenso komplexen Systems unter Kontrolle gebracht werden kann oder anders ausgedrückt, die verfügbare Lenkungsvarietät relativ zu den beabsichtigten Zielen mindestens genauso groß sein muss, wie die Varietät des zu lenkenden Systems (Malik 2008, S. 175). Dies bedeutet wiederum, dass auch Modelle, die von einem System angefertigt werden, annähernd gleich viel Komplexität besitzen müssen, wie das System selbst, wenn es ein sinnvoller Bezugspunkt für Lenkungsmaßnahmen sein soll (Malik 2008, S. 92). Die Aussage bezüglich der Systemmodelle beruht auf dem Conant/ Ashby-Theorem (Conant und Ashby 1970). Das Theorem besagt, dass der Erfolg in der Regulierung eines Systems die Erstellung eines hinreichend ähnlichen Modells voraussetzt. Auf das Management übertragen bedeutet es, dass das Management nicht besser sein kann als das zugrunde liegende Modell, da die Wahrnehmung von Fakten von dem Modell bestimmt wird.

124

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Einen weiteren Ausgangspunkt des Ansatzes bildet das zuvor erwähnte Konzept der spontanen Ordnung. Es wurde bereits angesprochen, dass sich bei spontanen Ordnungen evolutionär bedingt Verhaltensregeln aus der Interaktion von Individuen untereinander und mit ihrer Umwelt bilden. Durch die wechselseitige antizipierende Anpassung und Modifikation von Verhalten passen sich die beteiligten Personen selbständig an ihre Umwelt an, und ihre Verhaltensregeln entwickeln sich evolutionär durch Selbstorganisation weiter (Kieser und Ebers 2006, S. 344). Dabei stehen nie genügend Informationen zur Verfügung, um das Verhalten ausschließlich analytisch, also nach Ursache-Wirkungs-Zusammenhängen, auszurichten (Bandte 2007, S. 61). Die Ursache dafür liegt in der begrenzten Informationsverarbeitungskapazität28 und ist somit ein weiterer Aspekt der Komplexität, der für das Management einer Unternehmung von hoher Relevanz ist (Malik 2008, S. 179). Auf den Management-Kontext übertragen bedeutet Komplexität in diesem Sinne, „dass die formalen Führungsorgane einer Unternehmung niemals über ausreichende Informationen, niemals über genügend Wissen und niemals über genügend Kenntnisse und Fertigkeiten verfügen können, um eine Unternehmung, die sich jenseits der Komplexitätsbarriere befindet, im Detail zu steuern und zu gestalten.“ (Malik 2008, S. 76) Das Überschreiten einer Komplexitätsbarriere sieht Malik durch den Übergang einer integral geführten Unternehmung zu einer arbeitsteilig geführten Unternehmung gegeben. Durch das Problem der Delegation ergeben sich Probleme der Aufteilung von Funktionen auf mehrere Personen sowie Probleme der Arbeits- und Wissensteilung. Daraus wiederum resultiert das Problem der Re-Integration von aufgeteilten Aufgaben und Funktionen (Malik 2008, S. 75). 4.3

Softwareevolution und Komplexität

Softwaresysteme unterliegen einem kontinuierlichen Änderungsprozess. Ursachen für Änderungen der Software können, wie bereits erwähnt, unterschiedliche Faktoren sein, wie z.B. neue Geschäftsanforderungen, Veränderung von Organisationsstrukturen, neue bzw. bessere Technologien oder die Behebung von Fehlern. Die Entwicklung einer Software ist somit nicht mit ihrer Auslieferung abgeschlossen, sondern wird im Laufe ihres Lebenszyklus ständig weiterentwickelt. Sommerville merkt an, dass die Änderung von Software sehr wichtig ist, da Organisationen völlig abhängig von ihren Softwaresystemen sind. Sie zählen aufgrund des hohen Investitionsvolumens zum Betriebsvermögen der Organisation, welches nur durch weitere Investitionen in Systemänderungen nachhaltig gesichert werden kann (Sommerville 2004, S. 489).

28

Vgl. dazu (Bremermann 1962)

Softwareevolution und Komplexität

125

Jede Veränderung der Software stellt einen Übergang des Softwaresystems in einen anderen Zustand dar und wird als Softwareevolution bezeichnet. Es ist durchaus möglich, dass der Bedarf von Änderungen und somit die Evolution der Software sich schon offenbart, bevor die Software überhaupt ausgeliefert oder in Betrieb genommen wurde. Es ist daher keine Seltenheit, dass an zukünftigen Releases einer Software schon vor dem Initialrelease entwickelt wird (Sommerville 2004, S. 489). Das Phänomen der Softwareevolution wurde in den späten 60er von Lehmann identifiziert, jedoch erst 1974 als Begriff eingeführt (Lehman und Ramil 2003, S. 33). Aus den Erkenntnissen entwickelte sich ein ganzes Forschungsfeld, das sich in den Folgejahren mit der Dynamik der Programmevolution auseinandersetzte (Lehman und Ramil 2002, S. 277). Aufbauend auf diesen Arbeiten folgten in den 90er Jahren weitere Forschungen und Studien, die den Stellenwert von Feedback im Evolutionsprozess untersuchten. Die Untersuchungen fanden im Rahmen des FEAST-Projektes und auf Basis der gleichnamigen Hypothese statt und fokussierten die Evolution sogenannter E-type-Software, mit der Anwendungssysteme für die „reale Welt“ implementiert sind (Lehman 1996a). Hinsichtlich der großen Herausforderungen und Probleme bei der Entwicklung von E-type-Software wurde die Annahme formuliert, dass mögliche Einschränkungen bei der Verbesserung von Softwareentwicklungsprozessen auf der Tatsache beruhen, dass der globale Softwareprozess, der u.a. technische, fachliche, Marketing- und personenbezogene Aktivitäten umfasst, ein multi-loop, multi-level Feedback-System konstituiert. Insofern sind sowohl vorwärts, als auch rückwärtsgerichtete Pfade (forward and feedback paths) notwendig, um die gewünschten Änderungen im extern sichtbaren Verhalten zu erreichen. Lehmann fügt hinzu, dass es nicht verwunderlich ist, dass die Verbesserungsaktivitäten die gesetzten Erwartungen nicht erfüllen konnten. Zu sehr fokussieren die Prozessmodelle und Verbesserungen vorwärtsgerichtete technische Pfade und übersehen die vielen Feedback-Pfade und Einschränkungen, die sie der Verbesserung von Projekten auferlegen (Lehman 1996a). Auf Basis der Forschungsarbeiten und Studien wurden von Lehmann und weiteren Forschern acht Hypothesen abgeleitet, die heute als Lehmann’s Gesetze bekannt sind. Folgende acht Gesetze wurden aufgestellt (Lehman 1996b): x

Kontinuierliche Änderungen: Ein Programm, das in einer realen Umgebung verwendet wird, muss sich notwendigerweise verändern, oder es verliert zunehmend seinen Nutzen in dieser Umgebung.

x

Steigende Komplexität: Mit der Evolution eines Programms steigt dessen Komplexität, es sei denn, Aufwände werden betrieben, um es zu erhalten und zu vereinfachen.

x

Selbst-Regulierung: Programmevolution ist ein selbst-regulierender Prozess, bei dem die Produkt- und Prozessmerkmale fast konstant bleiben.

126

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

x

Erhalt der organisatorischen Stabilität: Die effektive globale Rate an Entwicklungstätigkeiten bleibt während des Lebenszyklus eines Programms im Durchschnitt gleich und ist unabhängig von den eingesetzten Ressourcen.

x

Erhalt der Vertrautheit: Während des Lebenszyklus eines weiterentwickelten Programms bleibt der Umfang aufeinanderfolgender Releases statistisch invariant.

x

Ständiges Wachstum: Die Funktionalität eines Programms muss kontinuierlich wachsen, um den Anforderungen der Benutzer gerecht zu werden und sie zufrieden zu stellen.

x

Abnehmende Qualität: Es wird eine abnehmende Qualität des Programms wahrgenommen, es sei denn, das Programm wird an die sich ändernde operative Umgebung angepasst.

x

Feedback-System: Entwicklungsprozesse konstituieren multi-loop, multi-level Feedback-Systeme und müssen auch als solche angesehen und behandelt werden, um erfolgreich modifiziert und verbessert werden zu können.

Wie am zweiten Gesetz zu erkennen ist, ist die Komplexität von der Evolution, also der Weiterentwicklung und den Änderungen des Softwaresystems abhängig, und diese Änderungen müssen, bedingt durch die ersten sieben Gesetze, notwendigerweise vorgenommen werden. Eine entscheidende Einflussgröße ist somit die Frequenz, in der Änderungen vorgenommen werden können. Insbesondere neue Technologien ermöglichen eine höhere Entwicklungsgeschwindigkeit und verkürzen somit die Änderungsfrequenz, was wiederum zu einem Anstieg der Komplexität führen kann. 4.4

Komplexität softwaretechnischer Systeme

In den vorigen Kapiteln wurden zunächst unterschiedliche Ebenen der Systembildung komplexer Systeme vorgestellt. Des Weiteren wurde näher erörtert, was Komplexität im Kontext systemtheoretischer Ansätze bedeutet. Anschließend wurde in das Forschungsfeld der Softwareevolution eingeführt, in der Komplexität in Relation mit der Änderungsnotwendigkeit von Softwaresystemen gesetzt wird. Die folgenden Kapitel setzen sich mit der Komplexität von softwaretechnischen Systemen auseinander. In diesem Zusammenhang stehen insbesondere Algorithmen, Strukturen oder Daten im Fokus der Betrachtungen. Die Forschung beschäftigt sich im Bereich der Softwarekomplexität mit unterschiedlichen Komplexitätsarten und -metriken sowie Verständnisstrategien, um Software besser erfassen und verstehen zu können. Seit der Softwarekrise Mitte der 1960er und der NATO-Tagung 1968 in GarmischPartenkirchen ist der Begriff der Komplexität im Zusammenhang mit Software nicht mehr wegzudenken. Brooks schreibt in seinem Artikel No Silver Bullet (Brooks 1995, S. 179ff.), dass Software komplexer ist, als jedes andere vom Menschen geschaffene Konstrukt. Brooks

Komplexität softwaretechnischer Systeme

127

differenziert bei den Schwierigkeiten, die im Zusammenhang mit Softwaretechnologie entstehen, zwischen der Essenz, d.h. den inhärenten Schwierigkeiten in der Natur von Software, und Unfällen, also jenen Schwierigkeiten, die in der Produktion entstehen, aber vermeidbar wären bzw. zu reduzieren sind. Dabei sieht er in der Komplexität eine essenzielle Eigenschaft von Software, die jedoch oft durch abstrakte und vereinfachte Beschreibungen selber zu abstrakt betrachtet wird (Brooks 1995, S. 182f.). Glass berichtet in einem Praxisbeitrag über zwei Forschungsergebnisse, in denen sich seiner Meinung nach das Ausmaß der Komplexität von Software manifestiert (Glass 2002, S. 19). Das erste Ergebnis sagt aus, dass eine Steigerung der Problemkomplexität um 25% eine Steigerung der Komplexität der Softwarelösung um 100% nach sich zieht (Woodfield 1979). Das zweite Ergebnis, welches auch seinen persönlichen Einschätzungen aus der Praxis entspricht, sagt aus, dass im Laufe der Entwicklung einer Software explizite Anforderungen in impliziten Designanforderungen des Faktors 50 oder größer resultieren (Glass 2002, S. 20). Booch, der Software eine inhärente Komplexität zuschreibt, merkt an, dass die Komplexität von Softwaresystemen oft die intellektuelle Kapazität von Menschen übersteigt (Booch et al. 2007, S. 42). Aus Miller’s viel zitierten Experimenten geht hervor, dass ein Mensch nur bis zu sieben plus/minus zwei Informationseinheiten gleichzeitig verarbeiten kann (Miller 1956). Nach Booch sind vier Faktoren zu beobachten, von denen sich Komplexität ableitet. Als Faktoren nennt er die Komplexität der Problemstellung, die Schwierigkeit, den Entwicklungsprozess zu steuern, die Flexibilität, die geliefert werden soll und die Probleme bei der Charakterisierung des Verhaltens diskreter Systeme (Booch et al. 2007, S. 5). Dabei gelten die Zerlegbarkeit, die Abstraktion und die Hierarchie als zentrale Prinzipien zur Komplexitätsbeherrschung im Bereich der Softwareentwicklung (Booch et al. 2007, S. 18ff.). In der Literatur wird der Komplexitätsbegriff im Bereich der Softwareentwicklung sehr kontrovers diskutiert und auf unterschiedlichen Ebenen analysiert. Eine klare Bedeutung und Abgrenzung des Begriffs lässt sich daher nur sehr schwierig gestalten. Zu den unterschiedlichen Ebenen zählen bspw. das Softwaresystem, die an der Entwicklung beteiligten Menschen, deren Zusammenarbeit, Kommunikation und Interaktion, der zugrunde liegende Entwicklungsprozess, das Management und der Betrieb sowie das Unternehmen und seine Umwelt. Wird Komplexität auf einer bestimmten Ebene oder in einem bestimmten Kontext reduziert, wird dadurch eine neue Ebene von Komplexität eröffnet. Lilienthal identifiziert drei generelle Ebenen, in die sich der Begriff Komplexität über die in der Literatur aufzufindenden Aussagen einordnen lässt (Lilienthal 2008). Als Ebenen führt sie die Komplexität der Interaktion im Entwicklungsteam, die Verstehenskomplexität beim Menschen und die Softwarekomplexität im technischen Artefakt an.

128

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Eine klassische Definition für Softwarekomplexität formuliert Basili (Basili 1979). Komplexität ist demnach das Maß an verbrauchten Ressourcen eines anderen Systems bei der Interaktion mit einem Stück Software. Kategorien von Systemen, die mit Software interagieren können sind Maschinen, andere Software, Menschen und die externe Umwelt. Falls es sich bei dem interagierenden System um Software handelt, fokussieren die Maße die Anzahl der Schnittstellen. Handelt es sich bei dem interagierenden System um Menschen, beschäftigen sich die Maße mit dem menschlichen Aufwand, die Software zu verstehen, zu warten bzw. in Stand zu halten, zu ändern, zu testen, etc.. Die externe Umwelt hingegen gibt eine Menge an Einschränkungen vor, wie z.B. Reisezeiten in Softwareprojekten oder physikalische Grenzen. Harrison et al. beschreiben Softwarekomplexität als ein Maß, um Aussagen darüber treffen zu können, wie schwer es ist, mit einem Programm zu arbeiten oder dieses zu verstehen (Harrison et al. 1982, S. 65). Andere Autoren wie Henderson-Sellers (Henderson-Sellers 1995) oder Zuse (Zuse 1991) hingegen führen lediglich an, dass Komplexität nur schwer zu definieren ist. Henderson-Sellers bspw. trifft in Bezug auf den Komplexitätsbegriff nur die sehr allgemeine Aussage, dass Komplexität eine Charakteristik von Software ist, die Ressourcen für das Verständnis, Design und die Codierung benötigt (Henderson-Sellers 1995). 4.4.1

Arten von Komplexität

Auf Ebene der Softwaretechnik kann Komplexität aus unterschiedlichen Perspektiven diskutiert und betrachtet werden. Abhängig von einer bestimmten Perspektive können dann mehrere unterschiedliche Merkmale von Bedeutung sein, um zu verstehen, worum es sich bei Komplexität handelt (Zuse 1991; Fenton und Pfleeger 1998). Auf den großen Interpretationsspielraum des Komplexitätsbegriffs ist es wohl auch zurückzuführen, dass in der Literatur unterschiedliche Arten von Komplexität im Kontext von Software betrachtet werden und darauf aufbauend verschiedene Komplexitätsmaße abgeleitet und entwickelt wurden. Die unterschiedlichen Arten von Komplexität überschneiden sich zum Teil oder können einander direkt zugeordnet werden. Eine Übersicht, welche Arten von Komplexität unterschiedlicher Autoren sich einander zuordnen lassen, liefert Lilienthal (Lilienthal 2008, S. 14ff.). Im Folgenden werden exemplarisch Komplexitätsarten unterschiedlicher Autoren vorgestellt. Ebert differenziert zwischen einer probleminhärenten und einer lösungsabhängigen Komplexität (Ebert 1995a). Die probleminhärente Komplexität bezieht sich auf die Komplexität der zugrunde liegenden Problemstellung, die es zu lösen gilt, also bspw. einen Teil der Realwelt, der mithilfe einer softwaretechnischen Lösung abgebildet werden soll. Die lösungsabhängige Komplexität hingegen umfasst Komplexitätsaspekte der softwaretechnischen Lösung, wie z.B. die verwendeten Algorithmen, deren Struktur oder der Aufwand, der nötig ist, um die Software verstehen zu können.

Komplexität softwaretechnischer Systeme

129

Curtis et al. grenzen Komplexität in Berechnungskomplexität und psychologische Komplexität ab (Curtis et al. 1979, S. 96). Bei der Berechnungskomplexität verweisen sie auf eine Definition von Rabin. Die Berechnungskomplexität bezieht sich demnach auf „the quantitative aspects of the solutions of computational problems.“ (Rabin 1977, S. 625) Unter der psychologischen Komplexität verstehen die Autoren „characteristics of software which make it difficult to understand and work with.“ (Rabin 1977, S. 625) Fenton und Pfleeger unterscheiden abhängig von der Perspektive zwischen der Problemkomplexität, der algorithmischen, der strukturellen und der kognitiven Komplexität (Fenton und Pfleeger 1998, S. 245). Die Problemkomplexität, welche auch Berechnungskomplexität genannt wird, misst die Komplexität des zugrunde liegenden Problems. Die algorithmische Komplexität spiegelt die Komplexität des Algorithmus wider, der implementiert wurde, um ein Problem zu lösen. In einer gewissen Art und Weise wird durch diese Art der Komplexität die Effizienz der Software gemessen. Die strukturelle Komplexität misst die Struktur der Software, die zur Implementierung des Algorithmus verwendet wurde. Als Beispiele führen die Autoren Kontrollfluss-, hierarchische oder modulare Strukturen an. Mit der letztgenannten kognitiven Komplexität wird der Aufwand gemessen, der benötigt wird, um die Software zu verstehen. Ähnlich wie Ebert diskutieren Fenton und Pfleeger neben den oben angesprochenen Komplexitätsarten die Komplexität des Problems und die Komplexität der Lösung (Fenton und Pfleeger 1998, S. 267). Sie merken an, dass die Lösungskomplexität idealerweise nicht größer sein sollte als die Problemkomplexität. Die Autoren definieren informell die Komplexität des Problems als die Menge an Ressourcen, die für eine optimale Lösung eines Problems benötigt werden. Die Komplexität der Lösung wird in Hinblick auf die Ressourcen betrachtet, die benötigt werden, um eine bestimmte Lösung zu implementieren. Des Weiteren werden die Zeitkomplexität, wobei es sich bei der Ressource um Rechenzeit handelt, und die Raumkomplexität, d.h. die Ressource ist Rechenspeicher, als Aspekte der Lösungskomplexität angesehen. Card und Glass unterscheiden Komplexitätsarten im Kontext des Softwaredesigns (Card und Glass 1990, S. 44ff.). Zu diesen zählen die funktionale Komplexität, die Systemkomplexität, die sich über strukturelle Komplexität und Datenkomplexität definiert, und die prozedurale Komplexität. Die funktionale Komplexität bezieht sich auf die Anzahl und die Natur der Anforderungen, die später die Größe des Softwaresystems ausmachen. Durch die Funktionalität wird das Minimum möglicher Komplexität beim Softwaredesign bestimmt. Die Systemkomplexität drückt sich in der vollbrachten Arbeit innerhalb einzelner Module (Datenkomplexität) und den Verbindungen zwischen den Modulen (strukturelle Komplexität) aus. Die Komplexität des Systemdesigns ist daher definiert als die Summe der intermodulen plus der intramodulen Komplexität (Card und Glass 1990, S. 47). Card und Glass sprechen bei der Beziehung zwischen Daten- und struktureller Komplexität von einem Gesetz einer unvollendeten Erhal-

130

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

tung von Komplexität, da sie einerseits abnimmt, aber gleichzeitig wieder steigt (Card und Glass 1990, S. 47). Die prozedurale Komplexität wird den Algorithmen zugeschrieben, die zur Ausführung von Funktionen und zur Verarbeitung von Daten entwickelt werden. Ein Teil der Komplexität des Algorithmus ist dabei der innewohnenden Schwierigkeit bzw. der Komplexität des Problems zuzurechnen (Card und Glass 1990, S. 50). Auch Henderson-Sellers diskutiert unterschiedliche Arten von Komplexität (HendersonSellers 1995). Zu diesen zählen die Berechnungskomplexität, die psychologische Komplexität sowie die Darstellungskomplexität. Des Weiteren existieren ebenfalls eine strukturelle Komplexität sowie die Problemkomplexität. Die unterschiedlichen Arten von Komplexität können miteinander in Beziehung stehen und korrelieren, so dass neben deren Einzelbetrachtungen eine Analyse in einem gemeinsamen übergeordneten Kontext zu deutlich anderen Ergebnissen führen kann. Werden bspw. Problem- und Lösungskomplexität unabhängig voneinander betrachtet, kann dies zur Folge haben, dass es bei komplexen Lösungen nur noch schwer nachzuvollziehen ist, auf welchen Teil eines komplexen Problems sich die Lösung bezieht, insbesondere dann, wenn für ein Problem zahlreiche Lösungsvarianten existieren. Tritt ein solcher Fall ein, entsteht durch den Verlust von Informationen während der Transformation von Ergebnissen im Problemlösungsprozess zusätzliche Unordnung. Die eigentliche Ursache der Komplexität lässt sich dann nur noch schwer ermitteln, und damit verbunden schwinden die Möglichkeiten, Komplexität weiter zu reduzieren. Verstärkt wird dieser Effekt noch weiter, wenn, wie bereits erwähnt, die Steigerung der Problemkomplexität eine mehrfache Steigerung der Komplexität der Softwarelösung nach sich zieht (Glass 2002; Woodfield 1979). 4.4.2

Komplexitätsmaße

Die Schwierigkeit, den Begriff Komplexität abzugrenzen und zu definieren, spiegelt sich auch in der Entwicklung zahlreicher unterschiedlicher Komplexitätsmaße wider. Wie bereits erwähnt, steht die Entwicklung von Komplexitätsmaßen in enger Verbindung mit der Diskussion über unterschiedliche Komplexitätsarten und ist demnach ebenso abhängig von der Perspektive und spezifischen Merkmalen. Auf eine tiefere Auseinandersetzung bezüglich der Zuordnung von Komplexitätsarten und Komplexitätsmaßen wird jedoch verzichtet. Für eine detaillierte Differenzierung des Verständnisses von Komplexitätsarten und -maßen unterschiedlicher Autoren sei auch an dieser Stelle wieder auf die Arbeit von Lilienthal (Lilienthal 2008) zur Komplexität von Softwarearchitekturen verwiesen. Eine Übersicht verschiedener Komplexitätsmaße führt Kemerer im Rahmen einer Untersuchung des Verhältnisses von Softwarekomplexität und Softwarewartung an (Kemerer 1995). Kemerer unterteilt seine Untersuchungen in die Kategorien Modularitäts- und Strukturmaße, andere Komplexitätsmaße sowie Softwareverständnis (Software Comprehension). Henry und

Komplexität softwaretechnischer Systeme

131

Kafura identifizierten im Bereich der klassischen Softwaremetriken drei große Forschungsfelder (Henry und Kafura 1981). Das erste Forschungsfeld konzentriert sich auf die Erforschung von Metriken auf Basis von lexikalischen Inhalten. Die zweite Forschungsrichtung basiert auf der Anwendung informationstheoretischer Konzepte, wie z.B. Entropie. Das dritte Forschungsfeld fokussiert Systemzusammenhänge durch die Analyse von Informationsflüssen und der Kontrolle von Systemkomponenten. Zu den klassischen und viel zitierten Komplexitätsmaßen zählen bspw. McCabe’s Cyclomatic Number (McCabe 1976), die die Anzahl linear unabhängiger Ausführungspfade im Programm repräsentiert, Halsted’s Programming Effort (Halstead 1977) zur Messung des Implementierungsaufwands auf Basis der Anzahl von Operatoren und Operanden, Oviedo's Data Flow Complexity Measures (Oviedo 1980) auf Basis von Datenflusscharakteristika eines Programms und Henry und Kafuras Information Flow (Henry und Kafura 1981), dessen Messung abhängig von der Prozedurgröße und dem eingehenden (fan-in) und ausgehenden (fan-out) Informationsfluss bei Prozeduren ist. Modernere Ansätze, bei denen es sich um Variationen bzw. Weiterentwicklungen klassischer Komplexitätsmaße handelt oder die aufgrund neuer Forschungserkenntnisse entwickelt wurden, umfassen die Messung kognitiver Komplexität (z.B. (Shao und Wang 2003; Misra und Misra 2007)), die Entwicklung von Entropie-basierten Maßen (z.B. (Harrison 1992)), die Messung der Komplexität von Prozessen (z.B. (Melcher und Seese 2008)) oder die Komplexität von Softwarearchitekturen (z.B. (Lilienthal 2008)). Ferner wird sich in der Forschung mit den Möglichkeiten des Tracings von Komplexität über den gesamten Entwicklungsprozess beschäftigt (Ebert 1995a; Ebert 1995b). Die hier vorgestellten Komplexitätsmaße sind exemplarisch und repräsentieren daher nur einen kleinen Ausschnitt der zahlreichen Entwicklungen in diesem Forschungsgebiet. Ein wichtiger Aspekt, der in der wissenschaftlichen Literatur im Kontext von Komplexitätsmaßen und allgemein im Kontext von Metriken diskutiert wird, ist deren Evaluation. Aufgrund des hohen Interpretationsspielraums bedarf der Einsatz von Komplexitätsmaßen einer kritischen Auseinandersetzung und Überprüfung sowie der Schaffung von Kriterien, anhand derer eine Evaluation ermöglicht wird. Kearney et al. bspw. weisen im Umgang mit Komplexitätsmaßen darauf hin, dass durch die vielfältigen Interpretationsmöglichkeiten und eine unangemessene Anwendung von Komplexitätsmaßen die Gefahr besteht, dass schlechte Programmierpraktiken gefördert und gute Programmierer demoralisiert werden (Kearney et al. 1986). Der Forderung nach Evaluation von Komplexitätsmaßen kommen auch Weyuker oder Tian und Zelkowski nach (Weyuker 1988; Tian und Zelkowitz 1995). Weyuker bspw. ermittelt neun verschiedene Eigenschaften, die ein syntaktisches Komplexitätsmaß erfüllen sollte und anhand derer Komplexitätsmaße differenziert und evaluiert werden können (Weyuker 1988).

132

4.5

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Zwischenfazit

Das terminologische Verständnis des Komplexitätsbegriffs ist in der wissenschaftlichen Literatur nur unzureichend strukturiert (Bandte 2007, S. 89). Wie zu Beginn des Kapitels betont wurde, erfordert die Suche nach neuen Lösungsansätzen zur Komplexitätsbeherrschung eine Differenzierung des Komplexitätsbegriffs, um bei aller Vielschichtigkeit und Heterogenität den richtigen Fokus und Bezugsrahmen wählen zu können. Die vorangegangenen Ausführungen haben gezeigt, dass in der Literatur keine einheitliche Begriffsdefinition von Komplexität vorliegt. Auf den Versuch, eine Definition des Komplexitätsbegriffs zu formulieren, wird in dieser Arbeit jedoch verzichtet. Vielmehr wird die soziale Theorie Luhmanns zur Erklärung der Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme verwendet und auf das Komplexitätsverständnis dieser Theorie zurückgegriffen. Zudem werden in Bezug auf Fragestellungen der Informationsverarbeitung und Informationsversorgung, die im Zusammenhang mit komplexen sozialen Systemen stehen, Erkenntnisse systemischer Denkansätze und der Management-Kybernetik herangezogen. Die soziologische Systemtheorie, systemische Denkansätze und die Management-Kybernetik bilden somit eine gedankliche Basis, um verschiedene Aspekte der Komplexität bei der Entwicklung und dem Management betrieblicher Anwendungssysteme erklären oder untersuchen zu können. Die unterschiedlichen Arten von Softwarekomplexität werden im Folgenden nicht weiter verfolgt. Der Grund dafür liegt darin, dass ihr Fokus stark auf das technische Produkt Software und weniger auf deren Konstruktion gerichtet ist. Dies soll ihnen jedoch keinesfalls ihre Daseinsberechtigung noch ihre Relevanz absprechen. Es bleibt zudem anzumerken, dass sich auch die unterschiedlichen Arten von Softwarekomplexität in das systemtheoretische Verständnis von Komplexität in Bezug auf die System/Umwelt-Differenz einordnen lassen. So könnte bspw. die probleminhärente Komplexität (Ebert) oder Problemkomplexität (Fenton, Norman) als Umweltkomplexität verstanden werden, die lösungsabhängige Komplexität bzw. die Lösungskomplexität als Teil der Eigenkomplexität des Systems. Unterschieden werden muss bei solch einem Verständnis, auf welche Art von System (psychisch, sozial, technisch) und Systemgrenze sich die Eigenkomplexität bezieht und welche anderen Systeme die Umwelt bilden und zur Umweltkomplexität beitragen. 4.5.1

Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme

Bei der Entwicklung und dem Management von technischen Systemen sind immer soziale Systeme und psychische Systeme, die strukturell gekoppelt sind, involviert. So werden im Rahmen von Entwicklungsprozessen bestimmte Aspekte auf Basis von Kommunikation thematisiert und im menschlichen Bewusstsein über Gedanken und kognitive Prozesse verarbei-

Zwischenfazit

133

tet (verstanden oder auch nicht verstanden, mentale Modelle gebildet, etc.). An der Entwicklung und dem Management betrieblicher Anwendungssysteme sind immer mehrere Personen beteiligt, die auf Basis von Kommunikation und sozialem Handeln technische Systeme gestalten, der Einhaltung bestimmter Regeln unterliegen und Entscheidungen zu treffen haben – ein betriebliches Anwendungssystem ist niemals ein Konstrukt einer einzelnen Person. Im Folgenden wird daher in Anlehnung an die Theorie sozialer Systeme Luhmanns von organisierten sozialen Systemen im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme gesprochen. Die Leistungserfüllung solcher sozialen Systeme liegt darin, ihrer Umwelt betriebliche Anwendungssysteme und die entsprechenden IT-Dienstleistungen zur Verfügung zu stellen, um der Nachfrage nach einem immer höheren Automatisierungsgrad bestimmter System/UmweltKonstellationen nachzukommen. Dabei muss stets berücksichtigt werden, dass unterschiedliche Organisationsysteme die Umwelt anderer Organisationssysteme bilden, diese wiederum Teilsysteme von Funktionssystemen (z.B. Wirtschaftssystem, Rechtssystem, politisches System) der Gesellschaft sein können. Gleichzeitig ist eine Organisation aber wieder Umwelt von Teilsystemen „innerhalb“ der Organisation. Ändert sich nun eines dieser Systeme, so müssen alle anderen Systeme, die das sich ändernde System ihrer Umwelt zurechnen, sich ebenfalls im Rahmen ihrer eigenen Operationsbasis neu konstituieren. Keines dieser Systeme wird daher durch seine Umwelt determiniert, so dass immer wieder neue emergente Ordnungsstrukturen auf unterschiedlichen Emergenzebenen mit komplexen Wechselwirkungen und hoher Eigendynamik entstehen. Emergente Ordnungen bezeichnen Phänomene, die nicht aus den Eigenschaften ihrer Elemente abzuleiten sind, sondern sich aus den selektierten Relationen zwischen Elementen ergeben und sich nur auf Ebene des Systems erkennen lassen. Dies gilt ebenfalls für soziale Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme. Sie können sich auf unterschiedliche Art und Weise konstituieren und ausdifferenzieren, wodurch sich ebenfalls zahlreiche unterschiedliche System/Umwelt-Konstellationen bilden können. So kann es sich bspw. um eine Organisation (z.B. ein Systemhaus oder IT-Dienstleister) oder um ein Teilsystem einer Organisation (z.B. eine Entwicklungsabteilung) handeln, aus denen heraus sich wiederum soziale Teilsysteme bilden können. Über Mitgliedschaftsregeln wird festgelegt, wer als Mitglied eines (Teil-) Systems angesehen wird und in welcher Rolle (Anforderungsmanager, Architekt, Entwickler, etc.), d.h. mit welcher Verantwortlichkeit und welchen Verhaltensweisen die Mitgliedschaft ausgeübt wird (Luhmann 2006) (siehe auch Kapitel 4.2.3.3). Wie sich ein soziales System konstituiert und welche Eigenkomplexität ein solches System aufbringen muss, ist in jedem konkreten Fall von seiner Umwelt und der entsprechenden Umweltkomplexität abhängig. Denn auch bei sozialen Systemen im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme gilt: „Jedes System hat in seiner Umwelt mit anderen Systemen

134

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

zu rechnen. Je nachdem, wie tiefenscharf die Umwelt aufgenommen werden kann, erscheinen in ihr mehr oder verschiedenartigere Systeme.“ (Luhmann 1987, S. 256) und „Komplex ist die Welt nicht an sich, sondern nur aus der Perspektive von Systemen, die die Welt komplexitätsreduzierend zu verarbeiten versuchen.“ (Kneer und Nassehi 2000, S. 42) Die Tiefenschärfe der Umwelt und somit die Umweltkomplexität kann bei der Entwicklung und dem Management betrieblicher Anwendungssysteme ein gewaltiges Ausmaß annehmen. Gerade die Möglichkeiten neuer Technologien und Paradigmen erlauben es, dass immer größere Automatisierungsanteile aus immer mehr System/Umwelt-Konstellationen in Anwendungssysteme einfließen können. Sie erwecken leicht den Anschein, dass betriebliche Anwendungssysteme oder auch andere Softwareprodukte in nahezu beliebiger Größe erstellt werden können. So haben verbesserte Technologien und die Möglichkeiten der Integration bspw. dazu beigetragen, dass betriebliche Anwendungssysteme nicht mehr nur aus einzelnen Kernprodukten bestehen, sondern ein gewaltiges Netz aus unterschiedlichsten softwaretechnischen Systemkomponenten bilden. Insbesondere der Einsatz autonomer Services in serviceorientierten Architekturen weicht technologische Einschränkungen bezüglich der Integration und Interoperabilität von Anwendungssystemen immer weiter auf. Aus technologischer Sicht besteht somit die Möglichkeit einer beliebigen Vernetzung lose gekoppelter Services, durch die jegliche Form von Hierarchie aufgelöst werden kann. Durch das Auflösen von technologischen Grenzen einzelner betrieblicher Anwendungssilos können somit organisationsweite oder organisationsübergreifende Anwendungssysteme geschaffen werden, die durch flexible Vernetzung den Anforderungen zahlreicher sozialer System/Umwelt-Konstellationen entsprechen. Es ist daher auch nicht verwunderlich, dass durch die scheinbar unbegrenzten Möglichkeiten von Technologien immer wieder die Forderung in Erscheinung tritt, die Entwicklungsgeschwindigkeit von softwaretechnischen Systemen an die (Eigen-)Dynamik sich konstituierender sozialer Systeme anzupassen. Betriebliche Anwendungssysteme werden aber, wie zuvor angesprochen, durch soziale Systeme konstruiert bzw. gemanagt und sind Ergebnis einer teils jahrzehntelanger Evolution (wie z.B. bei Banken oder Versicherungen). Kein organisationsweites betriebliches Anwendungssystem wird mit all seiner Funktionalität auf einmal konstruiert oder in Betrieb genommen, sondern es entsteht aus einer fortlaufenden Konstruktion von Einzelkomponenten und deren Verflechtung. In seiner lauffähigen Form als Softwareprodukt spiegelt es lediglich eine zeitliche Fixierung einer unüberschaubaren Menge einzelner Konstruktionsergebnisse wider. Im Rahmen einer solchen Konstruktion hochintegrierter betrieblicher Anwendungssysteme müssen soziale Systeme eine hohe Eigenkomplexität (Anzahl möglicher eigener Zustände) ausbilden, um die Umwelt in ihrer gesamten Tiefenschärfe aufnehmen und auf wechselnde Umweltanforderungen angemessen reagieren zu können. D.h., sie müssen in der Lage sein, die systemexterne Welt mit all ihren komplexen Wechselwirkungen, in Form einer systemin-

Zwischenfazit

135

ternen Konstruktion zu beachten. Denn nur wenn die Eigenkomplexität des sozialen Gesamtsystems aufrecht erhalten werden kann, wird es sich gegenüber der Umweltkomplexität behaupten, sich an die wechselnden Umweltbedingungen anpassen und somit den Fortbestand des technischen Systems durch weitere Konstruktionen sicherstellen können. Zur Reduktion der Gesamtkomplexität sind große soziale Systeme auch im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme zwangsläufig – es sei denn, die Komplexität würde in der Zeit verarbeitet – weiter ausdifferenziert, wobei alle Teilsysteme des Gesamtsystems in einem wechselseitigen System/Umwelt-Verhältnis zu einander stehen und in einem arbeitsteiligen Prozess zur Steigerung der Arbeitsleistung jeweils einen Teil der Gesamtsystemreproduktion übernehmen (siehe Kapitel 4.2.3.2). Jedes dieser Teilsysteme orientiert sich dabei an seiner eigenen System/Umwelt-Differenz und verarbeitet zur Lösung von Problemen und Fragestellungen sowie den daraus resultierenden Interessen unterschiedliche Informationen. 4.5.2

Probleme der Informationsverarbeitung im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme

Mit den zuvor angestellten Betrachtungen sozialer Systemen und dem damit verbundenen Komplexitätsverständnis ergeben sich im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme verschiedene Fragestellungen. So muss bspw. hinterfragt werden, welche Möglichkeiten der Steuerung, Kontrolle und Organisation (Selbstregulierung und Selbstorganisation) existieren, wie Ergebnisse der Arbeitsteilung reintegriert werden können, welche Art von Gedächtnis zur Speicherung von organisationalem Wissen dem Gesamtsystem zur Verfügung stehen muss, welche Kommunikationsstrukturen und Selektionsmuster notwendig sind und wie bei den zahlreichen System/Umwelt-Konstellationen systemspezifisch Informationen gewonnen und verarbeitet werden können. Die Fragestellungen mögen mit Blick auf die wissenschaftliche Literatur nicht neu erscheinen; die Berücksichtigung von Theorien und Ansätzen anderer Disziplinen und die daraus resultierende Interdisziplinarität eröffnen jedoch Möglichkeiten, die Fragestellungen differenzierter zu betrachten. Der Forderung in Lehmanns achtem Gesetz, multi-loop, multi-level Feedback-Systeme als solche anzusehen und zu behandeln (siehe Kapitel 4.3), würde durch die Entwicklung von Ansätzen, die den Einsatz kybernetischer Lenkungsstrukturen, Regelkreise und Rückkopplungen bei der Entwicklung und dem Management betrieblicher Anwendungssysteme untersuchen, sicherlich Rechnung getragen. Arbeiten, wie z.B. (Masak 2007; Kawalek und Wastell 1996; Cai et al. 2002; Cai et al. 2003; Buckl et al. 2009), greifen die Möglichkeiten kybernetischer Lenkungsstrukturen auf und unternehmen Untersuchungen in diese Richtung. Auch im Bereich der Informationssystemgestaltung, des Informationsmanagements oder des Managements von IS-Architekturen greifen Arbeiten, wie z.B. (Teubner 1999; Hafner 2006; Gabriel und Beier 2003), eine systemtheoretische und kybernetische Perspektive explizit auf.

136

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

Dabei wird bspw. das Informationsmanagement im Sinne der Kybernetik als Lenkungssystem zur Gestaltung, Steuerung und Kontrolle des Informationssystems aufgefasst (Ferstl und Sinz 2006, S. 73ff.; Gabriel und Beier 2003, S. 55ff.; Beier 2002). Im Folgenden werden Probleme und Herausforderungen der Informationsverarbeitung untersucht, mit denen soziale Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme konfrontiert sind. Der Fokus liegt daher weniger auf Fragestellungen bezüglich der Gestaltung geeigneter Lenkungsstrukturen, sondern vielmehr darauf, welchen Ansprüchen die Informationsverarbeitung im Sinne systemischer Denkansätze und einer kybernetischen Systemmethodik genügen muss, um Lenkungsstrukturen effizient und effektiv unterstützen und somit einen Beitrag zur Komplexitätsbeherrschung leisten zu können. Wie bereits erwähnt, wird der Schwerpunkt im Verlauf der Betrachtung auf die Informationsverarbeitung im Architekturmanagement gerichtet, wobei wiederum die Verwendung unterschiedlicher Sichten und Perspektiven im Mittelpunkt stehen. Es wurde bereits angesprochen, dass sich die Komplexität sozialer Systeme in Bezug auf die Selektivität immer auch darin ausdrückt, dass ein System niemals über genügend Informationen verfügt, um sich selbst und seine Umwelt vollständig erfassen und beschreiben zu können (siehe Kapitel 4.2.3.2 und 4.2.5). Zudem führen die Arbeitsteilung und die Konzentration auf Detailkomplexitäten spezieller Problemstellungen zu Informationsverlusten und steigender Ungewissheit, die ohne das Festhalten der gewonnenen Informationen nicht ausgeglichen werden können. Die Speicherung gewonnener Informationen in Form von Daten und Metadaten ist jedoch keine einfache Aufgabe, da auch diese unmittelbar mit der Komplexität sozialer Systeme verbunden ist und ebenfalls unter dem Einfluss von Wechselwirkungen und (Eigen)Dynamik steht. Eine wichtige Rolle spielt insbesondere die Aktualität von Daten, um systemische Wechselwirkungen erkennen zu können, die auf Basis von reaktiven Ereignissen an anderer Stelle des Gesamtsystems entstehen. Aber selbst wenn es gelingt, Informationsverluste durch die Speicherung von Daten und Metadaten zu reduzieren oder zu vermeiden, so existiert nach wie vor die zentrale Fragestellung, wie aus diesen Daten wiederum systemspezifisch Informationen gewonnen und verarbeitet werden können. Wilke formuliert das Verhältnis von Daten, Informationen und Systemen folgendermaßen: „Aus Daten werden Informationen durch Einbindung in einen ersten Kontext aus Relevanzen, die für ein bestimmtes System gelten.“ (Wilke 1998, S. 8) Beim Informationsbegriff verweist Wilke, wie auch Luhmann (siehe Kapitel 4.2.3.3), auf die klassische Formulierung von Gregory Bateson „A ‘bit‘ of information is definable as a difference which makes a difference“ (Bateson 2000, S. 315), d.h. eine Information ist ein bedeutsamer Unterschied. Des Weiteren führt Wilke an: „Bedeutsam kann ein Unterschied nur am Maßstab eines Kriteriums von Relevanz sein. Da es keine Relevanzen an sich gibt, sondern jede Relevanz systemspezifisch und systemabhängig ist, folgt zwingend, dass jede Information nur systemrelativ sein kann. Eine

Zwischenfazit

137

Information ist nur dann konstituiert, wenn ein beobachtendes System über Relevanzkriterien verfügt und einem Datum eine spezifische Relevanz zuschreibt. […] Weiter folgt aus dieser Rekonstruktion zwingend, dass Informationsaustausch zwischen unterschiedlichen Systemen unmöglich ist.“ (Wilke 1998, S. 8f.) Unter diesem Gesichtspunkt merkt Wilke an, dass eine Organisation über Beobachtungsinstrumente verfügen muss, die es ermöglichen, Daten zu generieren, die die Organisation in ihrem Kontext betreffen (Wilke 1998, S. 34). Des Weiteren muss sie über „eigenständige, systemisch übergreifende Beobachtungsregeln und Relevanzkriterien für die Bewertung von Daten und mithin für die Konstruktion von Informationen verfügen. Nur so kann sie aus dem Ozean von Daten systemspezifisch relevante Informationen generieren, die auf die Strategien und Ziele der Organisation im Kontext ihrer relevanten Umwelten bezogen sind.“ (Wilke 1998, S. 35) Dies betrifft zugleich jedes Teilsystem einer Organisation, das unter Berücksichtigung seiner Umwelt zur Generierung systemspezifischer Informationen auf Daten zurückgreifen muss. Bei dem Verständnis komplexer Systeme geht es, wie Vester betont, jedoch keinesfalls darum, eine noch größere Genauigkeit oder Datendichte zu schaffen, sondern vielmehr um die Erfassung der richtigen Vernetzung (Vester 2002, S. 179). Dies ist in Bezug auf die zuvor angesprochenen systemischen Denkansätze (siehe Kapitel 4.2.4) ein entscheidender Aspekt, um Wechselbeziehungen und Veränderungsmuster erkennen zu können. Die Entwicklung und das Management betrieblicher Anwendungssysteme sind jedoch sehr von einer analytischen Denkweise sowie kommunikationsintensiven Prozessen geprägt. Bei der Fokussierung auf Einzelprobleme und Detailkomplexitäten in den unterschiedlichen Entwicklungsphasen entstehen enorme Detailkenntnisse über einzelne Ausschnitte des Gesamtsystems. Im Laufe der Evolution betrieblicher Anwendungssysteme werden somit unüberschaubare Mengen an Dokumentationen und Konstruktionsergebnissen (Entwicklungsartefakte, wie z.B. Anforderungsdokumente, Geschäftsprozessmodelle, UML-Diagramme, ERDiagramme) mit unterschiedlichem Abstraktionsniveau und Detailgrad festgehalten. Zudem entstehen durch den arbeitsteiligen Entwicklungsprozess in Bezug auf die Dokumentationen und Artefakte zahlreiche unterschiedliche Medienbrüche, die Kommunikationsprobleme (insbesondere an den Schnittstellen) hervorrufen. Vernetzte Zusammenhänge, Abhängigkeiten und Wechselwirkungen lassen sich auf Basis von Detailkenntnissen, analytischer Konstruktionsergebnisse und Ursache-WirkungsZusammenhängen aber nur schwer rekonstruieren. So stellt sich z.B. bei Entscheidungen, die im Rahmen der Weiterentwicklung oder Modifikation eines Anwendungssystems zu treffen sind, die Frage, wie auf Basis von linearen Konstruktionen systemisch relevante Informationen gewonnen und somit nicht-lineare Sachverhalte rekonstruiert werden können. Dies betrifft vor allem Systemebenen, auf denen Personen mit den entsprechenden Entscheidungsbe-

138

Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme

fugnissen ausgestattet sind und die Konsequenzen von Änderungen für andere Bereiche und Phasen eines Entwicklungsprozesses abschätzen bzw. nachvollziehen müssen. Die Gefahr, die von den zahlreichen Detailkenntnissen und Detaillösungen ausgeht, ist, dass in Bezug auf das Gesamtsystem schnell der Eindruck entsteht, über alles notwendige Wissen zur Beherrschung von Komplexität zu verfügen. Die Frage nach dem Nicht-Wissen wird daher viel zu selten oder gar nicht gestellt, so dass Wechselbeziehungen und Veränderungsmuster häufig unerkannt bleiben. Dieser Gefahr ist, genau wie andere Bereiche der Entwicklung und des Managements betrieblicher Anwendungssysteme, auch das Architekturmanagement ausgesetzt. Im Rahmen des Architekturmanagements existieren zahlreiche unterschiedliche Sichten, mit denen auf Basis von Relevanzkriterien bestimmte Aspekte betrachtet werden. Welche Sicht eingenommen wird, auf welche Art und Weise eine Sicht dokumentiert wird, wie kommuniziert wird und welche Informationen aus einer bestimmten Perspektive gewonnen und verarbeitet werden, ist auch in diesem Fall systemspezifisch und abhängig von den Relevanzkriterien spezifischer System/Umwelt-Konstellationen. Dies kann schon alleine daran ausgemacht werden, dass unterschiedliche Interaktionssysteme, die bei der Konstruktion betrieblicher Anwendungssysteme über das gleiche Thema kommunizieren, völlig unterschiedliche Sichten einnehmen können. Das gleiche gilt für kognitive Prozesse verschiedener Personen. Da es jedoch nicht möglich ist, für jede zukünftige System/Umwelt-Konstellation – dazu zählen auch bereits bestehende System/Umwelt-Konstellationen, die sich über Strukturänderung und Veränderung der Systemgrenzen neu konstituieren – die entsprechenden Relevanzkriterien und Sichten zu antizipieren und schon im Vorhinein festzulegen, müssen aus den bestehenden Konstruktionsergebnissen die entsprechenden Informationen gewonnen werden. Auf die Aussagen von Wilke bezogen bedeutet dies, auch im Rahmen des Architekturmanagements Instrumente zur Verfügung zu stellen, die aus den Daten und Metadaten systemspezifisch relevante Informationen generieren können, um diese nicht nur im Kontext, der ihrer Konstruktion zugrunde liegt, sondern auch in weiteren Kontexten verwenden zu können. Im nachfolgenden Kapitel wird das Konzept der Architektursichten unter Berücksichtigung der in diesem Kapitel geschilderten Problem- und Fragestellungen weiter analysiert und aufgezeigt, welche Grenzen dem Konzept in seiner heutigen Anwendung mit dem zugrunde liegenden Verständnis komplexer sozialer Systeme im Rahmen der Entwicklung und des Managements betrieblicher Anwendungssysteme gesetzt sind.

5

Sichtenkonzepte

Eines der wohl wichtigsten Konzepte im Bereich der Architekturdokumentation ist das Konzept der Sicht (Clements et al. 2002, S. 13). Welche Sichten im Rahmen der Architekturdokumentation relevant sind, ist abhängig von der Rolle des Betrachters und den verfolgten Zielen. Durch spezifische Fragestellungen und Interessen verschiedener Stakeholder werden zahlreiche Sichten auf ein System benötigt, die unterschiedliche Aspekte und Informationen in Bezug auf das Gesamtsystem beinhalten. Hinsichtlich der Reduktion und Beherrschung von Komplexität sehen Clements et al. in der Verwendung von Sichten das bei weitem mächtigste Hilfsmittel im Rahmen der Architekturkommunikation (Clements et al. 2002, S. 379). Im Folgenden wird zunächst der Industriestandard ISO/IEC 42010 IEEE Std 1471-2000 zur Beschreibung und Dokumentation von Architekturen softwareintensiver Systeme beschrieben (Kapitel 5.1). Anschließend werden Sichtenmodelle aus den Bereichen der Software-, Unternehmens- und serviceorientierten Architekturen vorgestellt (Kapitel 5.2 und 5.3). Abschließend werden die in Kapitel 4 erörterten Sachverhalte und Fragestellungen wieder aufgegriffen, um die Probleme und Herausforderungen von Architekturbeschreibungen und -dokumentationen auf Basis von Architektursichten ausführlicher zu diskutieren (Kapitel 5.4). 5.1

Architekturbeschreibung und -dokumentation

Wie bereits im Rahmen der Architekturbegriffsabgrenzung (siehe Kapitel 2.3) angeführt, handelt es sich bei ISO/IEC 42010 IEEE Std 1471-2000 um einen internationalen Standard, mit dem im Bereich des Systems und Software Engineering eine Empfehlung zur Architekturbeschreibung und -dokumentation softwareintensiver Systeme erarbeitet wurde. Unter softwareintensiven Systemen werden Systeme verstanden, bei denen Software essenzielle Einflüsse auf das Design, die Konstruktion, die Entwicklung und die Evolution des Gesamtsystems hat (ISO/IEC und IEEE 2007, S. 1). Die Empfehlung richtet sich an Aktivitäten der Architekturerstellung, -analyse und -erhaltung. Der Standard stellt die grundlegende Terminologie und ein konzeptionelles Framework zur Beschreibung von Architekturen zur Verfügung. Clements et al. sehen den grundlegenden Nutzen von Architekturdokumentationen in ihrer Verwendung als Schulungsmittel, als Kommunikationsinstrument zwischen den unterschiedlichen Stakeholdern und als Basis für Systemanalysen (Clements et al. 2002, S. 10ff.). Adressierte Stakeholder sind u.a. Anforderungsentwickler, Architekten, Entwickler, das Wartungsteam, Designer und die Qualitätssicherung, für deren unterschiedliche Kommunikationsbedarfe Architekturdokumentationen herangezogen werden können. Zudem wird in ISO/IEC 42010 IEEE Std 1471-2000 die Verwendung von Architekturbeschreibungen u.a. im Rahmen von Planungs- und Managementaufgaben, der Architekturevaluation und der Verifikationen von Systemimplementierungen in Bezug auf Architekturvorgaben angeführt (ISO/IEC und IEEE T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_5, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

140

Sichtenkonzepte

2007, S. 1 u. 8). Nach ISO/IEC 42010 IEEE Std 1471-2000 richten sich die Empfehlungen zur Architekturbeschreibung primär an Gruppen von Stakeholdern, die x

das System benutzen, besitzen und anschaffen (Benutzer, Operator, Käufer oder Kunden),

x

die Architektur entwickeln, beschreiben und dokumentieren (Architekten),

x

das System entwickeln, ausliefern und warten (Architekten, Designer, Programmierer, Maintainer, Tester, Qualitätssicherer, Konfigurationsmanager, Projektmanager etc.),

x

die Systeme und deren Entwicklung managen und evaluieren (Chief Information Officers, Prüfer, unabhängige Gutachter) (ISO/IEC und IEEE 2007, S. 2).

Weitere Gruppen von Nutzern der Architekturdokumentation sind diejenigen, die in unternehmensweite Infrastrukturaktivitäten involviert sind, wie z.B. Methodiker, Prozessverantwortliche und -ingenieure, Forscher, Ersteller von Standards, Werkzeugentwickler und Trainer. Stakeholder können hinsichtlich der Erstellung und Verwendung von Architekturbeschreibungen zahlreiche Rollen einnehmen. Als Schlüsselrollen werden der Käufer bzw. Kunde und der Architekt angesehen. Das in ISO/IEC 42010 IEEE Std 1471-2000 definierte konzeptionelle Framework (ISO/IEC und IEEE 2007, S. 4ff.) legt die Begriffe und Konzepte in Bezug auf den Inhalt und die Verwendung von Architekturbeschreibungen fest. Im Folgenden werden die Begriffe und die Konzepte des Frameworks erläutert. Eine Übersicht über die Konzepte und deren Relationen ist in Abbildung 41 dargestellt. Der Begriff System wird im Standard sehr allgemein gefasst und umfasst individuelle Applikationen, Systeme im traditionellen Sinne, Subsysteme, Systeme von Systemen, Produktlinien, ganze Unternehmen und andere Aggregationen, die von Bedeutung sind. Es wird jedoch weder eine Aussage darüber getroffen, wie sich die Systeme konstituieren, noch welche Merkmale sie im Einzelnen besitzen können. Ein System wohnt einer Umwelt bei, die Einfluss auf das System hat. Die Umwelt, oder der Kontext (Context), legt die Zustände und Rahmenbedingungen der Entwicklungs-, der operativen, der politischen und anderer Einflüsse auf das System fest. Die Umwelt kann andere Systeme beinhalten, die direkt oder indirekt miteinander interagieren. Die Umwelt determiniert dabei die Grenzen eines Systems und definiert somit den Rahmen bzw. den Geltungsbereich eines Systems relativ zu anderen Systemen. Ein System hat einen oder mehrere Stakeholder. Jeder Stakeholder hat typischerweise Interessen (Concerns) an oder relativ zu dem betrachteten System. Bei Concerns handelt es sich um diejenigen Interessen, die sich auf die Systementwicklung, dessen Betrieb oder jegliche anderen Aspekte beziehen, die für einen oder mehrere Stakeholder kritisch oder wichtig sind. Concerns umfassen Aspekte wie z.B. Performanz, Zuverlässigkeit, Sicherheit und Verteilung.

Architekturbeschreibung und -dokumentation

141

Abbildung 41: Konzeptionelles Modell zur Architekturbeschreibung Quelle: (ISO/IEC und IEEE 2007, S. 5)

Die Aufgabe eines Systems besteht darin, eine oder mehrere Missions in seiner Umwelt zu erfüllen. Eine Mission stellt den Verwendungszweck eines Systems für einen oder mehrere Stakeholder zur Erfüllung festgelegter Ziele dar. Jedes System besitzt nach ISO/IEC 42010 IEEE Std 1471-2000 eine Architektur, die mithilfe einer Architekturbeschreibung festgehalten werden kann. Dabei wird die Architektur eines Systems entweder als konzeptionell oder als bestimmte Beschreibung einer Architektur in Form eines konkreten Produktes oder von Artefakten verstanden. Eine Architekturbeschreibung ist in einen oder mehrere Bestandteile, die als Sichten (Views) bezeichnet werden, eingeteilt. Jede dieser Sichten adressiert unterschiedliche Concerns der Stakeholder des Systems. Eine Sicht bezieht sich bei der Darstellung einer Systemarchitektur immer auf einen bestimmten Viewpoint. Dieser legt die Konventionen fest, mit denen eine Sicht erstellt, beschrieben und analysiert wird. Eine Sicht ist somit immer konform zu einem Viewpoint, der die Sprache (z.B. Notationen, Modelle, Produkttypen, etc.) zur Beschreibung von Sichten sowie die damit verbundenen Modellierungsmethoden oder Analyseverfahren vorgibt. Durch die Verwendung unterschiedlicher Sprachen und Verfahren wird es ermöglicht, Ergebnisse unter Berücksichtigung der durch einen Viewpoint adressierten Concerns hervorzubringen. Eine Sicht kann aus einem oder mehreren Architekturmodellen bestehen, wobei jedes dieser Modelle auf Basis

142

Sichtenkonzepte

festgelegter Methoden eines assoziierten Viewpoints erstellt wird. Ein Modell ist jedoch nicht an einzelne Sichten gekoppelt, sondern kann Teil mehrerer Sichten sein, solange diese dem gleichen Viewpoint entsprechen. Weitere Informationen, die in keiner der Sichten enthalten sind, können dennoch als Ergebnisse von Dokumentationstätigkeiten einer Organisation in eine Architekturbeschreibung einfließen. Beispiele dafür sind Systemübersichten, der Systemkontext, die Stakeholder eines Systems und ihre Concerns oder die Gründe, die zu einem konkreten Aufbau des Systems geführt haben (System Rationale). Zur Architekturbeschreibung werden ein oder mehrere Viewpoints ausgewählt. Die Auswahl bestimmter Viewpoints basiert typischerweise auf den Überlegungen und Interessen verschiedener Stakeholder, an die die Beschreibung gerichtet ist. Eine Viewpoint-Definition kann aus einer konkreten Architekturbeschreibung hervorgehen oder an anderer Stelle definiert sein. Ein Viewpoint, der an anderer Stelle definiert wird, wird in ISO/IEC 42010 IEEE Std 14712000 als Library Viewpoint bezeichnet. 5.2

Softwarearchitektursichten

Im Bereich der Softwarearchitekturen existieren neben dem ISO/IEC 42010 IEEE Std 14712000-Standard verschiedene verwandte Arbeiten, die sich dem Thema der Architekturdokumentation und dem damit verbundenen Sichtenkonzept widmen. Zu den Arbeiten zählen u.a. die Kruchten „4+1“-Sichten (Kruchten 1995), UML (OMG 2009), Siemens Four Views (Soni et al. 1995), Business Component Factory Sichten (Herzum und Sims 2000) und RM-ODP (Reference Model for Open Distributed Processing) (Putman 2000). Stellvertretend für die verschiedenen Arbeiten wird im Folgenden näher auf den „4+1“-Ansatz von Kruchten und den am Software Engineering Institute (SEI) der Carnegie Mellon Universität entwickelten Ansatz „Views and Beyond“ eingegangen. 5.2.1

Kruchten „4+1“-Sichtenmodell

Das von Kruchten entwickelte „4+1“-Sichtenmodell (Kruchten 1995) zur Architekturbeschreibung softwareintensiver Systeme basiert auf der Verwendung mehrerer simultaner Sichten, die eine separate Betrachtung von Concerns diverser Stakeholder einer Architektur (z.B. Endanwender, Entwickler, Systemingenieure, Projektmanager, etc.) erlauben. Die „4+1“Sichten bilden heute die Grundlage der Architekturdokumentation im Rational Unified Process. Dem Sichtenmodell liegt das von Perry und Wolf definierte Modell einer Softwarearchitektur (Perry und Wolf 1992, S. 44) zugrunde: Software Architecture = { Elements, Form, Rationale/Constraints }

Softwarearchitektur S rsichten

1433

Abbildung A 42: Dass „4+1“-Sichtenmoodell Quelle: Q (Kruchten 11995, S. 43)

Das D Modell bestteht aus fünf zeentralen Sichten (siehe Abbildung 42), mit dennen eine spezifi-sche s Menge an Concerns unterrschiedlicher Sttakeholder adresssiert wird (Kruuchten 1995, S.. 42f.): 4 x

hreibt das Objektmodell, wennn eine objektori-Die logissche Sicht (Logiical View) besch entierte Designmethode D verwendet wirdd. Falls es sich um eine stark datengetriebenee Anwenduung handelt, kann k ein alternaativer Ansatz, wie z.B. Entitty-Relationship-Diagramm me, für die logissche Sicht verw wendet werden.

x

Die Prozzesssicht (Proceess View) besch hreibt Aspekte der Nebenläufiigkeit und Syn--

x

Die physsikalische Sicht (Physical View w) beschreibt diie Zuordnung von v Software zuu Hardware und spiegelt Aspekte A der Vertteilung wider.

x

Die Entw wicklungssicht (Development ( View) V beschreibbt den statischenn Aufbau einerr

x

Die Bescchreibung der Arrchitektur und die d getroffenen Entscheidungen E werden mit denn vier zuvoor genannten Sicchten organisierrt und mithilfe einer e Auswahl an a Use Cases o-der Szennarien (Scenarioos), die die fün nfte Sicht bildenn, dargestellt. Die D fünfte Sichtt stellt dass Zusammenwirrken der anderren Sichten darr. Die ausgewähhlten Szenarienn spiegeln eine abstrakte Darstellung D der wichtigsten w Anfforderungen widder.

chronisattion.

Softwaree in deren Entwicklungsumgebuung.

144

Sichtenkonzepte

Die von Perry und Wolf definierte Gleichung wird für jede Sicht unabhängig angewendet, d.h. es werden für jede Sicht die zu verwendenden Elemente, Formen und Muster sowie die Gründe und Einschränkungen festgelegt. Blueprints mit jeweils eigener Notation dienen zur Beschreibung der einzelnen Sichten. Zudem kann für jede Sicht ein bestimmter Architekturstil gewählt werden, so dass mehrere Stile in einem System existieren können. Da die verschiedenen Sichten jedoch nicht orthogonal und unabhängig voneinander sind und Elemente einer Sicht mit Elementen anderer Sichten verbunden sind, ist eine Zuordnung zwischen den Sichten erforderlich. Kruchten betont, dass das „4+1“-Modell generischen Charakter besitzt. Es werden zwar aufgrund von gesammelten Erfahrungen konkrete Vorschläge zur Beschreibung der einzelnen Sichten angestellt. Das Modell hält aber dennoch die Möglichkeit offen, andere Notationen, Werkzeuge und Designmethoden zu verwenden (Kruchten 1995, S. 43). 5.2.2

SEI‘s „Views and Beyond“

Der vom Software Engineering Institute (SEI) der Carnegie Mellon University vorgestellte Ansatz zur Dokumentation von Softwarearchitekturen basiert auf den drei Basiskonzepten Viewtype, Styles und Views. Der Fokus des Ansatzes liegt neben der Definition von Konzepten und Richtlinien zur Architekturbeschreibung in der Dokumentation konkreter Viewtypes und Anwendungsbeispiele, die im Rahmen von Forschungsarbeiten und Praxisprojekten identifiziert wurden und eine große Anzahl von Stakeholder-Concerns adressieren. Bei der Strukturierung von Software geht der Ansatz von drei zentralen Fragestellungen aus (Clements et al. 2002, S. 18; Bass et al. 2003, S. 206): x

Wie ist Software als eine Menge von Implementierungseinheiten strukturiert?

x

Wie ist Software als eine Menge von Elementen strukturiert, die Laufzeitverhalten besitzen und interagieren?

x

Wie ist der Bezug zu anderen Strukturen in der Umwelt?

Der SEI-Ansatz teilt Softwarearchitekturen bezüglich der Strukturfragen von Software in die folgenden drei Kategorien ein, die als Viewtypes bezeichnet werden: x

Module viewtype (Implementierungseinheiten)

x

Component-and-connector (C&C) viewtype (Laufzeiteinheiten)

x

Allocation viewtype (Zuordnung von Softwareelementen zu Umgebungsstrukturen)

Ein Viewtype definiert die Element- und Beziehungstypen, die verwendet werden, um die Architektur eines Softwaresystems aus einer bestimmten Perspektive zu beschreiben (Clements et al. 2002, S. 18). Ein Architekturstil (Architectural Style) ist eine Spezialisierung von Element- und Beziehungstypen in Verbindung mit einer Menge von Einschränkungen hinsichtlich ihrer Verwendung (Clements et al. 2002, S. 18). Ein Architekturstil bezieht sich auf

Softwarearchitektur S rsichten

1455

wiederkehrende w Muster oder geemeinsame Variiationen, die in völlig unterschiiedlichen Syste-men m auftauchen können. Zur Beeschreibung einees Architektursttils, mit dem dass Vokabular dess Designs D (Elemennt- und Beziehuungstypen) und die Regeln, wiee das Vokabulaar zu verwendenn ist (topologischee und semantischhe Einschränkun ngen), festgeleggt werden, dientt der sogenanntee Style S Guide. Einne View ist definniert als die Reepräsentation einner Menge von Elementen undd den d Beziehungenn zwischen denn Elementen (Cllements et al. 20002, S. 13). Jedde erstellte View w ist einem der drrei Viewtypes bzzw. einem View wtype angehöriggen Style unterggeordnet. Abbil-dung d 43 zeigt exxemplarisch die Zusammenhäng ge zwischen View wtypes, Styles und u Views.

Abbildung A 43: Zussammenhänge zwiischen Viewtypes, Styles und Views Quelle: Q (Clements eet al. 2002, S. 21)

Für F den Einsatz von Architektuurdokumentation nen in der Praxxis werden von Clements et al.. (Clements et al. 2002) neben den Basiskonzepteen erweiterte Koonzepte diskutieert, denen insbe-sondere s im Um mgang mit großeen realen Systeemen ein besonderer Stellenweert beigemessenn wird. w Zu den Techniken und Strategien S der erweiterten e Konnzepte zählen diie Verfeinerungg (Refinement) unnd das Zusammeenfassen (Chun nking) von Inforrmationen, Konntextdiagramme,, die d Erstellung unnd Dokumentatiion kombinierteer Sichten, die Dokumentation D von Variabilitätt und u Dynamik unnd die Dokumenntation neuer Stiile (vgl. im Folggenden (Clementts et al. 2002, S.. 185ff.)). 1 Im Zusammenhaang mit dem soggenannten Chunnking von Inform mationen werdeen unterschiedli-che c Techniken uund Strategien vorgestellt: v Sichttenpakete (View w Packets), Verfe feinerungen (Re-finement) f und diie Vollständigkeeit von Beschreiibungen (Descrip iptive Completenness). Aufgrundd der d hohen Anzahhl an Elementenn und Beziehung gen, die ein System enthalten kann, k ist es nichtt möglich, m mit derr Dokumentatioon einer Sicht allle Informationeen auf einmal daarzustellen. Auss diesem d Grund w werden die Inforrmationen aufgeeteilt und in Vieew Packets orgaanisiert. Mithilfee von v View Packeets wird es Stakeeholdern ermöglicht, in der Dokumentation einnes Systems auff unterschiedliche u n Granularitätseebenen von Sichht zu Sicht zu naavigieren und glleichzeitig einenn zusammenhänge z enden Überblickk zu bewahren n. Über das Ref efinement könneen Eltern-Kind--

146

Sichtenkonzepte

Beziehungen dargestellt werden, mit denen eine stärkere Fokussierung auf interne Strukturen von Elementen oder auf neue spezifischere Elemente und Beziehungen ermöglicht wird. Die Strategie der Descriptive Completeness sagt aus, dass alle Elemente und Relationen innerhalb einer Sicht vollständig durch ein View Packet dokumentiert werden. So kann bspw. ausgeschlossen werden, dass Beziehungen zwischen Elementen existieren, wenn diese nicht explizit in einer Sicht dargestellt werden. Wird Unvollständigkeit als Strategie gewählt, so können Elemente und Beziehungen auch an anderer Stelle (z.B. in Dekompositionen) dokumentiert sein. Mit der Verwendung von Kontextdiagrammen werden die Grenzen der Informationen, die in View Packets enthalten sind, festgelegt. Ein Kontextdiagramm für ein Gesamtsystem definiert, was Teil dieses Systems ist und was nicht. Es gibt somit einen Rahmen für die Aufgabenbereiche eines Architekten vor. Eine strikte Verwendung starr aufgeteilter Sichten bei der Beschreibung von Architekturen wäre ein naives Vorgehen, da es zahlreiche Situationen und Gründe gibt, zwei oder mehrere Sichten in einer einzelnen Sicht zu kombinieren. Eine kombinierte Sicht enthält Elemente und Beziehungen von zwei oder mehreren anderen Sichten und kann aus Sichten erstellt werden, die zu unterschiedlichen Styles und Viewtypes gehören. Es werden zwei Typen kombinierter Sichten unterschieden. Der hybride Stil (Hybrid Style) ist eine Kombination aus zwei oder mehreren bestehenden Stilen. Dabei unterliegt der hybride Stil den gleichen Dokumentationsverpflichtungen wie jede andere Sicht. Zudem muss die Zuordnung der verschiedenen Stile, aus denen sich der hybride Stil zusammensetzt, dokumentiert werden. Das Overlay ist eine Kombination von Informationen aus zwei oder mehreren Sichten, zwischen denen eine starke Beziehung besteht. Ein Overlay hat die gleichen Dokumentationsanforderungen wie normale Sichten. Es werden aber keine neuen Dokumentationsvorschriften eingeführt. Overlays können für eine kurzfristige Verwendung, wie z.B. bei Analysen oder Kommunikationen, erstellt werden. Der Einsatz kombinierter Sichten kann zur Überprüfung der konzeptionellen Integrität einer Architektur beitragen, da nur Sichten zusammengefasst werden können, die auch dem gleichen grundlegenden Konzept folgen. Zu Problemen und Verwirrung können kombinierte Sichten jedoch führen, wenn aufgrund einer vernachlässigten Architekturdokumentation unbeabsichtigt Concerns miteinander vermischt werden. Die Dokumentation von Variabilität ist notwendig, wenn Entscheidungen über bestimmte Aspekte noch nicht getroffen und unterschiedliche Optionen ermittelt wurden (z.B. bei Produktfamilien oder Frameworks, die bestimmte Variations- und Erweiterungsmöglichkeiten offenhalten). Informationen, die hinsichtlich der Variabilität dokumentiert werden müssen, sind Variationspunkte, Elemente, die von Optionen betroffen sind, und der Zeitpunkt der Bindung einer Option. Mithilfe der Dokumentation von Dynamik können Strukturänderungen

Softwarearchitektursichten

147

dokumentiert werden, die durch das System selber zur Laufzeit durchgeführt werden (z.B. Reallokation von Ressourcen und Verantwortlichkeiten, etc.). Das Erstellen und Dokumentieren neuer Stile ist eine wichtige Aufgabe im Rahmen der Architekturdokumentation. Mit der Ergänzung bestehender Style Guides oder Pattern-Kataloge werden neue Lösungen zur Verfügung gestellt und somit zukünftige Projekte besser unterstützt. Wie zuvor erwähnt bestehen Views aus unterschiedlichen View Packets, die bspw. über Eltern-Kind-Beziehungen miteinander verbunden sind. Für die Dokumentation der View Packets wird unabhängig von der Sicht eine einheitliche Gliederung vorgeschlagen, die aus den folgenden sieben Teilen besteht (Clements et al. 2002, S. 317ff.): Grundlegende Darstellung (Primary Presentation), Elementkatalog (Element Catalog), Kontextdiagramm (Context Diagram), Variabilitäts-Guide (Variability Guide), Hintergrund der Architektur (Architecture Background), weitere Informationen (Other Information) und verwandte View Packets (Related View Packets). Abbildung 44 zeigt ein entsprechendes Template für die Dokumentation von View Packets. Neben der Dokumentation einzelner Sichten spielt das Erfassen von sichtübergreifenden Informationen eine wichtige Rolle, um Fragestellungen beantworten zu können, die über die Aspekte einzelner Sichten hinaus gehen. Zu den drei zentralen Fragestellungen (siehe Abbildung 45) zählen, wie die Architekturdokumentation aufgebaut ist (Roadmap und Templates), was die Architektur ist (Systemübersicht, Zuordnung der Sichten, Verzeichnis, Glossar und Abkürzungsverzeichnis) und warum die Architektur so ist wie sie ist (Hintergrund, Einschränkungen und Bedingungen, Gründe). Erst durch die Berücksichtigung der zuvor genannten Aspekte wird die Dokumentation der Gesamtarchitektur vervollständigt (Clements et al. 2002, S. 323).

148

Sichtenkonzepte

Template for a View Packet Section 1. Primary Presentation of the View Packet

OR

Textual version of the primary presentation

Section 2. Element catalog Section 2.A Elements and their properties Section 2.B Relations and their properties Section 2.C Element interfaces Section 2.D Element behavior Section 3. Context diagram SCF

EDOS/EBnet

ASTER GDS Glas SCF

System

LPS

MODAPS

AMSR-E SCF

MOPITT SCF

ACRIM SCF SAGE III SCF

SAGE III MOC

Section 4. Variability guide Section 5. Architecture background Section 5.A Design rationale Section 5.B Analysis Results Section 5.C Assumptions Section 6. Other information Section 7. Related view packets Abbildung 44: Template für ein View Packet Quelle: (Clements et al. 2002, S. 321)

Unternehmensarchitektur- und SOA-Sichten

149

Template for Documentation Beyond Views How the documentation is organized: Section 1. Documentation roadmap Section 2. View template What the architecture is: Section 3. System Overview Section 4. Mapping between views Section 5. Directory Section 6. Glossary and acronym list Why the architecture is the way it is: Section 7. Background, design contraints, and rationale Abbildung 45: Sichtübergreifende Dokumentation Quelle: (Clements et al. 2002, S. 324)

5.3

Unternehmensarchitektur- und SOA-Sichten

In Kapitel 2.3.2 wurden verschiedene Gesamtarchitekturansätze, -modelle und -Frameworks im Bereich der Unternehmensarchitektur genannt, die eine multiperspektivische Betrachtung der Gestaltungsobjekte erlauben. Abhängig von den unterschiedlichen Teilarchitekturen unterscheiden sich dabei der Umfang bzw. die Breite und das Granularitätsniveau der betrachteten Objekte. Die Konstruktionsregeln der einzelnen Architekturtypen geben vor, wie die Gestaltungsobjekte aus einer bestimmten Perspektive bzw. Sicht und mit Blick auf die angestrebten Eigenschaften miteinander in Beziehung zu setzen sind. In solch mehrstufigen Architekturen existieren schichtspezifische und schichtübergreifende Sichten (Winter und Fischer 2006, S. 31). Auf Basis der Konzepte mehrschichtiger Repräsentationen und Aggregationshierarchien (siehe Kapitel 2.3.2) sowie schichtübergreifender Sichten kann bspw. die Unternehmensarchitektur als diejenige Sicht definiert werden, die alle aggregierten Artefakte und ihre Beziehungen über alle Ebenen hinweg darstellt (siehe Abbildung 46). Dabei werden nur die Artefakte der höchsten Aggregationsstufe als fundamental angesehen, so dass alle weiteren Artefakte tieferer Aggregationsstufen von spezialisierten Architekturen abgedeckt werden müssen (Winter und Fischer 2006, S. 31). Auf Ebene der Softwarearchitektur kann dann bspw. auf einen der in Kapitel 5.2 vorgestellten Ansätze zurückgegriffen werden.

150

Sichtenkonzepte

Business Architecture

Process Architecture

Integration Architecture

Software Architecture

Technology Architecture

Enterprise Architecture

Abbildung 46: Unternehmensarchitektur als schichtübergreifende Sicht von aggregierten Artefakten Quelle: (Winter und Fischer 2006, S. 32)

Im Bereich der Unternehmensarchitekturen folgen viele Ansätze und Frameworks den Empfehlungen des ISO/IEC 42010 IEEE Std 1471-2000 oder erweitern diese um zusätzliche Konzepte. Im Folgenden wird dies am Beispiel von TOGAF Version 9 veranschaulicht und auf die Vorschläge des Frameworks zur Erstellung und Verwendung von Architektursichten eingegangen. Die Kernkonzepte von TOGAF Version 9 wurden in Kapitel 2.3.3 bereits vorgestellt. Die Entwicklung von Architektursichten wird im Rahmen der Architecture Development Method als iterativer Prozess verstanden (The Open Group 2009c, S. 414f.). Typischerweise vollzieht sich der Prozess ausgehend von den Geschäftsanforderungen bis hin zu Fragen der Technologie und von einer High-Level-Übersicht zu Low-Level-Details. Dabei wird ein ständiger Bezug zu den Concerns und Anforderungen der unterschiedlichen Stakeholder gewahrt. Darüber hinaus muss die jeweilige Iterationsstufe sowohl für die bestehende Umgebung als auch für die Zielumgebung durchgeführt werden. Das bedeutet, dass entsprechende Architektursichten für die Baseline-Architektur und die Zielarchitektur erstellt werden müssen, um somit einen Kontext für Gap-Analysen zur Verfügung stellen zu können.

Unternehmensarchitektur- und SOA-Sichten

151

TOGAF befürwortet bei der Erstellung von Architektursichten die Empfehlungen, Definitionen und Konzepte von ISO/IEC 42010 IEEE Std 1471-2000, schreibt deren Verwendung aber nicht zwingend vor (The Open Group 2009c, S. 415). Auch wenn ISO/IEC 42010 IEEE Std 1471-2000 kein spezifisches Vorgehen zur Erstellung von Viewpoints oder Views vorsieht, so haben sich in Unternehmen die folgenden Schritte als gängige Praxis bewiesen (The Open Group 2009c, S. 415): 1. Nachschlagen in einer bestehenden Bibliothek von Viewpoints. 2. Auswählen geeigneter Viewpoints (bezogen auf die Stakeholder und deren Concerns, die von den Views abgedeckt werden sollen). 3. Erzeugen von Sichten unter Verwendung der ausgewählten Viewpoints als Vorlage. In TOGAF wird eine Vielzahl empfohlener Viewpoints vorgestellt, die als Ausgangspunkt bei der Architekturentwicklung dienen sollen und um weitere Viewpoints ergänzt werden können. Die einzelnen Viewpoints werden daher nur als Orientierungshilfe und nicht als vollständige Definition verstanden. Typischerweise werden zur Erweiterung oder zur Erstellung neuer komplexerer Viewpoints in einem Unternehmen Stakeholder-Concerns identifiziert (The Open Group 2009c, S. 419). Wie zuvor beschrieben stellt das Architecture Content Framework im Rahmen von TOGAF ein strukturelles Modell (Content Metamodel) zur Verfügung, mit dem die zahlreichen Arbeitsergebnisse (kategorisiert in Deliverables, Artifacts und Building Blocks), die aus den Phasen der Architecture Development Method hervorgehen, konsistent definiert, strukturiert und dargestellt werden können. Abbildung 47 zeigt die unterschiedlichen Viewpoints, die dem Content Metamodel und den einzelnen Content-Erweiterungen zugeordnet sind. Als spezifische Klassen von Viewpoints werden unterschieden (The Open Group 2009c, S. 420): x

Kataloge: Spezifische grundlegende Viewpoints, die Listen von Building Blocks repräsentieren.

x

Matrizen: Spezifische grundlegende Viewpoints, die die Beziehungen zwischen Building Blocks spezifischen Typs darstellen.

x

Diagramme: Graphische Viewpoints, die Building Blocks visuell darstellen und somit besser für die Kommunikation zwischen Stakeholdern geeignet sind.

Auch die einzelnen TOGAF-Architekturdomänen (Business Architecture, Data Architecture, Application Architecture, Technology Architecture) werden in diesem Zusammenhang als Viewpoints verstanden, mit denen Kataloge, Matrizen und Diagramme gruppiert werden können.

152 1

Sichtenkonzeptee

Abbildung A 47: TOGAF Core Conten nt Metamodel und d zugehörige View wpoints Quelle: Q (The Open G Group 2009c, S. 4119)

Im Vergleich zuu Software- unnd Unternehmennsarchitekturanssätzen sind Disskussionen überr Architektursicht A en im Bereich serviceorientiert s ter Architektureen nicht so weitt verbreitet. Derr Grund G dafür maag darin liegen, dass sich, wiee die Betrachtunngen der Zusam mmenhänge vonn und serviceorieentierten Architekturen gezeigtt haben (Kapiteel 3.1.4), Unter-UnternehmensU nehmensarchitek n kturansätze um SOA-spezifisch he Charakteristika erweitern laassen. Und auchh die d technischen A Aspekte einer SOA S lassen sichh in Verbindung mit Softwarearchitektursichtenn und u entsprechenden Erweiterunggen betrachten. Als A Erweiterungg wäre bspw. diee Definition SO OA-spezifischer Viewpoints V unteer Berücksichti-gung g der entsprrechenden Term minologie sowie serviceorientierrter Designprinnzipien und Pat-terns zu versteheen, mit denen Aspekte A betrachhtet werden, die von Viewpointts der Software-oder o Unternehm mensarchitekturannsätze nicht abg gedeckt werden.. Eine Trennungg der Aspekte inn Form F von Viewppoints könnte siich z.B. an den Abstraktionsschhichten einer SO OA (siehe Kapi-tel 3.2.3) oder eiinzelnen Phasenn eines SOA-Leb benszyklus orienntieren.

Unternehmensarchitektur- und SOA-Sichten

153

Eine Beschreibung dreier grundlegender SOA-Viewpoints liefert bspw. die OASIS Reference Architecture Foundation for Service Oriented Architectures (Estefan et al. 2009, S. 15ff.), die ebenfalls auf den Empfehlungen von ISO/IEC 42010 IEEE Std 1471-2000 basieren: Service Ecosystem, Realizing Service Oriented Architectures und Owning Service Oriented Architectures. Der Service Ecosystem Viewpoint fokussiert die Art und Weise, wie Personen Geschäfte sicher und effizient auf Basis serviceorientierter Systeme durchführen können. Dabei stehen insbesondere die sozialen Strukturen der unterschiedlichen Teilnehmer und deren Verhaltensweisen im sozialen Kontext im Vordergrund. Der Fokus des Realizing Service Oriented Architectures Viewpoint ist auf Aspekte bezüglich des Aufbaus einer SOA gerichtet. Dazu zählen Infrastrukturelemente, wie z.B. Service Descriptions, Policies und Contracts, die notwendig sind, um die Discovery von und die Interaktion mit Services zu ermöglichen. Der Schwerpunkt des Owning Service Oriented Architectures Viewpoint liegt auf Aspekten, die sich auf den Betrieb, das Management und das Controlling einer SOA beziehen. Von daher stehen die Governance SOA-basierter Systeme, Herausforderungen in Bezug auf Sicherheitsfragen und das Management sowie die Qualitätssicherung mithilfe geeigneter Teststrategien im Vordergrund. Tabelle 15 fasst die Viewpoint-Spezifikationen der drei grundlegenden Viewpoints der Referenzarchitektur zusammen. Viewpoint Element

Viewpoint Service Ecosystem

Realizing Service Oriented Architectures

Owning Service Oriented Architectures

Kernkonzepte

Beschreibt, was es im Sinne von SOA für Personen bedeutet, Teil eines Service Ecosystems zu sein.

Beschreibt die Anforderungen zum Aufbau einer SOA.

Adressiert Problemstellungen beim Management einer SOA.

Stakeholders

Personen, die SOA einsetzen: Entscheider, Unternehmensarchitekten, Standardisierungsarchitekten und Analysten

Standardisierungsarchitekten, Unternehmensarchitekten, Geschäftsanalysten, Entscheider

Service Providers, Service Consumers, Unternehmensarchitekten, Entscheider

Concerns

Sichere und effiziente Ausführung des Geschäfts

Effektive Konstruktion SOA-basierter Systeme

Prozesse zum Betrieb einer SOA sind effektiv, angemessen und gesichert.

Modellierungstechniken

UML Klassendiagramme

UML Klassen-, Sequenz-, Komponenten-, Aktivitäts-, Kommunikations-, und Kompositionsdiagramme

UML Klassen- und Kommunikationsdiagramme

Tabelle 15: Viewpoint Spezifikationen der OASIS Reference Architecture Foundation for SOA Quelle: In Anlehnung an (Estefan et al. 2009, S. 15)

154

5.4

Sichtenkonzepte

Sichtendilemma

Die Herausforderungen und Fragestellungen, mit denen soziale Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme konfrontiert sind, wurden unter Berücksichtigung systemtheoretischer Ansätze und dem damit verbundenen Verständnis von Komplexität in Kapitel 4.5 bereits diskutiert. Im Folgenden werden sie im Zusammenhang mit den zuvor vorgestellten Sichtenkonzepten wieder aufgegriffen und detaillierter analysiert. Die Zielsetzungen der vorgestellten Sichtenkonzepte haben gemein, dass sie u.a. Aspekte der Kommunikation von Architekturen fokussieren. Bass et al. fassen die Bedeutung der Kommunikation im Architekturentwicklungsprozess wie folgt zusammen: „For the architecture to be effective as the backbone of the project’s design, it must be communicated clearly and unambiguously to all of the stakeholders. Developers must understand the work assignments it requires of them, testers must understand the task structure it imposes on them, management must understand scheduling implication it suggests, and so forth” (Bass et al. 2003, S. 13f.). Bei genauer Betrachtung der einzelnen Ansätze wird jedoch deutlich, dass der Aspekt der Architekturkommunikation nicht explizit in den Frameworks oder Modellen berücksichtigt wird, sondern nur implizit aus den vorhandenen Konzepten abgeleitet werden kann. Mit dem in Kapitel 4.5.1 dargelegten Verständnis über die Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme nimmt der Aspekt der Kommunikation in Bezug auf die Sichtenkonzepte jedoch eine zentrale Rolle ein. Das Konzept der Architekturbeschreibung und die zugrunde liegenden Sichten und Modelle sollten daher als ein zentrales Kommunikationsmedium bei der Entwicklung und dem Management betrieblicher Anwendungssysteme betrachtet werden. So sind Stakeholder im Rahmen des Architekturmanagements Teil unterschiedlicher sozialer System/Umwelt-Konstellationen, die Designentscheidungen in Bezug auf die Architektur treffen und kommunizieren, Elemente und Relationen zur Betrachtung bestimmter Aspekte selektieren und diese sowie weitere gewonnene Informationen in Form von Architekturbeschreibungen festhalten. Wie bereits diskutiert, entstehen im Laufe der Architekturevolution somit zahlreiche Sichten aus unterschiedlichen Perspektiven, die die Relevanzkriterien spezifischer System/Umwelt-Konstellationen erfüllen. Gleichzeitig gilt es jedoch zu berücksichtigen, dass die Architekturbeschreibung als Kommunikationsmedium wiederum zahlreichen unterschiedlichen System/Umwelt-Konstellationen zur Verfügung gestellt werden muss, damit diese auf Basis ihrer Relevanzkriterien systemspezifische Informationen gewinnen und neue Entscheidungen kommunizieren können. Die Möglichkeiten der Anschlusskommunikation unterschiedlicher System/Umwelt-Differenzen sind demnach zu einem Großteil von der Architekturbeschreibung und den zuvor getroffenen Entscheidungen abhängig. Wird der Kommunikationsaspekt in Bezug auf die unterschiedlichen System/Umwelt-Differenzen nur

Sichtendilemma

155

unzureichend berücksichtigt und die Architekturbeschreibung als reines Arbeitsergebnis von und nicht als Medium für Kommunikationsprozesse aufgefasst, so besteht die Gefahr, dass die Beschreibung bzw. Dokumentation der Architektur einem reinen Selbstzweck verfällt. In einzelnen Teilbereichen der Architektur-Community wird der Kommunikationsaspekt zunehmend aufgegriffen. Der Fokus der Forschungsarbeiten richtet sich dort verstärkt auf die Kommunikation von Architekturentscheidungen (Bosch 2004; Dueñas und Capilla 2005; Ven et al. 2006; Capilla und Nava 2007; Tyree und Akerman 2005) und Architekturwissen (Lago et al. 2008; de Boer et al. 2007; Clerc et al. 2008). Bspw. adressieren Lago et al. in einem Diskussionspapier zum Thema Architekturwissen die zentralen Fragestellungen, was überhaupt relevantes Architekturwissen ist und wie dieses Wissen geteilt werden kann (Lago et al. 2008). Die zwei Fragestellungen schließen die damit wichtige Frage ein, wie das richtige Wissen den richtigen Personen zu jedem denkbaren Zeitpunkt zur Verfügung gestellt und zugänglich gemacht werden kann. Dies zeigt, dass Dokumentationen nicht allein die Ziele ihrer Ersteller adressieren, sondern sich vielmehr an die Interessen eines breiten Publikums unterschiedlicher Zielgruppen richten sollten. Bosch sieht den nächsten Schritt in der Entwicklung von Architekturansätzen dahingehend, dass die Architektur als eine Menge von Designentscheidungen angesehen wird und nicht, wie bei klassischen Ansätzen, als eine Menge von Komponenten und deren Relationen (Bosch 2004, S. 197). Dieser Meinung sind auch Largo et al., wie folgendes Zitat zeigt: „The next evolution step represents a fundamental change in the notion of software architecture. By recognizing that architects are mainly decision makers, software architecture can be seen as a set of design decisions. This definition covers a broader perspective of the profession, trying to solve problems like governance of know-how within the company. Recent work addresses an even broader definition, which focuses on the complete knowledge produced around the software architecting process, and its integration.” (Lago et al. 2008, S. 271) Ausgehend von diesen Einschätzungen werden klassische Architekturkonzepte um Ansätze zur Dokumentation von Architekturentscheidungen und Entscheidungsprozessen erweitert, um somit das Verständnis und die Kommunikation hinsichtlich der Architektur zu verbessern (Dueñas und Capilla 2005; Ven et al. 2006; de Boer et al. 2007). Auch bei der Weiterentwicklung des ISO/IEC 42010 IEEE Std 1471-2000 wird im aktuellen Entwurf ISO/IEC WD4 42010 IEEE P42010/D6 ein stärkerer Fokus auf die Dokumentation von Architekturentscheidungen, der Architecture Rationale und deren Einfluss auf Architekturelemente gelegt (ISO/IEC und IEEE 2009, S. 9f.). All diese Bemühungen weisen einen Schritt in die richtige Richtung. In Bezug auf die in Kapitel 4.5.2 dargelegten Problemstellungen und Herausforderungen stoßen die bestehenden Sichtenkonzepte trotz solcher Erweiterungen jedoch an gewisse Grenzen. So ist es nach wie vor fraglich, wie der Informationsbedarf bei einer solch hohen Varietät multidimensionaler

156

Sichtenkonzepte

Interessen unterschiedlicher System/Umwelt-Konstellationen im Laufe der Architekturevolution gedeckt werden kann. Zudem müssen der Eigendynamik und den damit verbundenen Wechselwirkungen sozialer Systeme besondere Beachtung geschenkt werden. Wie zuvor erwähnt, sollte die Architekturbeschreibung den zahlreichen unterschiedlichen System/UmweltKonstellationen als Kommunikationsmedium dienen. Die Architekturbeschreibung und die darin organisierten Sichten sind in Bezug auf die fokussierten Aspekte und aufgrund ihrer manuellen Erstellung jedoch sehr statisch und starr. Natürlich unterliegen solche Sichten einer kontinuierlichen Veränderung und einem Anpassungsprozess. Die mit einer bestimmten Sicht verbundenen Interessen (Concerns) und die damit betrachteten Aspekte bleiben jedoch unverändert – ansonsten würde eine komplett neue Sicht erstellt werden. Insofern wird der Begriff der Architekturdokumentation, wenn dieser als ein Ausdruck statischer Kommunikation aufgefasst wird, den Anforderungen der Kommunikation, insbesondere denen der häufig auftretenden asynchronen Kommunikation, nur unzureichend gerecht. Das Dilemma, das sich somit aus einer Menge statischer Sichten auf Basis vordefinierter Viewpoints ergibt, ist, dass diese Sichten, bzw. die darin enthaltenen Daten, die Relevanzkriterien zahlreicher System/Umwelt-Konstellationen nicht erfüllen und daher notwendige Informationen nicht gewonnen werden können. Im Falle einer Kontextänderung ist somit der Kontext, in dem die Sichten erstellt wurden, im Zeitpunkt des Sichtenkonsums nicht mehr gültig. Dies birgt die Gefahr, dass trotz einer großen Menge dokumentierter Sichten erhebliche Defizite bei der Informationsversorgung entstehen können und somit die Betrachtung relevanter kontextspezifischer Aspekte mit Bezug auf das Gesamtsystem nicht oder nur mit erheblichem Aufwand möglich ist. Die zwei folgenden abstrakten Beispiele verdeutlichen die Problematik. Das erste Beispiel in Abbildung 48 zeigt die Erstellung und Verwendung von Sichten im Entwicklungsprozess entlang einer Zeitachse. In den Zeitpunkten x1 bis x4 werden Sichten unter Berücksichtigung bestimmter Interessen und den entsprechenden Viewpoints erstellt und dokumentiert. In Zeitpunkt xn jedoch entstehen Interessen im Rahmen von Kommunikationen, für die weder eine View noch ein zugrunde liegender Viewpoint definiert wurde. Der Viewpoint und eine entsprechende Sicht müssten somit „just in time“ erstellt werden können. Im TOGAF-Framework wird ein ähnlicher Sachverhalt beschrieben (The Open Group 2009c, S. 415), der auf die zuvor geschilderte Problematik hinweist. Demnach können Situationen auftreten, in denen eine spezielle Sicht notwendig ist, für die jedoch kein entsprechender Viewpoint vordefiniert wurde.

Sichtendilemma S

1577

Abbildung A 48: Con ncerns, Viewpointts, Views und Artiffacts im Lebenszyyklus

Dies D ist insbesonndere dann der Fall, wenn Emp pfehlungen, wiee die des ISO/IE EC 42010 IEEE E Std S 1471-2000-S Standards, noch nicht in die Arcchitekturentwickklung einer Organisation einbe-zogen z wurden uund somit keine umfassende Biibliothek mit Viiewpoints zur Verfügung V steht.. Wie W von ISO/IE EC 42010 IEEE Std 1471-2000 empfohlen, wääre es nun eine Möglichkeit, M ei-nen n neuen View wpoint zu entwicckeln, der die erforderlichen e A Aspekte abdeckt und auf dessenn Basis B eine Sicht erzeugt werdenn kann. Als Alteernative dazu wird w ein pragmattischerer Ansatzz vorgeschlagen, v n nämlich die Sichht für ein spezifi fisches System ad a hoc zu erstellen und erst spä-ter zu entscheiden, ob eine absstraktere Form des d impliziten Viewpoints V – jede Sicht besitztt mindestens m einenn impliziten Viewpoint – expliizit definiert unnd in einer Bibliiothek zur Wie-derverwendung d g gespeichert werrden sollte (The Open Group 20009c, S. 415). Eine E andere Perrspektive auf die gleiche Probllematik liefert Abbildung A 49. Das D zweite Bei-spiel s zeigt Sichten, die Architekkturelemente un nd Relationen inn Bezug auf besttimmte Metada-ten, Daten und Artefakte A unterschiedlicher Absstraktionsschichtten umfassen (zz.B. View „yz“).. Wenn W nun aber Interessen an Elementen E und Relationen der Architektur enntstehen, für diee keine k Sicht auf die entsprechennden Metadaten n, Daten und Arrtefakte existiertt, muss auch inn diesem d Fall eine neue Sicht (verranschaulicht duurch View “???““) erstellt werdenn.

158 1

Sichtenkonzeptee

Abbildung A 49: Sich hten, Metadaten, Daten D und Artefak kte unterschiedlicher Abstraktionssschichten

Die D Fokussierunng bestimmter Aspekte A bedeuteet eben nicht nuur, dass andere Aspekte A aus ei-nem n gewählten B Blickwinkel keiine Relevanz beesitzen, sondernn auch, dass zahhlreiche Aspektee im m Kontext der Sichtenerstelluung gar nicht bekannt b sind bzzw. berücksichtiigt werden undd ih hnen somit keinne Relevanzkriteerien zugerechnet werden könneen. Wenn jedocch ein Aspekt zuu einem e anderen Z Zeitpunkt aus eiinem bis dahin nicht n gewähltenn Blickwinkel reelevant wird, soo muss m dafür Sorgge getragen werdden, dass entspreechende Sichtenn zeitnah zur Verrfügung stehen. Für F das Überdeckungsverhältniis relevanter Aspekte von Stakkeholder-Interesssen und doku-mentierten m Sichtten können die vier v folgenden Fälle F identifiziertt werden: 1. 2. 3. 4.

Eine dokkumentierte Sichht beinhaltet allee relevanten Asppekte. Relevantte Aspekte sind über ü unterschieddliche Sichten verteilt. v Es existieeren dokumentieerte Sichten, diee aber nur Teilasspekte abdeckenn. Aspekte sind in keiner dokumentierten Sicht S vorhandenn.

Eine E abstrakte D Darstellung der vier v Überdeckun ngsmöglichkeiteen wird in Abbilldung 50 veran-schaulicht. s

Sichtendilemma S

1599

Abbildung A 50: Übeerdeckungsverhälttnis zwischen View ws und Stakeholdeer-Concerns

Die D Gründe dafü für, dass Sichtenn im Laufe der Architekturevollution nicht denn Interessen vonn Stakeholdern S enttsprechen, sind vielfältig. Eine zentrale Ursachhe ist darin zu sehen, dass auchh bei b der Sichtenerstellung durch das vorherrscheende Prinzip dess „divide and coonquer“ (Boochh et e al. 2007, S. 32ff.; Dijkstra 19979, S. 5; Parnaas et al. 2001, S. S 497ff.) vor alllem analytischee Denkprozesse D zuu Konstruktionsergebnissen füh hren (vgl. Kapiteel 4.5.2), die x

an bestim mmte Phasen dess Lebenszyklus gebunden sind,

x

unterschiiedliches Abstraaktionsniveau un nd unterschiedlicchen Detailgradd besitzen,

x

Lücken zwischen z Mikro- und Makro-Peerspektiven aufw weisen,

x

unterschiiedliche Verschaachtelungstiefenn besitzen,

x

starke Abbhängigkeitspfade besitzen,

x

technischhe und fachlichee Aspekte voneinnander trennen.

Auch A andere Foorschungsarbeiteen sehen in den genannten Punnkten Ursachen für Defizite beii der d Informationssversorgung (z.B B. (Egyed 1999 9; Murphy et al. 2001; Medvidoovic et al. 2003;; Kennaley K 2008; Boehm und Poort 1999; Maleticc et al. 2005)). Der Fokus dieser Ansätze liegtt in n der Verbesserrung der Traceaability von Modellen, der Sichteenintegration unnd der Überbrü-ckung c von Infoormationslückenn zwischen Entw wurfs- und Impplementierungsaartefakten bzw.. zwischen z High-L Level- und Low w-Level-Modelleen entlang des Lebenszyklus. L M Medvidovic et al.. (Medvidovic et al. 2003, S. 199) 1 verweisen in diesem Zussammenhang innsbesondere auff Schwierigkeiten S ,

160

Sichtenkonzepte

x

die Konsistenz der Informationen über mehrere Modelle hinweg sicherzustellen, die die gleichen Artefakte beschreiben (z.B. Klasseninstanzen in Objekt- oder Kollaborationsdiagrammen) und

x

die Konsistenz der Informationen über mehrere Modelle hinweg sicherzustellen, die unterschiedliche Artefakte beschreiben (z.B. Use Cases in den Anforderungen und Klassen im Entwurf).

Sie fügen hinzu, dass in beiden Fällen jedes Modell unterschiedliche Informationen auf unterschiedliche Art und Weise darstellt und es somit schwierig ist, Eigenschaften festzulegen, die sich auf das modellierte Phänomen im Ganzen beziehen (Medvidovic et al. 2003, S. 199). Wichtige systemische Fragestellungen, die im Sinne systemischer Denkansätze ganzheitliche und dynamische Aspekte berücksichtigen, sind auf Basis analytischer Konstruktionsergebnisse bzw. Sichten nur schwer zu beantworten. Bspw. verlangt der Umgang mit Abhängigkeiten und Wechselwirkungen eine stärkere Berücksichtigung von cross-cutting Concerns, die wiederum die Betrachtung relevanter Aspekte über zahlreiche Sichten mit unterschiedlichem Abstraktionsniveau oder Detailgrad hinweg erfordern. Eine weitere Problematik, die indirekt im Zusammenhang mit dem Überdeckungsverhältnis von Sichten und Concerns steht, ist die Verwendung unterschiedlicher Terminologien und Notationen auf Seiten der Sichtenersteller und Sichtenkonsumenten (siehe Abbildung 51). Das bedeutet, dass eine Sicht in Bezug auf einen Concern zwar alle erforderlichen Daten beinhalten kann, diese jedoch aufgrund eines unterschiedlichen Verständnisses der Terminologie und Darstellung bzw. Visualisierung nicht als solche verstanden bzw. wahrgenommen und somit die benötigten Informationen nicht gewonnen werden können. Bspw. wurden bei der kognitiven Verarbeitung von Diagrammen einige Unterschiede zwischen Experten und Personen, die mit den Darstellungsformen nicht vertraut sind, festgestellt (Koedinger und Anderson 1990; Winn 1993; Lohse et al. 1995; Cheng et al. 2001; Novick 2006). Die Problematik der Terminologie- und Notationsdiskrepanz bezieht sich zwar in erster Linie auf die Wahrnehmung und das Verständnis psychischer Systeme einzelner Stakeholder, ist aber durch deren strukturelle Kopplung mit sozialen Systemen (siehe Kapitel 4.2.3.3) auch für den Aspekt der Kommunikation ein wichtiger Faktor. Werden bspw. einem Mitarbeiter der Fachbereiche technische Modelle vorgelegt, die er aufgrund unbekannter Terminologien und Notationen nicht verstehen kann, so besteht die Gefahr negativer Auswirkungen auf die Anschlusskommunikation mit anderen Mitarbeitern. Das bedeutet, dass möglicherweise im Rahmen der Anschlusskommunikation Fehlentscheidungen in Bezug auf die Gesamtarchitektur getroffen werden oder durch die Nicht-Erfüllung bestimmter Erwartungen überhaupt keine Anschlusskommunikationen mehr zustande kommen.

Sichtendilemma S

1611

Abbildung A 51: View w-Provider vs. View-Consumer Quelle: Q Verändert nnach (Freitag 2001, S. 12)

Wie W bereits die Diskussionen inn Kapitel 4.5 geezeigt haben, istt es aufgrund dees dynamischenn Umfelds U sozialeer Systeme undd den systemiscchen Wechselwirkungen, die deren d Verhaltenn beeinflussen, b niccht möglich, füür jede zukünftige System/Umw welt-Konstellatiion die entspre-chenden c Relevannzkriterien zu antizipieren a undd im Vorhinein festzulegen. Zaahlreiche Frage-stellungen s lassenn sich somit nurr im Zuge einerr Re-Integrationn von Konstruktionsergebnissenn und u mit einer „juust in time“-Bereitstellung kontextspezifischer Sichten beantwoorten. Um U den dargestellten Herausforderungen und Problemen bei der Informationnsgewinnung zuu entgegnen, e sind unterschiedlichee Ansätze denkbbar. So wäre es bspw. über einee Sichtensynthe-se s bzw. Rekonsttruktion von Sicchten, d.h. durch h die Zusammennfassung oder Verknüpfung vonn Daten D mehrerer Konstruktionseergebnisse, möglich, relevantee Informationenn zu gewinnen.. Dies D könnte auff Basis von Techhniken und Straategien erweitertter Sichtenkonzeepte, wie sie im m Rahmen R des SE EI-Ansatzes prokklamiert werdenn (siehe Kapiteel 5.2.2), erfolgeen. Eine solchee Synthese S bzw. R Rekonstruktion ist jedoch ein zeiitaufwendiger und u kostenintenssiver Prozess, daa abhängig a von deen aufkommendeen Fragestellung gen und Interesssen die relevanteen Aspekte überr zahlreiche z nicht direkt identifiziierbare Sichten bzw. Sichtenarttefakte verteilt sein s können undd aufbereitet a werdden müssen. Zuddem ist nicht sichhergestellt, dasss auf Basis bereiits dokumentier-ter Sichten und dden darin zur Verfügung V gestelllten spezifischeen Detaildaten Innformationen inn Bezug B auf Relevvanzkriterien annderer emergennter Systemebennen gewonnen werden w können..

162

Sichtenkonzepte

Ferner sind Sichten nicht überschneidungsfrei, so dass sich bezüglich der betrachteten Elemente und Relationen bzw. ihrer Teilstrukturen Schnittmengen bilden und somit Redundanzen auftreten, die immer der Gefahr von Inkonsistenzen ausgeliefert sind. Eine andere Möglichkeit besteht darin, Elemente und Relationen aus den Konstruktionsergebnissen zu extrahieren und in Form von Daten und Metadaten in einer speziellen Datenbank zu speichern. Dem Entwicklungssystem und seinen Teilsystemen würde somit ein Gedächtnis zur Verfügung stehen. Die Basis eines solchen Gedächtnisses können bspw. moderne Repositories bilden, mit denen Elemente und Relationen unterschiedlichster Konstruktionsergebnisse über eine gezielte Erfassung von Daten und Metadaten in Beziehung gesetzt werden. Anders als bei einer Sichtensynthese läge der Vorteil bei der Informationsgewinnung darin, dass die Elemente und Relationen bzw. die Daten und Metadaten von den Relevanzkriterien bestimmter Sichten entkoppelt sind. Aber selbst bei der Verfügbarkeit eines solchen Gedächtnisses besteht nach wie vor das Problem, aus den systemübergreifenden Daten und Metadaten systemspezifisch relevante Informationen zu generieren und in Form von Sichten mit entsprechenden Darstellungsformen „just in time“ zur Verfügung zu stellen. Ziel ist es daher, im weiteren Verlauf der Arbeit ein Konzept zu entwickeln, dass unter Berücksichtigung des im IEEE-Standard definierten Frameworks und den darin festgelegten Terminologien Instrumente zur Verfügung stellt, Sichten in Bezug auf kontextspezifische Relevanzkriterien unterschiedlicher System/Umwelt-Konstellationen zu generieren. Der Standard wird somit nicht nur als Grundlage für die Beschreibung von Architekturen mit dem Schwerpunkt der Sichtenerstellung im Rahmen analytischer konstruktionsorientierter Aktivitäten verstanden. Er wird vielmehr als Basis für ein offenes generalisiertes und systemisch orientiertes Sichtenkonzept – nachfolgend als Generisches Sichtenkonzept bezeichnet – interpretiert, mit dem Fokus, die (Eigen-)Dynamik und Wirkungsgefüge komplexer sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme und deren Umwelten aufnehmen zu können. Es sei noch einmal betont, dass mit dem Ziel keinesfalls die Absicht verfolgt wird, die Daseinsberechtigung vorhandener Sichtenkonzepte bzw. deren Errungenschaften im Rahmen der Entwicklung und des Managements betrieblicher Anwendungssysteme in Frage zu stellen. Wie die Prämissen des Generischen Sichtenkonzepts zeigen werden, sind die bestehenden Ansätze nach wie vor als Schlüsselkonzepte für den Entwurf und die Beschreibung bzw. Dokumentation von Architekturen zu verstehen. Insofern stellt das Generische Sichtenkonzept eine Ergänzung etablierter Sichtenkonzepte dar, das zu einer Verbesserung der Beherrschung von Komplexität in einem Netz aus emergenten Ordnungsstrukturen mit nicht mehr vorhersehbaren Wechselwirkungen und hoher Dynamik beitragen soll und sich damit den Ansprüchen einer systemischen und polykontexturalen Wirklichkeit annähert.

6

Generische Sichten

In diesem Kapitel wird ein Konzept zur Erzeugung kontextspezifischer Sichten auf SOAbasierte Systeme – im Folgenden als Generisches Sichtenkonzept bezeichnet – vorgestellt, das unter Berücksichtigung der zuvor beschriebenen Grenzen und Problemstellungen bestehender Sichtenkonzepte in Bezug auf Kommunikationsaspekte und Aspekte der Informationsversorgung von Stakeholdern entwickelt wurde. Zunächst wird auf die Zielsetzung des Generischen Sichtenkonzepts eingegangen und der Begriff der Generischen Sicht definiert (Kapitel 6.1). Anschließend werden die Prämissen, die dem Konzept zugrunde liegen, festgelegt (Kapitel 6.2) und die Anforderungen beschrieben (Kapitel 6.3). Den Hauptteil des Kapitels bildet das Generische Sichtenmodell, in dem die notwendigen Teilkonzepte zur Erzeugung Generischer Sichten erarbeitet werden (Kapitel 6.4). Im Anschluss daran wird ein 3-D-Entwurf zur Darstellung Generischer Sichten vorgestellt (Kapitel 6.5) und die Verwendung Generischer Sichten aus einer Prozessperspektive diskutiert (Kapitel 6.6). Abschließend wird das Generische Sichtenkonzept im Zusammenhang mit dem im ISO/IEC 42010 IEEE Std 1471-2000Standard definierten Framework betrachtet (Kapitel 6.7). 6.1

Zielsetzung und Definition

Wie bereits in der Einleitung dieser Arbeit beschrieben, liegt die Zielsetzung des Konzepts in der kontextspezifischen Erzeugung von Sichten auf SOA-basierte Systeme, um eine erhöhte Informationsversorgung der Stakeholder zu erreichen und Aspekte der Kommunikation zwischen Stakeholdern besser zu unterstützen. Darüber hinaus wird mit der Zielsetzung ein verbessertes und nachhaltigeres Management betrieblicher Anwendungssysteme, insbesondere in Bezug auf die zuvor angesprochenen Herausforderungen des Architekturmanagements verfolgt. Die kontextspezifische Erzeugung von Sichten bedeutet in diesem Zusammenhang, alle relevanten Aspekte in Bezug auf die Concerns von Stakeholdern unterschiedlicher System/Umwelt-Differenzen „just in time“ zur Verfügung stellen zu können. Generische Sichten werden demnach definiert als Sichten, die unter Berücksichtigung von Relevanzkriterien unterschiedlicher System/Umwelt-Konstellationen kontextspezifisch erzeugt werden und eine geeignete Darstellung der relevanten Aspekte zur Verfügung stellen. Der Begriff generisch bringt dabei zum Ausdruck, dass das Konzept unabhängig von einem bestimmten Kontext, d.h. unabhängig von bestimmten Faktoren, die den Kontext einer System/Umwelt-Konstellation bestimmen (z.B. Lebenszyklusphase, Disziplin, Größe des Systems, Know-how bzw. Erfahrungswerte der Stakeholder), universell einsetzbar ist. Ein wesentlicher Vorteil ist daher vor allem in der Flexibilität zu sehen, mit der sich verschiedene Aspekte einer SOA trotz sich ändernder Kontexte neu miteinander verknüpfen und in Form von Sichten zur Informationsgewinnung und Kommunikation bereitstellen lassen. T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_6, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

164

Generische Sichten

Um das hohe Maß an Flexibilität und den universellen Charakter des Konzepts zu bewahren, werden die einzelnen Teilkonzepte verallgemeinert formuliert und auf spezifische Details, die sich nur auf bestimmte Anwendungsfälle beziehen, verzichtet. Es werden jedoch die Möglichkeiten einer stärkeren Formalisierung des Konzepts bei einer konkreten Implementierung berücksichtigt, indem innerhalb der Teilkonzepte auf verwandte Ansätze verwiesen wird, die durch einen engeren Fokus und damit verbundenen Einschränkungen einen weniger allgemeingültigen Anspruch aufweisen. Durch die automatische Erzeugung von Sichten adressiert das Generische Sichtenkonzept primär die Analyse SOA-basierter Systeme. Die gewonnenen Informationen sollen dabei wichtige Anhaltspunkte für Entscheidungen geben, die im Rahmen des Entwurfs und der Weiterentwicklung eines Systems zu treffen sind. Selbst wenn bereits eine große Menge von Sichten bei der Architekturdokumentation beschrieben wurde, so ermöglicht das Generische Sichtenkonzept, Sichten mit zusätzlichen Aspekten zu generieren, die in keiner bisher vorhandenen Sicht wiederzufinden sind. Im „schlechtesten“ Fall wird dabei eine Sicht generiert, die bereits dokumentiert vorliegt. Diese würde zwar bezüglich neuer Aspekte keinen direkten Mehrwert bringen, könnte aber dennoch zu einer Qualitätskontrolle der dokumentierten Sicht, bspw. in Bezug auf ihre Aktualität, beitragen. Grundsätzlich ist aber in jeder generierten Sicht, die einen Zugewinn an Informationen liefert, ein Mehrwert zu sehen. Ein entscheidender Faktor bei der Entwicklung des Konzepts besteht darin, die Informationsbedarfe der Stakeholder, ein zielgerichtetes Informationsmanagement im Kontext serviceorientierter Architekturen, die Tatsache sich ändernder Kontexte sowie deren Darstellung bzw. Visualisierung gleichermaßen zu berücksichtigen und ganzheitlich zu betrachten. Nur durch das Zusammenspiel dieser Komponenten kann eine adäquate Informationsversorgung gewährleistet werden, die der Vielseitigkeit von Interessen in einem solch dynamischen Umfeld gerecht wird und somit zu einem besseren Verständnis sowie zu einer besseren Beherrschbarkeit von Komplexität beiträgt. 6.2

Prämissen

Um bei der Entwicklung des Konzepts erforderliche Prämissen festlegen zu können, werden zunächst zwei grundlegende Herangehensweisen der Informationsversorgung beim Management und bei der Entwicklung von Anwendungssystemen differenziert. Bei der ersten Herangehensweise wird das Informationsangebot kontinuierlich angepasst, indem Informationen schon zum Zeitpunkt ihrer Entstehung systematisch erfasst werden. Dabei sollte sich nach Möglichkeit eine umfangreiche Informationsversorgung, d.h. eine große Schnittmenge zwischen dem Informationsbedarf und dem Informationsangebot, ergeben (siehe Kapitel 2.2.2). Dafür bedarf es Analysen, welche Informationen in der Evolution eines

Prämissen

165

Systems von Relevanz sind, um somit die notwendigen Daten und Metadaten strukturiert im Rahmen standardisierter Prozesse erheben zu können. Die zweite Herangehensweise bezieht sich auf typische Aktivitäten der Instandhaltung und des Reengineerings, bei denen versucht wird, relevante Informationen so gut wie möglich wiederzugewinnen bzw. zu recovern, da diese bspw. aufgrund unsystematischer Vorgehensweisen zuvor nicht erfasst wurden. Das bedeutet, dass erst im Zuge konkreter Informationsbedarfe durch den Einsatz spezieller Werkzeuge und Verfahren das notwendige Informationsangebot erstellt und die Informationsversorgung wiederhergestellt wird. Beim Vergleich beider Herangehensweisen stehen sich in erster Linie die Aufwände und die Qualität der Informationen sowie die Effizienz, mit der sie gewonnen oder abgerufen werden können, gegenüber. Um die Aufwände der ersten Herangehensweise rechtfertigen zu können, müssten die Informationen zum Zeitpunkt ihrer Entstehung so gezielt erfasst und dokumentiert werden, dass der Nutzen bezüglich der Informationsversorgung höher und die Aufwände zur Erfassung der Informationen niedriger sind als bei üblichen Ansätzen der Wartung und des Reengineerings. Sneed29 merkt diesbezüglich an, dass seines Wissens nach bis heute jedoch keine eindeutigen Erkenntnisse in der Forschung vorliegen, die eine Aussage über das Verhältnis und die Korrelation zwischen dem Dokumentationsaufwand von Softwaresystemen und dem Aufwand für die Wartung und das Reengineering erlauben. Es existiert lediglich eine allgemeine Vermutung und Behauptung, dass ein dokumentiertes Programm einfacher zu warten bzw. zu ändern ist. Trotz der Schwierigkeiten einer Nutzen-Aufwand-Schätzung und anfänglich hoher Investitionskosten gewinnen ingenieursmäßige Vorgehensweisen und standardisierte Prozesse eine zunehmende und immer breitere Akzeptanz. Bei der Einführung und dem nachhaltigen Betrieb serviceorientierter Architekturen zählen dazu bspw. Qualitätssicherungsverfahren, ein gezieltes Informationsmanagement, eine Governance, die Orientierung an bewährten Prinzipien sowie der Einsatz von Patterns und Best Practices. Insofern wird dem Generischen Sichtenkonzept die erste Herangehensweise zugrunde gelegt und von einer systematischen Erfassung relevanter Informationen ausgegangen. Dazu werden folgende Prämissen festgelegt: x

29

Es wird angenommen, dass ein einheitliches Verständnis über die Terminologien, Konzepte, Prinzipien, Eigenschaften, Bestandteile und Ebenen serviceorientierter Architekturen innerhalb des Anwendungskontexts des Konzepts existiert oder geschaffen wird. Die Voraussetzungen dafür sind, wie in Kapitel 3 aufgezeigt, vorhanden.

In einer E-Mail von Harry Sneed an den Autor vom 05.12.2008 auf die Frage, in welchem Verhältnis und in welcher Korrelation der Dokumentationsaufwand von Softwaresystemen zu den Maintenance- oder Reengineering-Aufwänden stehen

166

Generische Sichten

x

Es wird angenommen, dass SOA-Governance-Strategien, die ein Steuerungs- und Regelungssystem zur Überwachung, Durchsetzung und Regulierung von geltenden Richtlinien und Regeln im Rahmen des Informationsmanagements bereitstellen, vorhanden sind oder eingeführt werden. Die SOA-Governance soll bei der Anwendung des Konzepts die Erfassung und Bereitstellung konsistenter Daten unterstützen, damit diese zur Erzeugung Generischer Sichten verwendet werden können. Dadurch, dass die IT-Governance als eine Führungsaufgabe des Informationsmanagements (siehe Kapitel 2.2.1) und die SOA-Governance als ein Erfolgsfaktor bei der Einführung und dem Betrieb einer SOA (siehe Kapitel 3.1.3) gelten, kann die Aufstellung einer SOAGovernance im Unternehmen vorausgesetzt werden.

x

Es wird angenommen, dass Möglichkeiten der Identifikation von Informationsbedarfen existieren. Einen Ausgangspunkt für die Analyse und Identifikation allgemeiner Informationsbedarfe bilden bspw. bestehende Rollenmodelle und die darin festgelegten Aufgaben und Verantwortlichkeiten der einzelnen Rollen (siehe Kapitel 3.4). Zudem können Patternkataloge, Best Practices oder Prozessmodelle zur Ermittlung der Informationsbedarfe herangezogen werden. Darüber hinaus können bspw. Umfragen in einem Unternehmen Aufschluss darüber geben, welche unternehmensspezifischen Informationsbedarfe bezüglich einer SOA existieren. Die Voraussetzungen sind somit auch für diese Prämisse gegeben.

6.3

Anforderungen

Im Laufe dieser Arbeit wurden unterschiedliche Grundlagen zu den Bereichen des Informationsmanagements, des Architekturmanagements, serviceorientierter Architekturen und der Visualisierung betrachtet, die den Bezugsrahmen und den Anwendungskontext für das Generische Sichtenkonzept bilden. Durch die Synthese unterschiedlicher Ansätze und die Betrachtung neuer Aspekte, die bei der Auseinandersetzung mit der Komplexitätsproblematik und Problemstellungen bestehender Sichtenkonzepte erörtert wurden, müssen neben den Anforderungen innerhalb der einzelnen Teilbereiche zusätzliche Anforderungen berücksichtigt werden. Im Hinblick auf die Ziele des Generischen Sichtenkonzepts lassen sich die folgenden spezifischen Anforderungen definieren: x

Ganzheitlichkeit: Wie in Kapitel 4.5 diskutiert, haben insbesondere soziale Aspekte einen starken Einfluss auf die Komplexität der Entwicklung und des Managements von Anwendungssystemen. Zwar tragen analytische Denkweisen und reduktionistische Ansätze zur Komplexitätsbeherrschung bei. Bei Systemen, die von hoher Eigendynamik, emergenten Ordnungsstrukturen und starken Wechselwirkungen geprägt sind, stoßen solche Ansätze jedoch an ihre Grenzen. Im Sinne systemischer Denkan-

Modell Generischer Sichten

167

sätze (siehe Kapitel 4.2.4) sollte das Konzept daher zu einer ganzheitlichen Betrachtung der Entwicklung und des Managements betrieblicher Anwendungssysteme beitragen, um somit das Verständnis systemischer Zusammenhänge und Wechselwirkungen zu verbessern. x

Multidimensionalität: Die Berücksichtigung der Multidimensionalität serviceorientierter Architekturen (siehe Kapitel 3.5) ist eine Kernanforderung. Von daher gilt es, im Rahmen des Konzepts geeignete Mechanismen zur Verfügung zu stellen, mit denen die zahlreichen Aspekte unterschiedlicher Stakeholder-Concerns aus unterschiedlichen Perspektiven betrachtet werden können. Dies gilt insbesondere in Bezug auf die SOAElemente und die damit verbundenen Abhängigkeiten, die auf unterschiedlichen Abstraktionsschichten betrachtet werden können (siehe Kapitel 3.2).

x

Polykontexturalität: Die Polykontexturalität stellt ebenfalls eine Kernanforderung dar, d.h. es müssen Mechanismen zur Verfügung gestellt werden, um Informationen auf Basis von Relevanzkriterien in unterschiedlichen Kontexten gewinnen zu können (siehe Kapitel 4.5.2 und 5.4).

x

Skalierbarkeit: Die Umsetzung einer SOA kann je nach Ausprägungsform bzw. Evolutionsstufe stark variieren. Dabei gilt es sicherzustellen, dass geeignete Mechanismen zur Verfügung stehen, die unabhängig von der Größe einer serviceorientierten Architektur und der damit verbundenen Anzahl beteiligter Stakeholder anwendbar sind.

x

Adaptionsfähigkeit: Um das Konzept in unterschiedlichen Anwendungskontexten einsetzen zu können, muss es adaptionsfähig sein. D.h. es müssen bestimmte Rahmenbedingungen bestehender Konzepte (z.B. Sichtenkonzepte bei der Architekturentwicklung) berücksichtigt werden, um das Konzept in laufende Prozesse integrieren zu können.

Die Anforderungen bilden die Grundlage für den Aufbau und die Bestandteile des Generischen Sichtenmodells, welches im nächsten Kapitel erarbeitet wird. 6.4

Modell Generischer Sichten

Um Generische Sichten einsetzen zu können, bedarf es einer genaueren Definition, welche Teilkonzepte für die Erzeugung Generischer Sichten notwendig sind und wie diese miteinander in Beziehung stehen. Im Folgenden wird ein Modell vorgestellt, das die notwendigen Teilkonzepte und deren Beziehungen zur Erzeugung Generischer Sichten beschreibt. Um der Zielsetzung und den Anforderungen des Generischen Sichtenkonzepts zu genügen, muss das Modell Generischer Sichten ein entsprechendes Abstraktionsniveau besitzen, so dass es in diversen SOA-Szenarien, die sich in ihren Organisationsstrukturen, Implementierungen, Infrastrukturen und Strategien voneinander unterscheiden, angewendet werden kann. Demnach besitzt das Modell einen abstrakten Charakter; mögliche Ausprägungsformen des

168 1

G Generische Sichtenn

Modells M hinsichttlich verschiedeener Anwendung gskontexte sow wie die Möglichkkeiten der Stan-dardisierung d undd Formalisierunng in Bezug auff unterschiedlichhe SOA-Lösunggen werden aberr bei b der Betrachtuung der einzelneen Teilkonzepte berücksichtigt. Abbildung A 52 zeeigt eine Übersiicht des Generisschen Sichtenmoodells und desseen Bestandteile.. Das D Modell ist in vier Hauptbbereiche logisch h unterteilt: Profile, Information, Kontext undd Darstellung. D

Abbildung A 52: Übeersicht des Generiischen Sichtenmod dells

6.4.1 6

Profilee

Um U die Concernns unterschiedliicher Stakeholdder abhängig voon ihren Rollenn und Aufgabenn beschreiben b undd abbilden zu köönnen, werden sogenannte s Proffile verwendet. Der Begriff dess Profils P ist an denn von Krcmar verwendeten Beggriff des Informaationsbedarfsproofils (vgl. Kapi-tel 2.2.2) angelehhnt, in denen deer Informationsb bedarf aus den Ergebnissen E eineer Informations-bedarfserhebung b g für unterschieedliche Nutzerg gruppen aggregiiert werden kannn. Im Kontextt

Modell Generischer Sichten

169

dieser Arbeit entspricht ein Profil der Definition des Informationsbedarfs auf Basis individueller Kriterien, die anhand von Concerns spezifischer Stakeholder abgeleitet werden können. Für die Identifikation von Concerns sind unterschiedliche Ansätze denkbar. Neben der Dokumentation von Concerns, die situativ und kontextspezifisch bei einzelnen Stakeholdern auftreten, besteht die Möglichkeit, Concerns auf Basis einer Analyse von Rollenbeschreibungen (vgl. Kapitel 3.4) oder im Rahmen von Umfragen in einem Unternehmen zu identifizieren. Des Weiteren geben bspw. Entwurfsprinzipien (vgl. Kapitel 3.1.2) wichtige Anhaltspunkte für Fragestellungen in Bezug auf die Architektur. Darüber hinaus kann auf vorhandene PatternKataloge zurückgegriffen werden, in denen bereits eine Anzahl wohlbekannter Concerns identifiziert wurde. Ein solcher Pattern-Katalog wird bspw. von Buckl et al. (Buckl et al. 2008) vorgestellt, in dem 43 Concerns identifiziert wurden. Der Enterprise Architecture Management Pattern Catalog bezieht sich zwar auf den Bereich der Unternehmensarchitektur. Die Zusammenhänge zwischen Unternehmensarchitekturen und serviceorientierten Architekturen (siehe Kapitel 3.1.4) zeigen aber, dass sich bei der Identifikation von Concerns durchaus auch an Arbeiten des Bereichs der Unternehmensarchitektur orientiert werden kann. Bezüglich der Rollen und Aufgaben eines Stakeholders wurde die Entscheidung getroffen, diese nicht direkt mit Profilen in Verbindung zu setzen, d.h. die Definition der Profile nicht auf Basis vordefinierter Rollenbeschreibungen vorzunehmen. Auch wenn die Rolle eines Stakeholders viel über dessen Informationsbedarf impliziert, so würde eine direkte Zuordnung von Rollen und Profilen die Anpassungsfähigkeit des Konzepts einschränken. Dies wird damit begründet, dass Rollen in einem Unternehmen trotz einer Vielzahl verfügbarer Rollendefinitionen (vgl. Kapitel 3.4) typischerweise nicht idealistisch sind und ihre Funktionen und Verantwortlichkeiten durch unterschiedliche Faktoren, wie z.B. die Größe einer Organisation, beeinflusst werden. Der Vorteil, sich bei der Definition von Profilen an Stakeholder-Concerns zu orientieren, liegt darin, dass die Informationsversorgung der Stakeholder feingranularer und flexibler kanalisiert werden kann. Darüber hinaus kann ein Profil auf Basis eines identifizierten Concerns wiederverwendet werden, falls die darin abgedeckten Aspekte auch den Relevanzkriterien von Stakeholdern in anderen Rollen entsprechen. Um Concerns in Form von Profilen abbilden zu können, bedarf es einer Möglichkeit, die darin enthaltenen Aspekte nach bestimmten Kriterien zu strukturieren bzw. zu klassifizieren. In Kapitel 3.2 und 3.5 wurde bereits angeführt, dass die Abstraktionsschichten und Bestandteile einer SOA je nach Betrachtungsweise unterschiedliche Dimensionen aufweisen. Die zahlreichen Aspekte, die je nach Stakeholder Concern und der eingenommenen Perspektive unterschiedliche Relevanz besitzen, unterstreichen die Multidimensionalität einer SOA. Insofern wird der Begriff der Dimension als primäres Konzept für die Definition von Profilen verwendet.

170

Generische Sichten

6.4.1.1

Profildimensionen

Um eine umfassende Kontrolle über die zahlreichen unterschiedlichen Aspekte einer SOA zu gewinnen, wird im Zusammenhang mit der Definition von Profilen das Konzept der Dimension zum Aufbau eines Dimensionssystems eingeführt. Profildimensionen strukturieren und repräsentieren verschiedene Informationsarten, die unterschiedlichen Einfluss auf den Inhalt einer Sicht besitzen. Dimensionen grenzen sich in dem Sinne voneinander ab, dass die von einer Dimension repräsentierten Aspekte durch keine andere Dimension, noch durch eine Kombination mehrerer Dimensionen dargestellt werden können. Die Kombination von Dimensionen erlaubt es hingegen, Metadaten und Daten unter Berücksichtigung unterschiedlicher Dimensionsausprägungen zu filtern, um somit den Informationsgehalt einer Sicht zu beeinflussen. Jede Dimension besitzt mindestens eine Dimensionsausprägung. Alle festgelegten Dimensionen und Dimensionsausprägungen bilden zusammen das Dimensionssystem. Ein Profil wird schließlich über die Konfiguration des Dimensionssystems, d.h. einer Menge von Dimensionen mit den entsprechenden Dimensionsausprägungen, festgelegt. Ein wesentliches Unterscheidungsmerkmal von Dimensionen ist die Kategorisierung in Strukturdimensionen und Wertdimensionen. Strukturdimensionen auf der einen Seite beeinflussen eine Sicht in Bezug auf strukturelle Aspekte einer SOA, d.h. welche SOA-Elemente und Beziehungen in einer Sicht relevant sind und welche nicht. Wertdimensionen auf der anderen Seite bestimmen den Informationsgehalt bezüglich der Merkmale einzelner Elemente und Beziehungen. Um die Beziehungen zwischen Profilen, Profildimensionen und Dimensionsausprägungen sowie deren Einfluss auf Sichten zu verdeutlichen, werden im Folgenden unterschiedliche Struktur- und Wertdimensionen diskutiert. Das Konzept erlaubt im Sinne der Allgemeingültigkeit und Offenheit die Auswahl bzw. Definition eigener Dimensionen, so dass es sich bei den hier ausgewählten Dimensionen und Dimensionsausprägungen lediglich um eine Empfehlung handelt. Insofern kann die Auswahl von Dimensionen im Rahmen einer konkreten Anwendung des Konzepts und unter Berücksichtigung spezifischer SOA-Lösungen von Unternehmen zu Unternehmen variieren. Strukturdimensionen Wie zuvor erwähnt, beziehen sich Strukturdimensionen auf strukturelle Aspekte einer SOA. Als Strukturdimensionen werden im Rahmen dieser Arbeit die drei folgenden Dimensionen unterschieden: x

Lebenszyklus (Lifecycle)

x

Abstraktion (Abstraction)

x

Domäne (Domain)

Modell M Generischerr Sichten

1711

Die D Dimension Lifecycle L hat Einfluss darauf, welche w SOA-Eleemente in Bezugg auf bestimmtee asen Teil einer spezifischen Sicht Lebenszyklusph L S sind. Darüüber hinaus beeinflusst die Di-mension m die struukturellen Abhänngigkeiten, d.h. welche Art vonn Beziehung zw wischen den Ele-menten m innerhalb einer Sicht reelevant ist. Typiische Dimensionnsausprägungenn der Dimensionn Lifecycle L sind Phhasen wie Requiirements, Design, Developmentt, Test, Deploym ment, Operationss oder o Maintenance (siehe Abbilldung 53). So sind s bspw. Servvice-Endpunkt-R Referenzen Teill einer e Sicht, die ssich auf die Phaase Deploymentt oder Operationns bezieht. In deer Phase Designn sind s solche Refferenzen wenigeer oder gar niccht relevant. Darüber hinaus kann k ein SOA-Element E je nach Phase und Blicckwinkel mit untterschiedlichen Aspekten verknnüpft sein. So istt es e bspw. in Bezzug auf einen Service S möglichh, im Requirem ment Managemeent die Service-Anforderungen, A im Design die Service-Spezifik S kation, im Deveelopment die Seervice-Logik, im m Test T die Service--Testfälle und im m Operations die Service-Instannzen zu betrachtten.

Abbildung A 53: Leb benszyklus von SO OA-Elementen

Über Ü die Dimennsion Abstractioon wird bestimm mt, welche SOA A-Elemente durcch ihre Zugehö-rigkeit r zu bestim mmten Abstrakttionsschichten Teil T einer Sicht sind. Zudem kaann mit der Di-mension m Abstracction der Granuularitätsgrad eineer Sicht beeinfluusst werden, waas unterschiedli-che c High-Level-- (macro view) und Low-Levell- (micro view) Perspektiven auf a eine service-orientierte o Archiitektur erlaubt. Zur Auswahl geeeigneter Abstraaktionen könnenn die in Kapitell 3.2.3 3 vorgestelltten SOA-Abstraaktionsschichten n herangezogenn werden. Die Definition D einerr Abstraktionsdim A mension Process könnte dann bsspw. Prozesse, Aktivitäten A oderr Partner umfas-sen, s Services odeer Komponentenn hingegen aussschließen. Abbildung A 54 zeeigt die Zuordnuung von SOA-Elementen zu Abbstraktionsschichhten, die gleich-zeitig z Dimensionnsausprägungenn der Dimensionn Abstraction billden. Die Auswahl von Dimen--

172 1

G Generische Sichtenn

sionsausprägung s gen und die Zuoordnung von SO OA-Elementen orientiert o sich weitestgehend w ann den d von Erl idenntifizierten Abstrraktionsschichteen (siehe Kapitel 3.2.3) und dereen Merkmalen.

Abbildung A 54: Zuoordnung von Absttraktionsschichten n und SOA-Elemen nten

zu folgen, mitt Bezüglich B der A Abstraktionsschiichten ist es wiichtig, einem Ordnungsprinzip O dem d die Anordnnung der Schichhten und Elemennte innerhalb der Schichten festgelegt werdenn kann. k Dazu wurdden die Schichteen und Subschicchten sowie die Elemente E innerhhalb der Schich-ten auf Basis einner hierarchischhen Nummerieru ung gegliedert und u codiert. Im Falle F von dyna-mischen m Bindunngen müsste einee solche Codieru ung für die entspprechenden Elem mente zur Lauf-zeit z erfolgen. Abbildung A 54 zeigt drei SOA-Abstraktionsschhichten, die in weitere w Subschiichten unterteiltt sind s und entspreechend ihrer Abbstraktions- und Hierarchiestufee codiert sind. Am A Beispiel derr Service-Schicht S wird die Zuordnnung von SOA-Elementen darggestellt. Dabei werden w Prozesse,, Aktivitäten A und PartnerLinkTyppes, die in diesem Fall auf Basiis von WSBPEL L (OASIS 2007)) beschrieben b werrden, der Orchesstrated Services-Schicht zugeorrdnet. PortTypes, Bindings undd Services S hingegeen, die mit WSD DL (W3C 2001 1) beschrieben werden, w sind miit den Schichtenn Entity E Services ooder Utility Serrvices assoziiertt. Die Anordnunng der Schichtenn und Elementee stellt s insbesondeere bei der visueellen Darstellun ng einer Sicht eiine wichtige Orrientierungshilfee bei b der Ortung von v Elementen und der Nachvo ollziehbarkeit ihhrer Beziehungeen bzw. Abhän-gigkeiten g dar. Mit M der Dimension Domain kannn beeinflusst werden, w welche SOA-Elementee durch ihre Zu-gehörigkeit g zu bestimmten b Dom mänen Teil eineer Sicht sind. Die D Domäne ist dabei entwederr verantwortlich v fü für ein SOA-Eleement oder wird d von diesem in irgendeiner Artt und Weise un--

Modell M Generischerr Sichten

1733

terstützt. Möglicche Dimensionssausprägungen der d Dimension Domain sind bspw. b Sales, Fi-nance, n Productioon, oder Humann Resources. Umfasst U bspw. die d Domäne Finance bestimmtee Prozesse oder Services, wie Darlehen, D Kredit,, Debit, D etc., so w würden diese beii der Auswahl der d Domäne in einer e Sicht berüccksichtigt. Ähn-lich der Dimenssion Lifecycle kann k ein SOA-E Element auch mehreren m Domäänen zugeordnett sein s (siehe Abbiildung 55), wass bspw. bei dom mänenübergreifeenden Prozessenn oder Servicess und u Komponenteen, die globale Funktionalität F bereitstellen, der Fall ist.

Abbildung A 55: Dom mänen und SOA-E Elemente

Wertdimensionen W n Wie W zuvor erwäähnt, sind Wertddimensionen niccht-strukturelle Dimensionen, D d den Informa-die tionsgehalt einerr Sicht bezügliich der Merkmaale einzelner Elemente E und Beziehungen B be-stimmen. s Sie habben dadurch keinen Einfluss au uf strukturelle Aspekte A einer Siicht. Im Folgen-den d werden zweii Wertdimensionnen unterschied den. Die D technische Dimension ist eine nicht-stru ukturelle Wertdiimension, die unterschiedliche u e Sichten S auf ein S SOA-Element inn Bezug auf tecchnische Merkm male erlaubt. Weerden bspw. vonn einem e Stakeholdder Abhängigkeeiten zwischen Prozessaktivitätten und Servicees analysiert, soo können k technischhe Merkmale wie w das verwendete Protokoll odder der Nachrichhtentyp von Re--

174

Generische Sichten

levanz sein. Beispiele für Dimensionsausprägungen sind technische Merkmale wie Protokolle, Art des Nachrichtenaustauschs, Datentypen, Versionen, Perfomance-Indikatoren oder Sicherheitsmerkmale. Die fachliche Dimension ist eine nicht-strukturelle Wertdimension, die unterschiedliche Sichten auf ein SOA-Element in Bezug auf fachliche Merkmale erlaubt. Beispiele für Dimensionsausprägungen sind fachliche Merkmale wie Preise, Verantwortlichkeiten, Berechtigungen, Policies, Quality of Service oder Geschäftsregeln. 6.4.1.2

Parametrisierung von Dimensionsausprägungen

Um Profile feiner konfigurieren und auf spezifische Concerns abstimmen zu können, besteht die Möglichkeit der Parametrisierung von Dimensionsausprägungen. Parameter bestehen je nach Dimensionsausprägung aus numerischen oder alphanumerischen Werten. Zudem können bekannte Filtertechniken wie Platzhalter, Intervalle oder zusammengesetzte Ausdrücke verwendet werden. In Bezug auf Wertdimensionen stellt die Parametrisierung ein wichtiges Werkzeug dar, um Relevanzkriterien einzelner Stakeholder-Concerns weiter einzugrenzen. So ist es bspw. bei einer entsprechenden Parametrisierung von Dimensionsausprägungen der technischen Dimension denkbar, dass eine Sicht nur Services beinhaltet, die als Protokoll das Simple Object Access Protocol (SOAP) verwenden und eine Wiederverwendungsrate zwischen 10% und 20% besitzen. Bezüglich der Strukturdimensionen lässt sich die Frage, ob deren Parametrisierung notwendig oder sinnvoll ist, nicht ohne weiteres beantworten, da dies stark von den gewählten Dimensionen und Dimensionsausprägungen abhängt. Die Entscheidung, Strukturdimensionen zu parametrisieren, sollte daher unter Berücksichtigung einer konkreten SOA-Lösung und unternehmensspezifischen Anforderungen getroffen werden. Denkbar wäre bspw. die Parametrisierung von Dimensionsausprägungen der Dimension Abstraction in Form von Skalenwerten, mit denen der Detailgrad der einzelnen Abstraktionsschichten festgelegt wird. Somit könnte in einem Profil der Detailgrad jeder Abstraktionsschicht unabhängig voneinander konfiguriert werden. 6.4.1.3

Regelsystem zur Einschränkung der Kombinationsmöglichkeiten von Dimensionen und Dimensionsausprägungen

Um die Variationsmöglichkeiten bei der Profilkonfiguration nicht im Vorhinein schon einzugrenzen, wird das Dimensionssystem frei definiert und unterliegt somit keinen Einschränkungen und Regeln in Bezug auf Kombinationsmöglichkeiten von Dimensionen und Dimensionsausprägungen. Da aber nicht jede Kombination von Dimensionsausprägungen sinnvoll ist, bedarf es eines Regelsystems, mit dem die entsprechenden Einschränkungen zur Eingrenzung der Variationsmöglichkeiten definiert werden können. Bspw. macht es wenig Sinn, technische

Modell Generischer Sichten

175

oder fachliche Dimensionsausprägungen, die sich allein auf Merkmale von Services beziehen, zu selektieren, wenn mit der Strukturdimension Abstraction bereits eine Eingrenzung auf die Geschäftsprozessebene vorgenommen wurde. Für die Definition eines Regelwerks muss eine geeignete Regelsprache verwendet werden, die die Anforderung an das Regelsystem, sinnvolle bzw. gültige Kombinationen zu erstellen, erfüllt. Auf Basis der Regelsprache müssen daher Profilrestriktionen erstellt, vordefinierte Profile geladen und validiert sowie neue valide Profile erstellt werden können. Darüber hinaus ist es wichtig, dass das Regelwerk jederzeit verändert oder erweitert werden kann, da auch das der Profilkonfiguration zugrunde liegende Dimensionssystem Modifikationen erlaubt. Soweit die Anforderungen an die Regelsprache in Bezug auf ein konkretes Dimensionssystem erfüllt werden, besteht die Möglichkeit, das Regelwerk mithilfe bestehender Ansätze, wie z.B. der Object Constraint Language (OCL)30, RuleML31 oder Ontologiesprachen, zu beschreiben. Alternativ kann eine eigene proprietäre Sprache, bspw. auf Basis von XML-Schema, definiert werden (vgl. Kapitel 7.2). 6.4.1.4

Profiltypen

Profile können für verschiedene Zwecke eingesetzt werden. Insofern werden je nach Verwendungszweck unterschiedliche Profiltypen unterschieden. Kommunikationsprofil Kommunikationsprofile dienen der direkten Interaktion zwischen Stakeholdern. Es muss daher berücksichtigt werden, über welches Wissen und welche Erfahrungswerte die Interaktionsteilnehmer verfügen und welchen Disziplinen diese angehören (vgl. Kapitel 5.4). Insofern müssen sich die Interaktionsteilnehmer bei der Konfiguration eines Kommunikationsprofils aufeinander abstimmen, um Sichten erzeugen zu können, die für alle Beteiligten nachzuvollziehen sind. Analyseprofil Analyseprofile dienen der Beantwortung spezieller Fragestellungen, die von Experten unterschiedlicher Disziplinen im Rahmen von Analysen formuliert werden. Eine auf Basis eines Analyseprofils erzeugte Sicht kann bspw. wichtige Anhaltspunkte in Bezug auf Architekturentscheidungen liefern. Ein Analyseprofil kann im weiteren Sinn auch als spezielle Form des Kommunikationsprofils verstanden werden, sofern es im Rahmen einer Interaktion, bspw. bei der Diskussion von Analyseergebnissen, verwendet wird.

30 31

Siehe http://www.omg.org/technology/documents/modeling_spec_catalog.htm#OCL Siehe http://ruleml.org/

176

Generische Sichten

Schulungsprofil Schulungsprofile dienen der Darstellung von Aspekten, die in Bezug auf Schulungsmaßnahmen für konkrete SOA-Lösungen hohe Relevanz besitzen und somit zur Erzielung von Lerneffekten beitragen können. Dabei ist insbesondere ein Mix aus abstrakten Sichten und Detailsichten wichtig, um ein System aus unterschiedlichen Perspektiven verstehen zu können. Es muss jedoch beachtet werden, dass die Zusammenhänge durch die unterschiedlichen Abstraktions- und Detailstufen nicht verloren gehen. Für eine bessere Nachvollziehbarkeit von Zusammenhängen können bspw. vordefinierte Schulungsprofile mit einer festgelegten Reihenfolge verwendet werden. 6.4.2

Information

Der Bereich der Information umfasst Informationsmodelle, mit denen informationsbezogene Aspekte einer SOA-Landschaft abgebildet werden können. Da der Begriff des Informationsmodells in der Literatur unterschiedlich verwendet wird, werden zunächst einige Begriffsdefinitionen angeführt. Picot und Maier definieren Informationsmodelle wie folgt: „Informationsmodelle bilden die informationsbezogenen Aspekte des betrieblichen Geschehens ab. Sie stellen eine strukturierte Beschreibung von Informationen und Informationsbeziehungen dar. [...] Sie dienen der formalen Beschreibung betriebswirtschaftlicher Informationssysteme auf konzeptioneller Ebene.“ (Picot und Maier 1993) Becker und Schütte verstehen unter einem Informationsmodell „die immaterielle Repräsentation des betrieblichen Objektsystems aus Sicht der in diesem verarbeiteten Informationen für Zwecke des Informationssystem- und Organisationsgestalters.“ (Becker und Schütte 2004, S. 67) Nach Teubner bilden Informationsmodelle „nicht nur einzelne Informationssysteme ab, sondern das Unternehmen bzw. die Unternehmensorganisation und stellen damit einen Bezugsrahmen für die Beschreibung und organisatorische und softwaretechnische Integration der Informations- bzw. Anwendungssysteme dar.“ (Teubner 1999, S. 53) Die drei Definitionen legen einen starken Fokus auf das betriebliche System als Bezugsrahmen für ein Informationsmodell. Scheer hingegen rückt Informations- und Anwendungssysteme stärker in den Vordergrund. Ihm zufolge beschreibt ein Informationsmodell „die Konstrukte und deren Beziehungen, aus denen ein Informationssystem beschrieben werden soll, ein Repository speichert die nach diesen Konstrukten beschriebenen (Anwendungs)Informationssysteme.“ (Scheer 1997, S. 686) Das Informationsmodell liefert somit zum einen den Methodenrahmen zur Beschreibung von Anwendungssystemen, zum anderen stellt es das Datenmodell des Repositories dar (Scheer 1997, S. 693). Informationsmodelle werden mithilfe von Metamodellen beschrieben, die das Methodenwissen (Arbeitstechniken, Vorgehensweisen, Werkzeuge) zur Konstruktion von Modellsystemen enthalten. Metamodelle beschreiben zudem die notwendigen Konstrukte, Strukturen und syn-

Modell Generischer Sichten

177

taktischen Beziehungsregeln zur Modellbildung (Esser 2002, S. 50), in diesem Fall zur Bildung von Informationsmodellen. Auf Basis des Metamodells lassen sich somit die Konsistenz und Verhaltenstreue unterschiedlicher Informationsmodelle überprüfen. Die Erhebung von Informationsobjekten erfolgt durch die Betrachtung eines Ausschnitts der Realität und resultiert in einem Objektsystem, das in das Informationsmodell, d.h. das Modellsystem, überführt wird (vgl. (Esser 2002, S.49; Sinz 1996, S. 125)). Im Rahmen serviceorientierter Architekturen bilden sowohl betriebliche Systeme als auch Informationssysteme den Bezugsrahmen bei der Konstruktion von Informationsmodellen. Von daher wird ein Informationsmodell im Kontext Generischer Sichten als ein Modell verstanden, dass SOA-relevante Informationsobjekte (SOA-Elemente) sowie deren Eigenschaften und Beziehungen unter Berücksichtigung betrieblicher und informationstechnischer Aspekte abbildet und klassifiziert. Das Methodenwissen sowie die notwendigen Konstrukte, Strukturen und Beziehungsregeln zur Konstruktion von Informationsmodellen werden auch hier von entsprechenden Metamodellen beschrieben. Die Informationsobjekte sowie die Metadaten über Informationsobjekte werden unter Berücksichtigung des Informationsmodells in einem Repository gespeichert und verwaltet. Im Zusammenhang mit Generischen Sichten wird dem Repository eine aktive Rolle zugerechnet, was eine enge Verknüpfung der Repository-Objekte zu Artefakten, Building Blocks, Deliverables, produktiven Anwendungssystemen und weiteren Unternehmensressourcen voraussetzt. Somit können Elemente unterschiedlicher Entwicklungsphasen, Abstraktionsstufen, Disziplinen und Domänen über die Informationsobjekte im Repository miteinander integriert und auf Basis einer konsistenten Datenbasis verwaltet werden. Die Verwendung eines spezifischen Informationsmodells wird im Kontext des Generischen Sichtenmodells nicht vorgeschrieben. Demnach können unterschiedliche Informationsmodelle, die von Standardisierungsgremien, Repository-Herstellern oder einzelnen Unternehmen entwickelt werden, zum Einsatz kommen. Abbildung 56 zeigt ein Informationsmodell für das Management von Service-Lebenszyklus-Ressourcen (Belter und Ludwig 2009), das bei einer konkreten Umsetzung des Konzepts in das Modell Generischer Sichten einbezogen und adaptiert werden könnte. Weitere Informationsmodelle, Metamodelle oder Definitionen von Entitätstypen im Bereich des Service Computing und serviceorientierter Architekturen, an denen sich bei der Konstruktion spezifischer Informationsmodelle sowie bei der Identifikation von Informationsobjekten orientiert werden kann, werden bspw. in (Estefan et al. 2009; MacKenzie et al. 2006; Heutschi 2007; Everware-CBDI 2007) vorgeschlagen. Standardisierte Informationsmodelle, die keinen direkten Fokus auf serviceorientierte Architekturen richten, aber dennoch in diesem Kontext verwendet werden können, sind z.B. die IT Portfolio Management Facility (ITPMF)

178

Generische Sichten 32

der OMG (OMG 2004) und das Common Information Model (CIM) der Distributed Management Task Force (DMTF). responsible for

Organizational Unit 1

1

Service Provider provides

is part of

*

Resource

belong to

Lifecycle

has

*

Service *

*

IT Service

Profile

Service Description

has

uses

*

*

uses

* *

*

1 1

* *

defines behavior *

*

Infrastructure Component 1

is a

is a

Lifecycle Stage

is defined by

IT Service Process

is a

Constraint

is a

1

* has

has

is part of

Monitoring Data

* is in

*

KPIs

*

has

Business Service

* Service Stakeholder

has

*

Source Code Artefact

is a

Service Level Agreement *

+is part of

* is a

Deployment Specification has

*

Service Management Information

Abbildung 56: Service Management Information Model Quelle: (Belter und Ludwig 2009, S. 503)

Grundsätzlich ist es möglich, mehrere Informationsmodelle, die in verschiedenen Repositories abgebildet werden, zu verwenden. Dies ist bspw. dann der Fall, wenn kein übergeordnetes Informationsmodell verwendet wird, sondern eine Menge einzelner Informationsmodelle, die miteinander integriert sind. Eine Voraussetzung dafür ist jedoch, dass die Informationsmodelle über eine einheitliche Semantik und Syntaktik verfügen. Ist dies nicht der Fall, da diesen bspw. unterschiedliche Metamodelle oder Terminologien zugrunde liegen, so müssen ent-

32

Eine Übersicht der Common Information Model (CIM) Standards ist unter http://www.dmtf.org/standards/cim/ zu finden.

Modell Generischer Sichten

179

sprechende Transformationssprachen und -regeln zum Mapping bzw. zur Überführung der Informationsmodelle eingesetzt werden. Möglichkeiten der Transformation von Informationsmodellen werden bspw. in (Buckl 2005) diskutiert. 6.4.3

Kontext

Der Bereich „Kontext“ ist dafür verantwortlich, dass sich ein Dimensionssystem in Verbindung mit einem oder mehreren spezifischen Informationsmodellen anwenden lässt. Die Kernelemente des Bereichs „Kontext“ sind das Mapping von Profilen und den Informationsmodellen entsprechenden Daten und Metadaten sowie die daraus gewonnene Ergebnismenge, die als Kontext bezeichnet wird. 6.4.3.1

Dimension-Element-Matrix

Das Wissen darüber, welche Elemente und Beziehungen in Bezug auf einzelne Dimensionsausprägungen und respektive auf den durch Stakeholder-Concerns identifizierten Informationsbedarf relevant sind, wird auf Basis einer Dimension-Element-Matrix (siehe Tabelle 16) beschrieben und dokumentiert. Dies umfasst bspw. auch die Dokumentation von Relationen, die die Verbindung von Elementen zu Artefakten, Building Blocks, Deliverables oder den entsprechenden Instanzen auf Produktivsystemen beschreiben. Dadurch besteht die Möglichkeit, neben Daten und Metadaten, die in einem Repository gespeichert sind, zusätzliche Detaildaten jenseits der abstrakten Informationsmodelle in den Kontext mit einfließen zu lassen. Dabei ist jedoch weiterhin zu berücksichtigen, dass die Informationsmodelle immer die zentrale Schnittstelle für das Dimensionssystem und die damit festgelegten Profile bildet.

180

Generische Sichten

Requirements Development Test Deployment Operation Maintenance … Abstraction

Structural Dimension

Lifecycle

Design

Business Process Service Application …

Domain

Sales Finance Production Human Resources

…

… … Name Technical

Message Interchange Datatype Version Perfomance Security … Name Price

Functional

Non-structural Dimension

Protocol

Responsibility Rights Policy QoS Business Rule

…

… …

Tabelle 16: Dimension-Element-Matrix

…

Org. Unit

Component

Service

Orchestrated Service

Activity

Business Process

SOA Element

Modell M Generischerr Sichten

6.4.3.2 6

1811

Mappping und Konteextgenerierung

Das D Mapping deer Profile und Daten/Metadaten D n erfolgt auf Bassis von Abfragenn (Queries), diee unter u Berücksichhtigung des im Profilbereich festgelegten f Reggelsystems undd des in der Di-mension-Elemen m nt-Matrix dokum mentierten Wissens definiert bzzw. generiert weerden (siehe Ab-bildung b 57).

Abbildung A 57: Mapping von Profilen n und Daten/Metaadaten

Die D durch das R Regelsystem deefinierten Restriiktionen des Diimensionssystem ms spielen einee wichtige w Rolle, da d über diese siichergestellt wirrd, dass die Abffrage nur Wertdiimensionen vonn Elementen E berüccksichtigt, die den d Kriterien deer ausgewähltenn Strukturdimennsionen entspre-chen. c Das bedeuutet, dass Datenn und Metadateen, die den seleektierten Wertdiimensionen ent-sprechen, s in Beezug auf die Strrukturdimension nen und der daaraus resultierennden Menge ann Elementen E Gültiigkeit besitzen müssen. m Somit lässt l sich bspw. verhindern, dass eine Abfragee Laufzeit-Perform L mance-Indikatorren zur Verfügu ung stellt, falls die d Dimensionsaausprägung De-sign s der Strukturrdimension Lifeccycle selektiert wurde. w Die D Dimension-E Element-Matrixx hingegen stellt das notwendigee Wissen über die d Zuordnungenn von v Dimensionssausprägungen und u SOA-Elemeenten zur Verfüügung, die für die d Abfrage derr Instanzdaten undd -metadaten zw wingend erforderrlich sind. Bei B der Implemeentierung des Generischen G Sichtenkonzepts isst es daher notw wendig, die Ele-mente m und Bezieehungen dem Dimensionssystem m entsprechend zu kategorisiereen oder zu klas-sifizieren. s Zur K Kategorisierung oder Klassifikaation der Datenn und Metadatenn können unter--

182

Generische Sichten

schiedliche Konzepte, wie Annotationen, Taxonomien oder Ontologien eingesetzt werden. Welches Konzept Anwendung findet, ist in erster Linie davon abhängig, wie die Daten und Metadaten in einem Repository abgebildet und strukturiert sind. Werden zur Strukturierung der Daten und Metadaten bspw. auch Ontologien verwendet, so könnten diese erweitert und die Kategorisierung oder Klassifikation von Elementinstanzen auf Basis dieser Erweiterungen durchgeführt werden. Eine andere Möglichkeit der Umsetzung besteht darin, die Zuordnungen der DimensionElement-Matrix auf Basis eines Mapping-Schemas formal zu beschreiben, um somit die Daten und Metadaten bezüglich des Dimensionssystems unabhängig vom zugrunde liegenden Informationsmodell zu kategorisieren oder zu klassifizieren. Ein Nachteil dieser Möglichkeit ist jedoch, dass das Mapping-Schema in Bezug auf das Informationsmodell konsistent gehalten werden muss, falls die Informationsmodelle Änderungen unterliegen. Hinsichtlich des Mappings müssen bei der Anwendung des Generischen Sichtenkonzepts zwei weitere wichtige Aspekte berücksichtigt werden. Zum einen ist es – abhängig von den Profilkonfigurationen und der Größenordnung einer SOA – möglich, dass Abfragen lange Antwortzeiten erzeugen und große Datenmengen als Ergebnis zurückgeliefert werden. Zum anderen können bei bestimmten Abfragen spezielle Analysen erforderlich sein, mit denen weitere Detaildaten (Elemente, Beziehungen und Attribute), sofern diese nicht im Repository hinterlegt sind, aus Artefakten extrahiert werden. Von daher sollten geeignete Strategien und Mechanismen, wie z.B. der Einsatz von Abhängigkeitsanalysen, Parsern, CachingMechanismen oder Staging-Areas mit eigener Zieldatenbank, in die Überlegungen der Umsetzung mit einbezogen werden. Der durch das Mapping generierte Kontext umfasst alle für einen Stakeholder Concern relevanten Informationen. Der Kontext wird in Form eines oder mehrerer Graphen verwaltet. Die Elemente stellen dabei die Knoten des/der Graphen dar; die Beziehungen zwischen den Elementen bilden die Kanten. Darüber hinaus ist es möglich, Elemente und Beziehungen zu logischen Teilgraphen zusammenzufassen, um somit bestimmte Teilstrukturen des Kontexts, insbesondere in Hinblick auf die Darstellung, besser verwalten zu können. 6.4.4

Darstellung (Visualisierung)

Der Bereich „Darstellung“ ist dafür verantwortlich, den erzeugten Kontext zu visualisieren und dem Benutzer eine adäquate Repräsentation der darin enthaltenen Informationen zur Verfügung zu stellen. In Bezug auf die in Kapitel 2.4.4 vorgestellte Visualisierungspipeline übernimmt der Darstellungsbereich die Datenabbildung (Mapping) und die Bildgenerierung (Rendering). Die Datenaufbereitung hingegen erfolgt im zuvor beschriebenen Kontextbereich. Durch die Trennung des Darstellungsbereichs von den anderen Bereichen des Modells, und damit insbesondere durch die Trennung von Kontext und Kontextrepräsentation, schränkt sich

Modell Generischer Sichten

183

die Repräsentation nicht auf bestimmte Darstellungen ein, sondern fördert im Gegenteil die Nutzung unterschiedlicher Darstellungsformen. Wie im integrierten Referenzmodell für die Visualisierung (siehe Kapitel 2.4.4) beschrieben, können dem Nutzer somit Möglichkeiten zur Verfügung gestellt werden, die einzelnen Schritte der Visualisierungspipeline zu kontrollieren und direkten Einfluss auf die Visualisierung und deren Expressivität und Effektivität zu nehmen. Die Visualisierung eines Kontexts basiert auf dem Mapping und der Transformation semantischer Konstrukte zu visuellen Symbolen und Strukturen. Die Repräsentation eines Kontexts und respektive einer Sicht besteht dann aus graphischen Symbolen, die mithilfe von Layouts positioniert werden. Darüber hinaus stehen dem Betrachter unterschiedliche visuelle Konzepte zur Verfügung, mit denen die Darstellungsmöglichkeiten beeinflusst werden können. 6.4.4.1

Mapping und Transformation

Zur Darstellung von Kontextinformationen ist es notwendig, dass semantische Konstrukte, deren Definition typischerweise mithilfe von Metamodellen vorgenommen werden, durch geeignete graphische Symbole (1D-Graphikelemente (Linien), 2-D-Graphikelemente (Flächen), 3-D-Graphikelemente (Volumen), Textelemente (Label) und räumliche Beziehungen) und Anordnungen (hierarchisch, organisch, orthogonal, kreisförmig, verschachtelt, etc.) symbolisiert bzw. repräsentiert werden. Abbildung 58 veranschaulicht die Beziehungen zwischen syntaktischen und semantischen Elementen auf Typ- und Instanzebene, die bei der Visualisierung von Informationen beachtet werden müssen. Sie basiert auf einer Abbildung von Moody (Moody 2009, S. 757), wobei aber auf Seiten der Syntax die beiden Quadranten um den Aspekt visueller Layouts erweitert wurden. Eine Menge graphischer Symbole (visuelles Vokabular), ein Satz an Kompositionsregeln (visuelle Grammatik) und die Definition der Bedeutung jedes einzelnen Symbols (visuelle Semantik) bilden zusammen eine visuelle Notation (Moody 2009, S. 757). Darüber hinaus besteht ein visuelles Layout aus einer Menge verschiedener graphischer Strukturen, mit denen die semantischen Konstrukte visuell strukturiert werden können. Auf Basis der visuellen Notation und visueller Layouts werden auf der Instanzebene Diagramme (visuelle Sätze) erstellt. Diagramme setzen sich aus Symbolinstanzen und Strukturinstanzen zusammen, die Instanzen semantischer Konstrukte graphisch symbolisieren und strukturieren. Instanzen semantischer Konstrukte sind Teil eines Modells, welches wiederum eine Instanz des Metamodells bildet. Die Erweiterung um den Aspekt visueller Layouts spielt im Rahmen des Modells Generischer Sichten eine wichtige Rolle. Durch das Dimensionssystem werden logische Strukturdimensionen vorgegeben, die Einfluss auf die semantische inhaltliche Struktur der Elemente und Beziehungen eines erzeugten Kontexts besitzen.

184 1

G Generische Sichtenn

Abbildung A 58: Bezziehungen syntaktiischer und semanttischer Elemente auf a Typ- und Instaanzebene Quelle: Q In Anlehnunng an (Moody 20099, S. 757)

Diesen D Struktureen wird über die d Auswahl besstimmter Layouut-Algorithmen und der darauss resultierenden r A Anordnungen voon Elementen (g graphische Strukktur) auch eine visuelle v Seman-tik zugeordnet. So S können bspw w. die Ordnung der Abstraktionnsschichten undd die Zugehörig-keit k der Elementte zu bestimmteen Abstraktionssschichten durch entsprechende visuelle Anord-nungen n repräsenntiert werden. Für F die graphiscche Symbolisierrung und Struktu urierung ist es wichtig, w die Beddeutung graphi-scher s Symbole und u Strukturen durch d ein Mapp ping zu den sem mantischen Konsstrukten zu defi-nieren. n Somit lassen sich semanntische Konstrukkte symbolisch kodieren und graphische g Sym-bole b wieder ihreer Bedeutung entsprechend dekoodieren. Bei dem m Mapping solltte zwischen denn semantischen s Koonstrukten und den d graphischen n Symbolen einee 1-zu-1-Übereinnstimmung vor-liegen, da sonst eine oder mehrere der folgendeen Anomalien auftreten a könnenn (Moody 2009,, S. S 762): x

Symbolreedundanz entsteeht, wenn meh hrere graphischee Symbole verw wendet werdenn können, uum das gleiche semantische s Koonstrukt zu reprääsentieren.

x

Symbolübberladung entsteht, wenn zwei unterschiedlichhe Konstrukte mit m dem gleichenn graphischhen Symbol reprräsentiert werdeen können.

Modell Generischer Sichten

x

185

Symbolüberdeckung entsteht, wenn graphische Symbole mit keinem semantischen Konstrukt übereinstimmen.

x

Symbolunterdeckung entsteht, wenn semantische Konstrukte existieren, die von keinem graphischen Symbol repräsentiert werden.

Auch wenn Moody sich in seinen Ausführungen nur auf die Anforderungen visueller Notationen bezieht, kann gleiches in Bezug auf graphische Strukturen angenommen werden, so dass auch hier eine 1-zu-1-Übereinstimmung mit semantischen Konstrukten existieren muss, um das Entstehen von Anomalien vermeiden zu können. Das Modell der Generischen Sicht erlaubt es, sowohl auf Seite der Semantik, als auch auf Seite der Syntaktik auf bestehende Sprachen, wie z.B. die Unified Modeling Language, zurückzugreifen. So könnte sich seitens der Semantik an unterschiedlichen Modelltypen der UML orientiert werden, um geeignete semantische Konstrukte in Bezug auf einen Kontext auszuwählen. Auch seitens der visuellen Syntax könnte auf die bestehenden Notationen der UML zurückgegriffen und diese im Rahmen der Visualisierung eingesetzt werden. Es ist jedoch zu berücksichtigen, dass das Generische Sichtenkonzept primär die automatisierte Erzeugung von Sichten und nicht deren manuelle Modellierung adressiert. Zwar wird der Aspekt der Modellierung in Verbindung mit dem Generischen Sichtenkonzept nicht ausgeschlossen, jedoch wurden diesbezüglich noch keine Forschungen unternommen. Insofern sollte bei einer konkreten Umsetzung des Generischen Sichtenkonzepts zum einen geprüft werden, ob und inwieweit sich bestehende semantische Konstrukte, insbesondere im Hinblick auf die verschiedenen Stakeholder-Concerns und die generierten Kontexte, eignen. Zum anderen sollte analysiert werden, ob und inwieweit bestehende Notationen zur Generierung von visuellen Darstellungen verwendet werden können, ob diese möglicherweise erweitert werden müssen oder ob eine Entwicklung zusätzlicher Notationen erforderlich ist (z.B. bei Verwendung dreidimensionaler Darstellungen). Die Definition und Auswahl semantischer Konstrukte ist im Zusammenhang mit dem Generischen Sichtenkonzept von mehreren Faktoren abhängig. Neben den Profilkonfigurationen und dem zugrunde liegenden Dimensionssystem, den durch die Informationsmodelle beschriebenen SOA-Elementen und Abhängigkeiten sowie den durch das Mapping generierten Kontexten müssen auch das grundlegende Verständnis serviceorientierter Architekturen und die damit verbundenen technischen und fachlichen Aspekte berücksichtigt werden. Für den Entwurf kognitiv effektiver visueller Notationen definiert und beschreibt Moody (Moody 2009) einen Satz von Prinzipien, die auf Basis einer Synthese von theoretischen Erkenntnissen und empirischen Befunden über die kognitive Effektivität visueller Repräsentationen entwickelt wurden. Das Generische Sichtenkonzept kann sich an diesen Prinzipien ori-

186

Generische Sichten

entieren, sofern für die Generierung von Darstellungen neue Notationen entworfen oder bestehende erweitert werden müssen. Zu den Prinzipien zählen (Moody 2009, S. 761ff.): x

Principle of Semiotic Clarity: Es sollte eine 1-zu-1-Übereinstimmung zwischen semantischen Konstrukten und graphischen Symbolen bestehen.

x

Principle of Perceptual Discriminability: Die verschiedenen Symbole sollten klar voneinander zu unterscheiden sein.

x

Principle of Semantic Transparency: Verwendung visueller Repräsentationen, deren Aussehen auf ihre Bedeutung schließen lassen.

x

Principle of Complexity Management: Berücksichtigung expliziter Mechanismen für den Umgang mit Komplexität.

x

Principle of Cognitive Integration: Berücksichtigung expliziter Mechanismen zur Unterstützung der Integration von Informationen unterschiedlicher Diagramme.

x

Principle of Visual Expressiveness: Verwendung des vollen Angebots und der vollen Kapazität an visuellen Variablen.

x

Principle of Dual Coding: Verwendung von Text zur Ergänzung von Graphiken.

x

Principle of Graphic Economy: Die Anzahl der unterschiedlichen graphischen Symbole sollte kognitiv verarbeitet werden können.

x

Principle of Cognitive Fit: Einsatz unterschiedlicher visueller Dialekte für unterschiedliche Aufgaben und Zielgruppen.

Bei der Verwendung der Prinzipien gilt es zu beachten, dass sich einige untereinander beeinflussen (Moody 2009, S. 773f.). Bei Prinzipien, die sich negativ beeinflussen, müssen daher Kompromisse gemacht werden, wohingegen Prinzipien, die sich gegenseitig unterstützen, die Nutzung von Synergien erlauben. Darüber hinaus wird bei der Definition der Prinzipien vorwiegend der Einsatz zweidimensionaler Darstellungen bzw. Diagramme untersucht und diskutiert, so dass zu prüfen bleibt, inwieweit die Prinzipien auch bei dreidimensionalen Darstellungen mit umfangreicheren Interaktionsmöglichkeiten angewandt werden können. Da sich die Aussagen der Prinzipien grundsätzlich aber auch auf dreidimensionale Darstellungen übertragen lassen, wird davon ausgegangen, dass die Prinzipien bei dem Entwurf visueller Notationen für dreidimensionale Darstellungen ebenfalls Gültigkeit besitzen. Die Visualisierung eines generierten Kontexts wird auf Basis von Transformationen vorgenommen, die mithilfe von Templates definiert werden. Dazu bedarf es einer Menge von Transformationsvorschriften, die unter Berücksichtigung der visuellen Syntax, semantischer Inhalte und dem Mapping von visuellen Symbolen und Strukturen zu semantischen Konstrukten festgelegt werden. Die Templates und die darin enthaltenen Transformationsvorschriften können mithilfe von Stylesheet-Sprachen, ähnlich wie in Bereichen der Web-Entwicklung,

Modell Generischer Sichten

187

z.B. auf Basis von Cascading Style Sheets (CSS), oder bei der Transformation von Dokumenten, z.B. auf Basis von XSL Transformations (XSLT), beschrieben werden. Der Vorteil in der Verwendung von Templates liegt darin, dass für die verschiedenen Stakeholder unterschiedliche Transformationen erstellt werden können. Somit können diesen nicht nur Concern-spezifische Kontexte, sondern auch zielgruppenorientierte Darstellungen zur Verfügung gestellt werden. Die abschließende Bildgenerierung wird von einer Render-Engine vorgenommen und auf einem entsprechenden Anzeigegerät ausgegeben. 6.4.4.2

Visuelle Konzepte

Im Rahmen dieser Forschungen wurde von dem Autor der vorliegenden Arbeit eine Diplomarbeit (Kahl 2007) vergeben und betreut, mit der Aufgabenstellung und dem Ziel, auf Basis bestehender Ansätze der Informations- und Softwarevisualisierung (siehe Kapitel 2.4) die Möglichkeiten der Visualisierung serviceorientierter Architekturen zu erörtern und zu analysieren. Bei der Erarbeitung der Diplomarbeit wurden von Kahl (Kahl 2007, S. 88ff.) u.a. verschiedene visuelle Konzepte identifiziert und beschrieben, die bei der Visualisierung serviceorientierter Architekturen verwendet werden können. Bereits gesammelte Erkenntnisse in Bezug auf die Entwicklung des Generischen Sichtenkonzepts lieferten die entsprechenden Vorgaben für die Untersuchung von Visualisierungsansätzen, so dass sich die visuellen Konzepte in den übergeordneten Rahmen des Generischen Sichtenkonzepts und speziell in den Bereich „Darstellung“ des Modells der Generischen Sicht integrieren lassen. Bspw. orientiert sich Kahl bei der Ausgestaltung der einzelnen visuellen Konzepte ebenfalls an den von Erl beschriebenen Abstraktionsschichten (siehe Kapitel 3.2.3). Zudem berücksichtigt er Anforderungen, die die Aspekte Dynamik, Multidimensionalität, Skalierbarkeit und Ganzheitlichkeit umfassen. Die visuellen Konzepte bauen zum Teil auf bewährten Konzepten der Softwarevisualisierung auf. Sie wurden auf einem abstrakten Niveau definiert, d.h. es werden weder Vorgaben hinsichtlich der Darstellungsform (2-D oder 3-D) festgelegt, noch werden explizite Lösungen für die Ebene der Implementierung definiert. Im Folgenden werden die von Kahl beschriebenen visuellen Konzepte vorgestellt und erläutert. Auf Basis dieser Konzepte können einem Stakeholder hinsichtlich des erzeugten Kontexts einer Generischen Sicht unterschiedliche Filtertechniken und Interaktionsmöglichkeiten auf der Darstellungsebene zur Verfügung gestellt werden. Multiple Subsichten Mithilfe des Konzepts simultaner multipler Subsichten (Kahl 2007, S. 89ff.) ist es möglich, eine Generische Sicht in mehrere Subsichten (Teilsichten) zu unterteilen, die sich gleichzeitig darstellen lassen. Durch die simultane Darstellung können mehrere Subsichten mit variablem

188 1

G Generische Sichtenn

Detailgrad D abhänngig von den Präferenzen P und Bedürfnissen der d Stakeholder betrachtet wer-den. d Somit bestteht bspw. die Möglichkeit, M beestimmte Ausscchnitte eines Koontexts in einerr Subschicht S darzuustellen, ohne dabei den übergeeordneten Konteext („Big Picturee“) zu verlieren,, da d dieser in eineer weiteren Subbsicht in Form einer Überblickksdarstellung beetrachtet werdenn kann k (siehe Abbildung 59).

Abbildung A 59: Kon nzept multipler Su ubsichten Quelle: Q (Kahl 2007,, S. 90)

Multiple M Sichtenn sind aufgrundd des zugrunde liegenden gemeeinsamen Konteexts miteinanderr verknüpft. v Die Verknüpfung V kaann zum einen in Form einer direkten d Assoziation vorliegen,, d.h. d es stehen unnterschiedliche Perspektiven au uf die gleichen visuellen Elemeente und Bezie-hungen h zur Verffügung. Zum annderen ist es mög glich, dass die Subsichten S indirrekt miteinanderr verknüpft v sind, also jeweils unnterschiedliche visuelle v Elemennte und Beziehuungen betrachtett werden w können. In beiden Fälleen besteht die Möglichkeit, M unnterschiedliche DarstellungsforD men m für die Subbsichten zu verw wenden, so dass bspw. Detailiinformationen zweidimensional z l als a Diagramm unnd ein Überblick des Kontexts dreidimensionaal und perspektivvisch dargestelltt werden w könnten.. Informationshier I rarchie Das D Konzept derr Informationshierarchie (Kahl 2007, S. 93ff.) unterstützt die Darstellung D vonn und u die Interakttion mit Informaationen, die auff unterschiedlichhen Ebenen hieerarchisiert sind.. Kahl K unterscheiddet drei verschiiedene Hierarch hieebenen: sichttbare Informatioonen (Ebene 1),, Kontextinformat K tionen (Ebene 2)) und externe In nformationen (siehe Abbildung 60). Während W die Infformationen derr ersten Ebene für f den Betrachtter direkt sichtbbar sind, werdenn Informationen dder zweiten Ebeene nur durch spezielle s Interakktionen (z.B. Maus-Ereignisse) M ) angezeigt. a Dies gilt auch für diie dritte Ebene. Im Gegensatz zur z zweiten Ebeene, bei der diee Informationen als Teil des erzeeugten Kontextss direkt verfügbbar sind, müssenn Informationenn der d dritten Ebene erst abgerufenn werden. Es han ndelt sich demnnach um externee Informationen,, die d keinen Bestaandteil der Darsstellung einer Generischen G Sichht bilden, sondeern lediglich mitt dieser d verknüpftt sind. Informattionen der dritteen Ebene sind bspw. b Dokumennte, die mit dem m aktuellen a Kontexxt in Beziehungg stehen und au us der Sicht heraaus zusätzlich geöffnet g werdenn können. k

Modell M Generischerr Sichten

1899

Abbildung A 60: Kon nzept der Informaationshierarchie Quelle: Q (Kahl 2007,, S. 94)

Information I on D Demand Das D Konzept dees Information on o Demand (Kaahl 2007, S. 96fff.) erlaubt es, Stakeholder S hin-sichtlich s einer G Generischen Sichht jederzeit mit zusätzlichen Innformationen verrsorgen zu kön-nen n (siehe Abbilldung 61).

Abbildung A 61: Infoormation on Demaand am Beispiel eiines Services Quelle: Q (Kahl 2007,, S. 97)

Dabei D ist es gruundsätzlich egal,, woher die Datten kommen unnd ob diese direkt oder indirektt verfügbar v sind. D Das Konzept istt eng mit den zu uvor genannten Konzepten derr multiplen Sub-sichten s und der Informationshieerarchie verbundden. Einerseits können k auf Basis des Konzeptss

190 1

G Generische Sichtenn

neue n Subsichtenn generiert werdden, andererseitts erlaubt es dass Eintauchen inn tiefere Hierar-chieebenen c eineer Informationshhierarchie. Wo diese Daten abbgerufen werdenn und ob diesee direkt d oder indirrekt zur Verfüguung stehen müsssen, wird aber dann d wieder durrch das Konzeptt der d multiplen Suubsichten oder der d Informationsh hierarchie vorgeegeben. Filterung F Durch D die Generrierung des Konntexts werden diie allgemein verrfügbaren Datenn bereits auf einn adäquates a Maß beschränkt. Der generierte Ko ontext kann jedooch immer nocch große Daten-mengen m enthalteen, wenn sich ein e Stakeholderr in Bezug auf bestimmte Asppekte bspw. erstt nach n der Generiierung des Konttexts beschränken möchte. Die daraus resultieerenden Darstel-lu ungen können eeine hohe visuellle Komplexität besitzen und zuu einer Informattionsüberladungg beim b Betrachter führen.

Abbildung A 62: Kon nzept der Filterun ng Quelle: Q (Kahl 2007,, S. 99)

Das D Konzept derr Filterung (Kahhl 2007, S. 98fff.) dient als zusäätzliches Mittel der d Abstraktion,, mit m dessen Hilffe die Menge der d dargestelltenn Informationenn in einer Sicht visuell einge-schränkt s werdenn können. Das bedeutet, b dass au usschließlich Ellemente und Bezziehungen einerr Sicht S visualisierrt werden, die den d im Filter geewählten Filterkkriterien entsprechen. Somit er-laubt das Konzeept der Filterungg einem Betrach hter, bestimmte Informationen einer e Sicht tem-porär p auszublendden und andere damit stärker in n den Fokus zu rüücken (siehe Abbbildung 62). Entgegen E dem K Konzept der Infformationshierarrchie, welches eine e bedarfsorientierte Erweite-rung r von Inform mationen unterstüützt, dient das Konzept K der Filtterung einer beddarfsorientiertenn Reduktion R von Innformationen.

Modell M Generischerr Sichten

1911

Aggregation A Mithilfe M des Konnzepts der Aggrregation (Kahl 2007, 2 S. 100ff.) lässt sich eine bestimmte b Men-ge g von Informattionen in einem m einzelnen visu uellen Element zusammenfassen z n und somit diee Komplexität K der Darstellung durrch die Reduktio on von Elementen reduzieren (ssiehe Abbildungg 63). 6 Die zur Agggregation vorgesehenen Inform mationen könneen dabei von eiinem Betrachterr manuell m oder durrch den Einsatz von Aggregatio onskriterien autoomatisch ausgew wählt werden.

Abbildung A 63: Kon nzept der Aggregaation Quelle: Q (Kahl 2007,, S. 101)

Neben N der Reduuktion visueller Komplexität träägt das Konzeptt durch die syntaaktische Aggre-gation g auf visuelller Ebene zudeem zu einem bessseren Verständdnis semantisch aggregierter In-halte h bei. So kannn die Aggregattion bspw. zur visuellen v Grupppierung von Elementen in einerr Sicht S verwendet werden. Kontext K und Dettail Das D Konzept Koontext und Detaiil (Kahl 2007, S. S 102ff.) untersstützt die Betrachtung bestimm-ter Details, ohnee dabei den Bezuug zu ihrem Kon ntext zu verliereen. Es wird also im Rahmen derr Betrachtung B vonn Detailinformaationen auch deeren übergeordnneter Kontext abgebildet. a Diess ermöglicht e einem m Betrachter, eiinzelne Elementte besser in denn Gesamtzusamm menhang einzu-ordnen. o Bei der Anwendung dees Konzepts unnterscheidet Kahhl zwischen einner internen undd externen e Ebene, was insbesondeere in Kombinattion mit dem Koonzept multiplerr Subsichten einn wichtiges w Untersscheidungsmerkkmal darstellt. Die D interne Ebenne bezieht sich auf die sichtinterne Darstellung, d.h. der Konttext wird inner-halb h einer Sicht oder Subsicht zusammen z mit den d Detailinform mationen abgebildet, wobei diee fokussierten f Dettails eindeutig hervorgehoben h werden w müssen (siehe ( Abbildunng 64). Zur Her-vorhebung v lasseen sich graphiscche Kodierungeen der Informatiionen, wie z.B. Variationen inn

192 1

G Generische Sichtenn

Farbe, F Form, Grröße, Helligkeit, Ausrichtung unnd Textur, sowie zusätzliche grraphische Effek-te, wie z.B. Anim mationen, verweenden.

Abbildung A 64: Kon nzept des Kontextts und Detail auf siichtinterner Eben ne Quelle: Q (Kahl 2007,, S. 103)

Die D externe Ebeene bezieht sich,, gemäß dem Konzept K der multtiplen Subsichteen, auf simultann dargestellte d Subssichten, die eineen unterschiedlicchen Abstraktioonsgrad besitzenn können. Einem m Betrachter B wird demnach ein deetaillierter Aussschnitt eines Koontexts in einer Subsicht darge-stellt, s während ggleichzeitig der übergeordnete ü K Kontext als Orieentierungshilfe in i einer anderenn Subsicht S angezeiigt wird. 6.5 6

3-D-Darrstellungen Gen nerischer Sichten

Konzeptionell K ab abstrahiert das Generische G Sich htenmodell von einer konkreteen Darstellungs-form, f so dass beei einer Umsetzuung des Konzeptts sowohl 2-D- als auch 3-D-Daarstellungen zurr Visualisierung V kkontextspezifischher Sichten verw wendet werden können. k In Kapiitel 6.4.4.1 wur-de d bereits angespprochen, dass im m Rahmen der Visualisierung V auuf bestehende zw weidimensiona-le Notationen, w wie z.B. UML, zurückgegriffen z n werden kann. Im Folgenden wird w jedoch derr Einsatz E von 3-D-Darstellungen, -Techniken undd -Technologienn im Kontext serrviceorientierterr Architekturen A diiskutiert. Unter U Berücksicchtigung der zuvvor beschriebennen SOA-Konzeepte und -Eigennschaften (siehee Kapitel K 3), der Vor- und Nachhteile dreidimen nsionaler Darsteellungsformen im i Rahmen derr Softwarevisualis S sierung (siehe Kapitel K 2.4.6) un nd des Generischhen Sichtenmodells wird in die-sem s Kapitel einee Konzeption zuur dreidimensionnalen Visualisieerung serviceoriientierter Archi-tekturen vorgesteellt. Der Fokus der Konzeption liegt weniger auf a einer syntakttischen Untersu-chung c in Bezug auf dreidimenssionale Notationnen, sondern viielmehr auf der generellen An-wendbarkeit w dreiidimensionaler Darstellungen D im m Kontext serviiceorientierter Architekturen. A Inn diesem d Zusamm menhang muss nooch einmal beto ont werden, dasss die dreidimensionale Darstel--

3-D-Darstellungen Generischer Sichten

193

lung bewährte zweidimensionale Ansätze keinesfalls ersetzen soll, sondern vielmehr eine alternative Darstellungsform zur Verfügung stellt, mit der Aspekte, bei denen 2-DDarstellungen Schwächen aufweisen, leichter „zugänglich“ gemacht werden können. Wie in Kapitel 3.2 verdeutlicht, müssen bei der Planung, dem Entwurf und dem Betrieb einer serviceorientierten Architektur unterschiedliche Aspekte und Dimensionen berücksichtigt werden. Dabei weisen die Ebenen und Bestandteile einer SOA zahlreiche Abhängigkeiten auf. Auf der einen Seite existieren Abhängigkeiten zwischen den Elementen innerhalb einer Abstraktionsschicht. Bspw. bestehen Prozesse aus mehreren Aktivitäten, die voneinander abhängig sind. Des Weiteren können sich Prozesse aus verschiedenen Sub-Prozessen zusammensetzen. Auf der anderen Seite gibt es zahlreiche schichtübergreifende Abhängigkeiten, die durch den Prozess der Abstrahierung und den daraus resultierenden Abstraktionsschichten sowie dem SOA-typischen Technologiemix entstehen. Um sowohl schichtinterne als auch schichtübergreifende Abhängigkeiten darstellen und visualisieren zu können, wurde in Anlehnung an Abbildung 23 eine dreidimensionale Repräsentation der SOA-Schichten erstellt. In Abbildung 65 erstrecken sich drei Schichten entlang der XZ-Achsen. Die höchste Ebene in der Abbildung enthält eine Menge von Geschäftsprozessen. Auf der darunter liegenden Ebene erfolgt die Abbildung von Services. Einzelne (atomare) und zusammengesetzte (orchestrierte) Services stellen Funktionalitäten bereit, welche von darüber liegenden Aktivitäten genutzt werden. Die Implementierung der von den Services bereitgestellten Funktionalitäten wird durch Komponenten bzw. Module auf der untersten Ebene realisiert, die wiederum verschiedene Abhängigkeiten aufweisen können. Der Vorteil der dreidimensionalen Repräsentation besteht darin, dass sowohl verschiedene Abstraktionsschichten als auch die damit verbundenen schichtinternen und die schichtübergreifenden Abhängigkeiten zusammenhängend (sowohl entlang der XZ- als auch entlang der XY-Achsen) dargestellt werden können. Eine entsprechende zweidimensionale Darstellung würde entweder zahlreiche Verdeckungen von Verbindungslinien bei der Darstellung von Abhängigkeiten aufweisen oder in verschiedenen Diagrammen resultieren, die aufgrund von Platzmangel nicht gleichzeitig visuell dargestellt werden können. Zwar werden durch das Verlinken von Elementen und Diagrammen Konzepte wie drill-across oder drill-down unterstützt, so dass Zusammenhänge besser nachvollzogen werden können. Der Gesamtkontext geht jedoch, insbesondere bei einer steigenden Anzahl von Informationseinheiten, schnell verloren (vgl. Kapitel 2.4.6).

194 1

G Generische Sichtenn

Abbildung A 65: 3-D D-Darstellung meh hrerer SOA-Schich hten

Im Folgenden w werden anhand eiines visuellen Entwurfs E die Mööglichkeiten eineer dreidimensio-nalen n Darstellunng näher diskutiert. Bei dem Enntwurf wurde deer Fokus auf diee Struktur einess abstrakten a Beisppielprozesses unnd auf die Bezieehungen zwischeen den Elementten (Aktivitäten,, Services S und Koomponenten) gerrichtet. Das ursp prüngliche Modeell des Beispielpprozesses wurdee auf a Basis von W WSBPEL (OASIIS 2007) erstelllt. Die Schnittsttellen der Services wurden mitt WSDL W (W3C 20001) beschriebeen, die Komponnenten mithilfe objektorientierte o er Technologienn im mplementiert. Die D Darstellung der Elemente ist in der vorlieg genden Form duurch die Verwenndung einfacherr geometrischer g P Primitive noch sehr s abstrakt. Soo werden bspw. alle Aktivitäteen mit den glei-chen c geometriscchen Formen abggebildet. Um deer gesamten Darrstellung eine seemantisch höhe-re r Aussagekraft zu verleihen, empfiehlt e es sichh, unter Berückksichtigung der in i Kapitel 2.4.55 vorgestellten v vissuellen Variableen und den in Kapitel K 6.4.4.1 angeführten a Prinnzipien eine ge-eignete e 3-D-Nottation zu entwickkeln. Somit würrde sich jedem Elementtyp E einee eigene visuellee

3-D-Darstellungen 3 G Generischer Sichten

1955

Repräsentationsf R form zuordnen lassen. l Auch auuf die Darstellunng von Detailinfformationen derr einzelnen e Elemeente wurde in deem Entwurf zunäächst verzichtet.. Der D Entwurf wuurde mithilfe einnes 3-D-Modelllierungswerkzeuugs erstellt. Abbbildung 66 zeigtt ein e Rendering, das einen Proozess, seine Ak ktivitäten und PartnerLinks (vvgl. WSBPEL-Spezifikation S (O OASIS 2007)), Dienste, D Schnittsstellen und Binddings (vgl. WSD DL-Spezifikationn (W3C 2001)) sow wie die Komponnenten der Servicelogik darstelllt. Die D Aktivitäten des Prozesses werden w in Abbildung 66 durchh abgerundete bllaue Boxen undd die d darüber lieggenden Nachrichhtensymbole reepräsentiert. Fürr die Darstellunng von Partner-Links L und Schniittstellen werdenn einfache Kugeeln verwendet, die d unterhalb des Prozesses undd dessen d Aktivitäteen angeordnet sind. Um die Zuo ordnung zwischhen PartnerLink und Schnittstel-le stärker zum A Ausdruck zu brinngen, sind die Kugelpaare K jeweeils von einer trransparenten ge-ometrischen o Form umschlossen..

Abbildung A 66: 3-D D-Entwurf eines Beeispielprozesses, der d Services und Komponenten K

Unterhalb U der PaartnerLinks undd den Schnittstelllen liegen die Dienste, D dargesteellt durch trans-parente p Sphären. Innerhalb der Sphären S befindeen sich die Diennstoperationen, die d von den Ak-tivitäten des Proozesses aufgeruffen werden. Untter den Dienstenn werden die Bindings, welchee

196

Generische Sichten

die Zuordnung zwischen den Diensten und deren Implementierung beschreiben, wiederum durch Kugeln repräsentiert. Komponenten werden durch transparente gelbe Boxen abgebildet. Sie befinden sich unterhalb der Bindings und werden von Modulen umschlossen, wodurch die jeweilige Modulzugehörigkeit verdeutlicht wird. Die Verschachtelung mehrerer geometrischer Formen, wie es z.B. bei den Komponenten der Fall ist, wird mithilfe unterschiedlicher Transparenzstufen umgesetzt. Die Verbindungslinien zeigen die Abhängigkeiten zwischen den Elementen. Die Pfeilsymbole an den Linien geben den Nachrichtenfluss wieder. Der Entwurf macht deutlich, dass die gewählte dreidimensionale Darstellungsform die Zielsetzung erfüllt, sowohl schichtinterne als auch schichtübergreifende Abhängigkeiten visuell abzubilden. Darüber hinaus sind zahlreiche Erweiterungsmöglichkeiten des Entwurfs denkbar. So könnten bspw. die verwendeten Kommunikationsprotokolle mit in die Darstellung einbezogen werden. Auch ist vorstellbar, neben den statischen Informationen auch dynamische Aspekte zu berücksichtigen. Die Visualisierung könnte z.B. für die Simulation des Nachrichtenflusses verwendet werden, um das Laufzeitverhalten des Systems zu überprüfen. Aber auch fachliche Informationen, wie z.B. Qualitätsmerkmale von Diensten, könnten in die Darstellung einbezogen werden. 3-D-Modellierungswerkzeuge stellen verschiedene Navigations- und Interaktionshilfen zur Verfügung. Dazu gehören unterschiedliche Kamerasysteme, die bspw. grundlegende Pan& Zoom-Techniken sowie unterschiedliche Rotationsmöglichkeiten zur Veränderung der Perspektive auf ein Modell ermöglichen. Ein Modell kann zudem in mehreren Viewports (vgl. das Konzept der multiplen Sichten in Kapitel 6.4.4.2) aus unterschiedlichen Perspektiven gleichzeitig betrachtet werden. In Abbildung 67 ist ein weiteres Rendering dargestellt, bei der die Perspektive (visuell) durch einen Zoom und eine Rotation geändert wurde. Insbesondere die Verwendung mehrerer Viewports erweist sich als hilfreich. Bspw. kann ein Viewport dafür verwendet werden, das entworfene Modell von oben zu betrachten, so dass, wie in der zweidimensionalen Darstellung der Entwicklungsumgebung, nur der Prozess und dessen Aktivitäten zu sehen sind. Die darunter liegenden Elemente können durch Selektion und Filterung (vgl. Kapitel 6.4.4.2) ausgeblendet werden. In einem zweiten Viewport sind wie in Abbildung 66 alle Elemente des Modells weiterhin sichtbar, um zu gewährleisten, dass der Gesamtkontext für den Betrachter erhalten bleibt. Da eine serviceorientierte Architektur in der Regel zahlreiche Prozesse beinhaltet, wurde der Entwurf um einen weiteren Prozess ergänzt. Abbildung 68 zeigt neben dem bereits bekannten Prozess (im Vordergrund) einen weiteren Beispielprozess sowie die damit verbundenen Services und Komponenten.

3-D-Darstellungen 3 G Generischer Sichten

1977

Abbildung A 67: Navvigation im 3-D-En ntwurf des Beispieelprozesses, der Seervices und Komp ponenten

Durch D die gleichhzeitige Darstellung mehrerer Prozesse P ist es bspw. b möglich, ganze Prozess-landschaften zu visualisieren. Die D Erweiterung g der Darstellunng um den zweiiten Prozess hatt jedoch zur Folgee, dass abhängigg von der Persppektive eines Beetrachters visuellle Überdeckun-gen g entstehen, ddie Wahrnehmunngsprobleme veerursachen könnnen. Aus diesem m Grund werdenn Nebeleffekte N verrwendet, mit deren Hilfe Teile des Modells vissuell hervorgehooben und in un-terschiedliche N Nebelcluster einggeteilt werden können. k Als Neebelcluster wird ein bestimmterr Ausschnitt A von Informationen I b bezeichnet, der durch d den Einsattz von Nebeleffe fekten von ande-ren r Informationeen visuell abgeggrenzt ist. In Abbildung 688 werden die drrei Ebenen eineer SOA durch den d Einsatz horiizontaler Nebel-schichten s visuelll voneinander abgegrenzt. a Es entstehen e somitt drei horizontalle Nebelcluster.. Der D Vorteil derr Verwendung von Nebeleffek kten liegt darinn, dass Überdecckungsproblemee vermindert v werdden können, da die d Intensität deer Elemente, diee außerhalb einees Nebelclusterss liegen, stark reduuziert wird. Diee Elemente bleib ben jedoch bis zu z einer bestimm mten räumlichenn Tiefe T für den Beetrachter sichtbaar. Die Sichtbarkkeit kann dabei zum einen durchh die Stärke derr Nebeleffekte N und zum anderen durch die Anzaahl der Nebelcluuster beeinflusstt werden. In ei-nem n entsprechennden Software-T Tool sollten die Nebelcluster voom Betrachter konfiguriert k undd – je nach Bedarff – aktiviert bzw w. deaktiviert weerden können (ähhnlich einer Filterfunktion).

198 1

G Generische Sichtenn

Abbildung A 68: Proozesslandschaft miit horizontalen Nebelclustern

In Bezug auf daas Generische Siichtenkonzept können k sowohl der d Entwurf mitt nur einem dar-gestellten g Prozesss als auch der erweiterte e Entwurf mit zwei Proozessen als eigeenständige Sich-ten angesehen w werden. Anders ausgedrückt a stelllen die beiden 3-D-Entwürfe 3 sppezifische Sich-ten dar, die Aussschnitte eines Systems mit deen für einen Staakeholder relevvanten Aspektenn repräsentieren. r 6.6 6

Prozessp perspektive beii der Verwendu ung Generischeer Sichten

Um U eine konkrette Implementierrung des Generischen Sichtenkoonzepts anwendden und kontinu-ierlich verbesserrn zu können, müssen m untersch hiedliche Schrittte durchlaufen werden, w auf diee zum z Teil schon im Generischenn Sichtenmodelll eingegangen wurde. w Im Folggenden wird dass Generische G Sichhtenkonzept aus einer Prozessperspektive näheer beschrieben und u die notwen-digen d Schritte errläutert. Im ersten Schriitt müssen Datten aus zahlreiichen unterschiiedlichen Artefaakten, Buildingg Blocks B und Deliiverables, die im m Lebenszyklus eines SOA-basiierten Systems entstehen, e extra-hiert h werden. D Dabei kann es siich im Fall einer SOA beispieelsweise um Daaten aus UML-,, XML-, X Text-, odder Quellcode-D Dokumenten haandeln. Die Heteerogenität der aus a unterschied-lichsten Quellenn stammenden extrahierten e Daten erfordert im Rahmen des zw weiten Schrittess

Prozessperspektive bei der Verwendung Generischer Sichten

199

eine Transformation, um sie in Bezug auf die Informationsmodelle zu harmonisieren, zu aggregieren und semantisch anzureichern. Im dritten Schritt werden die transformierten Daten in ein Repository geladen. Von besonderer Bedeutung ist, dass bei Änderungen der Artefakte mithilfe von Synchronisationsmechanismen die Konsistenz der transformierten Daten zu gewährleisten ist. Die Extraktion, die Transformation und das Laden können sowohl automatisiert durch entsprechende Werkzeuge oder manuell durch die Stakeholder erfolgen, wobei eine Automatisierung aus Gründen der Wirtschaftlichkeit jedoch klar bevorzugt werden sollte. Der vierte und letzte Schritt beinhaltet die graphische Repräsentation, die auf Basis der Vorgaben des Generischen Sichtenmodells erzeugt wird. Die ersten drei genannten Schritte sind mit Prozessschritten vergleichbar, die im Bereich der Business Intelligence (BI), des Data Warehouse und der Management Support Systeme (Bauer und Günzel 2008; Chamoni und Gluchowski 2006; Schütte et al. 2001; Turban et al. 2006) Anwendung finden. Sie sollen, ähnlich wie die Schritte von ETL-Prozessen (Extraktion, Transformation, Laden) des Data Warehousing (Bauer und Günzel 2008, S. 79ff.; Turban et al. 2006, S. 222ff.), eine weitgehende Automatisierung der Datenbereitstellung erlauben. Der vierte Schritt hingegen kann mit dem betrieblichen Berichtswesen bzw. -system verglichen werden, dessen Aufgabe darin besteht, durch eine geeignete Informationslogistik „[…] Mitarbeitern die richtigen Informationen zum passenden Zeitpunkt in erforderlicher Form und Genauigkeit am benötigten Platz anbieten zu können.“ (Chamoni und Gluchowski 2006, S. 209) Um einen weitestgehend reibungslosen Ablauf der vier Schritte gewährleisten zu können, müssen diese, wie auch schon in den Prämissen für das Generische Sichtenkonzept formuliert (siehe Kapitel 6.2), von Governance-Mechanismen und der Definition entsprechender Policies, Prinzipien, Standards und Prozeduren unterstützt werden. Aus der Prozessperspektive wird das Generische Sichtenkonzept als Teil eines evolutionären Prozesses verstanden, der durch das Feedback von Stakeholdern in unterschiedlichen Lebenszyklusstufen und Disziplinen einer kontinuierlichen Weiterentwicklung und Verbesserung unterliegt. Da die unterschiedlichen Prozessbestandteile voneinander abhängig sind, trägt die kontinuierliche Verbesserung der einzelnen Bestandteile auch zu einer Verbesserung des Gesamtkonzepts bei. Wie in Abbildung 69 dargestellt, entsteht auf Basis der Erfahrungen von Stakeholdern bei der Verwendung Generischer Sichten Feedback, das zur Erweiterung und Verbesserung der Informationsmodelle bezüglich neuer Asset-Typen, Strukturen oder Abhängigkeiten beiträgt. Die Verfeinerung der Informationsmodelle hingegen verbessert das Management der Artefakte, Building Blocks und Deliverables. Es trägt zudem zu einer höheren Integration der Arbeitsergebnisse bei, wodurch wiederum andere Aspekte, wie die Verbesserung der Traceability oder (Meta-)Datenkonsistenz, beeinflusst werden.

200 2

G Generische Sichtenn

Abbildung A 69: Gen nerische Sichten als a Teil eines evolutionären Prozessees

Eine E verbessertee Verwaltung unnd Integration vo on Arbeitsergebnnissen wiederum m erlaubt es denn verschiedenen v S Stakeholdern, ihrre Concerns prääziser zu definieeren, da mehr Daten D und Meta-daten d in einer strrukturierten undd standardisierteen Art und Weisse extrahiert undd integriert wer-den d können. Dass bedeutet, dass eine größere An nzahl an Concerrns durch Datenn und Metadatenn im m Repository abbgedeckt werden. Die Unterstützung einer größßeren Anzahl sppezifischer Con-cerns c seitens dess Repositories hat h indes Einflusss auf die Erzeuugung Generischher Sichten undd ih hren Informatioonsgehalt, da diees eine Verfeineerung des Dimennsionssystems, der Profilkonfi-gurationen, g der K Kontexterzeugunng und der Visuualisierung ermööglicht. Im Gegensatz zuu Sichten, die während w des Sysstementwurfs unnd der Systementwicklung vonn einer e eingeschräänkten Anzahl an a Stakeholdernn manuell erstellt werden, förddert der Einsatzz Generischer G Sichhten die Partizippation zahlreich her unterschiedliicher Stakeholdder. Der zentralee Vorteil V Generisccher Sichten aus der Prozesspeerspektive ist deemnach in der kontinuierlichen k n Verbesserung V deer Prozessbestanndteile durch diee beteiligten Stakkeholder zu sehen. 6.7 6

Generische Sichten im Kontext von IS SO/IEC 42010 IEEE Std 14711-2000

In Kapitel 5.4 w wurde erwähnt, dass das Generrische Sichtenkonzept das im ISO/IEC I 420100 IEEE Std 1471-22000-Standard (ISO/IEC ( und IE EEE 2007) definnierte Frameworrk und die darinn festgelegten f Term rminologien undd Konzepte berü ücksichtigt. Abbbildung 70 zeigt eine Übersicht,, in n der das konzeeptionelle Modeell zur Architektturbeschreibungg des ISO/IEC 42010 4 IEEE Stdd 1471-2000-Stand 1 dards um die verschiedenen v Bestandteile B des Generischen Sichtenmodellss

Generische Sichten im Kontext von ISO/IEC 42010 IEEE Std 1471-2000

201

erweitert wird. Wie im ISO/IEC 42010 IEEE Std 1471-2000-Standard angemerkt, handelt es sich bei dem Modell zur Architekturbeschreibung um eine Zusammenfassung der Schlüsselkonzepte. Dies gilt ebenfalls für die in Abbildung 70 dargestellte Übersicht, bei der aus Gründen der Übersichtlichkeit der Fokus ebenfalls auf die Schlüsselkonzepte gerichtet ist und bewusst auf Details bei der Darstellung verzichtet wurde. Mission 1..* fullfills

has

Environment

Social System

Psychic System

based on

0..* depends upon

0..*

serves as medium assigned to Stakeholder assigned to 1..*

affects

Architecture Element relates to 0..*

has 1..* identifies 1..*

1..* chooses

1

provides

described by

Architectural Description

is important to

raises 0..* 1..* has 1..* 1..* selects 0..* pertains to identifies conforms to Concern Viewpoint covers 1..* corresponds to 1 1..* defines

Dimension

Rationale

Cognition

results in 0..*

0..*

Technical System

0..*

Decision

Architecture

based on

Communication 0..*

has 1

System

irritates

Implicit Viewpoint

Profile

may define 0..1

Explicit Viewpoint

1..* organized by View 1..*

establishes methods for

participates in 1..* composed from Model

is matched 0..1 has source provides

Metadata

Context

Library Viewpoint

Static Model

Generic Model

is generated from

Abbildung 70: Generische Sichten und ISO/IEC 42010 IEEE Std 1471-2000

In der Übersicht werden die ursprünglichen Schlüsselkonzepte des ISO/IEC 42010 IEEE Std 1471-2000-Standards als weiße Elemente dargestellt. Die orangenen Elemente sind Konzepte, die aus der Weiterentwicklung des ISO/IEC 42010 IEEE Std 1471-2000-Standards, also aus ISO/IEC 42010 (IEEE P42010/D6) (ISO/IEC und IEEE 2009), übernommen wurden. Bei den grünen Elementen handelt es sich um Modifikationen des ISO/IEC 42010 IEEE Std 14712000-Standards, die zur Integration der Bestandteile des Generischen Sichtenmodells notwendig sind. Diese Modifikationen haben jedoch keinen direkten Einfluss auf das ursprüngli-

202

Generische Sichten

che Modell des ISO/IEC 42010 IEEE Std 1471-2000-Standards, da es sich lediglich um Spezialisierungen einzelner Schlüsselkonzepte handelt. Die blauen Elemente stellen die spezifischen Erweiterungen des ISO/IEC 42010 IEEE Std 1471-2000-Standards durch das Generische Sichtenmodell dar. Die Beziehung zwischen System und Umwelt wird im Sinne der Systemtheorie als System/Umwelt-Differenz verstanden. Das heißt es können zahlreiche unterschiedliche System/Umwelt-Konstellationen existieren, die sowohl eigene als auch übergeordnete Ziele verfolgen, je nachdem, wie Systeme bzw. Teilsysteme durch die Systembildung ausdifferenziert sind (siehe Kapitel 4.2.3 und 4.5). Jedes dieser Systeme besitzt eine Architektur, die mithilfe einer Architekturbeschreibung dokumentiert wird. Systeme werden, ebenfalls in Anlehnung an die Systemtheorie, weiter spezialisiert. Dabei werden in diesem Kontext die folgenden drei Systeme berücksichtigt: Soziale Systeme, psychische Systeme und technische Systeme. Wie in Kapitel 4.2.3.3 beschrieben, basieren soziale Systeme auf Kommunikation und psychische Systeme auf Kognition. Beide Operationsweisen werden unterschiedlichen Stakeholdern zugerechnet. Die Stakeholder wiederum erstellen technische Systeme auf Basis dieser Operationsweisen. Andersherum gesehen hat ein technisches System nach seiner Konstruktion unterschiedliche Stakeholder, die bestimmte Funktionen im Rahmen ihrer Aufgaben in Anspruch nehmen. Um den in Kapitel 5.4 diskutierten Aspekt der Kommunikation hervorzuheben, wurde die Beziehung zwischen dem Element der Kommunikation und der Architekturbeschreibung explizit berücksichtigt. Diese bringt zum Ausdruck, dass die Architekturbeschreibung die Funktion eines zentralen Kommunikationsmediums einnimmt. Dabei werden in erster Linie Architekturentscheidungen kommuniziert, die voneinander abhängig sind und im Laufe der Evolution weitere Architekturentscheidungen beeinflussen. In diesem Zusammenhang sollte auf Basis der Architekturbeschreibung kommuniziert und nachvollzogen werden können, aus welchem Grund (Rationale) eine bestimmte Entscheidung getroffen wurde und welchen Einfluss die Entscheidung auf die unterschiedlichen Architekturelemente und ihre Beziehungen hat. Stakeholder-Concerns werden durch die unterschiedlichen Entscheidungen hervorgerufen oder Entscheidungen im Rahmen spezifischer Concerns getroffen. Die Architekturbeschreibung muss dabei sicherstellen, dass alle relevanten Informationen bezüglich eines Concerns gewonnen werden können. Um eine erhöhte Informationsversorgung der Stakeholder zu erreichen und Aspekte der Kommunikation zwischen den Stakeholdern besser unterstützen zu können, wird der ISO/IEC 42010 IEEE Std 1471-2000-Standard um die Bestandteile des Generischen Sichtenmodells zur Erzeugung kontextspezifischer Sichten erweitert.

Generische Sichten im Kontext von ISO/IEC 42010 IEEE Std 1471-2000

203

Wie im Generischen Sichtenmodell beschrieben (siehe Kapitel 6.4), werden die Concerns der unterschiedlichen Stakeholder auf Basis des Dimensionssystems in Form von Profilen abgebildet. Durch das Mapping der Profile und Daten/Metadaten wird der Kontext erzeugt. Der Kontext steht in Beziehung mit einem Viewpoint, wobei durch die Integration Generischer Sichten zwischen impliziten und expliziten Viewpoints (siehe Kapitel 5.4) unterschieden werden muss. Jede Sicht besitzt einen impliziten Viewpoint, so dass in diesem Fall eine 1-zu1-Korrespondenz zwischen einer View und einem Viewpoint besteht. Durch die „just in time“-Erzeugung von Sichten beziehen sich der Kontext und die Darstellung einer Generischen Sicht in der Regel auf einen impliziten Viewpoint einer Sicht. Explizite Sichten hingegen sind Spezifikationen von Konventionen, die bei der Konstruktion und Verwendung von Sichten eingehalten werden müssen. Sofern diese Konventionen bei der Erzeugung Generischer Sichten eingehalten werden, können sich der Kontext und die Darstellung einer Generischen Sicht durchaus auch auf explizite Viewpoints beziehen. Eine Sicht mit einem impliziten oder expliziten Viewpoint wird aus einem oder mehreren Modellen zusammengestellt. Als statische Modelle werden Modelle verstanden, die im Rahmen der Architekturentwicklung unter Berücksichtigung der Konventionen expliziter Viewpoints entworfen werden. Wie in Kapitel 5.4 erwähnt, ist es jedoch auch möglich, eine Sicht bzw. die Modelle für ein spezifisches System ad hoc zu erstellen und erst später zu entscheiden, ob ein expliziter Viewpoint definiert wird. Generische Modelle hingegen sind Darstellungen, die auf Basis des Generischen Sichtenmodells zur Visualisierung eines spezifischen Kontexts erzeugt werden. Der Vorteil der Unterscheidung impliziter und expliziter Viewpoints sowie der Erweiterung durch das Generische Sichtenmodell liegt darin, dass mit der Erzeugung kontextspezifischer Sichten die hohe Dynamik und die daraus resultierenden Wechselwirkungen besser erfasst werden können, gleichzeitig aber nach wie vor formalisiertere Verfahren zur Konstruktion von Architektursichten zur Verfügung stehen. Zudem eröffnen Generische Sichten neue Möglichkeiten für die Identifikation geeigneter expliziter Viewpoints, bspw. wenn bestimmte Profilkonfigurationen sehr häufig verwendet werden oder sich alternative Darstellungsformen bewährt haben.

7

Prototypische Realisierung

Als Proof of concept wurde im Rahmen dieser Forschungsarbeit ein Prototyp (Codename „Kaleidoscope“) entwickelt, um einerseits die technische Machbarkeit des Generischen Sichtenkonzepts überprüfen und andererseits Aussagen hinsichtlich der Verwendung Generischer Sichten treffen zu können. Darüber hinaus sollen aktuelle und zukünftige Erfahrungen im Umgang mit dem Prototyp zu wichtigen Erkenntnissen bezüglich des theoretischen Gesamtkonzepts beitragen. Im Folgenden wird zunächst auf Aspekte des Entwurfs und der Implementierung des Prototyps eingegangen (Kapitel 7.1). Dazu werden die Kernkomponenten des Prototyps und deren Funktionen näher beschrieben. Anschließend werden die unterschiedlichen Konfigurationsmöglichkeiten des Prototyps in Bezug auf das Dimensionssystem, die Profile, das Regelsystem und die Darstellung vorgestellt (Kapitel 7.2). Zum Abschluss wird auf Basis unterschiedlicher Profilkonfigurationen die Verwendung des Prototyps in der Rolle eines ServiceDesigners und eines Geschäftsprozessarchitekten exemplarisch erläutert (Kapitel 7.3). 7.1

Entwurf und Implementierung des Prototyps

Die technologische Basis des Prototyps bildet das Microsoft .NET Framework. Für die dreidimensionale Visualisierung Generischer Sichten wurde unter Berücksichtigung der in Kapitel 6.5 vorgestellten Entwürfe eine 3-D-Engine auf Basis des Microsoft XNA Frameworks33 implementiert. Als zentrales SOA Repository bzw. zentrale SOA Registry34 zur Speicherung der Daten, Metadaten und Assets wurde das Produkt CentraSite35 der Software AG verwendet. CentraSite stellt sowohl eine UDDI- als auch eine JAXR-Schnittstelle (Java API for XML Registries) zur Verfügung. Die Java-basierte JAXR-Schnittstelle wurde mithilfe von Web Services gekapselt, um den Zugriff für Queries vom .NET-basierten Prototyp zu ermöglichen. Das Dimensionssystem wurde auf Seiten des Repositories mithilfe von Klassifikationen und Kategorien abgebildet, so dass die SOA-Elemente, die im Repository gespeichert werden, den Dimensionen bzw. Dimensionsausprägungen zugeordnet werden können. Der Entwurf und die Implementierung des Prototyps orientiert sich an den vier Kernbereichen des Generischen Sichtenmodells. In Abbildung 71 werden die Kernkomponenten des Prototyps und deren Abhängigkeiten dargestellt.

33 34

35

Siehe http://creators.xna.com Bei den Produkten, die am Markt existieren, werden die Begriffe Repository und Registry unterschiedlich verwendet. Im Folgenden wird weiterhin der Begriff Repository verwendet, auch wenn sich dies nicht immer mit den Terminologien der Produkthersteller deckt. Siehe http://www.softwareag.com/corporate/products/wm/soagovernance/centrasite/overview/default.asp

T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_7, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

206

Prototypische Realisierung

Client

Profile

VisEngine

SOAAnalysis

SOAContext

SOAObjectModel

Abbildung 71: Kernkomponenten des Prototyps

x

Profilkomponente (Profile): Neben der Verwaltung des Dimensions- und Regelsystems ist die Profilkomponente für die Erstellung, das Laden und die Validierung von Profilkonfigurationen verantwortlich. Darüber hinaus umfasst die Profilkomponente die Erstellung und Verwaltung von Queries sowie deren Ausführung über Schnittstellen zu einem Repository.

x

Analysekomponente (SOAAnalysis): Die Analysekomponente übernimmt Funktionen der Analyse und Aggregation von Daten und Metadaten, die auf Basis der Profilkonfigurationen und den entsprechenden Queries von der Profilkomponente zur Verfügung gestellt werden.

x

Kontextkomponente (SOAContext): Die Kontextkomponente verwaltet die Strukturen der analysierten und aggregierten Daten und Metadaten in Form eines oder mehrerer Graphen.

x

Objektkomponente (SOAObjectModel): Die Objektkomponente verwaltet die analysierten und aggregierten Daten und Metadaten in Form von Objektmodellen.

x

Visualisierungskomponente (VisEngine): Die Visualisierungskomponente stellt die für die Darstellung bzw. Visualisierung implementierte 3-D-Engine sowie die notwendi-

Entwurf und Implementierung des Prototyps

207

gen Layoutalgorithmen und graphischen Elemente zur Verfügung. Darüber hinaus ist die Komponente für die Umsetzung visueller Konzepte verantwortlich. x

Benutzerschnittstelle (Client): Die Benutzerschnittstelle stellt Bedienelemente zur Konfiguration von Profilen, zur Interaktion mit Generischen Sichten und zur Anzeige zusätzlicher Informationen zur Verfügung.

Das Klassendiagramm in Abbildung 72 gibt eine Übersicht über die zentralen Klassen der zuvor genannten Komponenten. Durch die farbige Markierung wird die Zugehörigkeit der Klassen zu den Komponenten in Abbildung 71 veranschaulicht. Die Klasse ProfileManager übernimmt die zentralen Funktionen zur Verwaltung von Profilen, wie z.B. das Erstellen, Editieren, Löschen und Laden von Profilkonfigurationen. Die Funktionalität zur Verwaltung der Profile wird über Steuerelemente im Client zur Verfügung gestellt. Darüber hinaus werden auf Basis der Profilkonfigurationen Queries generiert, die über einen Proxy der Web Service-Schnittstelle zum Repository weitergereicht werden. Der Zugriff auf das Dimensionssystem erfolgt über die Klasse Configuration, die Verwaltung der Profilkonfigurationen, die in einer Liste gespeichert werden, über die Klasse Profile. Auf eine Darstellung der einzelnen Klassen des Dimensionssystems und der Profilkonfiguration wird der Übersicht halber verzichtet. Im nächsten Kapitel wird im Rahmen der unterschiedlichen Konfigurationsmöglichkeiten des Prototyps aber näher auf die Strukturen des Dimensionssystems und der Profilkonfigurationen eingegangen. Die Daten und Metadaten der SOA-Elemente, die nach Auswahl einer Profilkonfiguration und Durchführung der entsprechenden Queries vom Repository zurückgeliefert werden, werden mithilfe einer Liste von Objekten des Typs MetaInformation verwaltet. Die Klasse MetaInformation umfasst unterschiedliche Attribute, wie z.B. den Namen, den Typ und die Beschreibung des SOA-Elements, Assoziationen zu anderen SOA-Elementen sowie Referenzen zu den zugrunde liegenden Artefakten. Die Liste mit Objekten des Typs MetaInformation wird an die Klasse AnalysisManager übergeben, die Analysen bezüglich der Abhängigkeiten zwischen den SOA-Elementen durchführt. Darüber hinaus kommen verschiedene Parser zum Einsatz, um weitere SOA-Elemente und Abhängigkeiten, die nicht direkt im Repository hinterlegt sind, aus den referenzierten Artefakten extrahieren und in Objektmodelle überführen zu können. Durch die Verwendung einheitlicher Schnittstellen ist die Analysekomponente flexibel und erweiterbar, so dass Parser für unterschiedliche Quellcode-Artefakte, wie z.B. BPMN, WSDL, XPDL oder WSBPEL Dokumente, jederzeit in die Analyse eingebunden werden können. Die Klasse Object bildet die Basisklasse für alle weiteren Klassen der spezifischen Objektmodelle.

208

Prototypische Realisierung

Abbildung 72: Zentrale Klassen der Komponenten des Prototyps

Während der Analyse werden die SOA-Elemente zudem in eine Graphenstruktur überführt. Der Graph wird durch die Klasse SOAGraph, die SOA-Elemente durch die Klasse SOAElement und die Abhängigkeiten durch die Klasse SOADependency repräsentiert. Mithilfe der Klasse LogicalGraphIdentifier wird eine Codierung logischer Teilgraphen vorgenommen und jedes SOA-Element einem dieser Teilgraphen zugeordnet. Die Klasse SOAElement repräsentiert die Knoten des Graphen und umfasst alle für den Kontext der Profilkonfiguration relevanten Eigenschaften eines SOA-Elements. Zu den Eigenschaften zählen u.a. Attribute, die die Zuordnung zu den Dimensionsausprägungen, wie bspw. die Zuordnung zu einer Abstraktionsschicht, beschreiben. Darüber hinaus besitzt die Klasse SOAElement eine Referenz zu dem Objekt, welches das ursprüngliche SOA-Element im Objektmodell repräsentiert. Die Klasse SOAElement besitzt somit einen höheren Abstraktionsgrad als das referenzierte Pendant im Objektmodell. Die Klasse SOADependency umfasst eine Quell- und eine Zielreferenz auf die Klasse SOAElement und repräsentiert somit die Kanten des Graphen. Zudem besitzt auch die Klasse SOADependency eine Referenz auf ein entsprechendes Objekt im Objektmodell, sofern die Abhängigkeit explizit als Objekt im Objektmodell vorgesehen ist. Der Zugriff auf die Visualisierungskomponente (VisEngine) erfolgt über die Klasse GenericViewControl. Bei der Klasse handelt es sich um ein graphisches Steuerelement, das in unter-

Konfigurationsmöglichkeiten

209

schiedliche Clients (z.B. Entwicklungsumgebungen, Office-Anwendungen oder Eigenentwicklungen) eingebunden werden kann. Die Visualisierungskomponente umfasst zudem die Implementierung der 3-D-Engine, in der unterschiedliche Kamerasysteme, eine Content Pipeline zum Laden graphischer Elemente (Texturen, 3-D-Modelle, Text, Effekte, etc.) und verschiedene Interaktionsmöglichkeiten realisiert sind. In das Steuerelement können unterschiedliche Arten von Projektionsflächen über die Schnittstelle IScreen geladen werden. Die Klasse ViewScreen implementiert die Schnittstelle IScreen und stellt eine Projektionsfläche zur dreidimensionalen Darstellung Generischer Sichten zur Verfügung. Die Erzeugung und Repräsentation einer Generischen Sicht erfolgt mithilfe der Klasse View. Dazu wird auf die Klasse SOAGraph zugegriffen und für jedes SOA-Element und jede Abhängigkeit ein Sichtenobjekt vom Typ ViewObject erzeugt. Jedem Sichtenobjekt wiederum wird abhängig von dem Typ des referenzierten SOA-Elements ein graphisches Element, wie z.B. 3-D-Modelle, Billboards, Verbindungslinien oder Text, zugeordnet. Die Klasse Model bspw. erbt wie alle anderen graphischen Elemente von der abstrakten Basisklasse GraphicsComponent und ist für das Rendering von 3-D-Modellen zuständig. Neben der Erzeugung und Verwaltung von Sichtenobjekten ist die Klasse View für deren Anordnung verantwortlich. Dazu bedient sie sich u.a. der Funktionalität der Klasse LayoutGraph, die unterschiedliche Layouter zur Verfügung stellt. Die Anordnung der Elemente und die Auswahl der Layouter erfolgen abhängig von dem Typ des referenzierten SOA-Elements und dessen Zuordnung zu Dimensionsausprägungen der Strukturdimensionen sowie zu logischen Teilgraphen. 7.2

Konfigurationsmöglichkeiten

Der Prototyp besitzt verschiedene Konfigurationsmöglichkeiten, um das Dimensionssystem, die Profile, das Regelwerk und die Darstellung in unterschiedlichen Anwendungskontexten flexibel anpassen zu können. Für die Konfigurationen werden XML-Dateien verwendet, deren Strukturen auf Basis von XML-Schema-Definitionen (XSDs) festgelegt wurden. Die Struktur des Dimensionssystems wurde auf Basis einer XML-Schema-Definition beschrieben, die in Abbildung 73 veranschaulicht wird. Das Dimensionssystem wird demnach über den Bereich Settings festgelegt. Darüber hinaus umfasst der Settings-Bereich Repositoryspezifische Qualifier und Classifications, die für die Generierung von Queries verwendet werden. Somit lassen sich Repositories unterschiedlicher Hersteller in die Konfiguration einbinden und mit dem Dimensionssystem in Verbindung setzen. Das Dimensionssystem besitzt gemäß dem Generischen Sichtenmodell (siehe Kapitel 6.4.1.1) unterschiedliche Dimensionstypen (Types), für die wiederum die jeweiligen Dimensionsausprägungen (DimensionValue) festgelegt werden können. Die Unterscheidung der Profildimensionen in Strukturdimensionen und Wertdimensionen wird im Bereich Categories festgelegt.

210 2

Prototyppische Realisierungg

Abbildung A 73: XM ML-Schema-Definiition des Dimensio onssystems

Jedes J Element ddes Dimensionsssystems besitzt eine eindeutige ID in Form einner GUID. Diess hat h den Vorteil, dass das Dimennsionssystem einne eigene Abstraaktionsschicht besitzt und somitt mit m unterschiedllichen Standardds, Produkten oder o Lösungen verknüpft werrden kann. Diee ms und eine XM XML-Schema-D X Definition des Dimensionssyste D ML-Konfiguration des Dimen-sionssystems s auff Basis dieses XML-Schemas X siind in Anhang A.1 A und A.2 zu finden. f Um U eine hohe F Flexibilität gewäährleisten zu kö önnen, wird das Dimensionssystem im Bereichh Settings S völlig fr frei definiert, d.hh., es liegen nocch keine Restrikktionen bzw. Regeln bezüglichh der d Kombinationnsmöglichkeitenn von Dimensionen und Dimeensionsauspräguungen vor. Dass Regelwerk R zur D Definition bestiimmter Restrikttionen des Dim mensionssystems wird über denn Bereich B Policiess festgelegt. Die D entsprechennden technologisschen Konzeptee zur Abbildungg eines solchen Regelwerks so-wie w ein Prototypp zur Erstellungg von Restriktion nen (Regeleditoor) und Validierrung von Profil-konfigurationen k wurden in eineer Diplomarbeit von Witteler (W Witteler 2009) erarbeitet. e Diesee

Konfigurationsmög K lichkeiten

2111

bauen b auf dem Schema S des Dim mensionssystem ms (Abbildung 73) auf, das als Vorgabe V für diee Entwicklung E einnes Regelsystem ms galt. Die D schematischhe Darstellung inn Abbildung 74 zeigt, dass sichh das Regelwerkk aus einer Men-ge g an Restriktionnstypen, Restrikktionen und spezziellen Beziehunngen, mit denenn die Zuordnun-gen g von Wertdim mensionen und unterstützten Strukturdimensioonen festgelegt werden, w zusam-mensetzt. m

Abbildung A 74: XM ML-Schema-Definiition des Regelsysttems

Über Ü einen Edittor können die Restriktionen für f das Dimenssionssystem anggelegt und dem m Schema S entsprecchend in eine XML-Datei X seriialisiert werden. Bei jeder Proofilkonfigurationn durch d einen Bennutzer werden diie definierten Reestriktionen dannn überprüft. Die D Konfiguratioon der Profile erfolgt e über die Auswahl und Parametrisierung P g von Dimensi-onsausprägungen o n. Das Schema der Profilkonfigguration wird inn Abbildung 75 dargestellt. Einn Profil P besitzt einnen Namen und eine eindeutigee ID. Dem Profi fil können im Beereich Dimensi-ons o unterschiedlliche Dimensionen (Dimension n) und Dimenssionsausprägunggen (Value) dess Dimensionssyste D ems durch einenn Verweis auf deeren IDs zugorddnet werden. Je ProfilkonfiguraP tion muss mindeestens eine Dim mension und je Dimension D minddestens eine Dim mensionsausprä-gung g ausgewählt werden. Alle weiteren w Einsch hränkungen werrden, wie zuvor erläutert, durchh die d Restriktionenn des Regelwerrks vorgegeben. Die XML-Schhema-Definitionn für die Profil-konfiguration k unnd eine XML-K Konfiguration unterschiedlicher u r Profile auf Basis B des XML-Schemas S sind in Anhang A.3 unnd A.4 zu findenn.

212 2

Prototyppische Realisierungg

Abbildung A 75: XM ML-Schema-Definiition der Profilkon nfiguration

Die D Konfiguratioon der Darstelluung Generischer Sichten ist in der d aktuellen Version des Proto-ty yps nur eingescchränkt möglich, da bestimmte Teile der Visuaalisierung, die koonfiguriert wer-den d könnten, nooch hart codiert vorliegen. Einen Vorschlag zuur Konfigurationn der Visualisie-rung r Generischeer Sichten wurdee jedoch von Witteler, W ebenfallls im Rahmen seeiner Diplomar-beit b (Witteler 20009), erarbeitet. Dabei orientiert sich Witteler an dem Web-S Standard Casca-ding d Style Sheets (CSS), der eine Trennung von v Inhalt und Darstellung D erm möglicht. Das inn Abbildung A 73 daargestellte Schem ma des Dimensiionssystems galtt auch hier als Vorgabe. V Der D grundlegendde Aufbau der Schemadefinition n für die Konfigguration der Visuualisierung wirdd in n Abbildung 766 dargestellt. Follgende Elementtgruppen werdenn unterschieden (Witteler 2009,, S. S 65ff.): x

ormen zur Darrstellung der einzelnen e SOA-entityForrms: Menge geeometrischer Fo Elementee

x

entityCollors: Menge möglicher Farben der d einzelnen SO OA-Elemente

x

entitySizees: Menge mögllicher Größen deer einzelnen SOA-Elemente

x

entityStruuctures: Mengee möglicher Ob berflächeneigennschaften der einzelnen e SOA--

x

layers: D Darstellungsmögglichkeiten der Layer L und Sub-L Layer

x

overridess: Möglichkeiteen, einzelne Eig genschaften besttimmter SOA-E Elemente gezieltt zu überscchreiben

Elementee

Konfigurationsmög K lichkeiten

2133

Abbildung A 76: XM ML-Schema-Definiition zur Konfigurration der Visualissierung Generisch her Sichten

Über Ü die ersten vier Elementgrruppen können die für die Daarstellung verfüggbaren Formen,, Farben, F Größen und Strukturen erfasst werden. Die Elemente der d ersten vier Elementgruppen E n besitzen b alle diee gleichen Attribbute. So kann für f jedes Elemeent ein Name, eine e ID und einn Wert W festgelegt werden. Als Wert W eines Elem ments entityForm m könnte bspw. der Dateinamee eines e 3-D-Modells festgelegt weerden, als Wert eines Elements entityColor einne Hexadezimal-zahl. z Die D Konfiguratioon der Darstelluung unterschiedllicher Schichtenn erfolgt über diie Elementgrup-pe p Layers (siehee Abbildung 77). Darin wird zum m einen übergeoordnet festgelegt, welche Struk-tu urdimensionen den Achsen dess Koordinatensy ystems im 3-D-R Raum zugeordneet werden. Zum m anderen a können die einzelnen Schichten S und Su ubschichten übeer die Elemente Layer und Sub-Layer L definiert werden. Dazu stehen unterschhiedliche Attribuute zur Verfüguung, mit denenn bestimmt b wird, welche Dimenssionsausprägung gen den einzelnnen Schichten zugeordnet z sind,, wie w SOA-Elemeente auf die einnzelnen Subschiichten verteilt und u wie die SO OA-Elemente inn Bezug B auf die einnzelnen Schichtten darzustellen sind. Mithilfe M der Elem mentgruppe Oveerrides besteht die d Möglichkeitt, die Darstellungseigenschaftenn graphischer g Elem mente an bestim mmte Bedingung gen zu knüpfen und u die Standarrdwerte zu über-schreiben. s In Annlehnung an denn CSS-Standard d ist es somit möglich, m mehreree Stile in einem m Stil S zu „kaskadieeren“ und in einer definierten Reihenfolge R zu übberschreiben. Als A Bedingungenn können k bspw. diie Zugehörigkeitt zu bestimmten n Dimensionsaussprägungen oderr spezielle Wer-tebereiche festgeelegt werden. Soo könnte z.B. eiin kritischer Serrvice, der der Domäne D Financee angehört a und einnen Schwellenw wert in Bezug auf seine Perform mance überschrreitet, rot darge-stellt s werden.

214 2

Prototyppische Realisierungg

Abbildung A 77: Ausszug der XML-Sch hema-Definition zur z Konfiguration visueller Schichteen

7.3 7

Einsatz und Verwendu ung des Prototy yps

Im Folgenden w werden der Einsatz und die Verrwendung des Prototyps P in konnkreten Anwen-am Beispiel zw dungskontexten d weier Szenarien betrachtet, um Aussagen A über den Nutzen dess Generischen G Sicchtenkonzepts trreffen zu könneen. Dafür werdeen die Concernss eines Service-Designers D und eeines Geschäftspprozessarchitekten mithilfe von Profilkonfiguraationen abgebil-det d und die entspprechenden Sichhten erzeugt. Diie benötigten Arrtefakten, Datenn und Metadatenn sind s in einem SO OA Repository gespeichert. g Dabbei handelt es sich um Beispielldaten, die wäh-rend r der Definitiion von Szenarieen ausgewählt wurden. w Aus A den in Kapiitel 3.4 vorgesteellten Rollenbesschreibungen lasssen sich für diee Rolle des Ser-vice-Designers v – auch als Serviice-Architekt beezeichnet – die folgenden f wesentlichen Aufga-benfelder b und Verantwortlichkeiten zusammenffassen: x

Bereitstellung von Serviceverträgen und d Entwurf von Servicelogik

x

Entwurf von Services auuf Basis der Geschäftsanforderuungen

Einsatz und Verwendung des Prototyps

215

x

Technischer Entwurf von Services unter Berücksichtigung von Servicekandidaten

x

Zuordnung von Services und Geschäftsprozessen

x

Modellierung von Services und deren Abhängigkeiten

x

Definition und Wartung der Richtlinien und Schemata für den Nachrichtenaustausch zwischen Services

Im Rahmen der Aufgabenfelder und Verantwortlichkeiten eines Service-Designers tritt folgendes Szenario ein: Aufgrund eines Change Requests, der einen bestimmten Prozess betrifft, benötigt der ServiceDesigner Informationen über alle mit dem Prozess verbundenen Serviceschnittstellen. Der Fokus seines Concerns liegt daher in der Analyse der Abhängigkeiten zwischen dem Prozess und den verwendeten Services. Darüber hinaus ruft der Change Request technologische Fragestellungen hervor, so dass technische Aspekte des Prozesses und der Services von Relevanz sind. Zur Beantwortung der Fragestellungen liegt keine dokumentierte Sicht vor, die alle relevanten Aspekte gemeinsam berücksichtigt, um die benötigten Informationen gewinnen zu können. Um eine adäquate Sicht mit den entsprechenden Informationen für den Kontext des Szenarios zu erzeugen, konfiguriert der Service-Designer ein Profil, das den Relevanzkriterien seines Concerns entspricht. Tabelle 17 zeigt die Auswahl der Dimensionsausprägungen und deren Parametrisierung. Structural Dimensions Abstraction Orchestrated Services Entity Services

Lifecycle Design

Non-Structural Dimensions Domain Sales

Technical

Functional

Name = market* Message Exchange

Utility Services Tabelle 17: Auswahl und Parametrisierung der Dimensionsausprägungen für die Profilkonfiguration des Service-Designers im Kontext des Szenarios

Die Screenshots in Abbildung 78 und Abbildung 79 zeigen die Benutzeroberfläche des Prototyps bei der Konfiguration des Profils durch den Service-Designer. Die Auswahl und die Parametrisierung der Dimensionsausprägungen werden mithilfe verschachtelter Tabellensteuerelemente vorgenommen.

216 2

Abbildung A 78: Proofilkonfiguration des d Service-Design ners (a)

Abbildung A 79: Proofilkonfiguration des d Service-Design ners (b)

Prototyppische Realisierungg

Einsatz und Verwendung des Prototyps

217

Nachdem der Service-Designer das Profil konfiguriert und angelegt hat, wird es durch Auswahl in der Profilliste geladen. Auf Basis des Profils wird eine Query generiert und an das Repository übergeben. Die Daten und Metadaten der zurückgelieferten Ergebnismenge werden, wie in Kapitel 7.1 beschrieben, analysiert und aufbereitet. Anschließend erfolgt die Visualisierung. Der Screenshot des Prototyps in Abbildung 80 zeigt die erzeugte dreidimensionale Darstellung der Generischen Sicht, die in dem zuvor beschriebenen Steuerelement GenericViewControl (siehe Kapitel 7.1) visualisiert wird. Auf Ebene der Orchestrated Services wird der WSBPEL-Prozess „Marketplace“ dargestellt, der der Domäne Sales zugeordnet ist. Um den Kontrollfluss der Aktivitäten des Prozesses abzubilden, wurde ein hierarchisches Fluss-Layout verwendet. Unterhalb der Aktivitäten, die Web Services aufrufen, befinden sich die PartnerLinks und die PartnerLinkTypes, die im WSBPEL-Prozess (vgl. WSBPEL-Spezifikation (OASIS 2007)) definiert wurden. Diese wiederum sind mit Porttype-Definitionen von Services tieferliegender Service-Schichten verknüpft. Die Schnittstellen der Services wurden mit WSDL (vgl. WSDL-Spezifikation (W3C 2001)) beschrieben. Da es sich dabei jedoch um abstrakte Schnittstellenbeschreibungen handelt und zum Zeitpunkt des Designs weder ServiceBindings noch konkrete Services mit Endpunktreferenzen festgelegt wurden, werden lediglich die Porttype-Definitionen der Web Service-Schnittstellen in der Sicht dargestellt. Nach der Generierung der Darstellung stehen dem Benutzer des Prototyps verschiedene Navigations- und Interaktionsmöglichkeiten zur Verfügung. Der Benutzer kann bspw. zwischen einer First Person-, einer Third Person-, einer Flight-, einer Orbit- und einer Pan&ZoomKamera wechseln, die aufgrund unterschiedlicher Freiheitsgrade verschiedene Navigationstechniken im 3-D-Raum ermöglichen. Die Navigation, also z.B. die Bewegung oder Rotation im 3-D-Raum, erfolgt über Tastaturbefehle, Maussteuerung (Mouse View) oder die Verwendung von Controllern für Spielkonsolen. Abbildung 81 zeigt eine andere perspektivische Darstellung der Sicht nach der Navigation durch den Benutzer. Als Interaktionsmöglichkeit steht dem Benutzer die Selektion graphischer Elemente zur Verfügung, durch die eine Kamerafahrt zum ausgewählten Element eingeleitet wird und weitere Informationen nicht-struktureller Dimensionsausprägungen, sofern verfügbar, angezeigt werden.

218 2

Prototyppische Realisierungg

Abbildung A 80: Visu ualisierung einer Generischen G Sichtt auf Basis der Proofilkonfiguration des d ServiceDessigners (a)

Abbildung A 81: Visu ualisierung einer Generischen G Sichtt auf Basis der Proofilkonfiguration des d ServiceDessigners (b)

Einsatz und Verwendung des Prototyps

219

Für ein weiteres Szenario werden der Einsatz und die Verwendung des Prototyps in der Rolle eines Geschäftsprozessarchitekten (vgl. Kapitel 3.4.2, Rollenbeschreibung nach KajkoMattson et al.) betrachtet. Zu den Aufgabenfeldern und Verantwortlichkeiten eines Geschäftsprozessarchitekten zählen: x

Entwurf der Geschäftsprozessarchitektur und ihrer Komponenten

x

Entscheidungsbefugnis bei Architekturänderungen an Geschäftsprozessen

x

Analyse von Geschäftsanforderungen und Transformation in Architekturkomponenten

Im Rahmen der Tätigkeiten des Geschäftsprozessarchitekten kommt es zu folgendem Szenario: Aufgrund neuer Geschäftsanforderungen muss die Funktionalität der automatisierten Geschäftsprozesse sowie der damit verbundenen Services für die Domäne Human Resources analysiert werden. Zudem sollen die in den Service Level Agreements vereinbarten Dienstgüteeigenschaften der Services überprüft werden. Auch in diesem Szenario liegt keine dokumentierte Sicht vor, um im Rahmen der Analysen alle relevanten Aspekte gleichzeitig betrachten und die benötigten Informationen gewinnen zu können. Tabelle 18 zeigt die Auswahl der Dimensionsausprägungen und deren Parametrisierung, die den Relevanzkriterien des Concerns des Geschäftsprozessarchitekten im Kontext des Szenarios entsprechen. Structural Dimensions Abstraction

Lifecycle

Orchestrated Services

Configuration

Entity Services Utility Services

Non-Structural Dimensions Domain Human Resources

Technical

Functional Name Operation SLA

Tabelle 18: Auswahl und Parametrisierung der Dimensionsausprägungen für die Profilkonfiguration des Geschäftsprozessarchitekten im Kontext des Szenarios

Die Konfiguration des Profils im Prototyp wurde – wie bei der Rolle des Service-Designers – über die in Abbildung 78 und Abbildung 79 dargestellte Benutzeroberfläche vorgenommen. Abbildung 82, Abbildung 83 und Abbildung 84 zeigen die daraus resultierende Visualisierung der Generischen Sicht aus unterschiedlichen Perspektiven.

220 2

Prototyppische Realisierungg

Abbildung A 82: Visu ualisierung einer Generischen G Sichtt auf Basis der Proofilkonfiguration des d Geschäftsproozessarchitekten (aa)

Abbildung A 83: Visu ualisierung einer Generischen G Sichtt auf Basis der Proofilkonfiguration des d Geschäftsproozessarchitekten (b b)

Einsatz E und Verwenndung des Prototypps

2211

Abbildung A 84: Visu ualisierung einer Generischen G Sichtt auf Basis der Proofilkonfiguration des d Geschäftsproozessarchitekten (cc)

Im Gegensatz zuu der Sicht des Service-Designners umfasst diee Sicht des Gescchäftsprozessar-chitekten c nicht nur einen WSB BPEL-Prozess, sondern eine Prozesslandschafft aus mehrerenn WSBPEL-Proze W ssen. Ein weiterrer Unterschied besteht darin, dass d durch die Auswahl A der Di-mensionsauspräg m gung Configuraation alle Schn nittstellenbeschrreibungen die ServiceBindings S s sowie s die konkrreten Services mit m Endpunktrefferenzen enthalteen, die unterhallb der Porttypess dargestellt d werdeen. Bezüglich B des Ü Überdeckungsverrhältnisses von relevanten Aspeekten und bereits dokumentier-ten Sichten (siehhe Kapitel 5.4) wurden w im Zusaammenhang mitt den beiden Szzenarien die fol-genden g Fälle bettrachtet: x

Relevantte Aspekte sind über ü unterschieddliche Sichten verteilt. v

x

Es existieeren dokumentieerte Sichten, diee aber nur Teilasspekte abdeckenn.

Auf A Basis des Generischen G Siichtenkonzepts ließen sich diee spezifischen Concerns C unter-schiedlicher s Rolllen abbilden, daavon betroffene SOA-Elementee identifizieren, analysieren undd mit m zusätzlichenn Metadaten verrknüpfen sowie kontextspezifissche Sichten erzzeugen, die allee relevanten r Aspekkte bezüglich deer Concerns berrücksichtigen. Der D Mehrwert Geenerischer Sich-ten im Gegensattz zu vorhandennen Sichten ist insbesondere darrin zu sehen, daass alle relevan-ten Aspekte „jusst in time“ zur Verfügung V gesteellt und somit diie benötigten Innformationen di-rekt r gewonnen werden w können. Gleiches gilt für f den Fall, wenn relevante Asspekte in keinerr

222

Prototypische Realisierung

der dokumentierten Sichten vorhanden sind. Sollte eine dokumentierte Sicht alle relevanten Aspekte beinhalten, so kann zwar der Bereitstellung dieser Aspekte kein Mehrwert zugeschrieben werden. Ein Mehrwert würde aber dennoch dadurch entstehen, dass die Aktualität und Konsistenz einer identischen dokumentierten Sicht überprüft werden könnten. Die zuvor diskutierten Vorteile eines dreidimensionalen Visualisierungsansatzes (siehe Kapitel 6.5) zur Darstellung Generischer Sichten im Kontext serviceorientierter Architekturen konnten auf Basis der gewählten Szenarien ebenfalls untermauert werden. Dies zeigt sich insbesondere bei der Visualisierung größerer und komplexerer Strukturen, bei denen zweidimensionale Darstellungen auf bekannte Schwächen stoßen (siehe Kapitel 2.4.6). Als hilfreich wurde unabhängig von der Darstellungsform vor allem der Einsatz von Layouts zur visuellen Anordnung und Strukturierung semantischer Konstrukte erachtet. So konnten bspw. die Ordnung der Abstraktionsschichten und die Zugehörigkeit der Elemente zu bestimmten Abstraktionsschichten durch entsprechende visuelle Anordnungen repräsentiert werden.

8

Schlussbetrachtung

In diesem letzten Kapitel werden zunächst die Ergebnisse der Arbeit zusammengefasst (Kapitel 8.1). Daran anschließend wird die Arbeit aus Sicht der zugrunde gelegten Forschungsmethodik reflektiert (Kapitel 8.2). Abschließend wird ein Ausblick auf den weiteren Forschungsbedarf, Erweiterungsmöglichkeiten des Generischen Sichtenkonzepts sowie dessen Einsatz in anderen Anwendungsbereichen gegeben (Kapitel 8.3). 8.1

Zusammenfassung der Ergebnisse

Das Ziel der vorliegenden Arbeit bestand in der Entwicklung eines Konzepts, das die Erzeugung kontextspezifischer Sichten auf SOA-basierte Systeme ermöglicht und somit zu einer verbesserten Informationsverarbeitung sowie einer erhöhten Informationsversorgung von Stakeholdern im Rahmen des Architekturmanagements beiträgt. Die Zielsetzung wurde durch die Entwicklung des Generischen Sichtenkonzepts als Lösungsansatz und die Bearbeitung der damit verbunden Forschungsfragen erreicht. Im zweiten Kapitel wurden die Grundlagen der vorliegenden Arbeit erarbeitet und präzisiert. Mit der Betrachtung des Informationsmanagements, der Architekturthematik und der computergestützten Visualisierung wurden ein Bezugsrahmen und der für die Arbeit wichtige Begriffsapparat geschaffen. Im Mittelpunkt der Betrachtungen des dritten Kapitels stand das Paradigma serviceorientierter Architekturen. Zunächst wurde ein Überblick über die Grundlagen serviceorientierter Architekturen gegeben. Der anschließende Fokus lag auf den Bestandteilen und Ebenen serviceorientierter Architekturen, der SOA-Governance und SOA-Rollen, aus denen später die erforderlichen Prämissen für das Generische Sichtenkonzept abgeleitet werden konnten. Im vierten Kapitel wurde die Komplexität der Entwicklung und des Managements betrieblicher Anwendungssysteme untersucht. Dazu wurden zunächst Diskussionen in der Literatur aufgegriffen und thematisiert. Im Anschluss daran hat der Autor sich mit dem Komplexitätsverständnis unterschiedlicher wissenschaftlicher Disziplinen und Theorien auseinandergesetzt, wobei die soziologische Systemtheorie, systemische Denkansätze und die ManagementKybernetik im Mittelpunkt der Betrachtungen standen. Des Weiteren wurde die Komplexität im Rahmen der Softwareevolution und in Bezug auf softwaretechnische Systeme betrachtet. Die Darstellung der Ergebnisse der Untersuchungen erfolgte in einem Zwischenfazit. Darin wurde die allgemeine Theorie sozialer Systeme Luhmanns als Erklärungsansatz für die Konstitution sozialer Systeme im Kontext der Entwicklung und des Managements betrieblicher Anwendungssysteme und der damit verbundenen Komplexität herangezogen. Aufbauend auf diesen Erkenntnissen erfolgten die Identifikation und Diskussion verschiedener Problem- und Fragestellungen bezüglich der Informationsverarbeitung und Informationsversorgung im Rahmen der Entwicklung und des Managements betrieblicher Anwendungssysteme. T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4_8, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

224

Schlussbetrachtung

Im fünften Kapitel wurden die Problem- und Fragestellungen des vierten Kapitels aufgegriffen, um sie im Kontext des Architekturmanagements zu vertiefen und in Bezug auf die Verwendung bestehender Sichtenkonzepte näher zu untersuchen. Dazu erfolgte unter Berücksichtigung des ISO/IEC 42010 IEEE Std 1471-2000-Standards zunächst eine Einführung in die Architekturbeschreibung und Architekturdokumentation softwareintensiver Systeme. Anschließend wurden Sichtenkonzepte bzw. Sichtenmodelle aus dem Bereich der Software- und Unternehmensarchitektur sowie serviceorientierter Architekturen vorgestellt. Die abschließenden Untersuchungen haben gezeigt, dass die bestehenden Sichtenkonzepte im Rahmen von Informationsverarbeitungsprozessen Defizite aufweisen und somit die Betrachtung kontextspezifischer Aspekte im Laufe der Evolution eines Systems nur unzureichend unterstützen. Die Ergebnisse der Untersuchungen des vierten und fünften Kapitels bildeten im sechsten Kapitel den Ausgangspunkt für die Entwicklung des Generischen Sichtenkonzepts, mit dem ein Ansatz zur Erzeugung kontextspezifischer Sichten auf SOA-basierte Systeme erarbeitet wurde. Den Kern des Konzepts stellt das Generische Sichtenmodell dar, mit dem das notwendige Wissen zur Erzeugung Generischer Sichten strukturiert und integriert wurde. Dazu erfolgte eine Unterteilung des Modells in vier Hauptbereiche, in denen die Konzepte zur Abbildung von Stakeholder-Concerns, die Verwaltung und Analyse von Daten und Metadaten, die Erzeugung spezifischer Kontexte und die Darstellung bzw. Visualisierung der erzeugten Kontexte beschrieben und festgelegt wurden. Durch die Erstellung eines 3-D-Entwurfs konnte eine Diskussionsgrundlage geschaffen werden, um die Möglichkeiten dreidimensionaler Darstellungen als Visualisierungsansatz für Generische Sichten im Kontext serviceorientierter Architekturen näher zu erörtern. Des Weiteren wurde die Verwendung des Generischen Sichtenkonzepts aus einer Prozessperspektive diskutiert und Potenziale für eine kontinuierliche Verbesserung der einzelnen Bestandteile durch Rückkopplungen in den Prozessschritten angeführt. Abschließend wurde das Generische Sichtenkonzept im Zusammenhang mit dem im ISO/IEC 42010 IEEE Std 1471-2000-Standard definierten Framework betrachtet und ein Vorschlag zur Integration des Konzepts mit dem Framework erarbeitet. Kapitel 7 umfasste den Entwurf und die Implementierung eines Prototyps, der im Rahmen dieser Forschungsarbeiten als Proof of concept entwickelt wurde und durch seine Konfigurationsmöglichkeiten ein Instrument zur Verfügung stellt, mit dem das Generische Sichtenkonzept in konkreten Anwendungskontexten instanziiert werden kann. Die Überprüfung des Generischen Sichtenkonzepts erfolgte unter Verwendung des Prototyps auf Basis unterschiedlicher Szenarien. Zwei dieser Szenarien wurden abschließend vorgestellt und die entsprechenden Generischen Sichten präsentiert.

Reflexion der Arbeit aus Sicht der zugrunde gelegten Forschungsmethodik

8.2

225

Reflexion der Arbeit aus Sicht der zugrunde gelegten Forschungsmethodik

Im Folgenden wird die Arbeit anhand der einzelnen Aktivitäten der ausgewählten Forschungsmethode (siehe Kapitel 1.3) reflektiert. Da bei der Reflexion lediglich eine andere Perspektive – die des Prozessmodells der Forschungsmethode – auf die Arbeit eingenommen wird, treten teilweise inhaltliche Redundanzen mit der zuvor dargelegten Zusammenfassung auf. Mit der gewählten Forschungsmethode konnten die Forschungsfragen beantwortet und die Zielsetzung erfüllt werden. Die Problemstellung und deren Relevanz wurden im Laufe der Arbeit sukzessiv herausgearbeitet. Die Identifikation und Motivation der Problemstellung erfolgte zunächst durch das Aufgreifen von Diskussionen in Wissenschaft und Praxis. Durch die Erklärung der Komplexitätsproblematik bei der Entwicklung und dem Management betrieblicher Anwendungssysteme wurde dann das notwendige Verständnis geschaffen, um Rückschlüsse auf spezifische Problem- und Fragestellungen im Kontext des Architekturmanagements und in Bezug auf die Verwendung bestehender Sichtenkonzepte treffen zu können. Dabei wurden Problemstellungen bezüglich der Informationsgewinnung und -verarbeitung identifiziert, die sich im Laufe der Architekturevolution durch die hohe Varietät multidimensionaler Interessen unterschiedlicher System/Umwelt-Konstellationen sowie die Eigendynamik und die damit verbundenen Wechselwirkungen komplexer sozialer Systeme ergeben. Die Zielsetzung der Arbeit bestand in der Entwicklung eines Konzepts, das die Erzeugung kontextspezifischer Sichten auf SOA-basierte Systeme ermöglicht und somit zu einer erhöhten Informationsversorgung von Stakeholdern sowie einer besseren Informationsverarbeitung – insbesondere in Bezug auf Aspekte der Kommunikation – beiträgt. Eine zentrale Herausforderung der Konzeptentwicklung lag darin, die unterschiedlichen Teilkonzepte unter Berücksichtigung der Eigenschaften und Ansprüche komplexer sozialer Systeme zu gestalten, zu strukturieren und zu integrieren und bereits etablierte Konzepte im Rahmen eines nachhaltigen Architekturmanagements und bei der Beherrschung von Komplexität zu ergänzen und zu unterstützen. Als Artefakte wurden das Generische Sichtenkonzept und ein Proof of concept-Prototyp entworfen und entwickelt. Das Generische Sichtenkonzept beinhaltet ein Modell, das aus vier Kernbereichen besteht, mit denen Stakeholder-Concerns abgebildet, Daten und Metadaten verwaltet und analysiert, spezifische Kontexte erzeugt und die Inhalte der erzeugten Kontexte visualisiert und dargestellt werden können. Für die Ausgestaltung der einzelnen Teilbereiche wurde bereits vorhandenes Wissen aus der Literatur herangezogen und unter Berücksichtigung der definierten Zielsetzung, Prämissen und Anforderungen in das Generische Sichtenmodell integriert. Eine wichtige Bedeutung bei dem Entwurf des Modells und seiner Teilbe-

226

Schlussbetrachtung

reiche kam der Auswahl des Abstraktionsniveaus zu. Um einem allgemeingültigen Anspruch Rechnung tragen zu können, wurde auf eine Konkretisierung bestimmter Aspekte innerhalb des Konzepts (Spezifikation der Dimensionen und Dimensionsausprägungen, Formalisierung der Analysen, Definition der Daten- und Metadatenverwaltung, Spezifikation der Informationsmodelle, Auswahl spezifischer Notationen zur Darstellung) verzichtet. Gleichzeitig wurde damit ein Gestaltungsspielraum bezüglich der Teilkonzepte mit Blick auf weitere Forschungsarbeiten geschaffen. Das Konzept liefert aber verschiedene Vorschläge und Ansatzpunkte für Gestaltungsmöglichkeiten, um konkrete Lösungen in spezifischen Anwendungsszenarien entwickeln zu können. Für den Darstellungsbereich des Generischen Sichtenmodells wurden im Rahmen der Konzeptentwicklung die Möglichkeiten dreidimensionaler Darstellungen als Visualisierungsansatz auf Basis eines 3-D-Entwurfs erörtert und diskutiert. Darüber hinaus wurde der Einsatz Generischer Sichten aus einer Prozessperspektive betrachtet und auf die Potenziale von Rückkopplungseffekten für eine kontinuierliche Verbesserung der einzelnen Prozessbestandteile eingegangen. Die Betrachtung des Generischen Sichtenmodells im Zusammenhang mit dem Framework des ISO/IEC 42010 IEEE Std 1471-2000-Standards hat gezeigt, dass sich das Generische Sichtenkonzept mit vorhandenen Ansätzen integrieren lässt. Somit können bereits angewandte Konzepte um das Generische Sichtenkonzept erweitert werden, ohne diese dabei maßgeblich modifizieren oder gar verwerfen zu müssen. Mit der Entwicklung des Prototyps konnte die technische Machbarkeit des Generischen Sichtenkonzepts überprüft werden. Darüber hinaus erlaubt es der Prototyp, Aussagen über den Einsatz und Nutzen des Generischen Sichtenkonzepts in konkreten Anwendungsszenarien zu treffen. Diese können einen wichtigen Beitrag zur Verfeinerung der Teilkonzepte in weitere Iterationen leisten. Die verschiedenen Konfigurationsmöglichkeiten des Prototyps schaffen die notwendige Flexibilität, um das Generische Sichtenkonzept an spezifische Anwendungskontexte anzupassen. Abhängig von der Ausprägungsform und den Eigenschaften einer serviceorientierten Architektur im Unternehmen kann der Prototyp bspw. mit unterschiedlichen Instanzen des Dimensions- und Regelsystems oder verschiedenen Informationsmodellen und Repositories betrieben werden. Das Generische Sichtenkonzept und der Prototyp wurden im Rahmen von Workshops und Präsentationen mit Unternehmensvertretern (anwendende Unternehmen und Werkzeughersteller) vorgestellt und demonstriert. Dabei handelte es sich um Vertreter von Unternehmen aus der Banken-, Versicherungs- und Telekommunikationsbranche sowie um Vertreter großer Werkzeughersteller und IT-Dienstleister. Die Relevanz der Problemstellung und des Lösungsansatzes für die Praxis wurde durch die verschiedenen Teilnehmer bestätigt. Bspw. wurde darauf hingewiesen, dass sich zahlreiche Fragestellungen in Bezug auf die Systemlandschaften eines Unternehmens mit gängigen Lösungen nicht oder nur schwer beantworten las-

Ausblick

227

sen. Dies betrifft vor allem Fragestellungen, die die Schnittstellen der Lebenszyklusphasen und somit unterschiedlicher Rollen aus Fachbereichen und IT betreffen. Gleichzeitig muss aber auch angemerkt werden, dass teilweise größere Anstrengungen unternommen werden müssten, um die entsprechenden Vorrausetzungen für den Einsatz des Generischen Sichtenkonzepts zu schaffen. Nach Auffassung des Autors sollten solche Investitionen jedoch auch unabhängig von der Verwendung des Generischen Sichtenkonzepts erfolgen, um die Nachhaltigkeit der Systeme sicherstellen zu können. Die Evaluation erfolgte anhand von Szenarien, die auf Basis der verwendeten Literatur und unter Berücksichtigung des Feedbacks aus der Demonstration abgeleitet wurden. Am Beispiel zweier ausgewählter Szenarien wurde der Nutzen des Generischen Sichtenkonzepts gegenüber vorhandenen Sichten dargestellt. Dazu wurden die vier identifizierten Fälle des Überdeckungsverhältnisses von relevanten Aspekten und bereits dokumentierter Sichten herangezogen und der Mehrwert des Generischen Sichtenkonzepts beim Eintreten dieser Fälle beschrieben. Der Mehrwert Generischer Sichten liegt vor allem in einer Erhöhung der Informationsversorgung und einer Verbesserung der Informationsverarbeitung, da kontextspezifische Aspekte unter Berücksichtigung der Relevanzkriterien von Stakeholder-Concerns „just in time“ und mit entsprechenden Darstellungen zur Verfügung gestellt werden können. Eine Effizienzsteigerung in Bezug auf Entwicklungs- und Managementaktivitäten ist zum aktuellen Zeitpunkt schwer nachzuweisen. Für einen Nachweis müssten die Aufwände einer systematischen und zielgerichteten Extraktion, Transformation und Erfassung von Daten den Aufwänden einer manuellen Sichtenerstellung auf Basis von Recovery-Aktivitäten gegenübergestellt werden. Sofern die Voraussetzungen für den Einsatz des Generischen Sichtenkonzepts erfüllt sind, lässt sich eine Effizienzsteigerung aber im hohen Automatisierungsgrad des Konzepts begründen. Darüber hinaus gestaltet es sich schwierig, Aussagen zur Akzeptanz des Generischen Sichtenkonzepts zu treffen, da die dazu notwendigen Erkenntnisse nur im praktischen Einsatz in einem realen Umfeld gewonnen werden können. Die Ergebnisse der Forschungsaktivitäten werden mit der Veröffentlichung der vorliegenden Arbeit kommuniziert. Einzelne Teilergebnisse wurden zuvor in wissenschaftlichen Beiträgen (Eicker et al. 2007a; Eicker et al. 2007b; Eicker et al. 2008; Spies und Hofmann 2010) publiziert. 8.3

Ausblick

Die vorgestellten Ergebnisse eröffnen unterschiedliche Möglichkeiten für zukünftige Forschungsarbeiten. Als Optionen ergeben sich weitere Evaluationen und Überprüfungen, Erweiterungsmöglichkeiten sowie die Übertragbarkeit des Generischen Sichtenkonzepts auf andere Forschungs- und Anwendungsbereiche.

228

Schlussbetrachtung

Die Ergebnisse sollten weiteren Evaluationen und Überprüfungen unterworfen werden, da diese einen wichtigen Beitrag leisten können, um zusätzliche Erkenntnisse über die Wirksamkeit des Generischen Sichtenkonzepts und dessen Teilkonzepte zu gewinnen. Auf Basis solcher Erkenntnisse ließen sich die Teilkonzepte in weiteren Iterationen des Forschungsprozesses verfeinern. Bezüglich des Darstellungsbereichs im Generischen Sichtenmodell könnten bspw. auf Basis von Experimenten Aussagen darüber getroffen werden, wie sich die Verwendung unterschiedlicher Darstellungsformen und Notationen auf die Kognitionsprozesse der Stakeholder auswirkt. Darüber hinaus wäre die Durchführung von Fallstudien denkbar, um die Akzeptanz des Generischen Sichtenkonzepts im praktischen Einsatz beurteilen zu können. Ferner könnte im Rahmen von Fallstudien untersucht werden, ob sich bei der Verwendung Generischer Sichten bestimmte Verhaltensmuster bilden, mit denen bspw. Rückschlüsse auf die Genauigkeit und Vollständigkeit der Daten- und Metadatenerfassung, die Auswirkungen auf die Kommunikationsprozesse oder die Vorzüge bestimmter Darstellungen getroffen werden können. Die Durchführung von Experimenten und Fallstudien gestaltet sich aus einer forschungstheoretischen und pragmatischen Sicht allerdings schwierig, da die Aussagefähigkeit der Ergebnisse von zahlreichen Einflussfaktoren abhängt. So müssten vor allem Vergleichskriterien in Bezug auf die Entwicklungs- und Managementprozesse, die Unternehmenskultur, den Kenntnisstand und die Fähigkeiten der Stakeholder sowie die Eigenschaften bestehender Anwendungslandschaften herangezogen werden. Die Erweiterungsmöglichkeiten des Generischen Sichtenkonzepts beziehen sich insbesondere auf den Aspekt der Zeit. Zwar lassen sich Generische Sichten für unterschiedliche Systemzustände erzeugen, eine Betrachtung von Veränderungen zwischen Systemzuständen und entsprechender Deltas innerhalb eines vorgegebenen Zeitraums wird bislang jedoch nicht berücksichtigt. Somit ließen sich bspw. zurückliegende Entscheidungen und die davon betroffenen Strukturveränderungen entlang einer Zeitachse analysieren. Die Erweiterungen könnten an den Teilkonzepten innerhalb der Teilbereiche des Generischen Sichtenmodells anknüpfen, da die zeitlichen Aspekte sowohl bei der Abbildung von Concerns, der Verwaltung und Analyse der Daten und Metadaten als auch bei der Darstellung berücksichtigt werden müssten. Auch in Bezug auf den Prototyp ergeben sich unterschiedliche Erweiterungsmöglichkeiten. So wäre es bspw. denkbar, einen Generischen Sichten-Server zu implementieren, der es mehreren Benutzern ermöglicht, gleichzeitig mit einer erzeugten Sicht zu interagieren. Dies wäre vergleichbar mit Computerspielen, in denen mehrere Benutzer gleichzeitig einer virtuellen Welt beitreten können. Die entsprechenden Technologien zur Implementierung eines solchen Servers werden durch das verwendete Computerspiele-Framework XNA bereits zur Verfügung gestellt. Des Weiteren ließen sich durch Erweiterungen des Prototyps Modifikationen an den Elementen und deren Abhängigkeiten vornehmen, wodurch eine direkte Manipulation der

Ausblick

229

Daten und Metadaten im Repository zur Verfügung stände. Diesbezüglich müssten jedoch umfangreiche Untersuchungen erfolgen, wie die Synchronisierung und damit die Konsistenz der Daten und Metadaten – vor allem der Daten, die aus Artefakten extrahiert wurden – sichergestellt werden kann. Eine Übertragbarkeit des Generischen Sichtenkonzepts ist insbesondere in Bezug auf weitere Architekturdisziplinen und Architekturtypen vorstellbar. Für den Bereich der Unternehmensarchitektur wurden dahingehend gemeinsam mit der Forschungsgruppe Wirtschaftsinformatik und Unternehmensmodellierung der Universität Duisburg-Essen bereits erste Untersuchungen angestellt. Dazu wurden Modellbestandteile unterschiedlicher Diagrammtypen aus dem sogenannten MEMOCenter-Protoyp36 in eine dem Generischen Sichten-Prototyp konforme Graphenstruktur exportiert. Gleichzeitig wurden am Generischen Sichten-Prototyp Modifikationen und Erweiterungen vorgenommen, so dass nach dem Import der Graphenstruktur eine Komposition der unterschiedlichen Modellperspektiven in Form einer dreidimensionalen Darstellung erzeugt werden konnte. Weitere Berührungspunkte bildet das Generische Sichtenkonzept mit dem Forschungsbereich des Architekturwissens. Erste Untersuchungen wurden diesbezüglich von Schwittek mit der Ableitung von Implikationen für die Gestaltung von Softwarewerkzeugen zur Unterstützung der computervermittelten Kommunikation von Architekturwissen unternommen (Schwittek 2009). Die Implikationen wurden als Grundlage herangezogen, um den Prototyp und das Generische Sichtenkonzept unter dem Gesichtspunkt der Unterstützung der Kommunikation von Architekturwissen zu evaluieren. Dabei wurde aufgezeigt, inwieweit das Generische Sichtenkonzept und der Prototyp die Implikationen bereits berücksichtigen und welche Erweiterungsmöglichkeiten sich ableiten lassen.

36

MEMOCenter ist der Prototyp eines Werkzeugs zur Unternehmensmodellierung, der im Rahmen des MEMOCenterNG Projekts (siehe http://www.wi-inf.uni-duisburg-essen.de/FGFrank/index.php?lang=de&&group Id=1&&contentType=Project&&projId=19) entwickelt wird und die Sprachen der MEMO-Methode (vgl. (Frank 1994a; Frank 1995a)) anwendbar macht.

Literatur Abramovitz R, von Foerster H (1995) Cybernetics of Cybernetics: or, the Control of Control and the Communication of Communication, 2. Aufl. Future Systems, Inc. Aier S, Riege C, Winter R (2008) Unternehmensarchitektur – Literaturüberblick und Stand der Praxis. WIRTSCHAFTSINFORMATIK 50(4):292-304. doi:10.1365/s11576008-0062-9 Allen P (2006) Service Orientation: Winning Strategies and Best Practices, 1. Aufl. Cambridge University Press, Cambridge Anonym (2006) Duden - Das Herkunftswörterbuch. Etymologie der deutschen Sprache, 4. Aufl. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim Anonym (2005) Brockhaus - Die Enzyklopädie: in 30 Bänden, 21. Aufl. F.A. Brockhaus GmbH, Leipzig, Mannheim Arsanjani A (2004) Service-Oriented Modeling and Architecture: How to Identify, Specify, and Realize Services for your SOA. http://www.ibm.com/developerworks/web services/library/ws-soa-design1/. Abruf am 2010-01-06 Arsanjani A, Zhang L, Ellis M, Allam A, Channabasavaiah K (2007) S3: A Service-Oriented Reference Architecture. IT Professional 9(3):10-17. doi:10.1109/MITP.2007.53 Arsanjani A, Booch G, Boubez T, Brown PC, Chappell D, deVadoss J, Erl T, Josuttis N, Krafzig D, Little M, Loesgen B, Manes AT, McKendrick J, Ross-Talbot S, Tilkov S, Utschig-Utschig C, Wilhelmsen H (2009) SOA Manifesto. http://soa-manifesto.org/. Abruf am 2009-12-02 Arsanjani A, Zhang L, Ellis M, Allam A, Channabasavaiah K (2007) Design an SOA Solution Using a Reference Architecture: Improve your Development Process Using the SOA Solution Stack. http://www.ibm.com/developerworks/library/ar-archtemp/. Abruf am 2010-01-06 Ashby WR (1956) An Introduction to Cybernetics. Chapman & Hall, London Balzer M, Deussen O (2005) Exploring Relations within Software Systems Using Treemap Enhanced Hierarchical Graphs. In: Proceedings of the 3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT 2005), Budapest Balzer M, Noack A, Deussen O, Lewerentz C (2004) Software Landscapes: Visualizing the Structure of Large Software Systems. In: Symposium on Visualization (VisSym 2004), Konstanz

T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

232

Literatur

Balzer Y (2004) Improve your SOA Project Plans: Strong Governance Principles Ensure a Successful Outcome. http://www.ibm.com/developerworks/webservices/library/wsimprovesoa/. Abruf am 2009-08-08 Bandte H (2007) Komplexität in Organisationen: Organisationstheoretische Betrachtungen und agentenbasierte Simulation, 1. Aufl. Deutscher Universitäts-Verlag, Wiesbaden Basili VR (1979) Quantitative Software Complexity Models: A Panel Summary. In: Workshop on Quantitative Software Models for Reliability, Complexity & Cost, Kiamesha Lake, NY Bass L, Clements P, Kazman R (2003) Software Architecture in Practice, 2. Aufl. AddisonWesley, Boston Bateson G (2000) Steps to an Ecology of Mind, 1. Aufl. University of Chicago Press (Originally published by Ballantine, 1972), Chicago Bauer A, Günzel H (2008) Data-Warehouse-Systeme: Architektur, Entwicklung, Anwendung, 3. Aufl. dpunkt.verlag, Heidelberg Baumöl U (2009) Informationsmanagement - Kurseinheit 1: Grundlagen des Informationsmanagements. Kurs 41760: Informationsmanagement, FernUniversität in Hagen, Fakultät für Wirtschaftswissenschaft, Hagen Becker J (2008) Ein Plädoyer für die gestaltungsorientierte Wirtschaftsinformatik. In: Jung R, Myrach T (Hrsg) Quo vadis Wirtschaftsinformatik?. Gabler, Wiesbaden Becker J, Schütte R (2004) Handelsinformationssysteme - Domänenorientierte Einführung in die Wirtschaftsinformatik, 2. Aufl. Moderne Industrie, Frankfurt am Main Beer S (1995) Brain of the Firm, 2. Aufl. John Wiley & Sons, London, New York Beier D (2002) Informationsmanagement aus Sicht der Betriebswirtschaftslehre: Theoretische Ansätze und das Beispiel Mobile Business, 1. Aufl. Peter Lang, Frankfurt am Main Belter R, Ludwig A (2009) An Information Model for Managing Service Lifecycle Resources. In: Proceedings of the IEEE International Conference on Services Computing (SCC 2009), Bangalore Berghaus M (2004) Luhmann leicht gemacht. Eine Einführung in die Systemtheorie, 2. Aufl. UTB, Stuttgart Bertin J (1982) Graphische Darstellungen und die graphische Weiterverarbeitung der Information, 1. Aufl. de Gruyter, Berlin, New York Bertin J (1974) Graphische Semiologie. Diagramme, Netze, Karten. de Gruyter, Berlin, New York

Literatur

233

Bieberstein N, Bose S, Fiammante M, Jones K, Shah R (2005) Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap, 1. Aufl. IBM Press, Upper Saddle River, NJ Bischofberger W, Kühl J, Löffler S (2004) Sotograph - A Pragmatic Approach to Source Code Architecture Conformance Checking. In: Proceedings of the First European Workshop on Software Architecture (EWSA 2004), St Andrews Biske T (2008) SOA Governance, 1. Aufl. Packt Publishing Ltd., Birmingham BITKOM (2009) Service-orientierte Architekturen: Leitfaden und Nachschlagewerk, 2. Aufl. BITKOM, Berlin Bloomberg J (2007) The Value of SOA Governance. Whitepaper. ZapThink, LLC, Baltimore Boehm B, Port D (1999) When Models Collide: Lessons from Software Systems Analysis. IT Professional 1(1):49-56. doi:10.1109/6294.774794 Booch G, Maksimchuk RA, Engel MW, Young BJ, Conallen J, Houston KA (2007) ObjectOriented Analysis and Design with Applications, 3. Aufl. Addison-Wesley Professional, Upper Saddle River, NJ Bosch J (2004) Software Architecture: The Next Step. In: Proceedings of the First European Workshop on Software Architecture (EWSA 2004), St Andrews Bremermann HJ (1962) Optimization through Evolution and Recombination. In: Yovits MC, Jacobi GT, Goldstein GD (Hrsg) Self-Organizing Systems. Spartan Books, Washington, DC Brooks FP (1995) The Mythical Man-Month: Essays on Software Engineering, 2. Aufl. Addison-Wesley, Reading, MA Brown WA, Laird RG, Gee C, Mitra T (2008) SOA Governance: Achieving and Sustaining Business and IT Agility, 1. Aufl. IBM Press, Upper Saddle River, NJ Buckl S, Matthes F, Schweda CM (2009) A Viable System Perspective on Enterprise Architecture Management. In: Proceedings of the 2009 IEEE International Conference on Systems, Man, and Cybernetics (SMC 2009), San Antonio Buckl S (2005) Modell-basierte Transformationen von Informationsmodellen zum Management von Anwendungslandschaften. Diplomarbeit, Technische Universität München, Software Engineering for Business Information Systems (sebis), München Buckl S, Ernst AM, Lankes J, Matthes F (2008) Enterprise Architecture Management Pattern Catalog - Version 1.0. Technical Report TB 0801. Software Engineering for Business Information Systems (sebis), Technische Universität München, München

234

Literatur

Buckl S, Ernst AM, Lankes J, Matthes F, Schweda CM, Wittenburg A (2007) Generating Visualizations of Enterprise Architectures Using Model Transformations. Enterprise Modelling and Information Systems Architectures 2(2):3-13 Cadbury A (1992) The Financial Aspects of Corporate Governance (Cadbury Report). The Committee on the Financial Aspects of Corporate Governance and Gee and Co. Ltd., London Cai K, Cangussu JW, DeCarlo RA, Mathur AP (2003) An Overview of Software Cybernetics. In: Proceedings of the 11th Annual International Workshop on Software Technology and Engineering Practice (STEP 2003), Amsterdam Cai K, Chen TY, Tse TH (2002) Towards Research on Software Cybernetics. In: Proceedings of the 7th IEEE International Symposium on High Assurance Systems Engineering (HASE 2002), Tokyo Capilla R, Nava F (2007) Extending Software Architecting Processes with Decision-Making Activities. In: Proceedings of the Second IFIP TC 2 Central and East European Conference on Software Engineering Techniques (CEE-SET 2007), Poznan Card DN, Glass RL (1990) Measuring Software Design Quality, 1. Aufl. Prentice Hall, Englewood Cliffs, NJ Card SK, Mackinlay JD, Shneiderman B (1999) Information Visualization. In: Card SK, Mackinlay JD, Shneiderman B (Hrsg) Readings in Information Visualization: Using Vision to Think. Morgan Kaufmann, San Francisco Chamoni P, Gluchowski P (2006) Analytische Informationssysteme: Business IntelligenceTechnologien und -Anwendungen, 3. Aufl. Springer, Berlin, Heidelberg, New York Chen C (2004) Information Visualization: Beyond the Horizon, 2. Aufl. Springer, London Chen C, Härdle W, Unwin A (2008) Introduction. In: Chen C, Härdle W, Unwin A (Hrsg) Handbook of Data Visualization. Springer, Berlin, Heidelberg Cheng P, Lowe R, Scaife M (2001) Cognitive Science Approaches To Understanding Diagrammatic Representations. Artificial Intelligence Review 15(1-2):79-94. doi:10.1023/A:1006641024593 Clements P, Bachmann F, Bass L, Garlan D, Ivers J, Little R, Nord R, Stafford J (2002) Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional, Boston Clerc V, Lago P, van Vliet H (2008) The Architect's Mindset. In: Proceedings of the Third International Conference on Quality of Software Architectures (QoSA 2008), Medford, MA

Literatur

235

Conant RC, Ashby WR (1970) Every Good Regulator of a System Must Be a Model of that System. International Journal of Systems Science 1(2):89. doi:10.1080/0020772700 8920220 Curtis B, Sheppard SB, Milliman P, Borst MA, Love T (1979) Measuring the Psychological Complexity of Software Maintenance Tasks with the Halstead and McCabe Metrics. IEEE Transactions on Software Engineering 5(2):96-104. doi:10.1109/TSE.1979. 234165 de Boer R, Farenhorst R, Lago P, van Vliet H, Clerc V, Jansen A (2007) Architectural Knowledge: Getting to the Core. In: Proceedings of the Third International Conference on Quality of Software Architectures (QoSA 2007), Medford, MA DeMarco T, Lister T (1999) Wien wartet auf Dich!, 2. Aufl. Hanser Fachbuch, München, Wien Denford M, O'Neill T, Leaney J (2002) Architecture-based Visualisation of Computer Based Systems. In: Proceedings of the Ninth Annual IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS 2002), Lund Dern G (2009) Management von IT-Architekturen: Leitlinien für die Ausrichtung, Planung und Gestaltung von Informationssystemen, 3. Aufl. Vieweg, Wiesbaden Dern G (2006) Management von IT-Architekturen, 2. Aufl. Vieweg, Wiesbaden Diehl S (2007) Software Visualization, 1. Aufl. Springer, Berlin, Heidelberg Diehl S (2003) Softwarevisualisierung. Informatik-Spektrum 26(4):257-260. doi:10.1007/ s00287-003-0314-4 Diehl S (2002) Software Visualization: International Seminar Dagstuhl Castle, Germany, May 20–25, 2001 Revised Papers. Springer, Berlin, Heidelberg Dijkstra EW (1982) EWD 447: On the Role of Scientific Thought. In: Dijkstra EW (Hrsg) Selected Writings on Computing: a Personal Perspective. Springer, New York Dijkstra EW (1979) Programming Considered as a Human Activity. In: Yourdon EN (Hrsg) Classics in Software Engineering. Yourdon Press, Upper Saddle River, NJ Dörner D (2003) Die Logik des Mißlingens. Strategisches Denken in komplexen Situationen, 7. Aufl. Rowohlt Taschenbuch Verlag, Hamburg Dueñas JC, Capilla R (2005) The Decision View of Software Architecture. In: Proceedings of the 2nd European Workshop Software Architecture (EWSA 2005), Pisa Durst M, Daum M (2007) Erfolgsfaktoren serviceorientierter Architekturen. HMD - Praxis der Wirtschaftsinformatik 42(253):18-27

236

Literatur

Dwyer T (2001) Three Dimensional UML Using Force Directed Layout. In: Proceedings of the 2001 Asia-Pacific Symposium on Information Visualisation (APVis 2001), Sydney Ebert C (1995a) Complexity Traces: an Instrument for Software Project Management. In: Fenton N, Whitty R, Lizuka Y (Hrsg) Software Quality Assurance and Measurement: Worldwide Perspective. International Thomson Computer Press, London Ebert C (1995b) Tracing Complexity Through the Software Process. In: Proceedings of the First IEEE International Conference on Engineering of Complex Computer Systems (ICECCS'95), Ft. Lauderdale Egyed A (1999) Trace Observer: A Reengineering Approach to View Integration. USC-CSE99-517. Center for Software Engineering, University of Southern California, Los Angeles Eicker S, Jung R, Schwittek W, Spies T (2008) SOA Generic Views In the Eye of the Beholder. In: Proceedings of the IEEE Congress on Services (SERVICES 2008), Honolulu Eicker S, Spies T, Kahl C (2007a) Software Visualization in the Context of Service-Oriented Architectures. In: Proceedings of the 4th IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT 2007), Banff Eicker S, Spies T, Kahl C (2007b) Softwarevisualisierung im Kontext serviceorientierter Architekturen. ICB Research Report 13. Institut für Informatik und Wirtschaftsinformatik, Universität Duisburg-Essen, Essen Engels G, Hess A, Humm B, Juwig O, Lohmann M, Richter J (2008) Quasar Enterprise: Anwendungslandschaften serviceorientiert gestalten, 1. Aufl. dpunkt.verlag, Heidelberg Erl T (2007) SOA Principles of Service Design, 1. Aufl. Prentice Hall, Upper Saddle River, NJ Erl T (2005) Service-Oriented Architecture (SOA): Concepts, Technology, and Design, 1. Aufl. Prentice Hall, Upper Saddle River, NJ Esser M (2002) Komplexitätsbeherrschung in dynamischen Diskurswelten. Ein Metamodell zur Modellierung betrieblicher Informationssysteme, 1. Aufl. Josef Eul Verlag, Lohmar, Köln Estefan JA, Laskey K, McCabe FG, Thornton D (2009) OASIS Reference Architecture Foundation for Service Oriented Architecture Version 1.0. Committee Draft 02. OASIS Service Oriented Architecture Reference Model TC

Literatur

237

Everware-CBDI (2007) CBDI-SAE™ Meta Model for SOA Version 2. http://www.cbdi forum.com/public/meta_model_v2.php. Abruf am 2010-01-29 Favre JM (2001) GSEE: a Generic Software Exploration Environment. In: Proceedings of the 9th International Workshop on Program Comprehension (IWPC 2001), Toronto Fenton NE, Pfleeger SL (1998) Software Metrics: A Rigorous and Practical Approach, Revised, 2. Aufl. Course Technology, Boston Ferstl OK, Sinz EJ (2006) Grundlagen der Wirtschaftsinformatik, 5. Aufl. Oldenbourg, München Ferstl OK, Sinz EJ (1995) Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen. WIRTSCHAFTSINFORMATIK 37(3):209-220 Franck G, Sardesai M, Ware C (1995) Layout and Structuring Object Oriented Software in Three Dimensions. In: Proceedings of the 1995 Conference of the Centre for Advanced Studies on Collaborative Research (CASCON'95), Toronto Frank U (2007) Ein Vorschlag zur Konfiguration von Forschungsmethoden in der Wirtschaftsinformatik. In: Lehner F, Zelewski S (Hrsg) Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. GITO, Berlin Frank U (1995a) MEMO: Eine werkzeuggestützte Methode zum integrierten Entwurf von Geschäftsprozessen und Informationssystemen. In: König W (Hrsg) Wirtschaftsinformatik '95: Wettbewerbsfähigkeit, Innovation, Wirtschaftlichkeit, Heidelberg Frank U (1995b) MEMO: Objektorientierte Unternehmensmodellierung zum gemeinsamen Entwurf optimierter Geschäftsprozesse und hochintegrierter Anwendungssysteme. OBJEKTspektrum (6):43-47 Frank U (1994a) MEMO: A Tool Supported Methodology for Analyzing and (Re-) Designing Business Information Systems. In: Ege R, Singh M, Meyer B (Hrsg) Proceedings of the 14. International Conference on Technology of Object-Oriented Languages and Systems (TOOLS 14), Santa Barbara Frank U (1994b) Multiperspektivische Unternehmensmodellierung. Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung (zugleich Habilitationsschrift, Universität Marburg). Oldenbourg, München Freitag U (2001) Die Entwicklung der Theorie der Kartographie. In: Koch WG (Hrsg) Theorie 2000: Kartographische Bausteine. TU Dresden, Dresden Fröhlich M, Glasner K (2007) IT-Governance: Leitfaden für eine praxisgerechte Implementierung, 1. Aufl. Gabler, Wiesbaden

238

Literatur

Gabriel R, Beier D (2003) Informationsmanagement in Organisationen, 1. Aufl. Kohlhammer, Stuttgart Gil J, Kent S (1998) Three Dimensional Software Modelling. In: Proceedings of the 20th International Conference on Software Engineering (ICSE'98), Kyoto Glass RL (2002) Sorting out Software Complexity. Communications of the ACM 45(11):1921. doi:10.1145/581571.581584 Graþanin D, Matkoviü K, Eltoweissy M (2005) Software Visualization. Innovations in Systems and Software Engineering 1(2):221-230. doi:10.1007/s11334-005-0019-8 Grochla E (1975) Betriebliche Planung und Informationssysteme. Rowohlt, Reinbek Hafner M (2006) Entwicklung eines Zielsystems für ein systemisch-evolutionäres Management der IS-Architektur im Unternehmen. In: Schelp J, Winter R (Hrsg) Integrationsmanagement - Planung, Bewertung und Steuerung von Applikationslandschaften, 1. Aufl. Springer, Berlin, Heidelberg Hafner M, Schelp J, Winter R (2004) Architekturmanagement als Basis effizienter und effektiver Produktion von IT-Services. HMD - Praxis der Wirtschaftsinformatik 39(237):54-66 Hafner M, Winter R (2005) Vorgehensmodell für das Management der unternehmensweiten Applikationsarchitektur. In: Ferstl OK, Sinz EJ, Eckert S, Isselhorst T (Hrsg) Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety, Bamberg Halstead MH (1977) Elements of Software Science (Operating and Programming Systems Series). Elsevier Science Inc., New York Hamilton P (2008) Wege aus der Softwarekrise: Verbesserungen bei der Softwareentwicklung, 1. Aufl. Springer, Berlin, Heidelberg Hamilton P (2006) Dynaxity: Management von Dynamik und Komplexität im Softwarebau, 1. Aufl. Springer, Berlin, Heidelberg Hansen HR, Neumann G (2009) Wirtschaftsinformatik 1, 10. Aufl. UTB, Stuttgart Harrison W (1992) An Entropy-Based Measure of Software Complexity. IEEE Transactions on Software Engineering 18(11):1025-1029. doi:10.1109/32.177371 Harrison W, Magel K, Kluczny R, DeKock A (1982) Applying Software Complexity Metrics to Program Maintenance. IEEE Computer 15(9):65-79. doi:10.1109/MC.1982.165 4138 Hasenkamp U, Stahlknecht P (2004) Einführung in die Wirtschaftsinformatik, 11. Aufl. Springer, Berlin, Heidelberg, New York

Literatur

239

Hedin M (2007) SOA-Driven Organizational Change Management: A Market Trends and Vendor Landscape Analysis of Major Service Players to Address This Emerging Opportunity. IDC 204727. IDC, Framingham, MA Heinrich LJ, Heinzl A, Roithmayr F (2007) Wirtschaftsinformatik: Einführung und Grundlegung, 3. Aufl. Oldenbourg, München Heinrich LJ, Stelzer D (2009) Informationsmanagement: Grundlagen, Aufgaben, Methoden, 9. Aufl. Oldenbourg, München Heinzl A, König W, Hack J (2001) Erkenntnisziele der Wirtschaftsinformatik in den nächsten drei und zehn Jahren. WIRTSCHAFTSINFORMATIK 43(3):223-233 Henderson-Sellers B (1995) Object-Oriented Metrics: Measures of Complexity. Prentice Hall PTR, Upper Saddle River, NJ Henry S, Kafura D (1981) Software Structure Metrics Based on Information Flow. IEEE Transactions on Software Engineering 7(5):510-518. doi:10.1109/TSE.1981.231113 Herzum P, Sims O (2000) Business Components Factory: A Comprehensive Overview of Component-based Development for the Enterprise, 1. Aufl. John Wiley & Sons, New York Hesse W, Müller D, Ruß A (2008) Information, Information Systems, Information Society: Interpretations and Implications. Poiesis & Praxis: International Journal of Technology Assessment and Ethics of Science 5(3):159-183. doi:10.1007/s10202-008-00444 Heutschi R (2007) Serviceorientierte Architektur, 1. Aufl. Springer, Berlin, Heidelberg Hevner AR, March ST, Park J, Ram S (2004) Design Science in Information Systems Research. MIS Quarterly 28(1):75-105 Hopkins JF, Fishwick PA (2002) The rube Framework for Personalized 3-D Software Visualization. In: Diehl S (Hrsg) Revised Lectures on Software Visualization, International Seminar, Dagstuhl Castle Institute for Software Technology, University of Stuttgart (2006) Bauhaus - A Tool Suite for Program Understanding and Reverse Engineering. http://www.bauhaus-stuttgart.de/ bauhaus/presentation.pdf. Abruf am 2010-04-10 Irani P, Ware C (2003) Diagramming Information Structures Using 3D Perceptual Primitives. ACM Transactions on Computer-Human Interaction 10(1):1-19. doi:10.1145/ 606658.606659

240

Literatur

ISO/IEC, IEEE (2009) ISO/IEC/IEEE Draft Standard for Systems and Software Engineering Architecture description. IEEE Unapproved Draft Std ISO/IEC 42010 (IEEE P42010/D6). ISO/IEC, IEEE, Genf, Los Alamitos ISO/IEC, IEEE (2007) ISO/IEC 42010 IEEE Std 1471-2000: Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems, 1. Aufl. ISO/IEC, IEEE, Genf, Los Alamitos IT Governance Institute (2009) CobiT 4.1 Excerpt - Executive Summary. IT Governance Institute (ITIG), Rolling Meadows, IL IT Governance Institute (2003) IT Governance für Geschäftsführer und Vorstände. Zweite Ausgabe. IT Governance Institute, Rolling Meadows, IL Janich P (2006) Was ist Information? Kritik einer Legende, 1. Aufl. Suhrkamp, Frankfurt am Main Johannsen W, Goeken M (2007) Referenzmodelle für IT-Governance. Strategische Effektivität und Effizienz mit COBIT, ITIL & Co, 1. Aufl. dpunkt.verlag, Heidelberg Josuttis NM (2008) SOA in der Praxis, 1. Aufl. dpunkt.verlag, Heidelberg Jung R (2006) Architekturen zur Datenintegration: Gestaltungsempfehlungen auf der Basis fachkonzeptueller Anforderungen, 1. Aufl. Deutscher Universitäts-Verlag, Wiesbaden Kahl C (2007) Dynamische Visualisierung serviceorientierter Architekturen, 1. Aufl. Diplomica Verlag, Hamburg Kajko-Mattsson M, Lewis GA, Smith DB (2007) A Framework for Roles for Development, Evolution and Maintenance of SOA-Based Systems. In: Proceedings of the 2nd International Workshop on Systems Development in SOA Environments (SDSOA 2007), Minneapolis Kawalek P, Wastell D (1996) Organisational Design for Software Development: a Cybernetic Perspective. In: Proceedings of the 5th European Workshop on Software Process Technology (EWSPT'96), Nancy Kazman R, Carriere SJ (1998) View Extraction and View Fusion in Architectural Understanding. In: Proceedings of the Fifth International Conference on Software Reuse (ICSR'98), Victoria Kearney JP, Sedlmeyer RL, Thompson WB, Gray MA, Adler MA (1986) Software Complexity Measurement. Communications of the ACM 29(11):1044-1050. doi:10.1145/7538.7540

Literatur

241

Keller T, Tergan S (2005) Visualizing Knowledge and Information: An Introduction. In: Keller T, Tergan S (Hrsg) Knowledge and Information Visualization: Searching for Synergies. Springer, Berlin, Heidelberg Keller W (2007) IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen ITUnterstützung, 1. Aufl. dpunkt.verlag, Heidelberg Kemerer C (1995) Software Complexity and Software Maintenance: A Survey of Empirical Research. Annals of Software Engineering 1(1):1-22. doi:10.1007/BF02249043 Kennaley M (2008) "The 3+1 Views of Architecture (in 3D)": An Amplification of the 4+1 Viewpoint Framework. In: Proceedings of the 7th Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), Vancouver Kieser A, Ebers M (2006) Organisationstheorien, 6. Aufl. Kohlhammer, Stuttgart Klemm H (2003) Ein großes Elend. Informatik-Spektrum 26(4):267-273. doi:10.1007/ s00287-003-0316-2 Kneer G, Nassehi A (2000) Niklas Luhmanns Theorie sozialer Systeme: Eine Einführung, 4. Aufl. UTB, Stuttgart Knight C, Munro M (1999) Comprehension With[in] Virtual Environment Visualisations. In: Proceedings of the Seventh International Workshop on Program Comprehension (ICPC'99), Pittsburgh Koedinger KR, Anderson JR (1990) Abstract Planning and Perceptual Chunks: Elements of Expertise in Geometry. Cognitive Science 14(4):511-550. doi:10.1016/03640213(90)90008-K Kohnke O, Scheffler T, Hock C (2008) SOA-Governance - Ein Ansatz zum Management serviceorientierter Architekturen. WIRTSCHAFTSINFORMATIK 50(5):408-412. doi:10.1007/s11576-008-0082-5 Koschke R (2002) Software Visualization for Reverse Engineering. In: Diehl S (Hrsg) Revised Lectures on Software Visualization, International Seminar, Dagstuhl Castle Koschke R (2000) Atomic Architectural Component Recovery for Program Understanding and Evolution. Dissertation, Institut für Softwaretechnologie, Universität Stuttgart, Stuttgart Krafzig D, Banke K, Slama D (2007) Enterprise SOA: Best Practices für Serviceorientierte Architekturen - Einführung, Umsetzung, Praxis, 1. Aufl. Mitp-Verlag, Heidelberg Krafzig D, Banke K, Slama D (2004) Enterprise SOA: Service-Oriented Architecture Best Practices (The Coad Series). Prentice Hall PTR, Upper Saddle River, NJ

242

Literatur

Krcmar H (2005) Informationsmanagement, 4. Aufl. Springer, Berlin, Heidelberg Krcmar

H (1990) Bedeutung und Ziele von WIRTSCHAFTSINFORMATIK 32(5):395-402

Informationssystemarchitekturen.

Kruchten PB, Obbink H, Stafford J (2006) The Past, Present, and Future for Software Architecture. IEEE Software 23(2):22-30. doi:10.1109/MS.2006.59 Kruchten PB (1995) The 4+1 View Model of Architecture. IEEE Software 12(6):42-50. doi:10.1109/52.469759 Lago P, Avgeriou P, Capilla R, Kruchten PB (2008) Wishes and Boundaries for a Software Architecture Knowledge Community. In: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), Vancouver Lange C (2006) Entwicklung und Stand der Disziplinen Wirtschaftsinformatik und Information Systems. ICB Research Report 4. Institut für Informatik und Wirtschaftsinformatik, Universität Duisburg-Essen, Essen Lankes J, Matthes F, Wittenburg A (2007) Exkurs Softwarekartographie. In: Keller W (Hrsg) IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen ITUnterstützung, 1. Aufl. dpunkt.verlag, Heidelberg Lankes J, Matthes F, Wittenburg A (2005) Softwarekartographie: Systematische Darstellung von Anwendungslandschaften. In: Ferstl OK, Sinz EJ, Eckert S, Isselhorst T (Hrsg) Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety, Bamberg Lankhorst M (2009) Enterprise Architecture at Work: Modelling, Communication and Analysis, 2. Aufl. Springer, Berlin, Heidelberg Lehman MM (1996a) Feedback in the Software Evolution Process. Information and Software Technology 38(11):681-686. doi:10.1016/0950-5849(96)01121-4 Lehman MM (1996b) Laws of Software Evolution Revisited. In: Proceedings of the 5th European Workshop on Software Process Technology (EWSPT '96), Nancy Lehman MM, Ramil JF (2003) Software evolution - Background, Theory, Practice. Information Processing Letters 88(1-2):33-44. doi:10.1016/S0020-0190(03)00382-X Lehman MM, Ramil JF (2002) Software Evolution and Software Evolution Processes. Annals of Software Engineering 14(1):275-309. doi:10.1023/A:1020557525901 Lei D, Medvidovic N (2001) Focus: a Light-Weight, Incremental Approach to Software Architecture Recovery and Evolution. In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA 2001), Amsterdam

Literatur

243

Lewis GA, Morris E, Simanta S, Wrage L (2008) Effects of Service-Oriented Architecture on Software Development Lifecycle Activities. Software Process: Improvement and Practice 13(2):135-144. doi:10.1002/spip.372 Lilienthal C (2008) Komplexität von Softwarearchitekturen, Stile und Strategien. Dissertation, Universität Hamburg, Hamburg Lohse GL, Min D, Olson JR (1995) Cognitive Evaluation of System Representation Diagrams. Information & Management 29(2):79-94. doi:10.1016/0378-7206(95)00024Q Longepe C (2003) The Enterprise Architecture It Project: The Urbanisation Paradigm. Elsevier Science & Technology, Amsterdam Luhmann N (2009) Einführung in die Systemtheorie, 5. Aufl. Carl-Auer-Systeme, Heidelberg Luhmann N (2006) Organisation und Entscheidung, 2. Aufl. VS Verlag, Wiesbaden Luhmann N (1997) Die Gesellschaft der Gesellschaft: 2 Bde., 1. Aufl. Suhrkamp, Frankfurt am Main Luhmann N (1987) Soziale Systeme: Grundriß einer allgemeinen Theorie, 1. Aufl. Suhrkamp, Frankfurt am Main MacKenzie CM, Laskey K, McCabe F, Brown PF, Metz R (2006) OASIS Reference Model for Service Oriented Architecture 1.0. Official OASIS Standard. OASIS SOA Reference Model TC Mackinlay J (1986) Automating the Design of Graphical Presentations of Relational Information. ACM Transactions on Graphics 5(2):110-141. doi:10.1145/22949.22950 Maletic JI, Collard ML, Simoes B (2005) An XML Based Approach to Support the Evolution of Model-to-Model Traceability Links. In: Proceedings of the 3rd International Workshop on Traceability in Emerging Forms of Software Engineering (TEFSE'05), Long Beach Maletic JI, Marcus A, Feng L (2003) Source Viewer 3D (sv3D) - a Framework for Software Visualization. In: Proceedings of the 25th International Conference on Software Engineering (ICSE'03), Portland Malik F (2008) Strategie des Managements komplexer Systeme: Ein Beitrag zur Management-Kybernetik evolutionärer Systeme, 10. Aufl. Haupt, Bern Malinverno P (2006) Service-Oriented Architecture Craves Governance. G00135396. Gartner, Inc., Stamford, CT

244

Literatur

Manes AT (2009) SOA is Dead; Long Live Services. http://apsblog.burtongroup.com/2009/ 01/soa-is-dead-long-live-services.html. Abruf am 2009-10-03 March ST, Smith GF (1995) Design and Natural Science Research on Information Technology. Decision Support Systems 15(4):251-266. doi:10.1016/0167-9236(94)00041-2 Marcus A, Feng L, Maletic JI (2003) 3D Representations for Software Visualization. In: Proceedings of the 2003 ACM Symposium on Software Visualization (SoftVis'03), San Diego Marks EA, Bell M (2006) Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology, 1. Aufl. Wiley & Sons, Hoboken, NJ Martin W, Eckert J, Repp N (2009) SOA Check 2009. S.A.R.L Martin, TU Darmstadt, IT Research, Darmstadt Maruyama M (1963) The Second Cybernetics: Deviation-Amplifying Mutual Causal Processes. American Scientist 51:164-179 Masak D (2007) SOA? Serviceorientierung in Business und Software, 1. Aufl. Springer, Berlin, Heidelberg, New York Matthes F (2008) Softwarekartographie. Informatik-Spektrum 31(6):527-536. doi:10.1007/ s00287-008-0289-2 Maturana HR, Varela FJ (1990) Der Baum der Erkenntnis. Die biologischen Wurzeln des menschlichen Erkennens. Goldmann, München McCabe TJ (1976) A Complexity Measure. IEEE Transactions on Software Engineering 2(4):308-320. doi:10.1109/TSE.1976.233837 McCormick BH, DeFanti TA, Brown MD (1987) Visualization in Scientific Computing. Computer Graphics 21(6) Medvidovic N, Grünbacher P, Egyed A, Boehm BW (2003) Bridging Models Across the Software Lifecycle. Journal of Systems and Software 68(3):199-215. doi:10.1016/ S0164-1212(03)00063-3 Melcher J, Seese D (2008) Process Measurement: Insights from Software Measurement on Measuring Process Complexity, Quality and Performance. Fakultät für Wirtschaftswissenschaften, Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB), Universität Karlsruhe, Karlsruhe Melzer I (2007) Service-orientierte Architekturen mit Web Services. Konzepte - Standards Praxis, 2. Aufl. Spektrum Akademischer Verlag, München

Literatur

245

Mertens P, Back A, Becker J (2001) Lexikon der Wirtschaftsinformatik, 4. Aufl. Springer, Berlin, Heidelberg Mertens P, Ehrenberg D, Griese J (1998) Virtuelle Unternehmen und Informationsverarbeitung, 1. Aufl. Springer, Berlin, Heidelberg Mesarovic MD, Macko D, Takahara Y (1970) Theory of Hierarchical, Multilevel, Systems. Academic Press, New York, London Miller GA (1956) The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. Psychological Review 63(2):81-97. doi:10.1037/h0043158 Misra S, Misra AK (2007) Evaluation and Comparison of Cognitive Complexity Measure. SIGSOFT Software Engineering Notes 32(2):1-5. doi:10.1145/1234741.1234761 Misue K, Eades P, Lai W, Sugiyama K (1995) Layout Adjustment and the Mental Map. Journal of Visual Languages & Computing 6(2):183-210. doi:10.1006/jvlc.1995.1010 Moody D (2009) The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE Transactions on Software Engineering 35(6):756-779. doi:10.1109/TSE.2009.67 Müller S, Kuhn W, Meiler C, Petrov I, Jablonski S (2009) Integratives IT-Architekturmanagement. In: Reussner R, Hasselbring W (Hrsg) Handbuch der SoftwareArchitektur: Werkzeuge für Controlling und Management, 2. Aufl. dpunkt.verlag, Heidelberg Murer S, Worms C, Furrer FJ (2008) Managed Evolution. Informatik-Spektrum 31(6):537547. doi:10.1007/s00287-008-0290-9 Murphy GC, Notkin D, Sullivan KJ (2001) Software Reflexion Models: Bridging the Gap between Design and Implementation. IEEE Transactions on Software Engineering 27(4):364-380. doi:10.1109/32.917525 Naidoo R (2002) Corporate Governance: An Essential Guide for South African Companies, 1. Aufl. Double Storey Books, Cape Town Natis YV (2003) Service-Oriented Architecture Scenario. AV-19-6751. Gartner, Inc., Stamford, CT Niemann KD (2005) Von der Unternehmensarchitektur zur IT-Governance. Bausteine für ein wirksames IT-Management, 1. Aufl. Vieweg, Wiesbaden Novick L (2006) The Importance of Both Diagrammatic Conventions and Domain-Specific Knowledge for Diagram Literacy in Science: The Hierarchy as an Illustrative Case. In: Barker-Plummer D, Cox R, Swoboda N (Hrsg) Diagrammatic Representation and

246

Literatur

Inference, Proceedings of the 4th International Conference on Theory and Application of Diagrams (Diagrams 2006), Stanford Nunamaker J, Chen M, Purdin TDM (1991) Systems Development in Information Systems Research. Journal of Management Information Systems 7(3):89-106 OASIS (2007) Web Services Business Process Execution Language Version 2.0, OASIS Standard. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html. Abruf am 2010-02-23 OASIS (2004) UDDI Version 3.0.2, UDDI Spec Technical Committee Draft, Dated 20041019. http://uddi.org/pubs/uddi_v3.htm. Abruf am 2010-02-23 OECD (2004) OECD-Grundsätze der Corporate Governance 2004. OECD Publishing, Paris Office of Government Commerce (OGC) (2007) Service Strategy (ITIL V3). TSO (The Stationery Office), London OMG (2009) OMG Unified Modeling Language (OMG UML). http://www.uml.org/. Abruf am 2009-02-01 OMG (2004) IT Portfolio Management Facility (ITPMF), Working Document: 1.0 Beta 2 Specification. http://www.omg.org/technology/documents/domain_spec_catalog.htm#ITPM. Abruf am 2010-06-02 Österle H (1995) Business Engineering: Prozess- und Systementwicklung, 2. Aufl. Springer, Berlin, Heidelberg Österle H, Becker J, Frank U, Hess T, Karagiannis D, Krcmar H, Loos P, Mertens P, Oberweis A, Sinz EJ (2010) Memorandum zur gestaltungsorientierten Wirtschaftsinformatik. In: Österle H, Winter R, Brenner W (Hrsg) Gestaltungsorientierte Wirtschaftsinformatik: Ein Plädoyer für Rigour und Relevanz. Infowerk, Nürnberg Oviedo EI (1980) Control Flow, Data Flow, and Program Complexity. In: Proceedings of the Fourth International Computer Software and Applications Conference (COMPSAC'80), Chicago Panas T, Berrigan R, Grundy J (2003) A 3D Metaphor for Software Production Visualization. In: Proceedings of the Seventh International Conference on Information Visualization (IV'03), London Panas T, Lincke R, Löwe W (2005) Online-Configuration of Software Visualizations with Vizz3D. In: Proceedings of the 2005 ACM symposium on Software Visualization (SoftVis'05), St. Louis

Literatur

247

Papazoglou M, van den Heuvel W (2007) Service Oriented Architectures: Approaches, Technologies and Research Issues. The VLDB Journal 16(3):389-415. doi:10.1007/ s00778-007-0044-3 Parnas DL, Hoffman DM, Weiss DM (2001) Software Fundamentals: Collected Papers by David L. Parnas. Addison-Wesley, Boston Peffers K, Tuunanen T, Rothenberger MA, Chatterjee S (2008) A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems 24(3):45-77 Perry DE, Wolf AL (1992) Foundations for the Study of Software Architecture. SIGSOFT Software Engineering Notes 17(4):40-52. doi:10.1145/141874.141884 Petre M, Blackwell A, Green T (1998) Cognitive Questions in Software Visualisation. In: Stasko J, Domingue J, Brown MH, Price BA (Hrsg) Software Visualization: Programming as a Multimedia Experience. MIT Press, Cambridge Picot A, Maier M (1993) Interdependenzen zwischen betriebswirtschaftlichen Organisationsmodellen und Informationsmodellen. Information Management & Consulting 3:6-15 Picot A, Reichwald R, Wigand RT (2003) Die grenzenlose Unternehmung, 4. Aufl. Gabler, Wiesbaden Price B, Baecker R, Small I (1998) An Introduction to Software Visualization. In: Stasko J, Domingue J, Brown MH, Price BA (Hrsg) Software Visualization: Programming as a Multimedia Experience. MIT Press, Cambridge Putman JR (2000) Architecting with RM-ODP. Prentice Hall PTR, Upper Saddle River, NJ Rabin MO (1977) Complexity of Computations. Communications of the ACM 20(9):625-633. doi:10.1145/359810.359816 Rechenberg P (2003) Zum Informationsbegriff der Informationstheorie. Informatik-Spektrum 26(5):317-326. doi:10.1007/s00287-003-0329-x Reiss SP, Renieris M (2003) The BLOOM Software Visualization System. In: Zhang K (Hrsg) Software Visualization: From Theory to Practice. Kluwer Academic Publishers, Boston, Dordrecht, London Ricadela A (2006) The Dark Side of SOA. http://www.informationweek.com/news/ showArticle.jhtml?articleID=192501102. Abruf am 2010-04-23 Robertson GG, Mackinlay JD, Card SK (1991) Cone Trees: Animated 3D Visualizations of Hierarchical Information. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems: Reaching through Technology (CHI'91), New Orleans

248

Literatur

Robertson PK, De Ferrari L (1994) Systematic Approaches to Visualization: Is a Reference Model Needed? In: Rosenblum L, Earnshaw RA, Encarnacao J, Hagen H, Kaufman A, Klimenko S, Nielson G, Post F, Thalmann D (Hrsg) Scientific Visualization: Advances and Challenges. Academic Press, Los Alamitos Rosen M, Lublinsky B, Smith KT, Balcer MJ (2008) Applied SOA: Service-Oriented Architecture and Design Strategies, 1. Aufl. Wiley Publishing Inc., Indianapolis Rüter A, Schröder J, Göldner A (2006) IT-Governance in der Praxis, 1. Aufl. Springer, Berlin, Heidelberg Sanders K, Kianty A (2006) Organisationstheorien - Eine Einführung, 1. Aufl. VS Verlag, Wiesbaden Schauer C, Frank U (2007) Wirtschaftsinformatik und Information Systems: ein Vergleich aus wissenschaftstheoretischer Sicht. In: Lehner F, Zelewski S (Hrsg) Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. GITO, Berlin Scheer A (2001) ARIS - Modellierungs-Methoden, Metamodelle, Anwendungen, 4. Aufl. Springer, Berlin, Heidelberg Scheer A (1997) Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse, 7. Aufl. Springer, Berlin, Heidelberg Schekkerman J (2004) How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework, 2. Aufl. Trafford Publishing, Victoria Schelp J, Stutz M (2007) SOA-Governance. HMD - Praxis der Wirtschaftsinformatik 42(253):66-73 Schelp J, Winter R (2009) Management der Unternehmensarchitektur. In: Reussner R, Hasselbring W (Hrsg) Handbuch der Software-Architektur: Werkzeuge für Controlling und Management, 2. Aufl. dpunkt.verlag, Heidelberg Schulte WR (1996) "Service Oriented" Architectures, Part 2. SPA-200-127. Gartner, Inc., Stamford, CT Schulte WR, Natis YV (1996) "Service Oriented" Architectures, Part 1. SPA-ARCH-259. Gartner, Inc., Stamford, CT Schumann H, Müller W (2000) Visualisierung: Grundlagen und allgemeine Methoden, 1. Aufl. Springer, Berlin, Heidelberg, New York Schütte R, Rotthowe T, Holten R (2001) Data Warehouse Managementhandbuch: Konzepte, Software, Erfahrungen, 1. Aufl. Springer, Berlin, Heidelberg, New York

Literatur

249

Schwittek W (2009) Kommunikation von Architekturwissen - Implikationen für die Gestaltung unterstützender Software-Werkzeuge. Diplomarbeit, Lehrstuhl für Wirtschaftsinformatik und Softwaretechnik (Softec), Universität Duisburg-Essen, Essen Senge PM (2006) The Fifth Discipline: the Art and Practice of the Learning Organization. Doubleday/Currency, New York Shannon CE, Weaver W (1949) The Mathematical Theory of Communication. University of Illinois Press, Urbana Shao J, Wang Y (2003) A New Measure of Software Complexity Based on Cognitive Weights. Canadian Journal of Electrical and Computer Engineering 28(2):69-74. doi:10.1109/CJECE.2003.1532511 Shaw M, Garlan D (1996) Software Architecture: Perspectives on an Emerging Discipline, 1. Aufl. Prentice Hall, Upper Saddle River, NJ Simon HA (1996) The Sciences of the Artificial, 3. Aufl. MIT Press, Cambridge Simon HA (1969) The Sciences of the Artificial, 1. Aufl. MIT Press, Cambridge Sinz EJ (2002) Architektur von Informationssystemen. In: Rechenberg P, Pomberger G (Hrsg) Informatik-Handbuch, 3. Aufl. Hanser, München Sinz EJ (1996) Ansätze zur fachlichen Modellierung betrieblicher Informationssysteme. Entwicklung, aktueller Stand und Trends. In: Heilmann H, Heinrich LJ, Roithmayr F (Hrsg) Information Engineering, 1. Aufl. Oldenbourg, München Software Engineering betrieblicher Informationssysteme (sebis), Technischen Universität München (2010) SyCaTool - Software and System Cartography Tool. http://wwwmatthes.in.tum.de/wikis/sebis/sycatool. Abruf am 2010-04-13 Sommerville I (2004) Software Engineering, 7. Aufl. Addison Wesley, Boston Soni D, Nord RL, Hofmeister C (1995) Software Architecture in Industrial Applications. In: Proceedings of the 17th International Conference on Software Engineering (ICSE'95), Seattle Sowa JF, Zachman JA (1992) Extending and Formalizing the Framework for Information Systems Architecture. IBM Systems Journal 31(3):590-616 Spence R (2001) Information Visualization. Addison Wesley, Harlow, England Spies T, Hofmann T (2010) Usability eines 3D-Interfaces zur Visualisierung von Informationssystemlandschaften. In: Gesellschaft für Arbeitswissenschaft e.V. (GfA) (Hrsg) Neue Arbeits- und Lebenswelten gestalten, 56. Kongress der Gesellschaft für Arbeitswissenschaft (GfA 2010), Darmstadt

250

Literatur

Staples ML, Bieman JM (1998) 3-D Visualization of Software Structure. In: Zelkowitz MV (Hrsg) Advances in Computers. Academic Press, San Diego Starke G, Tilkov S (2007) SOA-Expertenwissen - Methoden, Konzepte und Praxis serviceorientierter Architekturen, 1. Aufl. dpunkt.verlag, Heidelberg Stasko JT (1992) Three-Dimensional Computation Visualization. Technical Report GITGVU-92-20. Graphics, Visualization, and Usability Center, College of Computing, Georgia Institute of Technology, Atlanta Stasko J, Domingue J, Brown MH, Price BA (1998) Software Visualization: Programming as a Multimedia Experience. MIT Press, Cambridge Steen MWA, Akehurst DH, ter Doest HWL, Lankhorst MM (2004) Supporting ViewpointOriented Enterprise Architecture. In: Proceedings of the Eighth IEEE International Enterprise Distributed Object Computing Conference (EDOC'04), Monterey Storey MD, Fracchia FD, Müller HA (1997) Cognitive Design Elements to Support the Construction of a Mental Model during Software Visualization. In: Proceedings of the Fifth International Workshop on Program Comprehension (IWPC'97), Dearborn, MI Strnadl C (2007) Bridging Architectural Boundaries Design and Implementation of a Semantic BPM and SOA Governance Tool. In: Proceedings of the Fifth International Conference on Service-Oriented Computing (ICSOC 2007), Wien Teubner RA (1999) Organisations- und Informationssystemgestaltung. Theoretische Grundlagen und integrierte Methoden. Deutscher Universitäts-Verlag, Wiesbaden Teyseyre AR, Campo MR (2009) An Overview of 3D Software Visualization. IEEE Transactions on Visualization and Computer Graphics 15(1):87-105. doi:10.1109/TVCG. 2008.86 The Open Group (2009a) SOA Reference Architecture (Draft 10). http://www.opengroup.org/ soa/projects/refarch.htm. Abruf am 2010-06-02 The Open Group (2009b) SOA Source Book. Van Haren Publishing, LK Zaltbommel, NL The Open Group (2009c) TOGAF Version 9 - The Open Group Architecture Framework (TOGAF), 9. Aufl. Van Haren Publishing, LK Zaltbommel, NL Tian J, Zelkowitz MV (1995) Complexity Measure Evaluation and Selection. IEEE Transactions on Software Engineering 21(8):641-650. doi:10.1109/32.403788 Tilkov S (2007) Roles in SOA Governance. http://www.infoq.com/articles/tilkov-soa-roles. Abruf am 2009-08-01

Literatur

251

Turban E, Aronson JE, Liang T, Sharda R (2006) Decision Support and Business Intelligence Systems, 8. Aufl. Prentice Hall, Upper Saddle River, NJ Tyree J, Akerman A (2005) Architecture Decisions: Demystifying Architecture. IEEE Software 22(2):19-27. doi:10.1109/MS.2005.27 Ulrich H, Probst GJB (1995) Anleitung zum ganzheitlichen Denken und Handeln. Ein Brevier für Führungskräfte, 4. Aufl. Haupt, Bern Vahs D (2003) Organisation: Einführung in die Organisationstheorie und -praxis, 4. Aufl. Schäfer-Poeschel, Stuttgart van Deursen A, Hofmeister C, Koschke R, Moonen L, Riva C (2004) Symphony: ViewDriven Software Architecture Reconstruction. In: Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA'04), Oslo Ven J, Jansen A, Nijhuis J, Bosch J (2006) Design Decisions: The Bridge between Rationale and Architecture. In: Dutoit AH, McCall R, Mistrik I, Paech B (Hrsg) Rationale Management in Software Engineering. Springer, Berlin, Heidelberg Vester F (2002) Die Kunst, vernetzt zu denken, 6. Aufl. Deutscher Taschenbuch Verlag (dtv), München von Bertalanffy L (1976) General System Theory: Foundations, Development, Applications. George Braziller, New York von Bertalanffy L (1949) Zu einer allgemeinen Systemlehre. Biologia Generalis 19(1):114129 von Foerster H (1993) Über selbstorganisierende Systeme und ihre Umwelten. In: Schmidt SJ (Hrsg) Wissen und Gewissen: Versuch einer Brücke, 1. Aufl. Suhrkamp, Frankfurt am Main von Hayek FA (1980) Recht, Gesetzgebung und Freiheit. Bd.1: Regeln und Ordnung, 2. Aufl. Moderne Industrie W3C (2004a) Web Services Architecture, W3C Working Group Note 11 February 2004. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. Abruf am 2009-12-02 W3C (2004b) Web Services Glossary, W3C Working Group Note 11 February 2004. http://www.w3.org/TR/ws-gloss/. Abruf am 2009-12-02 W3C (2001) Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001. http://www.w3.org/TR/wsdl. Abruf am 2010-02-23 Walls JG, Widmeyer GR, El Sawy OA (1992) Building an Information System Design Theory for Vigilant EIS. Information Systems Research 3(1):36-59

252

Literatur

Ware C (2005) Visual Queries: The Foundation of Visual Thinking. In: Keller T, Tergan S (Hrsg) Knowledge and Information Visualization: Searching for Synergies. Springer, Berlin, Heidelberg Ware C (2004) Information Visualization: Perception for Design, 2. Aufl. Morgan Kaufmann, San Francisco Ware C, Hui D, Franck G (1993) Visualizing Object Oriented Software in Three Dimensions. In: Proceedings of the 1993 Conference of the Centre for Advanced Studies on Collaborative Research (CASCON'93), Toronto Weill P, Ross J (2004) IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, 1. Aufl. Harvard Business Press, Boston Wettel R, Lanza M (2007) Program Comprehension through Software Habitability. In: Proceedings of the 15th IEEE International Conference on Program Comprehension (ICPC'07), Banff Weyuker EJ (1988) Evaluating Software Complexity Measures. IEEE Transactions on Software Engineering 14(9):1357-1365. doi:10.1109/32.6178 Wiener N (1948) Cybernetics: or, Control and Communication in the Animal and the Machine. The Technology Press, Cambridge Wilde T, Hess T (2007) Forschungsmethoden der Wirtschaftsinformatik: Eine empirische Untersuchung. WIRTSCHAFTSINFORMATIK 49(4):280-287. doi:10.1007/s11576007-0064-z Wilke H (1998) Systemisches Wissensmanagement, 1. Aufl. UTB, Stuttgart Wilke H (1987) Systemtheorie: Eine Einführung in die Grundprobleme, 2. Aufl. Gustav Fischer Verlag, Stuttgart, New York Winn W (1993) An Account of How Readers Search for Information in Diagrams. Contemporary Educational Psychology 18(2):162-185. doi:10.1006/ceps.1993.1016 Winter R (2008) Design Science Research in Europe. European Journal of Information Systems 17(5):470-475. doi:10.1057/ejis.2008.44 Winter R, Fischer R (2006) Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. In: Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW'06), Hong Kong Witteler F (2009) Entwicklung einer Regel- und Transformationssprache zur Profilkonfiguration generischer Sichten im Kontext serviceorientierter Architekturen. Diplomarbeit, Lehrstuhl für Wirtschaftsinformatik und Softwaretechnik (Softec), Universität Duisburg-Essen, Essen

Literatur

253

Wittenburg A (2007) Softwarekartographie: Modelle und Methoden zur systematischen Visualisierung von Anwendungslandschaften. Dissertation, Fakultät für Informatik, Technische Universität München, München WKWI (1994) Profil der Wirtschaftsinformatik, Ausführungen der Wissenschaftlichen Komission der Wirtschaftsinformatik. WIRTSCHAFTSINFORMATIK 36(1):80-81 Woodfield SN (1979) An Experiment on Unit Increase in Problem Complexity. IEEE Transactions on Software Engineering 5(2):76-79. doi:10.1109/TSE.1979.234162 Workflow Management Coalition (WfMC) (2008) Workflow Management Coalition Workflow Standard: Process Definition Interface - XML Process Definition Language, Version 2.1a, Document Number WFMC-TC-1025. http://www.wfmc.org/index. php?option=com_docman&task=doc_download&Itemid=72&gid=132. Abruf am 2010-06-02 Zachman JA (2008) The Zachman Framework: The Official Concise Definition. http://www.zachmaninternational.com. Abruf am 2010-06-02 Zachman JA (1987) A Framework for Information Systems Architecture. IBM Systems Journal 26(3):276-292 Zarnekow R, Brenner W, Grohmann HH (2004) Informationsmanagement: Konzepte und Strategien für die Praxis, 1. Aufl. dpunkt.verlag, Heidelberg Zhang K (2003) Software Visualization: From Theory to Practice, 1. Aufl. Kluwer Academic Publishers, Boston, Dordrecht, London Zhang L, Zhang J, Cai H (2007) Services Computing, 1. Aufl. Springer, Berlin, Heidelberg, New York Zuse H (1991) Software Complexity: Measures and Methods. de Gruyter, Hawthorne, NJ

Anhang A.1 XML-Schema-Definition des Dimensionssystems

T. Spies, Generische Architektursichten, DOI 10.1007/978-3-8349-6670-4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

256

Anhang



A.2 XML-Konfiguration des Dimensionssystems

Anhang

A.3 XML-Schema-Definition der Profile Container for profiles Profile which represents stakholder concerns. It is configured by using dimensions Different dimension valuues Representing special aspects of one or more concerns Different dimension values

257

258

Anhang

Container for dimension elements

A.4 XML-Beispielkonfiguration eines Profils make