Integrationsmanagement: Planung, Bewertung und Steuerung von Applikationslandschaften (Business Engineering) (German Edition)

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner Business Engineering V. Bach, H. Österle (Hr...

Author: Joachim Schelp | Robert Winter

259 downloads 1804 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner

Business Engineering V. Bach, H. Österle (Hrsg.) Customer Relationship Management in der Praxis 2000. ISBN 3-540-67309-1 H. Österle, R. Winter (Hrsg.) Business Engineering, 2. Auflage 2003. ISBN 3-540-00049-6 R. Jung, R. Winter (Hrsg.) Data Warehousing Strategie 2000. ISBN 3-540-67308-3 E. Fleisch Das Netzwerkunternehmen 2001. ISBN 3-540-41154-2 H. Österle, E. Fleisch, R. Alt Business Networking in der Praxis 2002. ISBN 3-540-42776-7

L. Kolbe, H. Österle, W. Brenner (Hrsg.) Customer Knowledge Management 2003. ISBN 3-540-00541-2 R. Alt, H. Österle Real-time Business 2003. ISBN 3-540-44099-2 G. Riempp Integrierte Wissensmanagement-Systeme 2003. ISBN 3-540-20495-4 T. Puschmann Prozessportale 2004. ISBN 3-540-20715-5 H. Österle, A. Back, R. Winter, W. Brenner Business Engineering – Die ersten 15 Jahre 2004. ISBN 3-540-22051-8

S. Leist, R. Winter (Hrsg.) Retail Banking im Informationszeitalter 2002. ISBN 3-540-42776-7

R. Zarnekow, W. Brenner, U. Pilgram Integriertes Informationsmanagement 2005. ISBN 3-540-23303-2

C. Reichmayr Collaboration und WebServices 2003. ISBN 3-540-44291-X

U. Baumöl, H. Österle, R. Winter (Hrsg.) Business Engineering in der Praxis 2005. ISBN 3-540-20517-9

O. Christ Content Management in der Praxis 2003. ISBN 3-540-00103-4

R. Zarnekow, A. Hochstein, W. Brenner Serviceorientiertes IT-Management 2005. ISBN 3-540-20532-2

E. von Maur, R. Winter (Hrsg.) Data Warehouse Management 2003. ISBN 3-540-00585-4

Joachim Schelp Robert Winter Herausgeber

Integrationsmanagement Planung, Bewertung und Steuerung von Applikationslandschaften

mit 81 Abbildungen und 45 Tabellen

123

Dr. Joachim Schelp Professor Dr. Robert Winter Institut für Wirtschaftsinformatik IWI-HSG Universität St. Gallen Müller-Friedberg-Strasse 8 9000 St. Gallen Schweiz E-mail: [email protected] E-mail: [email protected]

ISSN 1616-0002 ISBN-10 3-540-20506-3 Springer Berlin Heidelberg New York ISBN-13 978-3-540-20506-7 Springer Berlin Heidelberg New York Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany 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. Einbandgestaltung: Erich Kirchner Herstellung: Helmut Petri Druck: Strauss Offsetdruck SPIN 10971055

Gedruckt auf säurefreiem Papier – 42/3153 – 5 4 3 2 1 0

Vorwort Die Integration operativer Applikationen ist eine Herausforderung, der sich Unternehmungen permanent gegenübersehen. Im Gegensatz zur analytischen Integration im Data Warehousing sind für die operative Integration keine etablierten Techniken und Methoden vorhanden – selbst der Umfang der Integrationsaufgabe wird in Wissenschaft und Praxis kontrovers diskutiert. Angestossen durch das Stichwort Enterprise Application Integration (EAI) fokussierte sich die Diskussion in den letzten Jahren letztlich eher auf technische Aspekte, während gegenwärtig – nicht zuletzt unter dem Stichwort Serviceorientierung – erneut der Versuch unternommen wird, über die reine Technologiesicht hinaus eine nachhaltige Bewirtschaftung der gesamten Applikationslandschaft zu erreichen. Deshalb geht es in diesem Band weniger um die Integrationsaufgabe aus Technologiesicht, sondern um die Managementsicht auf Integration – die Planung (einschl. Architektur), Steuerung / Führung, Wirtschaftlichkeitsanalyse / -kontrolle usw. von Integrationsprojekten und Integrations-Infrastrukturen. Da dieses Themenfeld noch am Anfang seiner Entwicklung steht, ist es zum gegenwärtigen Zeitpunkt noch nicht möglich, es vollständig abzudecken. Die hier vorgestellten Beiträge konzentrieren sich daher auf zentrale Fragestellungen wie z.B.: Wie kann die heterogene Applikationslandschaft erfasst und strukturiert werden? Welche Hilfestellungen gibt es bei konkreten Entscheidungen während der Gestaltung der Applikationsintegration? Wie kann die Integrationsinfrastruktur bewertet werden? Wie können längerfristige Aspekte berücksichtigt werden? Insbesondere mit der letzten Frage weitet sich der Fokus von der Betrachtung von einzelnen Integrationsprojekten zur Betrachtung der gesamten Unternehmensarchitektur, in deren Kontext Integrationsprojekte verankert werden müssen. Diese Fragestellungen waren der Gegenstand eines in den Jahren 2002 bis 2004 durchgeführten Konsortial-Forschungsprojektes, des Kompetenzzentrums Application Integration Management (CC AIM), das im Rahmen des Forschungsprogramms Business Engineering am Institut für Wirtschaftsinformatik der Universität St. Gallen (IWI-HSG) durchgeführt wurde. Das CC AIM hat sich zum Ziel gesetzt, die oben skizzierten Gestaltungsbedarfe methodisch zu unterstützen und „Successful Practices“ zu identifizieren. An diesem Konsortialprojekt nahmen die folgenden Partnerunternehmen aktiv teil:

VI

Vorwort

–

Axpo Informatik AG

–

Credit Suisse Financial Services

–

Sparkassen Informatikzentrum

–

Swisscom IT Services

–

Swiss Re

–

Winterthur Versicherungen

Die Organisation der Forschungsarbeit ist für alle Kompetenzzentren des IWI-HSG gleichartig. Sie gestaltete sich im CC AIM wie folgt: Die Arbeitsgruppe trägt die inhaltliche Arbeit des Kompetenzzentrums und setzt sich aus Mitarbeitern der Partnerunternehmen und des IWI-HSG zusammen:

– – – –

Je zwei bis drei Mitarbeiter jedes Partnerunternehmens, typischerweise mit Projektleitungsfunktion, der Projektleiter des Kompetenzzentrums (gleichzeitig Post-Doc mit Forschungs- und Lehrtätigkeit an der Universität St. Gallen), drei Projektassistenten (gleichzeitig Doktoranden an der Universität St. Gallen) sowie mehrere studentische Mitarbeiter.

In bilateralen Projekten zwischen einem Partunternehmen und dem IWIHSG werden einzelnen Themen vertieft. Stets bilden unternehmensspezifische Problemstellungen den Ausgangspunkt für die Entwicklung geeigneter Techniken und Methoden, die zunächst mit Fokus auf das initiierende Unternehmen entwickelt werden, um dann mit dem Ziel genereller Anwendbarkeit erweitert zu werden. Der Beirat ist das Steuerungs- und Kontrollgremium des Kompetenzzentrums. Der Beirat diskutiert auf Vorschlag der Projektleitung den Projektplan, genehmigt diesen und überprüft die Ergebnisse der gesetzten Forschungsziele. Der Beirat besteht jeweils aus einem Vertreter jedes Partnerunternehmens sowie dem Direktor des IWI-HSG, der das Kompetenzzentrum wissenschaftlich betreut. Das Forschungsprojektportfolio des IWI-HSG wird durch ein weiteres Gremium, den Forschungsrat des Forschungsprogramms Business Engi-

Vorwort

VII

neering, gesteuert. Dem Forschungsrat gehören Topmanager verschiedener Grossunternehmen aus der Schweiz und aus Deutschland an. Die in diesem Buch dargelegten Ergebnisse wurden primär durch die jeweiligen Arbeitsgruppenmitglieder jedes Partnerunternehmens sowie des Instituts erarbeitet. Wichtige Voraussetzung für den Erfolg waren nicht nur das beiderseitige Bestreben aus Praxis und Wissenschaft, gemeinsam geeignete Methoden erarbeiten zu wollen, sondern insbesondere auch die Bereitschaft, die praktischen Erfahrungen der Partnerunternehmen mit den jeweils anderen Mitgliedern der Arbeitsgruppe austauschen zu wollen. Die hier dargestellten Ergebnisse entstanden in bilateralen Projekten, in gemeinsamen Workshops, bei der Vorbereitung von Publikationen sowie in Einzelarbeiten innerhalb des Themenspektrums des Kompetenzzentrums. Die erste Hälfte der Beiträge hat einen eher generellen Charakter, da sie weniger stark auf die Verhältnisse eines Unternehmens fokussieren. Den ersten Beitrag des vorliegenden Buches bildet das Modell zur Visualisierung der Anwendungslandschaft als Grundlage der InformationssystemArchitekturplanung von Winter. Dieser Beitrag konsolidiert die vorhergehenden Arbeiten zu dem Modell, das in dieser Form auch Anwendung bei einem Partnerunternehmen gefunden hat. Einen weiteren Beitrag zur Modellierung stellen die Entwurfsmuster zur Applikationsintegration dar, die von Schwinn aus einem bilateralen Projekt heraus entwickelt wurden. Auf die Ebene des Managements der IS-Architektur wird mit dem Beitrag Entwicklung eines Zielsystems für ein systemisch-evolutionäres Management der IS-Architektur im Unternehmen von Hafner gewechselt, der einen Bezugs- und Ordnungsrahmen für das Management der IS-Architektur liefert. Die aktuelle Diskussion um Serviceorientierung wird anschliessend von Hafner, Schelp und Winter im Beitrag Berücksichtigung des Architekturmanagements in serviceorientierten IT-Managementkonzepten am Beispiel von ITL aufgegriffen. Auf die – auch im Architekturkontext – häufig zu kurz kommenden Sicherheitsaspekte gehen anschliessend Rupprecht und Wortmann mit ihrem Beitrag Zugriffskontrolle in heterogenen Applikationslandschaften ein und konzentrierten sich insbesondere auf Fragen der Zugriffskontrolle und den dazu bestehenden Integrationsansätzen im Umfeld heterogener Applikationslandschaften. Danach geht Wortmann genereller auf Integrationsinfrastrukturen in der Finanzdienstleistungsbranche: Ergebnisse einer Studie ein. Die zweite Hälfte der Beiträge zeichnet sich durch eine stärkere Nähe zu den Verhältnissen in den jeweiligen Unternehmungen aus. Aus einem bilateralen Projekt heraus, aber mit hohem Wiederverwendungspotenzial in ähnlich gelagerten Problemstellungen, entwickeln Siegenthaler und

VIII

Vorwort

Schwinn einen Beitrag zur Modellierung von Integrationsaspekten in Applikationslandschaften. Gleiches gilt für den Beitrag Architekturmanagement – Rahmen und Realisierung der Unternehmensarchitektur der Mobiliar, mit dem Dietzsch einen konkreten Ansatz zum Architekturmanagement skizziert. Ebenso wertvoll ist die Auseinandersetzung mit Measured Integration – Metriken für die Integrationsarchitektur, die im Beitrag von Hagen und Schwinn diskutiert wird und die gegenwärtig im Kontext der Serviceorientierung eine höhere Aufmerksamkeit erfordert. Unser Dank gehört nicht nur allen Autoren, sondern insbesondere den Mitarbeitern, die seitens der Partnerunternehmen die inhaltliche Auseinandersetzung und Verankerung in der Praxis vorangetrieben haben. Besonderer Dank gilt auch Martina Schmid und Remo Stieger, studentische Mitarbeiter am IWI-HSG, die den organisatorischen und technischen Erstellungsprozess dieses Bandes mit grossem Engagement gemeistert haben. Wir hoffen, dass die hier präsentierten Beiträge zu den Themen Integration und Architektur für unsere Leser und Leserinnen Anregung und nicht zuletzt Hilfestellung bei der Entwicklung von Lösungen in ihrem Umfeld geben. Für uns sind es Grundlagen und Wegweiser, die uns bei der weiteren Forschungstätigkeit in diesem Gebiet leiten, die im Nachfolgeprojekt Kompetenzzentrum Integration Factory (CC IF) geleistet wird. Natürlich sind wir für alle Anregungen zur Weiterentwicklung der hier skizzierten Ideen stets dankbar. Joachim Schelp, Robert Winter

St. Gallen, im August 2005

Inhaltsverzeichnis Robert Winter Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage der Informationssystem-Architekturplanung........................... 1 Alexander Schwinn Entwurfsmusterbasierter Ansatz zur Systematisierung von Applikationsbeziehungen im Business Engineering ............................... 31 Martin Hafner Entwicklung eines Zielsystems für ein systemisch-evolutionäres Management der IS-Architektur im Unternehmen.................................. 61 Martin Hafner, Joachim Schelp, Robert Winter Berücksichtigung des Architekturmanagements in serviceorientierten IT-Managementkonzepten am Beispiel von ITIL ......................................................................................................... 99 Josef Rupprecht, Felix Wortmann Zugriffskontrolle in heterogenen Applikationslandschaften ................. 123 Felix Wortmann Integrationsinfrastrukturen in der Finanzdienstleistungsbranche: Ergebnisse einer Studie ......................................................................... 169 Andreas Siegenthaler, Alexander Schwinn Modellierung von Integrationsaspekten in Applikationslandschaften ...................................................................... 203 Andreas Dietzsch Architekturmanagement – Rahmen und Realisierung der Unternehmensarchitektur der Mobiliar ................................................. 231 Claus Hagen, Alexander Schwinn Measured Integration – Metriken für die Integrationsarchitektur ......... 267 Autorenverzeichnis................................................................................ 293

Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage der Informationssystem-Architekturplanung Robert Winter Universität St. Gallen

Ein wichtiges Ziel der Informationssystem-Architekturplanung ist es, organisatorisch eng gekoppelte, informationell eng gekoppelte oder wiederverwendbare Funktionalitäten in integrierten Anwendungssystemen zusammenzufassen und zwischen den damit entstehenden Anwendungssystemen effiziente Schnittstellen zu bilden. Zur Visualisierung der Anwendungslandschaft und als Grundlage für das Integrationsmanagement wird in diesem Beitrag ein semiformales Beschreibungsmodell hergeleitet. Unter Nutzung dieses Modells werden Regeln für die Unterstützung der Anwendungssystem- und der Schnittstellengestaltung vorgeschlagen.

1 2

3

4

5

Einführung ................................................................................................... 2 Modellierung der Anwendungslandschaft ............................................... 6 2.1 Semiformale Modelle ......................................................................... 8 2.2 Ableitung eines kombinierten, semiformalen Modells ................ 11 Nutzung des Architekturmodells für die Anwendungssystembildung .................................................................................... 14 3.1 Analyse der Ist-Architektur auf Anwendungssystemebene ........ 14 3.2 Entwicklung der Soll-Architektur auf Anwendungssystemebene ....................................................................................... 17 Nutzung des Architekturmodells für die Schnittstellenbildung.......... 21 4.1 Nutzung von Integrationssystemen zur Reduktion der Anzahl von Schnittstellen .............................................................................. 22 4.2 Generische Referenz-Anwendungslandschaft .............................. 24 Zusammenfassung und Ausblick ............................................................ 25

2

1

R. Winter

Einführung

Die Problematik der Informationssystem-Architekturplanung wird gleichermassen von der Forschung (z.B. im deutschsprachigen Raum, vgl. Krcmar 1990; Österle et al. 1992) wie auch von Beratungs- bzw. Softwareunternehmen (z.B. vgl. O.V. 1984; Zachman 1987) adressiert. Seit einigen Jahren wird die Informationssystem-Architekturplanung zunehmend mit Architekturplanungs-Ansätzen auf anderen Betrachtungsebenen (z.B. „Business Architecture”, vgl. McDavid 1999; Youngs et al. 1999) integriert und als umfassendes Gestaltungskonzept „Enterprise Architecture” (vgl. Malhotra 1996; Zachman 1999; Martin/Robertson 2000) diskutiert. Mit ISO 15704 Annex A, ISO/CEN FDIS 19439 sowie ISO/IEC 15288 liegen zudem erste Normen vor, die die Gestaltung der Informationssystem-Architektur als Teil eines umfassenderen Gestaltungsansatzes beschreiben. Obwohl in der Wirtschaftsinformatik weitgehende Einigkeit über die Bedeutung der Informationssystem-Architektur sowie über die Zweckmässigkeit der Verwendung des Architekturbegriffs besteht (vgl. Lehner et al. 1995, S. 59), findet sich dafür keine eindeutige, generelle Definition (vgl. Schmalzl 1995, S. 13). Beispielsweise bezeichnet Scheer die Komponenten eines Informationssystems und ihre Beziehungen als Architektur (vgl. Scheer 1995, S. 3) während Österle et al. die Informationssystem-Architektur als Grobstruktur der Organisation, der Geschäftsfunktionen, der Daten, der Applikationen und der Datenbanken definieren (vgl. Österle et al. 1992, S. 26). Allen Definitionen gleich ist die Zielsetzung der Informationssystem-Architekturplanung, die Strukturierung betrieblicher Informationssysteme auf hohem Aggregationsniveau abzubilden, um damit einen ganzheitlichen Überblick zu schaffen und Gestaltungsentscheidungen zu unterstützen (vgl. Krcmar 2003, S. 39ff.). Entsprechende Architekturmodelle sollten deshalb nicht nur Beschreibungsmittel, sondern auch Gestaltungsregeln umfassen (vgl. Sinz 1997). In den hier zitierten Informationssystem-Architekturansätzen ist der Informationssystembegriff weit definiert, d.h. umfasst neben den implementierten bzw. zu implementierenden Systemkomponenten (Anwendungssystemen) auch die gesamten fachlichen Grundlagen einschliesslich solcher für nicht implementierte bzw. nicht implementierbare Systemkomponenten. Um die durch diesen weiten Informationssystem-Begriff induzierte Vielgestaltigkeit und Komplexität der Beschreibung beherrschbar zu machen, umfassen Informationssystem-Architekturmodelle im Normalfall mehrere Teilmodelle. So finden sich im bekannten Zachman-Framework (vgl. Zachman 1987) nicht weniger als 30 Teilmodelle, die jeweils eine

Ein Modell zur Visualisierung der Anwendungslandschaft

3

bestimmte Perspektive-Fragestellungs-Kombination abbilden. Das ISAModell (vgl. Krcmar 1990) umfasst sieben Teilmodelle, die sich durch Beschreibungsebene (z.B. Strategie, Organisation, Informationssystem, Infrastruktur) und Informationssystemsicht (z.B. Daten, Funktionen, Informationsflüsse) unterscheiden. In ARIS werden zwölf Teilmodelle unterschieden, die sich durch unterschiedliche Implementierungsnähe (Fachkonzept, DV-Konzept, Implementierung) und unterschiedliche Informationssystemsicht (Daten, Funktionen, Steuerung, Organisation) unterscheiden (vgl. Scheer 2001). Da alle genannten Ansätze versuchen, die fachlichen Grundlagen des Informationssystems möglichst vollständig abzubilden, müssen in die einführende Betrachtung auch Architektur-Gesamtansätze wie z.B. die multiperspektivische Unternehmensmodellierung (vgl. Frank 1994), das semantische Objektmodell (z.B. vgl. Ferstl/Sinz 1995) und das Business Engineering-Modell (z.B. vgl. Österle/Blessing 2000) einbezogen werden. Diese drei Ansätze sind hinsichtlich der Betrachtungsebenen weitgehend kompatibel (vgl. Leist 2002): Überall findet sich eine Strategieebene zur Beantwortung der „was?”-Fragen, eine Organisations- bzw. Prozessebene zur Beantwortung der „wie?”-Fragen und eine Anwendungssystemebene zur Beantwortung der „womit?”-Fragen, wobei bei letzterer fast immer zwischen der fachlichen Beschreibung und der technischen (Realisierungs)Beschreibung unterschieden wird (vgl. Winter 2003). Dieser Beitrag beschränkt sich auf die Betrachtungsebene, auf der – im Rahmen eines Gesamtansatzes oder auch isoliert – Anwendungssysteme aus fachlicher Sicht betrachtet werden. Diese Betrachtungsebene wird im Folgenden als Anwendungssystemebene bezeichnet. Die Anwendungssystem-Architektur soll einen ganzheitlichen Überblick über Anwendungssysteme schaffen und Gestaltungsentscheidungen unterstützen. Aus technischer Sicht repräsentiert ein Anwendungssystem eine aggregierte Zusammenfassung bestimmter Softwareartefakte (z.B. Module, Komponenten, Datenstrukturen), die in einem engen Zusammenhang stehen (z.B. Aufruf, Zugriff). Aus fachlicher Sicht repräsentiert ein Anwendungssystem eine aggregierte Zusammenfassung bestimmter Funktionalitäten, die in einem engen, noch genauer zu bestimmenden fachlichen Zusammenhang stehen. Im Folgenden werden Anwendungssysteme ausschliesslich aus fachlicher Sicht betrachtet. Enge fachliche Zusammenhänge ergeben sich beispielsweise aufgrund gemeinsamer Nutzung bestimmter Daten, gemeinsamer Unterstützung eines bestimmten Geschäftsprozesses bzw. der Erstellung einer bestimmten Leistung, gemeinsamer Verantwortung durch eine bestimmte Organi-

4

R. Winter

sationseinheit (Ownership) oder der Wiederverwendung einer bestimmten Funktionalität in verschiedenen Kontexten. Enge Zusammenhänge führen im Normalfall dazu, dass die entsprechenden Funktionalitäten in einem gemeinsamen Anwendungssystem zusammengefasst werden. Weniger enge Zusammenhänge werden in Form von Schnittstellen zwischen Anwendungssystemen abgebildet. Je nach Abgrenzung „enger“ und „schwacher“ Zusammenhänge entsteht somit eine unterschiedliche Anzahl von Anwendungssystemen und Schnittstellen. Je weniger Anwendungssysteme gebildet werden, desto weniger Schnittstellen sind abzubilden und desto geringer fallen Aufwendungen für die Entwicklung und den Betrieb dieser Schnittstellen aus. Dieser Zusammenhang wird durch die Kurve „Schnittstellenkosten“ in Abbildung 1 illustriert. Aufgrund des Netzeffekts darf erwartet werden, dass diese Kurve einen mit zunehmender Anzahl von Anwendungssystemen exponentiell steigenden Verlauf hat. Je weniger Anwendungssysteme gebildet werden, desto höher werden jedoch die Aufwendungen zur Entwicklung und zum Betrieb dieser – entsprechend komplexeren – Anwendungssysteme sein. Dieser Zusammenhang wird durch die Kurve „Anwendungssystemkosten“ in Abbildung 1 illustriert. Auch hier darf ein mit abnehmender Anzahl von Anwendungssystemen exponentiell steigender Verlauf unterstellt werden. In Abbildung 1 sind beide Kurven in Anlehnung an die Darstellung bei Frese (vgl. Frese 1995, zitiert nach Rosemann 1999, S. 14) dargestellt. Summe aus Entwicklungsund Betriebskosten

Anwendungssystemkosten

Schnittstellenkosten

Gesamtkosten

Optimaler Integrationsgrad

Abb. 1:

Anzahl der Anwendungssysteme

Optimaler Integrationsgrad

Eines der wichtigsten Ziele der Architekturplanung auf Anwendungssystemebene ist die Minimierung der Gesamtkosten im Sinne der Summe von Schnittstellen- und Anwendungssystemkosten. Das Minimum der Gesamtkosten ergibt sich in der exemplarischen Darstellung von Abbildung 1 im


5

Schnittpunkt von Schnittstellen- und Anwendungssystemkosten. Die entsprechende Anzahl von Anwendungssystemen wird als „optimaler Integrationsgrad“ bezeichnet. Leider zeigen empirische Untersuchungen (z.B. vgl. Leist/Winter 1998), dass der optimale Integrationsgrad analytisch nicht oder nur unter unrealistischen Annahmen erreicht werden kann. Um dennoch durch gezielte Architekturplanung Entwicklungs- und Betriebskosten senken zu können, wird hier ein pragmatischer, auf Architekturprinzipien beruhender Ansatz vorgeschlagen. Durch Anwendung genereller Architekturprinzipien in Entwicklungsprojekten wird versucht, die Gesamtkosten sukzessiv zu reduzieren und sich schrittweise dem optimalen Integrationsgrad anzunähern. Andere Ziele der Architekturplanung wie z.B. Schnittstellenqualität bleiben dabei zunächst ausserhalb der Betrachtung. Eine zentrale Rolle bei der Architekturplanung spielt die Anwendungslandschaft. Die Anwendungslandschaft bildet als aggregiertes Modell der Anwendungssysteme aus fachlicher Sicht den „Bauplan, nach dem die Planung, Koordinierung und Realisierung [von Anwendungssystemen] im Rahmen des Konstruktionsprinzips zu erfolgen hat“ (van Dillen 2002, S. 222). Nach dieser Einführung wird in Abschnitt 2 zunächst ein Modell zur Visualisierung der Anwendungslandschaft abgeleitet. Grundlage dafür bilden die Anforderungen an ein geeignetes Beschreibungsmodell und eine Überprüfung bestehender Ansätze hinsichtlich dieser Anforderungen. In Abschnitt 3 werden auf Grundlage dieses Modells Architekturprinzipien abgeleitet und es wird gezeigt, wie diese Regeln zur sukzessiven Senkung von Schnittstellen- und Anwendungssystemkosten beitragen. Dazu wird zunächst die Visualisierung der Probleme von Ist-Anwendungslandschaften betrachtet. Auf dieser Grundlage wird gezeigt, wie die Architekturregeln Hilfestellung bei der (Um-)Strukturierung von Anwendungssystemen leisten kann. Auf der Grundlage einer entsprechend umgestalteten Anwendungslandschaft wird in Abschnitt 4 die Nutzung des vorgeschlagenen Modells zur Gestaltung von Schnittstellen skizziert. Die nach der (Um)Strukturierung von Anwendungssystemen verbleibenden Schnittstellenanforderungen werden dabei möglichst umfassend durch die Nutzung von Integrationssystemen abgedeckt, die dem sog. Hub and Spoke-Konzept entsprechen. Diese Überlegungen führen zum Vorschlag einer generischen Referenz-Anwendungslandschaft. Im abschliessenden Abschnitt 5 werden die Ergebnisse zusammengefasst, bewertet und in Beziehung zu künftigem Forschungsbedarf gesetzt.

6

R. Winter

Die in diesem Beitrag dokumentierten Erkenntnisse sind vorwiegend im Rahmen der wissenschaftlichen Betreuung von (Re-)Architekturprojekten grosser Dienstleistungsunternehmen gewonnen worden. Die vorgestellten Referenz-Architekturmodelle wurden durch Generalisierung aus konkreten Ist- und Soll-Anwendungslandschaften abgeleitet. Der Autor hat im Sinne von Action Research an der Überprüfung bestehender Modelle teilgenommen, ein kombiniertes Modell entwickelt, Architekturregeln formuliert und schliesslich die Anwendung des vorgeschlagenen Modells begleitet.

2

Modellierung der Anwendungslandschaft

In der wissenschaftlichen Literatur und in Praxisberichten findet sich eine grosse Zahl von Modellen zur Abbildung der Anwendungslandschaft. Dabei sind informelle, semiformale und formale Modelle zu unterscheiden: Da für informelle Modelle weder die Syntax noch die Semantik des Abbilds klar definiert sind, lassen sich die Konsistenz der Abbildung, die Vollständigkeit der Abbildung und das Fehlen von Anomalien und Redundanzen nicht nachweisen. Semiformale Modelle verfügen zwar über eine formalisierte Syntax und explizite Abbildungsregeln, so dass nicht nur eine eindeutige und präzise Beschreibung des Abbilds möglich wird, sondern auch bestimmte Qualitätsprüfungen durchgeführt werden können (z.B. Konsistenz bestimmter Beschreibungselemente). Nur bei Nutzung formaler Modelle sind Syntax und Semantik des Abbilds jedoch so vollständig spezifiziert, dass umfassende Nachweise und Prüfungen der Abbildung möglich werden (vgl. Fraser 1994). Abbildung 2 zeigt beispielhaft die typische Abbildung einer Anwendungslandschaft aus der Praxis. In diesem Fall sind nur sehr wenige Abbildungsvorschriften klar zu erkennen: • Bilde Anwendungssysteme durch ein benanntes Rechteck ab. • Bilde Gruppen zusammengehöriger Anwendungssysteme ebenfalls durch benannte Rechtecke ab und platziere zugehörige Anwendungssysteme innerhalb des betreffenden Rechtecks. • Ordne Anwendungssysteme so an, dass sog. Frontoffice-Systeme und sog. Backoffice-Systeme auch optisch getrennt sind.


7

Front Office Applications

Core Data Managemt. Customers

Transactions

Payments Clearing

Foreign Exchange

Loans

General Functions ... Input/ Output

Financial Instrum. Products Cond.

Financial Acc. Base Applications Accounts

... Credit/ Control

...

...

...

...

... Reporting

Risk Analysis

...

...

...

...

...

Data Warehousing

Abb. 2:

...

SAP

Anwendungslandschaft in der Praxis (vgl. Leist/Winter 1999)

Offensichtlich fehlen Vorschriften zur Festlegung der Grösse der Abbilder von Anwendungssystemen ebenso wie eindeutige Regeln zur Positionierung der Abbilder von Anwendungssystemen oder Regeln zur Abbildung der Schnittstellen zwischen Anwendungssystemen. Im Folgenden werden deshalb ausschliesslich (mindestens) semiformale Architekturmodelle auf Anwendungssystem-Ebene betrachtet. Diese zeichnen sich dadurch aus, dass • Regeln festlegen, wie gross ein Anwendungssystem abzubilden ist, • Regeln festlegen, wo das Abbild eines Anwendungssystems zu platzieren ist, • Regeln für die Abbildung der Schnittstellen zwischen Anwendungssystemen existieren und • Regeln für die Optimierung der Anwendungslandschaft existieren.

8

2.1

R. Winter

Semiformale Modelle

Die von IBM entwickelte Methode „Business Systems Planning” (BSP) (vgl. O.V. 1984) geht auf die 1960er Jahre zurück und wurde weltweit in vielen Unternehmungen zur Planung und Überarbeitung der Anwendungsarchitektur eingesetzt. Grundlage für die Identifikation optimaler Anwendungssysteme ist in BSP die Analyse der Datennutzung: Im Verlauf der Studie werden u.a. Geschäftsprozesse und Datenklassen erhoben und es wird untersucht, welche Geschäftsprozesse welche Datenklassen nutzen oder erzeugen. Eine Clusteranalyse zeigt dann, welche Bereiche mit enger Daten-/Prozesskopplung zu einem Anwendungssystem integriert werden sollten und welche Schnittstellen zwischen den entstandenen Anwendungssystemen entstehen. Zur Beschreibung der Anwendungslandschaft benutzt BSP ein semiformales Modell, da die Grösse und die Positionierung der Anwendungssystem-Abbilder nicht wahlfrei sind, sondern sich als Ergebnis der Clusteranalyse und durch Referenzierung der beiden Dimensionen Geschäftsprozess und Datencluster ergibt (siehe Abb. 3). Schnittstellen zwischen Anwendungssystemen entstehen durch Zusammenfassung der Datenflüsse zwischen jeweils zwei Anwendungssystemen. Als Optimierungsverfahren (anstelle von Gestaltungsregeln) wird die Clusteranalyse benutzt, wobei der gewünschte Integrationsgrad als Parameter eingestellt werden könnte.


9

U n te rn eh m e n sp lan u n g O rg an isatio n san a ly se R e v ie w u n d K o n tro lle F in an z p la n u n g K ap italb esch affu n g F o rsch u n g V o rh e rsa g e D esig n u n d E n tw ic k lu n g P ro d u k tsp e zifik atio n E in k a u f W aren a n n ah m e B e stan d sk o n tro lle A rb eitsab lau fp lan u n g T erm in ieru n g K ap a zitä tsau slastu n g M a terialb ed arfsp la n u n g F ertig u n g G eb ietsm an ag e m e n t V erk au f V erk au fsad m in istratio n A u ftrag sb ea rb eitu n g V ersan d B u ch h altu n g K o ste n p lan u n g B u d g etrec h n u n g P erso n alp lan u n g A n w erb u n g /F ö rd e ru n g E n tlo h n u n g

B eda rf

P ro d u k tio n

V ertrieb

V erw altu n g

Personal

P ro zeß

Management

D ate n k lasse

Planung Finanzmittel Produkte Teilekatalog Stücklisten Lieferanten Rohmaterialbestände Fertigfabrikatbestände Anlagen Produktionsvolumen Maschinenbelastungen Offene Bedarfe Arbeitspläne Kunden Verkaufsgebiete Aufträge Kosten Beschäftige

Datencluster

Geschäftsprozesse Abb. 3:

Anwendungssystem-Architekturplanung in BSP

Die von der Unternehmensberatung IMG entwickelte Technik „IS-Architekturplanung“ ist Teil der Methode „Promet® Systems and Technology Planning“ (STP) (vgl. O.V. 2000). Eine ähnliche Darstellung findet sich auch in BSP. Im Verlauf der STP-Anwendung werden Funktionscluster und Geschäftseinheiten erhoben und es wird untersucht, welche Geschäftseinheiten für welche Funktionscluster verantwortlich sind (sog. Ownership). Sortiert man Funktionscluster und Geschäftseinheiten aufgrund der Ownership, ergibt sich ebenfalls eine zweidimensionale Strukturierung. Auch STP verwendet zur Beschreibung der Anwendungslandschaft ein semiformales Modell, da die Grösse und die Positionierung der Anwendungssystem-Abbilder nicht wahlfrei sind, sondern aus der OwnershipAnalyse und durch Referenzierung der beiden Dimensionen Geschäftseinheit und Funktionscluster resultieren (siehe Abb. 4). Aufgrund der Fokussierung auf Ownership anstelle von Datenverwendung und Datenflüssen werden jedoch in STP keine Schnittstellenspezifikationen erzeugt. An Stelle von expliziten Gestaltungsregeln wird eine Organisationsanalyse

10

R. Winter

vorgeschlagen, in deren Rahmen geeignete Verantwortlichkeiten zu identifizieren sind.

Funktionscluster Schadenbearbeitung Vertragsverwaltung Inkasso Ertragscontrolling ... ... ... ... ...

Appl. A

Geschäftsbereich

Sachvers. Einzelkunden Einzel-Lebensvers. Inl. Gruppen-Lebensv. Inl. Einzel-Lebensv. Ausl. Gruppen-Lebensv. Ausl. Unfallversicherung Inl. Unfallvers. Ausland ...

Geschäftsbereiche

Appl. B

Funktionscluster Abb. 4:

Anwendungssystem-Architekturplanung in STP

Im Gegensatz zu den zweidimensionalen Darstellungen in BSP und STP sieht das von der Unternehmensberatung Context entwickelte Architekturmodell (vgl. Penzel 2002; Spitzer 2002) drei Beschreibungsdimensionen für Anwendungssysteme vor: • Produkte • Prozessschritte (z.B.Akquisition,Bestellung, Auftragsabwicklung, Nachkalkulation) • Plattformen (z.B. Applikation, Middleware, Datenbank, Betriebssystem, Hardware, Netzwerk). Falls die Handhabung dreidimensionaler Modelle als problematisch betrachtet wird, wird vorgeschlagen, durch Festlegung jeweils eines Wertes jeder Dimension ein Bündel zweidimensionaler Modelle abzuleiten. So ergibt sich beispielsweise bei Auswahl eines Produkts eine Darstellung des betreffenden Geschäftsprozesses (hinsichtlich der restlichen Dimensionen Prozessschritt und Plattform) oder bei Auswahl einer Plattform eine Darstellung eines entsprechenden Infrastrukturmodells (hinsichtlich der restlichen Dimensionen Prozessschritt und Produkt). Anwendungssysteme setzen sich aus sog. Building Blocks zusammen.


11

Zwar erlaubt das Context-Modell aufgrund der dritten Dimension die Darstellung semantisch reichhaltigerer Sachverhalte. Auch sind explizite Dimensionen und darauf basierende Abbildungs- und Anordnungsregeln erkennbar. Leider werden jedoch keine „harten“ Regeln für die Bildung der Building Blocks publiziert (z.B. auf Grundlage der Analyse der Datennutzung, der Ownership o.ä.). Stattdessen wird vorgeschlagen, Funktionalitäten in Building Blocks zusammenzufassen, die im Hinblick auf Anforderungen, Know-How und Zusammenhänge ähnlich sind, aber nur lose mit Funktionalitäten anderer Building Blocks gekoppelt sind (vgl. Spitzer 2002). Deshalb wird das Context-Modell in der derzeit publizierten Form nicht in die folgenden Überlegungen einbezogen.

2.2

Ableitung eines kombinierten, semiformalen Modells

Während die Anwendungssystembildung bei BSP auf Datennutzung und Datenflüsse fokussiert, basiert die STP-Anwendungssystembildung auf der Organisation. Beide Aspekte werden für die Architekturplanung auf Anwendungssystemebene als wichtig erachtet: Während die Berücksichtigung der Datennutzung und Datenflüsse für die Umsetzung einer effizienten Informationslogistik notwendig ist, ist die Berücksichtigung der Verantwortlichkeiten für ein effizientes Informationssystemmanagement unverzichtbar. Als Konsequenz müssten die beiden jeweils zweidimensionalen Gestaltungsmodelle von BSP und STP zu einem vierdimensionalen Modell kombiniert werden. Da vierdimensionale Modelle nur schwer zu kommunizieren sind, müssen zwei der vier Dimensionen verschmolzen werden. Dafür bestehen vier Möglichkeiten: • Datencluster (aus BSP) und Funktionscluster (aus STP): Die Unterscheidung zwischen Datensicht und Funktionssicht wird nicht nur in klassischen Architekturkonzepten, sondern auch in aktuellen, in der Unternehmensrealität bedeutungsvollen Architekturkonzepten wie z.B. ARIS aufrechterhalten. Einer der Gründe ist die grössere Stabilität, die für Datenstrukturen gegenüber funktionalen Strukturen unterstellt wird. Deshalb sind diese beiden Dimensionen eher ungeeignet, um verschmolzen zu werden. • Datencluster (aus BSP) und Geschäftseinheiten (aus STP): In modernen Organisationen sollte die sog. Data Ownership konsequent und umfassend umgesetzt sein (vgl. Meyer/Strauch 2000). Ist dies der Fall, sollten diese beiden Dimensionen auf aggregierter Ebene weitgehend konsi-

12

R. Winter

stent strukturiert sein und könnten verschmolzen werden. Anderenfalls würde diese Verschmelzung jedoch äusserst problematisch sein. • Geschäftsprozesse (aus BSP) und Funktionscluster (aus STP): Es ist eine der wesentlichen Eigenschaften von Geschäftsprozessen, dass sie orthogonal zu funktionalen Strukturen strukturiert sind (vgl. Rummler/Brache 1995). Deshalb können diese beiden Dimensionen nicht verschmolzen werden. • Geschäftsprozesse (aus BSP) und Geschäftseinheiten (aus STP): In modernen Organisationen sollten die Geschäftseinheiten entsprechend der Geschäftsprozesse/Prozessleistungen und nicht funktional strukturiert sein (vgl. Rummler/Brache 1995). Deshalb sollten diese beiden Dimensionen am ehesten zu einer Dimension „Leistung/Organisation“ verschmolzen werden können. Es wird deshalb vorgeschlagen, für den Fall prozessorientierter Organisationsstrukturen die Geschäftsprozess- und die Geschäftseinheits-Dimension zu verschmelzen. Für funktional organisierte Unternehmungen sollte dagegen die Funktionscluster-Dimension mit der Geschäftseinheit-Dimension verschmolzen werden. Im Folgenden wird nur noch der erstgenannte Fall betrachtet und durch Beispiele illustriert; für den letztgenannten Fall gelten die Ausführungen sinngemäss. Das zunächst vierdimensionale Modell wird durch die Verschmelzung der Dimensionen „Geschäftsprozess“ und „Geschäftseinheit“ in ein Modell mit den folgenden drei Dimensionen transformiert: 1. Leistung/Organisation: In dieser Dimension werden Leistungstypen und damit (für prozessorientiert organisierte Unternehmungen) implizit Organisationseinheiten auf hohem Aggregationsniveau abgebildet. Für das Privatkundengeschäft einer Bank wären Zahlungsverkehr, Bargeldversorgung, Kleinkredite, Hypotheken, Geldanlage und Beratung typische Ausprägungen dieser Dimension. 2. Funktionalität: In dieser Dimension werden wiederverwendbare Funktionalitäten auf hohem Aggregationsniveau abgebildet. Für eine Bank wären Autorisierung, Limitenverwaltung, Vertragsverwaltung, Abschluss und Dokumentenerzeugung oder die Nutzung eines speziellen Zugangskanals (z.B. Internet, Call Center, Geldautomat) typische Ausprägungen dieser Dimension. 3. Informationsobjekt: In dieser Dimension werden Kerndaten auf hohem Aggregationsniveau abgebildet. Für ein Dienstleistungsunternehmen wären Kundendaten und Limiten, Produktdaten und Preise, Risiken


13

sowie Umsätze und Rentabilitäten typische Ausprägungen dieser Dimension. Das resultierende, erstmals in Winter (2000) skizzierte Modell wird durch Abbildung 5 illustriert. Jedem Anwendungssystem wird in diesem Modell ein Abbild zugeordnet, das sowohl hinsichtlich seiner Grösse wie auch hinsichtlich seiner Positionierung eindeutig durch die Ausprägungen des abgebildeten Anwendungssystems in Bezug auf unterstützte Leistungsprozesse bzw. Zuordnung zu einer Organisationseinheit, in Bezug auf implementierte Funktionalitäten und in Bezug auf genutzte bzw. erzeugte Informationsobjekte definiert ist. Schnittstellen zwischen Anwendungssystemen können durch Kanten abgebildet werden. Funktionalität

Leistung / Organisation

Informationsobjekt

Abb. 5:

Dreidimensionales Modell zur Abbildung von Anwendungssystemen

Im Idealfall werden Anwendungssysteme durch kompakte Kuben repräsentiert. Im – leider vorherrschenden – Normalfall zeigt sich, dass viele Anwendungssysteme zwar einen Schwerpunkt haben, sich aber ansonsten amorph über einen grösseren Bereich ausdehnen, jedoch ohne diesen lückenlos abzudecken. Es ist denkbar, zur Quantifizierung des Abdeckungsgrads eines Modellbereichs durch ein Anwendungssystem und/oder zur Quantifizierung der Abweichung eines Anwendungssystems von bestimmten Idealtypen (siehe Folgeabschnitt) entsprechende Metriken zu definieren. Im Idealfall wird auch deutlich, wie weit eine Menge von Anwendungssystemen überschneidungsfrei ist und alle zu implementierenden Funktionalitäten, alle zu nutzenden Informationsobjekte und alle zu unterstützenden Leistungserstellungsprozesse lückenlos abdeckt. Im – leider vorherr-

14

R. Winter

schenden – Fall einer gewachsenen (nicht „architektierten“) Anwendungslandschaft zeigt sich deutlich, wo Überschneidungen und Lücken bestehen und wie gross diese sind. Es ist denkbar, zur Quantifizierung von Überschneidungen und Lücken einer Anwendungssystem-Menge ebenfalls entsprechende Metriken zu definieren.

3

Nutzung des Architekturmodells für die Anwendungssystembildung

Im Folgenden wird zunächst gezeigt, wie durch das vorgestellte Modell der Anwendungslandschaft Defizite existierender Anwendungssysteme bzw. Anwendungssystem-Architekturen verdeutlicht werden können. Auf Grundlage dieser Analyse werden sog. „Idealtypen” von Anwendungssystemen identifiziert.

3.1

Analyse der Ist-Architektur auf Anwendungssystemebene

In fast allen Unternehmungen ist die Anwendungslandschaft über einen längeren Zeitraum organisch gewachsen. Mitunter wurden Anwendungssysteme planlos neben- und nacheinander entwickelt bzw. eingeführt, ohne eventuelle Überlappungen oder Lücken hinsichtlich bereits existierender Anwendungssysteme zu berücksichtigen. Besonders nachteilig ist dabei, dass sich der vorherrschende Integrationsfokus im Zeitverlauf mehrfach geändert hat: • Anfangs orientierte sich die Strukturierung der Anwendungssysteme im Normalfall an Funktionalbereichen (z.B. Auftragsabwicklung, Materialwirtschaft, Rechnungswesen) oder an Produkten bzw. Leistungen. So finden sich beispielsweise in Versicherungsunternehmen in der Regel für jede Produktgruppe („Sparte“, z.B. Einzellebens-, Einzelkranken-, Gruppen- oder Sachversicherung) separate Gruppen von Anwendungssystemen, die nicht nur z.B. die Vertragsverwaltung und die Schadenabwicklung redundant implementieren, sondern oft auch Kunden-, Produkt- und Tarifdaten redundant verwalten. Im Extremfall werden für jede Sparte Kundenstammdaten und Produktmodelle redundant geführt. Als Konsequenz werden die Daten eines Versicherungsnehmers, der mit einem Unternehmen unterschiedliche Versicherungsverträge abgeschlossen hat, auch in mehreren Anwendungssystemen redundant verwaltet. Eine für den Geschäftserfolg und die Kundenbezie-


15

hung negative Konsequenz ist, dass für den Kunden aus Unternehmenssicht keine Gesamtsicht verfügbar ist. Er wird mehrere Rechnungen erhalten, er muss u.U. Adressänderungen mehrfach melden und ärgert sich u.U. über Marketingaktionen, durch die ihm Versicherungen angeboten werden, die er bereits mit dem betreffenden Unternehmen abgeschlossen hat. Das Unternehmen hat die Folgen von Unzufriedenheit als Konsequenz dieser Probleme zu tragen und kann mangels umfassender Kundeninformationen Cross Selling-Potentiale nicht nutzen. • In den 1980er Jahren führte die Intensivierung der kommerziellen Nutzung von Datenbanktechnologien und Management-Informationssystemen dazu, Informationsobjekten und den durch ihre integrierte Verwaltung realisierbaren Effizienz- und Qualitätsgewinnen höhere Aufmerksamkeit zu widmen. In der Folge wurde versucht, die Verwaltung wichtiger Informationsobjekte wie beispielsweise Kundenstammdaten oder Produktstammdaten sowie wichtige damit verbundene Funktionalitäten wie beispielsweise Konfiguration oder Preisbildung/Tarifierung in dedizierten Anwendungssystemen zu zentralisieren. Aufgrund der teilweise tiefen Eingriffe in die betroffenen, funktions- bzw. produktabwicklungsorientierten Anwendungssysteme sind solche Projekte sehr aufwändig (vgl. Schönsleben/Leuzinger 1996). In neuester Zeit führen der Zwang zum integrierten Management von Risikoinformationen (z.B. Basel II im Finanzdienstleistungsbereich) und die Notwendigkeit eines integrierten Prozessmanagements zur Intensivierung der Entwicklung informationsobjektorientierter Anwendungssysteme. • Seit Ende der 1990er Jahre stellt die zunehmende Zahl parallel genutzter Zugangs- und Distributionskanäle (z.B. Call Center, Internet, SBTerminal) die Anwendungsarchitektur vor eine neue Herausforderung: Waren es bisher Informationsobjekte, die redundant implementiert wurden und damit zu hohen Schnittstellenkosten und schlechter Datenqualität führten, so waren es nun Kommunikationsfunktionalitäten, die in Zeiten einer beschränkten Anzahl von Kanälen (Filialen und Zentrale) in die Abwicklungssysteme „einprogrammiert“ wurden und nun aus diesen herausgelöst werden müssen: Nur durch Separierung von Anwendungssystemen für (Kunden-) Informationen, Produktabwicklung und Kanalabwicklung wird flexibles Multikanalmanagement ermöglicht, das als eine Voraussetzung für moderne Dienstleistungskonzepte angesehen wird (vgl. Schierenbeck 1999). Den spezifischen, aus den Produktabwicklungen herauszulösenden Kanalfunktionalitäten konzeptionell ähnlich sind dabei produkt- bzw. organisationseinheitübergreifende, wiederverwendete Funktionalitäten wie Autorisierung oder Limitenüberwachung.

16

R. Winter

Abbildung 6 zeigt die Abbildung einer gewachsenen Anwendungslandschaft im vorgeschlagenen Modell. Da zum Integrationsfokus „Produkt-/ Leistungsorientierung“ im Laufe der Zeit zunächst „Informationsobjektorientierung“ und schliesslich „Kanal- bzw. Funktionsorientierung“ hinzukamen, finden sich die unterschiedlichsten Typen von Anwendungssystemen nebeneinander: • „A“ repräsentiert ein typisches produktorientiert integriertes Anwendungssystem (z.B. Vertragsverwaltung Einzellebensversicherung, Schadenabwicklung Sachversicherung, Hypothekenabwicklung): Für eine bestimmte Leistung/ein bestimmtes Produkt oder für eine bestimmte Organisationseinheit werden viele Funktionalitäten und viele Informationsobjekte in einem Anwendungssystem zusammengeführt, so dass tendenziell eine vertikale Scheibe entsteht. • „B“ repräsentiert ein typisches informationsobjektzentriertes Anwendungssystem (z.B. Produktdatenmanagement, Produktkonfiguration, Tarifierung, Partnerverwaltung): Für ein bestimmtes Informationsobjekt werden bestimmte Funktionalitäten über möglichst viele Organisationseinheiten/Produktgruppen hinweg zusammengeführt, so dass tendenziell ein horizontaler Stab entsteht. • „C“ repräsentiert ein typisches funktionsorientiert integriertes Anwendungssystem (z.B. Autorisierung, Limitenüberwachung, Call Center, SB-Terminal): Bestimmte Funktionalitäten werden in einem Anwendungssystem zusammengefasst und für möglichst viele Organisationseinheiten bzw. Produktgruppen sowie für möglichst viele Informationsobjekte wiederverwendet, so dass tendenziell eine horizontale Scheibe entsteht.


17

Funktionalität

C A B


Informationsobjekt

Abb. 6:

Gewachsene, nicht „architektierte“ Anwendungslandschaft

Es ist anzumerken, dass die grafische Repräsentation von Anwendungssystemen in Form von Kuben nicht impliziert, dass Anwendungssysteme als monolithische Softwareartefakte implementiert werden müssen oder sollen. Im Normalfall handelt es sich bei jedem Anwendungssystem um eine komplexe Struktur aus Modulen, Datenstrukturen und/oder Komponenten, die softwaretechnisch durch geeignete Mechanismen wie beispielsweise eine gemeinsame Datenbank, Datenübertragung, Aufruf, Nachrichten o.ä. gekoppelt sind. Abbildung 6 verdeutlicht, dass die Nutzung des vorgeschlagenen Architekturmodells Lücken und Überlappungen nicht nur gut visualisiert, sondern auch als Grundlage für entsprechende Metriken dienen kann. Überlappungen entstehen beispielsweise, wenn eine Funktionalität wie Kundendatenverwaltung in unterschiedlichen produktorientierten Anwendungssystemen redundant implementiert wurde. Lücken entstehen beispielsweise, wenn eine Funktionalität wie Autorisierung nicht in allen produktorientierten Anwendungssystemen wiederverwendet wird.

3.2

Entwicklung der Soll-Architektur auf Anwendungssystemebene

Die Transformation der Ist-Architektur auf Anwendungssystemebene in die Soll-Architektur wird durch Durchführung ausgewählter Anwendungssystem-Entwicklungsprojekte erreicht (vgl. Kummer/Dietzsch 2003). Die Definition bzw. Auswahl dieser Entwicklungsprojekte erfolgt im Rahmen

18

R. Winter

des Informationssystem-Managements häufig auf der Grundlage von Portfolioanalysen (vgl. Österle 1992). Wird wie in der Einleitung dieses Beitrags als Zielsetzung vorrangig die Reduktion von Anwendungssystemund Schnittstellenkosten verfolgt, sind die jeweils geschätzten Kostensenkungsbeiträge Grundlage der Portfoliobildung bzw. der Bewertung der Projektanträge. Zur schrittweisen Erreichung des optimalen Integrationsgrads ist die Summe aus Anwendungssystem- und Schnittstellenkosten zu minimieren (siehe Abschnitt 1). In diesem Abschnitt wird zunächst die Anwendungssystembildung betrachtet. Im Folgenden wird von der Hypothese ausgegangen, dass die durchschnittlichen Kosten der Anwendungssystembildung verringert werden können, wenn eine bereits realisierte Integrationsdimension (Leistung/ Organisation, Funktionalität oder Informationsobjekt) komplett abgedeckt wird, während sich das Anwendungssystem in den beiden jeweils anderen Dimensionen auf wenige Aspekte konzentriert. In diesem Fall ist zu erwarten, dass Entwicklungsprojekte im Rahmen der Architektur-Transformation zur Realisierung von Anwendungssystemen führen, die einer der folgenden drei Klassen zugeordnet werden können: • Vollständige Abwicklung (d.h. Implementierung aller notwendigen, nicht mehrfachverwendbaren Funktionalitäten) für bestimmte Leistungen bzw. alle Leistungen einer bestimmten Organisationseinheit hinsichtlich aller relevanten Informationsobjekte. • Bereitstellung bestimmter, wiederverwendbarer Funktionalitäten für alle Leistungsabwicklungen/Organisationseinheiten und für alle Informationsobjekte. • Umfassende Bewirtschaftung (d.h. Implementierung aller notwendigen Funktionalitäten) für bestimmte Informationsobjekte als wiederverwendbarer Dienst für alle Leistungsabwicklungen/Organisationseinheiten. Eine vierte Klasse umfasst Informationsobjekt-zentrierte Anwendungssysteme, die nicht Geschäftsprozesse, sondern (operative oder nicht-operative) Führungsprozesse unterstützen. Zwar werden durch diese Anwendungssysteme u.U. die gleichen Informationsobjekte bewirtschaftet wie durch „normale“ Informationsobjekt-zentrierte Anwendungssysteme. Es werden jedoch andere Funktionalitäten und möglicherweise andere Organisationseinheiten unterstützt, so dass diese Anwendungssysteme separat betrachtet werden. Die Unterscheidung von vier Klassen von Anwendungssystemen findet sich auch in der Praxis:


19

• Anwendungssysteme, die alle notwendigen, nicht wiederverwendbaren Funktionalitäten für bestimmte Leistungen bzw. alle Leistungen einer bestimmten Organisationseinheit unterstützen, werden als „vertikale“ Anwendungssysteme bezeichnet. • Anwendungssysteme, die bestimmte Funktionalitäten für alle Leistungsabwicklungen/Organisationseinheiten und für alle Informationsobjekte wiederverwendbar anbieten, werden als „horizontale“ Anwendungssysteme bezeichnet. • Anwendungssysteme, die alle notwendigen Funktionalitäten für bestimmte Informationsobjekte als Service für alle Leistungsabwicklungen/Organisationseinheiten wiederverwendbar anbieten, werden häufig als Core Data-Anwendungssysteme bezeichnet. • Anwendungssysteme, die Auswertungsfunktionalitäten für bestimmte Informationsobjekte zur Unterstützung von Führungsprozessen bereitstellen, werden als „analytische“ Anwendungssysteme bezeichnet. Vertikale, horizontale und Core Data-Anwendungssysteme können als transaktionsorientierte Anwendungssysteme generalisiert werden und bilden damit das Gegenstück zu analytischen Anwendungssystemen. Funktionalität Analytische Applikationen

…

…

Hy po Da the rle ken he n Ei nl ag e … n

Partnermanagement Produktdatenmanagement

Call Center SBTerminal WWW Portal Autorisierung

Informations objekt

Abb. 7:

...


„Architektierte“ Anwendungslandschaft

Abbildung 7 zeigt eine Anwendungslandschaft im vorgeschlagenen Architekturmodell, die ausschliesslich Instanzen dieser vier Klassen von Anwendungssystemen umfasst: Neben idealtypisch realisierten vertikalen Anwendungssystemen (Hypotheken-, Darlehens-, Einlagenabwicklung

20

R. Winter

usw.) finden sich idealtypisch realisierte horizontale Anwendungssysteme (Call Center-, SB-Terminal- und WWW-Portal-Unterstützung, Autorisierung usw.), idealtypisch realisierte Core Data-Anwendungssysteme (Partner- und Produktdatenmanagement) sowie analytische Applikationen (z.B. Data Marts für Marketing, Controlling, Produktentwicklung etc.). Wenn ausschliesslich Instanziierungen dieser Typen von Anwendungssystemen realisiert würden, dürfte es in der Anwendungslandschaft keine Überschneidungen und keine ungewollten Lücken geben. Abwicklungsfunktionalitäten, kanalspezifische Funktionalitäten, informationsobjektspezifische Funktionalitäten und analytische Funktionalitäten wären vollständig voneinander getrennt, so dass z.B. im Rahmen des Multikanalmanagements beliebige Zuordnungen vorgenommen werden könnten, ohne dass Restriktionen oder Zwänge durch die bestehende IT-Plattform zu beachten wären. Es sei angemerkt, dass die grafische Darstellung in Abbildung 7 eine kleine Ungenauigkeit enthält, die dem besseren Verständnis dient: Genaugenommen müssten die Blöcke aus vertikalen, horizontalen, Core Dataund analytischen Anwendungssystemen sich jeweils auf unterschiedliche Abschnitte der Modellachsen beziehen (z.B. werden die durch vertikale Anwendungssysteme realisierten Funktionalitäten ja gerade nicht auch durch horizontale Anwendungssysteme abgedeckt). Die korrekte Abbildung würde jedoch zu einer wesentlich komplexeren und schwerer verständlichen Darstellung der idealen Anwendungslandschaft führen. Die am Anfang dieses Abschnitts unterstellte Hypothese ist naheliegend; ihre empirische Validierung ist jedoch noch ausstehend. Im Folgenden wird weiterhin von der Korrektheit dieser Hypothese ausgegangen. Die Anwendung der entsprechenden Gestaltungsregel in Entwicklungsprojekten führt dazu, dass die entstehenden Anwendungssysteme tendenziell immer einem der Idealtypen entsprechen. Insgesamt entwickelt sich dann die Ist-Anwendungslandschaft (siehe z.B. Abb. 6) sukzessiv in Richtung der in Abbildung 7 illustrierten Soll-Anwendungslandschaft. Diese Strukturierung von Anwendungssystemen führt allerdings auch dazu, dass massive Integrationsbedarfe zwischen Anwendungssystemen entstehen. So führt z.B. die Zerlegung einer Geschäftsfall-Abwicklung in produktspezifische, kanalspezifische und informationsspezifische Funktionalitäten dazu, dass für die meisten Geschäftsvorfälle Schnittstellen zwischen jeweils mehreren relevanten Anwendungssystemen implementiert werden müssen. Im folgenden Abschnitt wird deshalb dargestellt, wie für die ideale, die Anwendungssystemkosten minimierende Anwendungslandschaft durch Reduktion der Zahl von Schnittstellen auch die Schnittstellenkosten verringert werden können.


4

21

Nutzung des Architekturmodells für die Schnittstellenbildung

Im vorangehenden Abschnitt ist gezeigt worden, wie eine Soll-Anwendungslandschaft sukzessiv durch Entwicklungsprojekte verwirklicht werden kann, die zu Anwendungssystemen führen, bei denen jeweils eine bestimmte Integrationsdimension im Vordergrund steht. Als Konsequenz darf erwartet werden, dass aufgrund der Integrationszielsetzung relativ wenige Schnittstellen zwischen Anwendungssystemen des gleichen Typs entstehen (z.B. zwischen Hypotheken- und Einlagenabwicklung, zwischen Call Center- und WWW-Portal-Unterstützung oder zwischen Produktdaten- und Partnermanagement). Zwischen Anwendungssystemen verschiedener Typen entstehen jedoch sehr viele Schnittstellen. Diese lassen sich auf Grundlage des Architekturmodells wie folgt klassifizieren: • Analytische Anwendungssysteme beziehen Daten von vertikalen, horizontalen und Core Data-Anwendungssystemen. Diese Klasse von Schnittstellen ist im Normalfall durch reinen Lesezugriff, Historisierung, Notwendigkeit einer Integration und Notwendigkeit umfassender Qualitätssicherung gekennzeichnet (vgl. Devlin 1997). Im schlechtesten Fall ist eine Schnittstelle mit Extraktions- und Aufbereitungsfunktionalitäten für jede Kombination eines transaktionsorientierten und eines analytischen Anwendungssystems zu entwickeln und zu warten. • Vertikale, horizontale und Core Data-Anwendungssysteme tauschen untereinander Daten aus, um die Abwicklung von Geschäftsvorfällen abzubilden. Diese Klasse von Schnittstellen ist durch bidirektionalen Datenfluss, hohe Schnelligkeitsanforderungen (sog. Straight Through Processing) und hohe Aktualitätsanforderungen gekennzeichnet. Auch hier muss im schlechtesten Fall eine Schnittstelle mit Extraktions- und Aufbereitungsfunktionalitäten für jede Kombination zweier transaktionsorientierter Anwendungssysteme entwickelt und gewartet werden. • Sowohl transaktionsorientierte wie auch analytische Anwendungssysteme tauschen Daten mit Anwendungssystemen anderer Unternehmungen aus, um unternehmensübergreifende Geschäftsprozesse zu unterstützen (z.B. gemeinsame Planung der sog. Supply Chain, gemeinsame Nutzung von Kundeninformationen in unternehmensübergreifenden Kundenbindungsprogrammen). Diese Klasse von Schnittstellen ist durch bidirektionalen Datenfluss, u.U. hohe Schnelligkeits- und Aktualitätsfunktionen, aber auch die Problematik der unbestimmten Ownership der ausgetauschten Informationen wie auch der genutzten Schnittstellen gekennzeichnet. Theoretisch muss auch für diese Klasse von

22

R. Winter

Schnittstellen im (allerdings kaum vorstellbaren) schlechtesten Fall eine Schnittstelle mit Extraktions- und Aufbereitungsfunktionalitäten für jede Kombination zweier Anwendungssysteme in den beteiligten Unternehmungen entwickelt und gewartet werden. Obwohl die skizzierten schlechtesten Fälle sehr unwahrscheinlich oder sogar kaum vorstellbar sind, ergeben sich selbst für mittelgrosse Unternehmungen oft Tausende von Schnittstellen zwischen Anwendungssystemen, die entwickelt und gewartet werden müssen. Die Unübersichtlichkeit der Kopplung von Anwendungssystemen sowie die hohen Entwicklungsund Wartungskosten werden deshalb als eines der aktuellen Hauptprobleme der betrieblichen Informationsverarbeitung angesehen (vgl. Gartner Group 2003).

4.1

Nutzung von Integrationssystemen zur Reduktion der Anzahl von Schnittstellen

Inte g tion rasys stem

Der naheliegendste Ansatz zur Reduktion von Schnittstellen ist die Einführung eines zentralen Integrationssystems. Dieses entkoppelt bilaterale Extraktions- und Aufbereitungsfunktionalitäten und bildet damit einen sog. Hub. Müssen im schlechtesten Fall theoretisch n*(n-1)/2 (bidirektionale) Schnittstellen zwischen n Anwendungssystemen entwickelt und gewartet werden, so sind es im Hub and Spoke-Konzept nur noch n Adapter, die jeweils eine (bidirektionale) Schnittstelle zwischen dem jeweiligen Anwendungssystem und dem Hub implementieren. Dieses Konzept wird durch Abbildung 8 illustriert.

Abb. 8:

Bilaterale Schnittstellen (schlechtester Fall, links) vs. Hub and SpokeKonzept (rechts)


23

In den letzten zwanzig Jahren hat die Softwareindustrie drei Typen von Integrationssystemen entwickelt – jeweils einen Integrationssystem-Typ für jede der im vorangehenden Abschnitt vorgestellten Klassen von Schnittstellen: • Data Warehouse-Systeme stellen eine logisch zentrale, konsistente Datenbasis für alle analytischen Anwendungssysteme dar, die durch Integration (d.h. Extraktion, Zusammenführung, Bereinigung und Qualitätssicherung) von Daten aus den verschiedensten transaktionsorientierten Anwendungssystemen gewonnen wird. Im Data Warehousing ersetzen je ein Extraktionsadapter zu jedem relevanten transaktionsorientierten Anwendungssystem und je ein Aufbereitungsadapter zu jedem analytischen Anwendungssystem die ansonsten unvermeidliche Vielzahl bilateraler, direkter Schnittstellen (vgl. Devlin 1997). • Enterprise Application Integration (EAI)-Systeme stellen eine logisch einheitliche Plattform dar, über die alle angeschlossenen transaktionsorientierten Anwendungssysteme Daten und/oder Nachrichten austauschen können. Neben rein datenorientierten Lösungen (Operational Data Stores, vgl. Imhoff 1999) gibt es rein nachrichten- bzw. ereignisorientierte Lösungen verschiedenster Art (z.B. nach dem Message BusPrinzip oder dem Publish and Subscribe-Prinzip), funktional orientierte Lösungen sowie verschiedenste Mischformen (vgl. Schissler et al. 2002). Das gemeinsame Ziel ist, die ansonsten unvermeidliche Vielzahl bilateraler, direkter Schnittstellen zwischen transaktionsorientierten Anwendungssystemen durch jeweils einen Adapter zur Integrationsplattform zu ersetzen (vgl. Rowohl/Schelp 2002). • Die Business Collaboration Infrastructure (BCI) stellt eine Menge von Diensten und Standards dar, die genutzt werden können, um Anwendungssysteme in verschiedenen Unternehmungen zu koppeln. Der Unterschied zwischen EAI-System und BCI besteht darin, dass bei unternehmensübergreifender Integration im Normalfall keines der beteiligten Unternehmen Eigentümer einer solchen Infrastruktur und/oder der ausgetauschten Daten sein will oder sein soll, um die Integration offen und flexibel zu gestalten. Deshalb findet Integration in Interorganisationssystemen auch nicht schwerpunktmässig auf Grundlage einer gemeinsamen (Software-)Plattform statt, sondern durch Nutzung vereinbarter Standards und genereller Dienste. Eine offene und mächtige BCI muss es erlauben, durch Nutzung geeigneter Standards und Dienste die Entwicklung und Wartung bilateraler, direkter Schnittstellen vermeiden zu können (vgl. Cäsar et al. 2002).

24

R. Winter

Obwohl das generelle Prinzip der Einführung einer logisch zentralen Integrationsschicht allen drei Konzepten gemeinsam ist, werden sie völlig unterschiedlich implementiert. Data Warehouse-Systeme integrieren asynchron und rein datenorientiert. EAI-Systeme integrieren synchron, aber je nach Anwendungszweck und Anforderungen eher daten- oder eher nachrichten- bzw. ereignisorientiert. Die BCI schliesslich integriert indirekt und ereignisorientiert, wird aber nicht durch eine dedizierte Infrastruktur implementiert, sondern durch offene Standards und Services, deren Nutzung die Entwicklung und Wartung von Schnittstellen vereinfacht.

4.2

Generische Referenz-Anwendungslandschaft

In Abschnitt 3.2 wurde beschrieben, wie durch gezielte Entwicklungsprojekte „architektierte“ Anwendungssysteme geschaffen werden können, die die Anwendungssystemkosten verringern. Im vorangegangen Abschnitt wurde beschrieben, dass die in einer entsprechend gestalteten Anwendungslandschaft entstehenden Schnittstellen durch Nutzung verschiedener Typen von Integrationssystemen massiv reduziert werden können, wodurch sich die Schnittstellenkosten drastisch verringern. Um den optimalen Integrationsgrad zu erreichen, müssen beide Aktivitäten solange kombiniert werden, bis die durchschnittlichen Kosten der Integration entweder durch „Übernutzung“ von Integrationssystemen oder durch Bildung zu komplexer Anwendungssysteme wieder ansteigen.

Interorganisationssysteme

BCI

Analytische Anwendungssysteme Data Marts Core DataAnwendungss.

Selektion und Aggregation

Data Warehouse-System Externe Daten

Integration und Bereinigung

Vertikale Anwendungssysteme

Horizontale Anwendungssysteme

Staging Channeling

Staging Channeling

EAI

Abb. 9:

Generische Referenz-Anwendungslandschaft einschliesslich Integrationssystemen

Eine generische Darstellung der sich aus architektierten Anwendungssystemen und Integrationssystemen ergebenden Soll-Anwendungslandschaft


25

findet sich in Abbildung 9. Primäre Informationsflüsse werden durch (durchgezogene) gerichtete Kanten, weniger bedeutende Informationsflüsse durch unterbrochene, gerichtete Kanten repräsentiert. Während Datei-Symbole eine eher datenorientierte Integration anzeigen, werden eher nachrichtenorientierte Integrationsformen durch Briefumschläge symbolisiert. Integrationsdienste, Extraktions- und Aufbereitungsfunktionalitäten sowie Anwendungssysteme werden durch Kuben repräsentiert.

5

Zusammenfassung und Ausblick

Als eine der wichtigsten Aufgaben des Integrationsmanagements wurde in diesem Beitrag die auf das Ziel der Minimierung der Anwendungssystemund Schnittstellenkosten gerichtete Gestaltung von Anwendungssystemen und Schnittstellen betrachtet. Es sollte gezeigt werden, dass die Erreichung dieses Ziels durch ein geeignetes Architekturmodell und entsprechende Gestaltungsregeln unterstützt werden kann. Anwendungssysteme entstehen in dieser Sichtweise durch Bündelung von Funktionalitäten, Verantwortlichkeiten und Datennutzung zur Abbildung enger Zusammenhänge; Schnittstellen entstehen durch Trennung weniger enger Zusammenhänge. Es wurde gezeigt, dass bei der sukzessiven Umgestaltung der Anwendungslandschaft die Fokussierung auf eine der Integrationsdimensionen „Funktionalitäts-Wiederverwendung“, „Bezug zu Verantwortlichkeiten/Leistungen“ und „Datennutzung“ bei der Anwendungssystemgestaltung die Anwendungssystemkosten generell gesenkt werden könnten. Durch möglichst umfassende Nutzung aller Typen von Integrationssystemen sollten dann auf dieser Grundlage auch die Schnittstellenkosten gesenkt werden können. Beide Aktivitäten erfolgen in Form einer Vielzahl von Anwendungssystem- bzw. Integrationssystem-Entwicklungsprojekten iterativ und (bei aggregierter Betrachtung) mehr oder weniger kontinuierlich (vgl. Kummer/Dietzsch 2003). Werden die Integrationskosten zeitnah verfolgt, wird es möglich, auf diese Weise den optimalen Integrationsgrad (siehe Abb. 1) zu erreichen. Es wurde ein Architekturmodell auf Anwendungssystemebene sowie entsprechende Abbildungsvorschriften skizziert. Ebenso wurde auf einige durch dieses Modell und die unterstellte Zielsetzung implizierten Gestaltungsregeln eingegangen. Mit Hilfe des vorgestellten Modells können Istund Soll-Anwendungslandschaften abgebildet sowie Probleme und Problemlösungen visualisiert werden.

26

R. Winter

Das Modell und die Gestaltungsregeln wurden in Zusammenarbeit mit Grossunternehmungen des Dienstleistungsbereichs entwickelt und verfeinert. Zwar werden insbesondere das Modell, aber auch die Gestaltungsregeln als sinnvoll und hilfreich angesehen und in der Praxis eingesetzt; zur formalen Validierung des unterstellten Zusammenhangs zwischen dem Aufzeigen des Architekturmanagement-Handlungsbedarfs, der Beachtung der vorgeschlagenen Gestaltungsregeln und der tatsächlichen Senkung der Gesamtkosten bedarf es jedoch noch folgender Ergänzungen bzw. Untersuchungen: • Auf Grundlage des dreidimensionalen Modells sind Metriken zur Quantifizierung von Überlappungen und Lücken zu definieren. • Unter Nutzung dieser Metriken ist durch ausreichend viele Fälle die Hypothese zu validieren, dass die Anwendungssystemkosten verringert werden können, wenn auf nur eine Integrationsdimension fokussiert wird. • Schliesslich müssen die bisher nur qualitativ begründeten Kostenverläufe empirisch validiert werden, ein starker Zusammenhang zwischen Überlappungen und Lücken der Anwendungslandschaft einerseits und Anwendungssystemkosten andererseits muss nachgewiesen werden, und ein starker Zusammenhang zwischen dem Umfang der Nutzung von Integrationssystemen und den Schnittstellenkosten muss ebenfalls nachgewiesen werden Um den Ansatz zu einer vollwertigen Methode des Integrationsmanagements auszubauen, bedarf es neben seiner formalen Validierung noch der Ergänzung um Techniken zur Klassifikation von Integrationsprojekten bzw. Integrationsszenarien sowie um Techniken zur Wirtschaftlichkeitsanalyse (ex ante und ex post) von Integrationsprojekten. Daneben sind entsprechende Rollenmodelle, Referenzprozessmodelle und schliesslich ein umfassendes Informationsmodell (als Grundlage des Metadatenmanagements) zu entwickeln sowie zu validieren. Eine entsprechend ergänzte und validierte Integrationsmethode auf Anwendungssystemebene sollte es dann ermöglichen, diesen Problembereich der Wirtschaftsinformatik soweit zu strukturieren und zu standardisieren, dass systematisches Architekturmanagement und letztlich ArchitekturBenchmarking möglich wird. Angesichts des hohen Anteils von Integrationskosten an den Gesamtkosten der betrieblichen Informationsverarbeitung würde damit ein wichtiges Instrumentarium zur Effizienzsteigerung geschaffen.


27

Literatur Cäsar, M.; Alt, R.; Grau, J.: Collaboration in the consumer product goods industry – Analysis of marketplaces. Proceedings of 10th European Conference on Information Systems (ECIS), Gdansk, 2002. Devlin, B.: Data Warehouse – from Architecture to Implementation, Reading et al. 1997. Ferstl, O.K.; Sinz, E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, in: Wirtschaftsinformatik, 37 (1995), 3, S. 209-220. Frank, U.: Multiperspektivische Unternehmensmodellierung: theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung, München/Wien, 1994. Fraser, M.D.; Kumar K.; Vaishnavi, V.K.: Strategies for Incorporating Formal Specifications in Software Development, Communications of the ACM, 37 (1994), 10, S. 74-85. Frese, E.: Grundlagen der Organisation. Konzept – Prinzipien – Strukturen, 6. Aufl., Wiesbaden, 1995. Gartner Group: Application Integration and Middleware Top of the CIO’s List, January 2003, http://www.gartner.com/webletter/rte_vendor_230103/html/ aim_top_of_the_CIOs_list.htm, Abruf am 2003-01-27. O.V.: Business Systems Planning – Information Systems Planning Guide, 4th ed., IBM-Form GE20-0527-4, Atlanta, 1984. O.V.: Promet® STP, Methodenhandbuch für die System- und Technologieplanung, Version 1.1, St. Gallen, 2000. Imhoff, C.: The Corporate Information Factory, DM Review, December 1999, http://www.dmreview.com/editorial/dmreview, Abruf am 2000-03-29. Krcmar, H.: Bedeutung und Ziele von Informationssystem-Architekturen, Wirtschaftsinformatik, 32 (1990), 5, S. 395-402. Krcmar, H.: Informationsmanagement, 3. Aufl., Berlin et al., 2003. Kummer, P.; Dietzsch, A.: Architekturmanagement bei der Schweizerischen Mobiliar, Vortragsunterlagen, Business Engineering Center, Universität St. Gallen 2003, http://bec.unisg.ch, Abruf am 2003-01-25. Lehner, F.; Maier, R.; Hildebrand, K.: Wirtschaftsinformatik: theoretische Grundlagen, Wien, 1995.

28

R. Winter

Leist, S.: Bankenarchitektur des Informationszeitalters – Zielsetzung und Gestaltungsebenen, in: Leist, S.; Winter, R. (Hrsg.): Retail Banking im Informationszeitalter, Berlin et al., 2002, S. 4-28. Leist, S.; Winter, R.: Optimal Allocation of Standardized Application Software Packages to Business Process Steps – A Simulation Study Based on Communication and Automation Costs, in: Larsen, T.J.; Levine, L.; deGross, J.I. (Eds.): Information Systems – Current Issues and Future Changes, Laxenburg, 1998, pp. 439-454. Leist, S.; Winter, R.: Component-based Banking – Modularization and Information Processing in Banks as a Foundation for Virtual Business, in: Abramowicz, W. (Ed.): Business Information Systems BIS’99, pp. 125-134. Malhotra, Y.: Enterprise Architecture: An Overview, @BRINT Research Institute 1996, http://www.brint.com/papers/enterarch.htm, Abruf am 2002-09-13. Martin, R.; Robertson, E.: A Formal Enterprise Architecture Framework to Support Multi-model Analysis, Proc. 5th CAiSE/IFIP8.1 international workshop on evaluation of modeling methods in systems analysis and design, Stockholm, 2000. Meyer, M.; Strauch, B.: Organisationskonzepte im Data Warehousing, in: Jung, R.; Winter, R. (Hrsg.): Data Warehousing Strategie, Berlin et al., 2000, S. 79100. McDavid, D. W.: A standard for business architecture description, IBM Systems Journal 38 (1999), 1, pp. 12-31. Österle, H.; Blessing, D.: Business Engineering Model, in: Österle, H.; Winter, R. (Hrsg:): Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, Berlin et al., 2000, S. 61-81. Österle, H.; Brenner, W.; Hilbers, K.: Unternehmensführung und Informationssystem, Stuttgart, 1992. Penzel, H.-G.: Die Universalbank neuen Typs – mit einer Informationstechnologie neuen Typs, in: Proc. of the Third Conference on Innovations in the Banking Industry (CIBI 2002), Institut für Bankinformatik, Regensburg, 2002. Rosemann, M.: Gegenstand und Aufgaben des Integrationsmanagements, in: Scheer, A.-W.; Rosemann, M.; Schütte, R. (Hrsg.): Integrationsmanagement, Arbeitsbericht Nr. 65 des Instituts für Wirtschaftsinformatik, Westfälische Wilhelms-Universität, Münster, 1999. Rowohl, F.; Schelp, J.: Enterprise Application Integration, in: Khosrowpour, M. (Ed.): Issues & Trends of Information Technology Management in Contemporary Organizations, Idea Group Publishing, Hershey et al. 2002, pp. 775-779.


29

Rummler, G.A.; Brache, A.P.: Improving Performance – How to Manage the White Space on the Organization Chart, 2nd ed., San Francisco, 1995. Scheer, A.W.: Wirtschaftsinformatik, 6. Aufl., Berlin et al., 1995. Scheer, A.-W.: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen, 4. Aufl., Berlin et al., 2001. Schierenbeck, H.: Die Vertriebskanäle der Zukunft im Privatkundengeschäft, in: Basler Bankenvereinigung (Hrsg.): Multi Channel Distribution im Banking – Tagungsband zum 6. Basler Bankentag, Bern,1999, S. 3-49. Schmalzl, J.: Architekturmodelle zur Planung der Informationsverarbeitung von Kreditinstituten, Heidelberg, 1995. Schissler, M.; Mantel, S.; Ferstl, O.K.; Sinz, E.J.: Kopplungsarchitekturen zur überbetrieblichen Integration von Anwendungssystemen und ihre Realisierung mit SAP R/3, Wirtschaftsinformatik, 44 (2002), 5, S. 459-468. Schönsleben, P.; Leuzinger, R.: Innovative Gestaltung von Versicherungsprodukten: flexible Industriekonzepte in der Assekuranz, Wiesbaden, 1996. Sinz, E.J.: Architektur von Informationssystemen, in: Rechenberg, P.; Pomberger, G. (Hrsg.): Informatikhandbuch, München, 1997, S. 875-887. Spitzer, P.: Gesamtarchitektur aus Sicht der HVB Group, in: Proc. of the Third Conference on Innovations in the Banking Industry (CIBI 2002), Institut für Bankinformatik, Regensburg, 2002. van Dillen, R.: Die Anwendungslandschaft als Werkzeug für die Bildung von Applikationen, in: Leist, S.; Winter, R. (Hrsg.): Retail Banking im Informationszeitalter, Berlin, 2002, S. 221-237. Winter, R.: Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur, in: Schmidt, H. (Hrsg.): Modellierung betrieblicher Informationssysteme (Proc. der MobIS-Fachtagung 2000), Rundbrief der GI-Fachgruppe 5.10, 7 (2000), 1, S. 23-38. Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, erscheint in: Österle, H.; Winter, R. (Hrsg.): Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Aufl., Berlin et al., 2003. Youngs, R.; Redmond-Pyle, D.; Spaas, P.; Kahan, E.: A standard for architecture description, IBM Systems Journal 38 (1999), 1, pp. 32-50. Zachman, J.A.: A framework for information systems architecture, IBM Systems Journal 26 (1987), 3; reprinted in IBM Systems Journal 38 (1999), 2&3, pp. 454-470. Zachman, J.A.: Enterprise Architecture: The Past and the Future, DM Review, December 1999, http://dmreview.com, Abruf am 2002-09-1

Entwurfsmusterbasierter Ansatz zur Systematisierung von Applikationsbeziehungen im Business Engineering Alexander Schwinn Universität St. Gallen

Applikationsarchitekturen grosser Unternehmen stellen eine komplexe, vernetzte Struktur von Applikationen dar. Zwischen den einzelnen Applikationen müssen oft Informationen ausgetauscht und Funktionsparameter übergeben werden, um eine reibungslose Verarbeitung von Prozessen zu gewährleisten. Die dadurch entstehenden Applikationsbeziehungen können sehr vielseitig sein. Der vorliegende Beitrag versucht, diese Beziehungen anhand eines Entwurfsmusteransatzes (Design Patterns) zu systematisieren. Die entwickelten Entwurfsmuster sollen in der Designphase von Integrationsprojekten eine konstruktive Hilfestellung leisten, um die Probleme und die korrespondierenden Lösungen besser zu verstehen. Zudem sollen sie helfen eine gemeinsame Sprache zu entwickeln, um die Kommunikation in einem interdisziplinären Entwicklungsteam, das bei Integrationsprojekten meist vorzufinden ist, zu erleichtern.

1 2 3

4

5

Einleitung ................................................................................................... 32 Grundlagen ................................................................................................. 32 Vorhandene Entwurfsmusteransätze ...................................................... 38 3.1 Entwurfsmuster von Gamma et al. ................................................. 38 3.2 Patterns for e-Business ..................................................................... 41 3.3 EAI-Architekturmuster nach Lutz .................................................. 47 Entwicklung von Entwurfsmustern für Integrationsbeziehungen ...... 49 4.1 Muster vom Typ Informationsbedarf ............................................. 50 4.2 Muster vom Typ Verarbeitungsauftrag .......................................... 53 Zusammenfassung..................................................................................... 57

32

1

A. Schwinn

Einleitung

Diese Arbeit entstand im Rahmen des Kompetenzzentrums Application Integration Management (CC AIM). Ein Schwerpunkt dieses Forschungsprojekts ist die Entwicklung einer geeigneten Technik zur systematischen Darstellung von Applikationen und deren Beziehungen auf unterschiedlichen Abstraktionsniveaus. Zur Systematisierung von Applikationsbeziehungen wurde ein Entwurfsmusteransatz gewählt, wie er sich schon in anderen Design-Disziplinen (z.B. der objektorientierten Softwareentwicklung) bewährt hat. Dieser entwickelte Ansatz wird in dem vorliegenden Beitrag behandelt. Zunächst wird das Verständnis von Applikationen und der Applikationsintegration im Business Engineering (BE) sowie das Konzept von Entwurfsmustern vorgestellt. Anschliessend werden vorhandene Entwurfsmusteransätze vorgestellt, die sich der Integrationsthematik widmen. Darauf aufbauend wird ein neuer Musteransatz vorgeschlagen, der sich durch Unabhängigkeit von konkreten Implementierungen, Produkten und Technologien auszeichnet und vor allem die fachkonzeptionellen Anforderungen bei der Integration von Applikationen berücksichtigt. Die identifizierten Muster werden dabei nach einem fest vorgegebenen Raster durchgängig beschrieben und dokumentiert.

2

Grundlagen

In der Wirtschaftsinformatik wird unter dem Begriff Integration die Verknüpfung von Menschen, Aufgaben und Technik zu einer Einheit verstanden (vgl. Mertens 2000, S. 1). Der Fokus des Beitrags ist die Integration von Informationen und Funktionen zwischen Applikationen. Die Applikationsintegration wird häufig unter dem Stichwort „Enterprise Application Integration“ (EAI) diskutiert. Ruh et al. verstehen darunter die Erstellung neuer Business-Anforderungen durch Integration vorhandener Informationen und Funktionen durch Einsatz von einheitlicher Middleware (vgl. Ruh et al. 2001, S. 2). EAI ist die Reaktion auf die jahrzehntelange Entwicklung monolithischer Applikationen, die isoliert voneinander für spezielle Aufgaben entwickelt worden sind (vgl. Linthicum 2000, S. 3). EAI soll die uneingeschränkte Nutzung aller Informationen und Geschäftsprozesse zwischen allen Informationssystemen innerhalb des Unternehmens ermöglichen. Innerhalb des Business Engineering ist die Applikationsintegration auf der Systemebene, insbesondere der Applikationsebene angesiedelt.

Entwurfsmusterbasierter Ansatz

33

Abbildung 1 zeigt das integrationsspezifische Metamodell der Systemebene des Business Engineering. 6\VWHPHEHQH

HUI¾OOW

LVW1XW]HULQ LVW,QSXWI¾ULVW2XWSXWYRQ HQWK¦OW

$SSOLNDWLRQVIXQNWLRQ

RSHULHUWDXI

$SSOLNDWLRQ YHUZDOWHW

,QIRUPDWLRQVREMHNW

IDFKO,QWHJUDWLRQV EH]LHKXQJ WDXVFKWDXV

LVW,QSXWI¾ULVW2XWSXWYRQ

6FKQLWWVWHOOH

ELHWHWDQ

'DWHQREMHNW

'DWHQVSHLFKHU REMHNW

'DWHQVSHLFKHU

,QWHJUDWLRQV EH]LHKXQJ

ZLUGUHDOLVLHUWGXUFK

RSHULHUWDXI

6:.RPSRQHQWH YHUZDOWHW

OLHJW YRUDOV

HQWK¦OW

LVW]XJH RUGQHW

ELHWHWDQ

0HWKRGH

6RIWZDUHNRPSRQHQWHQ 'DWHQVWUXNWXUHEHQH

fachl. Integrationsanforderung

LVW$QELHWHULQ

UHDOLVLHUW

$SSOLNDWLRQVHEHQH

)XQNWLRQ

LVW1XW]HULQ LVW$QELHWHULQ

Middlewarekomponente

$QZHQGXQJVEH]RJHQH6LFKW

$QZHQGXQJVQHXWUDOH 6LFKW

Abb. 1: Integrationsspezifisches Metamodell der Systemebene des Business Engineering

Sowohl auf der Applikations- wie auch auf der Software- und Datenstrukturebene können Infrastrukturfunktionalitäten betrachtet werden. Deshalb werden im Folgenden zwei Sichten auf die Systemebene betrachtet: Eine anwendungsbezogene Sicht und eine anwendungsneutrale Sicht. Die anwendungsbezogene Sicht betrachtet ausschliesslich Elemente, die unmittelbaren Anwendungsbezug haben, d.h. Elemente der Applikationsebene können immer auf eine spezifizierte Aktivität der Prozessebene referenziert werden und Softwarekomponenten/Datenstrukturen können immer auf eine Applikation der Applikationsebene referenziert werden. Anwendungsneutrale Elemente der jeweiligen Ebene dienen nicht der unmittelbaren Umsetzung von Aktivitäten der Prozessebene, sondern bieten unterstützende Dienste auf der jeweiligen Ebene an. Im Folgenden werden die anwendungsbezogenen und anwendungsneutralen Elemente der Applikationsebene näher spezifiziert. Da in dieser Arbeit die Integration im Vordergrund steht, werden diejenigen Infrastrukturkomponenten betrach-

34

A. Schwinn

tet, die in direktem Zusammenhang mit Integrationsfragestellungen stehen. Stehen andere Fragestellungen im Vordergrund, lässt sich das anwendungsneutrale Metamodell leicht anpassen, indem die anwendungsneutralen Komponenten ersetzt werden. Liegt beispielsweise der Schwerpunkt auf der Erstellung einer Sicherheitsarchitektur, wären als Infrastrukturkomponenten der Applikationsebene beispielsweise unterschiedliche Authentifizierungsverfahren denkbar. Die zentralen anwendungsbezogenen Begriffe der Applikationsebene sind Funktionen, Applikationen, Applikationsfunktionen und Informationsobjekte. Diese werden wie folgt definiert: Eine (Geschäfts-)Funktion ist eine Verarbeitungseinheit, die aus einer geschäftlichen (betriebswirtschaftlichen) Perspektive erhoben wurde und durch eine Applikationsfunktion ausgeführt wird. Bei einer (Geschäfts-)Funktion handelt es sich um eine nicht-redundante Beschreibung einer Funktion, die auf Aktivitäten oder Aufgaben der Prozessebene verweist. Sie dient unter anderem dazu, Redundanzen von Applikationsfunktionen aufzudecken (Funktionen können in mehreren Applikationsfunktionen realisiert sein). In der Regel benötigen Geschäftsfunktionen Eingabeinformationen und erzeugen Ausgabeinformationen. Dazu ist es notwendig, dass Informationsobjekte existieren: Ein Informationsobjekt stellt eine Sammlung von auf Dauer gespeicherten Informationen dar, auf die wiederholt zurückgegriffen wird. Das Informationsobjekt stellt die Eingabeinformation für eine oder mehrere Applikationsfunktionen zur Verfügung. Eine oder mehrere Applikationsfunktionen erzeugen, verändern oder löschen als Ausgabe Informationen in Informationsobjekten. Aus der Funktions-Definition geht hervor, dass alle von Applikationen ausgeführten Funktionen auf geschäftliche Aufgaben oder Aktivitäten zurückgeführt werden können. Hier wird nicht davon davon ausgegangen, dass jede Funktion von genau einer Applikationsfunktion realisiert wird, sondern dass gleiche Funktionen auch von mehreren Applikationsfunktionen realisiert werden können. Der Idealzustand wäre zwar, dass jede Funktion nur einmal von einer Applikation realisiert wird, jedoch existieren in der Realität häufig funktionale Redundanzen. Um diese Unterscheidung treffen zu können, wird der Begriff der Applikationsfunktion eingeführt:


35

Eine Applikationsfunktion realisiert eine (Geschäfts-)Funktion und ist Bestandteil einer Applikation. Applikationsfunktionen benötigen als Input Informationsobjekte oder Erzeugen als Ausgabe neue oder veränderte Informationsobjekte. Aus der logischen Zusammenfassung von Applikationsfunktionen und Informationsobjekten lässt sich die hier verwendete Definition einer Applikation ableiten: Eine Applikation enthält Applikationsfunktionen, die eine oder mehrere Funktionen auf Basis von Informationstechnologie realisieren. Die Zusammenfassung mehrerer Applikationsfunktionen und ihren Operationen auf Informationsobjekten bildet die Applikation. Neben den anwendungsbezogenen Elementen existieren – wie bereits erwähnt – ebenso Infrastrukturkomponenten auf der Applikationsebene. Da die Integration von Applikationen betrachtet wird, werden hier die zur Unterstützung der Integration spezifischen Komponenten betrachtet. Sie werden auf der Applikationsebene als fachliche Integrationsbeziehungen bezeichnet: Eine fachliche Integrationsbeziehung ist eine Beziehung zwischen zwei Applikationsfunktionen. Eine fachliche Integrationsbeziehung entsteht immer dann, wenn eine Applikationsfunktion (Nutzer) ein Informationsobjekt oder eine Applikationsfunktion einer anderen Applikation (Anbieter) benötigt, um die Ausführung einer Funktion zu ermöglichen (Integrationsbedarf). In fachlichen Integrationsbezie-hungen werden gegebenenfalls Informationsobjekte ausgetauscht. Die Gestaltung dieser Beziehung wird allgemein auch als Applikations-integration bezeichnet. Die unterschiedlichen Arten von fachlichen Integrationsbeziehungen sollen so spezifiziert werden, dass sie bestimmte fachliche Integrationsanforderungen erfüllen (z.B. Forderung nach Verarbeitungs-autonomie, Anforderungen an die Aktualität von Informationsobjekten, usw.). Zur Systematisierung dieser fachlichen Integrationsbeziehungen schlägt dieser Beitrag einen entwurfsmusterbasierten Ansatz vor. Im Folgenden werden zunächst Entwurfsmuster eingeführt. Traditionell wurden und werden Entwurfsmuster (Design Patterns) in der objektorientierten Softwareentwicklung (OOSE) entwickelt und eingesetzt. Mitte der 90er Jahre wurden sie vor allem durch Arbeiten von Gamma et

36

A. Schwinn

al. (1995) berühmt. Sie dienen zur Lösung immer wiederkehrender, ähnlicher Entwurfprobleme in der Softwareentwicklung. Durch Einsatz von Entwurfsmustern soll vor allem die Flexibilität und die Wiederverwendbarkeit von Software erhöht werden (vgl. Gamma et al. 1996, S. 2). Mittlerweile werden in den unterschiedlichsten Bereichen (z.B. Organisationsgestaltung, Architekturgestaltung, Softwareentwicklung, usw.) und Disziplinen (Informatik, Wirtschaftswissenschaften, Architektur, usw.) Entwurfsmuster verwendet und Sprachen zur Definition von Mustern in den jeweiligen Disziplinen entwickelt (vgl. dazu beispielsweise die Arbeit von Klose 2002). Die Definition eines Entwurfsmusters von Alexander et al. aus dem Jahre 1977, der über Muster in Gebäuden und Städten spricht, kann ebenso für diese Arbeit übernommen werden: „Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice.“ Zur Formalisierung und Dokumentation von Entwurfsmustern wurden von Gamma vier grundlegende Eigenschaften festgelegt, die ein Muster besitzt: der Name des Musters, die Problembeschreibung, die Lösung und die Konsequenzen, die die Anwendung des entsprechenden Musters impliziert (vgl. Gamma et al. 1996, S. 3). In der Literatur werden zahlreiche Ziele und Zwecke von Entwurfsmustern genannt: „Patterns represent distilled experience which, through their assimilation, convey expert insight and knowledge to inexpert developers.“ (Appleton 2000), „Capture design experience in a form that people can use effectively to inexpert developers.“ (Gamma et al. 1995), „Design patterns provide a common vocabulary for designers to use to communicate, document, and explore design alternatives. Designing patterns make a system seem less complex by letting you talk about it at a higher level of abstraction […]“ (Gamma et al. 1995), „Reusing design experience is difficult, however, because good design decisions often remain hidden in the designer’s mind and thus are difficult to share.“ (Rossi et al. 1999) oder „A design pattern attempts to collect experience from the expert to pass on to other experts or novices in the field, hence avoiding others reinventing them.“ (German/Cowan 1999). Aus diesen und weiteren Zitaten lassen sich nach Klose grundsätzlich drei Ziele von Entwurfsmustern ableiten (vgl. Klose 2002, S. 114): Die konstruktive Unterstützung des Designprozesses, der Wissensaufbau und -erhalt und die Entwicklung einer gemeinsamen Sprache zur Unterstützung des interdisziplinären Designprozesses. Entwurfsmuster dokumentieren Wissen über bekannte, immer wiederkehrende Problemtypen und Anwendungsszenarios und die dazugehörigen bewährten Lösungen. Dabei soll das Entwurfsmuster in einer leicht ver-


37

ständlichen Form beschrieben werden, so dass nicht nur Experten Problemsituationen verstehen und geeignete Lösungen entwickeln können. Damit die entwickelten Entwurfsmuster lange Gültigkeit besitzen, bzw. über einen längeren Zeitraum anwendbar sein sollen, sollten sie unabhängig von unterschiedlichen Implementierungen (z.B. verwendeten Programmiersprachen) und verwendeter Infrastruktur (z.B. Netzwerkprotokolle, Betriebssysteme) und eingesetzten Softwarepaketen (Datenbanksysteme, ERP-Systeme, CRM-Systeme, usw.) sein. Ein weiterer Zweck ist die Verwendung der Entwurfsmuster zur Aus- und Weiterbildung von Designern und Architekten. Zudem soll nach Gamma et al. (1995) und German/Cowan (1999) der Einsatz von Entwurfsmustern die Effizienz des Designprozesses steigern. Der Wissensaufbau und -erhalt soll durch die Entwicklung und den Einsatz von Entwurfsmustern sichergestellt werden, indem das implizite Wissen in den Köpfen erfahrener Designer durch Dokumentation von Entwurfsmustern expliziert wird. Auch im Falle der Applikationsintegration handelt es sich um ein interdisziplinäres Designteam: Architekten, Softwareentwickler, Vertreter aus Fachabteilungen, Vertreter vom Infrastrukturbetrieb, gegebenenfalls externe Mitarbeiter, usw. Entwurfsmuster helfen dabei ein gemeinsames Verständnis von der Problemsituation und der Lösung zu bekommen, indem eine Sprache vorliegt, die von allen Beteiligten leicht verstanden wird. Die Sprache der Entwurfsmuster in ihrer Funktion als Lingua Franca ist daher von entscheidender Bedeutung für den Erfolg des Designprozesses (vgl. Perzel/Kane 1999; Erickson 2000). Die folgenden Abschnitte stellen zunächst einige vorhandene Entwurfsmusteransätze vor, die im Bereich der Applikationsintegration entwickelt wurden oder diesbezüglich angepasst werden können. Anschliessend wird der neue Ansatz eingeführt, der in Zusammenarbeit mit zahlreichen Vertretern aus der Praxis und ausgehend von den vorhandenen Ansätzen entwickelt worden ist.

38

3

A. Schwinn

Vorhandene Entwurfsmusteransätze

Im Folgenden werden drei verschiedene Musteransätze zur Applikationsintegration vorgestellt: Der Ansatz von Gamma et al. (1995) stellt den wohl bekanntesten Ansatz zu Entwurfsmustern dar, wenngleich dieser nicht die Applikationsintegration fokussiert. Er zeigt jedoch die Vorgehensweise zur Entwicklung neuer Entwurfsmuster auf. Zudem lassen sich einige der Muster von Gamma et al. (1995) auf die Applikationsintegration übertragen, was im Folgenden aufgezeigt wird. Der zweite hier vorgestellte Ansatz „Patterns for e-Business“ wurde von IBM entwickelt (vgl. Adams et al. 2001; O.V. 2002). Ein Teil dieses Ansatzes beschäftigt sich explizit mit der Applikationsintegration. Als dritter Ansatz werden die von Lutz entwickelten EAI-Architekturmuster vorgestellt, die sich ausschliesslich der Applikationsintegration widmen (vgl. Lutz 2000).

3.1

Entwurfsmuster von Gamma et al.

Zwar wurden die Entwurfsmuster von Gamma et al. (1995) vorrangig für den objektorientierten Softwareentwurf entwickelt, jedoch können einige der Muster ebenso auf Integrationsaspekte übertragen werden. Zudem zeigen Gamma et al. (1995) auf, wie neue Entwurfsmuster zu erstellen sind, die optimal auf die entsprechenden Anforderungen angepasst sind. Neue Entwurfsmuster zu entwickeln ist immer dann sinnvoll, wenn ein ähnliches Problem immer wieder auftritt. Nur dann kann ein Entwurfsmuster auch mehrfach angewendet werden – ein Hauptnutzen von Entwurfsmustern, nämlich die Wiederverwendbarkeit, kann dadurch gewährleistet werden.Im Folgenden werden einige klassische Entwurfsmuster von Gamma et al. (1995) in gekürzter Form vorgestellt und dabei erläutert, inwieweit diese auch bei der Integration von Applikationen angewendet werden können. Gamma beschreibt jedes Muster mit den Attributen Mustername und Klassifizierung, Zweck, Motivation, Anwendbarkeit, Struktur, Teilnehmer, Interaktionen, Konsequenzen, Beispielcode, bekannte Verwendungen und verwandte Muster (vgl. Gamma et al. 1995, S. 8ff.). Name des Musters: Adapter Definition nach Gamma et al. (1996, S. 171) „Passe die Schnittstelle einer Klasse an eine andere von ihren Klienten erwartete Schnittstelle an. Das Adaptermuster lässt Klassen zusammenarbeiten, die wegen inkompatibler Schnittstellen ansonsten dazu nicht in der Lage wären.“


39

Relevanz in Bezug auf Anwendungsintegration Auch bei der Integration von Applikationen steht man häufig vor dem wiederkehrenden Problem: unterschiedliche Applikationen mit inkompatiblen Schnittstellen müssen miteinander integriert werden. Adapter werden häufig eingesetzt, um eine syntaktische oder semantische Vereinheitlichung von Schnittstellen zu erreichen. Auch in anderen Ansätzen ist das Adapter-Muster vorzufinden (vgl. Lutz 2000; Adams et al. 2001; O.V. 2002). Tab. 1:

Adapter-Muster

Name des Musters: Façade Definition nach Gamma et al. (1996, S. 212) „Eine Fassade bietet eine einheitliche Schnittstelle zu einer Menge von Schnittstellen eines Subsystems. Die Fassade definiert eine abstrakte Schnittstelle, welche die Verwendung des Subsystems vereinfacht.“ Relevanz in Bezug auf Anwendungsintegration Das Fassade-Muster kann direkt auf die Anwendungsintegration übertragen werden, denn auch hier werden zur Reduktion der Komplexität mehrere Schnittstellen zu einer zusammengefasst. Ein Beispiel, das dem Fassade-Muster sehr ähnlich ist, wäre das Aggregator-Muster in dem Ansatz von Adams et al. (2001) und O.V. (2002) (siehe Folgeabschnitt). Tab. 2:

Façade-Muster

Name des Musters: Stellvertreter (Proxy) Definition nach Gamma et al. (1996, S. 254) „Kontrolliere den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts.“ Relevanz in Bezug auf Anwendungsintegration Das Proxy-Muster tritt bei der Anwendungsintegration auf, wenn ein transparenter Zugriff (beispielsweise bei verteilten Rechenzentren) erfolgen soll, d.h. für den Client ist es nicht ersichtlich, auf welche physischen Ressourcen er zugreift. Tab. 3:

Proxy-Muster

40

A. Schwinn

Name des Musters: Vermittler (Mediator) Definition nach Gamma et al. (1996, S. 385) „Definiere ein Objekt, welches das Zusammenspiel einer Menge von Objekten in sich kapselt. Vermittler fördern lose Kopplung, indem sie Objekte davon abhalten, aufeinander explizit Bezug zu nehmen. Sie ermöglichen es ihnen, das Zusammenspiel der Objekte von ihnen unabhängig zu variieren.“ Relevanz in Bezug auf Anwendungsintegration Das Muster Mediator wurde, bezogen auf Applikationsintegrationsaspekte auch beschrieben in Adams et al. (2001), O.V. (2002) und Lutz (2000). Oft ist ein Vermittler in der EAI-Schicht anzutreffen, in der Aufgaben wie Transformation, Komposition, Aggregation, usw. von Nachrichten angesiedelt sind. Tab. 4:

Mediator-Muster

Name des Musters: Beobachter (Observer) Definition nach Gamma et al. (1996, S. 287) „Definiere eine 1:n-Abhängigkeit zwischen Objekten, so dass die Änderung des Zustands eines Objekts dazu führt, dass alle abhängigen Objekte benachrichtigt und automatisch aktualisiert werden.“ Relevanz in Bezug auf Anwendungsintegration Das Observer-Pattern wird bei der Integration von Applikationen sehr häufig eingesetzt. Vor allem bei der Verteilung von Informationen an mehrere Applikationen nach dem Publish/Subscribe-Prinzip. Der Publisher gibt dabei Änderungen bekannt. Er muss dazu nicht notwendigerweise die Subscriber (Abonnenten) kennen. Hierdurch entsteht eine lose gekoppelte Informationsverteilung. Tab. 5:

Observer-Muster

Die hier vorgestellten Entwurfsmuster von Gamma et al. (1995) stellen nur eine kleine Auswahl dar, um sich ein Bild davon machen zu können, wie vorhandene Entwurfsmuster aus der objektorientierten Softwareentwicklung auf Integrationsaspekte übertragen werden können. Der Hauptunterschied zwischen den Entwurfsmustern nach Gamma et al. (1995) und dem Schwerpunkt dieser Arbeit ist der Betrachtungsfokus: Architekturmuster betrachten systemweite Zusammenhänge, während Gamma kleinere Einheiten (einzelne Softwarekomponenten) betrachtet und nicht den systemweiten Gesamtzusammenhang. Jedoch liefert Gamma, als bekanntester Vertreter von Entwurfsmustern, eine Anleitung zum Erstellen neuer Mus-


41

ter und zeigt, in welchen begründeten Fällen das Erstellen neuer Muster sinnvoll ist. Im nächsten Abschnitt wird ein Ansatz vorgestellt, der ebenso auf die Verwendung von Entwurfsmustern als Hilfsmittel zurückgreift. Dieser Ansatz wurde/wird von IBM entwickelt.

3.2

Patterns for e-Business

Im Rahmen der sehr umfangreich dokumentierten „Patterns for e-business“ (vgl. Adams et al. 2001; O.V. 2002)1 entwickelte IBM diverse Entwurfsmuster, die speziell für die Applikationsintegration vorgesehen sind. Die Muster zur Applikationsintegration unterscheiden sich von den anderen Mustern darin, dass sie keine Geschäftslösungen bereitstellen, sondern die Implementierung bestimmter Geschäftsmodelle unterstützen. Sie dienen zur Integration mehrerer Applikationen, Informationsquellen oder der Integration verschiedener Muster. Die Muster zur Applikationsintegration betrachten nur die Backend-Integration und sind für Benutzer transparent. Die Integrationsmuster stellen dabei nur einen Teil einer sehr umfangreichen Sammlung von Entwurfsmustern dar. Bei den Integrationsmustern unterscheiden Adams et al. (2001) und O.V. (2002) zwischen „Access Integration“ und „Application Integration“. Bei „Access Integration“ handelt es sich um Muster, die Benutzern einen einheitlichen, konsistenten und nahtlosen Zugang zu Applikationen verschaffen (z.B. Web SinglSign-On Muster). Bei den „Application Integration“ Mustern werden nicht Applikationen mit Benutzern, sondern Applikationen untereinander integriert. Vor dem Hintergrund, dass sich dieser Beitrag auf die Integration von Applikationen konzentriert, werden im Folgenden nur die Muster der Kategorie „Application Integration“ berücksichtigt. In Adams et al. (2001) und O.V. (2002) werden die Muster für die Applikationsintegration in zwei Hauptkategorien eingeteilt: Prozess- und datenorientierte Muster. Prozessorientierte Integrationsmuster werden verwendet, um mehrere automatisierte Geschäftsprozesse miteinander zu kombinieren, um beispielsweise neue Geschäftsanforderungen umzusetzen oder um eine konsolidierte Sicht auf eine Geschäftsentität zu bekommen (z.B. geschäftsbereichsübergreifende Gesamtsicht auf einen Kunden). Die prozessorientierten Muster fokussieren die transaktionale Steuerung und Verarbeitung von Prozessen. Datenorientierte Muster eignen sich vor allem, 1

Die „Patterns for e-business“ sind zudem online unter O.V. (2002) zu finden. Die Online-Version ist teilweise aktueller und umfangreicher.

42

A. Schwinn

wenn ein Informationsaustausch zwischen Applikationen oder die gemeinsame Nutzung von Informationen durch Applikationen im Vordergrund stehen. Jedoch kann dazu auch ein prozessorientiertes Muster zur Anwendung kommen, wenn besondere transaktionale Anforderungen an die Integration gestellt werden. Datenorientierte Muster beeinflussen im Gegensatz zu prozessorientierten Mustern nicht die Applikationslogik, sondern operieren in dem Ansatz von Adams et al. (2001) und O.V. (2002) auf der Datenbankebene. Sowohl für die prozess-, wie auch für die datenorientierten Muster wurden gemeinsame, allgemeine Dienste definiert, die unabhängig von den jeweiligen Ausprägungen eines Musters vorhanden sein müssen. Tabelle 6 stellt diese allgemeinen technischen EAI-Dienste für die prozess- und datenorientierten Muster zusammenfassend dar. Allgemeine Dienste für prozessorientierte Muster Dienst

Aufgabe

Protokolladapter

Wenn zwei oder mehr zu integrierende Applikationen unterschiedliche Kommunikationsprotokolle verwenden, und die Applikationen selbst nicht angepasst werden können, transformiert der Protokolladapter von einem zum anderen Protokoll.

Message Handler

Der Message Handler analysiert eintreffende Nachrichten syntaktisch (Parsing) und konvertiert die Nachrichten gegebenenfalls in ein anderes Format.

Datentransformation

Der Datentransformationsdienst greift auf ein zentrales Repository zu und gleicht unterschiedliche Datenschemata miteinander ab.

Komposition/Dekomposition

Die Kompositionskomponente dient zur Zusammensetzung mehrerer Nachrichten von unterschiedlichen Applikationen zu einer Dekomposition analog.

Routing

Steuerung der Reihenfolge der eintreffenden/ausgehenden Nachrichten, beispielsweise zur Komposition von Nachrichten. Verteilung der Nachrichten an die korrekten Adressaten.

Sicherheit

Dienst zur Überwachung der Zugriffskontrolle und Authentisierung.


43

Allgemeine Dienste für prozessorientierte Muster Dienst

Aufgabe

Transaktionskontrolle

Die Transaktionskontrolle stellt sicher, dass eine Unit-of-Work atomar ausgeführt wird.

Allgemeine Dienste für datenorientierte Muster Dienst

Aufgabe

Datenreplikation

Erstellung einer konsistenten (Teil-)Kopie einer Datenquelle (z.B. über das DBMS oder das Dateisystem) zu definierten Zeitpunkten.

Datenbereinigung und -transformation

Löschen von Duplikaten, Konsistenzprüfungen, usw.

Datenanreicherung

Anreicherung vorhandener Daten mit zusätzlichen Attributen und Werten.

Tab. 6:

Allgemeine Dienste von prozess- und datenorientierten Mustern (in Anlehnung an Adams et al. 2001, S. 212ff.)

Ähnlich wie Gamma et al. verwenden auch Adams et al. ein festes Raster zur Beschreibung eines Musters (vgl. Gamma et al. 1995, S. 8f.; Adams et al. 2001, S. 25ff.). Zur Beschreibung eines prozess- oder datenorientierten Musters wird von Adams et al. folgendes Beschreibungsraster vorgeschlagen (vgl. Adams et al. 2001, S. 216ff.): • Mustername und kurze Beschreibung: Name des Musters und kurze Beschreibung. • Geschäfts- und IT-Treiber: Beschreibung der Auswirkungen bei Anwendung des Musters aus Geschäftssicht (z.B. schnellerer Produktivsetzung, Beschleunigung von Geschäftsprozessen, usw.) und aus ITSicht (z.B. Minimierung der Total Costs Of Ownership (TCO), Komplexitätsreduktion, Steigerung der Verfügbarkeit, Skalierbarkeit, Leistungsfähigkeit, usw.). • Lösung: Die Beschreibung der Lösung erfolgt anhand einer einfachen graphischen Darstellung, die die Topologie aller beteiligten Applikationen und Middleware-Komponenten zeigt. Dazu wird eine leicht verständliche Notation vorgeschlagen. • Anwendungsleitfaden: Hier werden einige typische Anwendungsszenarios identifiziert, die dem Architekten helfen sollen, das am besten passende Muster auszuwählen.

44

A. Schwinn

• Nutzen: Hier werden Gründe angegeben, warum das Muster als Lösung für die bestimmte Anforderung betrachtet werden sollte. • Einschränkungen: In dieser Sektion werden Nachteile genannt, die bei der Verwendung des Musters entstehen können. Die Bereiche Nutzen und Einschränkungen werden dabei immer zusammen betrachtet. • Anwendungen des Musters: In diesem Abschnitt wird exemplarisch eine Lösung aus der Praxis vorgestellt, um zu illustrieren, wie das Muster in realen Umgebungen angewendet werden kann. Zur Verdeutlichung werden im Folgenden zwei Muster aus dem Ansatz von IBM zur Integration von Applikationen vorgestellt. Es wird jeweils ein prozessorientiertes („Direct Connection“) und ein datenorientiertes Muster („Operational Data Store“) gezeigt:

Initiator

Read-write data Application node containing new or modified code for this project Application node containing existing code with no need for modification for this project or which cannot be changed

Abb. 2:

„Direct Connection“-Muster (vgl. Adams et al. 2001, S. 217; O.V. 2002).

Das prozessorientierte Muster „Direct Connection“ (siehe Abb. 2) wird anhand der oben genannten Attribute wie folgt beschrieben (vgl. Adams et al. 2001, S. 216ff.; O.V. 2002):


45

Mustername und kurze Beschreibung Direct Connection: Das Muster „Direct Connection“ hilft dabei, die direkte Kommunikation zwischen einem Applikationspaar zu strukturieren. Geschäfts- und IT-Treiber Der primäre Geschäftstreiber, dieses Muster zu verwenden, ist der Echtzeitzugriff auf eine andere Applikation. Das Ziel ist die Beschleunigung von Geschäftsprozessen. Lösung Das Muster bietet eine einfache direkte Verbindung zwischen zwei Applikationen. Die Verbindung kann synchron (blockierend) oder asynchron (nicht blockierend) erfolgen.2 Eine Applikation enthält neuen oder modifizierten Programmcode (Initiator), die andere bestehende Applikation wird nicht manipuliert. Die direkte Verbindung erfolgt mithilfe der allgemeinen Dienstkomponenten (prozessorientierter Muster) Protokolladapter, Message Handler und Datentransformation (siehe Tab. 6). In der in Abbildung 2 dargestellten 2Schichten-Architektur erfolgt die Kommunikation über die Applikationsschicht (nicht die Datenbankschicht). Anwendungsleitfaden Typischerweise ist eine direkte 1:1 Verbindung unflexibel, da Änderungen an der einen Applikation, Änderungen der anderen Applikation implizieren. Diese Effekte sind zeitaufwändig und teuer. Nutzen Einfach zu implementieren (über einen Konnektor oder Adapter). Einschränkungen Eine grosse Anzahl direkter Verbindungen zwischen Applikationen führt zu einem „Integrationsspaghetti“ und hat einen überproportionalen Zuwachs der Komplexität der Applikationslandschaft zur Folge. Zudem ist das Wiederverwendungspotential einzelner Implementierungen sehr gering. Anwendungen des Musters Integration einer Kernapplikation in einem Unternehmen (z.B. SAP R/3) mit einer Web-Applikation. Tab. 7:

2

Beschreibung des Musters „Direct Connection“ (in Anlehnung an Adams et al. 2001, S. 216ff.; O.V. 2002).

Zu Vor- und Nachteilen synchroner (blockierender) und asynchroner (nichtblockierender) Kommunikation vgl. z.B. Burkhart (1999), Mühlhäuser (1999), Linthicum (2000), Ruh et al. (2001) und Tanenbaum (2003)

46

A. Schwinn Access

ODS

Application 1

Application 2

Transform rules

Application n

population

Read-write data Read only data Application node containing new or modified code for this project Application node containing existing code with no need for modification for this project or which cannot be changed

Abb. 3:

„Operational Data Store“-Muster (vgl. Adams et al. 2001; O.V. 2002).

Das datenorientierte Muster „Operational Data Store (ODS)“ (siehe Abb. 3) wird anhand der oben genannten Attribute wie folgt beschrieben (vgl. Adams et al. 2001; O.V. 2002): Mustername und kurze Beschreibung Operational Data Store (ODS): Das ODS-Muster erlaubt einer Applikation auf einen konsolidierten, aus mehreren Quellen integrierten Datenbestand zuzugreifen. Die Datenbestände aus den unterschiedlichen Datenquellen werden dabei jeweils von eigenständigen Applikationen (siehe Abb. 3: Applikation 2, …, Applikation N) verwaltet und verändert. Geschäfts- und IT-Treiber Verringerung der Abfragekomplexität, da auf eine optimale Sicht zugegriffen wird. Steigerung der Effizienz und somit Beschleunigung der Ausführung von Geschäftsprozessen. Lösung Das ODS-Muster verwendet die Basisdienste Datenpopulation, Transformation und Datenanreicherung (siehe Tab. 6). Anwendungsleitfaden Der Zugriff einer Applikation auf einen ODS erfordert neue Applikationslogik, da der ODS ein neues (nämlich das konsolidierte) Schema besitzt.


47

Nutzen Die Verwendung eines ODS ermöglicht die Entwicklung spezialisierter Applikationen. Einschränkungen Es stellt einen grossen Aufwand dar, die neuen Datenschemata des ODS zu entwickeln und die Applikationen auf die neuen Schemata anzupassen. Es muss abgewogen werden, in welchem Verhältnis der Nutzen der Integration gegenüber den Kosten der anfallenden Änderungen der Applikationen steht. Anwendungen des Musters Web-Applikation, die beispielsweise Kundendaten, die auf einem Host verwaltet werden, über einen Browser zugänglich macht. Tab. 8:

Beschreibung des Musters „Operational Data Store (ODS)“ (in Anlehnung an Adams et al. 2001; O.V. 2002).

Die zwei hier vorgestellten Muster aus dem Ansatz von Adams et al. (2001) und O.V. (2002) stellen nur eine sehr kleine Auswahl des gesamten Ansatzes dar. Es sollte ein Eindruck vermittelt werden, wie in diesem Ansatz Muster beschrieben und angewendet werden. Im Vergleich zu dem im vorherigen Abschnitt dargestellten Ansatz von Gamma et al. (1995), der sich auf den Applikationsentwurf konzentriert, wird hier konkret auf die Integration von Applikationen eingegangen. Der Fokus des Ansatzes ist jedoch nicht die Integration von Applikationen, sondern – ausgehend von einer Geschäftsanforderung – die passende logische Implementierung und anschliessend die entsprechende Infrastruktur und die geeigneten Produkte auszuwählen. Im nächsten Abschnitt wird ein weiterer Ansatz vorgestellt, der ausschliesslich Muster im Kontext Enterprise Application Integration (EAI) betrachtet.

3.3

EAI-Architekturmuster nach Lutz

Der Ansatz von Lutz (2000) greift zum einen auf die bewährten Ansätze von Gamma zurück und überträgt einzelne Entwurfsmuster in den EAIKontext. Zum anderen versucht er, typische Systemkomponenten (Adapter, Konnektoren, Message Broker, usw.), die traditionell bei der Integration von Applikationen verwendet werden, in Mustern zu systematisieren. Das Ergebnis seiner Arbeit ist die Identifikation von fünf EAI-Architekturmustern, mit jeweils unterschiedlichen Ausprägungen:

48

A. Schwinn

• Integration Adapter: Konvertiert eine vorhandene Applikationsschnittstelle auf ein gewünschtes (offenes und wiederverwendbares) Schnittstellenformat. • Integration Messenger: Beschreibt einen Ansatz, um die Abhängigkeiten zwischen Applikationen bei der Kommunikation zu minimieren. • Integration Façade: Um die Abhängigkeiten zwischen Client und Server zu minimieren, wird im Backend-Bereich eine vereinfachte transparente Schnittstelle zur Verfügung gestellt. • Integration Mediator: Interaktionslogik zwischen Applikationen wird gekapselt. Dadurch werden die Abhängigkeiten verringert. • Process Automator: Dieses Muster beschreibt einen Ansatz, um die Abhängigkeiten zwischen der Prozessautomatisierung und den Informationssystemen zu minieren. Der Ansatz von Lutz geht sowohl auf konkrete Implementierungen (z.B. Publish/Subscribe über einen Messaging Server), wie auch auf abstraktere Integrationskonzepte (z.B. Kapselung von Interaktionslogik) ein. Man vermisst eine systematische Klassifikation und Beschreibung der einzelnen Muster. Zum einen werden typische Middleware-Komponenten (z.B. Adapter) als Muster identifiziert, zum anderen komplexe Szenarien zur Minimierung von Abhängigkeiten zwischen den Geschäftsprozessen und den Informationssystemen. Zur Beschreibung von Mustern auf konzeptioneller Ebene wird der Ansatz deshalb nur teilweise anwendbar sein. Der Ansatz ist jedoch der einzige hier vorgestellte, der ausschliesslich die EAIThematik fokussiert. Eine detaillierte Beschreibung zu den einzelnen Mustern, die Lutz identifiziert hat, ist in Lutz (2000) zu finden. Neben den hier vorgestellten Ansätzen existieren weitere, die jedoch meist sehr technisch orientiert sind und somit dem Ziel dieses Beitrags – nämlich die Systematisierung fachlicher Integrationsbeziehungen – wenig dienlich sind (vgl. z.B. Hohpe et al. (2003) oder Fowler et al. (2002)). Nachdem nun drei unterschiedliche Ansätze zu Entwurfsmustern vorgestellt wurden, werden diese in Bezug auf Verwendbarkeit zur Entwicklung von fachlichen Integrationsbeziehungen hin untersucht und darauf aufbauend ein neuer Ansatz entwickelt. In der Literatur existieren zahlreiche weitere Klassifikationen von Integrationsbeziehungen, die hier nicht vorgestellt worden sind, jedoch beinhalten die meisten nicht den Grundgedanken eines Musters, zu immer wieder auftretenden ähnlichen Problemen eine Lösung zu bieten, sondern stellen vielmehr eine statische Klassifizierung dar. So ist beispielsweise eine Klassifikation in Integration auf Prä-


49

sentationsebene, auf Applikationslogikebene und Integration auf Daten(bank)ebene in der Literatur häufig vorzufinden, z.B. in Österle et al. (1996), Linthicum (2000), Ruh et al. (2001) und Puschmann (2003).

4

Entwicklung von Entwurfsmustern für Integrationsbeziehungen

Ausgehend von den vorgestellten vorhandenen Ansätzen und in Zusammenarbeit mit Praxisvertretern wurden Entwurfsmuster für (fachliche) Integrationsbeziehungen identifiziert. Neben den allgemeinen Zwecken von Mustern nach Klose sollte der zu entwickelnde Ansatz weiteren Anforderungen gerecht werden (vgl. Klose 2002, S. 114): Er sollte unabhängig von konkreten Implementierungen und verwendeten MiddlewareKomponenten sein. Zudem sollte er den Gesamtzusammenhang der Integrationsaspekte einer Applikationsarchitektur darstellen können. Bei der Entwicklung der formalen Gestaltung von Mustern wurde nach dem vorgestellten Ansatz von Gamma et al. (1995) vorgegangen. Alle entwickelten Muster wurden gemäss diesem Ansatz entwickelt und beschrieben. Aus dem vorgestellten Ansatz von Adams et al. (2001) und O.V. (2002) wurde im Wesentlichen die Unterscheidung von Integrationsbeziehungen in prozessorientierte und datenorientierte übernommen, jedoch mit leicht veränderten Bedeutungen. Bei der Ausgestaltung der einzelnen Muster wurde aber nicht auf die von Adams et al. (2001) und O.V. (2002) entwickelten zurückgegriffen, da der Anforderung nach Unabhängigkeit von Implementierungen, Middleware-Komponenten und Produkten nicht vollständig Rechnung getragen werden konnte. Lutz (2000) kann diesen Anforderungen ebenso nicht restlos nachkommen. Er ist zwar losgelöst von konkreten Produkten, jedoch beinhalten die Muster konkrete Middleware-Komponenten, die zur Lösung bestimmter Integrationsanforderungen eingesetzt werden. Ein weiterer Kritikpunkt in dem Ansatz von Lutz (2000) ist die mangelhafte Dokumentation der Muster, da sie nicht systematisch in einem zuvor definierten Raster beschrieben werden. In Zusammenarbeit mit zahlreichen Vertretern aus der Praxis wurden in Anlehnung an Adams et al. (2001) und O.V. (2002) zwei Hauptmuster identifiziert: Informationsbedarfe und Verarbeitungsaufträge. Informationsbedarfe liegen immer dann vor, wenn eine Applikation von einer anderen Informationen in Form von Daten benötigt. Ein Verarbeitungsauftrag wird einer Applikation erteilt, wenn innerhalb der Abwicklung eines Prozesses die Weiterverarbeitung auf einer anderen Applikation angestossen

50

A. Schwinn

werden soll. Beim Informationsbedarf wird weiter unterschieden, ob der Informationsbedarf erfüllt wird, indem auf eine Datenkopie oder auf eine Originaldatenquelle zugegriffen wird. Diese Unterscheidung ermöglicht unter anderem die schnelle Erkennung von Redundanzen innerhalb der Applikationslandschaft. Verarbeitungsaufträge werden dahingehend unterschieden, ob sie unmittelbar oder zeitverzögert angestossen werden. Somit können bei der Verarbeitung auch zeitliche Abhängigkeiten berücksichtigt werden, die Rückschlüsse auf die Verarbeitungsgeschwindigkeit von Geschäftsprozessen zulassen. Abbildung 4 zeigt die identifizierten implementierungsneutralen Muster Informationsbedarf und Verarbeitungsauftrag. Informationsbedarf Original

Abb. 4:

Datenkopie

Verarbeitungsauftrag Unmittelbar

Zeitverzögert

Identifizierte Integrationsmuster

Im Folgenden werden die einzelnen Muster gemäss dem Vorschlag von Gamma et al. (1995) beschrieben. Demnach umfasst die Beschreibung eines Musters einen Namen und Klassifizierung, einen Problemabschnitt, einen Lösungsabschnitt und einen Konsequenzenabschnitt. Der Konsequenzenabschnitt wird im Folgenden durch Nennung von Vor- und Nachteilen einzelner Muster dokumentiert.

4.1

Muster vom Typ Informationsbedarf

Im Folgenden werden die zwei Muster vom Typ Informationsbedarf (Zugriff auf Originaldaten und Zugriff auf eine Datenkopie) detailliert beschrieben. Der Informationsbedarf ist vom Typ „Zugriff auf Originaldaten“, wenn der Informationsbedarf dadurch gedeckt wird, dass die Applikation auf die Originaldatenbestände einer fremden Applikation zugreift. Der Aufruf erfolgt dann meist entweder über die beteiligten Datenbankmanagementsysteme (DBMS) oder mittels eines API-Aufrufs (Application Programming Interface). Der Aufruf über das Datenbanksystem kann jedoch nur implementiert werden, wenn ein Zugriff auf das System gegeben ist und die Applikation keine „Black Box“ ist. Standardapplikationen erlauben häufig keinen direkten Zugriff auf das Datenbanksystem, bieten jedoch Schnittstellen in Form von APIs an (vgl. Linthicum 2000, S. 47). Ein APIAufruf kann aber nur dann erfolgen, wenn zum einen der angebotene Aufruf genau die Anforderungen erfüllt, bzw. wenn die aufrufende Applika-


51

tion dementsprechend manipuliert werden kann. Eine Erweiterung des angebotenen API ist wiederum in den meisten Fällen nicht möglich, sofern es sich nicht um Eigen- oder Auftragsentwicklungen handelt. Eine weitere Implikation, die sich durch den Zugriff auf Originaldaten einer anderen Applikation ergibt, ist die Abhängigkeit der Verfügbarkeit der Applikationen. Ist die Applikation, welche die Originaldaten hält, nicht verfügbar, ist auch die datenbeziehende Applikation eingeschränkt. Die Verfügbarkeit der datenliefernden Applikation kann zudem durch viele und lange andauernde Transaktionen und Locking-Probleme eingeschränkt werden. Die Vorteile der Verwendung dieses Musters sind vor allem in der Redundanzfreiheit und den damit verbundenen Konsequenzen zu sehen: Kein zusätzlicher Speicherplatz wird benötigt, Mechanismen zur Synchronisation von Daten sind nicht erforderlich, usw. Aufgrund dieser Faktoren ist eine Implementierung in der Regel einfacher und kostengünstiger. Folgende Tabelle dokumentiert das Muster Informationsbedarf-Originaldatenquelle zusammenfassend: Name des Musters: Informationsbedarf-Originaldatenquelle Beschreibung Durch Verwendung des Musters wird ein Informationsbedarf einer Applikation gedeckt, indem auf die Originaldaten einer fremden Applikation zugegriffen wird. Anwendungsbereiche • Bei Industriestandards • Bei Eigenentwicklung (inkl. Auftragsentwicklung) Vorteile • Einfach zu implementieren, geringste Komplexität und somit geringe Implementierungskosten • Redundanzfrei, und somit kein Mehraufwand der durch die Entstehung von Redundanz impliziert wird (mehr Speicher, Kosten für Synchronisation, Konsistenzprüfungen, usw.) Nachteile • Software-Komponenten sind nicht immer zugänglich und beeinflussbar • Enge Kopplung (impliziert Abhängigkeit von der Verfügbarkeit der Applikation, Change Management schwieriger) • Locking-Probleme bei komplexen Transaktionen • Evtl. Überlastung der Applikation, welche die Originaldaten hält • Plattformübergreifende Kommunikation unter Umständen sehr komplex Tab. 9:

Muster „Informationsbedarf-Originaldatenquelle“

52

A. Schwinn

Aus unterschiedlichen Gründen werden immer wieder Redundanzlösungen benötigt: Ein typisches Beispiel wäre die Anforderung, dass die Autonomie eines Systems sichergestellt sein muss, d.h., dass die Applikation auch dann arbeitet, wenn die Applikation, die die Originaldaten hält, nicht verfügbar ist. Eine Datenkopie kann von einer Applikation lokal gehalten werden, es können aber ebenso von mehreren Applikationen gemeinsam genutzte Datenkopien (z.B. Data Warehouse, ODS) angelegt werden. Bei den Kopien kann es sich um 1:1-Kopien oder um auszugsweise oder konsolidierte Kopien einer oder mehrerer Ursprungsquellen handeln. Das Leistungsverhalten der datenbeziehenden Applikation wird gesteigert, da eine „personalisierte“ Datensicht angelegt wird. Im Falle einer lokalen Datenkopie entfallen zudem Verzögerungen, die durch den Netzwerkverkehr verursacht werden. Lösungen, bei denen der Zugriff auf eine Datenkopie erfolgt, sind immer mit Mehraufwand – im Vergleich zu einer redundanzfreien Lösung – verbunden, da Daten synchronisiert werden müssen und zusätzlicher Speicherbedarf entsteht. Da die Datenkopie nie so aktuell ist, wie die Originaldaten, besteht die Gefahr, dass Inkonsistenzen entstehen (auch auf Kundenseite), worunter die Qualität der Daten leidet (vgl. Helfert 2002). Folgende Tabelle dokumentiert das Muster Informationsbedarf-Datenkopie zusammenfassend. Name des Musters: Informationsbedarf-Datenkopie Beschreibung Durch Verwendung des Musters wird ein Informationsbedarf einer Applikation gedeckt, indem auf eine angelegte Datenkopie zugegriffen wird. Die Datenkopie kann lokal gehalten werden oder es ist eine Datenkopie, die von mehreren Applikationen genutzt wird (z.B. ODS). Es kann sich dabei um eine 1:1 Kopie der Originaldaten handeln oder um eine auszugsweise oder konsolidierte Datenkopie.

Anwendungsbereiche • Höhere Verfügbarkeit als Zulieferapplikationen erforderlich • Autonomie des Systems (Bereitstellung und Betrieb) erforderlich • Beispiele: DWH, ODS, Channel- und Vertriebsapplikationen, Packaged Applications


53

Vorteile • • • •

Hohe Performance Hohe Verfügbarkeit Stand-alone-fähig Single-Source zur Auswertung von Daten (optimale Datensicht für analytisches System/Analysen, keine verteilten Abfragen über mehrere Datenquellen hinweg nötig)

Nachteile • Aktualität der Daten (in Abhängigkeit von Synchronisationsabständen) geringer • Overhead durch Synchronisationsmechanismen (Datenkonsistenz) • Kosten für Redundanz (Speicher, Management der Redundanz und Change Management) • Mögliche inkonsistente Sichten auf Kundenseite (z.B. Bankomat, Internetbanking) Tab. 10: Muster „Informationsbedarf-Datenkopie“

4.2

Muster vom Typ Verarbeitungsauftrag

Bei den Verarbeitungsaufträgen werden zwei Typen unterschieden: Aufträge, die von einer Applikation unmittelbar angestossen werden und Aufträge, die zeitverzögert angestossen werden. Diese Unterscheidung wurde vorgenommen, da die entstehenden zeitlichen Abhängigkeiten bei der Betrachtung der Ausführung eines Geschäftsprozesses wesentlich sind; sie können Auskunft geben darüber, wie „schnell“ ein Prozess abgewickelt wird. Diese zwei Muster der Kategorie Verarbeitungsauftrag werden im Folgenden beschrieben. Eine unmittelbare (synchrone) Verarbeitung zeichnet sich durch fehlende Pufferung von Daten aus, d.h. Daten müssen sofort vom Empfängerprozess übernommen werden (vgl. Burkhart 1999, S. 591). In der Regel wird mit unmittelbarer Kommunikation auch Blockierung in Verbindung gebracht, d.h. die Applikation ist während der Verarbeitung eines unmittelbaren Aufrufs blockiert, und kann somit keine weiteren Operationen durchführen. Unmittelbare Verarbeitung ist immer dann sinnvoll, wenn die Anforderungen an die Ausführungszeiten hoch sind und volle Transaktionskontrolle innerhalb einer Unit-of-Work gewünscht wird. Zudem können Rückgabewerte direkt ausgewertet werden, und es kann somit unmittelbar sichergestellt werden, dass eine Transaktion korrekt ausgeführt worden ist.

54

A. Schwinn

Der Nachteil bei unmittelbarer, blockierender Kommunikation besteht darin, dass es zu Locking-Problemen und Deadlocks kommen kann, wenn eine Transaktion zu lange dauert. Folgende Tabelle fasst das Muster zusammen: Name des Musters: Verarbeitungsauftrag-Unmittelbar Beschreibung Eine Applikation stösst unmittelbar einen Verarbeitungsauftrag bei einer anderen Applikation an. Anwendungsbereiche • System wartet Request ab und behält volle Kontrolle über den Prozess („Alles oder Nichts“-Prinzip) • Service-Aufruf (Request-Reply), z.B. über Corba, .NET, usw. Vorteile • Volle Transaktionskontrolle (Unit-of-Work) • Rückgabewerte können unmittelbar geliefert und ausgewertet werden (z.B. Referenznummer) • Der Sender ist sicher, dass die Nachricht empfangen wurde, wenn er entblockiert wird. Diese Semantik ist intuitiv und leicht verständlich Nachteile • Transaktion dauert zu lange • Antwortzeiten zu lange, und somit schlechte Auslastung des Systems durch lange Wartezeiten • Locking-Probleme bei komplexen Transaktionen • Das Blockieren kann zu einem Deadlock führen Tab. 11: Muster „Verarbeitungsauftrag-Unmittelbar“

Existiert bei der Abarbeitung von Prozessen eine Pufferung der Nachrichten, treten keine Einschränkungen (z.B. durch Blockierung) im Ablauf auf. Diese Form der Kommunikation wird auch als asynchron bezeichnet (vgl. Burkhart 1999; S. 591). Da der Begriff asynchron sehr implementierungsnah erscheint, hier aber die Entwicklung eines implementierungsneutralen Ansatzes angestrebt wird, wird der Begriff zeitverzögert verwendet, um Missverständnisse zu vermeiden, wenngleich die Begriffe nicht immer gleichzusetzen sind. Eine zeitverzögerte Verarbeitung ist zu präferieren, wenn viele oder verteilte Transaktionen ausgeführt werden müssen oder wenn die Blockierung von einzelnen Systemen minimiert werden soll. Durch gepufferte, zeitverzögerte Verarbeitung wird das System entlastet, da es nicht wie bei der direkten Ausführung lange blockiert wird. Zudem


55

ist eine Parallelisierung von Prozessen möglich, wodurch die Leistungsfähigkeit des Systems erhöht werden kann. Diese zeitverzögerte indirekte Ausführung hat eine losere Kopplung als bei direktem Zugriff zur Folge. Damit sind einige Vorteile (z.B. Minimierung von Abhängigkeiten zwischen Applikationen), aber auch Nachteile (z.B. keine unmittelbare Transaktionskontrolle) verbunden. Weitere Vor- und Nachteile loser und enger Kopplung sind in Ruh et al. und Cummins zu finden (vgl. Ruh et al. 2001, S. 20/21; Cummins 2002, S. 48). Die Nachteile einer gepufferten, zeitverzögerten Verarbeitung liegen in der komplexeren Fehlerbehandlung und dem Zusatzaufwand, der entsteht, um Transaktionssicherheit zu gewährleisten. Die Fehlerbehandlung ist komplexer, da Rückgabewerte nicht unmittelbar ausgewertet werden können und keine klassischen atomaren Transaktionen existieren. Folgende Tabelle fasst das Muster zusammen: Name des Musters: Verarbeitungsauftrag-Zeitverzögert Beschreibung Eine Applikation stösst zeitverzögert einen Verarbeitungsauftrag bei einer anderen Applikation an. Die Zeitverzögerung kann kurz sein (Near Realtime) oder länger (z.B. tägliche Batch-Verarbeitung). Rückgabewerte werden typischerweise nicht sofort benötigt, sondern die weitere Verarbeitung soll angestossen werden („fire-and-forget“-Prinzip). Anwendungsbereiche • Verteilte Transaktionen • Viele Transaktionen • Parallelisierung von Prozessen Vorteile • Lose Kopplung Hohe Performance/Verfügbarkeit • Der Sender verliert keine Zeit, da er nicht blockiert wird und kann diese Zeit unter Umständen sinnvoll nutzen • In der Regel gute Skalierbarkeit gegeben Nachteile • • • •

Komplexes Fehlerhandling Keine Transaktionssicherheit ohne Zusatzaufwand Der Sender weiss nicht, ob die Nachricht bereits empfangen wurde Der Sender kennt unter Umständen den/die Empfänger nicht

Tab. 12: Muster „Verarbeitungsauftrag-Zeitverzögert“

56

A. Schwinn

Partner

Geld-/Devisenhandel

Valorenkurs

PortfolioVerwaltungsauftrag

Partnerverwaltung

Valoreninformation

Die hier vorgestellten Muster sind zunächst völlig unabhängig von einer konkreten Implementierung. Beispielsweise kann ein Informationsbedarf über Datenbankmanagementsysteme, über Messaging-Systeme, API-Aufrufe, Kopieren von Dateien, usw. implementiert werden. Durch die Zuordnung vorhandener Applikationsbeziehungen zu den jeweiligen Mustern kann ein schneller Überblick über vorhandene Informations- und Funktionsabhängigkeiten gegeben werden. Durch die weitere Unterscheidung von Informationsbedürfnissen in Zugriff auf Originaldaten und Zugriff auf Datenkopien können zudem leicht Redundanzen erkannt werden. Die Unterteilung der Verarbeitungsaufträge in unmittelbare und zeitverzögerte ermöglicht es, Aussagen zu Verarbeitungsgeschwindigkeiten von Prozessen zu treffen. Abbildung 5 stellt diese Zusammenhänge anhand des Beispiels „Portfoliomanagement“ graphisch dar. Valorenverwaltung

Börsenauftrag

Portfolio-Management

Auftragsverwaltung

Depot-Position

Geldhandelsgeschäft

Saldo

Buchführung

Depotführung Buchung

Legende:

WS-Geschäft

A

B

Applikation B hat Informationsbedarf, der von Applikation A durch Zugriff auf die Originaldaten gedeckt wird

A

B

Applikation B hat Informationsbedarf, der von Applikation A durch Erzeugung einer Datenkopie gedeckt wird

A

B

Applikation A übergibt Verarbeitungsauftrag an Applikation B unmittelbar

B

Applikation A übergibt Verarbeitungsauftrag an Applikation B zeitverzögert

B

Ausgetauschtes Informationsobjekt

A A

Informationsobjekt

Auftragsabwicklung

Abb. 5: Beispielhafte Kombination von Mustern zur Darstellung von Gesamtzusammenhängen.

Idealerweise werden Integrationsbeziehungen in einem Repository hinterlegt und mit Hilfe eines Werkzeugs dokumentiert (z.B. Rational Rose), um derartige Diagramme automatisch erstellen, und Auswertungen (z.B. „Welche Informationsobjekte werden redundant gehalten?“ oder „Welche Applikationen sind beim Austausch einer Applikation betroffen?“) durchführen zu können.


57

Die hier vorgestellten Muster wurden in weiteren Arbeiten detailliert behandelt (vgl. Schwinn 2003b; Schwinn 2003a), jedoch handelt es sich dabei teilweise um firmenspezifische Ausprägungen.

5

Zusammenfassung

Der hier vorgestellte Ansatz dient zur Systematisierung und Dokumentation von Integrationsbeziehungen zwischen Applikationen unter Verwendung eines Entwurfsmusteransatzes. Die identifizierten Entwurfsmuster dienen dazu, einen Überblick über vorhandene Integrationsarten zu bekommen und Unterstützung in der Designphase zukünftiger Integrationsprojekte zu bieten. Der Nutzen eines Musters – zu einem immer wiederkehrenden ähnlichen Problem eine Lösung zu bieten – ist somit gegeben, wenngleich auf einem hohen Abstraktionsniveau. Die identifizierten Muster sind implementierungsunabhängig, und somit auch nicht firmenspezifisch, wodurch sie folglich – wie auch andere Musteransätze – auf einem abstrakten Niveau einzuordnen sind. In diesem Beitrag wurde aufgezeigt, welche Muster sich bei bestimmten Integrationsanforderungen eignen. Nun gilt es, zu den einzelnen identifizierten Integrationsmustern Implementierungsarten zu identifizieren (z.B. Implementierung einer Datenkopie über DBMS, Messaging, Kopieren von Dateien, usw.) und Handlungsanweisungen zu entwickeln, die aufzeigen, welche technische Implementierung bei welchen Anforderungen zu wählen ist. Dies ist gegenwärtig Gegenstand weiterer Arbeiten.

58

A. Schwinn

Literatur Adams, J.; Koushik , S.; Vasudeva, G.; Galambos, G.: Patterns for e-business: A Strategy for Reuse, Double Oak, USA, 2001. Alexander, C.; Ishikawa, S.; Silverstein, M.; Jacobson, M.; Fiksdahl-King, I.; Angel, S.: A Pattern Language, New York, 1977. Appleton, B.: Patterns and Software: Essential Concepts and Terminology, http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html, Abruf am 07.08.2003. Burkhart, H.: Parallele Programmierung, in: Rechenberg, P.; Pomberger, G. (Hrsg.): Informatik Handbuch, München et al., 1999, S. 587-618. Cummins, F. A.: Enterprise Integration, New York, Chichester et al., 2002. Erickson, T.: Lingua Francas for Design: Sacred Places and Pattern Languages, Lingua Francas for Design: Sacred Places and Pattern Languages, 2000. Fowler, M.; Rice, D.; Foemmel, M.: Patterns of Enterprise Application Architecture, Addison-Wesley, Reading, 2002. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, 1995. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Entwurfsmuster – Elemente wiederverwendbarer objektorientierter Software, 5. Nachdruck, AddisonWesley, München et al., 1996. German, D.M.; Cowan, D.: Three Hypermedia Design Patterns, 1999. Hohpe, G.; Woolf, B.: Enterprise Integration Patterns, Addison-Wesley, Reading, 2003. Helfert, M.: Planung und Messung der Datenqualität in Data-Warehouse-Systemen, Bamberg, 2002. Klose, M.: Design Patterns für digitale Produkte im digitalen Wirtschaftsraum, St. Gallen, 2002. Linthicum, D.S.: Enterprise Application Integration, Massachusetts, 2000. Lutz, J.C.: EAI Architecture Patterns, in: EAI Journal, 2000, Nr. March, S. 64-73. Mertens, P.: Integrierte Informationsverarbeitung, 12. Aufl., Wiesbaden, 2000. Mühlhäuser, M.: Verteilte Systeme, in: Rechenberg, P.; Pomberger, G. (Hrsg.): Informatik Handbuch, München et al., 1999, S. 675-708.


59

Österle, H.; Riehm, R.; Vogler, P.: Middleware – Grundlagen, Produkte und Anwendungsbeispiele für die Integration heterogener Welten, Braunschweig et al., 1996. O.V.: IBM Patterns for e-business, http://www106.ibm.com/developerworks/patterns, 07.08.2003. Perzel, K.; Kane, D.: Usability Patterns for Applications on the World Wide Web, 1999. Puschmann, T.: Collaboration Portale. Architektur, Integration, Umsetzung und Beispiele, Dissertation, St. Gallen, Bamberg, 2003. Rossi, G.; Schwabe, D.; Garrido, A.: Designing Computational Hypermedia Applications, in: Journal of Digital Information, 1 (1999), 4. Ruh, W.A.; Maginnis, F.X.; Brown, W.J.: Enterprise Application Integration, New York et al., 2001. Schwinn, A.: Logische Datenintegrationstypen, Institut für Wirtschaftsinformatik, Universität St. Gallen, 2003a, S. 10-18. Schwinn, A.: Modellierung von Applikationslandschaften und Applikationsbeziehungen auf konzeptioneller und logischer Ebene, Working Paper, 2003b. Tanenbaum, A.: Computernetzwerke, Pearson Studium, 2003.

Entwicklung eines Zielsystems für ein systemisch-evolutionäres Management der IS-Architektur im Unternehmen Martin Hafner Universität St. Gallen

Das Informationsmanagement in Unternehmungen sieht sich Herausforderungen mit zunehmender Dynamik und Komplexität gegenüber, welche vielfach direkt Einfluss auf die Architektur des Informationssystems nehmen. Aus diesem Grund bedarf es eines Ansatzes zum systemisch-evolutionären Management der IS-Architektur, welcher den Herausforderungen adäquat begegnet. Ein Zielsystem sowie daraus abgeleitete Anforderungen für einen solchen Ansatz werden im vorliegenden Beitrag auf der Grundlage des allgemeinen systemisch-evolutionären Managements sowie des Informationsmanagements unabhängig von den heterogenen Auffassungen zum IS-Architekturmanagement in Theorie und Praxis entwickelt.

1 2

3

4

5

Einleitung .......................................................................................... 62 Systemtheoretische Grundlagen........................................................ 65 2.1 Aspekte der allgemeinen Systemtheorie .................................... 65 2.2 Management von Systemen ....................................................... 66 Bezugsrahmen für das Management der IS-Architektur................... 69 3.1 Das Informationssystem des Unternehmens .............................. 70 3.2 Managementaspekte im Informationswesen des Unternehmens 72 3.3 IS-Architektur als Plattform für das IS-Management ................ 81 Ordnungsrahmen für das Management der IS-Architektur............... 85 4.1 Zielsystem für das Management der IS-Architektur.................. 85 4.2 Einordnung des Informationsmanagements in das Zielsystem.. 89 4.3 Anforderungen an das Management der IS-Architektur............ 91 Zusammenfassung und Ausblick ...................................................... 93

62

1

M. Hafner

Einleitung

Das wirtschaftliche Umfeld eines Unternehmens des Informationszeitalters ist geprägt von Globalisierung, Deregulierung, verändertem Kundenverhalten sowie wachsenden Herausforderungen im Bereich der Produkt- und Dienstleistungsdifferenzierung (vgl. Baumöl/Winter 2003, S. 45-61; Winter et al. 1999, S. 6, 12). Die zentrale Herausforderung für das Management eines Unternehmens besteht darin, mit den vielfältigen Einflüssen aus seinem Umfeld angemessen umzugehen (vgl. Ulrich 1984, S. 236f.). Die Herausforderung wird dadurch verstärkt, dass die Einflüsse oft zeitgleich einwirken, einander oder dem Unternehmen entgegen gesetzte Zielsetzungen verfolgen (vgl. Rüegg-Stürm 2002, S. 36f., 43) und im Fall ihrer Akzeptation mit nachhaltigen und tief greifenden Veränderungen für das Unternehmen verbunden sind.1 Ein zentraler Auslöser für Veränderungen ist die Informationstechnik (IT) (vgl. Österle 1995, S. 1). Die strategische Nutzung des Informationssystems (IS) durch das Unternehmen bietet die Möglichkeit zu neuen Dienstleistungen und Produkten sowie optimierten Prozessen, aber auch neuen Geschäftsmodellen, Unternehmen oder gar Branchen (vgl. Österle/Winter 2000, S. 4ff.). Die Bedeutung des Informationssystems bleibt angesichts weiterer technologischer Innovationen (z.B. breitbandiger Kommunikationsnetze, mobiler Technologien, Digitalisierung der Medien) auch künftig im Mittelpunkt unternehmerischen Handelns (vgl. Österle/Winter 2003, S. 5). Umgekehrt wirken Veränderungen für das Unternehmen hinsichtlich ihrer Dynamik und Komplexität vielfach direkt auf das Informationssystem ein.2 1

2

Auf die enge Verflechtung des Kerngeschäfts mit dem Informationssystem weist Jagoda hin, indem er eine homologe Sichtweise von InformationssystemArchitektur und Organisationsstruktur fordert: „Zum einen, weil zu erwarten ist, dass mittels der DV neue Geschäftsfelder entstehen. Zum anderen aber auch, weil bestimmte geschäftsstrategische Neuausrichtungen den effizienten und effektiven Einsatz von informations- und kommunikationstechnischen Systemen zwingend voraussetzen.“ (Jagoda 1999, S. 4). Die Annahme der direkten Einwirkung ist auf den Unterstützungscharakter des Informationssystems gegenüber den Kern-Leistungsprozessen des Unternehmens zurückzuführen (vgl. Österle 1995, S. 130f.). Auf den Aspekt der Dynamik weist Keller (2000) hin: „In Zeiten, in denen ein Technologiezyklus mit 3 Jahre [sic!] schon wesentlich kürzer ist, als die Zeit, die man selbst bei bestem Projektmanagement benötigt, um 350 Mio. Euro umzusetzen, muß also das Argument entfallen, dass man für eine Rundumerneuerung eines An-

Entwicklung eines Zielsystems

63

In diesem Zusammenhang sind die vielfältigen Schnittstellen und der unkoordinierte Einsatz von Applikationen mit der Folge von Redundanzen und Überschneidungen (vgl. Winter 2003a) nicht zuletzt auf die Unüberschaubarkeit des Gesamtunternehmens in all seinen Facetten zurückzuführen. Diese rührt jedoch nicht ausschliesslich von der Komplexität und Dynamik des Unternehmensumfelds. Vielmehr besteht nach Bleicher die Gefahr, dass Integrations- und Koordinationsmechanismen im Unternehmen, wozu auch das Informationssystem gezählt werden kann, zu einem Mass an organisatorischem Überschuss führen, der den Bestand des Unternehmens in Frage stellt (vgl. Bleicher 1979, S. 61). Ein Ansatz zum Management der IS-Architektur3 darf aus diesem Grund die Eigenkomplexität des Informationssystems nicht weiter erhöhen, sondern muss einen Beitrag leisten, sie kontrollierbar zu halten. Zusammenfassend ist das Management der IS-Architektur somit im Umfeld der hochdynamischen, komplexen und oft konfliktreichen Wechselwirkungen zwischen unternehmerischen und informationstechnischen Zielsetzungen angesiedelt (vgl. Dern 2003, S. 7) (Abb. 1). Über den Lebenszyklus eines Informationssystems hinweg gilt es, kontinuierlich beherrschbare Systemzustände herbeizuführen, die sowohl die Einzelinteressen von Unternehmensbereichen berücksichtigen als auch das langfristige „Überleben“ des Informationssystems des Gesamtunternehmens gewährleisten. Da weder in der einschlägigen Literatur noch in der Praxis breiter Konsens über den Gegenstand und die Zielsetzungen des IS-Architekturmanagements besteht (vgl. z.B. Dern 2003; Dietzsch 2003; Krüger/Seelmann-Eggebert 2003; Perks/Beveridge 2003; Rohloff 2003), wird im vorliegenden Beitrag ein Zielsystem für das Management der IS-Architektur entwickelt und daraus Anforderungen an das IS-Architekturmanagement abgeleitet.

3

wendungsportfolios mit genau einer Anwendungsarchitektur ohne Anpassungen auskommen wird.“ (Anm. d. Autors: Rechtschreib- und Grammatikfehler). Zur singulären Verwendung des Begriffs „IS-Architektur“ siehe Abschnitt 3.3.

64

M. Hafner

Anspruchsniveaus steigend

stagnierend

Diskontinuitäten im Umfeld verbreitet

vereinzelt

Marktumfeld turbulent

ruhig

Dominanz von QuickWins hoch

niedrig

Bedeutung von Kennzahlen zunehmend

stagnierend

IT-Innovationszyklen kurz

lang

Mergers & Acquisitions häufig 0% 0%

Abb. 1:

10% 10%

nie 20% 20%

30% 30%

40% 40%

50% 50%

60% 40%

70% 30%

80% 20%

90% 10%

100% 0%

Dynamik im Umfeld der IS-Architektur4

Um das Zielsystem für das IS-Architekturmanagement theoretisch zu verankern werden in Abschnitt 2 zunächst relevante systemtheoretische Grundlagen identifiziert sowie das systemorientierte Managementverständnis dargestellt. In den Abschnitten 3 und 4 werden ein Bezugs- und ein Ordnungsrahmen für das Management der IS-Architektur konstruiert. Unter dem Bezugsrahmen soll dabei die externe Sicht auf das Management der IS-Architektur verstanden werden. Im Mittelpunkt der Betrachtungen steht der heterogen verwendete Begriff des Informationssystems. Darüber hinaus werden die traditionellen Ansätze des Informationsmanagements, des IS-Managements und des IS-Controllings betrachtet. Insbesondere wird die Rolle der IS-Architektur fokussiert. Ziel ist es, jeweils zu einem eindeutigen Begriffsverständnis und letztlich zu einem Anhaltspunkt für die Einordnung des Managements der IS-Architektur in das Informationsmanagement zu gelangen. Unter dem Ordnungsrahmen wird die interne Sicht auf das Management der IS-Architektur verstanden. Ausgehend von allgemeinen unternehmerischen Zielsetzungen sowie gestiegenen Anforderungen an das Informationsmanagement, wird er in Form eines Zielsystems entwickelt und dient als Grundlage für Anforderungen an das Management der IS-Architektur.

4

Die Ergebnisse stammen aus einer selbst durchgeführten Umfrage vom 15. September 2003 im Rahmen des 12. St. Galler Anwenderforums unter 177 Teilnehmern. Die Rücklaufquote lag bei 58,2%.


2

65

Systemtheoretische Grundlagen

Die Systemtheorie stellt für die unterschiedlichsten Wissenschaftsdisziplinen einen Bezugsrahmen ohne realen Inhalt zur Verfügung (vgl. Franken/Fuchs 1974, S. 23ff.; Hill et al. 1994, S. 18). Diese Unabhängigkeit begünstigt die interdisziplinäre Betrachtungsweise eines Forschungsgegenstands, was im Kontext des IS-Architekturmanagements von Bedeutung ist (siehe Abschnitt 1).

2.1

Aspekte der allgemeinen Systemtheorie

Unter einem System wird allgemein eine Menge von Elementen verstanden, zwischen denen Beziehungen vorliegen. Ein System ist gegenüber seiner Umwelt abgegrenzt (vgl. Krauch 1994, S. 338), indem diese aus denjenigen Elementen besteht, deren (wahrgenommene) Beziehungsintensität zu den Elementen des Systems geringer ist als die (wahrgenommene) Beziehungsintensität unter den Elementen des Systems. Innerhalb der Systemgrenzen wird somit ein „[…] grösseres (stärkeres, wichtigeres) Mass an Beziehungen […] als zwischen System und Umwelt“ (Daenzer/Huber 1999, S. 6) festgestellt bzw. wahrgenommen. In statischen Systemen bleibt das Verhalten der Elemente über die Zeit ebenso konstant wie die Beziehungen unter den Elementen. Dahingegen können die Elemente dynamischer Systeme durch Veränderung ihrer Eigenschaften verschiedene Zustände annehmen und über ihre Beziehungen zu anderen Elementen auch deren Eigenschaften und Zustände verändern (vgl. Teubner 1999, S. 11). Die Offenheit bzw. Geschlossenheit von Systemen ist mit der Durchlässigkeit der Systemgrenze für Energie-, Materie- und Informationsflüsse gekoppelt. Offene Systeme befinden sich somit in Austausch mit ihrer Umwelt. Dies impliziert, dass das dynamische Verhalten offener Systeme nicht nur von internen Transformationsprozessen, sondern auch von Austauschbeziehungen mit der Umwelt abhängt (vgl. Jantsch/Seiffert 1994; Zangemeister 1976, S. 14ff.). Mit der Unterscheidung dynamischer und statischer Systeme ist eine Differenzierung des Strukturbegriffs notwendig. Während statische Systeme durch ihre Gebildestruktur vollständig beschrieben werden können, müssen für die Betrachtung dynamischer Systeme zusätzlich die Abläufe innerhalb ihrer Gebildestruktur erfasst werden. Man spricht dann von ihrer Prozessstruktur (vgl. Daenzer/Huber 1999, S. 114ff.; Haberfellner 1974, S. 13).

66

2.2

M. Hafner

Management von Systemen

Um auf Systeme zielorientiert Einfluss nehmen zu können, bedarf es Mechanismen, wie der anwendungsunabhängigen Kybernetik, die u.a. als Grundlage des Managements komplexer, evolutionärer Systeme dient (siehe Abschnitt 2.2.2). Dieses stellt wiederum die Basis des hier zu entwickelnden Ansatzes für das Management der IS-Architektur dar.

2.2.1 Grundlagen der Kybernetik Die Kybernetik wendet sich der Steuerung und Regelung von Systemen zu (vgl. Teubner 1999, S. 12): • Im Rahmen der Steuerung werden externe Festlegungen über die Einstellung der Systemzustände getroffen. Dabei sind keine Rückkopplungen vorgesehen. • Die Regelung von Systemen erfolgt durch den Abgleich einer Regelgrösse mit der vorgegebenen Führungsgrösse. Nicht tolerierbare Abweichungen werden durch Veränderung einer Stellgrösse bereinigt. Im Rahmen der Regelung findet somit eine Rückkopplung des gelenkten an das lenkende System statt. Die kybernetische Forschung wird in zwei Phasen unterteilt (vgl. Maruyama 1963): • Die sogenannte Kybernetik I betont die Gleichgewichtserhaltung von Systemen. Zielsetzung ist es, durch die Bewahrung von im Voraus definierten Systemzuständen die Varietät gering zu halten (vgl. Gabriel/Beier 2003, S. 57). Somit steht die Erhaltung der Stabilität eines Systems mittels Soll-Ist-Vergleich, Abweichungsanalyse oder Rückkopplung im Mittelpunkt. • Die Kybernetik II fokussiert u.a. die Probleme der Instabilität, der Flexibilität, des Wandels und der Evolution. Ungleichgewicht wird als Normalfall und Voraussetzung für den Wandel aufgefasst. Diese Sichtweise soll für die Konstruktion eines Managementansatzes für die IS-Architektur zugrunde gelegt werden.


67

2.2.2 Management komplexer, evolutionärer Systeme Basierend auf einer systemorientierten Sicht auf Unternehmungen sowie den Grundlagen der Kybernetik wurden ab 1950 so genannte systemtheoretische Managementansätze entwickelt (vgl. Kast/Rosenzweig 1985, S. 118; Staehle 1999, S. 22, 41, 43). Als einer ihrer Vertreter geht Malik davon aus, dass das Grundproblem des Managements in der Beherrschung von Komplexität liegt, d.h. im angemessenen Umgang mit der Vielfalt der Beziehungen zwischen den Elementen eines Systems (vgl. Malik 1992, S. 25). Darauf bezogen unterscheidet er zwei Arten von Managementverständnis, die in Tabelle 1 gegenübergestellt werden. Konstruktivistisch-technomorph

Systemisch-evolutionär

Menschenführung

Gestaltung und Lenkung ganzer Institutionen in ihrer Umwelt

Ausrichtung auf Optimierung

Ausrichtung auf Steuerbarkeit

Existenz ausreichender Information

Keine Existenz ausreichender Information

Ziel der Gewinnmaximierung

Ziel der Maximierung der Lebensfähigkeit

Tab. 1:

Arten des Managementverständnisses (in Anlehnung an Malik 1992, S. 48ff.)

Das konstruktivistisch-technomorphe Managementverständnis ist darauf bedacht, dass die Elemente eines Systems ihre jeweiligen Funktionen (von denen aufgrund ausreichender Informationen angenommen wird, dass sie effektiv sind) optimal ausführen. Der Erfolg wird an der Maximierung des Gewinns gemessen, was ebenfalls durch die Annahme ausreichender Informationen möglich ist. Dem gegenüber ist das systemisch-evolutionäre Managementverständnis darauf bedacht, das System ganzheitlich zu gestalten und zu lenken. Es wird jedoch davon ausgegangen, dass zu keinem Zeitpunkt (aufgrund der Komplexität des Systems) hinreichend viele und exakte Informationen existieren, um determiniert handeln zu können. Deshalb muss Management als kontinuierliche Aufgabe erfasst werden, welche das System (wiederum aufgrund seiner Komplexität) nicht revolutionär (d.h. in seiner Gesamtheit) verändert. Je dynamischer sich die Umwelt eines solchen offenen, adaptiven Systems verhält, desto mehr müssen sämtliche Entscheidungen auf der Basis der jeweils aktuellen Umweltsituation sowie internen Situation getroffen und Veränderungen inkrementell durchgeführt werden. Auf externe Einflüsse kann somit auch während einer Transformation reagiert werden. Der Erfolg dieses Managementan-

68

M. Hafner

satzes wird an der Maximierung der Lebensdauer des Systems durch die Erhaltung seiner Steuerbarkeit im Sinne kontrollierter Flexibilität gegenüber externen Einflussfaktoren festgemacht. Letztere wird erreicht, indem Anforderungen externer Einflussfaktoren als Inkonsistenzen gegenüber dem bestehenden System aufgefasst und integriert werden, sofern sie zur Lebensfähigkeit des Systems beitragen (vgl. Malik 1992, S. 24ff.). Die Ziele, die das konstruktivistisch-technomorphe Managementverständnis direkt anstrebt, versucht das systemisch-evolutionäre Management auf nachhaltigere Art und Weise indirekt zu erreichen. Selbstverständlich muss beachtet werden, dass auch systemisch-evolutionäre Managementansätze nicht sämtliche Führungsprobleme wie Implementierungs-, Akzeptanz-, Motivations- oder Imageprobleme abdecken, so dass Ulrich (1983) berechtigterweise eine „Rekonstruktion des Nicht-Systemischen in der Unternehmung“ in Form eines kulturbewussten Konsensus-Managements fordert. Darüber hinaus ist in Anlehnung an Dachler (1984) zu beachten, dass die Handlungsanweisungen, wie sie eine kybernetisch ausgerichtete Systemtheorie als Grundlage des Managements hervorbringt, grundsätzlich in der Gefahr stehen, für die Praxis nur in begrenztem Masse verwendbar zu sein. Da diesem Beitrag ein systemisch-evolutionäres Verständnis des Managements einer komplexen IS-Architektur zugrunde liegt,5 werden Ansätze, die Malik (1992) als konstruktivistisch-technomorph bezeichnet, nicht weiter verfolgt. Obschon der systemisch-evolutionäre Managementansatz in Bezug auf komplexe soziale Systeme entwickelt wurde und Managemententscheidungen auf der Basis messbarer Kriterien weitgehend negiert werden, lässt sich ein Zusammenhang zum Business Engineering, der methoden- und modellbasierten Konstruktionslehre für Unternehmen (vgl. Österle/Winter 2000, S. 7), herstellen. Dieses liegt den Forschungsarbeiten des Kompetenzzentrums Application Integration Management zugrunde (vgl. O.V. 2003) und geht von einer evolutionären Vorgehensweise nach einer initialen „Systemrevolution“ (z.B. durch Business Process Reengineering) aus (siehe Abb. 2) (vgl. Österle 1995, S. 22f.).

5

Heinrich weist darauf hin, dass der systemtheoretisch-kybernetische Ansatz unter den verschiedenen Denk- und Erklärungsansätzen der Managementlehre für die Wirtschaftsinformatik von besonderem Interesse ist (vgl. Heinrich 2002, S. 7).


69

Da die IS-Architektur ihrerseits als komplexes soziotechnisches System aufgefasst werden kann und vielfältigen Einflüssen aus ihrer Systemumwelt ausgesetzt ist, sollte auch deren Management nach einer initialen Planungs-, Entwicklungs- und Bereitstellungsphase evolutionär betrieben werden.

Abb. 2:

3

Evolution und Revolution (vgl. Österle 1995, S. 23)

Bezugsrahmen für das Management der IS-Architektur

Im Zentrum des Managements der IS-Architektur steht das Informationssystem6 eines Unternehmens. Zunächst soll ein Überblick über gängige Auffassungen zur Abgrenzung des Begriffs gegeben werden, um zu einer mit Hinblick auf das Zielsystem geeigneten Definition zu gelangen. An6

Die Mehrheit der Autoren verwendet den Begriff des Informationssystems (IS) synonym mit dem des Informations- und Kommunikationssystems (IKS), was in diesem Beitrag analog gehandhabt werden soll. Laut Heinrich ist diese Handhabung auf den „siamesischen Zwillingscharakter“ von Information und Kommunikation zurückzuführen, die sich gegenseitig bedingen (vgl. Heinrich 1994, S. 12). Auch nach Krcmar ist die Kommunikation im IS nichts anderes als der notwendige Austausch von Informationen zwischen den Elementen eines Systems und zwischen dem System und seiner Umwelt (vgl. Krcmar 2000, S. 20).

70

M. Hafner

schliessend wird auf Managementaspekte des Informationswesens (Informationsmanagement, IS-Controlling und IS-Management) eingegangen, gegenüber denen das Management der IS-Architektur abzugrenzen ist.

3.1

Das Informationssystem des Unternehmens

Der Begriff des „betrieblichen Informationssystems“ im Sinne des Informationssystems eines Unternehmens wurde von Ferstl/Sinz geprägt (vgl. Ferstl/Sinz 1994, S. 2). Die Autoren fassen unter Informationssystem die menschliche und maschinelle Informationsverarbeitung zusammen, wobei die maschinellen Teile als betriebliche Anwendungssysteme bezeichnet werden. Bei der Analyse und Gestaltung von Informationssystemen werden Aufgaben der Informationsverarbeitung deren Aufgabenträgern (Mensch und Maschine) zugeordnet. Der Grad der Zuordnung von Aufgaben an maschinelle Aufgabenträger entspricht dem Automatisierungsgrad (vgl. Ferstl/Sinz 1994, S. 48). Alpar et al. liefern eine systemorientierte Definition des Informationssystems (siehe Tab. 2). Ein Informationssystem ist demzufolge ein künstliches, konkretes System, das aus maschinellen und natürlichen Elementen besteht und seine Nutzer mit Informationen versorgt. Es ist gegenüber seiner Umwelt offen und muss z.B. aufgrund von Ausfällen als zufällig eingestuft werden. Schliesslich gibt es Rückkopplungsmechanismen, die insbesondere von den Anwendern zu den Entwicklern des Informationssystems wirken, sodass sich das Informationssystem adaptiv verhält (vgl. Alpar et al. 2002, S. 28). Krcmar definiert Informationssysteme ebenfalls als Mensch-MaschineSysteme, fokussiert jedoch den maschinellen Teil, indem er diesen in Form eines Baumes weiter untergliedert und somit im Bereich von Anwendungen zu elementaren Bausteinen wie Daten, Funktionen und Prozessverbindungen gelangt (siehe Abb. 3).


71

Merkmal

Ausprägungen

Entstehung

natürlich

künstlich

Komponenten

natürlich

maschinell

Existenz

konkret

abstrakt

Umweltinteraktion

offen

geschlossen

Verhalten

deterministisch

Anpassung

adaptiv

nicht-adaptiv

Steuerung

mit Rückkopplung

ohne Rückkopplung

stochastisch

zufällig

Merkmalausprägungen für Informationssysteme

Tab. 2:

Eigenschaften von Informationssystemen (in Anlehnung an Alpar et al. 2002, S. 21, 28)

Darüber hinaus hebt Krcmar auf den offenen, dynamischen und komplexen Charakter von Informationssystemen ab (vgl. Krcmar 2000, S. 20). Dies begründet er damit, dass Informationssysteme mit ihrer Umwelt interagieren (Offenheit), wodurch einzelne Elemente ihre Eigenschaften verändern können (Dynamik). Die Komplexität wird durch die grosse Anzahl von Elementen und deren vielfältige Beziehungen erzeugt. Österle stellt ebenfalls die Bedeutung des maschinellen Teils des Informationssystems in den Vordergrund, indem er dessen Unterstützungscharakter gegenüber menschlichen Aufgabenträgern betont. Die natürlichen Komponenten des Informationssystems finden bei der weiteren Untersuchung nur insofern Berücksichtigung, als dass im Sinne des Business Engineerings enge Verflechtungen zwischen der Organisation und dem Informationssystem des Unternehmens existieren (vgl. Österle/Winter 2000, S. 14f.). Auf diese Weise gelangt Österle zu folgender Definition: „Als Informationssystem bezeichnen wir die Gesamtheit der (computerisierten) Informationsverarbeitung. Es besteht aus Applikationen und Datenbanken zur Unterstützung der Aufgabenausführung“ (Österle 1995, S. 58).

72

M. Hafner Informationssysteme

Mensch

Maschine

Anwendung

Daten

Prozesse

Funktionen

Abb. 3:

Hardware

Verbindungen

Informationssysteme als Mensch-Maschine-Systeme (in Anlehnung an Krcmar 2000, S. 73)

Basierend auf den obigen Ansätzen wird das Informationssystem im Folgenden als komplexes, offenes und dynamisches Subsystem eines Unternehmens aufgefasst, das aus maschinellen Komponenten besteht und als solches nach wirtschaftlichen Kriterien der adäquaten Informationsversorgung sowie der Unterstützung menschlicher Aufgabenträger bei der Informationsverarbeitung dient.

3.2

Managementaspekte im Informationswesen des Unternehmens

Entsprechend der zunehmenden strategischen Bedeutung des Informationssystems im Unternehmen (vgl. Österle 1995, S. 1ff.) bedarf es geeigneter Ansätze zu dessen nachhaltiger Gestaltung. Aus diesem Grund wird zunächst das Informationsmanagement betrachtet, das sich mit den ökonomischen Fragestellungen im Umgang mit der Ressource Information, mit der Gestaltung des Informationssystems sowie dessen Umsetzung mittels Werkzeugen der Informationstechnik auseinandersetzt. Dem gegenüber befasst sich das IS-Controlling in erster Linie mit dem ökonomischen Nutzen der Elemente des Informationssystems und betrachtet dessen Weiterentwicklung als Folge von Investitions- und Desinvestitionsentscheidungen. Das IS-Management wird als Teil des Informationsmanagements betrachtet (vgl. Winter 2002, S. 944), das der Fragestellung nach dem Management der IS-Architektur am nächsten kommt.


73

3.2.1 Informationsmanagement Den Ausgangspunkt für das Informationsmanagement bilden die Ebenen nach Wollnik, der ausgehend von der Ebene des Informationseinsatzes Anforderungen an die Ebene der Informations- und Kommunikationssysteme formuliert, die ihrerseits Anforderungen an informations- und kommunikationstechnische Infrastrukturen definieren (siehe Abb. 4) (vgl. Wollnik 1988, S. 38). Die untergeordneten Ebenen kommen den jeweiligen Anforderungen mittels Unterstützungsleistungen bzw. Diensten nach. Informationseinsatz Unterstützungsleistung/Dienste

Anforderungen

Informations- und Kommunikationssysteme Unterstützungsleistung/Dienste

Anforderungen IK-technische Infrastrukturen

Abb. 4:

Ebenen des Informationsmanagements nach Wollnik (1988)

Heinrich gibt einen Überblick über verschiedene Auffassungen des Informationsmanagements (vgl. Heinrich 2002, S. 8ff.), von denen die relevanten hier diskutiert werden sollen. Der leitungszentrierte Ansatz von Heinrich selbst stellt an jede Führungskraft eines Unternehmens die Forderung, laufend zu prüfen, ob die definierten Unternehmensziele durch den Einsatz von Informations- und Kommunikationstechnologien besser erreicht werden können, und entsprechend zu handeln. Dabei anfallende Aufgaben fasst er unter dem Begriff der Informationsfunktion zusammen, die sowohl betriebliche Grund- (Produktion, Vertrieb usw.) als auch Querschnittsfunktionen (Personal, Finanzierung usw.) tangiert. Da sämtliche betriebliche Funktionen betroffen sind, wird das Informationsmanagement als kontinuierliche Aufgabe aufgefasst, die mit der Schaffung, Nutzung und Weiterentwicklung der Infrastruktur der Informationsfunktion (Informationsinfrastruktur) befasst ist (vgl. Heinrich 2002, S. 8). Als allgemeines Formalziel des Informationsmanagements definiert Heinrich die Wirtschaftlichkeit. Das generelle Sachziel des Informationsmanagements (Umsetzung des Leistungspotenti-

74

M. Hafner

als der Informationsfunktion in Unternehmenserfolg für die Erreichung der strategischen Unternehmensziele durch Schaffung und Aufrechterhaltung einer geeigneten Informationsinfrastruktur) soll also bei gegebenen Kosten maximiert bzw. mit minimalen Mitteln erreicht werden (vgl. Heinrich 2002, S. 21f.). Die Aufgaben des Informationsmanagements leiten sich aus dem allgemeinen Sachziel ab und lassen sich drei Ebenen zuordnen (vgl. Heinrich 2002, S. 21): • Auf der strategischen Aufgabenebene werden Aufgaben der Planung, Überwachung und Steuerung der Informationsinfrastruktur in ihrer Gesamtheit wahrgenommen. Das Ergebnis ist die Architektur der Informationsinfrastruktur, die ein kontinuierlich zu aktualisierendes strategisches Projektportfolio nach sich zieht. • Die administrative Aufgabenebene fokussiert die Planung, Überwachung und Steuerung aller Komponenten der Informationsinfrastruktur, so z.B. Anwendungssysteme, Datensysteme, Personal und Betriebsmittel. Das Ergebnis ist der Informationsinfrastruktur-Bestand (z.B. der Bestand an Daten, Personal, Hardware, Software, Methoden, Werkzeugen usw.). • Die operative Aufgabenebene befasst sich mit der Nutzung der im Unternehmen vorhandenen Informationsinfrastruktur. Im Mittelpunkt steht hier die Produktion von Information, ihre Verbreitung und Verwendung. Neben einem ressourcen- und einem prozessorientierten Ansatz (vgl. Heinrich 2002, S. 9f.) identifiziert Heinrich schliesslich einen Führungsansatz. Dieser entspricht dem Modell des St. Galler Informationsmanagements und setzt sich aus betriebswirtschaftlicher Sicht mit der Informationsverarbeitung im Unternehmen auseinander (vgl. Winter 2002, S. 944). Dabei werden wie in Abbildung 5 angedeutet drei Sichten des Informationsmanagements unterschieden, die sich aus der jeweiligen Bedeutung der Informationstechnik für die unterschiedlichen Rollen im Informationsmanagement ergeben (vgl. Österle et al. 1991, S. 28ff.; Winter 2002, S. 944f.): • In Anlehnung an Heinrichs leitungsorientierten Ansatz des Informationsmanagements beschäftigt sich die informationsbewusste Unternehmensführung in erster Linie mit der Umsetzung von unternehmerischen Potentialen, die aus der Informationsverarbeitung resultieren.


75

Diese unternehmerische Sicht7 betrifft alle Bereiche und Hierarchieebenen des Unternehmens. • Im Rahmen einer konzeptionellen Sicht auf das Informationsmanagement, dem Management des Informationssystems, werden die IS-Strategie sowie die IS-Architektur definiert. Im Anschluss daran werden ISProjekte identifiziert und in einem Portfolio priorisiert, ehe sie schliesslich durch das IS-Management betreut werden. • Das Management der Informatik (instrumentelle Sicht) greift jene Aspekte auf, die sich mit der methodischen Organisation und Steuerung des Informationswesens als Funktionalbereich des Unternehmens befassen.

Informations- und Kommunikationstechnik

Unternehmen der Industriegesellschaft

Abb. 5:

Business Engineering

Management der Informatik und Management des Informationssystems

Information Informationsbewusste Unternehmensführung

Unternehmen der Informationsgesellschaft

Sichten auf das St. Galler Konzept des Informationsmanagements (in Anlehnung an Winter 2002, S. 946)

Die systemtheoretische Perspektive auf das Informationsmanagement greifen Gabriel/Beier explizit auf (vgl. Gabriel/Beier 2003, S. 55ff.), womit ein Übergang hergestellt wird zwischen den in Abschnitt 2 gemachten allgemeinen Ausführungen zum systemorientierten Management und dem im vorliegenden Beitrag angestrebten evolutionären Management der IS-Architektur. Das Informationsmanagement wird dabei im Sinne der Kybernetik als Systemlenkung aufgefasst (vgl. Beier 2001), womit die Gestaltung, Steue-

7

Zu dieser und den nachfolgenden Bezeichnungen für die Sichten siehe Alpar et al. (2002, S. 56f.).

76

M. Hafner

rung und Kontrolle des computergestützten Informations- und Kommunikationssystems der Unternehmung verbunden ist. Die Zielsetzung besteht darin, kurzfristig und langfristig die Ziele des Systems zu erreichen. Kurzfristige Lenkungsmassnahmen dienen dabei der Vermeidung bzw. Korrektur von Abweichungen gegenüber Zielzuständen, während langfristig die Anpassungsfähigkeit des Systems an wechselnde Situationen angestrebt wird. Die an obigen Zeithorizonten orientierten Zielsetzungen entsprechen im Wesentlichen denjenigen der Kybernetik I bzw. Kybernetik II (vgl. Gabriel/Beier 2003, S. 57). Als Beispiele für kurzfristige Ziele im Sinne der Beseitigung unternehmensexterner bzw. -interner Störungen können die Kompensierung des krankheitsbedingten Ausfalls von Mitarbeitern als Aufgabenträger der Informationsverarbeitung oder die Überlastung des Informationssystems genannt werden. Der auf Innovation bedachte Ansatz zur langfristigen Systemsteuerung gemäss Kybernetik II sieht vor, Entscheidungskompetenzen an dezentrale Stellen auszulagern, da diese meist bessere Kenntnis über die Anforderungen an das jeweilige Sub-Informationssystem haben als eine Zentralinstanz. Diese beschränkt sich somit auf Koordinationsaufgaben, die Definition von Schnittstellen, die Festlegung genereller, strategischer Zielsetzungen sowie die Bereitstellung entscheidungsrelevanten Wissens für die dezentralen Bereiche.

3.2.2 IS-Controlling Obschon das IS-Controlling laut der in Abschnitt 1 erwähnten Umfrage zum Architekturmanagement kaum direkt auf das Management der ISArchitektur Einfluss nimmt (siehe Abb. 6), soll ihm an dieser Stelle kurz Beachtung geschenkt werden. Dies wird damit begründet, dass das IS-Architekturmanagement über den Rahmen dieses Beitrags hinaus im Sinne des methoden- und modellbasierten Business Engineerings langfristig kennzahlenbasiert sein soll. Der vorliegende Abschnitt soll einen kurzen Überblick über die Potentiale des IS-Controllings für das Management der IS-Architektur skizzieren. Mit dem Controlling der Informationsverarbeitung setzen sich exemplarisch Alpar et al. auseinander (vgl. Alpar et al. 2002, S. 60ff.).8 Sie verstehen darunter den Aufbau einer Infrastruktur, durch die das Informations-

8

Das Werk wurde als Referenz für diesen Beitrag ausgewählt, da es neben dem IS-Controlling den St. Galler Ansatz des Informationsmanagements aufgreift und somit von einem hohen Mass an Konsistenz zwischen den Begriffen Informationsmanagement und IS-Controlling ausgegangen werden kann.


77

management mit Informationen zu seiner Lenkung und zu den Potentialen des Informationssystems versorgt wird. Zwischen dem Informationsmanagement und dem Controlling der Informationsverarbeitung, besteht die Gefahr institutioneller Konflikte (vgl. Alpar et al. 2002, S. 61), da das Controlling die Aktivitäten des Informationsmanagements plant und kontrolliert, was ohne ein effizientes Informationsmanagement jedoch nicht zu leisten ist. Strategische IS-Planung IS-Projekte Technologiemanagement Sicherheitsmanagement IS-Projektportfolio-Mgmt. Unternehmensstrategie Fachabteilungen Datenschutz IS-Betrieb IS-Controlling 0% 0%

10% 10%

20% 20%

Direkt

Abb. 6:

30% 30%

40% 40%

50% 50%

60% 40%

70% 30%

Nicht vorhanden/Unbekannt

80% 20%

90% 10%

100% 0%

Indirekt

Direkte und indirekte Einflussfaktoren auf das Management der ISArchitektur9

Die Aufgaben des IS-Controllings lassen sich grob in strategische und operative gliedern. Strategische Aufgaben umfassen dabei die systematische Erschliessung von Potentialen zur langfristigen Sicherung des Unternehmenserfolgs. Bezogen auf das Informationssystem bedeutet dies z.B. die Koordination zwischen Unternehmensstrategie und langfristiger Ausrichtung des Informationssystems, die Integration neuer Techniken, das Aufspüren von Rationalisierungspotentialen sowie die Auswahl von Instrumenten zur Planung und zum Betrieb des Informationssystems. Auf operativer Ebene steht dagegen die kurzfristige Planung und Kontrolle von Aktivitäten der Informationsverarbeitung sowie deren Koordination im Mittelpunkt. Dabei wird im Gegensatz zum IS-Architekturmanagement

9

Hinweise zur Umfrage siehe Fussnote 4.

78

M. Hafner

jedoch weniger das Informationssystem als Ganzes, sondern vielmehr das einzelne IS-Projekt fokussiert.

3.2.3 Informationssystem-Management Österle et al. entwickelten 1991 den St. Galler Ansatz des Informationssystem-Managements, welcher das Informationswesen aus einer logischkonzeptionellen Perspektive, losgelöst von anderen Dimensionen des Unternehmens wie z.B. Personal oder Produktgestaltung, betrachtet. Im Mittelpunkt der Betrachtung stehen im Gegensatz zum IS-Controlling konkret Daten, Funktionen, Aspekte der Kommunikation sowie organisatorische Fragestellungen (vgl. Winter 2002, S. 947f.). Das IS-Management steht im Austausch mit Fragestellungen der allgemeinen Unternehmens-, aber auch der Marketing-, Finanz- oder Personalplanung. Die Vorgehensweise verläuft prinzipiell in zwei Richtungen (vgl. Winter 2002, S. 949): • Top-Down, z.B. hinsichtlich der Planung von IS-Strategie und ISArchitektur. • Bottom-Up, z.B. müssen Änderungswünsche am Informationssystem, wie sie sich im Rahmen von IS-Projekten ergeben, aufgegriffen werden. Die Aufgaben des IS-Managements können fünf Ebenen zugeordnet werden (siehe Abb. 7) (vgl. Winter 2002, S. 949f.): • Die Ebene der IS-Strategie bildet die Grundlage für die Entwicklung integrierter Informationssysteme. Sie beinhaltet Standards und Grundsätze für das Management sowie die Entwicklung des Informationssystems in Form von Projekten. Die Einhaltung der Grundsätze wird in erster Linie durch Führungsgrössen und konkret definierte Ziele sichergestellt. • Die IS-Architektur10 stellt den zukunftsgerichteten „Bebauungsplan“ für die Entwicklung des Informationssystems dar, während das Applikationsportfolio den Ist-Zustand aller im Unternehmen verwendeten Applikationen beschreibt. Es werden die logischen Strukturen der Informationssystemlandschaft sowie der Organisation dargelegt.

10

Zur singulären Verwendung des Begriffs „IS-Architektur“ siehe Abschnitt3.3.


79

• Das IS-Projektportfolio setzt sich mit den v.a. aus der IS-Architektur abgeleiteten Projekten auseinander, indem diese gemäss unternehmerischen Gesichtspunkten und betrieblichen Abhängigkeiten priorisiert werden. Anschliessend werden den Projekten in der Reihenfolge ihrer Priorisierung entsprechende Ressourcen zugewiesen. • Die IS-Projekte, welche die Grundlage der Weiterentwicklung von Informationssystemen darstellen, müssen zielorientiert geführt und über-wacht werden, um die Vorgaben in den Bereichen Zeit, Kosten und Qualität in zufrieden stellender Weise zu erreichen. Das Management von IS-Projekten trifft hierfür entsprechende Vorkehrungen. • Schliesslich wird das Informationssystem über seine Nutzungszeit hinweg betreut. Diese Aufgabe spiegelt sich in starkem Mass im Bereich des Managements der Informatik wieder (siehe Abschnitt 3.2.1). Das IS-Management befasst sich nach dieser Systematik in erster Linie mit der schrittweisen Verfeinerung von Zielen, Plänen und Entscheidungen hinsichtlich des Informationssystems. Anwendungsbeispiele hierfür sind die Integration des Informationssystems, unternehmensweiter Datenaustausch oder die Realisierung einer unternehmensweiten IS-Architektur (vgl. Winter 2002, S. 950).

80

M. Hafner

Planung

Verabschiedung

Kontrolle

Umsetzung

Abb. 7:

ISStrategie

Planung

Verabschiedung

Kontrolle

Umsetzung

ISArchitektur

Planung

Verabschiedung

Kontrolle

Umsetzung

ISProjektportfolio

Planung

Verabschiedung

Kontrolle

Umsetzung

ISProjekt

Planung

Verabschiedung

Kontrolle

Umsetzung

ISBetreuung

Ebenen des Managements des Informationssystems (in Anlehnung an Winter 2002, S. 949)

Aufgrund seines bereits in der Entwicklung ausgeprägten Praxisbezugs (vgl. Österle et al. 1991, S. 6), der auch für das zu entwickelnde Zielsystem angestrebt wird, bildet das Konzept die Grundlage für die Definition der IS-Architektur in Abschnitt 3.3 sowie ihres Managements in Abschnitt 4. Weitere Ansätze zum Management von Informationssystemen sollen daher an dieser Stelle nicht im Detail beschrieben werden, da sie sich zudem mit der Systematisierung nach Österle et al. (1991) weitgehend decken. Exemplarisch lässt sich dies bei Mertens et al. zeigen, die im Zusammenhang mit der strategischen Planung der Informationsverarbeitung (vgl. Mertens et al. 2001, S. 197ff.) die Definition einer InformationsverarbeitungsStrategie, die Festlegung einer Informationsverarbeitungs-Architektur und schliesslich die Auswahl von Informationsverarbeitungs-Projekten identifizieren. Dies entspricht im Wesentlichen den ersten drei Ebenen in Abbildung 7.


3.3

81

IS-Architektur als Plattform für das IS-Management

Im Folgenden wird eine Definition des IS-Architektur-Begriffs erarbeitet, welche für den weiteren Gang der Diskussion hinreichend ist. Es soll jedoch vorausgeschickt werden, dass in der Literatur keineswegs Einigkeit darüber besteht, ob in einem Unternehmen eine Architektur des Informationssystems oder mehrere solcher Architekturen anzutreffen sind. Beispielsweise trifft Dern eindeutig die Aussage, dass „innerhalb der Anwendungslandschaft eines Unternehmens nicht von der IT-Architektur, sondern von mehreren IT-Architekturen gesprochen werden muss“ (Dern 2003, S. 2). Dem gegenüber baut der Begriff der IS-Architektur nach Sinz auf dem betrieblichen Informationssystem auf und fokussiert somit das gesamte Unternehmen (vgl. Sinz 1997, S. 2). Im Folgenden wird mit der IS-Architektur ebenfalls das gesamte Unternehmen betrachtet. Hinsichtlich der Definition der IS-Architektur lehnen sich zahlreiche Autoren (vgl. Alpar et al. 2002, S. 151f.; Hansen/Neumann 2001, S. 194; Heinrich 2002, S. 68ff.) an Krcmar an (vgl. Krcmar 2000, S. 30f.). Dieser stellt sein Modell der ganzheitlichen Informationssystem-Architektur (ISA) als Kreisel dar, der im Gleichgewicht gehalten werden soll, was gleichbedeutend ist mit der gegenseitigen Abstimmung aller Ebenen der IS-Architektur.

UnternehmensStrategie

Prozessarchitektur

Aufbauorganisationsarchitektur

DatenAnwendungsarchitektur architektur

Kommunikationsarchitektur

IT-Infrastruktur

Abb. 8:

Ganzheitliche Informationssystem-Architektur (ISA) nach Krcmar (1990, S. 399)

In der oberen Spitze des Kreisels (siehe Abb. 8) siedelt Krcmar die Unternehmensstrategie an, die eine Vision zur Verfügung stellen soll, welche sämtliche Ebenen der IS-Architektur durchzieht. Darunter siedelt er die organisatorische Schicht an, die er in eine Prozess- und Aufbauorganisati-

82

M. Hafner

onsarchitektur unterteilt. Auf der darunter liegenden Ebene sind die Anwendungsarchitektur, die Datenarchitektur sowie die Kommunikationsarchitektur aus fachlich-logischer Sicht angesiedelt. In der unteren Spitze des Kreisels befindet sich die IT-Infrastruktur, welche den Einsatz der verschiedenen Informations- und Kommunikationstechnologien an diversen Stellen im Unternehmen beschreibt. Eine ähnliche Unterteilung nehmen Mertens et al. vor. Sie identifizieren eine Informationsverarbeitungs-Architektur, innerhalb derer sie zwischen der IS- und der IT-Architektur unterscheiden. Erstere fokussiert fachliche Anwendungssoftware, die mit Hilfe der Daten- und Funktionsmodellierung oder alternativ der Geschäftsprozessmodellierung erschlossen werden kann. Letztere legt das Hauptaugenmerk auf die informationstechnische Infrastruktur (Hardware, systemnahe Software und technische Aspekte der Vernetzung) eines Unternehmens und definiert diese auf hohem Aggregationsniveau (vgl. Mertens et al. 2001, S. 203ff.). Diese Sichtweise deckt sich weitgehend mit der von Österle et al. vertretenen Auffassung, welche in Abschnitt 3.2.3 kurz beschrieben wurde. Die Betrachtung der Ansätze nach Mertens et al. und Krcmar, welche die IS-Architektur in erster Linie intern strukturieren, aber auch des Ansatzes nach Österle et al., der neben einer Definition auch eine Einordnung der IS-Architektur in das IS-Management vornimmt, zeigt einerseits, dass der allgemeine Architekturbegriff in vielfältigem Kontext verwendet wird. Andererseits ist den Ansätzen gemeinsam, dass sich die IS-Architektur an der Schnittstelle zwischen geschäftlich-funktionalen Anforderungen an das Informationssystem und dessen technischen Restriktionen befindet. Die geschäftlichen Anforderungen nehmen in erster Linie Einfluss auf anwendungsnahe Applikationen und Datenbestände, während die technischen Restriktionen von der IS-Infrastruktur, die Mertens et al. als IT-Architekturen bezeichnen, ausgehen. Es ergibt sich somit die Notwendigkeit eines kontinuierlichen Abstimmungsprozesses zwischen beispielsweise der an fachlichen Anforderungen ausgerichteten IS-Strategie mit den technischen Restriktionen aus IS-Projekten.11 Die logisch-konzeptionelle Sicht der IS-Architektur (vgl. Winter 2002, S. 948) gewährleistet dabei jene Granularität, die es sowohl dem Management des unternehmerischen Kerngeschäfts als auch den Mitar-

11

Den Einfluss der IS-Strategie und der IS-Projekte auf die IS-Architektur verdeutlicht Abbildung 6.


83

beitern der Informationstechnik ermöglicht, in Kommunikation zu treten.12 Konkret bedeutet dies, dass den Elementen der Applikationslandschaft eines Informationssystems Funktionalität, Daten und organisatorische Einheiten zugeordnet werden (vgl. Österle et al. 1991, S. 69). Winter schliesst sich dem mit seinem Modell der Applikationsarchitektur an (siehe Abb. 9), indem er die operativen Applikationen eines Unternehmens ebenfalls hinsichtlich ihrer Informationssubjekte, angebotenen Funktionalität und ihrer Zuordnung zu Organisationseinheiten respektive Produktlinien strukturiert.13

Abb. 9: 12

Idealtypische Applikationsarchitektur nach Winter (2003a)

Brenner et al. weisen auf die beiden Sichten der Applikationsarchitektur hin, die sowohl fachliche als auch technisch orientierte Aspekte beinhaltet (vgl. Brenner et al. 2003, S. 157). Auch Dern weist auf die Rolle von Architekturen im Rahmen des Business-IT-Alignments hin (vgl. Dern 2003, S. 4). Nach Krcmar umfasst die IS-Architektur ebenfalls fachliche und technische Aspekte (vgl. Krcmar 1990, S. 399). 13 In Abgrenzung zu den vorgenannten Ansätzen gelingt es Winter mit seinem Ansatz sämtliche Aspekte der mittleren Ebenen des Architekturkreisels nach Krcmar (siehe Abb. 9) ansatzweise in einem Modell aufzugreifen.

84

M. Hafner

Neben ihrer Funktion als Abstimmungsmechanismus bildet die IS-Architektur den zukunftsgerichteten logisch-konzeptionellen Rahmen für die Weiterentwicklung des Informationssystems im Sinne eines evolutionären Managements, wie es bereits zu Beginn der 90-er Jahre von Österle et al. gefordert wurde (vgl. Österle et al. 1991, S. 69f.). Dies impliziert, dass die IS-Architektur sowohl statische als auch dynamische Aspekte umfassen sollte. Festl et al. greifen dies auf, indem sie als Bestandteile der Architektur betrieblicher Informationssysteme „(1) den „Bauplan“ eines betrieblichen Informationssystems im Sinne einer Beschreibung seiner Komponenten und ihrer Beziehungen unter allen relevanten Blickwinkeln sowie (2) die „Konstruktionsregeln“ für die Erstellung des Bauplans“ (Ferstl/Sinz 1996, S. 31) identifizieren. Auch Brenner et al. schliessen sich dem an, indem sie für die Applikationsarchitektur, welche aufgrund ihres dortigen logisch-konzeptionellen Charakters am ehesten dem hier verwendeten Verständnis der IS-Architektur entspricht, die Beschreibung ihrer Funktionalität (statische Sicht auf die Applikationslandschaft) sowie ihrer Designprinzipien und genutzten Standards (dynamische Sicht) fordern (vgl. Brenner et al. 2003, S. 157). Dem Beitrag liegt somit folgendes Architekturverständnis zugrunde: Die IS-Architektur besteht einerseits aus einem statischen Modell des Informationssystems des Unternehmens auf logisch-konzeptioneller Ebene, das sich beispielsweise an einem Framework, wie es Winter in Abbildung 9 vorschlägt, anlehnt und somit in mehreren Sichten (Funktionalität, Information, Organisationseinheit) verfügbar ist. Andererseits definieren Regeln und Prinzipien den (dynamischen) Umgang mit der IS-Architektur bzw. den Interessen, wie sie im Umfeld der IS-Architektur auftreten (z.B. IS-Strategie, IS-Controlling, IS-Projekte, Technologieausblick etc.). Sie sind auf die Erreichung künftiger Versionen der IS-Architektur ausgerichtet, wobei die ständige Redefinition von zukünftigen Architekturen respektive der darauf abgestimmten Transformationsregeln im Rahmen des ISArchitekturmanagements möglich sein soll. Auf diese Weise dient die ISArchitektur als transparente Kommunikations- und Arbeitsplattform zwischen den verschiedenen Einflussfaktoren, die sich um die IS-Architektur gruppieren. Um diese Plattform systematisch einsetzen zu können, wird im folgenden Abschnitt ein Zielsystem definiert, das es zugleich ermöglichen soll, Anforderungen an das Management der IS-Architektur im Unternehmen abzuleiten.


4

85

Ordnungsrahmen für das Management der IS-Architektur

Die Ausführungen in Abschnitt 3 haben gezeigt, wo das Management der IS-Architektur bezüglich des Informations-, des IS-Managements bzw. des IS-Controllings im Unternehmen angesiedelt ist. Bevor das Management der IS-Architektur in diesem Abschnitt bezüglich seiner Innensicht in Form von Anforderungen charakterisiert wird, bedarf es einer Begründung für die Notwendigkeit eines expliziten IS-Architekturmanagements. Eine besondere Rolle spielen dabei die im Laufe der vergangenen Jahre gestiegenen Anforderungen an das IS-Management, wie sie in Abschnitt 1 bereits angedeutet wurden und in Abschnitt 4.1 näher ausgeführt werden. Aufgrund des kontinuierlichen Wandels der Anforderungen kann davon ausgegangen werden, dass eine völlige Konformität der realen Applikationslandschaft respektive ihrer Transformationsprojekte mit der angestrebten IS-Architektur der Ausnahmefall ist. Ein explizites Management von Inkonsistenzen zwischen der Ist-Architektur und diversen Soll-Architekturvarianten geht über die klassische Systementwicklung, von der auch das IS-Management weitgehend geprägt ist (siehe Abschnitt 3.2.3), hinaus und lässt eine Kapselung der Aufgaben des IS-Architekturmanagements gegenüber dem IS-Management sinnvoll erscheinen.

4.1

Zielsystem für das Management der IS-Architektur

Das Zielsystem für das Management der IS-Architektur soll ausgehend von einer Analyse der Anspruchsgruppen, die sich im Unternehmensumfeld befinden, aufgestellt werden. Die Basis hierfür bildet das „Neue St. Galler Managementmodell“ (siehe Abb. 10). Dies wird damit begründet, dass es den Ansatz des systemisch-evolutionären Managements aufgreift (siehe Abschnitt 2.2.2). Die einzelnen Gruppen wirken auf das Unternehmen, auf seine Weiterentwicklung und somit auf die Weiterentwicklung seines Informationssystems14 ein, indem sie aktiv mit dem Unternehmen interagieren und diesem entweder Rahmenbedingungen bzw. Ressourcen zur Verfügung stellen (z.B. Lieferanten, Staat

14

Da das Informationsmanagement als Unterstützungsprozess des Unternehmens aufgefasst wird, bildet das „Neue St. Galler Managementmodell“ einen weiteren Übergang zwischen dem systemorientierten Management und dem Informationsmanagement respektive dem Management der IS-Architektur.

86

M. Hafner

usw.) oder von der unternehmerischen Wertschöpfung betroffen sind (z.B. Kunden, Mitarbeitende usw.).15 Tabelle 3 gibt in den beiden linken Spalten eine Übersicht über die Anspruchsgruppen im Umfeld des Unternehmens und ihre Zielsetzungen. Im rechten Teil stellt Tabelle 3 den Zielsetzungen der Anspruchsgruppen die kritischen Erfolgsfaktoren für Unternehmensprozesse nach Österle in angepasster Form gegenüber. Die ursprünglichen kritischen Erfolgsfaktoren definiert Österle folgendermassen (vgl. Österle 1995, S. 109f.): • Der Kostenaspekt impliziert die effiziente Erbringung einer Leistung zu einem wettbewerbsfähigen Preis. • Mit Qualität verbunden ist die Erfüllung von Kundenbedürfnissen. • Unter Zeit ist zu verstehen, dass Prozessleistungen schnell erbracht und zugesagte Termine eingehalten werden. • Durch Flexibilität deckt das Unternehmen variierende Kundenanforderungen ab.

15

Der Ansatz der Anspruchsgruppenanalyse wird verfolgt, da das Management der IS-Architektur von den Anspruchsgruppen bzw. Einflussfaktoren in seinem Umfeld ausgehen soll. In diesem Kontext soll unter einer Anspruchsgruppe eine Gruppe oder Einzelperson verstanden werden, die auf die Gestaltung der IS-Architektur Einfluss nehmen möchte. Zum einen ist dies hinsichtlich der Definition von Soll-Architekturen bzw. der Transformation von Architekturen insbesondere aus fachlicher Sicht denkbar. Zum anderen gibt es Anspruchsgruppen, welche die fachlichen Anforderungen an die Architektur hinsichtlich ihrer technischen Realisierbarkeit oder aufgrund bereits existierender gesetzter Standards limitieren. Somit lassen sich auf Ebene des ISArchitekturmanagements fachliche und technische Anspruchsgruppen unterscheiden, die jeweils direkt oder indirekt auf die IS-Architektur Einfluss nehmen.


87 Gesellschaft Natur Technologie Wirtschaft Kapitalgeber

Konkurrenz

en ur

r l tu Ku

g Kunden

g

Lieferanten

n ru ie

Managementprozesse

im pt

kt ru St

n ru ue ne Er

ie eg

O

t ra St

Geschäftsprozesse Unterstützungsprozesse

Ressourcen Normen und Werte Anliegen und Interessen

Staat

Mitarbeitende

Öffentlichkeit NGOs

Prozesse

Anspruchsgruppen

Ordnungsmomente

Umweltsphären

Entwicklungsmodi

Interaktionsthemen

Abb. 10: Das neue St. Galler Managementmodell im Überblick (in Anlehnung an Rüegg-Stürm 2002, S. 39)

88

M. Hafner

Gewinn, Existenzsicherung

Kunden

Preis, Qualität, Service, Termine

Mitarbeitende/Arbeitnehmer

Einkommen, soziale Aspekte

Öffentlichkeit, Staat, NGOs

Umwelt, Beschäftigung, Steuern

Lieferanten

Absatz, Zahlung

Hohe Relevanz

Tab. 3:

Mittlere Relevanz

Lenkbarkeit

Kapitalgeber/Eigentümer

Zeit

Zielsetzung

Qualität

Anspruchsgruppe

Wirtschaftlichkeit

Kritische Erfolgsfaktoren

Geringe Relevanz

Zielsetzungen von Anspruchsgruppen im Umfeld des Unternehmens und Gegenüberstellung kritischer Erfolgsfaktoren für das Unternehmen (in Anlehnung an Grabatin 1981, S. 111ff.)

Die kritischen Erfolgsfaktoren sollen jedoch mit den Anforderungen eines systemisch-evolutionären Managementansatzes (siehe Abschnitt 2.2.2) in Einklang gebracht werden, da hierauf das zu entwickelnde Management der IS-Architektur eines Unternehmens gründen soll. Aus diesem Grund erfährt der Erfolgsfaktor „Kosten“ durch den Erfolgsfaktor „Wirtschaftlichkeit“ eine Erweiterung, indem die Nutzenpotentiale stärker betont werden. Zum anderen wird der Faktor „Flexibilität“ im Sinne des systemisch-evolutionären Managements in „Lenkbarkeit“ umgewandelt, womit das kontinuierliche Abwägen zwischen den variierenden Bedürfnissen der Anspruchsgruppen verbunden ist. Inwiefern ein einzelnes Unternehmen die genannten Zielsetzungen aus seinem Umfeld akzeptiert, bleibt seiner strategischen Ausrichtung überlassen. In Tabelle 3 wird rechts unten eine Einschätzung vorgenommen, welche der angepassten Erfolgsfaktoren in besonderer Weise von den Zielsetzungen der einzelnen Stakeholder betroffen sind. Die Betrachtung ergibt, dass „Wirtschaftlichkeit“ und „Lenkbarkeit“ die beiden übergreifenden Erfolgsfaktoren unternehmerischen Handelns darstellen, während die Kunden eines Unternehmens als einzige Anspruchsgruppe das gesamte Spektrum an Erfolgsfaktoren beanspruchen.


4.2

89

Einordnung des Informationsmanagements in das Zielsystem

Das Informationsmanagement als Unterstützungsprozess des Unternehmens nimmt sich der angepassten Erfolgsfaktoren an, wenn z.B. Heinrich als Sachziel des Informationsmanagements fordert, dass „das Leistungspotential der Informationsfunktion für die Erreichung der strategischen Unternehmensziele durch die Schaffung und Aufrechterhaltung einer geeigneten Informationsinfrastruktur in Unternehmenserfolg umzusetzen“ (Heinrich 2002, S. 21f.) ist. Winter führt eine Reihe von unternehmerischen Formalzielen an, denen das Informationsmanagement im Rahmen der informationsbewussten Unternehmensführung verpflichtet ist: Flexibilität, Geschwindigkeit, Kosten, Qualität, Ressourcenoptimierung, Sicherheit und Transparenz (vgl. Winter 2002, S. 947). Diese werden somit als konkrete Formalziele des Informationsmanagements aufgefasst und neben dem oben skizzierten Sachziel der Aufrechterhaltung des Informationssystems im Spannungsfeld der angepassten Prozess-Erfolgsfaktoren grob eingeordnet (siehe Abb. 11). Auf diese Weise wird angedeutet, dass die Formalziele des Informationsmanagements traditionell die unternehmerischen Zielsetzungen „Zeit“, „Wirtschaftlichkeit“ und „Qualität“ fokussieren, während der Aspekt der „Lenkbarkeit“ zwar als Sachziel (Aufrechterhaltung) gefordert, kaum jedoch explizit aufgegriffen wird. Nachhaltigkeit/ Lenkbarkeit Aufrechterhaltung

Transparenz Flexibilität Sicherheit

Zeit

Geschwindigkeit

Qualität

Ressourcenoptimierung

Qualität

Formalziele Sachziel

Kosten

Wirtschaftlichkeit

Abb. 11: Unternehmerische Ziele und Ziele des Informationsmanagements

90

M. Hafner

4.2.1 Auswirkungen erhöhter Dynamik und Komplexität auf das Zielsystem Die in Abschnitt 1 erwähnte und in Abbildung 12 auf der rechten Seite mit Pfeilen dargestellte Zunahme von Dynamik und Komplexität durch diverse Einflussfaktoren16 im Unternehmens- und IS-Architektur-Umfeld führen zu nicht vermeidbarer Heterogenität in der IS-Architektur. Folglich muss ihre Aufrechterhaltung respektive Lenkbarkeit stärker fokussiert und in Form eines expliziten Managements institutionalisiert werden. Konkret bedeutet dies, dass den Formalzielen Flexibilität und Transparenz, die im Rahmen des Informationsmanagements die grössten Affinitäten zum Sachziel der Aufrechterhaltung des Informationssystems aufweisen, höhere Bedeutung zuzumessen ist (Verschiebung der beiden Formalziele „Flexibilität“ und „Transparenz“ in Abbildung 12 nach oben). Variier. Gesch.modelle

IS-Architekturmanagement

Unt.zusammenschlüsse

Nachhaltigkeit/

Business-IT-Algmt./ RestriktionsKonsistenz IT-Governance Lenkbarkeit integration Anforderungsintegration Aufrechterhaltung Situationsorientierung Transparenz Flexibilität Wartbarkeit

Gesetzliche Vorgaben Time-to-Market-Anford.

Transparenz Flexibilität

Techn. Innovationszyklen Sicherheit

Zeit

Reorganisation Fachliche Anforderungen

Geschwindigkeit

Qualität

Ressourcenoptimierung

Formalziele

Kosten

Sachziel

Wirtschaftlichkeit

Qualität Ziel des Arch.mgmt. Herausforderung Zielverschiebung Nutzen

Abb. 12: Ziele und Wirkungsweise des IS-Architekturmanagements

Zudem bedarf es einer Konkretisierung des Sachziels Aufrechterhaltung des Informationssystems durch weitere Formalziele (siehe Abb. 12), die sich an die Forderungen des systemisch-evolutionären Managements anlehnen. Hierfür werden die bereits beschriebene Integration fachlicher Anforderungen und technischer Restriktionen vorgeschlagen. Darüber hin16

Die Herausforderungen in Abbildung 12 sind exemplarisch. Weitere Einflussfaktoren finden sich z.B. bei Brenner et al. (vgl. Brenner et al. 2003, S. 151), bzw. die Dynamik im Umfeld der IS-Architektur zeigt Abbildung 1.


91

aus sollte das Management der IS-Architektur anstreben, zwischen sämtlichen Anforderungen und bereits existierenden Vorgaben seitens der IS-Architektur situationsorientiert Konsistenz herzustellen. Die Verbindung und Kapselung dieser Formalziele (Kasten „IS-Architekturmanagement in Abbildung 12) führt zu einem evolutionären Management der IS-Architektur, wie es in Abschnitt 2.2.2 grundlegend diskutiert wurde. Gemäss den Grundsätzen des systemisch-evolutionären Managements werden auf diese Weise die übrigen Formalziele des Informationsmanagements, welche grösstenteils direkt unternehmerische Zielsetzungen abdecken, auf indirekte Weise unterstützt (Gepunktete Linien in Abbildung 12). Das Management der IS-Architektur verfolgt somit keine zusätzlichen Zielsetzungen, sondern trägt dazu bei, bestehende Ziele auf nachhaltige Art und Weise zu unterstützen.

4.3

Anforderungen an das Management der IS-Architektur

Aus dem oben skizzierten Zielsystem ergeben sich einige grundlegende Anforderungen an Ansätze für das Management der IS-Architektur. Diese sollen im Folgenden kurz beschrieben werden. • Skalierbarkeit. Der zunehmende Einsatz computergestützter Informationssysteme im Unternehmen führt in der Regel zu einer erhöhten Varietät in der Applikationslandschaft und somit zu einer zunehmend komplexen IS-Architektur (vgl. Brenner et al. 2003, S. 150f.). Ein Ansatz zum Management der IS-Architektur muss daher Aussagen zu seiner Skalierbarkeit treffen, d.h. darüber, wie mit einer zunehmend komplexen IS-Architektur über den Versuch der Standardisierung hinaus umgegangen wird. • Evolutionärer Charakter. Die ständig auftretenden Einflussfaktoren auf das Management der IS-Architektur (fachliche Vorgaben, technische Restriktionen etc.) machen es notwendig, dass ein Ansatz zum IS-Architekturmanagement kontinuierlich zwischen der langfristigen Ausrichtung der IS-Architektur und kurzfristigem unternehmerischem Erfolg abwägt, Anforderungen integriert und somit die Dynamik des Umfelds beherrscht. Im Idealfall sollte der Managementansatz im Sinne von Abschnitt 2.2.2 als evolutionär bezeichnet werden können. • Fokussierung von Inkonsistenzen. Eng mit den ersten beiden Punkten verbunden ist die Tatsache, dass Inkonsistenzen sowohl innerhalb der IS-Architektur als auch zwischen der IS-Architektur und den Anforderungen seitens ihrer Einflussfaktoren der Regelfall sind. Eine durch-

92

M. Hafner

gängige, widerspruchsfreie IS-Architektur wird falls überhaupt, nur in den seltensten Fällen erreicht. Dies sollte ein entsprechender Managementansatz aufgreifen und zugleich weniger die Aufhebung sämtlicher Inkonsistenzen anstreben als vielmehr den situationsorientierten Umgang mit ihnen im Sinne der Kybernetik II. • Visionsbildung. Neben der Fortschreibung der IS-Architektur aufgrund von fachlichen Anforderungen und technischen Restriktionen muss das Management der IS-Architektur proaktiv den Rahmen für die Fortschreibung zur Verfügung stellen, was im Sinne des Business Engineerings mit der Formulierung einer Vision17 und der Darlegung der Varianten und Etappen zu ihrer Erreichung umgesetzt werden sollte. Die stringente Durchsetzung des Rahmenwerks fällt jedoch nicht unbedingt in den Aufgabenbereich des IS-Architekturmanagements, sondern sollte vornehmlich von der Balance zwischen fachlichen Anforderungen und technischen Restriktionen getrieben sein (vgl. Greta 2002). • Einsatz von Modellen, Methoden und Kennzahlensystemen. Obschon ein evolutionäres Management der IS-Architektur von einer Reihe nicht formalisierbarer respektive planbarer Einflussfaktoren getrieben ist, sollten im Sinne des Business Engineerings (vgl. Winter 2003b, S. 88) bzw. in Anlehnung an ein Reifegradmodell (z.B. in Anlehnung an das Capability Maturity Model (CMM) (vgl. Dymond 2002) zunehmend dedizierte Modelle, Methoden und Kennzahlensysteme zum Einsatz kommen. Auf diese Weise würde das Management messbar in Richtung der Lenkbarkeit der IS-Architektur verbessert. • Transformationsregeln. Daran anschliessend sollte das Management der IS-Architektur Transformationsregeln aufstellen (vgl. Dern 2003, S. 108), die den Weg zu einer formulierten Vision der IS-Architektur operationalisieren und Entscheidungen des Managements der IS-Architektur gegenüber fachlichen oder technischen Anforderungen transparent gestalten können. Dabei empfiehlt sich ein hierarchisches Konzept, das neben kaum verhandelbaren Prinzipien der IS-Architektur auch Leitlinien mit Empfehlungscharakter enthält. • Analyse von Einflussfaktoren. Da die Einflussfaktoren aus dem Umfeld der IS-Architektur eine dominante Rolle spielen, sollte sie das Management der IS-Architektur einer ständigen Analyse unterziehen, um ihre jeweiligen Zielsetzungen langfristig zu kennen. Auf diese Weise 17

In Anlehnung an Österle, wo die Visionsbildung für Prozesse beschrieben ist (vgl. Österle 1995, S. 63).


93

lassen sich Entwicklungen des Unternehmens absehen und die Weiterentwicklung der IS-Architektur entsprechend anpassen. • Positionierung. Die Erkenntnisse der ständigen Umfeldanalyse sollten in eine explizite Positionierung des IS-Architekturmanagements einfliessen. Deren Bestandteile sollten u.a. der Grad der Serviceorientierung oder in Abhängigkeit des Management Commitments das Mass an Einflussmöglichkeit (z.B. hinsichtlich der Bildung der IS-Strategie oder des IS-Projektportfoliomanagements) sein. • Anschlussfähigkeit. In Abhängigkeit der Einflussmöglichkeiten (z.B. gegenüber der IS-Strategie bzw. des IS-Projektportfolios) ergibt sich die Definition von Informationsschnittstellen und Aufgabenabgrenzungen zu den einzelnen Phasen des IS-Managements sowie weiteren Aufgaben des Informationsmanagements und des IS-Controllings. Auf diese Weise wird die Anschlussfähigkeit des Managements der IS-Architektur gewährleistet. • Organisatorische Einbettung. Die Anschlussfähigkeit des IS-Archi-

tekturmanagements sollte nicht nur auf der Ebene von Aufgabenbereichen fokussiert werden, sondern auch aus organisatorischer Sicht. So bedarf das Management der IS-Architektur der aufbau- und ablauforganisatorischen Einbettung im Unternehmen und insbesondere im Informationsmanagement.

5

Zusammenfassung und Ausblick

Das Informationsmanagement in Unternehmungen sieht sich Herausforderungen mit zunehmender Dynamik und Komplexität gegenüber, welche vielfach direkt Einfluss auf die Architektur des Informationssystems nehmen. Beispiele hierfür sind variierende Geschäftsmodelle, Unternehmenszusammenschlüsse und damit verbundene Reorganisationen, fachliche und gesetzliche Anforderungen oder hohe Time-to-Market-Anforderungen bei geringen technischen Innovationszyklen. Aus diesem Grund bedarf es eines Ansatzes zum systemisch-evolutionären Management der IS-Architektur, welcher den dynamischen und komplexen Herausforderungen adäquat begegnet. Im vorliegenden Beitrag wurden Zielsetzungen und Anforderungen entwickelt, welche die Grundlage für ein solches Management der IS-Architektur sein können. Dazu wurde in Abschnitt 2 auf die Grundlagen der Sys-

94

M. Hafner

temtheorie sowie des systemisch-evolutionären Managements eingegangen. In Abschnitt 3 wurde das Architekturmanagement begrifflich definiert sowie gegenüber dem IS-Controlling abgegrenzt und in das traditionelle Informationsmanagement eingeordnet. In Abschnitt 4 wurde unabhängig von den heterogenen Auffassungen zum Architekturmanagement in Theorie und Praxis ein Zielsystem respektive Anforderungen für das evolutionäre Architekturmanagement auf der Grundlage des allgemeinen systemisch-evolutionären sowie des Informationsmanagements entwickelt. Hinsichtlich des weiteren Forschungsbedarfs sollten die verschiedenen existierenden Ansätze zum Architekturmanagement in Theorie und Praxis auf die Erfüllung der gestellten Anforderungen hin untersucht werden sowie ein allgemeingültiger Ansatz zum Management der IS-Architektur entwickelt werden.

Literatur Alpar, P.; Grob, H.-L.; Weimann, P.; Winter, R.: Anwendungsorientierte Wirtschaftsinformatik, 3. Aufl., Braunschweig/Wiesbaden, 2002. Baumöl, U.; Winter, R.: Qualifikation für die Veränderung, in: Österle, H.; Winter R. (Hrsg.): Business Engineering, 2. Aufl., Berlin et al., 2003, S. 45-61. Beier, D.: Informationsmanagement aus Sicht der Betriebswirtschaftslehre: theoretische Ansätze und das Beispiel Mobile Business, Universität Bochum, Bochum, 2001. Bleicher, K.: Unternehmungsentwicklung und organisatorische Gestaltung, Stuttgart/New York, 1979. Brenner, W.; Zarnekow, R.; Pörtig, F.: Entwicklungstendenzen im Informationsmanagement, in: Österle, H.; Winter R. (Hrsg): Business Engineering, 2. Aufl., Berlin et al.., 2003, S. 147-168. Dachler, H.P.: Grenzen der Erklärungskraft biologischer und organismischer Eigenschaften von Humansystemen, in: Ulrich, H.; Malik, F.; Probst, G.; Semmel, M.; Dyllick, T.; Dachler, P.; Walter-Busch, E. (Hrsg): Grundlegung einer Allgemeinen Theorie der Gestaltung, Lenkung und Entwicklung zweckorientierter sozialer Systeme, Diskussionsbeitrag Nummer 4, Institut für Betriebswirtschaft Universität St. Gallen, St. Gallen, 1984, S. 191-225. Daenzer, W.F.; Huber, F.: Systems-Engineering – Methodik und Praxis, Zürich, 1999.


95

Dern, G.: Management von IT-Architekturen - Informationssysteme im Fokus von Architekturplanung und -entwicklung, Wiesbaden, 2003. Dietzsch, A.: Positionierung eines Unternehmensarchitektur-Ansatzes: Erfahrung der Schweizerischen Mobiliar im Architekturmanagement, http://aim.iwi.unisg.ch/veranstaltungen/akea/downloads/ProceedingsAkEA.pdf, Abruf am 2003-11-04. Dymond, K.M.: CMM-Handbuch: das Capability Maturity Model für Software, Berlin et al., 2002. Ferstl, O.K.; Sinz, E.J.: Grundlagen der Wirtschaftsinformatik, 2. Aufl., München, 1994. Ferstl, O.K.; Sinz, E.J.; Amberg, M.: Stichwörter zum Fachgebiet Wirtschaftsinformatik, 1996. Franken, R.; Fuchs, H.: Grundbegriffe zur Allgemeinen Systemtheorie, in: Systemtheorie und Betrieb, Schmalenbachs Zeitschrift für betriebswirtschaftli-che For-schung (1974), Sonderheft 3, S. 23-49. Gabriel, R.; Beier, D.: Informationsmanagement in Organisationen, Stuttgart, 2003. Grabatin, G.: Effizienz von Organisationen, Berlin/New York, 1981. Greta, J.: Seven Architecture Management Best Practices, http://poseidon.iwi3.unisg.ch/gartner/content/research/112300/ 112330/112330.html, Abruf am 2003-08-13. Haberfellner, R.: Die Unternehmung als dynamisches System: Der Prozesscharakter der Unternehmensaktivitäten, Zürich, 1974. Hansen, H.R.; Neumann, G.: Grundlagen betrieblicher Informationsverarbeitung, 8. Aufl., Stuttgart, 2001. Heinrich, L.J.: Systemplanung – Planung und Realisierung von Informatikprojekten, Band 1, Der Prozess der Systemplanung, der Vorstudie und der Feinstudie, 6. Aufl., München/Wien, 1994. Heinrich, L.J.: Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur, 7. Aufl., München/Wien, 2002. Hill, W.; Fehlbaum, R.; Ulrich, P.: Organisationslehre, Band 1: Ziele, Instrumente und Bedingungen der Organisation sozialer Systeme, 5. Aufl., Bern et al., 1994. Jagoda, F.: Business und IT integriert betrachten, in: Computerwoche Extra (1999), 1, S. 4-12.

96

M. Hafner

Jantsch, E.; Seiffert, H.: System, Systemtheorie, in: Seiffert, H.; Radnitzky, G. (Hrsg.): Handlexikon zur Wissenschaftstheorie, 2. Aufl., München, 1994, S. 329-338. Kast, F.E.; Rosenzweig, J.E.: Organization and management, a systems and contingency approach, 4. Aufl., New York et al., 1985. Keller, W.: Sanfte Migration. Architekturmanagement in der Generali-Gruppe, http://www.objectarchitects.de/ObjectArchitects/papers/Presentations/ZippedPapers/IIRandOTG2000ArchitekturmanagementV01.pdf, Abruf am 2003-0807. Krauch, H.: Systemanalyse, in: Seiffert, H.; Radnitzky, G. (Hrsg.): Handlexikon zur Wissenschaftstheorie, 2. Aufl., München, 1994, S. 338-344. Krcmar, H.: Bedeutung und Ziele von Informationssystemarchitekturen, in: Wirtschaftsinformatik 32 (1990), 5, S. 395-402. Krcmar, H.: Informationsmanagement, 2. Aufl., Berlin, 2000. Krüger, S.; Seelmann-Eggebert, J.: IT-Architektur-Engineering – Systemkomplexität bewältigen, Kosten senken, Potentiale freisetzen, Bonn, 2003. Malik, F.: Strategie des Managements komplexer Systeme: ein Beitrag zur Management-Kybernetik evolutionärer Systeme, 4. Aufl., Bern/Stuttgart, 1992. Maruyama, M.: The second cybernetics: Deviation amplifying mutual causal processes, in: American Scientist 51 (1963), S. 164-179. Mertens, P.; Bodendorf, F.; König, W.; Picot, A.; Schumann, M.: Grundzüge der Wirtschaftsinformatik, 7. Aufl., Berlin et al., 2001. Österle, H.: Business Engineering: Prozess- und Systementwicklung, 2. Aufl., Berlin et al., 1995. Österle, H., Brenner, W., Hilbers, K.: Unternehmensführung und Informationssystem, 1. Aufl., Stuttgart, 1991. Österle, H.; Winter, R.: Business Engineering, in: (Hrsg.): Berlin et al., 2000, S. 3-20. Österle, H.; Winter, R.: Business Engineering, in: (Hrsg.): 2. Aufl., Berlin et al., 2003, S. 3-20. O.V.: CC AIM – Konzept und Idee, http://aim.iwi.unisg.ch, Abruf am 2003-09-27. Perks, C.; Beveridge, T.: Guide to Enterprise IT Architecture, New York, 2003. Rohloff, M.: Bausteine einer Unternehmensarchitektur: Die Integration von Geschäfts- und IT-Architektur, http://aim.iwi.unisg.ch/veranstaltungen/akea/downloads/ProceedingsAkEA.pdf, Abruf am 2004-11-02.


97

Rüegg-Stürm, J.: Das neue St. Galler Management-Modell, in: (Hrsg.): Bern et al., 2002, S. 33-106. Sinz, E.J.: Architektur betrieblicher Informationssysteme, 1997. Staehle, W.H.: Management: eine verhaltenswissenschaftliche Perspektive, 8. Aufl., überar-beitet von Conrad, P.; Sydow, J., München, 1999. Teubner, R.A.: Organisations- und Informationssystemgestaltung: Theoretische Grundlagen und integrierte Methoden, Wiesbaden, 1999. Ulrich, H.: Management, Hrsg. von Dyllick, T.; Probst, G., Bern, 1984. Ulrich, P.: Konsensus-Management: Die zweite Dimension rationaler Unternehmensführung, in: Betriebswirtschaftliche Forschung und Praxis 35 (1983), 1, S. 70-84. Winter, R.: Informationsmanagement, in: (Hrsg): Pilotversion, Bern, 2002, S. 929-969. Winter, R.: An Architecture Model for Supporting Application Integration Decisions, Proc. 11th European Conference on Information Systems, Naples, 2003a. Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: Österle, H.; Winter, R. (Hrsg.): 2. Aufl., Berlin et al., 2003b, S. 87-118. Winter, R.; Leist, S.; Fugmann, T.; Heinrich, B.: Banking im Informationszeitalter – Formen und Gestaltungsfragen von Wertschöpfungsnetzwerken im Bankbereich, 1999. Wollnik, M.: Ein Referenzmodell des Informations-Managements, in: Information Management 3 (1988), 3, S. 34-43. Zangemeister, C.: Nutzwertanalyse in der Systemtechnik: Eine Methodik zur multidimensionalen Bewertung und Auswahl von Projektalternativen, 4. Aufl., München, 1976

Berücksichtigung des Architekturmanagements in serviceorientierten IT-Managementkonzepten am Beispiel von ITIL Martin Hafner, Joachim Schelp, Robert Winter Universität St. Gallen

In der Praxis setzen sich serviceorientierte Konzepte des IT-Managements langsam durch. Nach ihrer Umsetzung führen sie zu einer verbesserten Berücksichtigung der fachlichen Anforderungen sowohl in der Applikationserstellung wie im Betrieb der Applikationen. Fragen der langfristigen Entwicklung der betrieblichen Applikationslandschaft werden üblicherweise nicht explizit behandelt. In diesem Beitrag wird daher anhand der verbreiteten IT Infrastructure Library (ITIL) hinterfragt, ob diese auch Aspekte des längerfristigen Managements einer betrieblichen Applikationslandschaft beinhaltet. Vor diesem Hintergrund werden einige Eckpunkte des Architekturmanagements skizziert, das sich in ein ServiceManagement wie von ITIL vorgeschlagen integrieren lässt.

1 2

3

4

Einführung ...................................................................................... 100 Bedeutung der Architektur für die Entwicklung und Bereitstellung von Applikationen........................................................................... 101 2.1 Gewachsene Applikationslandschaft eines Unternehmens...... 102 2.2 Notwendigkeit der integrierten Gesamtsicht auf die Applikationslandschaft ............................................................ 102 2.3 Eingrenzung des Architekturbegriffs....................................... 103 Positionierung der Entwicklung und Bereitstellung von Applikationen in ITIL...................................................................... 105 3.1 IT-Services als IT-Produkte in Kombination mit kundenorientierten Mehrwertservices...................................... 107 3.2 Berücksichtigung der Architektur im „Application Management“ ..................................................... 108 Architekturmanagement.................................................................. 109

100

5

1

M. Hafner, J. Schelp, R. Winter

4.1 Kontinuierliche Entwicklung und Pflege der Architektur ....... 111 4.2 Situationsabhängige Durchsetzung der Architektur ................ 112 4.3 Institutionalisierung des Architekturmanagements.................. 114 Architekturmanagement als wichtige Ergänzung des IT-Service-Managements ................................................................ 118

Einführung

Die Applikationslandschaften der Unternehmen unterliegen einem steten Wandel. Neue funktionale Anforderungen auf der fachlichen Seite sowie neue Technologien andererseits führen zur Steigerung der Komplexität der betrieblichen Informationssysteme. Gleichzeitig wandelt sich die innerbetriebliche IT als Organisation von einem Rechenzentrum zu einem IT-Service Provider und wird als selbständige Organisationseinheit geführt, die in einigen Fällen ihre IT-Services auch an unternehmensexterne Kunden vertreiben muss. Bei einem partiell oder gänzlich an Externe gerichteten IT-Serviceangebot kann die Heterogenität der Applikationslandschaft weiter steigen, da voneinander divergierende Geschäftsprozesse verschiedener Kunden applikatorisch unterstützt werden müssen. Bei einer Führung als selbständige Organisationseinheit und noch stärker als am Markt agierender IT-Service-Provider steigt die Notwendigkeit, diese komplexe Applikationslandschaft in einer nachhaltigen Form zu bewirtschaften: sowohl bezogen auf die Kosten der Entwicklung und des Betriebs wie bezogen auf die Komplexität und Handhabbarkeit der gesamten Applikationslandschaft. Die Entwicklung der einzelnen Applikationen kann daher nicht ohne weiteres wie bisher betrieben werden: Es besteht in vielen Ansätzen zum ITManagement die Forderung, dass die Entwicklung der Applikationen nicht einfach phasenartig ohne Rückkopplungen erfolgen soll. Ansätze wie z.B. das St. Galler Informationssystem-Management (ISM) sehen die Betrachtungsebenen IS-Konzept, IS-Architektur, IS-Projektportfolio, IS-Projekt und IS-Betreuung vor und berücksichtigen explizit einen geschlossenen Führungskreislauf (Planung, Verabschiedung, Umsetzung, Kontrolle, erneute Planung, …) nicht nur innerhalb der einzelnen Ebenen, sondern auch zwischen diesen schon seit geraumer Zeit ((Österle/Brenner/Hilbers 1992, S.44), ähnlich z.B. bei (Heinrich 2002)). In der Praxis bleiben diese Rückkopplungen nicht selten aus. Dies führt in der Konsequenz zu einer gerin-

Berücksichtigung des Architekturmanagements

101

gen Flexibilität hinsichtlich fachlicher Anforderungen, einer geringen Servicegarantie im Zeitablauf sowie nur selten zu einem fundierten Nachweis des Wertschöpfungsbeitrags einzelner Entwicklungsprojekte. Insbesondere wenn Infrastrukturprojekte betroffen sind, macht sich der letztgenannte Punkt deutlich bemerkbar. In der Praxis kommen in letzter Zeit verstärkt Konzepte zum Einsatz, welche die Service-Orientierung des IT-Managements betonen. Mit der IT Infrastructure Library (ITIL) steht ein De-facto-Standard zur Verfügung (Hochstein/Hunziker 2003), der eine dediziert serviceorientierte Perspektive verfolgt. Bei näherer Betrachtung von ITIL zeigt sich, dass die Berücksichtigung fachlicher Anforderungen durch ein geeignetes IT-ServiceAngebot im Vordergrund steht. Die Bewirtschaftung der Applikationslandschaft in einem langfristigen Sinne steht allenfalls im Hintergrund. Fraglich ist, welche Ansatzpunkte ITIL bietet, um auch den langfristigen Betrieb zu unterstützen. Dieser Beitrag skizziert kurz die Rolle, die eine Enterprise Architecture für das längerfristige Management einer betrieblichen Applikationslandschaft innehaben kann. Im Anschluss daran wird die Berücksichtigung von architekturbezogenen Fragestellungen innerhalb von ITIL betrachtet. Vor diesem Hintergrund werden einige Eckpunkte des Architekturmanagements skizziert, das sich in ein Service-Management wie von ITIL vorgeschlagen integrieren lässt.

2

Bedeutung der Architektur für die Entwicklung und Bereitstellung von Applikationen

Architekturen bieten einen Ansatzpunkt, die Vielfalt betrieblicher Applikationen in der Art eines Bauplans übersichtlich darzustellen und so ein ganzheitliches Management aller Applikationen zu ermöglichen. Der folgende Abschnitt stellt kurz die Ausgangssituation dar, die sich in Organisationen bei langjährig gewachsenen Applikationslandschaften gebildet hat. Daraus wird die Notwendigkeit abgeleitet, eine integrierte Gesamtsicht aufzubauen, in der schliesslich verschiedene Anforderungen berücksichtigt werden müssen.

102

2.1


Gewachsene Applikationslandschaft eines Unternehmens

In der meist über viele Jahre evolutionär gewachsenen IS-Landschaft der einzelnen Unternehmen finden sich Applikationsgruppen, die entlang der funktionalen Grenzen entsprechend der Unternehmensorganisation entstanden sind. Ihre Vielfalt hat sich durch die zunehmende Abdeckung betrieblicher Funktionen immer wieder erhöht. Neue Geschäftsmodelle, die sich z.B. durch Electronic Commerce ergeben, verstärken diese Entwicklung und führen zugleich zu einem höheren Integrationsbedarf zwischen den verschiedenen Anwendungen. Die Entwicklung dieser Applikationslandschaft verläuft nicht stetig und konsistent, die Landschaft ist vielmehr von Brüchen durchzogen. Technische Innovationen führen neue Technologien ein, ohne dass ältere Technologien in gleichem Masse abgebaut würden. In (Hagen 2003) findet sich das Beispiel der Credit Suisse, deren mittlerweile ca. 600 Applikationen ein komplexes miteinander verwobenes Geflecht ergeben, das auf unterschiedlichen technischen Plattformen betrieben wird. Weitere Brüche in der Applikationslandschaft ergeben sich zudem durch grössere Änderungen in der Organisationsstruktur, wie sie in der Geschichte eines Unternehmens immer wieder vorkommen und in Fusionen ihre stärksten Ausprägungen erfahren. Im letzteren Fall führt dies nicht selten dazu, dass funktional ähnliche Systeme aus den Vorgängerunternehmen bisweilen auch nach der Fusion noch parallel betrieben werden (Kromer/Stucky 2002), dann aber durch Integrationsinfrastrukturen miteinander gekoppelt werden müssen.

2.2

Notwendigkeit der integrierten Gesamtsicht auf die Applikationslandschaft

Die Notwendigkeit einer integrierten Gesamtsicht wird im Folgenden beispielhaft anhand der Applikationsentwicklung aufgezeigt. Die Heterogenität der betrieblichen Applikationslandschaft hat Konsequenzen hinsichtlich ihrer Handhabbarkeit. Aufgrund der Kopplung der Applikationen miteinander können Änderungen an einzelnen Applikationen nicht durchgeführt werden ohne die Konsequenzen für den reibungslosen Betrieb der übrigen Applikationen zuvor geprüft zu haben. Die Wartbarkeit des Gesamtsystems hängt entscheidend von der Transparenz der Applikationskopplung ab. Bei der Neuentwicklung weiterer Applikationen ebenso wie bei Einbindung zugekaufter Applikationen wird nur selten der Fall vorliegen, dass


103

das neue System isoliert betrieben wird. Daher ist auch hierfür ein möglichst vollständiger Überblick über die angebotenen Schnittstellen zu anderen System erforderlich. Wie bei der Wartung genügt es allerdings nicht, lediglich die Beschreibungen eines Systems vollständig und konsistent zur Verfügung zu haben. Da die Dokumentation einzelner Systeme oftmals nur an den Erfordernissen der Entwicklung des Einzelsystems ausgerichtet ist, wird sie die notwendigen Kopplungsinformationen nur teilweise beinhalten können. Insbesondere wenn ältere und schlechter dokumentierte Systeme vorhanden sind, wird das Gesamtbild lückenhaft sein. Bei einer Vielzahl von Systemen ist eine Berücksichtigung von Einzelsystemdokumentationen zudem kaum handhabbar, es ist eine integrierte Dokumentation erforderlich. Diese kann aber nicht alle Details berücksichtigen, sondern muss sich z.B. auf die Integrationsaspekte zwischen den Systemen fokussieren. Die bei der Systementwicklung üblicherweise angestrebten Ziele wie u.a. Flexibilität, Wiederverwendung bestehender Komponenten, Vermeidung von Redundanz, Beherrschung der Komplexität in Entwicklung wie Betrieb, Anpassungsfähigkeit und Verlässlichkeit der erstellten Systeme, können nur abgedeckt werden, wenn ein Gesamtbild der Applikationen und ihrer Verknüpfungen miteinander vorhanden ist. So kann aus Sicht des IT-Service-Managements in Anlehnung an (HuberGraul 2003) ein hoher Zufriedenheitsgrad bei den Kunden der IT nur dann entstehen, wenn die IT ihre Services hinsichtlich Prozessen, Mitarbeitern, Organisation und Technologie weiterentwickelt. Dabei sollte sie sich nicht an einer hochwertigen, aber reaktiven Service-Erbringung orientieren, sondern diese vielmehr langfristig, konsistent und auf der Grundlage strategischer Entscheidungen organisieren. Dazu bedarf es der langfristigen Planung von Mitarbeitern (Skills, Arbeitsgebiete usw.), Prozessen (Support-, Planungsprozesse), Organisation (Rechenzentrum, Helpdesk) und nicht zuletzt Technologien (Applikationen, Datenbanken, Betriebssysteme usw.). Das komplexe Gefüge letzterer, welches den hohen Time-to-Market-Erwartungen des Business entgegensteht, wird in Anlehnung an (Dern 2003, S.13) insbesondere durch das Architekturmanagement bzw. durch das von ihm bereitgestellte Gesamtbild der Applikationen und ihrer Schnittstellen bereitgestellt.

2.3

Eingrenzung des Architekturbegriffs

Das Architektur-Gesamtbild ist sowohl auf einer fachlichen Ebene (Übersicht über die applikatorisch abgebildeten betrieblichen Funktionen) not-

104


wendig wie auf einer DV-technischen Ebene (Kopplungsarten, technologisch bedingte Abhängigkeiten). Im Rahmen der Entwicklung wie der fortlaufenden Wartung und Pflege der Applikationen sind unterschiedliche Anspruchsgruppen zu berücksichtigen, die jeweils unterschiedliche Sichten und daraus resultierende Anforderungen an diese Gesamtsicht haben. Unter dem Begriff „Architektur“ findet sich ein weites Spektrum geeigneter Gesamtsichten, das von lediglich aggregierten Modellen des Gesamtzusammenhangs komplexer Systeme bis zur Berücksichtigung zugehöriger Gestaltungsprinzipien reicht. Als wichtigste Gesamtzusammenhänge in Unternehmungen und anderen Organisationen werden von den meisten Autoren • die Geschäftsarchitektur (Gesamtzusammenhang der Leistungsverflechtung in einem Wertschöpfungsnetzwerk), • die Prozessarchitektur (Gesamtzusammenhang der Leistungsentwicklung, Leistungserstellung und des Leistungsvertriebs in einer Organisation), • die Applikationsarchitektur (Gesamtzusammenhang der informatorischen Verflechtung von Applikationen in einer Organisation) sowie • die IT-Architektur (Gesamtzusammenhang der funktionalen Verflechtung zwischen Software- und Datenbankkomponenten) betrachtet (vgl. z.B. (Winter 2003), (Lichtenegger/Rohloff/Rosauer 2003)). Falls notwendig, kann auf jeder Ebene zwischen spezifischen Anwendungskomponenten und anwendungsneutralen, infrastrukturnahen Diensten unterschieden werden. Außerdem können Architektursichten eingeführt werden, wenn die Komplexität der abzubildenden Sachverhalte dies erfordert. Während z.B. das ISA-Modell die fachlichen Architekturebenen noch ganzheitlich abbildet und erst auf Informationssystem-Ebene verschiedene Sichten unterscheidet, differenziert das sog. Zachman-Framework (Zachman 1987) auf allen Architekturebenen sechs Sichten. Allen Ansätzen ist gemeinsam, dass die Informationssystem-Gestaltung fachlichen Anforderungen folgt und damit die Ergebnisse jeder Architekturgestaltung die Freiheitsgrade der nachfolgenden Gestaltungsebenen einschränken. In der Praxis hat sich die Perspektive, mit der die Applikationslandschaft aus Sicht des IT-Managements betrachtet wird, im Zeitablauf verändert. In (Dietzsch 2003) findet sich das Beispiel der Mobiliar Versicherungen, bei denen sich das Architekturverständnis im Zeitablauf von einem eher hardwareorientierten zu Beginn der betrieblichen Datenverarbeitung zu einem umfassenden Verständnis gewandelt hat, das heute auf die gesamte Unter-


105

nehmensarchitektur abzielt. Für die langfristige Bewirtschaftung der betrieblichen Applikationslandschaft ist gerade ein solch umfassendes Verständnis eine Voraussetzung. Für die weitere Betrachtung wird – sofern nicht anders darauf hingewiesen wird – ein Architekturbegriff verwendet, der sich auf die Applikationsarchitektur fokussiert. Diese wird aufgefasst als Schnittstelle zwischen einer rein fachlichen Architektur (z.B. Geschäfts- oder Prozessarchitektur) und der technisch orientierten IT-Architektur. Die Applikationsarchitektur ist in diesem Sinne ein fachliches Abbild der Applikationslandschaft des Unternehmens. Sie beinhaltet auch die Regeln und Prinzipien, die bei Ihrer Anwendung wie Ihrer Weiterentwicklung berücksichtigt werden müssen. In der aktuellen Diskussion wird die Applikationsarchitektur nach hier verwendeten Verständnis teilweise auch als „Enterprise Architecture“ bezeichnet, wobei technische und fachliche Aspekte ebenso wie zugehörige Regeln und Prinzipien in unterschiedlichem Maße berücksichtigt werden (vgl. z.B. (Dern 2003; Dietzsch 2003). Inwieweit eine Enterprise Architecture in modernen IT-Management-Konzepten Berücksichtigung findet, wird im nachfolgenden Abschnitt am Beispiel der IT Infrastructure Library (ITIL) näher betrachtet.

3

Positionierung der Entwicklung und Bereitstellung von Applikationen in ITIL

Bei der IT Infrastructure Library handelt es sich um ein generisches Referenzmodell, mit dem IT-Leistungen geplant, überwacht und gesteuert werden können. Ursprünglich von der britischen Central Computer and Telecommunications Agency (CCTA, heute Bestandteil des Office of Government Commerce, OGC) initiiert, wird es heute von einer Reihe von Anwendern (u.a. Barclays Bank, Bayer, Deutsche Post), Beratern (Siemens Business Services, exagon etc.) und Herstellern (z.B. HP, IBM, Microsoft) unter Federführung des OGC und des IT Service Management Forums weiterentwickelt. Unter den Titeln „Planning to Implement Service Management“, „Service Support”, „Service Delivery”, „Applications Management”, „Information and Communications Technology (ICT) Infrastructure Management“, „Security Management“ und „Software Asset Management“ wurden die einzelnen Bestandteile dieses Frameworks seit 1998 als „Code of Practice for IT Service Management” vom British Standard Institute veröffentlicht und 2000 zum „British Standard“ (BS15000) er-

106


klärt. Die wichtigsten Komponenten sind „Service Delivery“ und „Application Management“ auf der taktischen Ebene sowie „Service Support“ und „ ICT Infrastructure Management“ auf der operativen Ebene wie in Abbildung 1 dargestellt. Lieferanten

Leistungserbringer (IT Services)

Leistungsabnehmer

Strategisch Business Perspective

Software Software

Hardware Hardware

Business Business Perspective Perspective Prozesse Prozesse

Taktisch Appl. Mgmt.

Service Delivery CapacityCapacityMgmt. Mgmt.

Personal Personal

ApplicationApplicationMgmt.Mgmt.Prozesse Prozesse

Operativ Infrastr. Mgmt.

Business Business needs needs

Kunden Kunden

Incidents Incidents

Anwender Anwender

Service Support

Network Network Mgmt. Mgmt. Operations Operations Mgmt. Mgmt.

Transfer Transfer

ContinuityContinuityMgmt. Mgmt.

ServiceServiceLevelLevelMgmt. Mgmt.

FinancialFinancialMgmt. Mgmt.

Gebäude Gebäude

Externe Externe Dienstleister Dienstleister

AvailabilityAvailabilityMgmt. Mgmt.

ReleaseChangeRelease- ChangeMgmt. Mgmt. Mgmt. Mgmt.

ProblemProblemMgmt. Mgmt.

Systems Systems Mgmt. Mgmt. Installation Installation Mgmt. Mgmt.

IncidentIncidentMgmt. Mgmt. Service Desk

Configuration-Mgmt. Configuration-Mgmt. © 2003, CC IIM, Institut für Wirtschaftsinformatik IWI-HSG

Abb. 1: ITIL Framework (nach [Hochstein & Hunziker 2003])

Der Schwerpunkt der Veröffentlichungen und zugleich grösste Beitrag zum IT-Management findet sich zu den Bereichen „Service Support“ und „Service Delivery“. Die Orientierung an den fachlichen Anforderungen der Geschäftsseite des Unternehmens steht bei der Definition der IT-Services im Vordergrund. Der nachfolgende Abschnitt skizziert kurz die Spannweite des verwendeten IT-Services-Begriffs. Anschliessend wird der für die Applikationsentwicklung bedeutende Bereich „Application Management“ näher betrachtet und dabei untersucht, inwieweit Architekturen darin Berücksichtigung finden.


3.1

107

IT-Services als IT-Produkte in Kombination mit kundenorientierten Mehrwertservices

Die Produkte der IT lassen sich heute nicht mehr nur in CPU-Sekunden darstellen. Die Vielfalt der heutigen IT-Leistungen lassen sich nach (Zarnekow/Brenner 2003 10f.) in vier Gruppen unterteilen. Die Gleichsetzung des IT-Produktes mit IT-Ressourcen entspricht der Sichtweise eines klassischen Rechenzentrums, das technische Ressourcen zur Verfügung stellt, z.B. in Form von Rechenleistung (IT-Produkt = IT-Ressourcen). Informationssystemorientierte Produkte beinhalten die Bereitstellung einer Anwendung, wobei diese für unternehmensinterne Kunden spezifisch entwickelt (bzw. eingekauft und konfiguriert) werden und alle Phasen von Entwicklung bis Betrieb und Support in einem Produkt beinhalten (ITProdukt = IT-Informationssystem). Prozessorientierte IT-Produkte orientieren sich an der expliziten Unterstützung der Geschäftsprozesse eines Unternehmens. Die technische Komplexität wird noch stärker als bei informationssystemorientierten IT-Produkten vor den Abnehmern verborgen (IT-Produkt = IT-Prozessunterstützung). Schliesslich sind geschäftsproduktorientierte IT-Produkte Bestandteile des Produkt- und Leistungsbündels des Unternehmens, das am Markt angeboten wird (IT-Produkt = Geschäftsprodukt). Die von der IT erbrachten Leistungen umfassen damit nicht nur die reine Applikationsleistung (z.B. in Form von Transaktionen), sondern auch Dienstleistungen im Sinne einer Benutzerbetreuung, eines Vorfallsmanagements oder beispielsweise eines Änderungsmanagements und stellen damit kundenorientierte Mehrwertservices dar. Die in ITIL angesprochenen IT-Services lassen sich diesen Kategorien nicht ohne weiteres zuordnen. Leicht fällt es bei der Ressourcen- und der Informationssystem-Perspektive. Diese werden von ITIL in jedem Fall adressiert, da sich die unter „Service Support“, „Application Management“, „ICT Infrastructure Management“ und „Service Delivery“ diskutierten Konzepte unmittelbar mit dem Betrieb von Applikationen sowie deren Entwicklung auseinandersetzen und dabei sowohl Ressourcen (Kapazitätsplanung, Verfügbarkeitsplanung etc. im Rahmen des „Service Delivery“ wie Betrieb von Netzwerk, Hardware, Software etc. im Rahmen des „ICT Infrastructure Management“) als auch das Informationssystem im obigen Sinne (kundenorientierte IS-Entwicklung im Rahmen des „Application Management“) adressieren. Auch die dritte Stufe wird abgedeckt, da sich insbesondere im „Application Management“ die Berücksichtigung der fachlichen Anforderungen bis hin zur Nennung der Prozessunterstützung wiederfinden lässt und da die im Bereich „Service Support“ genannten Bausteine (v.a. Vorfalls-Management) den Kunden auf der Fachseite Unterstützung bei der reibungslosen Bearbeitung ihrer Prozesse geben. Ob

108


IT-Leistungen im Rahmen von ITIL als Geschäftsprodukt aufgefasst werden können, wird nicht explizit angegeben. Im Falle eines am Markt agierenden IT-Service-Providers (z.B. als ASP-Anbieter) ist dies aber implizit der Fall.

3.2

Berücksichtigung der Architektur im „Application Management“

Auf die Entwicklung von IT-Leistungen gehen drei Bände aus der ITILBibliothek dediziert ein. In (Baron et al. 2002) werden unter „Application Management“ die Steuerungsaktivitäten zusammengefasst, die alle Phasen des Lebenszyklus einer Applikation von der Erhebung der Geschäftsanforderungen bis zur Ausserbetriebsetzung betreffen. Die Schnittstellen zu „Service Support“, „Service Delivery“ und „ICT Infrastructure Management“ werden ebenfalls in diesem Band berücksichtigt. Fragen der Infrastruktur und auch der Architektur werden im Band „ICT Infrastructure Management“ (Graham et al. 2002) diskutiert. In einem dritten und neueren Band wird zusätzlich die Einbindung extern entwickelter Software im Rahmen des „Software Asset Management“ (Rudd et al. 2003) behandelt, jedoch eher unter dem Gesichtspunkt des Managements der Lizenzen als der Einbindung in die applikatorische Gesamtarchitektur, so dass auf diesen Band im Folgenden nicht weiter eingegangen wird. Folgende Punkte sind hinsichtlich der Berücksichtigung der Architektur bzw. des Architekturmanagements kritisch zu sehen: • Die kaum über bekanntes Lehrbuchwissen hinausgehenden Angaben zu den vorgeschlagenen Anwendungsentwicklungsphasen im „Application Management“ berücksichtigen Architekturfragen nur in der Phase „Requirements“ und sind auch dort sehr knapp gehalten. • An verschiedenen Stellen wird deutlich, dass Architekturen eher im Sinne technischer Frameworks aufgefasst werden, innerhalb derer Anwendungen entwickelt werden können, weniger im Sinne einer Wiedergabe der Applikationslandschaft der Unternehmung. • Generell werden Architekturen nicht-funktionalen Anforderungen zugeordnet, deren durchgängige und konsistente Berücksichtigung gefordert wird. Die Umsetzung bzw. Berücksichtigung der Architektur soll dabei über Richtlinien bzw. Gestaltungsempfehlungen (Guidelines) erfolgen.


109

• Im Band „ICT Infrastructure Managements“ werden die verschiedenen Entwicklungsphasen unter Deployment zusammengefasst (Graham et al. 2002). Architekturen bzw. deren Berücksichtigung werden ebenfalls angesprochen, doch wird hinsichtlich der Umsetzung kaum ein Hinweis gegeben, in welcher Form dies konkret erfolgen könnte. • Im „Application Management“ wiederum wird bei den Empfehlungen zur Umsetzung, explizit bei den organisatorischen Aspekten der einzelnen Phasen, jeweils auf die Einbindung der ICT Infrastructure Management-Rolle hingewiesen. Dieser Rolle wird dabei die Verantwortlichkeit insbesondere auch für das Berücksichtigen der nichtfunktionalen Anforderungen zugewiesen. Im entsprechenden Band finden sich dazu jedoch nur generische Hinweise. • Stehen einzelne funktionale Anforderungen bei ihrer Umsetzung mit übergreifenden Richtlinien bzw. Gestaltungsempfehlungen (Guidelines) in Konflikt, so wird die Änderung der Richtlinien empfohlen, auf dass diese Änderungen bei nachfolgenden Entwicklungsprojekten berücksichtigt werden können. Durch Einbindung der ICT Infra-structure Management-Rolle soll dies konsistent erfolgen. Die relevanten Kriterien im betreffenden Band orientieren sich an Aspekten wie Verfügbarkeiten, Kapazitäten, Kostenabschätzungen hinsichtlich der notwendigen Infrastrukturleistungen etc. und haben damit eher kurz-fristige operative Ziele im Blick als Fragen der nachhaltigen Entwick-lung der gesamten Applikationslandschaft. Deutlich wird so, welcher Stellenwert einer Enterprise Architecture bei Anwendung von ITIL tatsächlich zukommt. Die Angaben zur Entwicklung der Applikationen und damit der Services konzentrieren sich in den ITIL-Bänden eher auf die stringente Berücksichtigung der fachlichen Anforderungen seitens der Auftraggeber und gehen weniger auf Fragestellungen ein, welche die Applikationslandschaft, ihre innere Verfasstheit, Verbindlichkeit und Nachhaltigkeit insgesamt betreffen.

4

Architekturmanagement

Ziel des Architekturmanagements im allgemeinen Sinne ist es, die klassischen Aufgaben des Informationsmanagements zu unterstützen, d.h. die Schaffung und Aufrechterhaltung einer geeigneten Informationsinfrastruktur zur wirtschaftlichen Erreichung strategischer Unternehmensziele

110


(Heinrich 2002, S. 21). Demzufolge wäre es naheliegend die Kostenoptimierung und Effizienzsteigerung als nahezu ausschließliche Ziele des Architekturmanagements zu verfolgen, wie es auch im Rahmen einer selbst durchgeführten Umfrage befürwortet wurde.1 Dabei wird jedoch der Aspekt der Aufrechterhaltung außer Acht gelassen, dem im Umfeld kontinuierlich neuer technischer und fachlicher Anforderungen dezidiert Aufmerksamkeit zukommen sollte. Somit verfolgt das Architekturmanagement keine eigenen, über das allgemeine Informationsmanagement hinausgehenden Zielsetzungen, wodurch in Anlehnung an (Bleicher 1979, S. 61) weitere organisatorische Komplexität entstehen würde, sondern gewährleistet die langfristige Lenkbarkeit des gesamten Informationssystems. Auf diese Weise leistet das Architekturmanagement indirekt einen Beitrag, um Kosten-, Qualitäts-, Flexibilitäts- und zeitliche Anforderungen des allgemeinen Informationsmanagements sowie seiner benachbarten Bereiche wie dem IT-Controlling, dem Sicherheits- und Risikomanagement der IT aber auch dem IT-Service-Management zu erreichen. Zur praktischen Operationalisierung dieser Charakterisierung des Architekturmanagements ist es notwendig, dass künftige Forschungs- und Entwicklungsergebnisse nicht nur Architekturvisionen erzeugen, sondern auch skalierbar sind, evolutionäres Vorgehen unterstützen, auf die Beseitigung von Inkonsistenzen fokussieren, Metriken umfassen und an bestehende Informationsmanagement-Ansätze anschlussfähig sind. Im Folgenden wird insbesondere auf die Aufgabenfelder eines institutionalisierten Architekturmanagements im Sinne des Managements der Applikationsarchitektur eingegangen. Hinsichtlich der effektiven und effizienten Bereitstellung von IT-Produkten lassen sich grob zwei Bereiche unterschieden: • Pflege und Weiterentwicklung der Architektur im Unternehmen auf der Grundlage fachlicher und technischer Anforderungen. • Situationsabhängige Durchsetzung der Architektur gegenüber den verschiedenen Interessengruppen im Unternehmen. Abschließend wird die Institutionalisierung eines zentralen Architekturmanagements im Unternehmen diskutiert.

1

Die Umfrage wurde im Rahmen des 12. St. Galler Anwenderforums am 15.09.2004 unter 177 Teilnehmern (Rücklaufquote 58,2%) durchgeführt.


4.1

111

Kontinuierliche Entwicklung und Pflege der Architektur

Das Architekturmanagement greift zeitnah die aktuelle Ist-Situation der in der Vergangenheit meist heterogen gewachsenen Applikationslandschaft auf und arbeitet an ihrer kontinuierlichen Weiterentwicklung und Pflege. Dabei berücksichtigt es die Abhängigkeiten von Applikationen sowohl untereinander, aber auch von der ihnen zugrunde liegenden technischen Architektur sowie hinsichtlich ihrer weiteren Entwicklung. Um diesem Anspruch gerecht zu werden, ist die Abbildung der Applikationslandschaft in der Enterprise Architecture notwendig, wie sie in Abschnitt 2.3 angesprochen wird. Daran anschließend können Applikationen jeweils in verschiedenen Sichten respektive auf verschiedenen Abstraktionsebenen dargestellt werden, sodass ihre vielfältigen Abhängigkeiten transparent gemacht werden können. Die differenzierte Darstellung ist notwendig, da das Architekturmanagement mit den unterschiedlichsten Anspruchsgruppen kommuniziert, welche jeweils eigene architekturrelevante Interessen haben. In Anlehnung an (Dern 2003, S.109f.) lassen sich grob sechs Interessengruppen unterscheiden: • Business. Von hier aus werden fachliche Anforderungen an die Applikationslandschaft gestellt, welche durch das Architekturmanagement analysiert und bewertet werden. • Technik. Von Seiten der technischen Architektur werden operationelle Restriktionen wie z.B. Sicherheitsaspekte oder Plattformvorgaben formuliert. • Softwareentwicklung. Aus einzelnen Entwicklungsprojekten werden Informationen über Softwarebausteine und deren interne Architektur geliefert, welche eventuell nur geringe Kompatibilität zu anderen architekturrelevanten Interessen aufweisen. • Management. Die Beurteilung von IT-Aktivitäten respektive ITServices hinsichtlich ihrer Effizienz und Effektivität sowie Details zu unternehmerischen Prozessen und komplexen Systemverantwortlichkeiten können auf die Handlungsoptionen des Architektur-managements Einfluss nehmen. • IT-Explorer bzw. Technologiemanager. Technologische Einflüsse, welche für das Unternehmen als relevant eingestuft werden, nehmen Einfluss auf die Architektur. • Architekturmanagement. Von einem zentralen Architekturmanagement gehen im Zuge der ständigen Revision der Architektur ebenso Impulse

112


für deren Weiterentwicklung aus wie von der engen Zusammenarbeit zwischen dezentralen Architekten mit deren zugeordneten Fachabteilungen des Unternehmens. Neben der Darstellung der Ist-Architektur ist die Erarbeitung unterschiedlicher Architekturszenarien notwendig, um mit Hilfe ganz-heitlicher Konzepte auf die Anforderungen der unterschiedlichen Interessengruppen seitens des Architekturmanagements eingehen zu können. Bei der Bereitstellung von Architekturszenarien werden für die erforderlichen Sichten und Detaillierungsebenen verschiedene Varianten erstellt und unterschiedlichen Zeithorizonten zugeordnet (Versionierung). Wesentlich für die Auswahl aus Sicht des Architekturmanagements gangbarer Varianten ist deren Bewertung und somit die Bewertung der Gesamtapplikationslandschaft im Kontext der unterschiedlichen Anforderungen. Die Weiterentwicklung der Architektur auf der Basis der Anforderungen sämtlicher Interessengruppen führt fortlaufend zu Inkonsistenzen, welche einem Ausgleich entgegengeführt bzw. für welche Ausnahmeregelungen definiert werden müssen, sodass eine integrierte Sicht auf die Gesamtheit der architekturrelevanten Interessen erhalten bleibt. Dabei ist zu beachten, dass Anforderungen an die Architektur nicht zeitgleich auftreten. Vielmehr werden diese in einem relativ kleinen Zeitfenster ganzheitlich erhoben und gegenübergestellt. Dem Gedanken des kontinuierlichen Managements entspricht jedoch eher der Ansatz, die Anforderungen zum Zeitpunkt ihres jeweiligen Auftretens im Hinblick auf künftige Entwicklungen, vorhandene Business Cases und auf der Grundlage der IstSituation integriert zu bewerten. Dieser Ansatz hat gegenüber der periodischen, ganzheitlichen Erfassung den Vorteil, dass nicht auf der Grundlage eines zeitlich fixierten Ist-Zustands mittel- bis langfristige Architekturentscheidungen getroffen werden, sondern vielmehr dem Problem des „Moving Target“ (Starke 2003, S.23) Rechnung getragen werden kann. Das heißt, dass eine flexible Ausrichtung der Architektur ermöglicht wird, welche rasch auf neue Herausforderungen reagieren kann und selbst in der Folge von architekturrelevanten „Störungen“ innerhalb kürzester Zeit wieder effizient und effektiv agieren kann.

4.2

Situationsabhängige Durchsetzung der Architektur

Der eher passiven Aufgabe des Architekturmanagements, die Architektur unter Berücksichtigung allfälliger Einflussfaktoren zu dokumentieren und kontinuierlich weiterzuentwickeln, steht die proaktive Aufgabe der Architekturkommunikation und -durchsetzung gegenüber.


113

Probleme des Architekturmanagements sind primär auf mangelnde Adäquanz in der Kommunikation zurückzuführen (Dern 2003, S.45). Betrachtet man die Komplexität der Randbedingungen, die für die erfolgreiche Arbeit eines zentralen Architekturmanagements von Bedeutung sind, ist dies verständlich. Beispielhaft sind folgende kritische Faktoren zu nennen: • Committment der aktiv Beteiligten. Die Erfahrung in Zusammenarbeit mit namhaften schweizerischen Unternehmen zeigt, dass die Annahme des Architekturmanagements als zentralem Koordinationsmechanismus für die kontinuierliche Weiterentwicklung der IT von der Größe des Unternehmens abhängt. Während das Architekturmanagement in kleineren Unternehmen primär um freiwillige Akzeptanz wirbt, gelten seine Aussagen in Großunternehmen insbesondere für Entwicklungsprojekte als eher nur über verbindliche Regeln durchsetzbar. • Management Committment. Dem entsprechend ist die generelle Einschätzung des Managements bezüglich der Notwendigkeit eines Architekturmanagements relevant, d.h. der systematischen und nachhaltigen Weiterentwicklung der Architektur. • Finanzierung des Architekturmanagements. Vom Management Committment ist vielfach auch die Mittelvergabe im Hinblick auf die schwerpunktmäßig infrastrukturelle Investition in das Architekturmanagement abhängig. Die Handlungsspielräume und Durchsetzungsmöglichkeiten des Architekturmanagements orientieren sich stark daran, ob es selbst über Mittel verfügt, auf den Mittelerwerb beispielsweise durch die Mitarbeit in Softwareentwicklungsprojekten angewiesen ist oder gar selbst über die Mittelvergabe im Rahmen des Projektportfoliomanagements verfügt. • Umsetzen von Quick Wins. Mit obigen Punkten in Zusammenhang steht die Fokussierung von Unternehmen auf die Realisierung von Quick Wins. Diese spielen insbesondere bei hohen Time-to-MarketAnforderungen und hoher Abhängigkeit von technologischen Innovationen eine Rolle, sodass die Effizienzgewinne durch nachhaltiges, transparentes und flexibles Architekturmanagement vielfach verkannt werden. Träger der Kommunikation von Architekturvorgaben sind im Kontext der effektiven und effizienten Bereitstellung von IT-Services neben den in Abschnitt 4.1 diskutierten Darstellungen von Applikationslandschaften die Prinzipien, welche dem Architekturmanagement zugrunde liegen, sowie Architekturstandards, welche mit differenzierter Verbindlichkeit die Weiterentwicklung der Applikationslandschaft in geordnete Bahnen lenken.

114


Ausnahmeregelungen und Konzepte zur Bereinigung von Inkonsistenzen dürfen dabei selbstverständlich ebenso wenig außen vor bleiben wie flexible Roadmaps, welche die entwickelten Architekturversionen und -varianten in eine definierte zeitliche Reihenfolge bringen. In Abhängigkeit der obigen Randbedingungen ist die situationsabhängige Durchsetzung der Architektur auf verschiedene Weisen möglich. Der vielfach bevorzugte Weg ist die serviceorientierte Beratung und Mitarbeit in ausgewählten architekturrelevanten Projekten – beispielsweise der Softwareentwicklung, der IT-Strategie aber auch der Definition von IT-Services – wo der jeweilige Projektarchitekt die Vorgaben des Architekturmanagements einbringt und deren Nutzen transparent macht. Hierfür stehen Verfahren zur Bestimmung des Architekturnutzens zur Verfügung. In Anlehnung an (Leser/Scheibehenne/Alt 2004) können darin einem klassischen Zielportfolio, welches sich z.B. aus Kosten, Zeit und Qualität zusammensetzt, IT-Service-Prozesse gegenübergestellt werden, welche beispielsweise die Planung, Entwicklung und Produktion von IT-Services sowie das Business-IT-Alignment umfassen und vom Architekturmanagement profitieren sollen. In einer so entstandenen Matrix aus Zielen und IT-Service-Prozessen können Führungsgrößen eingeordnet und in Zusammenhang gebracht werden, sodass ein Wirkungsnetzwerk entsteht, dessen Input-Größen (z.B. Anzahl der (Meta-)Modelle, Informationssysteme, Schnittstellen oder Daten sowie deren jeweilige Varianten und Instanzen, Lebensdauer von Kundenanforderungen, Einhaltung von Service Level Agreements usw.) im Idealfall quantifizierbar sind. Werden insbesondere den zeitlichen Aufwendungen monetäre Tagessätze zugeordnet, lassen sich finanzielle Anhaltspunkte für den Nutzen von Architekturen finden und gegenüber verantwortlichen Stellen kommunizieren. Die controllingorientierte Variante der Projektrevision bedient sich dahingegen eher der definierten Eskalationspfade. Flankierend eignet sich in jedem Fall die unternehmensweite Verbreitung der Architekturvorgaben über diverse Kanäle wie dem Intranet oder Schulungen, um Akzeptanz zu erzeugen.

4.3

Institutionalisierung des Architekturmanagements

Aufgrund des kontinuierlichen Wandels der Anforderungen, wie sie im Umfeld des Architekturmanagements auftreten, kann davon ausgegangen werden, dass eine völlige Konformität der realen Applikationslandschaft respektive ihrer Transformationsprojekte mit einer angestrebten Architektur der Ausnahmefall ist (Dietzsch 2003, S.57). Ein explizites Management


115

von Inkonsistenzen zwischen der jeweiligen Ist-Architektur und diversen Soll-Architekturvarianten geht über die klassische Systementwicklung, von der das Informationsmanagement weitgehend geprägt ist, hinaus und lässt eine Kapselung der Aufgaben des Architekturmanagements gegenüber dem Informationsmanagement und seinen benachbarten Aufgabenbereichen sinnvoll erscheinen. Aus diesem Grund muss von neuem die Anschlussfähigkeit des Architekturmanagements an das Informationsmanagement sichergestellt werden, was im Kontext des St. Galler Modells des Informationssystemmanagements veranschaulicht werden kann. Wie in Abschnitt 1 erwähnt wurde, dominiert dort ein Phasenkonzept, welches bei einer architekturzentrierten Sicht auf das Informationsmanagement gemäss Abb. 2 adaptiert werden kann. Es handelt sich dabei um die phasenübergreifende, effiziente und effektive Kommunikation eines kontinuierlichen Architekturmanagements, welches zunächst – durch die grauen Pfeile auf der rechten Seite angedeutet – Informationen aus allen Bereichen aufnimmt. Auf diese Weise wird der hohen Komplexität und Dynamik im Spannungsfeld zwischen strategischen, fachlichen und technischen Anforderungen an die Architektur adäquat Rechnung getragen. Neue Anforderungen und Randbedingungen werden frühzeitig am Ort ihres Entstehens identifiziert. Auf diese Weise können sie vom Architekturmanagement mit geringem Zeitverzug aufgegriffen und situationsabhängig in die bestehende Architektur integriert werden. Danach stehen sie in Form von Architekturvorgaben der weiteren Bereitstellung von IT-Produkten und IT-Services zur Verfügung.

116

M. Hafner, J. Schelp, R. Winter Planung

Verabschiedung

Kontrolle

Umsetzung

ISStrategie

Planung

Kontrolle

Verabschiedung

ISArchitekturUmsetzung Mgmt. Planung

Verabschiedung

Kontrolle

Umsetzung

ISProjektportfolio

Planung

Verabschiedung

Kontrolle

Umsetzung

ISProjekt

Planung

Verabschiedung

Kontrolle

Umsetzung

ISBetreuung

Abb. 2: Berücksichtigung der Architektur im gesamten Informationsmanagement (in Anlehnung an [Österle/Brenner/Hilbers 1991])

Nicht zuletzt bedarf auch ein institutionalisiertes Architekturmanagement einer kontinuierlichen Weiterentwicklung. In Anlehnung an (Schekkerman 2003a, S. 22), der für das Management unternehmensweiter sowie -übergreifender Architekturen das sogenannte „Enterprise Architecture Program Maturity Model“ vorschlägt, lassen sich für diverse Aspekte des Architekturmanagements Reifegrade definieren. Bezogen auf das Management der im Zusammenhang der Bereitstellung von IT-Services besonders relevanten Applikationsarchitektur kommen insbesondere die in genannten Aspekte mit ihrer jeweils optimalen Ausprägung in Frage. Aspekte, welche sich mit der Einbindung des Top-Managements, externer Unternehmenspartner bzw. der Fachabteilungen oder der Strategie zum Business-IT-Alignment auf der Ebene rein strategischer oder organisatorischer Fragestellungen beschäftigen, sind im Bereich der Geschäftsbzw. Prozessarchitektur (siehe Abschnitt 2.3) ansiedelt.

Berücksichtigung des Architekturmanagements Aspekt

Optimale Ausprägung

Definition von Architekturszenarien

• Optimierung und kontinuierliche Verbesserung der Definition von Architekturszenarien

117

• Modellierung vorgeschlagener Architekturveränderungen vor ihrer Implementierung Weiterentwicklung der Architektur

• Definition der Architektur durch Standards, Prinzipien und Qualitätsfaktoren. • Existenz von Referenzmodellen und Standardprofilen. • Wiedererkennung der Architektur in realisierten Systemen. • Ausnahmeregelungen für Inkonsistenzen mit Architekturvorgaben.

Kommunikation der Architektur

• Regelmäßige Aktualisierung und Review von Architekturdokumenten im Gesamtkontext weiterer Architekturen. • Ausbildung neuer Architekten. • Regelmäßige Architekturkommunikation und -ausbildung für das Top-Management. • Ausnahmeregelungen zur expliziten Identifikation von Lücken in der Architekturkommunikation.

Durchsetzung der Architektur

• Strategische Abstimmung von geschäftlichen und IT Investitionen. • Formale Vorgehensweisen für den Umgang mit Inkonsistenzen mit Architekturvorgaben. • Ausnahmeregelungen bei der konsequenten Architekturdurchsetzung zur Identifikation von Mängeln.

Ganzheitlichkeit des Modellierungsansatzes

• Pflege des Applikationsportfolios zur Einbettung und Ausrichtung weiterer Entwicklungen. • Periodische Überprüfung der Anwendung vorgegebener Modellierungstechniken, u. a. zur Sicherstellung der semantischen Korrektheit. • Messung der Modellanwendung.

Tab. 1:

2

Optimale Ausprägungen2 bei der Bewertung des Reifegrads des Management der Applikationsarchitektur (in Anlehnung an Schekkerman 2003b)

Zwischenstufen auf dem Weg zum optimalen Reifgrad des Architekturmanagements („Optimierendes Architekturmanagement“) sind „Kein Architekturmanagement“, „Intiales Architekturmanagement“, „Architekturmanagement in Entwicklung“, „Definiertes Architekturmanagement“ und „Funktionierendes Architekturrmanagement“.

118

5


Architekturmanagement als wichtige Ergänzung des IT-Service-Managements

Durchgeführte Interviews bei verschiedenen internationalen Großunternehmen haben ergeben, dass das Architekturmanagement im Hinblick auf Applikationen sowohl die integrierte Sicht auf die Entwicklung und Bereitstellung als auch deren effiziente und effektive Durchführung aufgreift. Die nachhaltige Entwicklung und Pflege der Architektur stellt sicher, dass technische und fachliche Fragestellungen mit Blick auf das Gesamtportfolio behandelt werden. Komplementär zur fachlich orientierten Bereitstellung von IT-Services fokussiert sich das Architekturmanagement auf die langfristige Lenkbarkeit der Applikationslandschaft durch die ausgewogene Erhaltung ihrer Transparenz, Flexibilität und Konsistenz. Darüber hinaus ist seitens des IT-Managements in den Unternehmen die Einsicht erkennbar, dass das Architekturmanagement nicht nur zur langfristigen Kostenoptimierung beiträgt, sondern auch Wartbarkeit, Entwicklungsgeschwindigkeit und Flexibilität erhöht und so zu einem besseren Business-IT-Alignment sowie Vorteilen bei der zeitnahen und qualitativ hochwertigen Erbringung von IT-Services führt. Ansätze wie ITIL leisten einen wichtigen Beitrag, um das IT-Management in der Praxis für eine umfassende Berücksichtigung fachlicher Anforderungen nicht nur während der Anforderungsanalyse, sondern auch bei der Entwicklung einer Applikation und ihrem Betrieb zu sensibilisieren. Der Service-Gedanke wird insbesondere für den Betrieb stark betont. Der Einbindung der beteiligten Interessengruppen kommt die notwendige Aufmerksamkeit zuteil und es werden auch praktikable Vorgaben für deren Umsetzung gemacht. Architekturen bzw. das nachhaltige Entwickeln und Weiterentwickeln der gesamten Applikationslandschaft steht folglich bei ITIL nicht im Vordergrund und wird primär aus einer nicht-funktionalen Sicht betrachtet. Bezogen auf die fachliche Architektur wird der (kurzfristigen) Umsetzung fachlicher Anforderungen der Vorrang vor einer langfristig geplanten Zielarchitektur der gesamten Applikationslandschaft eingeräumt. Eine „100%ige“ Umsetzung von ITIL, wie von manchen Praxisvertretern angestrebt, führt zu einer Serviceorientierung des IT-Managements, stellt aber nicht sicher, dass sich die Applikationslandschaft in kontrollierbaren Bahnen entwickeln wird. ITIL bietet aber auch geeignete Ansatzpunkte, um ein Architekturmanagement wie in Abschnitt 4 in Grundzügen dargelegt zu berücksichtigen. Ein solches Architekturmanagement stellt dann die notwendigen Verfahren


119

und (Kontroll-) Instrumente zur Verfügung, um die Entwicklung der Applikationslandschaft insgesamt langfristig planen, durchsetzen und kontrollieren zu können. Für eine Berücksichtigung in ITIL bedarf es einer detaillierteren, architekturorientierten Ausgestaltung von Rollen und Aufgaben im „Application Management“ und „ICT Infrastructure Management“, wie in Abschnitt 4 durch die Interessengruppen und Aufgabenfelder im Bereich des Architekturmanagements dargestellt. Durch die Beigabe geeigneter Kennzahlen können darüber hinaus insbesondere innerhalb der nicht-fachlichen Anforderungen architekturspezifische Kontrollziele überprüft und so der Nutzen des Architekturmanagements u.a. im Hinblick auf das IT-Service- Management nachgewiesen werden (vgl. Abschnitt 4.2). Der Entwurf eines geeigneten Architekturmanagements ist Gegenstand eines laufenden Forschungsvorhabens innerhalb des Kompetenzzentrums Integration Factory der Universität St. Gallen. In Zusammenarbeit mit Partnerunternehmen sowie durch branchenunabhängige Studien werden gegenwärtig Ziele, Aufgaben, Rollen und Instrumente des Architekturmanagements erarbeitet und in einem integrierten Konzept konsolidiert, wobei auf Anwendbarkeit und Kompatibilität mit modernen serviceorientierten IT-Managementkonzepten geachtet wird.

120


Literatur Baron, A., Clarke, B., Hertroys, P., von Oosterom, N., Hinley, D.: Application Management, Office of Goverment Commerce (OGC), London, 2002. Bleicher, K.: Unternehmungsentwicklung und organisatorische Gestaltung, Fischer, Stuttgart, New York, 1979. Dern, G.: Management von IT-Architekturen - Informationssysteme im Fokus von Architekturplanung und -entwicklung, Vieweg Verlag, Wiesbaden, 2003. Dietzsch, A.: Positionierung eines Unternehmensarchitektur-Ansatzes: Erfahrung der Schweizerischen Mobiliar im Architekturmanagement, in: Schelp, J., Winter, R. (Hrsg): Institut für Wirtschaftsinformatik IWI-HSG, St. Gallen, 2003, S 50-61. Graham, P., Hulzinga, S., Rudd, C., van Dijk, A., von Winden, R., Bekenkamp, P., Doeff, I., Hinley, D., Leigh, C., Stringfellow, I., Wielinga, R.: ICT Infrastructure Management, Office of Government Commerce (OGC), London, 2002. Hagen, C.: Integrationsarchitektur der Credit Suisse, in: (Hrsg): GITO-Verlag, Berlin, 2003, S 61-81. Heinrich, L.J.: Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur, 7, Oldenbourg Verlag, München, 2002. Hochstein, A., Hunziker, A.: Serviceorientierte Referenzmodelle des ITManagements, in: HMD - Praxis der Wirtschaftsinformatik, 40, 232, 2003, S 46-56. Huber-Graul, M.: Software-Wartung als Herausforderung, in: Neue Zürcher Zeitung, 2003. Kromer, G., Stucky, W.: Die Integration von Informationsverarbeitungsressourcen im Rahmen von Mergers & Acquisitions, in: Wirtschaftsinformatik, 44, 6, 2002, S 523-533. Leser, F., Scheibehenne, R., Alt R.: Ansatz zur Bestimmung des Architekturnutzens bei der Deutschen Telekom, in: (Hrsg): Springer, Berlin et al., 2004, S 233-253. Lichtenegger, R., Rohloff, M., Rosauer, B.: Beschreibung von Unternehmensarchitekturen: Sichten und Abhängigkeiten am Beispiel der IT-Infrastrukturarchitektur, in: Dittrich K, König W, Oberweis A, Rannenberg K, Wahlster W (Hrsg): Gesellschaft für Informatik e.V. (GI), Bonn, 2003, S 426-434. Österle, H., Brenner, W., Hilbers, K.: Unternehmensführung und Informationssystem, 1. Auflage, B.G. Teubner, Stuttgart, 1991.


121

Österle, H., Brenner, W., Hilbers, K.: Unternehmensführung und Informationssystem - Der Ansatz des St. Galler Informationssystem-Managements, B. G. Teubner, Stuttgart, 1992. Rudd, C., Bicket, D., Diamon, P., Bull, R., Fröhlich, S., Best, R.: Software Asset Management, Office of Goverment Commerce (OGC), London, 2003. Schekkerman, J.: Enterprise Architecture Validation. Achieving Business-Aligned and Validated Enterprise Architectures, http://www.enterprise-architecture.info /Images/Extended%20Enterprise/Enterprise%20Architecture%20Validation% 20Full%20version.pdf, 07.04.2004. Schekkerman, J.: Extended Enterprise Architecture Maturity Model (E2AMM), http://www.enterprise-architecture.info/Images/E2AF/Extended% 20Enterprise%20Architecture%20Maturity%20Model%20_E2AMM_092003.pdf, 07.04.2004. Starke, G.: Architektur und Flexibilität – Ein Widerspruch?, in: It Fokus, 3, 2003 S 22-26. Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: (Hrsg): Springer, Berlin etc., 2003, S 87-118. Zachman, J.A.: A Framework for Information Systems Architecture, in: IBM Systems Journal, 26(1987)3, S 276-292. Zarnekow, R., Brenner, W.: Auf dem Weg zu einem produkt- und dienstleistungsorientierten IT-Management, in: HMD – Praxis der Wirtschaftsinformatik, 40 (2003) 232, S 7-16.

Zugriffskontrolle in heterogenen Applikationslandschaften Josef Rupprecht DATA MART Consulting GmbH

Felix Wortmann Universität St. Gallen

Unterschiedlichste IT-Applikationen werden heutzutage im betriebswirtschaftlichen Umfeld von heterogenen Benutzergruppen verwendet. Die verschiedenen Anwender und Benutzergruppen besitzen jedoch sehr unterschiedliche Berechtigungen zur Nutzung der Ressourcen. Deshalb wird in diesem Artikel vertiefend auf die Sicherheitsfunktion Zugriffskontrolle eingegangen. Anhand von Anforderungen und Bewertungskriterien aus der Praxis werden unterschiedliche Modelle und Integrationsansätze zur Zugriffskontrolle aus Theorie und Praxis im Hinblick auf ihre Eignung im betriebswirtschaftlichen Umfeld untersucht.

1 2

3

4

5

Motivation....................................................................................... 124 Datensicherheit................................................................................ 125 2.1 Terminologischer Bezugsrahmen ............................................ 125 2.2 Sicherheitsanforderungen ........................................................ 126 2.3 Grundlegende Sicherheitsfunktionen....................................... 127 Zugriffskontrolle ............................................................................. 128 3.1 Grundlagen............................................................................... 128 3.2 Anforderungen der Praxis ........................................................ 131 Zugriffskontrolle in der Literatur .................................................... 133 4.1 Zugriffskontrollansätze ............................................................ 133 4.2 Ansätze zur Integration der Zugriffskontrolle ......................... 142 Zugriffskontrolle in der Praxis ........................................................ 148 5.1 Zugriffskontrollansätze ............................................................ 148

124

6

1

J. Rupprecht, F. Wortmann

5.2 Ansätze zur systemübergreifenden Integration der Zugriffskontrolle...................................................................... 154 5.3 Ansätze zur Integration der Zugriffskontrolle in mehrschichtigen Systemen....................................................... 160 Zusammenfassung und Forschungsbedarf ...................................... 166

Motivation

Die Applikationen einer Unternehmung stellen eine besonders schützenswerte Ressource dar. Zahlreiche Unternehmensapplikationen haben mittlerweile einen so hohen Stellenwert in der Abwicklung des täglichen Geschäfts, dass ihr Ausfall den operativen Betrieb einer Unternehmung lahmlegt. Darüber hinaus beinhalten insbesondere Applikationen im Umfeld des Data-Warehousing Daten, die einen entscheidenden Wettbewerbsfaktor darstellen. Unerlaubte Offenlegung, Ausfall, Manipulation oder Zerstörung von Applikationen könnten verheerende Auswirkungen auf das Unternehmen haben. Eine konsistente Zugriffskontrolle stellt deshalb einen unverzichtbaren Baustein für ein ganzheitliches Sicherheitskonzept dar. Ein die konsistente Zugriffskontrolle besonders erschwerender Faktor, ist die Tatsache, dass die Applikationen in den Unternehmen sehr heterogen bezüglich ihrer technischen Plattformen und Realisierungen sind. Dieser Beitrag hat sich zum Ziel gesetzt, das Themenfeld der Datensicherheit in heterogenen Systemlandschaften näher zu beleuchten und insbesondere wesentliche Problematiken der Zugriffskontrolle sowohl aus konzeptioneller Sicht als auch aus Implementierungssicht zu analysieren. Zahlreiche Beiträge in der Fachliteratur befassen sich mit Zugriffskontrollkonzepten für spezifische Teile einer Applikationslandschaft, wenige betrachten jedoch das vollständige, heterogene System und erarbeiten ein ganzheitliches Konzept. Nach der Einleitung werden in Kapitel 2 zunächst die Grundlagen zum weiteren Verständnis des vorliegenden Artikels gelegt. In Kapitel 3 werden die fundamentalen Fragestellungen der Zugriffskontrolle dargestellt. Anforderungen an die Zugriffskontrolle aus Sicht der Praxis vervollständigen das Kapitel. Kapitel 4 diskutiert Autorisierungsansätze aus der Literatur. Es werden die drei Kategorien der benutzerbestimmten, systembestimmten und rollenbasierten Zugriffskontrolle differenziert und verschiedene Möglichkeiten untersucht, Zugriffskontrollansätze zu implementieren und in existierende, heterogene Systemlandschaften einzubinden. Zusätzlich werden die unterschiedlichen Zugriffs-

Zugriffskontrolle in heterogenen Applikationslandschaften

125

modelle und Integrationsansätze anhand von Kriterien aus der Unternehmenspraxis bewertet. Kapitel 5 geht analog zu Kapitel 4 vor, beschreibt jedoch Autorisierungsansätze aus der Praxis, die im Rahmen des Kompetenzzentrums Application Integration Management der Universität St. Gallen mit schweizerischen und deutschen Grossunternehmen diskutiert worden sind. Der Beitrag schliesst mit einer Zusammenfassung der Ergebnisse und einem Ausblick auf weiteren Forschungsbedarf.

2

Datensicherheit

Datensicherheit beschäftigt sich mit der sicheren Speicherung, Verarbeitung und Übertragung von informationstragenden Daten. Dies beinhaltet sowohl die Gewährleistung des störungsfreien operativen Betriebs der ITSysteme und Applikationen als auch die Sicherstellung, dass Daten und Informationen nur von berechtigten Personen gelesen, verändert oder gelöscht werden können (vgl. Oppliger 1997, S. 2). Sowohl interne als auch externe Bedrohungen werden adressiert.

2.1

Terminologischer Bezugsrahmen

Zur Etablierung eines einheitlichen, konsistenten Begriffsverständnisses beschreibt Abbildung 1 den Zusammenhang zwischen Sicherheitsanforderungen, -funktionen und -mechanismen anhand einiger Beispiele. Die Sicherheitsanforderungen ergeben sich aus den Bedrohungen. Die Anforderungen werden hinsichtlich ihrer Sach- und Formalziele, jedoch ohne Fokussierung auf eine konkrete Implementierung definiert (vgl. O.V. 1989, S. 6). Die spezifizierten Sicherheitsanforderungen werden durch Sicherheitsfunktionen erfüllt. Sie stellen eine Abstraktionsebene zwischen den Anforderungen und den implementierungs-spezifischen technischen Mechanismen dar. Funktionen können zur Erfüllung mehrerer Anforderungen beitragen und durch unterschiedliche Mechanismen implementiert werden. Ein Mechanismus kann mehrere Funktionen realisieren (vgl. O.V. 1989, S. 14). Zum Beispiel setzt sich die Autorisierung oder Zugriffskontrolle aus den Funktionen Zugriffsrechteverwaltung und -prüfung zusammen. Sie kann durch einen sogenannten Referenzmonitor implementiert werden, welcher zugleich zur Beweissicherung beitragen kann (vgl. Jonscher/ Dittrich 1994, S. 26).

126

2.2


Sicherheitsanforderungen

Sicherheitsfunktionen

Vertraulichkeit

Zugriffsrechteverwaltung

Sicherheitsmechanismen

Sicherheitsanforderungen

Bedrohungen richten sich meist gegen die drei Ziele Vertraulichkeit, Integrität und Verfügbarkeit, die in der Datensicherheit eine zentrale Bedeutung einnehmen (vgl. Oppliger 1997, S. 10). Ohne Sicherstellung dieser Sicherheitsanforderungen verlieren Informationen ihren eigentlichen Wert (vgl. Pipkin 2000, S. 14).

Smartcard

Abb. 1:

Verfügbarkeit

Integrität

...

Autorisierung

Authentifizierung Zugriffsrechteprüfung

Referenzmonitor

Beweissicherung

Übertragungssicherung

...

PIN / TAN PrüfsummenProtokollierung Verschlüsselung Abfrage bildung

...

Exemplarische Darstellung des Zusammenhangs zwischen Sicherheitsanforderungen, -funktionen und -mechanismen

1. Vertraulichkeit (engl.: confidentiality, secrecy): Diese Anforderung besagt, dass sämtliche Ressourcen, Daten und Informationen nur berechtigten Personen oder Organisationen zugänglich sein sollen. Nur wenn Informationen zur Erfüllung der Aufgaben notwendig sind, sollten sie den jeweiligen Personen zugänglich sein. Die Vertraulichkeit der Informationen muss sowohl bei direkten Zugriffen als auch bei indirekten Anfragen über logische Inferenzen sichergestellt sein. 2. Integrität (engl.: integrity, accuracy): Integrität zielt auf die Richtigkeit der Daten ab. Über den gesamten Lebenszyklus hinweg – von der Erzeugung über die Verarbeitung, Auswertung, Darstellung bis hin zur Archivierung – muss sichergestellt sein, dass nur erlaubte und beabsichtigte Veränderungen an den Daten vorgenommen werden. 3. Verfügbarkeit (engl.: availability): Darunter versteht man die Möglichkeit, Ressourcen in definierter Form innerhalb einer angemes-


127

senen Zeit zu nutzen (vgl. Oppliger 1997, S. 11). Ressourcen und Informationen, die zwar existieren, auf die aber nicht zugegriffen werden kann, sind zu jenem Zeitpunkt wertlos. Fehlende Verfügbarkeit von ITSystemen kann finanzielle Schäden in beträchtlicher Höhe nach sich ziehen. Eine zusammenhängende Verfolgung dieser drei Ziele in gegenseitiger Abstimmung ist für ein sicheres Informationssystem unbedingt notwendig.

2.3

Grundlegende Sicherheitsfunktionen

Die wichtigsten Grundfunktionen bei der Entwicklung und Umsetzung eines ganzheitlichen Sicherheitskonzeptes sind: • Identifikation und Authentifizierung: Grundlage für ein sicheres System ist die Erkennung und Verwaltung der Benutzer und Ressourcen. Sämtlichen Subjekten und Objekten eines Informationssystems müssen eindeutige, überprüfbare und fälschungssichere Identifikatoren zugeordnet werden (vgl. Pipkin 2000, S. 121ff.). Unter Authentifizierung versteht man die Validierung einer vorgegeben Identität (vgl. Oppliger 1997, S. 173). Dabei kann sowohl die Echtheit eines Benut-zers als auch die einer Ressource überprüft und bestätigt werden. Die Bestätigung und Sicherung der Authentizität erhöht somit den Grad der Vertraulichkeit und Integrität. • Zugriffsrechteverwaltung und -prüfung (Autorisierung): Die Verwaltung von Zugriffsrechten umfasst das Erteilen, Entziehen und Pflegen von Zugriffsrechten im gesamten Unternehmen. Zugriffsrechte bilden die Beziehungen zwischen Subjekten, Objekten und Zugriffsaktivitäten ab (vgl. Jonscher/Dittrich 1994, S. 27f.). Vor Ausführung eines Zugriffs muss überprüft werden, ob dieser gemäss Rechteverwaltung zulässig ist oder gegen etwaige Bedingungen verstösst. • Beweissicherung: Die Beweissicherung trägt zur Erhöhung der Nachvollziehbarkeit, Verbindlichkeit und Integrität bei. Sie dokumentiert alle Informationen über Zugriffe und Zugriffsversuche sämtlicher Subjekte (vgl. O.V. 1989, S. 9). Die Protokolle müssen in regelmässigen Zeitabständen auf Unregelmässigkeiten und Regelverstösse überprüft werden. Mit ihrer Hilfe lassen sich die für eine Operation verantwortlichen Subjekte identifizieren und geeignete Massnahmen und Konsequenzen ableiten (vgl. Pipkin 2000, S. 175).

128


• Übertragungssicherung: Daten und Informationen müssen nicht nur

innerhalb eines Systems sicher sein, sondern auch bei der Übertragung zwischen den Systemkomponenten und zum Benutzer (vgl. Oppliger 1997, S. 4 und 313). Gerade in verteilten, heterogen strukturierten Informationssystemen mit globalen Zugriffen über das Internet spielt dies eine wichtige Rolle.

3

Zugriffskontrolle

Heutzutage haben Mitarbeiter aller Ebenen und Funktionen Zugriff auf die verschiedensten IT-Applikationen. Moderne, leistungsfähige Werkzeuge bereiten Informationen aufgaben- und benutzerspezifisch auf und adressieren somit den Informationsbedarf fast sämtlicher Mitarbeiter. Durch die Anbindung von Applikationen an das Internet können Anwender und Partner wie Aussendienstmitarbeiter, Lieferanten und Kunden standort- und zeitunabhängig mit Informationen versorgt werden. Neben diesen unterschiedlichen Benutzern haben Entwickler und Administratoren Zugang zu den unterschiedlichen Applikationen. Die verschiedenen Benutzergruppen besitzen jedoch unterschiedliche Berechtigungen für diese Ressourcen. Daraus folgt, dass Applikationslandschaften ein sehr feingranulares und flexibles Zugriffskontrollkonzept benötigen, das die vielen unterschiedlichen Anforderungen abbilden kann.

3.1

Grundlagen

Unter Zugriffskontrolle oder Autorisierung versteht man die Spezifikation von Regeln, wer welche Art von Zugang unter welchen Bedingungen zu welchen Informationen oder Objekten hat (vgl. Pernul 1995, S. 241). Bei der Autorisierung wird grundsätzlich zwischen Zugriffsrechteverwaltung und -überprüfung unterschieden (vgl. Gerhardt 2000, S. 100). Die Verwaltung von Zugriffsrechten umfasst das Erteilen, Entziehen und Pflegen von Zugriffsrechten im gesamten Unternehmen. Vor Ausführung eines Zugriffs wird überprüft, ob dieser gemäss Rechteverwaltung zulässig ist oder nicht (vgl. Samarati/de Capitani di Vimercati 2002, S. 137). Ein Zugriffsrecht R lässt sich vereinfacht als Dreitupel bestehend aus Subjekt, Objekt und zugehöriger Zugriffsaktion beschreiben (vgl. Gerhardt et al. 2000, S. 106). Um jedoch die Flexibilität und Semantik zur Beschreibung von Zugriffskontrollstrategien zu erhöhen, wird von Jonscher und Dittrich


129

folgendes siebenteiliges Kreuzprodukt definiert (vgl. Jonscher/Dittrich 1994, S. 27): R⊇SxOxAxPxKxNxG S – Menge der Subjekte; O – Menge der Objekte; A – Menge der Aktionen; P – Menge der Prädikate; K – Kennzeichen zur Unterscheidung von Erlaubnissen und Verboten; N – Menge der Nutzer (Quellsubjekte); G – Grant-Option Die aktiven Entitäten eines Informationssystems, wie z.B. Benutzer oder Programme, welche den Zustand des IT-Systems verändern können, werden Subjekte genannt. Objekte hingegen sind passive Entitäten, auf die Subjekte zugreifen. Sie stellen die kleinsten Einheiten dar, welche durch das Zugriffskontrollsystem geschützt werden können. Objekte können softwaretechnische Konstrukte wie Dateien, Tabellen oder physische Einheiten, wie Drucker oder Server, aber auch logische Entitäten, wie z.B. eine betriebswirtschaftliche Transaktion repräsentieren (vgl. Seufert 2001, S. 27). Als Zugriff werden in diesem Zusammenhang alle Aktionen verstanden, die direkt oder indirekt über Werkzeuge die syntaktische Struktur oder die Semantik der Objekte auslesen, nutzen, erzeugen, verändern oder löschen. Zugriffsrechte bilden somit die Beziehung zwischen Subjekten, Objekten und Aktionen ab (vgl. Jonscher/Dittrich 1994, S. 27f.). Zusätzliche Spezifikationen, sogenannte Prädikate, erhöhen die semantische Ausdruckskraft von Zugriffsregeln. Regeln können positiv als Erlaubnis oder negativ als Verbot formuliert werden. Systeme, welche nur Erlaubnisse zulassen, werden als positive Schutzsysteme bezeichnet, während Systeme mit reinen Verbotsregeln als negative Schutzsysteme bezeichnet werden. Ebenso existieren gemischte Schutzsysteme mit Erlaubnissen und Verboten. Da eine vollständige Spezifikation aller potenziellen Regeln aussichtslos erscheint, ist es sinnvoll, Abschlussregeln bezüglich der zugrunde liegenden (System-)Weltannahme zu definieren. Bei einer offenen Weltannahme sind alle nicht spezifizierten Zugriffe erlaubt, während sie bei einer geschlossen Weltannahme grundsätzlich verboten sind. Sinnvolle Kombinationen sind positive/gemischte Schutzsysteme mit geschlossener Weltannahme und negative/gemischte Schutzsysteme mit offener Weltannahme (vgl. Jonscher/Dittrich 1994, S. 29). Bei gemischten Systemen müssen zusätzlich Prioritäten als Konfliktlösungsmechanismen definiert werden, da es ansonsten möglich wäre, parallel sowohl eine Erlaubnis als auch ein Verbot für das gleiche Subjekt und Objekt zu modellieren (vgl. Bauer/Günzel 2001, S. 247). Aktuelle kommerzielle Software-

130


systeme (z.B. Unix, Windows, Oracle RDBMS) sind zumeist als positive Schutzsysteme mit geschlossener Weltannahme konzipiert. Drei Paradigmen zur Verwaltung von Rechten werden üblicherweise unterschieden (vgl. Oppliger 1997, S. 202; Seufert 2001, S. 50): • Eigentümer-Paradigma: Nur der Eigentümer eines Objekts verwaltet dessen Zugriffsrechte. Der Erzeuger eines neuen Objekts wird zugleich deren Eigentümer. Das Recht zur Weitergabe von Zugriffsrechten (Grant-Option) kann jedoch vom Eigentümer auch an andere übertragen werden. Bei dieser dezentralen Verwaltung ist es allerdings aus Komplexitätsgründen meist unmöglich festzustellen, wer von wem (Quellsubjekt) welche Zugriffsrechte bekommen hat und wie diese ggf. rekursiv wieder zurückgenommen werden können. Die unternehmensweite Durchsetzung und lückenlose Überwachung von Sicherheitsrichtlinien ist auf Basis dieses unkontrollierten Rechtetransfers sehr schwierig (vgl. Lau/Gerhardt 1994, S. 61f.). • Besitzer-Paradigma: Das Besitzer-Paradigma schränkt die Verwaltungsmöglichkeiten deutlich weniger ein als das Eigentümer-Paradigma. Allein der Besitz eines Rechtes reicht bereits aus, um es weiterzugeben oder zu entziehen. • Administrator-Paradigma: Im Gegensatz zu den beiden vorher-

gehenden Alternativen propagiert das Administrator-Paradigma eine zentrale Instanz Systemadministrator, die alleine die Zugriffsrechte aller Objekte verwaltet, was jedoch bei Systemen mit vielen Anwendern und häufigen Rechteänderungen ein stark einschränkender Faktor sein kann (vgl. Lau/Gerhard 1994, S. 60). Sicherheitsstrategie Rechteverwaltung

Subjekt

Referenzmonitor

Schutzobjekt

Protokollierung

Abb. 2:

Modell eines Referenzmonitors (vgl. Jonscher/Dittrich 1994, S. 26)

Ein allgemeiner Sicherheitsmechanismus zur Umsetzung eines solchen Zugriffsschutzes ist ein Referenzmonitor (siehe Abb. 2). Jeder Zugriffswunsch eines Subjekts auf ein bestimmtes Objekt wird zunächst vom Re-


131

ferenzmonitor abgefangen und auf seine Zulässigkeit gemäss Rechteverwaltung und Sicherheitsstrategie überprüft. Der Referenzmonitor übernimmt zusätzlich die Verantwortung für die Beweissicherung. Je nach Sicherheitsstrategie werden sämtliche Zugriffe oder nur die Regelverletzungen mitprotokolliert (Jonscher/Dittrich 1994, S. 26).

3.2

Anforderungen der Praxis

Dieser Artikel untersucht, welche Zugriffskontrollansätze und welche Integrationsmöglichkeiten im Kontext von heterogenen Applikationen am geeignetesten sind. Bewertungskontrolle für die Implementierung der Zugriffskontrolle Kriterien

Erklärung

Administrierbarkeit

Ein Administrierungskonzept muss klare Regeln für die Rechtezuordnung und –verwaltung vorgeben. Systemübergreifende Zugriffskontrolle ist in den meisten Fällen zu aufwendig und zu komplex, um ausschliesslich von einer natürlichen Person gepflegt zu werden; eine Verteilung der administrativen Aufgaben ist deshalb erforderlich.

Nachvollziehbarkeit

Zu jeder Zeit sollten sämtliche Entitäten, Zuordnungen oder Aktionen nachvollziehbar und überprüfbar sein. Aufgrund der heterogenen, verteilten Struktur der Systemlandschaft sollte deshalb eine systemweite Sicherheitsstrategie umgesetzt werden.

Bewertungskontrolle für die Implementierung der Zugriffskontrolle Kriterien

Erklärung

Granularität des Kontrollbereichs

Die Granularität des Kontrollbereichs sollte grundsätzlich möglichst fein sein, um auf die unterschiedlichen Anforderungen im Umfeld heterogener Systemlandschaften individuell reagieren zu können. Einschränkungen sind jedoch im Hinblick auf die Performance zu beachten. Der Zugriffskontrollansatz muss im modernen betriebswirtschaftlichen Umfeld sinnvoll einsetzbar sein. Das betriebswirtschaftliche Umfeld zeichnet sich v. a. durch eine Vielzahl von Subjekten mit einer dynamischen Aufgabenzuordnung, flachen Hierarchien und wechselnder Verantwortung aus.

Eignung für betriebswirtschaftliches Umfeld

Tab. 1: Bewertungskriterien für konzeptionelle Zugriffskontrollansätze

132


Um dies zu beurteilen, sind praxisrelevante Anforderungen und Bewertungskriterien erforderlich. Die hier dargestellten Anforderungen für die Zugriffskontrolle und deren Implementierung wurden zusammen mit Praxisvertretern im Rahmen eines Workshops des Kompetenzzentrums Data Warehousing 2 sowie in vertiefenden Expertengesprächen erarbeitet (siehe Tab. 1 und Tab. 2). Für die Implementierung der Zugriffskontrolle wurden nachstehende Bewertungskriterien identifiziert (siehe Tab. 2). Bewertungskontrolle für die Implementierung der Zugriffskontrolle Kriterien

Erklärung

Konsistenz, Integrität

Das ganzheitliche Zugriffskontrollschema muss jederzeit in einem konsistenten Zustand sein, auch wenn viele Veränderungsoperationen auf unterschiedlichen Systemkomponenten durchgeführt werden: Beispielsweise muss beim Löschen eines Subjektes wegen seines Ausscheidens aus dem Unternehmen garantiert sein, dass es in allen Systemen gelöscht wird. Zugriff auf Daten darf nur für autorisierte Subjekte möglich sein. Um dies sicherzustellen, sollten individuelle Zugänge zu allen Systemen geschaffen werden, keine Pauschallogins Die Administration soll effizient und benutzerfreundlich sowie ganzheitlich (single point of administration) unterstützt werden.

Vertraulichkeit

Administration, Pflege

Bewertungskontrolle für die Implementierung der Zugriffskontrolle Kriterien

Erklärung

Erweiterbarkeit, Flexibilität Verfügbarkeit, Robustheit

Die Zugriffskontrolle sollte flexibel auf zusätzliche, ggf. heterogene Systemkomponenten erweiterbar sein. Die Verfügbarkeit und Robustheit des Gesamtsystems soll möglichst hoch sein. Der Ausfall einer Komponente soll die Funktionsfähigkeit der anderen Komponenten nicht oder möglichst wenig beeinträchtigen. Der Aufwand für die Implementierung sollte möglichst gering sein. Das Minimierungsziel bezieht sich auf die Gesamtkosten für die Erstellung, Erweiterung und Pflege der unterschiedlichen Sicherheitskomponenten.

Aufwand, Kosten

Tab. 2:

Bewertungskriterien für die Implementierung der Zugriffskontrolle


4

133

Zugriffskontrolle in der Literatur

Im Folgenden werden unterschiedliche Zugriffskontrollansätze aus der Literatur erläutert, sowie die Unterschiede und Einsatzmöglichkeiten aufgezeigt, um sie daraufhin mit Hilfe der oben genannten Bewertungskriterien zu vergleichen. Anschliessend werden Konzepte vorgestellt, die eine Integration unterschiedlicher Zugriffskontrollkomponenten erlauben. Auch diese Konzepte werden anhand der vorgestellten Kriterien diskutiert.

4.1

Zugriffskontrollansätze

In der Literatur lassen sich grundsätzlich drei verschiedene Klassen von Zugriffskontrollansätzen unterscheiden (vgl. Samarati/de Capitani di Vimercati 2002, S. 139): • Benutzerbestimmte Zugriffskontrolle (engl. Discretionary Access Control (DAC)) • Systembestimmte Zugriffskontrolle (engl. Mandatory Access Control (MAC)) • Rollenbasierte Zugriffskontrolle (engl. Role-based Access Control

(RBAC))

4.1.1 Benutzerbestimmte Zugriffskontrolle Eine benutzerbestimmte Zugriffskontrollstrategie beruht auf der eindeutigen und vollständigen Identifikation und Enumeration sämtlicher Subjekte und Objekte eines zu schützenden Systems. DAC-Modelle werden üblicherweise als Zugriffskontrollmatrizen dargestellt (siehe Abb. 3). Subjekte werden jeweils durch eine Zeile (S1-Si), Objekte jeweils durch eine Spalte (O1-Oj) beschrieben. In den Schnittpunkten von Zeilen und Spalten werden die Zugriffsrechte Rij, die ein Subjekt Si auf ein Objekt Oj hat, spezifiziert. Mögliche Zugriffsrechte sind z.B. Lesen, Schreiben, Ausführen von Prozeduren, Löschen oder Anlegen. Die Granularität der Objekte und Subjekte ist ein sehr wichtiger Parameter bei der Konzeption eines diskreten Zugriffskontrollmodells mit weitreichenden Auswirkungen auf den späteren Betrieb (vgl. Oppliger 1997, S. 204). Werden zum Beispiel nur komplette Tabellen eines RDBMS als Objekte identifiziert, so ist es später nicht möglich, den Zugriff auf Datensätze innerhalb einer Tabelle einzuschränken.

134


Sämtliche Objekte haben einen Eigentümer, der alle Rechte an dem Objekt besitzt und verwaltet. Er kann sie an weitere Subjekte ohne vorherige Vermittlung und Genehmigung eines Administrators weitergeben und auch widerrufen. Die Verwaltung der Rechte und der durch sie beeinflusste Informationsfluss unterliegt somit der Diskretion des einzelnen Benutzers, was dem Zugriffsmodell auch den Namen gab (vgl. Fischer-Hübner 2001, S. 79). Ein Beispiel für einen nicht autorisierten Informationsfluss soll die Problematik verdeutlichen: Subjekt S1 ist Besitzer einer vertraulichen Datei O1 und gewährt nur Subjekt S2 Leserechte für diese Datei. Subjekt S2 könnte nun eine neue Datei O2 anlegen und den Inhalt von O1 hineinkopieren. Danach könnte S2 als Erzeuger und Eigentümer der Datei O2 einem Dritten Leserechte auf die Datei O2 erteilen und so die vertraulichen Inhalte veröffentlichen, obwohl S1 dies eigentlich nicht zulassen wollte (vgl. Oppliger 1997, S. 210). Solches Fehlverhalten von Subjekten kann nur im Nachhinein durch Audit-Massnahmen erkannt werden. O1

O2

…

Oj

S1

R11

R12

R1j

S2

R21

R22

R2j

Ri1

Ri2

Rij

… Si Tab. 3:

Zugriffskontrollmatrix

Zugriffskontrollmatrizen eignen sich zwar gut für eine übersichtliche, logische Darstellung, sind in der Praxis aufgrund ihrer Unflexibilität und schnell wachsenden Grösse allerdings ungeeignet. Zugriffsrechte sind üblicherweise stark ungleich verteilt, d.h. Objekte, die öffentlich zugänglich sind, erfordern viele identische Rechteeinträge, und Objekte, die sehr limitiert zugänglich sind, ziehen andererseits viele Leerzellen in der Matrix nach sich. Diese sind speichertechnisch nachteilig. Des Weiteren wächst die Matrix bei mehreren tausend Benutzern und Objekten schnell in eine nicht mehr effizient handhabbare Grössenordnung (vgl. Oppliger 1997, S. 205 f.). DAC-Modelle werden deshalb nicht als Matrix, sondern meist als verlinkte Fähigkeitslisten oder Zugriffskontrolllisten implementiert. Fähigkeitslisten beschreiben die Zugriffsrechte aus der Perspektive der Subjekte. Sie stellen die Berechtigung für bestimmte Objekte und die zugehörige Zugriffsart dar (vgl. Pfleeger 1997, S. 247). Jeder Eintrag in der Fähigkeitsliste spezi-


135

fiziert somit die Schutzumgebung genau eines Subjekts (vgl. Oppliger 1997, S. 206 f.). Die alternative Darstellung ist die Zugriffskontrollliste. Jedes Element der Liste spezifiziert für ein Objekt, welche Subjekte welche Art von Zugriff haben (vgl. Pfleeger 1997, S. 244). Sowohl die Fähigkeits- als auch die Zugriffskontrollliste enthält nur die relevanten Einträge. Es werden keine Leereinträge verwaltet und gespeichert. Der DACZugriffsansatz ist wegen seiner hohen Flexibilität und leichten Implementierbarkeit in vielen Softwaresystemen, insbesondere in Betriebssystemen wie Windows 2000 und Sun Solaris, integriert.

4.1.2 Systembestimmte Zugriffskontrolle Im Vergleich zur benutzerbestimmten Zugriffskontrolle steht bei der systembestimmten Zugriffskontrolle (MAC) nicht die Kontrolle der Datenzugriffe, sondern die Kontrolle der Informationsflüsse im Vordergrund. Jedem Subjekt und Objekt wird eine Sicherheitsmarke (engl. label) zugewiesen, welche bei den Subjekten als Ermächtigung (engl. clearance) und bei den Objekten als Klassifikation (engl. classification) bezeichnet wird. Diese Sicherheitsmarke beschreibt die Vertrauenswürdigkeit des Subjekts bzw. die Sensitivität des Objekts (vgl. Pernul 1995, S. 245). Sicherheitsmarken bestehen aus zwei Komponenten, einer hierarchisch geordneten Menge von Sicherheitslevels und einer ungeordneten Menge von Kategorien. Mögliche Sicherheitslevel sind zum Bespiel „top secret“, „secret“, „confidential“ und „unclassified“ mit einer absteigenden Rangfolge von „top secret“ nach „unclassified“. Beispielhafte Kategorien in betriebswirtschaftlichen Systemen sind z.B. Funktionsbereiche „Finanzen“ oder „Marketing“ (vgl. Samarati/de Capitani di Vimercati 2002, S. 148f.). Die Kategorienzuordnung unterstützt die Umsetzung des Need-to-know-Prinzips, indem Anwendern nur der Zugang zu den für sie relevanten Bereichen gewährt wird (vgl. Fischer-Hübner 2001, S. 42). Zwischen den Sicherheitsmarken wird eine sogenannte Dominanzbeziehung definiert. Eine Sicherheitsmarke SM1 dominiert eine Sicherheitsmarke SM2, wenn der Sicherheitslevel von SM1 grösser oder gleich als von SM2 ist und zugleich die Kategorien von SM1 die Kategorien von SM2 einschliessen. Die Sicherheitsmarken und ihre Dominanzbeziehungen bilden das mathematische Konstrukt eines Verbandes. Abbildung 3 zeigt einen Ausschnitt aus einem Beispiel für einen Sicherheitsverband, bei dem nur die beiden Sicherheitslevel Top Secret (TS) und Secret (S), sowie die Kategorien Finanzen und Marketing betrachtet werden. Das Label „TS, {Marketing}“ dominiert z.B. die beiden Labels „TS, {}“ und „S, {Marketing}“. Zwei Sicherheitsmarken SM1 und SM2, für die weder SM1 > SM2, noch SM2 >

136


SM1 gilt, heissen unvergleichbar, wie z.B. „TS, {Marketing}“ und „S, {Finanzen}“ (vgl. Samarati/de Capitani di Vimercati 2002, S. 149). TS, {Finanzen, Marketing}

TS, {Finanzen}

S, {Finanzen, Marketing}

S, {Finanzen}

TS, {}

Legende:

S, {}

dominiert

Abb. 3:

TS, {Marketing}

S, {Marketing}

Beispiel für einen Sicherheitsverband (vgl. Samarati Capitani di Vimercati 2002, S. 148f.)

Die Verwaltung und Kontrolle der Zugriffsrechte ist nicht von der Diskretion der Besitzer und Anwender abhängig, sondern wird von einem zentralen Administrator vorgenommen und basiert auf der zuvor vorgenommenen Einstufung der Subjekte und Objekte hinsichtlich deren Vertrauenswürdigkeit bzw. Sensitivität. Nur wenn bestimmte mathematische Regeln zwischen Ermächtigung und Klassifikation erfüllt sind, wird der Zugriff erlaubt. Diese Regeln sind je nach verfolgtem Sicherheitsziel unterschiedlich. Die Umsetzbarkeit von betriebswirtschaftlichen Sicherheitsstrategien mit Hilfe dieses Zugriffskontrollansatzes ist in modernen Unternehmen mit flachen, teamorientierten Führungsstrukturen eher schwierig, da Ausnahmen ausserhalb der strikten Ordnung der Dominanzrelation schwer zu modellieren sind (vgl. Seufert 2001, S. 84). Im Folgenden werden zwei Vertreter von regelbasierten, systembestimmten Zugriffsmodellen, Bell-LaPadula und Biba, kurz vorgestellt.

Bell-LaPadula-Modell Das Bell-LaPadula-Modell (vgl. Bell, LaPadula 1973) schützt insbesondere die Vertraulichkeit von Informationen. Zentrale Bestandteile sind die Sicherheitsfunktion C und folgende zwei Regeln (vgl. Oppliger 1997, S. 215) (siehe Abb. 4): 1. Ein Subjekt darf auf ein Objekt nur dann zugreifen, wenn seine Ermächtigung grösser oder gleich der Klassifikation des Objekts ist


137

(C(S) ≥ C(O)). Diese Regel verhindert das Lesen von vertraulichen Informationen durch unautorisierte Anwender (no read up). 2. Ein Subjekt darf nur schreibend auf ein Objekt zu greifen, wenn seine

Top Secret

read

write

read

Confidential

Abb. 4:

Dominanz

write

read

Secret

Informationsfluss

write

read

write

Ermächtigung kleiner oder gleich der Klassifikation des Objekts ist (C(O) ≥ C(S)). Diese Regel (*-Eigenschaft) verhindert das Schreiben von vertraulichen Informationen auf niedrigere Level (no write down).

Unclassified

Darstellung des Bell-LaPadula-Zugriffskontrollmodells (vgl. Samarati/de Capitani di Vimercati 2002, S. 151)

Durch Anwendung dieser beiden Regeln wird jeglicher Informationsfluss (sowohl schreibend als auch lesend) auf eine niedrigere Vertraulichkeitsstufe verhindert. Will eine Person mit einer hohen Ermächtigung Informationen an ein Subjekt mit niedriger Ermächtigung weitergeben, so muss es sich mit einer niedrigen Ermächtigung am System anmelden (vgl. Samarati/de Capitani di Vimercati 2002, S. 151). Diese starren Regeln schränken jedoch die praktischen Einsatzmöglichkeiten des Modells stark ein. Insbesondere kann durch blindes Schreiben von Subjekten mit niedriger Ermächtigung auf Objekte mit höherer Einstufung die Integrität verletzt werden. Diese integritätsverletzenden Schreibvorgänge können sowohl absichtlich als auch unabsichtlich auftreten, da eine Kontrolle auf eventuelle Schreibfehler nicht erlaubt ist (no read up). Die Reorganisation von Daten und die Herabsetzung von Klassifikationen ist schwierig (vgl. Oppliger 1997, S. 215 f.).

138


Biba-Modell Das Bell-LaPadula-Modell verhindert zwar die Offenlegung von vertraulichen Informationen, aber nicht die absichtliche oder unabsichtliche Manipulation von höher klassifizierten Objekten. Das Biba-Modell (vgl. Biba 1977) wirkt diesem Mangel mit komplementären Regeln zu Bell-LaPadula entgegen. Das Biba-Modell beschränkt ebenso die Informationsflüsse, jedoch sind Schreibzugriffe nur nach unten und Lesezugriffe nur nach oben möglich (vgl. Oppliger 1997, S. 216f.). Hierzu definiert Biba eine Integritätsfunktion I, welche Integrationslevel für die Subjekte und Objekte berechnet, und folgende zwei Regeln (Oppliger 1997, S. 217): 1. Ein Subjekt darf auf ein Objekt lesend zugreifen, wenn die integrationsbezogene Klassifikation des Objekts grösser als oder gleich der integrationsbezogenen Ermächtigung des Subjekts (I(O) ≥ I(S)) ist (no read down). 2. Ein Subjekt darf auf ein Objekt schreibend zugreifen, wenn die integrationsbezogene Ermächtigung des Subjekts grösser oder gleich der Klassifikation des Objekts (I(S) ≥ I(O)) ist (no write up). Die Integrationslevel des Biba-Modells sind von den Sicherheitsniveaus des Bell-LaPadula-Modells unabhängig. Nachteile des Biba-Modells sind ebenso die hohen Restriktionen und die Unflexibilität sowie die nur unvollständige Kontrolle der Integrität. Sicherstellung von Integrität bedeutet nicht nur die Verhinderung des Informationsflusses von Hochsicherheitsin Niedrigsicherheitsbereiche, sondern auch die Sicherstellung, dass die Daten im System korrekt sind (vgl. Samarati/de Capitani di Vimercati 2002, S. 177). Bei Informationssystemen mit besonders hohen Sicherheitsanforderungen können beide regelbasierten Zugriffskontrollmodelle miteinander kombiniert werden. Dies kann mit Hilfe zweier Referenzmonitore, einer für den Bell-LaPadula- und einer für den Biba-Ansatz, mit ziemlich hohem Aufwand umgesetzt werden (vgl. Seufert 2001, S. 95 f.). Verschiedene Datenbankhersteller bieten MAC als Option an, wie z.B. Oracle oder Sybase (vgl. Gerhardt et al. 2000, S. 112f.; Samarati/de Capitani di Vimercati 2002, S. 159).


139

4.1.3 Rollenbasierte Zugriffskontrolle Rollenbasierte Zugriffskontrolle (engl. role-based access control (RBAC)) ist eine dritte Variante neben den traditionellen DAC und MAC, welche aufgrund der hohen Flexibilität bei der Beschreibung und Durchsetzung von unternehmensspezifischen Sicherheitspolitiken vor allem in kommerziellen Informationssystemen eingesetzt wird (vgl. Samarati/de Capitani di Vimercati 2002, S. 180). Subjekte erhalten aufgrund ihrer Aufgaben und Verantwortlichkeiten die Mitgliedschaft an benötigten Rollen. Rollen sind eine Weiterentwicklung des Gruppenkonzeptes, bei dem lediglich Mengen von Benutzern nach verschiedenen Kriterien zusammengefasst werden (vgl. Sandhu 1995, S. 25). Rollen stellen die Zusammenfassung von Rechten dar, die zur Erfüllung von mit ihnen verbunden Aufgaben und Funktionen notwendig sind (Need-to-know-Prinzip) (vgl. Lau/Gerhardt 1994, S. 66). Zwischen Rollen und Benutzern sowie Rollen und Zugriffsrechten auf Objekte existiert eine Viele-zu-viele-Beziehung (siehe Abb. 5). Aufgrund der Abstraktion von einzelnen, konkreten Subjekten ist die Rechtezuordnung zeitlich stabiler als bei der benutzerbestimmten Zugriffskontrolle (DAC). Veränderungen in der Personalstruktur, wie z.B. Neueinstellungen oder Entlassungen, beeinflussen die Rechtezuordnung nicht. Auch ein Wechsel oder eine Erweiterung des Aufgabenbereichs von Mitarbeitern verursacht wenig Aufwand für die Verwaltung der grundsätzlichen Rechtestruktur. Subjekte

Rollen

Objekte

Rolle 1

Rolle 2

...

... Rolle n

Abb. 5:

Role-based Access Control (vgl. Samarati/de Capitani di Vimercati 2002, S. 182)

Die dargestellte Basisvariante des RBAC kann mit unterschiedlichen Konzepten erweitert werden. Rollen können in einer Hierarchie angeordnet werden. Dadurch lassen sich typische Unternehmensstrukturen adäquat

140


modellieren. Eine Rolle kann eigene Attribute und Rechte sowie weitere Rollen besitzen (vgl. Ferraiolo et al. 1995). Zusätzlich lassen sich Regeln und Bedingungen spezifizieren, welche die Semantik des Zugriffskonzepts erhöhen. Zum Beispiel lassen sich das Prinzip der Aufgabentrennung oder das Mehr-Augen-Prinzip umsetzen. Zusätzlich werden die statische und die dynamische Sicht unterschieden. Bei der statischen Variante wird mit Hilfe einer Zuordnungskonfliktmatrix festgelegt, welche Rollen ein Subjekt nicht gleichzeitig besitzen darf. Die dynamische Sicht wird mit Hilfe einer Aktivierungskonfliktmatrix realisiert. Ein Benutzer besitzt zum Beispiel mehrere Rollen, darf sie aber nicht alle gleichzeitig aktivieren, sondern muss explizit angeben, in welcher Rolle er zu einem bestimmten Zeitpunkt agiert (vgl. Jonscher/Dittrich 1994, S. 31). Des Weiteren lassen sich Einschränkungen formulieren wie z.B. die maximale Anzahl von zugewiesenen Rollen pro Subjekt oder die maximale Anzahl der parallelen Aktivierungen einer Rolle zu einem bestimmten Zeitpunkt (vgl. Samarati/de Capitani di Vimercati 2002, S. 182 f.). Die Sicherheitsstrategie des rollenbasierten Zugriffskontrollansatzes ist systemweit, d.h. die einzelnen Subjekte haben keinen Einfluss hinsichtlich der Vergabe oder des Entzugs von Rechten. Die Pflege und Verwaltung des Schemas kann aber auf mehrere Administratoren aufgeteilt werden, indem wiederum ein Administrationsschema auf Basis eines Rollenkonzepts zur Verwaltung des eigentlichen RBAC-Schemas definiert wird (Sandhu et al. 1999). Der RBAC-Ansatz ist sehr flexibel und erweiterungsfähig und kann sowohl mit benutzerbestimmten als auch systembestimmten Zugriffskontrollstrategien kombiniert werden.

4.1.4 Bewertung der Zugriffskontrollansätze Die vorgestellten Ansätze werden im Folgenden gemäss den Anforderungen und Kriterien aus Abschnitt 3.2 bewertet (siehe Tab. 4).

Nachvollziehbarkeit

Granularität des Kontrollbereichs

Eignung für betriebswirtscaftliches Umfeld

141

Administrierbarkeit


Zugriffsmatrix

++

+

+++

++

Bell-LaPadula

++

+++

++

o

Biba

++

+++

++

o

RBAC

+++

++

+++

+++

Legende:

Tab. 4:

+++ erfüllt ++ weitgehend erfüllt + kaum erfüllt

o nicht erfüllt

Zusammenfassende Bewertung der Zugriffskontrollansätze

Beim Zugriffsmatrixansatz ist die Administrierbarkeit klar festgelegt. Sie wird vom dezentralen Eigentümerprinzip dominiert. Die Verantwortung für den Schutz der Vertraulichkeit und Integrität wird an die Eigentümer übergeben. Es muss darauf vertraut werden, dass sie die jeweiligen Rechte nur an vertrauenswürdige Subjekte weiter geben. Auch leidet durch die benutzerbestimmte Sicherheitsstrategie die Nachvollziehbarkeit. Wegen der unkontrollierten Rechtevergabe durch den Eigentümer ist es nur schwer möglich festzustellen, wer welche Rechte besitzt. Systemweite Beschränkungen können nicht effektiv durchgesetzt werden. Die Granularität des Kontrollbereichs kann durch die Zugriffsmatrix im Prinzip beliebig fein modelliert werden. Die Anwendbarkeit dieses Ansatzes im betriebswirtschaftlichen Umfeld ist aufgrund seiner Flexibilität und Einfachheit grundsätzlich gegeben, die Zuordnung und Pflege des Schemas bei einer grossen Anzahl von Subjekten und Objekten allerdings zunehmend mühsam und aufwendig. Bell-LaPadula und Biba nutzen beide einen zentralen Administrator-Ansatz, wodurch die systemweite Konsistenz und Durchsetzbarkeit gewährleistet ist. Die Bestimmung der Sicherheitsmarken für Subjekte und Objekte ist aber eine komplexe Aufgabe, die hierarchische Strukturen im Unternehmen erfordert. Die Ermittlung und Bestimmung dieser Sicherheitsmarken ist normalerweise sehr aufwendig und langwierig (z.B. Informationswertanalyse). Die Nachvollziehbarkeit ist aufgrund der systemweiten Strategie garantiert. Der Kontrollbereich bezieht sich bei den beiden Ansätzen auf den eigentlichen Informationsfluss zwischen den Entitäten und nicht auf die Entitäten selbst. Für den Einsatz in betriebswirt-

142


schaftlichen Umgebungen sind sie nicht oder nur bedingt geeignet, da die Ausdrucksfähigkeit der Regeln zur Sicherung der Vertraulichkeit bzw. Integrität sehr starr ist. Ausnahmen von der strikten Ordnung der Dominanzrelationen sind nur schwer zu modellieren. Der rollenbasierte Ansatz scheint für betriebswirtschaftliche Einsätze deutlich geeigneter. Rollen spezifizieren die zur Durchführung bestimmter Aufgaben notwendigen Rechte. Sie werden wiederum den Subjekten zugeordnet. Ein Subjekt kann verschiedene Rollen annehmen. Die Einführung der Abstraktionsebene der Rollen erhöht die Stabilität der Rechtezuordnungen und erleichtert die Administration. RBAC kann eine systemweite Sicherheitsstrategie mit dezentraler Verwaltung durch ein paralleles Rollenkonzept für die Administration umsetzen.

4.2

Ansätze zur Integration der Zugriffskontrolle

In diesem Kapitel wird eine organisatorische Sicht auf die Autorisierung eingenommen. Es werden unterschiedliche Möglichkeiten zur Integration von Zugriffskontrollansätzen in eine existierende Systemlandschaft betrachtet und diskutiert. Wie bereits erwähnt, handelt es sich bei den heutigen Systemlandschaften meist um historisch gewachsene, heterogene Systemumgebungen mit verschiedenen, eigenständigen Autorisierungskomponenten, sodass eine Integration zur Gewährleistung einer ganzheitlichen Zugriffskontrolle dringend erforderlich ist. Bei den folgenden vier Ansätzen wird von einer zentralen Autorisierungskomponente (engl. Access Control Service (ACS)) ausgegangen, die für die Administration und Realisierung der Zugriffskontrolle einer Applikation verantwortlich ist. Applikationen können sowohl monolithisch als auch nach dem Client-Server-Prinzip strukturiert sein. Die Implementierung der Autorisierungskomponente wird nicht näher aus Innensicht betrachtet, sondern lediglich ihre Einbindung in die Systemlandschaft. 4.2.1 Autonome Zugriffskontrolle Bei der autonomen Zugriffskontrolle existiert keine automatisierte Integration. Sämtliche Applikationen besitzen eigenständige Autorisierungskomponenten mit möglicherweise unterschiedlichen Zugriffskontrollansätzen. Die Sicherheitsadministratoren der einzelnen Applikationen sind verantwortlich für die konsistente Verwaltung und aktuelle Pflege der Benut-


143

zer, Rollen, Zugriffsrechte und deren Zuordnungen. Diese Variante erfordert keinen zusätzlichen Implementierungsaufwand und ist bei kleineren Systemen mit überschaubarer Benutzeranzahl organisatorisch effizient umsetzbar. Die Übersicht und Kontrolle geht bei steigender Anzahl von Systemen und Benutzern schnell verloren und es können durch fehlende Koordination unbemerkt Sicherheitslücken entstehen.

4.2.2 Server-Pull-Zugriffskontrolle Die Server-Pull-Zugriffskontrolle (siehe Abb. 6) erfordert die permanente Verbindung zwischen zentraler Autorisierungskomponente und den zu verwaltenden Applikationen. Die einzelnen Zielsysteme selbst besitzen keine selbständige Zugriffskontrolle, sondern greifen bei jeder Anfrage auf den zentralen Service zu. Applikationen mit externer Zugriffskontrolle werden auch als aktive Zielsysteme bezeichnet (vgl. Mänkeberg/Rakete 2000, S. 84).

Server

Zugriffskontrollanfrage

Abb. 6:

Client-/ServerKommunikation

Applikation

Client

Mensch-/MaschineKommunikation

Access Control Service (ACS)

Server-Pull-Zugriffskontrolle (vgl. Seufert 2001, S. 208)

Kritischer Punkt ist die Verfügbarkeit des Access Control Service und der Kommunikationsverbindung zwischen den Komponenten. Fällt eine von ihnen aus, so ist die gesamte Zugriffskontrolle aller angeschlossenen Applikationen nicht verfügbar und somit sind sämtliche Applikationen an sich nicht nutzbar. Bei Hochverfügbarkeitsanforderung sind diese Gefahren ggf. mehrfach abzusichern. Vorteile dieser Variante sind die redundanzfreie Implementierung und die konsistente, einfache Administration. Kommerzielle Standardsysteme unterstützen diese Architekturvariante zurzeit kaum. Anwendbar ist sie v.a. bei eigenentwickelten Systemen und Open-Source-Softwaresystemen, bei denen der Quellcode frei verfügbar ist (vgl. Seufert 2001, S. 226ff.).

144


4.2.3 Client-Pull-Zugriffskontrolle Die Client-Pull-Zugriffskontrolle eignet sich für Systeme, welche nach dem Client-Server-Prinzip strukturiert sind (siehe Abb. 7).

Server

Client-/ServerKommunikation Zertifikatübergabe


Abb. 7:

Applikation

Client


Zertifikatgenerierung

Client-Pull-Zugriffskontrolle (vgl. Seufert 2001, S. 209)

Der Client meldet sich beim Access Control Service an und bekommt von diesem ein signiertes Zertifikat, das die Berechtigungen des Clients fälschungssicher bezeugt. Dieses Zertifikat wird dem Server präsentiert, der dem Client daraufhin Zugriff auf die angeforderten Ressourcen gewährt (vgl. Seufert 2001, S. 209). Das Zertifikat wird bei allen Serveranfragen mitgesendet. Gut geeignet ist dieses Verfahren, wenn die Zugriffsobjekte im Voraus spezifiziert werden können und deren Anzahl nicht zu gross ist, um in einem Zertifikat abgelegt werden zu können. Ein Ausfall der ACSKomponente behindert die Generierung neuer Zertifikate, nicht aber den eigentlichen Autorisierungsvorgang zwischen Servern und Clients mit gültigen Zertifikaten.

4.2.4 Proxy-basierte Zugriffskontrolle Die proxy-basierte Zugriffskontrolle ist eine hybride Architektur aus Server- und Client-Pull-Autorisierung (siehe Abb. 8) (vgl. Sandhu 2000, S. 116).

Zugriffskontrolle in heterogenen Applikationslandschaften Client-/ServerKommunikation

Client-/ServerKommunikation

Server

Proxy

Client

145


Zugriffskontrollanfrage


Abb. 8:

Proxy-basierte Zugriffskontrolle (vgl. Seufert 2001, S. 211)

Dem Client gegenüber erscheint sie als Server-Pull-Zugriffskontrolle, während sie vom Server als Client-Pull-Autorisierung wahrgenommen wird. Die eigentliche Kommunikation mit dem Access Control Service wird von einem zwischengeschalteten Proxy durchgeführt (vgl. Sandhu 2000, S. 116). Der Proxy bildet die Schnittstelle des Servers genau ab. Er tritt als alleiniger Kommunikationspartner mit allen Rechten gegenüber dem Server auf. Die eigentliche Zugriffskontrolle wird durch den Access Control Service übernommen. Deshalb eignet sich diese Variante sehr gut für Legacy-Systeme, deren Schnittstellen und Funktionalitäten nicht mehr mit vertretbarem Aufwand angepasst werden können. Schwachpunkt ist wie bei der Server-Pull-Zugriffskontrolle die Abhängigkeit von der Verfügbarkeit der ACS-Komponente und des Kommunikationskanals (vgl. Seufert 2001, S. 210).

4.2.5 Zugriffskontrolle durch Remote-Administration Bei dieser Variante (siehe Abb. 9) erfolgt die Modellierung und Verwaltung des ganzheitlichen Zugriffskontrollschemas in der zentralen Autorisierungskomponente, die eigentliche Prüfung der Zugriffe findet aber in den lokalen ACS-Komponenten statt. Der zentrale Zugriffskontrollansatz wird auf die angeschlossenen Zugriffskontrollsysteme lediglich weitestgehend abgebildet, ersetzt diese aber nicht. Der Abgleich zwischen der Hauptzugriffskontrolle und den Zielsystemen erfolgt vollautomatisiert durch zielsystemspezifische Transformationsmodule in periodischen Abständen (vgl. Seufert 2001, S. 210 f.).

146


Server

Client-/ServerKommunikation ACS

Administration der Zugriffskontrolle

Abb. 9:

Transformationsmodul

Applikation

Client



Zugriffskontrolle durch Remote-Administration (vgl. Seufert 2001, S. 212)

Vorteil dieser Architektur ist die Unabhängigkeit der Komponenten. Selbst wenn der zentrale Access Control Service oder ein Kommunikationskanal ausfällt, können die anderen Applikationen weiter genutzt werden. Einziger Nachteil ist in diesem Fall der verzögerte Abgleich. Vorteilhaft ist auch die schnelle und relativ problemlose Möglichkeit, neue Zielsysteme einzubinden. Es muss lediglich ein neues Transformationsmodul erstellt werden. Ein Eingriff in die Zielsysteme ist nicht notwendig (vgl. Mänkeberg/Rakete 2000, S. 83 f).

4.2.6 Bewertung der Integrationsansätze Die vorgestellten Ansätze werden im Folgenden gemäss den Anforderungen und Kriterien aus Abschnitt 3.2 bewertet (siehe Tab. 5). Grundsätzlich lassen sich sämtliche dargestellten Zugriffskontrollansätze aus Abschnitt 4.2 mit allen spezifizierten Integrationsansätzen umsetzen. Beim autonomen Zugriffskontrollansatz findet keine wirkliche Integration statt. Die Zugriffskontrolle der verschiedenen Komponenten wird vom jeweiligen Administrator gewartet. In Systemumgebungen mit vielen Anwendern, Objekten und Rechten geht dabei schnell die Konsistenz zwischen den einzelnen Teilkomponenten verloren. Die Kosten für Administration sowie für Überprüfung und Wiederherstellung der Konsistenz erhöhen sich deutlich. Die Server-Pull-Zugriffskontrolle unterstützt die Konsistenz und einfache Administration durch eine zentrale Administrationskomponente. Die Vertraulichkeit ist hoch, da sämtliche Zugriffsüberprüfungen an die ACSKomponente weitergeleitet werden, in der individuelle Zugriffsprofile abgelegt sind. Die Erweiterbarkeit ist eingeschränkt, weil zurzeit wenige Systeme auf dem Markt eine aktive, ausgelagerte Zugriffskontrolle unter-


147


Vertraulichkeit

Administration

Erweiterbarkeit

Verfügbarkeit, Robustheit

Aufwand, Kosten

stützen. Bei Ausfall des Access Control Service oder der Kommunikationsverbindung sind sämtliche Komponenten des Gesamtsystems nicht funktionsfähig. Der Aufwand für Eigenentwicklungen oder für Erweiterungen von Standardsoftwarekomponenten zur Unterstützung der aktiven Zugriffskontrolle ist als hoch einzuschätzen. Zugriffskontrolle durch Zertifikate wird nicht von allen Komponenten unterstützt. Zur Umsetzung ist ein zusätzlicher Aufwand für die Public-Key-Infrastruktur zur Generierung der Zertifikate notwendig. Bei Ausfall der ACS-Komponente ist die Funktionstüchtigkeit des Gesamtsystems eingeschränkt. In diesem Fall können keine neuen Zertifikate ausgestellt werden, Subjekte mit existierenden, gültigen Zertifikaten können sich jedoch weiterhin gegenüber den Servern autorisieren. Bei Subjekten mit vielen Rechten können die Zertifikate sehr gross werden und ein effizientes Handling beeinträchtigen. Kritischer Punkt der proxy-basierten Zugriffskontrolle ist das Ausfallrisiko des Access Control Service, des Proxy oder der Kommunikationsverbindungen und der damit einher gehenden NichtVerfügbarkeit des Gesamtsystems. Die Vertraulichkeit ist stark gefährdet, wenn die Zugangsdaten des Proxy für den Server offen gelegt werden. Da der Proxy als der einzige Kommunikationspartner gegenüber dem Server auftritt, hat er normalerweise sämtliche Rechte auf dem Server. Bei einer Erweiterung muss die Schnittstelle der hinzugefügten Komponente durch den Proxy nachgebildet werden. Dies verursacht Zusatzaufwand, ist jedoch u.U. billiger als in das Zielsystem selbst einzugreifen.

Autonome Zugriffskontrolle

o

+

+

+++

+++

+

Server-Pull-Zugriffskontrolle

+++

+++

+++

+

o

+

Client-Pull-Zugriffskontrolle

++

+++

+++

+

++

o

Proxy-basierte Zugriffskontrolle

+++

+

+++

++

o

++

Remote-Administration

+++

+++

+++

+++

++

++

Legende:

Tab. 5:

+++ erfüllt ++ weitgehend erfüllt + kaum erfüllt

O nicht erfüllt

Zusammenfassende Bewertung der Integrationsansätze für die Zugriffskontrolle

148


Der Remote-Administrationsansatz verwaltet das gesamte Zugriffskontrollschema zentral. Durch den „single point of administration“ und die automatische Generierung der lokalen Zugriffskontrollschemata wird eine einfache, konsistente Verwaltung ermöglicht. Zudem wird durch die automatische Generierung auch das Ziel der Vertraulichkeit gestärkt, da individuelle Benutzerkonten leichter und aktueller gepflegt werden können. Die Architektur ist robust. Ein Ausfall hat keine grösseren Auswirkungen auf die anderen Komponenten, nur eine zeitliche Verzögerung der Synchronisation der Zugriffskontrolldaten. Eine Erweiterung ist verhältnismässig einfach zu realisieren. Es muss lediglich ein zusätzliches Transformationsprogramm für das neue Zielsystem erstellt werden. Die höheren Kosten für die Erstellung werden im Laufe der Zeit durch den gesparten Wartungsaufwand amortisiert.

5

Zugriffskontrolle in der Praxis

Im Folgenden wird aufgezeigt, welche Zugriffskontrollmechanismen in der Praxis vorherrschen und welche Möglichkeiten der Integration dieser Zugriffskontrollmechanismen sich bieten. Die vorgestellten Ergebnisse resultieren aus einem Praxisprojekt zum Thema „Autorisierung in verteilten Systemen“ des Kompetenzzentrums Application Integration Management mit einem Schweizer Grossunternehmen und der Diskussion des Themas „Sicherheit in verteilten Umgebungen“ im Rahmen eines Workshops des angesprochenen Kompetenzzentrums.

5.1

Zugriffskontrollansätze

Im Rahmen der Analyse der bestehenden Systemlandschaften kristallisierte sich die Verwendung von vier grundlegenden Zugriffskontrollansätze heraus. Diese können anhand von zwei Dimensionen systematisiert werden (siehe Abb. 10): • Ausrichtung des Rechtemanagements am Nutzer: Eine starke Ausrichtung am Nutzer liegt dann vor, wenn dem Benutzer direkt Rechte zugewiesen werden. Eine schwache Ausrichtung ist dann gegeben, wenn dem Nutzer die Rechte indirekt über die Verwendung von Rollen oder Gruppen zugewiesen werden. • Verwendung Aggregationskonzepte: Unter einem Aggregationskonzept

soll im Folgenden eine Rolle oder eine Gruppe verstanden werden.


149

Durchgängig Eingeschränkt

Verwendung Aggregationskonzepte

Beide Konzepte werden verwendet um Nutzer zu einer Entität zusammenzufassen, so dass die Administration erleichtert wird. Während man unter einer Gruppe eine Menge von Nutzern versteht, umfasst eine Rolle eine Menge von Rechten auf die Nutzung von Objekten (vgl. Samarati/de Capitani di Vimercati, S. 181). Eine eingeschränkte Verwendung von Aggregationskonzepten liegt vor, wenn Gruppen oder Rollen in vereinfachter Form verwendet werden. Existieren in einem System beispielsweise nur die Gruppen „Power User“ und „Standard User“, so liegt eine eingeschränkte Verwendung von Aggregationskonzepten vor. Im Gegensatz zu diesem einfachen Beispiel kann von einem erweiterten Aggregationsszenario z.B. dann gesprochen werden, wenn intensiv vom Gruppenkonzept gebrauch gemacht wird und eine Gruppe ggf. auch mehrere andere Gruppen enthält.

(n) Systemnutzer

(n)

(n) S.aggregations-

(n)

(n)

konzept

Systemrecht

(n)

Systemrolle

(n)

Systemgruppe

d,t

Nutzerorientiertes Aggregationskonzept Systemnutzer

Systemrecht

(n) (n) (n) S.aggregationskonzept (n)

(n)

(n)

Systemnutzer

(n)

Systemrecht

d,t

Systemrolle Systemgruppe

(n)

Durchgängiges Aggregationskonzept

(n) (n)

S.aggregationskonzept (n)

Systemrecht

(n)

d,t

(n)


Nutzerorientiertes Berechtigungskonzept

Einfaches Aggregationskonzept

Stark

Schwach

Ausrichtung des Rechtemanagements am Nutzer

Abb. 10: Zugriffskontrollansätze

Die hier aufgezeigten Grundtypen können nicht direkt den Zugriffsansätzen aus der Literatur (siehe Abschnitt 4.1) zugeordnet werden. So ist es beispielsweise möglich, das nutzerorientierte Berechtigungskonzept sowohl auf Basis der benutzerbestimmten Zugriffskontrolle als auch mittels rollenbasierter Zugriffskontrolle zu realisieren.

5.1.1 Nutzerorientiertes Berechtigungskonzept Beim nutzerorientierten Berechtigungskonzept werden weder Rollen noch Gruppen verwendet. Die Rechte werden direkt dem Nutzer zugewiesen (siehe Abb. 11). Während dieses Vorgehen bei einer geringen Nutzerzahl noch praktikabel ist, kann die Verwendung dieses Konzepts hingegen bei

150


steigender Nutzer- und Objektzahl insbesondere dann ineffizient sein, wenn eine grosse Anzahl an homogenen Systemnutzern (in Bezug auf ihre Rechte im System) existiert. Die Intransparenz, die bei grosser Nutzer- und Objektzahl entsteht, kann darüber hinaus zu Inkonsistenzen in der Rechtevergabe und zu Sicherheitslücken führen. Systemnutzer

Entitätstyp

(n)

Beziehungstyp Systemrecht

(n)

(n)

Maximal-Kardinalität

Abb. 11: Nutzerorientiertes Berechtigungskonzept

5.1.2 Einfaches Aggregationskonzept Das einfache Aggregationskonzept verwendet Rollen oder Gruppen, um Rechte an Nutzer zuzuweisen (siehe Abb. 12). Die Anzahl der verwendeten Gruppen bzw. Rollen sind jedoch stark beschränkt. Darüber hinaus findet keine explizite Zuordnung der Nutzer zu den Rollen im System statt. Der Zugriff auf das System erfolgt durch den Nutzer mit der ihm zugewiesenen Rolle bzw. Gruppe und nicht mit einem Systembenutzernamen. Typische Rollen, die in diesem Szenario vergeben werden, sind „Power User“ oder „Standard User“. Ebenfalls möglich ist die so genannte „Abstützung“ oder „Ableitung“ von Gruppen und Rollen, die in Abb. 12 durch die rekursive Beziehung abgebildet wird. Mittels dieser Beziehung kann beispielsweise definiert werden, dass die Rolle „Power User“ die Gruppe „Netzwerkadministratoren“ umfasst.

(n) (n)

S.aggregationskonzept (n)

Systemrecht

(n)

d,t


Abb. 12: Einfaches Aggregationskonzept

d,t

Disjunkte, totale Spezialisierung


151

Zu bemängeln ist bei diesem Konzept die in der Praxis anzutreffende hohe Granularität der Rechtevergabe bezüglich der gebildeten Nutzergruppen und -rollen. Auch wenn die Administration der Rechte dadurch erheblich vereinfacht wird, wirkt sich die undifferenzierte Vergabe von Rechten negativ auf die zu gewährleistende Sicherheit aus. Auch die im System fehlende Zuordnung von Nutzern zu Rollen bzw. Gruppen ist aus sicherheitstechnischen Überlegungen abzulehnen, da der Nutzer durch die fehlende Zuordnung anonym bleibt. Verstösse gegen die Sicherheit können so nicht geahndet werden. Darüber hinaus könnten Zugangsdaten einfach an andere Nutzer übertragen werden, ohne dass dies zentral kontrolliert werden kann. Ebenfalls problematisch gestaltet sich das Entziehen von Benutzerrechten.

5.1.3 Nutzerorientiertes Aggregationskonzept Beim nutzerorientierten Aggregationskonzept (siehe Abb. 13) wird das Rollen- bzw. Gruppenkonzept des einfachen Aggregationskonzepts erweitert. Darüber hinaus wird die Zuordnung des jeweiligen Nutzers zu einer bestimmten Gruppe oder Rolle explizit im System vorgehalten. Der Nutzer meldet sich mit einem eindeutigen Systemnamen am System an, so dass dieses protokollieren kann, welcher Nutzer welche Aktion im System vorgenommen hat. Eine Zuordnung von Rechten kann entweder mittels eines Aggregationskonzepts oder direkt über die Zuordnung zum Nutzer erfolgen. In der Praxis wird insbesondere im Umfeld von Produktivsystemen die Rechtevergabe mittels eines Aggregationskonzepts angewendet, da hier homogene Nutzergruppen (in Bezug auf ihre Rechte im System) existieren. Die direkte Zuordnung von Rechten erfolgt in der Regel in Bezug auf Testsysteme oder bei Ausnahmeregelungen. Die Ausgestaltung der rekursiven Beziehung, die auf der Entität Systemaggregationskonzept fusst, erfolgt in vielen Systemen ähnlich. Während die Nutzerverwaltung homogene Nutzergruppen, ausgehend von den Systemnutzern „top-down“ unter der Berücksichtigung ihrer Kompetenzen, bildet, erfolgt die Zusammensetzung von Rollen „bottom-up“ unter der Berücksichtigung von Systemobjekten und -rechten. Durch die Zuweisung von Benutzergruppen zu Rollen erfolgt letztendlich die Rechtezuweisung.

152


(n) Systemnutzer

(n)

(n)

(n) S.aggregations-

(n)

(n)

konzept

(n)

Systemrolle

Systemrecht

(n)

Systemgruppe

d,t

Abb. 13: Nutzerorientiertes Aggregationskonzept

Der Vorteil des nutzerorientierten Aggregationskonzepts liegt in der flexiblen Anwendung des Rollen- und Gruppenkonzepts. Rollen oder Gruppen können, müssen aber nicht zur Rechtevergabe verwendet werden. In Ausnahmen ist so auch eine direkte Zuordnung von Rechten möglich. Dadurch müssen nicht unnötig Rollen geschaffen werden, die lediglich eine eins-zu-eins Verkettung mit einem Nutzer aufweisen und dadurch die Komplexität des Systems unnötig erhöhen.

5.1.4 Durchgängiges Aggregationskonzept Das durchgängige Aggregationskonzept (siehe Abb. 14) ist mit dem nutzerorientierten Aggregationskonzept nahezu identisch. Lediglich die direkte Rechtezuweisung zwischen Systemnutzer und -objekt wird unterbunden.

(n) Systemnutzer

(n)

(n) S.aggregations-

(n)

konzept

(n)

Systemrolle

Systemrecht

(n)

Systemgruppe

d,t

Abb. 14: Durchgängiges Aggregationskonzept

Insbesondere langfristig ist die Definition von immer mehr Ausnahmen mittels der direkten Zuordnung von Rechten an Subjekte eine Gefahr für die Transparenz des gesamten Autorisierungssystems. Um das Abdriften des nutzerorientierten Aggregationskonzepts zum nutzerorientierten Berechtigungskonzept zu verhindern, kann die direkte Zuordnung von Rechten zu Benutzern untersagt werden. Speziell in Produktivsystemen wird daher das durchgängige Aggregationskonzept forciert, obwohl technisch gesehen auch das nutzerorientierte Aggregationskonzept realisierbar wäre.


153

5.1.5 Bewertung der Zugriffskontrollansätze Die vorgestellten Ansätze werden im Folgenden gemäss den Anforderungen und Kriterien aus Abschnitt 3.2 bewertet (siehe Tab. 6). Da es bei den hier diskutierten Zugriffskontrollansätzen nicht um technische Aspekte geht, werden die Anforderungen „Erweiterbarkeit, Flexibilität“18 und „Verfügbarkeit, Robustheit“ bei der Diskussion nicht berücksichtigt. Beim nutzerorientierten Berechtigungskonzept werden die Rechte direkt an die Nutzer vergeben. Dadurch ist lediglich eine sehr feingranulare Rechtezuweisung möglich, so dass diese genau auf die Benutzer abgestimmt werden kann. Benutzergruppen oder -rollen werden jedoch nicht verwendet. Dies beeinträchtigt insbesondere die Administrierbarkeit und die Nachvollziehbarkeit der Rechtevergaben von Systemen mit vielen Nutzern und kann darüber hinaus zu Inkonsistenzen führen. Im betriebswirtschaftlichen Umfeld ist insbesondere die ineffiziente Administration und mangelhafte Nachvollziehbarkeit des Ansatzes bei steigender Nutzerzahl zu berücksichtigen. Das einfache Aggregationskonzept verwendet Rollen und Gruppen um Rechte zuzuweisen. Eine explizite Verknüpfung von Gruppen und Rollen mit Benutzern findet bei diesem Ansatz nicht statt. Dadurch wird eine Benutzeranonymität ermöglicht, die diesen Ansatz hinsichtlich der Vertraulichkeit fragwürdig erscheinen lässt. Durch die Verwendung von Aggregationskonzepten ist die Nachvollziehbarkeit, Konsistenz und Administrierbarkeit der Rechtevergaben auch bei steigenden Nutzerzahlen noch gewährleistet. Das nutzerorientierte Aggregationskonzept sieht eine flexible Rechtevergabe sowohl über Nutzer als auch über Aggregationskonzepte vor. Hierdurch kann die Rechtevergabe auf unterschiedlichen Granularitätsstufen erfolgen, so dass eine effiziente Pflege und Administration der Rechte gewährleistet ist. Die Möglichkeit der Rollen- und Gruppenverwendung sichert auch bei steigender Nutzerzahl die Nachvollziehbarkeit der Rechtevergaben. Die dadurch gewährleistete Transparenz und die effizienten Pflegemöglichkeiten wirken sich ihrerseits positiv auf die Vertraulichkeit aus.

18

Das Kriterium „Erweiterbarkeit, Flexibilität“ ist in Abschnitt 3.2 nicht als konzeptionelles sondern als technisches Kriterium definiert.

Vertraulichkeit

Administration

Aufwand, Kosten



154

Nutzerorientiertes Berechtigungskonzept

+

+

O

O

Einfaches Aggregationskonzept

+++

O

+++

+++

Nutzerorientiertes Aggregationskonzept

+++

+++

+++

++

Durchgängigen Aggregationskonzept

+++

+++

+++

++

Legende:

Tab. 6:

+++ erfüllt ++ weitgehend erfüllt

+ kaum erfüllt

O nicht erfüllt

Zusammenfassende Bewertung der Zugriffskontrollansätze aus der Praxis

Beim durchgängigen Aggregationskonzept ist die direkte Vergabe von Rechten an Nutzer nicht möglich. Dadurch bleibt vor allem in grossen Systemen gewährleistet, dass die direkte Vergabe von Rechten an Nutzer nicht überhand nimmt und ein System nicht an Transparenz und Sicherheit verliert. Die alleinige Verwendung von Rollen kann jedoch insbesondere bei zu definierenden Ausnahmen einen höheren Administrationsaufwand nach sich ziehen, da ggf. erst eine Rolle angelegt werden muss, um einen bestimmten Zugriff zu ermöglichen.

5.2

Ansätze zur systemübergreifenden Integration der Zugriffskontrolle

Die Schwierigkeiten bei der Integration von Sicherheitskomponenten unterschiedlicher Systeme bestehen vor allem in der Existenz von systemspezifischen Rechten und Aggregationskonzepten. Selbst wenn ein Werkzeug zur Verfügung steht, das die systemübergreifende Rechteverwaltung in diesem einen Werkzeug („Single Point of Administration“) ermöglicht, bedeutet dies nicht, dass die systemspezifischen Sicherheitsregelungen systemübergreifend betrachtet in einem konsistenten Zustand sind. Die Überlegungen des folgenden Abschnitts fokussieren daher auf konzeptio-


155

nelle, logische Möglichkeiten der Integration und weniger auf organisatorische oder technische Aspekte. Im Rahmen der Projektarbeit wurden zwei Möglichkeiten diskutiert, wie eine Integration der Zugriffskontrollmechanismen mehrerer Systeme erfolgen kann:

Nutzerorientierte Integration

Aggregationskonzeptorientierte Integration

Nutzer

Aggregationskonzept Integrationsgegenstand

Abb. 15: Ansätze zur systemübergreifenden Integration der Zugriffskontrolle

Als Diskussionsgrundlage wurde dabei die systematische und umfassende Verwendung von Rollen und Gruppen in den zu integrierenden Systemen vorausgesetzt. Exemplarisch wird im Folgenden deshalb die Existenz des durchgängigen Aggregationskonzepts in den zu integrierenden Systemen zugrunde gelegt. Ohne die Diskussionsergebnisse zu beeinflussen könnte auch das nutzerorientierte Aggregationskonzept verwendet werden. Die beiden Ansätze können anhand ihres Integrationsgegenstands unterschieden werden: Der Integrationsgegenstand legt fest, welche Entität Ausgangspunkt der Integrationsbestrebungen ist. Es existieren zwei potentielle Anknüpfungspunkte. Zum einen der Nutzer, zum anderen das Aggregationskonzept.

5.2.1 Nutzerorientierte Integration Eine zentrale Herausforderung bei der Integration von Sicherheitskomponenten ist die Tatsache, dass ein Nutzer in den unterschiedlichen Systemen durch je einen Systemnutzer repräsentiert wird. Dies führt zu dem Problem, dass ein Benutzer unterschiedliche Systemnutzernamen mit zugeordneten Passwörtern verwalten muss. Für diese Fragestellung existieren heute zentrale Identitäts- und Authentisierungslösungen z.B. auf LDAPBasis. Eine weitere Herausforderung liegt in der Schaffung von Transparenz. Teilweise ist in der Praxis völlig unklar welcher Nutzer auf welche Systeme überhaupt zugreifen darf und welche Rechte er in diesem System hat.

156


Um das Transparenzproblem zu lösen, stellt die nutzerorientierte Integration (siehe Abb. 16) eine explizite Beziehung zwischen dem zentral vorgehaltenen Benutzer und seinen Rollen bzw. Gruppen in den einzelnen Systemen her. Dadurch ist ein zentraler Administrator in der Lage zu erkennen, welcher Benutzer auf welche Systeme zugreifen darf und welche systemspezifischen Rollen bzw. Gruppen er innehat. Durch die in gewachsenen Unternehmungen übliche hohe Systemanzahl und die systemspezifischen Gruppen und Rollen, die für Nichtsystemspezialisten nur schwer durchschaubar sind, ist jedoch noch immer kein integriertes Sicherheitsmanagement erzielbar. Beispielsweise kann die Frage welcher Nutzer welche Kompetenzen in welchem System hat auf Basis dieser Lösung nicht wirklich beantwortet werden, da die Semantik der systemspezifischen Rollen- und Gruppenbezeichnungen in der Regel nur für entsprechende Systemspezialisten erschliessbar ist. Ebenfalls nicht beantwortbar ist somit die Frage, ob die vergebenen Rechte angemessen und systemübergreifend konsistent sind.

Zentrales Repository

Nutzer (1)

(n)

(1)

(n)

Systemnutzer

System A

(n)

(n)

(n) S.aggregations-

(n)

konzept

(n)

Systemrolle

Systemrecht

(n)

Systemgruppe

d,t

Abb. 16: Nutzerorientierte Integration

Abb. 16 veranschaulicht die nutzerorientierte Zugriffskontrolle. Die Beziehung zwischen den Entitäten Nutzer und Systemnutzer repräsentiert die zentrale Identitäts- und Authentisierungslösung. Die Beziehung zwischen den Entitäten, Nutzer und Systemaggregationskonzept ermöglicht die diskutierte eingeschränkte Lösung des Transparenzproblems.


157

5.2.2 Aggregationskonzeptorientierte Integration Um das Problem der Transparenz zu lösen, setzt die aggregationskonzeptorientierte Integration auf fachlicher Ebene an. Die zentrale Idee des Konzepts ist, dass ein Mitarbeiter im Unternehmen die Rechte in den Systemen zugewiesen bekommt, die er aufgrund seiner Stellung bzw. Funktion im Unternehmen benötigt. Somit gilt es, ausgehend von den Stellen einer Unternehmung, systemunabhängige Rollen und Gruppen abzuleiten. Diesen systemunabhängigen Aggregationskonzepten werden dann die entsprechenden Rollen und Gruppen in den Systemen zugeordnet. Die geschilderte Vorgehensweise schafft in zweierlei Hinsicht Transparenz: • Es wird ersichtlich, welcher Mitarbeiter welche Stelle im Unternehmen einnimmt. • Es wird ersichtlich, welche Stellen zu welchen Systemberechtigungen führen. Durch die Kombination beider Aspekte wird es darüber hinaus möglich, nachzuhalten, wer welche Systemberechtigungen innehat. Abb. 17 stellt die aggregationskonzeptorientierte Integration dar. Die Beziehung zwischen den Entitäten Nutzer und Systemnutzer repräsentiert auch hier wieder die zentrale Identitäts- und Authentisierungslösung. Neu ist hingegen die Einführung der Entität Aggregationskonzept, die letztendlich die Brücke zu den Rollen und Gruppen auf Systemebene schlägt.

Zentrales Repository

Nutzer

(n)

(n) (n) Aggregations-

(n) d,t

konzept

(1)

Rolle

(n) Gruppe

(n)

(1) Systemnutzer

System A

(n)

(n)

(n) S.aggregations-

(n)

konzept

(n)

Systemrolle

Systemrecht

(n)

Systemgruppe

d,t

Abb. 17: Aggregationskonzeptorientierte Integration

158


Überträgt man die aggregationskonzeptorientierte Integration in die Praxis, so kann aus dem Modell mit zwei Ebenen ein Modell mit drei Ebenen konstruiert werden: Zentral Zentrales Rollen und Rechtemgmt

Domäne

System

Domäne 1: DWH

Systemrolle Recht

Domänenrolle System Systemrolle [FK]

DB Systemrolle Recht

User Systemunabhängige Rolle Systemunabhängige Rolle [FK] Domäne Domänenrolle [FK]

OLAP

… Domäne n

Systemrolle Recht Domänenrolle System Systemrolle [FK]

System 1 Systemrolle Recht

System s

Abb. 18: Zweistufige aggregationskonzeptorientierte Integration

Neben einer zentralen Ebene und der Systemebene existieren in der Praxis für gewöhnlich Systemverbünde, die auch Domänen genannt werden und aus mehreren Systemen bestehen. Ein Beispiel hierfür ist der Data Warehouse Systemverbund. Ein Data Warehouse Systemverbund besteht unter anderem aus einer oder mehreren Datenbanken, aus ETL- und aus OLAPWerkzeugen. Um einen Systemverbund sicherheitstechnisch zu managen, existieren bereits heute zentrale Rechtemanagementsysteme (vgl. auch im Folgenden Rupprecht 2003, S. 134 f.). Diese Systeme sind meist proprietär und arbeiten auf der Basis von systemunabhängigen, domänenspezifischen Rollen und Gruppen wie z.B. „DWH-Administrator“. Soll ein neuer Nutzer als „DWH-Administrator“ aufgenommen werden, so wird dies im Systemverbundsrepository vermerkt. In einem Batchlauf werden die neuen Sicherheitseinstellungen anschliessend in die jeweiligen Systeme der Domäne übernommen. Um die Systemverbünde zu integrieren, ist es nun möglich, ein zentrales, fachlich ausgerichtetes Repository in der oben diskutierten Weise einzusetzen (vgl. Abbildung 18).


159

5.2.3 Bewertung der Integrationsansätze Die vorgestellten Ansätze zur Integration der unterschiedlichen Sicherheitskomponenten werden im Folgenden gemäss den Anforderungen und Kriterien aus Abschnitt 3.2 bewertet (siehe Tab. 7). Da es sich bei den hier diskutierten Zugriffskontrollansätzen um logisch, konzeptionelle Ansätze handelt, wird die Anforderung „Verfügbarkeit, Robustheit“ bei der Diskussion nicht berücksichtigt.

Legende:

Tab. 7:

+++ erfüllt

Administration

Erweiterbarkeit

Aufwand, Kosten

Aggregationskonzeptorientierte Integration

Vertraulichkeit

Nutzerorientierte Integration


Die nutzerorientierte Integration stellt eine explizite Beziehung zwischen dem zentral vorgehaltenen Benutzer und seinen Rollen bzw. Gruppen in den einzelnen Systemen her. Dadurch wird transparent, welcher Nutzer auf welche Systeme zugreifen darf und welche Rollen er in diesen Systemen innehat. Bei einer steigenden Anzahl von Nutzern sinkt jedoch die Nachvollziehbarkeit der Gesamtlösung. Dies wirkt sich auch negativ auf die Konsistenz und Vertraulichkeit des Gesamtsystems aus. Auch die Administration gestaltet sich nicht sehr effizient. Soll beispielsweise ein neuer Call-Center-Mitarbeiter in den entsprechenden Systemen die notwendigen Systemrollen zugewiesen bekommen, so muss dies in jedem einzelnen System manuell nachgepflegt werden. Insbesondere die durch das Beispiel veranschaulichte aufwändige Administration treibt die Gesamtkosten der Lösung in die Höhe. Die Einbindung neuer Sicherheitskomponenten in die diskutierte Lösung gestaltet sich hingegen vergleichsweise einfach, da lediglich die Gruppen- und Rollenzugehörigkeiten der einzelnen Nutzer in das zentrale Repository eingefügt werden müssen.

+

++

+

++

+

+++

+++

+++

++

++

++ weitgehend erfüllt

+ kaum erfüllt

O nicht erfüllt

Zusammenfassende Bewertung der Integrationsansätze

Die aggregationskonzeptorientierte Integration arbeitet auf zentraler Ebene mit systemunabhängigen Gruppen und Rollen. Angewendet auf das CallCenter-Mitarbeiter-Beispiel bedeutet dies, dass eine Gruppe bzw. Rolle

160


„Call-Center-Mitarbeiter“ im zentralen Repository existiert. Sollen die Call-Center-Mitarbeiter in den Systemen neue Rollen erhalten, so müssen lediglich dem zentralen Aggregationskonzept Call-Center-Mitarbeiter die neuen Systemrollen zugewiesen werden. Die Änderungen wirken sich auf alle Nutzer des Aggregationskonzepts Call-Center-Mitarbeiter aus. Die Administration wird somit im Vergleich zum zuvor diskutierten Ansatz effizienter, was sich positiv auf die Gesamtkosten der Lösung auswirkt. Durch die Einführung von Rollen und Gruppen auf zentraler Ebene wird zudem die Transparenz des Gesamtsystems erhöht, was letztendlich auch eine bessere Konsistenz und Vertraulichkeit über Systemgrenzen hinweg fördert. Der initiale Aufwand, ein neues System in diese Lösung einzufügen, ist als hoch einzuschätzen. Zwischen den Rollen und Gruppen des neu einzufügenden Systems und den zentral existierenden Rollen und Gruppen gilt es zuerst einmal Beziehungen herzustellen.

5.3

Ansätze zur Integration der Zugriffskontrolle in mehrschichtigen Systemen

Eine weitere bedeutende Fragestellung im Kontext der Integration von Sicherheitskomponenten ist die Verkettung von Rollen und Gruppen über unterschiedliche Softwareschichten hinweg. App. 1

Application Layer

Servlet

Servlet

EJB

EJB

EJB

EJB

Service

Service Layer

Service

Servlet

EJB EJB

Service Service

App. 2

EJB

Service Service

Service

Backend Layer

Abb. 19: Drei-Schichten-Plattform für die Entwicklung von Applikationen


161

Abbildung 19 veranschaulicht die Problemstellung anhand einer typischen Plattform für die Entwicklung von Software auf der Basis von J2EE. Die Plattform enthält folgende Schichten: • Backend Layer: Der Backend Layer umfasst die Legacy-Systeme, die insbesondere in Grossunternehmen immer noch den Hauptanteil der fachlichen Funktionalität zur Verfügung stellen. • Service Layer: Der Service Layer stellt die Funktionalität der BackendSysteme z.B. in Form von Corba Services zur Verfügung. • Application Layer: Der Application Layer bündelt die Geschäftslogik, die in diesem Beispiel in Form von Enterprise Java Beans realisiert ist, zu Applikationen zusammen. Die Präsentationslogik der einzelnen Applikationen wird durch Servlets realisiert. Sicherheitstechnisch stellen sich bei diesem Beispiel zwei wesentliche Fragen: • Auf welcher Ebene ist ein eigenes Sicherheitsmanagement notwendig? • Wie können Sicherheitslösungen unterschiedlicher Ebenen integriert werden? Durch die gewachsenen Strukturen in den Unternehmen verfügt der Backend Layer in der Regel über ein eigenes Sicherheitsmanagement. Normalerweise enthält jede Applikation ebenfalls ein Sicherheitsmanagement, da beispielsweise bestimmte Funktionalitäten erst gar nicht für alle Anwender in der Benutzeroberfläche sichtbar sein sollen. Somit sind üblicherweise wenigstens zwei Ebenen sicherheitstechnisch aufeinander abzustimmen. Im Rahmen der durchgeführten Projektarbeit wurden zwei Möglichkeiten identifiziert, wie eine Integration der Zugriffskontrolle in mehrschichtigen Systemen realisiert werden kann (siehe Abb. 20). Als Diskussionsgrundlage wurde auch hier die Existenz des durchgängigen Aggregationskonzepts in den zu integrierenden Systemen zugrunde gelegt.

162


Horiziontale Integration

Vertikale Integration

Horizontal

Vertikal Integrationsrichtung

Abb. 20: Ansätze zur Integration der Zugriffskontrolle in mehrschichtigen Systemen

Die beiden Ansätze unterscheiden sich durch die eingeschlagene Integrationsrichtung: Die Integrationsrichtung determiniert wie die unterschiedlichen Autorisierungssysteme integriert werden. Bei dem vertikalen Konzept knüpft jedes der zu integrierenden Zugriffskontrollsysteme an ein übergelagertes zentrales Repository an. Das horizontale Lösungsszenario richtet sich hingegen auf eine bilaterale Integration der unterschiedlichen Systeme aus.

5.3.1 Vertikale Integration Der Ansatz, der die vertikale Integration in mehrschichtigen Systemen leistet, ist die bereits diskutierte aggregationskonzeptorientierte Integration. Die Anwendung dieses Konzepts in Bezug auf die Ebenenproblematik zeigt Abbildung 21.


163

Rolle

Gruppe

Schicht n+1: System B Systemrecht

d,t

Systemnutzer

S.aggregations- (n)

(n)

(n)

(n)

Systemrolle

d,t

Systemrolle

(n) (n)

(n) konzept

(n) Aggregations-

(n)

d,t

konzept

(n)

(n)

Systemnutzer

(n)

(n)

(n) S.aggregations-

Nutzer

(n)

(n) Zentrales Repository

Systemgruppe

(n)

konzept

Systemrecht

(n) (n)

(n)

Schicht n: System A

Systemgruppe

Abb. 21: Vertikale Integration zur Lösung der Ebenenproblematik

Die Systemgruppen und -rollen auf den unterschiedlichen Ebenen werden über die Gruppen und Rollen auf zentraler Ebene integriert. Die Abstimmungsarbeit findet also nicht zwischen den jeweiligen Systemen statt, sondern zwischen den Systemen einerseits und dem zentralen Repository andererseits. Nachteil dieses Ansatzes ist, dass die direkte Rollenzuordnung von höher gelegener zu tiefer gelegener Ebene nicht unterstützt wird. So ist es beispielsweise nicht möglich, die Rolle „Call-Center-MitarbeiterDeutsch“ der Applikation „Call-Center“ direkt mit den Rollen „LesenSchreiben-Deutschland“, „Lesen-Schreiben-Östereich“ und „Lesen-Schreiben-Schweiz“ des Kundenbackendsystems zu verknüpfen.

5.3.2 Horizontale Integration Eine direkte Verknüpfung von Rollen erlaubt die in Abbildung 21 vorgestellte horizontale Integration. Zwischen den Gruppen und Rollen der einzelnen Systeme werden direkt Beziehungen hinterlegt. Es bieten sich drei Möglichkeiten an, diese Beziehung zu verwalten: • Innerhalb des jeweiligen Systems der höher liegenden Schicht • Innerhalb des jeweiligen Systems der tiefer liegenden Schicht • Innerhalb eines zentralen Repository

164


Schicht n: System A

Schicht n+1: System B

Insbesondere weil bei einer unternehmensweiten Anwendung der Überblick über das Gesamtsystem verloren geht, ist der Ansatz, die Beziehungen in einem der beteiligten Systeme zu unterhalten, als problematisch anzusehen. Nur durch die Verwendung eines zentralen Repository zum Management der Rechte- und Gruppenbeziehungen zwischen den Systemen kann beispielsweise systemübergreifend festgestellt werden, welcher Benutzer auf welche Systeme mit welchen Rollen zugreifen darf.

(n) Systemnutzer

(n)

(n) S.aggregations-

(n)

konzept

(n)

Systemrecht

(n)

(n) d,t


(n) Systemnutzer

(n)

(n) S.aggregations-

(n)

konzept

(n)

Systemrecht

(n)

(n) d,t


Repository

Abb. 22: Horizontale Integration zur Lösung der Ebenenproblematik

5.3.3 Bewertung der Integrationsansätze Die vorgestellten Ansätze zur Integration der unterschiedlichen Sicherheitskomponenten werden im Folgenden gemäss den Anforderungen und Kriterien aus Abschnitt 3.2 bewertet (siehe Tab. 8). Da es sich bei den hier diskutierten Zugriffskontrollansätzen wie im vorherigen Kapitel um logisch, konzeptionelle Ansätze handelt, wird die Anforderung „Verfügbarkeit, Robustheit“ bei der Diskussion nicht berücksichtigt.

Administration

Horizontale Integration Legende:

Tab. 8:

Aufwand, Kosten

Vertraulichkeit

+++

+++

+++

++

++

++

++

++

++

++


Vertikale Integration

165

Erweiterbarkeit


+++ erfüllt ++ weitgehend erfüllt + kaum erfüllt O nicht erfüllt

Zusammenfassende Bewertung der Integrationsansätze

Die horizontale Integration ist identisch mit dem bereits diskutierten Ansatz der aggregationskonzeptorientierten Integration und arbeitet somit wie diese auf zentraler Ebene mit systemunabhängigen Gruppen und Rollen. Daher weisst sie im Kontext der Integration von Zugriffskontrollkomponenten in mehrschichtigen Systemen die gleichen Eigenschaften auf wie die aggregationskonzeptorientierte Integration im Kontext der systemübergreifenden Integration. Die vertikale Integration realisiert die Verkettung von Rollen und Gruppen über unterschiedliche Softwareschichten hinweg, indem sie jeweils zwei Systeme miteinander verknüpft. Damit zielt die vertikale Integration nicht darauf ab, alle Sicherheitskomponenten systemübergreifend zu verknüpfen. Vielmehr geht es darum, Gruppen und Rollen von aufeinander aufbauenden Softwaresystemen zu integrieren. Der gewählte Ansatz, die Verknüpfung jeweils zwischen zwei Systemen vorzunehmen, ist allerdings kritisch zu beurteilen. Insbesondere bei einer steigenden Anzahl von Verknüpfungen kann der Überblick über die Gesamtsicherheitslandschaft verloren gehen. Zu erwarten ist, dass sich dies negativ auf die Konsistenz, Vertraulichkeit und Administrierbarkeit der Gesamtlösung auswirkt. Diese Aspekte treiben wiederum die Kosten und den Aufwand der Gesamtlösung in die Höhe. Da bei dem hier diskutierten Ansatz bilaterale Lösungen geschaffen werden, ist der initiale Aufwand für eine neu einzurichtende Verknüpfung als moderat anzusehen.

166

6


Zusammenfassung und Forschungsbedarf

Heterogene Applikationslandschaften werden von einem grossen Anwenderkreis genutzt. Die verschiedenen Anwender und Benutzergruppen besitzen jedoch sehr unterschiedliche Berechtigungen für die vorhandenen Ressourcen. Deshalb wird in dieser Arbeit vertiefend auf die Sicherheitsfunktion „Zugriffskontrolle“ eingegangen. Anhand von Anforderungen und Bewertungskriterien aus der Praxis wurden unterschiedliche Modelle und Integrationsansätze im Hinblick auf ihre Eignung im Umfeld von heterogenen Systemlandschaften beurteilt. Der rollenbasierte Ansatz wurde insbesondere aufgrund seiner Flexibilität und Eignung für das betriebswirtschaftliche Umfeld sowie seiner systemweiten Sicherheitsstrategie als beste Lösung ermittelt. Er sollte mit Hilfe einer Remote-AdministrationsKomponente in die heterogene Landschaft integriert werden. Der letzte Teil der Arbeit ergänzt den eher theoriegeleiteten Vergleich mit Erkenntnissen aus der Praxis. Im Rahmen der Diskussion stellte sich die durchgängige Zugriffskontrolle als empfehlenswertes Konzept heraus. Die systemübergreifende Integration unterschiedlicher Zugriffskomponenten sollte auf der Basis der aggregationskonzeptorientierten Integration realisiert werden. In mehrschichtigen Systemen bietet sich die vertikale Integration als Integrationsansatz an. Weiterer Forschungsbedarf im Bereich der unternehmensweiten Zugriffskontrolle ergibt sich unter anderem hinsichtlich der organisatorischen Ausgestaltung der unternehmensweiten Administration der Sicherheitskomponenten. Hierbei sind folgende zentrale Fragestellungen zu beantworten: • Welche administrativen Verantwortlichkeitsbereiche sollten gebildet werden? • Wie kann die Administration durch technische Lösungen und Konzepte unterstützt werden? Ein weiterer Aspekt, den es zu untersuchen gilt, ist die Bildung und der Unterhalt von Rollen und Gruppen im Unternehmen. Zentrale Herausforderungen in diesem Bereich sind: • Nach welchen Gesichtspunkten sind Rollen zu bilden? • Wie kann die Rollenanzahl auf einem akzeptablen Niveau gehalten werden? Die Integration von Sicherheitskomponenten durch systemübergreifende Rollen und Gruppen bietet nicht nur die Möglichkeit zur substantiellen


167

Verbesserung der Sicherheit im Unternehmen, sondern auch Effizienzsteigerungspotenzial, das insbesondere durch einen höheren Automationsgrad im Bereich Administration zu erzielen ist.

Literatur Bauer, A.; Günzel, H. (Hrsg.): Entwicklung, Heidelberg, 2001.

Data-Warehouse-Systeme:

Architektur,

Bell, D.; LaPadula, L.: Secure Computer Systems: Mathematical Foundations, MTR-2547, Volume I +II, MITRE Corporation, Bedford, 1973. Biba, K.: Integrity Considerations for Secure Computer Systems, MTR-3153, MITRE Corporation, Bedford, 1977. Ferraiolo, D.; Cugini, J.; Kuhn, D.: Role-Based Access Control (RBAC): Features and Motivations, Computer Security Applications Conference, 1995, http://hissa.ncsl.nist.gov/rbac/newpaper/rbac.ps, Abruf am 2002-06-12. Fischer-Hübner, S.: IT-Security and Privacy – Design and Use of PrivacyEnhancing Security Mechanisms, Berlin et al., 2001. Gerhardt, W.; Pohl, H.; Spruit, M.: Informationssicherheit in Data Warehouses, in: Mucksch, H.; Behme, W. (Hrsg.): Das Data Warehouse-Konzept, 4. vollständig überarbeitete und erweiterte Aufl., Wiesbaden, 2000. Lau, B.; Gerhardt, W.: Ein rollenbasiertes unternehmensbezogenes Rechteverwaltungs-Paradigma, in: Bauknecht, K.; Teufel, S. (Hrsg.): Sicherheit in Informationssystemen, Zürich, 1994. Jonscher, D.; Dittrich, K.: Realisierung von Sicherheitsstrategien mit Hilfe flexibler Zugriffskontrollmechanismen, in: Bauknecht, K.; Teufel, S. (Hrsg.): Sicherheit in Informationssystemen, Zürich, 1994. Mänkeberg, A.: Datensicherheit, -schutz und Autorisierung, Vortrag auf dem 3. CC DW2-Workshop Datenschutz und Datensicherheit im Data Warehousing“, Augsburg, 2001. Mänkeberg, A.; Rakete, R.: Three for one – Role-based Access-Control Management in Rapidly Changing Heterogenous Environments, in: Fifth ACM Workshop on Role-based Access Control, ACM, New York, 2000, S. 83-88. Oppliger, R.: IT-Sicherheit – Grundlagen und Umsetzung in der Praxis, Braunschweig, 1997. O.V.: IT-Sicherheitskriterien, Bundesamt für Sicherheit in der Informationstechnik (BSI), 1989, http://www.bsi.bund.de/zertifiz/itkrit/itgruend. pdf, Abruf am 2002-03-25.

168


Pipkin, D.: Information Security – Protecting the Global Enterprise, Upper Saddle River, 2000. Pernul, G.: Information Systems Security: Scope, State-of-the-art, and Evaluation of Techniques, Intl. Journal of Information Management 15 (1995), 3, S. 239255. Pfleeger, C.: Security in Computing, Upper Saddle River, 1997. Rupprecht, J.: Zugriffskontrolle im Data Warehousing, in: von Maur, E.; Winter, R. (Hrsg.): Data Warehouse Management, Berlin et al., 2003. Samarati, P.; de Capitani di Vimercati, S.: Access Control: Policies, Models and Mechanisms, in: Focardi, R.; Gorrieri, R.(Hrsg.): Foundations of Security Analysis and Design – Tutorial Lectures, Berlin et al., 2002. Sandhu, R.: Roles versus Groups, in: First ACM Workshop on Role-based Access Control, ACM, New York, 1995, S. 25-26. Sandhu, R.; Bhamidipati, V.; Munawer, Q.: The ARBAC97 model for role-based administration of roles, ACM Transactions on Information and Systems security 2 (1999) 1, S. 105-135. Sandhu, R.: Engineering Authority and Trust in Cyberspace: The OM-AM and RBAC Way, in: Fifth ACM Workshop on Role-based Access Control, ACM, New York, 2000, S. 111-119. Seufert, S.: Die Zugriffskontrolle, Dissertation Otto-Friedrich-Universität Bamberg, Bamberg, 2001.

Integrationsinfrastrukturen in der Finanzdienstleistungsbranche: Ergebnisse einer Studie Felix Wortmann Universität St. Gallen

Die grossen Unternehmen der Finanzdienstleistungsbranche zeichnen sind durch gewachsene heterogene Systemlandschaften aus. Die unterschiedlichen Applikationen der Systemlandschaften flexibel und zuverlässig zu verknüpfen, ist die Aufgabe von Integrationsinfrastrukturen. Im Rahmen der hier präsentierten Studie sollen diese Infrastrukturen näher analysiert werden. Zum einen wird dabei der Frage nachgegangen, welche Rahmenbedingungen bei der Gestaltung von Integrationsinfrastrukturen zu beachten sind. Zum anderen wird erforscht, welche Entwicklungen sich im Bereich Integrationsinfrastrukturen in der Finanzdienstleistungsbranche abzeichnen.

1 2

3

4

5

Ziele, Vorgehensweise und Aufbau der Studie............................... 170 Analyse der Applikationslandschaften............................................ 171 2.1 Ist-Situation.............................................................................. 172 2.2 Entwicklungen ......................................................................... 178 Analyse der Eigenentwicklungen.................................................... 182 3.1 Präsentationslogik.................................................................... 182 3.2 Geschäftslogik ......................................................................... 184 3.3 Datenzugriffslogik ................................................................... 188 Analyse der Integrationsinfrastrukturen.......................................... 192 4.1 Anforderungen an Integrationsinfrastrukturen......................... 192 4.2 Ist-Situation und Entwicklungen.............................................. 194 Zusammenfassung und Erkenntnisse der Studie............................. 199

170

1

F. Wortmann

Ziele, Vorgehensweise und Aufbau der Studie

Ziel der hier präsentierten Studie ist es, Entwicklungen in Applikationslandschaften zu erfassen, die sich auf Integrationsinfrastrukturen auswirken. Darüber hinaus sollen die geplanten Entwicklungen von Integrationsinfrastrukturen aufgezeigt werden. Die Studie konzentriert sich auf Unternehmen des Finanzdienstleistungssektors. Im Zentrum stehen des Weiteren technische Fragestellungen. Betriebswirtschaftliche Aspekte werden insofern berücksichtigt, als dass sie im Sinne von Anforderungen an Integrationsinfrastrukturen im Zuge der Studie erfasst werden. Die Studie wurde im Zeitraum Mai bis Dezember 2003 durchgeführt. Die Durchführung gliederte sich in zwei Phasen. In der ersten Phase wurde auf der Basis einer Literaturanalyse und der Diskussion mit Rückversicherer B ein Fragebogen entworfen. In der zweiten Phase wurden Interviews mit Firmenvertretern von sechs Unternehmen durchgeführt. Folgende Banken nahmen an der Studie teil: • Bank A, Bereich IT-Architektur und Standards • Bank B, Bereich IT-Architektur Folgende Rückversicherer nahmen an der Studie teil: • Rückversicherer A, Bereich IT-Strategie • Rückversicherer B, Bereich IT-Standards und Architektur Folgende Versicherer nahmen an der Studie teil: • Versicherung A, Bereich IT-Architektur • Versicherung B, Bereich IT-Strategie and Architektur Alle befragten Unternehmen sind europäischen Ursprungs. Bei vier der sechs Unternehmen handelt es sich um weltweit tätige Unternehmen, die zu den führenden Unternehmen in ihrem Markt gehören. Die anderen beiden befragten Unternehmen sind Marktführer in einem oder mehreren europäischen Ländern. Die Interviews mit den aufgeführten Unternehmen wurden bei den jeweiligen Unternehmen vor Ort durchgeführt. Hierbei wurde ein strukturierter Fragebogen verwendet, der jedoch aufgrund der eingeschränkten Teilnehmerzahl und der individuellen Verschiedenheit der Unternehmen nicht statistisch ausgewertet werden soll.

Integrationsinfrastrukturen in der Dienstleistungsbranche

171

Die Studie beginnt mit einer Analyse der Applikationslandschaften der teilnehmenden Unternehmen, wobei insbesondere die verwendete Standardsoftware untersucht wird. Anschliessend erfolgt die Analyse der Eigenentwicklungen der Unternehmen. Eine Erfassung der Entwicklungen im Bereich der Integrationsplattformen bildet den Abschluss der Studie. Ein wesentlicher Teil der in dem vorliegenden Bericht präsentierten Ergebnisse beruht auf der Auswertung von Einschätzfragen, die für die Befragten zum Teil nur schwer zu beantworten sind. Einzelne Antworten gilt es daher mit besonderer Vorsicht im Kontext aller gegebenen Informationen eines Unternehmens zu bewerten. Ein Vergleich der Unternehmen kann aufgrund dessen nur eingeschränkt vorgenommen werden. Insbesondere gilt es zu berücksichtigen, dass die Aussagen über das jeweilige Unternehmen in den meisten Fällen lediglich von einem befragten Vertreter des Unternehmens stammen. Diese Studie bietet somit kein konsolidiertes Bild der befragten Unternehmungen. Die Ausführungen der Studie erfassen nur wesentliche Aspekte zu den gestellten Fragen. So kann zum Beispiel bei der Frage nach den eingesetzten ERP-Systemen lediglich ein ERP-System angegeben sein, obwohl weitere Systeme vorhanden sind, diese jedoch eine stark untergeordnete Stellung im Unternehmen einnehmen.

2

Analyse der Applikationslandschaften

Im Folgenden werden die Ergebnisse der Applikationslandschaften-Analyse der befragten Unternehmen vorgestellt. Die direkt anschliessende IstAnalyse erlaubt es nachzuvollziehen, warum bestimmte Integrationstechnologien heute verwendet werden. Darüber hinaus trägt sie zum Verständnis des Einsatzes zukünftiger Integrationstechnologien bei, da diese auch die Integration der etablierten Systeme zu leisten haben. Die nachfolgende Analyse der Entwicklungen im Bereich der Applikationslandschaften erfolgt in der Absicht, die Rahmenbedingungen, die sich für die Applikationsintegration ergeben, aufzuzeigen. Drei Bereiche werden zum Vergleich der Applikationslandschaften herangezogen. Dies sind im Einzelnen: • Applikationen: In diesem Bereich wird die Situation der geschäfts-

bereichsübergreifenden Standardapplikationen untersucht. Im Detail werden bestehende ERP-, HR-, CRM-, Business-Intelligence-, Dokumentenmanagement- und Kollobarationssyteme analysiert.

172

F. Wortmann

• Grundlegende Dienste/Backend-Komponenten: Dieser Bereich untersucht Backendsoftware wie z.B. verwendete Datenbanken, Betriebssysteme und Applikationsserver. • Applikationsintegration: Dieser Bereich analysiert die Verwendung von

Software zur Applikationsintegration.

2.1

Ist-Situation

Ist-Situation Applikationen Im Bereich der ERP-Systeme verwenden die untersuchten Unternehmen in der Regel ein dominierendes ERP-System. Die implementierten Systeme sind durchweg Standardanwendungen von Drittherstellern. Mehrere Unternehmen verwenden neben dem einen dominierenden System jedoch weitere ERP-Lösungen. Dies ist insbesondere bei Rückversicherer B der Fall. Bank A ausgenommen verwenden alle Unternehmen SAP als ERPSystem. Im Vergleich zu den ERP-Systemen existieren im Bereich der HR-Software auch Eigenentwicklungen. Ansonsten wird auch in diesem Gebiet Standardsoftware von Drittherstellern verwendet. Im Wesentlichen wird auf SAP und Peoplesoft zurückgegriffen. Eine besondere Kategorie bilden die CRM-Systeme. Keines der Unternehmen, die an der Studie teilgenommen haben, verwendet in diesem Bereich Standardsoftware. In allen Unternehmungen existieren Eigenentwicklungen. Einige Unternehmen prüfen derzeit die Einführung von CRM-Standardsoftware. Bank B hat die Einführung von CRM-Standardsoftware bereits geprüft und vorläufig verworfen. Bezüglich der verwendeten Reporting-Systeme lässt sich feststellen, dass die Unternehmen in ihren unterschiedlichen Fachbereichen sehr heterogene Reporting-Systeme einsetzen. Auch von den Business-IntelligenceSystemen, die auf Data Warehouses oder Data Marts aufsetzen, existieren in den einzelnen Unternehmen mehrere Systeme. Vergleicht man die Business-Intelligence- und Reporting-Produkte, die in den untersuchten Unternehmen eingesetzt werden, so fällt auf, dass diese von vielen unterschiedlichen Herstellern produziert worden sind. Dies deutet darauf hin, dass der entsprechende Markt noch keine so hohe Konsolidierung aufweist, wie z.B. der ERP- oder HR-System-Markt. Im Bereich der Dokumentenmanagementsysteme verwendet die Hälfte der untersuchten Untenehmen selbstentwickelte Softwarelösungen. Die ver-


173

wendeten Standardlösungen sind sehr unterschiedlich: Lediglich Documentum wird bei mehr als einem Unternehmen verwendet. Im Bereich Mail und Groupware werden Standardlösungen entweder von IBM Lotus oder Microsoft verwendet. Bei der Versicherung B sind im Augenblick sogar beide Hersteller mit ihrem Produkt vertreten. Banken

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B

Peoplesoft

SAP

SAP

Mehrere

SAP

SAP

Peoplesoft

Peoplesoft, SAP

SAP

Mehrere

SAP

ERP-Systeme Standardsoftware Eigenentwicklung(en) HR-Systeme Standardsoftware

Eigenentwicklung(en) CRM-Systeme Standardsoftware Eigenentwicklung(en)

Cognos

Cognos, SAP

Hyperion, Weitere

Business Intelligence, Reporting Standardsoftware Eigenentwicklung(en)

SAS, Brio

Mehrere

Dokumentenmanagementsysteme Standardsoftware Eigenentwicklung(en)

DocWeb

Microsoft

Microsoft

IXOS, Sharepoint

Documen tum

Microsoft

Lotus

Document um

Mehrere

Kollaboration Standardsoftware Eigenentwicklung(en)

Tab. 1:

Microsoft, Lotus

Standardsoftware im Bereich Applikationen

Fasst man die Beobachtungen zusammen, so lässt sich feststellen, dass in wesentlichen Gebieten der geschäftsbereichsübergreifenden Applikationen Standardsoftware verwendet wird. Es gibt jedoch weiterhin Gebiete in denen Eigenentwicklungen verwendet werden. Dies ist insbesondere bei CRM- und Dokumentenmanagementsystemen der Fall. Ein Quervergleich

174

F. Wortmann

zwischen den Unternehmen zeigt im Bereich der geschäftsbereichsübergreifenden Applikationen keine gravierenden Unterschiede zwischen den Unternehmen. Nur Versicherung A fällt ein wenig durch den verstärkten Einsatz von Eigenentwicklungen auf. Analysiert man nun die Auswirkungen der beschriebenen Beobachtungen (siehe Tab. 1) auf die Integrationsinfrastrukturen, so spielen zwei Aspekte eine wesentliche Rolle. Zum einen existieren in den Unternehmen zahlreiche heterogene Standardsoftwarelösungen. Zum anderen existieren zahlreiche unterschiedliche Eigenentwicklungen. Hieraus folgt: • Integrationsinfrastrukturen sind in den untersuchten Unternehmen unentbehrlich, um eine effiziente Prozessintegration über Systemgrenzen hinweg zu realisieren. • Integrationsinfrastrukturen (insbesondere unternehmensweite) müssen in der Lage sein, mit einer Vielzahl von Standardapplikationen und Eigenentwicklungen zu kommunizieren. • „Die eine“, vollkommen dominierende Unternehmensstandardsoftware wird in naher Zukunft auf keinen Fall Realität, so dass Integrationsinfrastrukturen auch in Zukunft eine gewichtige Bedeutung zukommen wird. Ist-Situation grundlegende Dienste/Backend-Komponenten Im Bereich der Server-Betriebssysteme verwenden alle Unternehmen sowohl eine Host-, eine Unix- und eine Intel-Plattform. Auf der Unix-Plattform wird grösstenteils Solaris als Betriebssystem verwendet. Lediglich Rückversicherer A und Versicherung A verwenden HP-UX bzw. AIX als Unix-Betriebssystem. Im Host-Umfeld wird auf z/Os zurückgegriffen. Im Intel-Umfeld wird Windows verwendet. Dabei ist Windows NT vorherrschend. Windows 2000 wird im Augenblick nur von den Rückversicherungen verwendet. Als Client-Betriebssystem verwenden alle Unternehmen Microsoft Windows. Die angewendeten Versionen verteilen sich gleichmässig über Windows NT, Windows 2000 und Windows XP. Die Unternehmen, die Windows NT verwenden, haben eine Migration ihrer Systeme bereits geplant. Die befragten Unternehmen verwenden in der Regel mehrere Datenbanken. Während im Unix-Umfeld Oracle dominiert, herrscht dagegen im Host-Bereich DB2 vor. Teilweise findet noch eine intensive Nutzung von IMS statt.


175

Für das Data Warehousing wird bei den Unternehmen grösstenteils eine dedizierte Datenbank-Umgebung verwendet. Vier der untersuchten Unternehmen geben Oracle auf der Basis von Unix als Data Warehouse an. Aber auch DB2 auf Unix- und Host-Basis bzw. SAP BW wurden im Rahmen der Studie als Data-Warehouse-Grundlage genannt. Bei den Applikationsservern existieren zwei Gruppen: Zum einen das Microsoft-‚Lager’, das auf die .Net-Umgebung baut. Zum anderen das ‚Java-Lager’, das auf die J2EE-Applikationsserver setzt. Applikationsserver auf der Basis von Java werden bei fünf der sechs Unternehmen verwendet. Als Hersteller dieser Server sind insbesondere Bea und IBM zu nennen. IONA wird bei Versicherung B insbesondere aufgrund der Verwendung von CORBA auch im J2EE-Umfeld eingesetzt. Lediglich Rückversicherer A verwendet einen Applikationsserver auf Microsoft-Basis. Vier der sechs Unternehmen verwenden den entsprechenden Webserver des Applikationsservers. Nur Rückversicherer B und Versicherung B geben als Webserver Apache an. Banken

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B

Betriebssyst. Server

Solaris/Unix WinNT/Intel zOs/Host

Solaris/Unix WinNT/Intel zOs/Host

HP-UX/Unix Win2k/Intel Host

Solaris/Unix Win2k/Intel zOs/Host

AIX/Unix WinNT/Intel zOs/Host

Solaris/Unix WinNT/Intel zOs/Host weitere

Betriebssyst. Client

Windows XP

Windows NT

Windows 2k

Windows XP

Windows XP

Windows 2k

Datenbanken

DB2/Host Oracle/Unix


Oracle/Unix


DB2/Host IMS/Host Oracle/Unix

DB2/Host IMS/Host Oracle/Unix

Data Warehouse

Oracle/Unix

DB2/Unix

SAP BW /Unix

Oracle/Unix

Oracle/Unix


Applikations server

Bea WebLogic

IBM WebSphere

Microsoft .Net

IBM WebSphere

Bea WebLogic

IONA Orbix

Webserver

Bea WebLogic

IBM WebSphere

Microsoft .Net

Apache

Bea WebL. Apache

Apache

Netzwerk, Directory Services

LDAP Active Dir. (in Planung)

LDAP Active Dir. X. 500

Active Directory

Active Directory

LDAP Active Directory

LDAP

Tab. 2:

Standardsoftware im Bereich grundlegende Dienste/Backend-Komponenten

176

F. Wortmann

Im Bereich der Directory Services ist der Standard LDAP weit verbreitet. Nahe liegend ist die intensive Nutzung des Microsoft Active Directory, das fünf der sechs Unternehmen als Directory Service verwenden, da alle Unternehmen Windows Clients verwenden. Fasst man die Beobachtungen aus dem Bereich grundlegende Dienste/ Backend-Komponenten zusammen, so zeigt sich, dass alle Unternehmen die Plattformen Unix, Host und PC/Intel verwenden. Die gravierenden konzeptionellen Unterschiede dieser Plattformen tragen stark zur Heterogenität der Systemlandschaften bei. Darüber hinaus speichert der Grossteil der befragten Unternehmen seine Daten nicht nur in Datenbanken unterschiedlicher Hersteller ab, sondern auch auf unterschiedlichen Betriebssystemplattformen. Auch dieser beobachtete Sachverhalt trägt massgeblich zur Heterogenität der vorhandenen Systemlandschaften bei. Analysiert man nun die Auswirkungen der beschriebenen Beobachtungen (siehe Tab. 2) auf die Integrationsinfrastrukturlandschaft, so können die bereits aufgezeigten Aussagen bzgl. der Rolle von Integrationsinfrastruktur bestätigt und erweitert werden: • Die Rolle von Integrationsinfrastrukturen ist und bleibt bedeutend: Durch die beobachtete Verwendung unterschiedlicher Plattformen ist die Verwendung von Integrationsinfrastrukturen unvermeidbar. Da eine Ablösung einzelner Plattformen nicht geplant ist (siehe Abschnitt 3) werden Integrationsinfrastrukturen auch in Zukunft eine gewichtige Rolle spielen. • Im Bereich der Applikationsserver können zwei Lager unterschieden werden. Auf der einen Seite existiert die etablierte Java- bzw. J2EEUmgebung. Auf der anderen Seite zeigt sich, dass auch die junge Microsoft-Umgebung erste Verwendung in Grossunternehmen findet. Ist-Situation Applikationsintegration Im Bereich der Portale ist die Verwendung von Portalstandardsoftware hoch. Fünf der sechs befragten Unternehmen verfügen über eine dedizierte Portalsoftware. Die Beobachtungen bestätigen den gegenwärtigen Trend, der Portalen als Integrationsinfrastruktur eine gewichtige Rolle zuweist.

Integrationsinfrastrukturen in der Dienstleistungsbranche Banken

177

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B

–

IBM Websphere Portal

mySAP Enterprise Portal

Plumtree Portal

Hyperwave

abaXX Portal

IBM WebSphere MQ Workfl.

–

–

Metro Activision, Sonic BPM

–

IBM WebSphere MQ Workfl.

IBM WebSphere MQ Integr.

Mercator

IBM WebSphere MQ

IBM WebSphere MQ

Microsoft BizTalk

IBM WebSphere MQ, Sonic BPM

SeeBeyond eGate

IBM WebSphere MQ

Object Broker

IONA Orbix

–

–

IONA Orbix

Bea WebL. Eigenentw.

IONA Orbix

Transaction Manager

IMS, CICS

CICS, Tuxedo

–

CICS

IMS

IMS, CICS

Nur im Warehouse

Nur im Warehouse

Nur im Warehouse

Informatica PowerCenter

Nur im Warehouse

Nur im Warehouse

Portale

Business Process Management, Workflow EAISoftware

Message Broker

ETL

Tab. 3:

Microsoft BizTalk

Sonic BPM

Bea WebLogic

IBM WebSphere MQ Integr.

Standardsoftware im Bereich Applikationsintegration

Lediglich drei der befragten Unternehmen geben bei der Frage nach Business-Process-Management- und Workflow-Werkzeugen ein Produkt an. Zwei dieser Unternehmen verwenden ihre Workflowlösungen jedoch sehr eingeschränkt. Diese Ergebnisse stehen im Gegensatz zur Aufmerksamkeit, die diesen Produkten üblicherweise gerade in Praxis und auch in der Wissenschaft zukommt. Alle Unternehmen verwenden eine EAI-Software. Auffällig ist, dass nur Rückversicherer A ein EAI-Produkt aus der gleichen Produktfamilie verwendet, aus der auch der Applikationsserver stammt. Analog zu den Applikationsservern sind auch bei den EAI-Produkten die ‚Lager’ Microsoft und Java zu unterscheiden. Ebenfalls in allen Unternehmen kommen Message Broker zur Anwendung. Wie bei den Applikationsservern und der EAI-Software sind die Produkte wieder vornehmlich auf die Microsoft- oder auf die Java-Umgebung abgestellt. Konsequenterweise verwendet Rückversicherer A somit Microsoft

178

F. Wortmann

BizTalk, während die anderen Unternehmen vor allem auf IBM WebSphere MQ zurückgreifen. Im Bereich der Object Broker kommen in drei Unternehmungen CORBALösungen auf der Basis von IONA zur Anwendung. Versicherung A setzt hier auf Bea WebLogic und eine Eigenentwicklung. Bei den Transaction-Manager-Werkzeugen finden IMS und CICS fast durchgängige Verwendung. Zwei der sechs befragten Unternehmen setzen sogar beide Transaction Manager parallel ein. Bezüglich des Bereichs Applikationsintegration lassen sich somit folgende Aussagen zusammenfassen (siehe auch Tab. 3): • Portale haben bereits heute in den untersuchten Unternehmen eine weite Verbreitung. • Der Einsatz von applikationsübergreifenden Workflow-Lösungen findet nur sehr eingeschränkt statt. • Die eingesetzten Werkzeuge im Bereich EAI-Software und Message Broker können analog zu den Applikationsservern in Microsoft- und Java-orientierte Produkte unterteilt werden. • Es existieren noch intensiv genutzte CORBA-Integrationsinfrastruktu-

ren in drei der sechs befragten Unternehmen.

2.2

Entwicklungen

Um zu verstehen, wie sich die Rahmenbedingungen der Applikationsintegration entwickeln, werden im Folgenden zum einen die IT-Investitionen der befragten Unternehmen, zum anderen die zukünftige Bedeutung von Standard- und selbstentwickelter Software untersucht. Investitionen bis 2006 Zwei der befragten Unternehmen investieren bis 2006 im Bereich Applikationen vor allem in ERP-Systeme (zu den einzelnen Entwicklungen siehe Tab. 4). Insbesondere Rückversicherer A ersetzt zahlreichen Applikationen im Rahmen eines Grossprojektes durch eine Standardlösung. Ebenfalls hohe Investitionen fliessen in die Bereiche Dokumentenmanagement sowie Business-Intelligence und Reporting. Vier der sechs Unternehmen investieren darüber hinaus in Kollaborationslösungen. CRM- und HR-Systeme werden von einzelnen Unternehmen modernisiert und ausgebaut.

Integrationsinfrastrukturen in der Dienstleistungsbranche Banken Bank A

Bank B

Rückversicherungen Rückv. A

Rückv. B

179 Versicherungen Vers. A

Applikationen ERP-Systeme HR-Systeme CRM-Systeme Business Intelligence, Reporting Dokumentenmanagementsysteme Kollaboration Grundlegende Dienste/Backend-Komponenten Datenbanken Data Warehouse Betriebssystem Server Betriebssystem Client Applikationsserver Webserver Netzwerk, Directory Services Sicherheit Überwachung (Monitoring) Werkzeuge zur Applikationsintegration Portale Business Process Management, Workflow EAI-Software Message Broker Object Broker Transaction Manager ETL Legende:

Tab. 4:

sehr hohe Investitionen;

Investitionen bis 2006

hohe Investitionen;

mittlere Investitionen;

Vers. B

180

F. Wortmann

Im Bereich der grundlegenden Dienste/Backend-Komponenten sind die Investitionen vor allem hinsichtlich der Betriebssysteme festzustellen. Insbesondere die Windows-Systeme müssen aufgrund ablaufender Support-Leistungen aktualisiert werden. Ebenfalls wird in Applikationsserver viel investiert, wobei auch hier Releasewechsel hohe Kosten nach sich ziehen. Eine dritte Domäne, in die eines der befragten Unternehmen hohe und zwei weitere geringe bis mittlere Beträge investieren, ist Sicherheit. Im Bereich grundlegende Dienste/Backend-Komponenten sind keine Entwicklungen zu erkennen, die auf eine Homogenisierung der Applikationslandschaft hindeuten. Auffällig ist der relativ hohe Anteil der Releasewechsel an den Gesamtinvestitionen. Zum einen ist dieser Anteil durch die massiven Kosten der Releasewechsel an sich begründet, die vornehmlich im Bereich Windows-Clients erhebliche Ausmasse annehmen. Zum anderen deutet sich damit an, dass die momentane wirtschaftliche Situation auf die Gesamtsumme der IT-Investitionen drückt, so dass umfangreiche Releasewechsel einen bedeutenden Stellenwert einnehmen. Im Bereich der Werkzeuge zur Applikationsintegration findet in erster Linie eine Investition in Portale statt. Der Trend, dieser Integrationstechnologie besondere Aufmerksamkeit zu schenken, setzt sich somit fort. Weniger wird demgegenüber in EAI-Software und Business-Process-Management- bzw. Workflow-Lösungen investiert. Auffällig ist, dass die Unternehmen entgegen der regen Diskussion dieser Technologien in wissenschaftlichen Veröffentlichungen und Fachpresse nur geringfügig in diese Technologien investieren. Vergleicht man die Investitionen in den drei diskutierten Bereichen untereinander, so fällt auf, dass am meisten im Bereich Applikationen investiert wird. Insbesondere die ERP-Systeme werden auch in den nächsten Jahren weiter ausgebaut. In die grundlegenden Dienste/Backend-Komponenten wird bereits deutlich weniger investiert. Auffällig sind hier die angesprochenen Releasewechsel im Bereich Betriebssysteme und Applikationsserver. Am wenigsten Investitionen fliessen in den Bereich Applikationsintegration. Bedeutung von selbstentwickelter Software und Standardsoftware Analysiert man die heutige Bedeutung selbstentwickelter Software, so fällt ihre dominierende Stellung auf (siehe Abb. 1). Alle befragten Untenehmen geben an, dass der Anteil der unternehmensweit implementierten Funktionalität, die durch selbstentwickelte Software abgedeckt wird, zwischen 80 und 90 Prozent liegt. Obwohl diese Frage nur sehr ungenau zu beantworten ist, zeigt sich dennoch, dass die befragten Unternehmen im Wesentlichen selbstentwickelte Software verwenden.


181

100 75 2003

50

2006

25 0 Bank A

Bank B*

Banken

Rückv. A

Rückv. B

Rückversicherungen

Vers. A

Vers. B

Versicherungen * Nur zentral administrierte Systeme

Abb. 1:

Anteil selbstentwickelter Software in Prozent

Als Antwort auf die Frage nach der voraussichtlichen Situation im Jahr 2006 kristallisieren sich zwei Muster heraus. Fünf von Sechs der befragten Unternehmen gehen von einer Reduzierung der selbstentwickelten Software zugunsten von Standardsoftware bis maximal 15 Prozent aus. Lediglich Rückversicherer A will durch die Ausweitung seiner ERP-Lösung eine signifikante Reduzierung von selbstentwickelter Software um bis zu 60 Prozent realisieren. Diese Aussagen können jedoch noch differenzierter betrachtet werden. Die Unternehmen unterscheiden in der Regel einen „Zentralen Bereich“ und einen „Dezentralen Bereich“. Der „Zentrale Bereich“ umfasst die Kernsysteme der Unternehmung, die bei den untersuchten Unternehmungen im Wesentlichen auf dem Host liegen. Diese Applikationen müssen hochverfügbar sein. Sie dienen zur Unterhaltung der wesentlichen Stamm- und Bewegungsdaten. Der „Dezentrale Bereich“ hingegen umfasst die Applikationen der jeweiligen Fachbereiche und die Client-Applikationen wie Officeanwendungen oder Nachrichtendienste wie Bloomberg. Die Funktionalität des „Zentralen Bereichs“ besteht beispielsweise bei Bank B zu 80 Prozent aus selbstentwickelter Software. Der „Dezentrale Bereich“ hingegen besteht nur zu 40 Prozent aus selbstentwickelter Software und somit zu 60 Prozent aus Standardsoftware. Differenzierter betrachtet werden können auch die Entwicklungen. Bank B erwartet keine Erhöhung des Standardsoftwareanteils im „Zentralen Bereich“. Im „Dezentralen Bereich“ hingegen wird eine Steigerung des Standardsoftwareanteils von bis zu 20 Prozent prognostiziert. Welche Bedeutung haben diese Entwicklungen für Integrationsinfrastrukturen? Im „Zentralen Bereich“ bleibt der Anteil selbstentwickelter Soft-

182

F. Wortmann

ware, die vor allem Host-basiert ist, fast konstant hoch. Wichtigste Aufgabe von Integrationsplattformen wird somit auch in Zukunft die Integration von Host-Applikationen in Unix/Linux- und Intel/PC- Umgebungen sowie moderne Java- und .Net-Lösungen sein. Im „Dezentralen Bereich“ deutet sich eine starke Zunahme des Standardsoftwareanteils an. Integrationsinfrastrukturen müssen somit verstärkt in der Lage sein, unterschiedliche Standardsoftware miteinander zu verknüpfen. Darüber hinaus müssen zukünftige Infrastrukturen die effektive und effiziente Zusammenarbeit zwischen Standardsoftware und insbesondere Host-basierten Eigenentwicklungen gewährleisten.

3

Analyse der Eigenentwicklungen

Nachdem im vorherigen Abschnitt insbesondere die heutige und zukünftige Verwendung von Standardsoftware untersucht wurde, soll im Folgenden selbstentwickelte Software untersucht werden. Dabei wird wiederum zu ergründen versucht, wo welche Infrastrukturen aus welchen Gründen verwendet werden und welche Technologien sich in Zukunft wie entwickeln werden.

3.1

Präsentationslogik

Im Umfeld der Präsentationslogik verwenden die Unternehmen verschiedene Technologien um die Clients entsprechend anzusteuern (siehe Tab. 5): • Thin Client: Beim Thin-Client-Konzept erfolgt die grafische Steuerung eines Programms über einen Web Browser. • Fat Client: Beim Fat Client erfolgt die grafische Steuerung eines Programms nicht über einen Browser sondern über Bibliotheken (Laufzeitumgebungen), die lokal auf dem Client installiert sein müssen. Diese Bibliotheken sind in der Regel programmier-sprachen- (z.B. C++, Java) oder plattformspezifisch (z.B. Microsoft .Net). • Host Terminal: Die Steuerung von Hosts erfolgt in den Unternehmen zum Teil noch über Host Terminals, die direkt auf den Host zugreifen. Im Bereich der Thin Clients verwenden die Unternehmen die Technologien analog zu den von ihnen verwendeten Applikationsservern. Für Bank A, Bank B, Rückversicherer B, Versicherung A und Versicherung B be-


183

deutet dies die Verwendung der Java-Servlet- bzw. Java-Server-PagesTechnologie. Rückversicherer A setzt in diesem Umfeld insbesondere auf die Möglichkeiten des .Net-Frameworks (ASP.NET). Fünf der sechs Unternehmen verwenden zudem die Java-Applet-Technologie, die mehr Möglichkeiten bei der grafischen Darstellung bietet. Die Java-AppletTechnologie ist und bleibt jedoch eher unbedeutend im Vergleich zu den Java Servlets und der ASP.NET-Technologie. Die Unternehmen, die auf die Java-Plattform setzen, haben die Java-Servlet-Technologie bereits in hohem Masse in Verwendung (zwei von fünf) oder planen einen intensiveren Einsatz der Technologie (drei von fünf). Analog zu dieser Entwicklung plant auch der Rückversicherer A, der auf die .Net-Plattform setzt, einen massiven Ausbau seiner ASP-Lösung. Banken

Rückversicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Java: Applets

Java: Servlets, JSP

.Net

Versicherungen Vers. A

Vers. B

Thin Client

Fat Client C++

Java .Net

Smalltalk

Host Hostbasierte Front Ends Legende:

Tab. 5:

sehr grosse Verwendung; grosse Verwendung; mittlere Verwendung; geringe Verwendung; (leer) geringe bis keine nennenswerte Verwendung

Ist-Situation und Entwicklungen im Bereich Präsentationslogik

Im Bereich der Fat-Client-Lösungen ergibt sich ein gemischtes Bild. Zum einen existieren dort zum Teil zahlreiche Applikationen auf der Basis von C++ und Smalltalk. Diese Sprachen verlieren jedoch zunehmend an Bedeutung. Zum anderen existieren jedoch auch Lösungen auf der Grundlage von Java und .Net, die zum Teil sogar ausgebaut werden. Auffallend ist der geplante starke Ausbau von .Net Fat Clients bei Rückversicherer A.

184

F. Wortmann

Im Bereich der Host Terminals verfügen noch drei der sechs Unternehmen über entsprechende Lösungen, die jedoch alle im Umfang reduziert oder eingeschränkt werden sollen. Insbesondere Bank A, Versicherung A und Versicherung B werden jedoch auch in Zukunft noch stark von Host Terminals Gebrauch machen. Vergleicht man die drei Technologien Thin Client, Fat Client und Host Terminal, so fällt auf, dass alle Unternehmen bereits in hohem Masse auf Thin-Client-Technologien setzen und bzw. oder den Einsatz dieser Lösungen intensivieren. Der Aufbau dieser Technologie geht zu Lasten der FatClient-Lösungen und der Host Terminals. Auffällig bei einem Vergleich der betrachteten Technologien ist auch, dass .Net in allen Unternehmen präsent ist. Dabei handelt es sich jedoch in der Regel um Lösungen, die eingekauft sind und die .Net-Umgebung voraussetzen. Nur bei Rückversicherer A nimmt die .Net-Plattform eine zentrale Stellung im Bereich der Eigenentwicklungen ein.

3.2

Geschäftslogik

Im Folgenden wird sowohl die Ist-Situation als auch die Entwicklungen im Bereich Geschäftslogik anhand der verwendeten Plattformen, der eingesetzten Programmiersprachen und der Organisation der Geschäftslogik aufgezeigt. Plattformen Die heutige Plattformsituation ist vornehmlich durch eine dominierende Stellung der Host-Systeme gekennzeichnet. Zwischen 50 und 90 Prozent der Geschäftslogik der befragten Unternehmen liegt auf dem Host. Insbesondere die befragten Versicherungen verfügen über umfangreiche Funktionalität auf ihren Hosts. Auf den Unix- bzw. Linux-Plattformen liegen zwischen 10 und 50 Prozent der Geschäftslogik. Lediglich Versicherung A setzt diese Plattform in geringerem Umfang ein. Die Windows-Systeme verfügen über 10 bis 20 Prozent der Geschäftsfunktionalität. Allerdings haben zwei der fünf Unternehmen, die diese Frage beantworteten, keine bzw. vernachlässigbare Teile der Logik auf Windows-Systemen angesiedelt. Um insbesondere die Konnektivität zum Host zu gewährleisten, verwenden Bank A, Rückversicherer B und Versicherung B Integrationslösungen auf CORBA-Basis. Analysiert man die Entwicklungen im Bereich der unterschiedlichen Plattformen, so fällt vor allem die Reduktion der auf dem Host liegenden Geschäftslogik um 10 bis 15 Prozent auf. Eine Ausnahme bildet in diesem


185

Fall Bank B, die den Einsatz von Host-Systemen in diesem Bereich geringfügig verstärken wird. Die Schwächung bzw. Stärkung der Hostsysteme wirkt sich entsprechend positiv bzw. negativ auf die Unix/Linux und Windows-Plattformen aus (siehe Abb. 2). 100%

90%

80%

70%

60% Windows Unix/Linux Host

50%

40%

30%

20%

10%

0% 2003

2006

2003

Bank A Banken

Abb. 2:

2006

Bank B

2003

2006

Rückv. A

2003

2006

Rückv. B

Rückversicherungen

2003

2006

Vers. A

2003

2006

Vers. B

Versicherungen

Prozentuale Verteilung der Geschäftslogik

Programmiersprachen Durch die häufige Verwendung von Host-Systemen zur Realisierung von Geschäftslogik sind auch die entsprechenden Programmiersprachen Cobol und PL1 stark in Gebrauch (siehe auch im Folgenden Tab. 6). In Zukunft bleibt die Nutzung dieser Programmiersprachen ebenfalls hoch, da eine Schwächung der Host-Plattform nicht abzusehen ist. Nur die beiden befragten Rückversicherer setzen in Zukunft verstärkt auf moderne Sprachen. Auffällig hoch ist der Einsatz von Java, das insbesondere bei den befragten Banken bereits intensiv genutzt wird. Drei der sechs befragten Unternehmen planen darüber hinaus einen teilweise massiv verstärkten Einsatz der Java-Technologie. Die Sprachen der .Net-Plattform werden heute in geringem Umfang lediglich bei den beiden Rückversicherungen angewendet. Ein verstärkter Einsatz der entsprechenden Sprachen zeichnet sich jedoch ab. Beachtet werden muss in diesem Zusammenhang, dass ausschliesslich Rückversicherer A .Net als strategische Plattform gewählt hat. Die anderen Unternehmen versuchen den Einsatz dieser Plattform nicht gezielt voranzutreiben.

186

F. Wortmann

Zum Befragungszeitpunkt weniger stark vertreten ist C++, das noch mittlere Verwendung bei den Banken und Rückversicherungen findet. Letztere planen jedoch für die kommenden Jahre einen Abbau von C++. C++ bleibt jedoch vornehmlich bei der Programmierung von Infrastruktur eine der häufig verwendeten Sprachen. Drei der sechs Unternehmen verwenden Smalltalk in mittlerem bis geringem Umfang. Eine Ablösung dieser Sprache deutet sich jedoch an. Banken

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

C++

Cobol

Java

.Net

PL 1

Smalltalk

Legende:

Tab. 6:

Vers. A

Vers. B


Programmiersprachen im Bereich Geschäftslogik: Ist-Situation und Entwicklungen

Gestaltungsprinzipien der Geschäftslogik Um eine maximale Wiederverwendung und Transparenz (im Sinne der Nachvollziehbarkeit) der Geschäftslogik sicherzustellen existieren drei wesentliche Faktoren: • Trennung von Geschäfts- und Präsentationslogik: Findet eine Durchmischung von Geschäfts- und Präsentationslogik statt, so ist eine Wiederverwendung der entsprechenden Geschäftslogik in der Regel nur in den seltensten Fällen realisierbar. • Partitionierung von Geschäftslogik in Module/Services: Nur wenn die Geschäftslogik in möglichst unabhängige Module untergliedert ist, kann eine effiziente Wiederverwendung stattfinden. Insbesondere der Umfang der entsprechenden Schnittstellen spielt eine wesentliche Rolle bei der Wiederverwendung. Sehr grosse Schnittstellen bedürfen beispielsweise einer langwierigen Einarbeitung, was sich negativ auf die Wiederverwendung auswirken kann.


187

• Explizite Spezifikation von Schnittstellen: Erfolgt keine explizite Dokumentation bzw. Spezifikation einer Schnittstelle, so ist zum einen die Verständlichkeit der Schnittstelle eingeschränkt. Zum anderen geht mit der expliziten Deklaration einer Schnittstelle auch eine gewisse Verpflichtung einher, die Schnittstelle nur moderaten Änderungszyklen zu unterwerfen und bei einer Änderung alle Verwender der Schnittstelle zu berücksichtigen. Fragt man die Unternehmen nach den drei dargestellten Prinzipien, zeigt sich, dass alle Unternehmen diese schon heute berücksichtigen und auch in Zukunft weiter forcieren werden (siehe Tab. 7). Ausgenommen Bank B, die sich in allen drei Bereichen bereits sehr gut positioniert sieht, arbeiten alle Unternehmen an der weiteren Durchsetzung der diskutierten Punkte. Dabei sind über die einzelnen Unternehmen zwar unterschiedliche Entwicklungsstadien zu erkennen, Regelmässigkeiten lassen sich jedoch nicht erkennen. Banken

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B

Trennung von Geschäftsund Präsentationslogik

Partitionierung der Geschäftslogik in Module/Services

Explizite Spezifikation von Schnittstellen

Legende:

Tab. 7:


Gestaltungsprinzipien der Geschäftslogik

Auswirkungen auf Integrationsinfrastrukturen Folgende Auswirkungen auf Integrationsinfrastrukturen können identifiziert werden: • Zusammenspiel Präsentations- und Geschäftslogik: Das Zusammenspiel von Präsentations- und Geschäftslogik stellt für die Unternehmen immer weniger eine Herausforderung dar. Teilweise liegen homogene Umgebungen vor, das heisst sowohl die Präsentations- als auch die Geschäftslogik sind in der gleichen Laufzeitumgebung wie z.B. Java/J2EE oder .Net realisiert. Somit können plattformnative Kommunikationsund Integrationsdienste in Anspruch genommen werden.

188

F. Wortmann

• Zusammenspiel von Geschäftslogik unterschiedlicher Plattformen und Sprachen: Alle befragten Unternehmen verfügen über mindestens eine Host- und eine Unix-Plattform mit den entsprechenden Programmiersprachen, die sie auch in Zukunft unterhalten werden. Somit ist in diesem Bereich auch zukünftig grosser Integrationsbedarf vorhanden. Welche Integrationsinfrastrukturen heute und in Zukunft verwendet werden, soll in erweiterter Form in Abschnitt 4 untersucht werden. • Integrationsprinzipien: Die weit reichende Umsetzung der Prinzipien

„Trennung von Geschäfts- und Präsentationslogik“, „Partitionierung der Geschäftslogik in Module/Services“ und „Explizite Spezifikation von Schnittstellen“ ist in den Unternehmen ein zentrales Anliegen. Integrationsinfrastrukturen und –technologien sollten dies z.B. durch die Verwendung neutraler, standardisierter Schnittstellenbeschreibungssprachen wie IDL oder WSDL berücksichtigen.

3.3

Datenzugriffslogik

Im folgenden Abschnitt werden die Datenzugriffslogik und die nachgelagerten Datenspeicher untersucht, um auch hier wiederum mögliche Konsequenzen für die Integrationsinfrastrukturen abzuleiten. Datenhaltungssysteme Bei der hier durchgeführten Analyse der Datenhaltungssysteme ist zu beachten, dass es sich bei den Daten um Schätzungen handelt. Somit sind die nachfolgenden Angaben nur unter Vorbehalt interpretierbar. Nichtsdestotrotz lassen sich wesentliche Ergebnisse aus der Frage, welcher Prozentsatz ihres gesamten Datenbestandes auf welcher Datenhaltungsplattform liegt, ableiten. Ein Aspekt, der diese Frage nur schwer abschätzbar macht, ist die Tatsache, dass bei den befragten Unternehmen in der Regel der Host die Stammdaten enthält, diese Daten jedoch auch redundant in den dezentralen Datenbanksystemen vorliegen. Aufgrund der Redundanz ist das Datenvolumen dort zum Teil erheblich grösser.


Abb. 3:

189

Datenhaltungssysteme: Ist-Situation und Entwicklungen

Bei den fünf Unternehmen, die diese Frage beantworten konnten, zeichnet sich bei vieren eine dominante Stellung des Hosts bei der Datenhaltung ab (siehe auch im Folgenden Abb. 3). Zwischen 50 und 96 Prozent der Daten liegen bei diesen vier Unternehmen auf den Hostsystemen. Insbesondere DB2 ist in diesem Umfeld stark vertreten (Rückversicherer B, Versicherung A, Versicherung B). Bei Bank A ist ein Grossteil der Daten auf dem Host in Files abgelegt, allerdings im Wesentlichen aus Caching-Gründen. Die Versicherungen verwenden IMS-Datenbanken im Umfang von 40 bis 45 Prozent. Weiterhin stark vertreten sind die Unix-basierten Oracle-Lösungen. Vor allem Rückversicherer A setzt diese fast ausschliesslich ein. Weniger präsent sind Datenbanklösungen auf der Basis von Microsoft Windows. Lediglich Rückversicherer A und Versicherung A setzen in geringem Umfang auf diese Applikationen. Substanzielle Entwicklungen im Bereich der Datenspeicherung zeichnen sich nur bei den Versicherungen ab. Dort wird insbesondere die Verwendung von IMS eingeschränkt. Davon profitieren insbesondere die Hostbasierten DB2-Lösungen. Letztendlich können jedoch auch die Unix/ Oracle- und Windows/DB2-Umgebung zulegen. Der Host bleibt allerdings die dominierende Datenspeicherungsplattform. Datenzugriff Gefragt nach der Technologie, die verwendet wird, um auf die Unternehmensdaten zuzugreifen, gaben alle Unternehmen unter anderem Java Da-

190

F. Wortmann

tabase Connectivity (JDBC) an. Die Nutzung dieser Technologie findet in den Unternehmen jedoch heute eher in mittlerem Umfang statt. Eine Ausnahme bildet Rückversicherer B, der eine grosse Verwendung angibt. Drei der Unternehmen setzen in Zukunft verstärkt auf diese Technologie, während Rückversicherer A aufgrund seiner .Net-Strategie die Ablösung bisheriger JDBC-Lösungen plant. Banken Bank A

Rückversicherungen

Bank B

Rückv. A

Rückv. B

IBM MQ J2EE Container Managed Persistency

JDBC ODBC/OLE DB

Tab. 8:

Vers. B

Eigene Frameworks, Third Party

Legende:

Vers. A

Corba Services

PL1

Versicherungen


Technologien zum Zugriff auf Datenhaltungssysteme: Ist-Situation und Entwicklungen

J2EE Container Managed Persistency als eine Technologie, die eine direkte Verwendung von SQL-Statements (wie sie in reinen JDBC-Lösungen verwendet werden) weitestgehend obsolet werden lässt, wird bereits in hohem Masse bei Bank B eingesetzt. Rückversicherer B plant den Einsatz dieser Technologie in den nächsten drei Jahren. Das Pendant zu JDBC auf der Microsoft-Plattform sind ODBC bzw. OLE DB. Lediglich Rückversicherer A setzt diese Technologie bereits intensiv ein. Ein geringfügiger Einsatz dieser Middleware ist auch bei Rückversicherer B zu verzeichnen. Bei Letzterem ist ein verstärkter Einsatz jedoch nicht geplant. Integrationsinfrastrukturen, die nur bei zwei Unternehmen auch in Zukunft zum Zugriff auf Daten verwendet werden, sind CORBA-Lösungen. Diese Infrastrukturlösungen werden sowohl bei Bank A als auch bei der Versicherung B angewendet. Weitere Angaben, die aber lediglich von einzelnen


191

Unternehmen gemacht wurden, sind IBM MQ, PL1 und „eigene Frameworks“. Gestaltungsprinzipien der Datenzugriffslogik Um eine maximale Wiederverwendung und Transparenz (im Sinne der Nachvollziehbarkeit) sowohl im Bereich der Geschäfts- als auch Datenzugriffslogik zu realisieren, bietet sich die Trennung von Geschäfts- und Datenzugriffslogik an. Alle Unternehmen haben die Wichtigkeit dieser Modularisierung erkannt, so dass bereits eine Trennung vorliegt oder an einer stärkeren Trennung gearbeitet wird (siehe auch im Folgenden Tab. 9). Insbesondere bei den Banken ist die Modularisierung bereits umgesetzt. Alle anderen Unternehmen arbeiten an einer weiteren Umsetzung des Modularisierungsprinzips der Datenzugriffslogik. Banken

Trennung von Geschäftsund Datenzugriffslogik Legende:

Tab. 9:

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B


Gestaltungsprinzip der Datenzugriffslogik

Auswirkungen auf Integrationsinfrastrukturen Folgende Auswirkungen auf Integrationsinfrastrukturen können im Bereich Datenzugriffslogik identifiziert werden: • Datenhaltungssysteme: Fünf der sechs befragten Untenehmen verwenden drei oder mehr Datenhaltungsplattformen, so dass in diesem Bereich in den Unternehmen ausgeprägte Heterogenität herrscht, die in diesem Bereich den Einsatz von Integrationslösungen nahe legt. Auch in Zukunft ist keine Konsolidierung dieser Systeme abzusehen. • Zusammenspiel Geschäfts und Datenzugriffslogik: Für den Datenzugriff werden heute und in Zukunft hauptsächlich JDBC bzw. ODBC/ OLE DB-basierte Lösungen eingesetzt. Bei zwei der befragten Unternehmen liegen ausgeprägte CORBA-Lösungen für diese Aufgabe vor. Diese Infrastrukturen werden sich auch in Zukunft eingehender Verwendung erfreuen. Eine Ablösung dieser Systeme durch Web-ServiceInfrastrukturen steht zurzeit nicht zur Diskussion.

192

F. Wortmann

• Organisation der Datenzugriffslogik: Die Trennung von Geschäfts- und

Datenzugriffslogik ist ebenso ein zentrales Anliegen wie auch die Trennung von Präsentations- und Geschäftslogik. Eine zukunftsweisende Integrationsinfrastrukturlösung sollte dieses Anliegen somit unterstützen. Dies ist beispielsweise durch die J2EE-Umgebung gegeben, die mit dem Konzept der Entity Beans eine Trennung der Datenzugriffs- von Geschäftslogik explizit vorsieht.

4

Analyse der Integrationsinfrastrukturen

Im Folgenden werden die wesentlichen Anforderungen, die an heutige und zukünftige Integrationsinfrastrukturen gestellt werden, analysiert. Im Anschluss daran werden die Ist-Situation und die Entwicklungen im Bereich der Integrationsinfrastrukturen dargestellt.

4.1

Anforderungen an Integrationsinfrastrukturen

Fragt man die Vertreter der Unternehmen nach den Anforderungen der Fachbereiche, die einen wesentlichen Einfluss auf die Gestaltung der Infrastruktur nehmen, nannten die Befragten an erster Stelle die Kosteneffizienz (siehe auch im Folgenden Tab. 10). Die Befragten wiesen dabei insbesondere auf die schlechten Wirtschaftsverhältnisse hin, die einen entsprechenden Kostendruck innerhalb der Unternehmen verursachen. Als weitere dominante Anforderung gilt „Geringe Komplexität“. Die befragten Unternehmen sind bestrebt, die Heterogenität ihrer Systemlandschaften einzuschränken. Dies soll zum einen durch die Standardisierung von Produkten und zum anderen durch Konsolidierung erreicht werden. Die Standardisierung zielt dabei auf eine Bereinigung des ITProduktportfolios ab. Ein Beispiel hierfür ist die Reduktion der ERPSysteme, die im Unternehmen eingesetzt werden, so dass letztendlich nur noch das System eines Herstellers verwendet wird. Die Konsolidierung versucht unterschiedliche Instanzen einer Software zusammenzuführen. Ein Beispiel hierfür ist die Zusammenlegung verschiedener ERP-Lösungen eines Herstellers zu einer Instanz. Ein weiterer Aspekt, der die Entwicklung von Integrationsinfrastrukturen wesentlich bestimmt, ist „Flexibilität“. Gerade durch die aufkommenden Diskussionen um Outsourcing und die Anforderung auch IT-Lösungen


193

immer schneller produktiv zu schalten, ist eine maximale Flexibilität im Bereich der Integrationsinfrastruktur gefordert. Banken Bank A

Bank B

Rückversicherungen Rückv. A

Rückv. B

Versicherungen Vers. A

Vers. B

Vorgegebene Anforderungen Bereitstellung von RealTime-Informationen Datenschutz Fähigkeit zur Kooperation mit Geschäftspartnern Flexibilität Geringe Komplexität Konzentration auf das Kerngeschäft Kosten Multikanalunterstützung Real-Time-EreignisBenachrichtigung Service- bzw. Produktqualität Time to market Eigenständig genannte Anforderungen Prozessverbesserungen Standards User Self Service Legende:

sehr grosse Bedeutung; grosse Bedeutung; mittlere Bedeutung; geringe Bedeutung; (leer) geringe bis keine nennenswerte Bedeutung

Tab. 10: Anforderungen an Integrationsinfrastrukturen

Weitere wichtige Aspekte, die eine Integrationsinfrastruktur berücksichtigen muss, sind Datenschutz- und Qualitätsanforderungen. Da die Integrationsinfrastrukturen für die Übermittlung grosser Datenmengen verantwortlich sind, unter denen sich auch personenbezogene Daten befinden können, gelten insbesondere auch für die Infrastrukturen die Datenschutzbestimmungen der Unternehmen. Im Hinblick auf die Qualitätsanforde-

194

F. Wortmann

rungen ist zu beachten, dass Integrationsinfrastrukturen in den befragten Unternehmen zahlreiche Applikationen miteinander verknüpfen, so dass ihre Zuverlässigkeit und Geschwindigkeit massgeblich zur Produkt- und Servicequalität des jeweiligen Unternehmens beiträgt. Anforderungen, die darüber hinaus als wichtig identifiziert wurden, sind „Fähigkeit zur Kooperation mit Geschäftspartnern“, „Multikanalunterstützung“ und „Time to market“. Gerade vor dem Hintergrund, dass Integrationsinfrastrukturen häufig auf der Basis des Multikanalmanagements gerechtfertigt werden (vgl. Keller 2002, S. 14), ist das durchschnittliche Abschneiden der Anforderung „Multikanalunterstützung“ auffällig. Auch die Anforderung “Fähigkeit zur Kooperation mit Geschäftspartnern“ ist im Hinblick auf die Potentiale, die dem B2B-Umfeld zugeschrieben werden, eher durchschnittlich bewertet worden. Die Anforderung „Time to market“, die laut den Befragten im E-Commerce-Hype eine der wesentlichen Treiber für Projekte war, ist in ihrer Bedeutung in den letzten Jahren zurückgedrängt worden. Eher unwichtig im Vergleich zu den anderen Anforderungen wurden „Konzentration auf das Kerngeschäft“, „Real-Time-Ereignis-Benachrichtigung“ und „Bereitstellung von Real-Time-Informationen“ bewertet. Dies ist insofern interessant, als dass das Thema „Real-Time“ sich bei Praktikern und Wissenschaftlern gegenwärtig grosser Beliebtheit erfreut. Von sich aus genannt haben die Unternehmen die Anforderungen „User Self Service“, „Standards“ und „Prozessverbesserungen“. Bei dem Thema „User Self Service“ steht die alleinige Durchführung von Aufgaben durch den Endbenutzer im Vordergrund. Beispielsweise kann im Bereich der Benutzeradministration dem Anwender eine Plattform zur Verfügung gestellt werden, auf der er seine Passwörter selbstständig pflegen kann. Im Wesentlichen werden solche Lösungen zur Einsparung von Personalkosten verwendet. Durch die Einführung von Standards sollen die bereits beschriebenen Standardisierungs- und Konsolidierungseffekte erzielt werden.

4.2

Ist-Situation und Entwicklungen

Eingesetzte Applikationsserver/Komponententechnologien Die Applikationsserver, die in den Unternehmen verwendet werden, bieten in der Regel die Verwendung eines Komponentenmodells an. Bei den Servern auf Java-Basis ist dies beispielsweise das J2EE-Framework. In den Unternehmen wird zum Befragungszeitpunkt insbesondere die Enterprise-Java-Beans-Technologie des J2EE-Frameworks verwendet (siehe auch im Folgenden Tab. 11). Diese Technologie wird auch in Zukunft von


195

fünf der sechs Unternehmen verstärkt eingesetzt werden. Eine intensive Nutzung liegt dann bei den beiden befragten Banken und Versicherung B vor. Eine Alternative zum Java-Komponentenmodell ist die .Net-Umgebung, die bei Rückversicherer A das strategische Komponentenmodell darstellt und somit in den nächsten Jahren eine wachsende Bedeutung erfährt. CORBA wird gegenwärtig und auch in Zukunft in hohem Masse bei Bank A und Versicherung B eingesetzt. Bank B und Rückversicherer B planen dagegen eine signifikante Reduzierung ihrer CORBA-Verwendung. Im Bereich der COM/DCOM-Lösungen plant Rückversicherer A eine weitgehende Ersetzung der bestehenden Anwendungen durch .Net-Applikationen. Versicherung A zieht hingegen den Einsatz von COM/DCOM-Lösungen in Erwägung. Kommt es zu dem geplanten Einsatz, dann wird die Verwendung jedoch von geringem Ausmass sein. Banken

CORBA

Rückversicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Enterprise Java Beans

.Net

Vers. B

Eigenes Framework Legende:

Vers. A

COM/DCOM

Versicherungen

1


Tab. 11: Applikationsserver/Komponententechnologien: Ist-Situation und Entwicklungen

Message Broker, Workflow Management und ETL Alle Unternehmen verwenden Message-Broker als eine Komponente ihrer Integrationsinfrastruktur (siehe auch im Folgenden Tab. 11). Insbesondere die Banken nutzen diese Werkzeuge in sehr grossem Umfang. In der Regel basiert die Kommunikation auf asynchronen Message Queues. Aber auch Publish-Subscribe-Lösungen befinden sich bereits im Einsatz und werden auch in Zukunft verstärkt eingesetzt. Während Bank B, Rückversicherer A und Versicherer A den Einsatz dieser Technologien vorsehen hat Bank A bereits eine Lösung auf Basis der Publish-Subscribe-Technologie installiert.

196

F. Wortmann

Auch im Bereich des regelbasierten Routings von Nachrichten hat Bank A bereits eine Lösung im Einsatz, die jedoch nicht wesentlich erweitert werden soll. Bank B, Rückversicherer A und Rückversicherer B planen in diesem Umfeld Lösungen von mittlerer Bedeutung. Bei der Frage, ob der Broker Geschäftslogik enthalten soll, sind die Befragten unterschiedlicher Meinung. Während Bank A diese Frage explizit verneint, so setzt Rückversicherer B in Zukunft verstärkt auf dieses Konzept. Banken

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B

Asynchrone Message Queues

Publish-SubscribeTechnologie

Regelbasiertes Routing

Message Broker

Kapselung von Geschäftslogik durch Broker

Workflow Management Workflow Management

ETL ETL Legende:


Tab. 12: Message Broker, Workflow Management und ETL: Ist-Situation und Entwicklungen

Der Einsatz von Workflow-Management-Lösungen ist in den Banken und Rückversicherungen in geringem Umfang gegeben. Eine eingeschränkte Steigerung des Einsatzes ist bei Bank A und Rückversicherer B möglich. Die beiden Versicherungen planen ebenfalls den Einsatz von WorkflowManagement-Lösungen. Gerade im Hinblick auf die derzeitigen Trends wie Business Process Management oder Business Performance Measurement ist die Investitionsbereitschaft der Unternehmen in Workflow-Technologie jedoch relativ gering. Die hier dargestellten Angaben scheinen im Kontext der vor Ort vertretenen Meinungen der Befragten sehr positiv. Typisch für die Investitionsbereitschaft der Unternehmen im Bereich Workflow-Management war der Kommentar eines Unternehmensvertre-


197

ters: „Das Interesse an Workflow Management ist gross. Bei sinkenden Budgets ist diese Technologie jedoch nur ‚nice to have’.“ ETL-Werkzeuge setzt nur Rückversicherer B als Integrationsinfrastruktur im operativen Bereich ein. Alle anderen Unternehmen verwenden diese Werkzeuge im Umfeld des Data Warehousing. Rückversicherer B plant jedoch für die Zukunft eine eingeschränkte Verwendung der ETL-Werkzeuge zur Integration operativer Datenbestände. Web Services Im Bereich der Web Services setzen drei der befragten Unternehmen bereits heute auf den Standard SOAP siehe auch im Folgenden Tab. 13). Dies sind die beiden befragten Banken und Rückversicherer B. WSDL haben ausschliesslich Bank A und Bank B im Einsatz. UDDI-Verzeichnisse verwendet noch keines der befragten Unternehmen. In Zukunft wird sich der Einsatz von Web-Service-Standards ausweiten. Alle Unternehmen planen die Verwendung von SOAP in geringem bis mittlerem Umfang. Auffällig bei der geplanten Verwendung von SOAP ist Rückversicherer B, der innerhalb der nächsten drei Jahre eine intensive SOAP-Verwendung anstrebt. Auch im Bereich des WSDL-Standards planen die Unternehmen mit Ausnahme von Versicherung B einen mittleren bis geringen Einsatz. Lediglich Rückversicherer A erwägt den Einsatz von UDDI-Verzeichnissen innerhalb der nächsten drei Jahre. Banken

Rückversicherungen

Versicherungen

Bank A

Bank B

Rückv. A

Rückv. B

Vers. A

Vers. B

SOAP

WSDL

Verwendete Standards

UDDI Anwendungsgebiete

Intern Ausgewählte Partner

Öffentlichkeit

Legende:


Tab. 13: Web Services: Ist-Situation und Entwicklungen

1

198

F. Wortmann

Die befragten Unternehmen sehen den Anwendungsbereich der Web-Service-Standards vor allem im Unternehmen selbst. Der Verwendung der Web-Service-Technologien in der Zusammenarbeit mit ausgewählten Geschäftspartnern wird jedoch ebenfalls Potential zugesprochen. Insbesondere Rückversicherer B erwartet in diesem Umfeld einen verstärkten Einsatz von SOAP und WSDL. Nur Bank A hält auch öffentlich zugreifbare Web Services für relevant. Beispielsweise im Home Banking könnten bestehende Standards durch Web-Service-Lösungen ergänzt bzw. abgelöst werden. Formatkonvertierungen Eine der wesentlichen Aufgaben von Integrationswerkzeugen neben der eigentlichen Herstellung der Konnektivität zwischen heterogenen Applikationen ist die Konvertierung von Datenformaten. Banken Bank A

Rückversicherungen

Bank B

Versicherungen

Rückv. A

Rückv. B

Vers. A

Vers. B

Vorgegebene Angaben

Message Broker ETL

Eigenentwicklung

Eigenständige Angaben Mercator Legende:


Tab. 14: Formatkonvertierungen: Ist-Situation und Entwicklungen

Die Unternehmen setzen in diesem Bereich bereits deutlich auf Message Broker, die Möglichkeiten zur Transformation bereitstellen (siehe auch im Folgenden Tab. 14). Vier der fünf Unternehmen, die Message Broker zur Formatkonvertierung einsetzen, werden diese auch in Zukunft stärker für Konvertierungsaufgaben einsetzen. Eigenentwicklungen spielen im Umfeld der Formatkonvertierungen ebenfalls eine Rolle. Dies jedoch lediglich bei drei der befragten Unternehmen. In Zukunft werden die selbstentwickelten Lösungen jedoch mehr und mehr durch Standardlösungen von Drittherstellern abgelöst werden. Eine geringe, dafür relativ konstante Bedeutung für Formatkonvertierungen haben ETL-Werkzeuge, die allerdings nur von Rückversicherer B und Versicherung B zur Transformation verwendet werden.


5

199

Zusammenfassung und Erkenntnisse der Studie

Ziel der Studie war es, Entwicklungen der Applikationslandschaften zu erfassen, die eine Auswirkung auf Integrationsinfrastrukturen haben. Darüber hinaus sollten die geplanten Entwicklungen von Integrationsinfrastrukturen aufgezeigt werden. Aus der Analyse der Applikationslandschaften ergaben sich folgende Beobachtungen: • Ist-Situation: Im Umfeld der geschäftsbereichsübergreifenden Applikationen wird in wesentlichen Bereichen Standardsoftware verwendet. Es gibt jedoch weiterhin Gebiete, in denen verstärkt Eigenentwicklungen verwendet werden. Dies ist insbesondere bei CRM-Systemen der Fall. Hinsichtlich der grundlegenden Dienste wie z.B. Betriebssysteme, Datenbanken und Applikationsserver fällt auf, dass fünf der sechs befragten Unternehmen die Plattformen Unix, Host und Intel verwenden. Darüber hinaus speichert der Grossteil der Unternehmen seine Daten in Datenbanken auf dem Host und auf Unix-Plattformen ab. Bezüglich der Verwendung von Standardsoftware im Bereich Applikationsintegration lässt sich feststellen, dass dedizierte Portalsoftware in den untersuchten Unternehmen bereits zum Befragungszeitpunkt eine hohe Verwendung findet. Hingegen ist der Einsatz von StandardWorkflow-Lösungen nur sehr eingeschränkt gegeben. Die eingesetzten Werkzeuge im Bereich EAI-Software und Message-Broker können analog zu den Applikationsservern in Microsoft- und Java-orientierte Produkte unterteilt werden. Fünf der sechs befragten Unternehmen setzen auf die Java-basierten Produkte. • Entwicklungen: Die befragten Unternehmen werden in den kommenden Jahren sehr unterschiedlich im Umfeld der IT investieren. Ein Schwerpunkt sind jedoch ERP-Systeme und Kollaborationslösungen. Bei der Applikationsintegration fliesst ein Grossteil der Investitionen in die Bereiche Portale. Object Broker, Transaktionsmanager und ETL-Werkzeuge kommen hingegen kaum Investitionen zu. Bei der Untersuchung der Entwicklungen in Bezug auf die Verwendung von Standardsoftware zeichnet sich eine geringfügig höhere Verwendung von Standardsoftware ab. Die Funktionalität, die in den befragten Unternehmen derzeit von Standardsoftware implementiert ist, liegt zwischen 20 und 30 Prozent. Der gegenwärtige Anteil wird sich in den nächsten drei Jahren nicht signifikant steigern. Lediglich eines der sechs befragten Unternehmen plant eine Steigerung des Standardsoftwareanteils um bis zu 60 Prozent.

200

F. Wortmann

Wesentliche Erkenntnisse aus der Analyse der Eigenentwicklungen sind: • Präsentationslogik: Die Unternehmen setzen bereits sehr stark auf die Thin-Client-Technologie. Darüber hinaus wird weiter in diese Technologie investiert. Diese Investitionen gehen vor allem zu Lasten der hostbasierten Frontends, die vier der sechs befragten Unternehmen noch verwenden. Im Bereich der Fat-Clients findet ein Abbau von Smalltalk und C++-Lösungen statt. • Geschäftslogik: Alle befragten Unternehmen verfügen über wenigstens eine Host- und eine Unix-Plattform, die sie auch in Zukunft unterhalten werden. Analysiert man die Entwicklungen im Bereich der unterschiedlichen Plattformen für die Gesamtheit der Unternehmen, so fällt eine geringe Reduktion der Geschäftslogik zu Lasten der Host-Plattform auf. Dies wirkt sich positiv auf die Unix- und Windows-Plattformen aus. Die Geschäftslogik wird schon heute unter der Berücksichtigung der Gestaltungsprinzipien „Trennung von Geschäfts- und Präsentationslogik“, „Partitionierung der Geschäftslogik in Module/Services“ und „Explizite Spezifikation von Schnittstellen“ gestaltet. In Zukunft wir die Durchsetzung dieser Prinzipien weiter forciert werden. • Datenzugriffslogik: Fünf der sechs befragten Unternehmen verwenden drei oder mehr Datenhaltungsplattformen. Bei vier der befragten Unternehmen ist eine deutliche Dominanz der Host-Systeme als Speicherort gegeben. Diese wird auch in Zukunft erhalten bleiben. In den nächsten drei Jahren werden jedoch die IMS-Systeme an Bedeutung verlieren. Alle Unternehmen haben die Trennung der Geschäfts- und Datenzugriffslogik als wichtiges Gestaltungsprinzip erkannt und arbeiten an einer weiteren Umsetzung des Modularisierungsprinzips. Die Analyse der Integrationsinfrastrukturen ergab: • Anforderungen an Integrationsinfrastrukturen: Auf die Frage nach den Anforderungen der Fachbereiche, die einen wesentlichen Einfluss auf die Gestaltung von Infrastrukturen nehmen, nannten die Befragten an erster Stelle die Kosteneffizienz. Weitere vorherrschende Anforderungen sind „Geringe Komplexität“, „Flexibilität“, „Datenschutz“ und „Service- bzw. Produktqualität“. • Ist-Situation und Entwicklungen: Web-Service-Standards werden in

den untersuchten Unternehmen heute nur sehr eingeschränkt verwendet. Die Bedeutung dieser Technologie wird sich innerhalb der nächsten drei Jahre aber geringfügig erhöhen. Auch Workflow-Lösungen sind nur in geringem Umfang im Einsatz. Auch die Bedeutung dieser Werkzeuge wird sich ebenfalls geringfügig steigern. Bei den asynchro-


201

nen Integrationstechnologien finden im wesentlichen asynchrone Message Queues Verwendung. Regelbasierte Lösungen und Publish-Subscribe-Technologien, die heute lediglich eines der Unternehmen implementiert hat, werden auch in drei weiteren Unternehmen angedacht bzw. geplant. Applikationsserver auf der Basis von Java oder .Net gewinnen langsam an Bedeutung. Nur eines der befragten Unternehmen verwendet das .Net-Framework als strategische Plattform. Alle anderen Unternehmen setzen auf Java-basierte Applikationsserver. Die durchgeführte Studie erhebt keinen Anspruch auf Vollständigkeit oder Generalisierbarkeit der Ergebnisse.

Literatur Keller, W.: Enterprise Application Integration, 1. Aufl., Heidelberg, 2002.

Modellierung von Integrationsaspekten in Applikationslandschaften Andreas Siegenthaler Swisscom IT-Services

Alexander Schwinn Universität St. Gallen

Der vorliegende Beitrag stellt Ergebnisse eines bilateralen Projekts zwischen der Swisscom IT Services AG und dem CC AIM dar. Ziel des Projekts war die Entwicklung einer Modellierungstechnik zur Darstellung von heterogenen Applikationslandschaften auf unterschiedlichen Ebenen. Die Ergebnisse sollen zur systematischen Darstellung von Integrationsaspekten in Applikationslandschaften dienen und bei zukünftigen Integrationsanforderungen Entscheidungen erleichtern. Zudem sollen die Ergebnisdokumente, die auszugsweise in diesem Beitrag vorgestellt werden, zur verständlichen Kommunikation zwischen unterschiedlichen Anspruchsgruppen beitragen.

1 2

3

4

Einleitung ........................................................................................ 204 Applikationsintegration................................................................... 204 2.1 Integrationsbegriff ................................................................... 204 2.2 Treiber der Applikationsintegration......................................... 206 2.3 Ziele der Applikationsintegration ............................................ 207 Informationssysteme, Modelle, Architekturen................................ 208 3.1 Informationssystembegriff....................................................... 208 3.2 Modellbegriff ........................................................................... 208 3.3 Architekturbegriff .................................................................... 210 Identifizierte Modellierungsebenen bei der Swisscom IT Services AG................................................................................ 211 4.1 Konzeptionelle Ebene .............................................................. 212 4.2 Logische Designebene ............................................................. 215

204

5

1

A. Siegenthaler, A. Schwinn

4.3 Physische Designebene............................................................ 221 4.4 Implementierungsebene ........................................................... 225 4.5 Beispielhafte Modellierungsergebnisse auf der Implementierungsebene ........................................................... 226 Zusammenfassung........................................................................... 228

Einleitung

Der folgende Beitrag stellt einen Ergebnisbericht aus einem gemeinsamen Projekt zwischen der Swisscom IT Services AG und dem Kompetenzzentrum Application Integration Management (CC AIM) des Instituts für Wirtschaftsinformatik der Universität St. Gallen dar. Ziel des Projekts war die Entwicklung einer Technik zur Modellierung von Applikationslandschaften und insbesondere deren Integrationsaspekte. Dabei hat sich gezeigt, dass von unterschiedlichen Anspruchsgruppen unterschiedliche Sichten auf die Applikationslandschaft gewünscht werden. Deshalb wurden in dem Projekt zunächst unterschiedliche Modellierungsebenen gebildet und entsprechende Metamodelle der einzelnen Ebenen festgelegt. Nach einer Einführung in die Integrationsthematik, werden die dem Projekt zugrundeliegenden Begrifflichkeiten wie Modellierung und Informationssystem-Architekturen geklärt. Daran anschliessend werden die im Projekt identifizierten Modellierungsebenen vorgestellt und beschrieben. Dabei werden jeweils exemplarisch typische Ergebnisdokumente auf den einzelnen Ebenen vorgestellt und Verwendungsmöglichkeiten aufgezeigt.

2

Applikationsintegration

2.1

Integrationsbegriff

Der Fokus des CC AIM und dieses Beitrags ist die Integration von Applikationen untereinander. Häufig werden unter dem Stichwort „Enterprise Application Integration“ (EAI) Gestaltungsoptionen der Integration diskutiert (vgl. Holten 2003, S. 45). In der Literatur und Praxis existieren zahlreiche Definitionen und Auffassungen des Begriffs EAI. Ruh et al. versteht

Modellierung von Integartionsaspekten

205

unter EAI die Erstellung neuer Business-Anforderungen durch die Integration vorhandener Daten und Prozesse durch den Einsatz von einheitlicher Middleware (vgl. Ruh et al. 2001, S. 2). Nach Linthicum ist EAI die Reaktion auf die jahrzehntelange Entwicklung monolithischer Applikationen, die isoliert voneinander für spezielle Aufgaben entwickelt worden sind (vgl. Linthicum 2000, S. 3). Er versteht unter EAI die uneingeschränkte Nutzung aller Informationen und Geschäftsprozesse zwischen allen Informationssystemen innerhalb des Unternehmens. Die Literatur unterscheidet bei der Integration zudem häufig Integrationsbreite vs. Integrationstiefe und horizontale vs. vertikale Integration (vgl. Mertens 2000, S. 4). Die Integrationsbreite betrifft die Anzahl der zu integrierenden Applikationen eines Unternehmens. Die Integrationstiefe gibt den Grad der semantischen Integration an. Ring/Ward-Dutton (1999) unterscheiden diese in Integration auf Datenebene, Integration auf Objektebene und Integration auf Prozessebene. Die ausgetauschten Informationen auf Datenebene sind demnach Bits, auf der Objektebene Nachrichten und auf der Prozessebene die Bedeutung. Die Hauptanforderung auf der Datenebene ist der sichere Transport von Daten (z.B. Dateien, XML-Nachrichten, usw.) von einer Datenquelle zu einer Datensenke über verschiedene Systemplattformen (vgl. Dangelmaier et al. 2002, S. 62). Auf Objektebene werden Daten mit einer spezifizierten Semantik konvertiert und ausgetauscht. Quell- und Zielapplikation müssen über ein gemeinsames Vokabular verfügen, um die Semantik der ausgetauschten Information interpretieren zu können. Auf der Prozessebene werden vorhanden Geschäftsprozesse in der Integrationsarchitektur abgebildet (vgl. Dangelmaier et al. 2002, S. 62). Neben Integrationsbreite und Integrationstiefe wird zudem die Integrationsrichtung unterschieden. Die horizontale Integration befasst sich mit der Integration von Teilsystemen entlang der betrieblichen Wertschöpfungskette. Die vertikale Integration bezieht sich auf die Datenversorgung der Planungs- und Kontrollsysteme (dispositive Applikationen) durch die administrativen und operativen Applikationen (z.B. Applikationen für Vertrieb, Beschaffung, Produktion) (vgl. Mertens 2000, S. 4). Unter dem Begriff Applikationsintegration oder Enterprise Application Integration (EAI) wird in diesem Beitrag die Integration von Daten und Funktionen in heterogenen Applikationslandschaften mit folgenden Eigenschaften verstanden:

206


• Beibehaltung der logischen Entkopplung der Applikationen • Realisierung der Integration auf Basis von Middleware • Nutzung standardisierter Schnittstellen und Austauschformate

2.2

Treiber der Applikationsintegration

In letzter Zeit war erkennbar, dass vermehrt Integrationsanforderungen aufkommen. Eine Untersuchung der Aberdeen Group ergab folgende Gründe für die Applikationsintegration (vgl. O.V. 1998) (siehe Abb. 1): Unternehmenszusammenschlüsse

„Best-of-Breed“ Ansatz 14%

Verbesserte Lieferantenund Kundenbeziehungen

10% 38%

Beschleunigte Produktivsetzung neuer Anwendungen (Time-To-Market)

18% 20%

Bessere Informationsversorgung über traditionelle Grenzen hinweg

Abb. 1:

Gründe für die Applikationsintegration (vgl. O.V. 1998).

Demnach ist der Hauptgrund für die Applikationsintegration die beschleunigte Produktivsetzung von neuen Applikationen (Time-To-Market). Ein typisches Beispiel dafür wäre die Einführung eines CRM-Systems. Dieses muss mit zahlreichen anderen vorhandenen Systemen integriert werden (z.B. mit einem ERP-System oder einem Data Warehouse). Daneben existieren zahlreiche weitere Gründe, wie beispielsweise die bessere Informationsversorgung über traditionelle Grenzen hinweg (z.B. Kunde kann sämtliche Daten über ein Portal abrufen), Integration aufgrund der Wahl von „Best-of-Breed“-Ansätzen oder aufgrund von Unternehmenszusammenschlüssen. Eine verbesserte Lieferanten- und Kundenbeziehung erfordert ebenso Integration, jedoch wird in diesem Beitrag überwiegend die unternehmensinterne Integration – gemäss der Definition von Linthicum – betrachtet (vgl. Linthicum 2000, S. 3). Nach Erasala et al. existieren drei Hauptfaktoren, die die zunehmende Applikationsintegration treiben (vgl. Erasala et al. 2003, S. 70f.):


207

Die Entwicklung des E-Commerce erfordert eine immer schnellere Entwicklung von Web-Applikationen, die in der Regel durch Integration bestehender Applikationen (z.B. ERP-System, CRM-System, usw.) entstehen. Für den Kunden werden über Portale immer mehr Informationen elektronisch zugänglich (z.B. Abfrage von Kontoständen). Zahlreiche Unternehmenszusammenschlüsse der letzten Jahre erfordern zum einen eine Konsolidierung der Systeme, zum anderen eine Integration der Systeme beider Unternehmen, um auf Kundenseite integriert zu wirken. Der Trend zum Einsatz von Standardsoftware und grossen ERP-Systemen erfordert die Integration zwischen den Applikationen. Beispielsweise setzen Firmen eine Lösung für Human Resources (HR) und eine andere für die Buchhaltung ein. Zudem existieren häufig Altanwendungen, die aufgrund ihrer Zuverlässigkeit und zum Investitionsschutz nicht abgelöst werden sollen oder können, und somit ebenso integriert werden müssen.

2.3

Ziele der Applikationsintegration

Hauptziel bei der Applikationsintegration ist die schnelle und kostengünstige Integration von Applikationen. Laut einer Untersuchung von Gartner werden „ca. 30% - 35% der Zeit und Kosten eines System-Implementierungs-Projekts mit der Integration existierender Legacy- oder PackagedSysteme verbracht“ und „40% der IT Budgets werden durchschnittlich für die Erstellung und Wartung von Schnittstellen aufgewendet“ (Krallmann 2003, S. 8). Übergeordnetes Ziel ist es, diesen Aufwand hinsichtlich Zeit und Kosten zu senken. Krallmann unterscheidet operative und strategische Ziele von EAI (vgl. Krallmann 2003, S. 12). Demnach ist das strategische Hauptziel die nachhaltige Erhöhung der Flexibilität und Reaktionsgeschwindigkeit auf zukünftige Anforderungen (z.B. neue Vertriebskanäle). Zur Erreichung des Hauptziels werden als Teilziele die Steigerung der Integrationsfähigkeit von zukünftigen Anwendungen und Prozessen, die Kosteneinsparungen in M&A-Projekten, die schnellere Reaktion auf Marktveränderungen, die Standardisierung im IT-Bereich und der Investitionsschutz genannt. Auf der operativen Seite ist das Hauptziel die Optimierung in Hinblick auf Zeit, Kosten und Qualität.

208

3


Informationssysteme, Modelle, Architekturen

In den folgenden Abschnitten werden die in diesem Beitrag verwendeten zentralen Begrifflichkeiten Informationssystem, Modell und Architektur erläutert.

3.1

Informationssystembegriff

Im Forschungsprogramm Business Engineering am Institut für Wirtschaftsinformatik der Universität St. Gallen existieren drei Gestaltungsebenen: Die Strategieebene, die Prozessebene und die Systemebene. Während die Strategieebene die strategische Positionierung eines Unternehmens definiert, werden auf der Prozessebene die notwendigen Aktivitäten zur Umsetzung der Strategie festgelegt. Auf der Informationssystemebene schliesslich, der sich dieser Beitrag widmet, wird untersucht, wie die einzelnen Aktivitäten durch den Einsatz von Informationssystemen unterstützt werden können (vgl. Winter 2003a, S. 48/49). Allgemein ist ein Informationssystem ein System zur Informationsproduktion und Kommunikation zur Deckung von Informationsnachfragen (vgl. Heinrich 1999, S. 1021). Im Sinne des Business Engineering werden auf der Informationssystemebene die Applikationen und ihr Zusammenwirken beschrieben. Das Gestaltungsziel ist dabei die optimale Strukturierung und Implementierung der Applikationen (vgl. Winter 2003a, S. 107).

3.2

Modellbegriff

Betrachtungsgegenstand der Wirtschaftsinformatik sind Informationssysteme in Wirtschaft und öffentlicher Verwaltung (vgl. Mertens 1999, S. 1). Modelle, die auf die Informationen in betrieblichen Systemen fokussieren, können somit als spezifischer Modelltyp der Wirtschaftsinformatik bezeichnet werden (vgl. Schütte 1998, S. 63). Modelle in der Wirtschaftsinformatik stellen das wichtigste Hilfsmittel zur Analyse und Gestaltung von Informationssystemen dar (vgl. Ferstl/Sinz 1998, S. 117). Der Begriff Modellierung bezeichnet den „Vorgang der Konstruktion eines Abbilds realer oder gedachter Sachverhalte […], welcher auf der Grundlage der Wahrnehmung dieser Sachverhalte durch den/die Modellierer/in erfolgt und durch den jeweiligen Modellierungszweck beeinflusst wird“ (Winter 2003b, S. 89). Das Ergebnis der Modellierung sind Modelle. Dieser Definition liegt ein konstruktionsorientiertes Begriffsverständnis zugrunde. Im Gegensatz zum abbildungsorientierten Modellbegriff, der eine homomorphe Abbildung der Realität fordert, wird hier die subjektive Wahrnehmung


209

der Realität der an der Modellierung beteiligten Personen betont. Ein qualitativer Vergleich zwischen Modell und Realität ist daher nicht möglich (vgl. Schütte 1998, S. 40-62). Leist hat zahlreiche Modellierungszwecke in der Literatur identifiziert (vgl. Leist 2002, S. 8): • Optimierung organisatorischer Veränderungen (vgl. Scheer 1998, S. 3) • Speicherung von Organisationswissen, z.B. in Form von Referenzmodellen (vgl. Scheer 1998, S. 3) • Dokumentation (vgl. Frank 1994, S. 12; Scheer 1998, S. 3) • Berechnung der Kosten organisatorischer Abläufe (vgl. Scheer 1998, S. 3) • Unterstützung des Softwareentwurfs (vgl. Becker/Schütte 1996, S. 24) • Integration von Anwendungssystemen (vgl. Becker/Schütte 1996, S. 24) • Beschreibung und Auswahl von Standardsoftware (vgl. Becker/Schütte 1996, S. 23) • Unterstützung des Customizing von Standardsoftware (vgl. Becker/ Schütte 1996, S. 23) • Kommunikationsbasis für Entwickler, Anwender, Führungskräfte, etc. (vgl. Frank 1994, S. 12) • Standardisierung von Begriffen • Erkennen von Abdeckungslücken bzw. Doppelbelegungen, Schwachstellenanalyse • Rahmen für die Aufnahme/Veränderung der Ist-Situation • Unterstützung des (Prozess-)Controlling, Grundlage für Benchmarking • Gesamtübersicht/Abgrenzung Diese genannten Zwecke lassen sich zu folgenden Gruppen zusammenfassen (vgl. Leist 2002, S. 8f.): • Schulungszweck: Der Schulungszweck beinhaltet sowohl das Erlernen der Modellierungstechnik als auch das einfache Vermitteln organisatorischer Abläufe oder Funktionen des Informationssystems.

210


• Kommunikationsbasis: Ergebnisdokumente einer Modellierungstechnik können innerhalb/ausserhalb eines Unternehmens zur Kommunikation unterschiedlichster Sachverhalte dienen. Zudem dient sie der Kommunikation zwischen verschiedenen, an einem Projekt beteiligten Rollen, indem relevante Objekte, ihrer Bezeichnung, sowie ihrer Attribute festgelegt werden. • Analysezweck: Ergebnisse der Modellierung können zum Analysieren von Sachverhalten herangezogen werden (z.B. Identifikation von Lücken und Redundanzen innerhalb der Applikationslandschaft). • Gestaltungs- und Entwicklungszweck: Ergebnisse der Modellierung

können als Grundlage für die Entwicklung und Integration neuer Informationssysteme (z.B. Standardsoftware oder Eigen- und Auftragsentwicklungen) herangezogen werden.

3.3

Architekturbegriff

Der Begriff Architektur wird in diesem Beitrag analog zu dem im Bauwesen verstanden. Demnach umfasst die Architektur eines Informationssystems den Bauplan des Informationssystems sowie die Konstruktionsregeln zur Erstellung des Bausplans. Der Bauplan ist die Spezifikation der Komponenten und ihrer Beziehungen unter allen relevanten Blickwinkeln (vgl. Sinz 1999, S. 1035). Die Architektur beschreibt den Gesamtzusammenhang aller relevanten Objekte, Funktionen, Schnittstellen und Beziehungen zwischen diesen (vgl. Lehner et al. 1995, S. 58). Der Nutzen von Informationssystem-Architekturen ist sehr vielseitig, da die InformationssystemArchitektur ein ganzheitliches Modell der Informationsverarbeitung eines Unternehmens darstellt – von strategischen Zielen bis zur technischen Basis (vgl. Lehner et al. 1995, S. 59). Folgende Nutzenaspekte von Informationssystemarchitekturen gelten jedoch allgemein: • Erhöhung der Planbarkeit der Informationsverarbeitung (vgl. Lehner et al. 1995, S. 59) • Förderung der unternehmensweiten Vereinheitlichung von Standards (vgl. Lehner et al. 1995, S. 59) • Erhöhung der Flexibilität, durch erhöhte Offenheit und Anpassbarkeit von Applikationen (vgl. Lehner et al. 1995, S. 59) • Vorteile bei Wartung und Reengineering (vgl. Lehner et al. 1995, S. 59)


211

• Ganzheitliche Analyse und Gestaltung von Informationssystemen (vgl. Sinz 1999, S. 1035) • Zielgerichtete Nutzung von Informationssystemen (vgl. Sinz 1999, S. 1035) • Einfachere Kalkulation von Kosten (vgl. Mertens 2001, S. 44) • Basis zur Schaffung von Wiederverwendungspotential (vgl. Mertens 2001, S. 44) Nachdem nun Begrifflichkeiten eingeführt worden sind, werden in den nächsten Abschnitten Ergebnisse aus dem bilateralen Projekt zwischen der Swisscom IT Services und dem CC AIM vorgestellt. In der Literatur existieren zahlreiche Ansätze zur Modellierung von Informationssystemarchitekturen. Diese wurden im Rahmen des Projekts untersucht und trugen zur Entwicklung des erarbeiteten Ansatzes bei. In diesem Beitrag werden sie jedoch aus Platzgründen nicht detailliert vorgestellt. Eine ausführliche Betrachtung vorhandener Ansätze ist in Schwinn zu finden (vgl. Schwinn 2003).

4

Identifizierte Modellierungsebenen bei der Swisscom IT Services AG

Im Rahmen des bilateralen Projekts wurden zu Beginn unterschiedliche Modellierungsebenen definiert und die jeweiligen Eigenschaften und Anforderungen der einzelnen Ebenen festgelegt. Die Ebenenbildung diente der Reduktion von Komplexität des Gesamtmodells. Die Bildung der Modellebenen erfolgte dabei aber nicht durch Orientierung an vorhandenen Technologien, sondern durch Orientierung an dem generischen Vorgehensmodell zur Gestaltung von Informationssystemen, das die Aktivitäten Konzeption (Business Modeling), Entwurf (Requierements Analysis und Design) und Umsetzung (Implementierung) enthält. Im Folgenden werden die Modellebenen, wie sie im Projekt zur Modellierung von Integrationsaspekten in Applikationslandschaften entwickelt worden sind, vorgestellt. Zur Modellierung innerhalb des Ebenenmodells des Business Engineering auf der Informationssystem-Ebene wurden vier Teilebenen definiert: Die konzeptionelle Ebene, die logische Designebene, die physische Designebene und die Implementierungsebene. Um sicherzustellen, dass die Modelle auf den einzelnen Ebenen vollständig sind, und dass zwischen den einzelnen Ebenen navigiert werden kann, wurde die Anforderung gestellt,

212


dass zwischen den Ebenen Referenzen definiert werden. Dies ermöglicht beispielsweise einen Rückschluss von konkreten Implementierungen auf die ursprünglichen fachlichen Anforderungen oder die unterstützten Geschäftsprozesse. Abbildung 3 verdeutlicht diesen Sachverhalt. Konzeptionelle Ebene Logische Design Ebene

Link

Physische Design Ebene Implementierungs-/ Infrastruktur-Ebene

Abb. 2:

Link

Link

Identifizierte Modellebenen und Referenzierung der einzelnen Ebenen

In den folgenden Abschnitten werden nun die einzelnen Modellierungsebenen detailliert vorgestellt. Am Ende eines jeden Abschnitts werden zur Illustration beispielhaft Ergebnisdokumente präsentiert.

4.1

Konzeptionelle Ebene

4.1.1 Eigenschaften des Modells auf der konzeptionellen Ebene Das Modell auf der konzeptionellen Ebene sollte völlig unabhängig von physischen Applikationen, von Implementierungsaspekten oder von der verwendeten Infrastruktur sein. Das Modell auf der konzeptionellen Ebene ändert sich nur dann, wenn sich die Geschäftsprozesse verändern. Bei einer Änderung der Applikationslandschaft ist das Modell auf der konzeptionellen Ebene nicht betroffen, da von konkreten Applikationen abstrahiert wird, wodurch auch eine Langlebigkeit des Modells sichergestellt ist. Zudem sollte es einen generischen Referenzcharakter haben und innerhalb einer Branche weitestgehend allgemeingültig sein, d.h. unterschiedliche Firmen mit gleichem Geschäftsmodell können mit dem gleichen konzeptionellen Modell arbeiten (z.B. mittlere Universalbanken). Auf konzeptioneller Ebene wird eine ideale, redundanzfreie Sicht auf die Applikationslandschaft modelliert, bei der vor allem die Geschäftsprozesse und ihre Unterstützung durch Applikationen im Vordergrund steht. Das entwickelte


213

Metamodell der konzeptionellen Ebene wird in Abbildung 4 wiedergegeben. Das Metamodell beinhaltet folgende Entitäten: • Geschäftsprozess: Ein Geschäftsprozess besteht aus einer Sequenz von Aktivitäten, die von einem oder mehreren Akteuren (Mensch, Rechner usw.) getrieben werden, Zeit benötigen und einen definierten messbaren Input und Output (Wertschöpfung) besitzen. Ein Prozess erzeugt durch Wertschöpfung Leistungen für seinen Prozesskunden. Die Wertschöpfung findet statt, indem die Aufgaben des Prozesses in einer vorgegebenen Ablauffolge erledigt werden. Applikationen der Informationstechnik unterstützen die Ausführungen der Aufgaben (vgl. Österle 1995). • Rolle: Die Zuordnung von Aktivitäten im Zusammenhang mit der Gestaltung von Prozessen zu Aufgabenträgern wird als Rollenmodell bezeichnet. Eine Rolle wird von einer Organisationseinheit oder einem einzelnen Mitarbeiter wahrgenommen. Jede Rolle ist mit entsprechenden Aufgaben, Kompetenzen und Verantwortungen verbunden (vgl. Gutzwiller 1994). • Applikationsdomäne: Eine Applikationsdomäne ist eine logische Zusammenfassung von Applikationen zur Abwicklung eines Kernprozesses der konzeptionellen Ebene. Applikationsdomänen abstrahieren von konkreten Applikationen. Das Domänenkonzept dient zur Reduktion der Komplexität des Modells. • Owner: Jeder Applikationsdomäne ist ein verantwortlicher Eigentümer zugeordnet, der die übergeordnete Verantwortung für diese Applikationsdomäne hat. Der Owner kann entweder eine Organisationseinheit oder ein einzelner Mitarbeiter sein. • Geschäftsentität: Eine Geschäftsentität (z.B. eine Online-Bestellung, eine Rechnung oder eine Fakturierung) besteht aus Daten und der darauf operierenden Programmlogik. Geschäftsentitäten dienen als Basisbausteine, mit denen E-Services aufgebaut werden. Die Herausforderung liegt vor allem darin, die Integration von verschiedenen Geschäftsentitäten so einfach wie möglich zu gestalten, um das schnelle (ggf. dynamische) Bereitstellen von neuen E-Services zu ermöglichen. • Datenfluss (konzeptionell): Der Datenfluss auf konzeptioneller Ebene

ist der Input für oder der Output von einzelnen Prozessschritten. Beispiele sind Börsenauftrag, Partnerdaten, Buchung, usw.

214


führt aus

Owner

Rolle ist verantwortlich für

wird durchgeführt Applikationsmit Domäne

benötigt als Input

hat als Output

Prozess

Abb. 3:

verwaltet

Datenfluss (konzeptionell)

enthält Information aus/zu

Geschäftsentität (konzeptionell)

Metamodell der konzeptionellen Ebene (vereinfachte Darstellung)

4.1.2 Beispielhafte Modellierungsergebnisse auf der konzeptionellen Ebene Ziel der Modellierung auf konzeptioneller Ebene war die Darstellung der jeweiligen Applikationsdomänen, die Geschäftsprozesse bei der Durchführung unterstützen. Abbildung 5 zeigt Applikationsdomänen und Geschäftsentitäten, die bei der Durchführung des Prozesses „Börsenauftrag erfassen“ beteiligt sind. Zudem wird gezeigt, welcher Input (Depot-Positionen und Valoreninformationen) benötigt und welcher Output (Börsenauftrag) erzeugt wird.


Input Depotführung

Börse Erfassung Depot-Positionen

Portfoliomanagement

Internet-Banking Valorenverwaltung

215

Output

WS-Börsenauftrag

Auftragsverwaltung

WS-Börsenauftrag

Valoreninformationen

Anlageberatung

WS-Börsenauftrag

Applikationsdomäne

Abb. 4:

Beteiligte Applikationsdomänen und Geschäftsentitäten bei der Erfassung eines Börsenauftrags

Demnach kann ein Börsenauftrag entweder im „Portfoliomanagement“, im „Internet Banking“ oder in der „Anlageberatung“ erfasst werden. Dazu werden vorhandene Depotpositionen aus der Applikationsdomäne „Depotführung“ und „Valoreninformationen“ aus der Applikationsdomäne „Valorenverwaltung“ benötigt. Der Output nach der Erfassung ist ein „Börsenauftrag“, der an die Auftragsverwaltung übermittelt wird. Das gezeigte Beispiel gibt einen schnellen groben Überblick, welche Applikationsdomänen (die nur eine logische Strukturierung darstellen und noch nichts über konkrete Applikationen aussagen) bei der Erfassung eines Börsenauftrags beteiligt sind. Das Diagramm eignet sich beispielsweise zur Kommunikation gegenüber Fachfremden, die einen groben Überblick benötigen.

4.2

Logische Designebene

4.2.1 Eigenschaften des Modells auf der logischen Designebene Im Gegensatz zur konzeptionellen Ebene wird auf der logischen Designebene nicht mehr die ideale, redundanzfreie Sicht modelliert, sondern reale Applikationslandschaften. Auf der logischen Designebene soll die Implementierung aus fachlicher Sicht modelliert werden, ausgehend vom konzeptionellen Modell. Applikationsdomänen stehen jetzt in einem konkreten Kontext, d.h. sie repräsentieren physisch vorhandene Applikationen. Zu-

216


dem soll auf der logischen Ebene gezeigt werden, in welcher Art die einzelnen Datenflüsse aus dem konzeptionellen Modell konkret implementiert werden (z.B. über periodische Datenreplikation, über Service-Integration oder durch manuelle Datenintegration). Desweiteren werden auf der logischen Designebene die Schnittstellen modelliert und die Kommunikationsart und die Applikationsbeziehungen zwischen zwei oder mehreren Applikationen festgelegt. Auf der logischen Designebene erfolgt jedoch keine Top-Down-Modellierung von Applikationsdomänen zu Applikationen, sondern eine Zuordnung applikatorischer Funktionen zu Applikationsdomänen (welche Funktionalität wird innerhalb welcher Applikationsdomäne abgewickelt). Anzumerken ist, dass es auf der logischen Designebene zu Überschneidungen und Lücken in der Abdeckung des „idealen“ konzeptionellen Modells kommen kann, da die „reale Welt“ in der Regel nicht redundanzfrei ist. Folgende Abbildung zeigt das entwickelte Metamodell auf der logischen Designebene: Applikation

enthält

enthält

bietet an benötigt ist Client in ist Server in

Funktion

unterstützt

Geschäftsentität (logisch)

Geschäftsentität (konzeptionell)

Schnittstelle

Datenfluss (konzeptionell) implementiert

Applikationsbeziehung

entspricht

Logisches Modell

Abb. 5:

Applikationsdomäne

Logisches Muster

Konzeptionelles Modell

Metamodell der logischen Designebene (vereinfachte Darstellung)

Die Elemente des Metamodells der logischen Ebene wurden im Projekt folgendermassen definiert: • Applikation: Eine Applikation ist auf der logischen Designebene ein logisches Konstrukt, welches Services, Funktionen und Daten für den Benutzer und andere Applikationen zur Verfügung stellt. Die einzelnen Komponenten einer Applikation können von unterschiedlichen Herstel-


217

lern entwickelt und auf unterschiedlichen Systemplattformen implementiert sein. Für unsere Betrachtung werden zwei Arten von Applikationen unterschieden: Business-Applikationen, die der Umsetzung der Geschäftsprozesse dienen (Geschäftsanwendungen) Infrastruktur-Applikationen: darunter fallen Software-Pakete, für die Integration von Applikationen (Middleware, EAI-Software, Benutzer- und Rechte-Verwaltung) sowie geschäftsneutrale Anwendungen, mit denen der Benutzer arbeitet (MS-Office-Produkte, Browser, Content-Management, Portal, usw.) Auf der logischen Design-Ebene werden nur Business-Applikationen betrachtet, da sich die logische Designebene durch Unabhängigkeit von eingesetzter Infrastruktur oder Middleware auszeichnet. Die Umsetzung von Geschäftsprozessen durch Business-Applikationen steht auf dieser Ebene im Vordergrund. • Funktion: Eine Funktion wird zur Durchführung einer bestimmten Aufgabe benötigt. Sie operiert auf/mit Daten. Jede Funktion wird einer Applikationsdomäne zugeordnet. Funktionen mit hoher innerer und geringer äusserer Kopplung werden in Applikationen zusammengefasst. • Logische Geschäftsentität: Vgl. Definition im konzeptionellen Modell. • Schnittstelle: Wenn zwei Applikationen nach vereinbarten Regeln Daten und/oder Funktionen untereinander austauschen, erfolgt der Austausch über zwei definierte Schnittstellen der jeweiligen Applikationen. Schnittstellen werden von Applikationen zur Verfügung gestellt. • Applikationsbeziehung: Wenn zwei Applikationen nach vereinbarten Regeln Daten und/oder Funktionen untereinander austauschen, so besteht zwischen den beiden Applikationen eine Applikationsbeziehung. • Logisches Muster: Da Applikationsbeziehungen sehr vielfältig ausgeprägt sein können, wird zur Vereinfachung jeder Applikationsbeziehung ein bestimmtes Muster zugeordnet. Zuvor müssen die unterschiedlichen Muster definiert werden. Ein möglicher Ansatz zur Systematisierung von Applikationsbeziehungen mit Hilfe von Entwurfsmustern, der in dem Praxisprojekt entwickelt und verwendet wurde, ist in diesem Band zu finden (siehe Beitrag A. Schwinn: Modellierung von Integrationsaspekten in Applikationslandschaften). Um dem Anspruch der Referenzierung zwischen den Modellebenen gerecht zu werden, werden im logischen Modell die Applikationsdomänen,

218


die Geschäftsentität sowie der Datenfluss aus dem konzeptionellen Modell referenziert. Somit ist sichergestellt, dass das konzeptionelle Modell vollständig ist und aus den logischen Modellen auf das konzeptionelle navigiert werden kann.

4.2.2 Beispielhafte Modellierungsergebnisse auf der logischen Designebene Auf der logischen Designebene werden im Gegensatz zur konzeptionellen Ebene bereits konkrete Applikationen betrachtet. Die hier dargestellten Applikationen sind nicht notwendigerweise physisch entsprechend abgebildet, sondern es handelt sich hierbei um logische Kompositionen, die aus hunderten unterschiedlichster physischer Softwarekomponenten bestehen können. Aus dem Applikationskontextdiagramm in Abbildung 6 kann entnommen werden, welche logischen Applikationen beim Portfoliomanagement (Kontext) beteiligt sind. Die Applikationsbeziehungen sind hier gemäss einem logischen Muster dargestellt. Dabei wurde die Unterscheidung gemacht, ob es sich bei einer Applikationsbeziehung um einen Informationsbedarf (zu erkennen an einer ausgefüllten Pfeilspitze) oder um einen Verarbeitungsauftrag (zu erkennen an der doppelten Pfeilspitze) handelt. Die hier dargestellten Applikationsbeziehungen in Form von logischen Mustern orientieren sich an den im Beitrag Modellierung von Integrationsaspekten in Applikationslandschaften aufgezeigten Mustern.

PortfolioVerwaltungsauftrag

AGI-PE

AGI-GDH

Valorenverwaltung

Börsenauftrag

AGI-PMS

Geldhandelsgeschäft

Partner

219

Valoreninformation Valorenkurs


Saldo

A

Abb. 6:

Datenfluss

B

Depot-Position

Depotführung Buchung

WS-Geschäft

AGI-BF

Auftragsverwaltung

Auftragsabwicklung

Applikationsbeziehung zwischen Applikation A und B (Datenfluss in Pfeilrichtung) Unterschiedliche Pfeilarten implizieren verschiedene logische Muster

Applikationskontextdiagramm

Beim Austausch einer vorhandenen Applikation (z.B. Einführung einer Standardsoftware zum Portfoliomanagement) können mit Hilfe des Modells alle applikatorischen Abhängigkeiten aufgedeckt werden. In der hier dargestellten Form lässt sich zudem erkennen, an welchen Stellen der Applikationslandschaft Datenredundanz entsteht (erkennbar an den Datentöpfen, die auf eine Datenkopie hindeuten). Zur detaillierten Beschreibug von Applikationsbeziehungen wurden nicht nur bestimmte Muster zugeordnet, sondern zudem Templates angelegt, die die Applikationsbeziehungen weiter beschreiben. Im Projekt wurden die in folgender Tabelle dargestellten Attribute zur Beschreibung einer Applikationsbeziehung identifiziert:

220


Attribut

Wert (+Beispiel)

Name der Applikationsbeziehung

Der Name setzt sich zusammen aus dem Datenfluss (immer singular), dem Namen der Quellapplikation, dem Namen der Zielapplikation und einem Verb. Das Verb kann dabei „kopieren“, „übermitteln“ oder „anfragen“ sein. (z.B. Portfolioverwaltungsauftrag von APP_1 an APP_2 übermitteln)

Beteiligte Schnittstellen

Schnittstellenbezeichnung Quell-Applikation Schnittstellenbezeichnung Ziel-Applikation

Auslöser

Prosabeschreibung des Auslösers eines Ereignisses (aus Sicht des Konsumenten). (z.B.: Veränderung der Kundenadresse)

Periodizität

Periodizität des ausgelösten Ereignisses (z.B. alle 4 Stunden, regelmässig)

Mengengerüst

Wie oft wird die Schnittstelle in einem bestimmten Zeitraum verwendet? (z.B. ca. 500 mal pro Stunde)

Entspricht logischem Muster

Welchem logischen Muster entspricht die Applikationsbeziehung? (z.B. Informationsbedarf) (siehe Beitrag A. Schwinn: Modellierung von Integrationsaspekten in Applikationslandschaften)

Datenfluss

Angabe des konzeptionellen Datenflusses, der durch die Applikationsbeziehung implementiert wird. (z.B. Portfolioverwaltungsauftrag)

Tab. 1:

Template zur Beschreibung von Applikationsbeziehungen

Durch Hinterlegen dieser Attribute in einem Tool sind weitere Auswertungen möglich. Beispielsweise können Rückschlüsse auf Verarbeitungsgeschwindigkeiten durch Auswertung des Attributs „Periodizität“ geschlossen werden. Im Beispiel des Applikationskontextdiagramms könnten Rückschlüsse gezogen werden, wie aktuell die Daten im Portfoliomanagement sind oder wie lange es dauert, bis ein ausgeführter Börsenauftrag in der Portfoliomanagement-Applikation „sichtbar“ ist.


4.3

221

Physische Designebene

4.3.1 Eigenschaften des Modells auf der physischen Designebene Auf der physischen Ebene werden nun konkrete Implementierungen identifiziert, die die Überlegungen aus der logischen Sicht bestmöglich umsetzen können. Dazu werden konkrete Implementierungsarten identifiziert und aufgezeigt, welche Implementierung am Besten auf die Anforderungen aus dem logischen Modell passt. Dies erfolgt durch Auswahl der benötigten Applikations- und Infrastrukturkomponenten. Zuvor müssen diese jedoch identifiziert und beschrieben werden. Folgendes Metamodell wurde auf der physischen Ebene erarbeitet:

ist Client in setzt sich zusammen aus

Entwicklungstechnologie

Softwarekomponente

wird erstelllt mit

ist Eigentum von ist Hersteller von wird bezogen bei

Applikation

Implementierungsmuster

ist Server in

Schnittstellen- entspricht implementierung

benötigt für Betrieb

Betriebskomponente läuft auf Betriebsplattform

Firma

Abb. 7:

Metamodell der physischen Designebene (vereinfachte Darstellung)

Das Metamodell enthält in der hier vereinfacht dargestellten Version folgende Entitäten: • Applikation: Eine Applikation setzt sich auf der physischen Designebene nicht mehr aus fachlichen Funktionen und Geschäftsentitäten, sondern aus physisch vorhandenen Softwarekomponenten zusammen. • Schnittstellen-Implementierung: Implementiert eine Applikationsbeziehung aus der logischen Designebene. • Implementierungs-Muster: Da Applikationsbeziehungen sehr vielfältig ausgeprägt sein können, wird zur Vereinfachung jeder Schnittstellen-

222


Implementierung ein bestimmtes Muster zugeordnet. Zuvor müssen die unterschiedlichen Muster definiert werden. Die Definition ist analog der logischen Designebene, jedoch sind die Ausprägungen der Muster unterschiedlich. Ein physisches Muster setzt sich aus Implementierungsbausteinen zur Lösung konkreter, immer wiederkehrender Problemstellungen zusammen. • Softwarekomponente: Applikationen setzen sich aus Softwarekomponenten zusammen. Eine Softwarekomponente zeichnet sich durch folgenden Eigenschaften aus: Sie hat je einen bestimmten Eigentümer, Hersteller und Lieferanten Es gibt mindestens einen aktuellen freigegebenen Release Sie kann als Ganzes konfiguriert und ausgeliefert werden Der Betrieb erfolgt auf einer bestimmten Betriebskomponente (Infrastruktur) Sie wird mit einer bestimmten Entwicklungstechnologie entwickelt Sie bedarf der Wartung • Betriebskomponente: Eine Betriebskomponente ist ein technisches System (Subsystem), welches die unmittelbare Run-Time-Umgebung einer Software-Komponente bildet, unabhängig davon, ob sie auf einer dezidierten oder auf einer virtuellen Hardware installiert ist. Beispiele für Betriebskomponenten wären CICS-Umgebungen, Datenbankserver mit Datenbankmanagementsystem (z.B. DB2), usw. • Betriebsplattform: Betriebskomponenten laufen auf Betriebsplattformen. Beispiele für Betriebsplattformen wären OS/390, Windows oder Unix. • Entwicklungstechnologie: Entwicklungstechnologien, z.B. J2EE eignen sich zur Erstellung von Applikationen respektive Softwarekomponenten. • Firma: Werden Softwarekomponenten nicht selbst hergestellt (z.B.

Kauf einer Standardsoftware) wird sie von einer Firma geliefert und/oder entwickelt.


223

4.3.2 Beispielhafte Modellierungsergebnisse auf der physischen Designebene Auf der physischen Designebene wird der Entwurf konkreter Implementierungen zu den Anforderungen aus dem logischen Design betrachtet. Dazu wurde zunächst versucht, physische Schnittstellenbeziehungen zu systematisieren. Eine Unterscheidung kann dabei nach verwendetem MessageTyp, nach Integrationsebenen (Präsentationsebene, Funktionsebene (Service-Integration) und Datenebene) oder nach der Art der Implementierung (z.B. synchrone Message) getroffen werden. Da die Ergebnisse der physischen Designebene sehr unternehmensspezifisch sind, wird hier kein exemplarisches Ergebnisdokument vorgestellt, das die vorhandenen Implementierungen auf den Ebenen Funktion, Daten und Präsentation darstellt. Ein Implementierungsbaustein ist der zu verwendende Message-Typ. Zur Unterstützung einer Implementierungsentscheidung wurden unterschiedliche Message-Typen untersucht, die überwiegend nicht unternehmensspezifisch sind, und hier vorgestellt werden können. Zur Verwendung der einzelnen Message-Typen wurden jeweils Vor- und Nachteile identifiziert. Dadurch kann die Entscheidung, bei welcher Anforderung welcher Message-Typ zur Anwendung kommen soll, erleichtert werden. Folgende Tabelle zeigt die Systematisierung von Messages mit ihren jeweiligen Vorund Nachteilen: Messages mit selbst definierten Format Vorteile

Nachteile

•

•

• • • •

Etabliert in der Swisscom IT Services-Umgebung Teil der internen Schichtenarchitektur Breite Anwendung Durchgängiger Konstruktions- und Fertigungsprozess Record-Struktur ist in Metadaten definiert

• •

Proprietär, API (Application Programming Interface) muss für jede Plattform implementiert werden. Die Metadaten müssen Client- und Server-seitig vorhanden sein Release-Abhängigkeit gross

224


Messages mit flachen Records und fixer Struktur Vorteile

Nachteile

•

•

• • •

Strukturdefinition statisch, muss somit nicht mitübertragen werden Einfaches Lesen möglich, da eine „Schablone“ über die Daten gelegt werden kann Die fixe Struktur kann durch HeaderDateien (Compilation) definiert sein Hohe Performance

•

Strukturdefinition muss Client- und Server-seitig verteilt werden Release-Abhängigkeit gross

Messages mit flachen Records und variabler Struktur Vorteile

Nachteile

•

•

•

Strukturdefinition muss mitübertragen werden Variante 1: Feld-Identifikation Variante 2: lediglich Trennzeichen Release-Abhängigkeit bei Variante 1 kleine Records, variable Struktur

•

Variante 2 zum Lesen komplizierter, da die Position detektiert werden muss Release-Abhängigkeit bei Variante 2 gross

Messages mit XML-Struktur/Baumstruktur Vorteile

Nachteile

•

• • •

• • •

Übertragung der Strukturinformation auf Message (zugleich auch ein Nachteil: Verhältnis Nutzdaten zu Strukturinformation) XML sorgt dafür, dass eine bestimmte Datenstruktur eindeutig bleibt Kann vom Menschen leichter gelesen werden Release-Abhängigkeit klein

•

Langsam durch das Parsen „lesbar und doch nicht lesbar“ Lesbarkeit bedeutet Optimierung für den Menschen und nicht für den Rechner XML-Dateien sind typischerweise grösser als vergleichbare binäre Formate

Messages mit externen Standardformaten, z.B. SWIFT Vorteile

Nachteile

• •

• •

•

Definierte und abgestimmte Formate Wichtig bei Datenaustausch, welcher über die Grenzen einer Unternehmung hinausgeht Die Verantwortung und Durchsetzung für das Format ist bestimmt

• •

Tab. 2:

Abstimmungsgremien notwendig Einhaltung von weiteren externen Vorgaben (z.B. Termine bezüglich Einführung, Änderung eines Formates) Release-Abhängigkeit gross, vor allem zu Beginn des Lifecycles eines solchen Formates Anpassungsmöglichkeiten gering, da fremdgetrieben/vorgegeben

Message-Typen mit ihren Vor- und Nachteilen


225

Da in der Swisscom IT Services-Umgebung eine Applikationsintegration massgeblich über Messages erfolgt, stellt sich immer wieder die Frage, welcher Messagetyp am Besten für eine bestimmte Anforderung geeignet ist und wie einzelne Vor- und Nachteile gegeneinander aufgewogen werden können. Die in Tabelle 2 dargestellte Systematisierung kann solche Entscheidungen erleichtern.

4.4

Implementierungsebene

4.4.1 Eigenschaften des Modells auf der Implementierungsebene Auf der Implementierungsebene werden nun konkrete Sachverhalte modelliert, die zur direkten Umsetzung durch Entwickler verwendet werden können. Bei der Implementierungssicht stehen keine Design-Fragen mehr im Vordergrund, sondern die Umsetzung der Ergebnisse aus dem physischen Design. Auf der Implementierungsebene werden konkrete Programmnamen, Message-Namen, usw. angegeben. Zur systematischen Darstellung der unterschiedlichen Diagramme wurden Notationen erarbeitet, um die relevanten Elemente (siehe Abb. 8) modellieren zu können. Das Beispiel in Abbildung 9 zeigt exemplarisch eine Notation zum Transfer einer Message zwischen zwei Softwarekomponenten über eine Queue. Betriebskomponente A Software-Komponente A Module A (Client) Message M.... Queue Q... Betriebskomponente B

Message M....

Software-Komponente B Module B (Server)

Abb. 8:

Notation Message-Transfer

226

4.5


Beispielhafte Modellierungsergebnisse auf der Implementierungsebene

Auf der Implementierungsebene wurden Ergebnisse entwickelt, die unmittelbar von Entwicklern zur Umsetzung verwendet werden können. Da die Dokumente auf der Implementierungsebene noch unternehmensspezifischer als auf der physischen Designebene sind, wird hier nur ein exemplarisches Beispiel dargestellt. Dabei handelt es sich um ein Schnittstellenimplementierungsdiagramm, das zur Implementierung einer Schnittstelle von Entwicklern verwendet wird. Darauf abgebildet sind alle Informationen (wie Betriebsplattformen, Betriebkomponenten, Softwarekomponenten, Programmnamen, Message-Namen, Queues, usw.), die zur Implementierung der Schnittstelle aus dem physischen Design für einen Entwickler erforderlich sind. Folgende Abbildung zeigt ein Beispiel eines Schnittstellenimplementierungsdiagramms:


227

Börsenauftrag eröffnen

Legende: Betriebsplattform

Betriebskomponenten

Softwarekomponenten

Module

Abb. 9:

Schnittstellenimplementierungsdiagramm

Die einheitliche Beschreibung über definierte Dokumenttypen wie beispielsweise dem Schnittstellenimplementierungsdiagramm erleichtert es den Entwicklern Lösungen umzusetzen und es können konkrete Schulungen durchgeführt werden. In dem Projekt wurde ein Teil der Ergebnisse in einem Modellierungstool (Rational Rose) hinterlegt, auf das die Entwickler direkten Zugriff haben und somit auch die kontinuierliche Pflege der Dokumente sichergestellt werden kann. Generell stellt die Pflege der Do-

228


kumentation ein Problem dar, weshalb versucht wurde die Ergebnisdokumente möglichst einfach mit den wesentlichen Elementen zu gestalten.

5

Zusammenfassung

Der vorliegende Beitrag hat eine kleine Auswahl von Ergebnissen aus einem Projekt zwischen dem Institut für Wirtschaftsinformatik der Universität St. Gallen und der Swisscom IT Services AG (Banking Solutions) präsentiert. Die Bildung von Modellierungsebenen und Sichten erleichtert die Erstellung von Dokumenten und verringert die Komplexität. Es wurde versucht die Ergebnisdokumente einfach und verständlich zu gestalten, um eine unnötige Überladung zu vermeiden. Derzeit wird das Modell weiter verfeinert, und einzelne Ergebnisse kamen in ersten Projekten zum Einsatz. Zudem wurde ein Prototyp erstellt, der auf Rational Rose basiert und eine konsistente Hinterlegung der Dokumente in einem gängigen Tool ermöglicht. Da Rational Rose ebenso in der Softwareentwicklung und -dokumentation bei der Swisscom IT Services AG eingesetzt wird, können Programme und Messages direkt referenziert werden, wodurch zusätzliche Medienbrüche vermieden werden.


229

Literatur O.V.: Advanced Technologies and a Sense of Process, Aberdeen Group Report, Boston/MA, 1998. Becker, J.; Schütte, R.: Handelsinformationssysteme, Landsberg/Lech, 1996. Dangelmaier, W.; Lessing, H.; Pape, U.; Rüther, M.: Klassifikation von EAI-Systemen, in: HMD Praxis der Wirtschaftsinformatik (2002), 225, S. 61-71. Erasala, N.; Yen, D.C.; Rajkumar, T.M.: Enterprise Application Integration in the electronic commerce world, in: Computer Standards & Interfaces, 25 (2003), S. 69-82. Ferstl, O.K.; Sinz, E.J.: Grundlagen der Wirtschaftsinformatik, 3. Aufl., München, 1998. Frank, U.: Multiperspektivische Unternehmensmodellierung: Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung, München, 1994. Gutzwiller, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Heidelberg, 1994. Heinrich, L.J.: Grundlagen der Wirtschaftsinformatik, in: Rechenberg, P.; Pomberger, G. (Hrsg.): Informatik-Handbuch, München/Wien, 1999, S. 1019-1034. Holten, R.: Integration von Informationssystemen, in: Wirtschaftsinformatik, 45 (2003), 1, S. 41-52. Krallmann, H.: Transformation einer industriell geprägten Unternehmensstruktur zur einer service-orientierten Organisation, Leipzig, 04.02.2003, Institut für Wirtschaftsinformatik, Universität Leipzig, Wirtschaftswissenschaftliche Fakultät, 2003. Lehner, F.; Maier, R.; Hildebrand, K.: Wirtschaftsinformatik: Theoretische Grundlagen, München/Wien, 1995. Leist, S.: Bankenarchitektur des Informationszeitalters - Zielsetzung und Gestaltungsebenen, in: Leist, S.; Winter, R. (Hrsg.): Retail Banking im Informationszeitalter, Berlin, 2002, S. 4-28. Linthicum, D.S.: Enterprise Application Integration, AWL Direct Sales, Massachusetts, 2000. Mertens, P.: Was ist Wirtschaftsinformatik?, in: Mertens, P.; Chamoni, P.; Ehrenberg, D.; Griese, J.; Heinrich, L.J.; Kurbel, K. (Hrsg.): Studienführer Wirtschaftsinformatik, 2. Aufl., Braunschweig, 1999, S. 1-6. Mertens, P.: Integrierte Informationsverarbeitung, 12. Auflage, Wiesbaden, 2000. Mertens, P.: Lexikon der Wirtschaftsinformatik, Berlin, 2001.

230


Österle, H.: Business Engineering: Prozess- und Systementwicklung, 2. Aufl., Berlin et al., 1995. Ring, K.; Ward-Dutton, N.: Enterprise Application Integration: Making the Right Connections, London, 1999. Ruh, W.A.; Maginnis, F.X., Brown, W.J.: Enterprise Application Integration, New York et al., 2001. Scheer, A.-W.: Wirtschaftsinformatik - Referenzmodelle für industrielle Geschäftsprozesse, 2. Auflage, Berlin/Heidelberg, 1998. Schütte, R.: Grundsätze ordnungsmässiger Referenzmodellierung, Wiesbaden, 1998. Schwinn, A.: Modellierung von Applikationslandschaften und Applikationsbeziehungen auf konzeptioneller und logischer Ebene, Working Paper, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen, 2003. Sinz, E.J.: Architektur von Informationssystemen, in: Rechenberg, P.; Pomberger, G. (Hrsg.): Informatik-Handbuch, München/Wien, 1999, S. 1035-1046. Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: Österle, H.; Winter, R. (Hrsg.): Business Engineering, Berlin et al. 2003a, S. 87-118. Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: Österle, H.; Winter, R. (Hrsg.): Business Engineering, 2. Aufl., Berlin et al. 2003b, S. 87-118.

Architekturmanagement – Rahmen und Realisierung der Unternehmensarchitektur der Mobiliar Andreas Dietzsch Schweizerische Mobiliar

Die Schweizerische Mobiliar hat eine lange Tradition in der Entwicklung und dem Betrieb von Applikationen zur Unterstützung ihrer Geschäftsprozesse. Um innerhalb der gewachsenen Applikationslandschaft die Erfüllung von Geschäftsanforderungen auf der einen Seite und den aus einem zunehmenden Kostenbewusstsein resultierenden Anforderungen auf der anderen Seite auch zukünftig gerecht werden zu können, erfolgte im Jahr 2002 der Aufbau der Unternehmensarchitektur. Der Beitrag beschreibt vor diesem Hintergrund, wie die Unternehmensarchitektur gegenüber den internen Kunden positioniert und in die Unternehmensprozesse der Strategieentwicklung sowie Projektplanung und -umsetzung eingebunden wurde. Er stellt weiterhin dar, wie in diesem Umfeld die Flexibilität der Unternehmensarchitektur sichergestellt wird.

1 2 3

4

5

Einleitung ........................................................................................ 232 Hintergrund ..................................................................................... 233 Grundlagen des Architekturmanagements ...................................... 234 3.1 Der Architektur-Begriff .......................................................... 234 3.2 Zweck von Architekturen ....................................................... 236 3.3 Wirkungsebenen von Architekturen ....................................... 237 3.4 Phasen des Architekturmanagements...................................... 239 Positionierung der Unternehmensarchitektur.................................. 240 4.1 Kunden der Architektur .......................................................... 240 4.2 Form der Leistungerbringung ................................................. 241 Gestaltung der Unternehmensarchitektur........................................ 245 5.1 Rahmen ................................................................................... 245

232

A. Dietzsch

5.2 Fokus....................................................................................... 248 5.3 Philosophie.............................................................................. 250 5.4 Organisation............................................................................ 251 5.5 Anforderungen an die Rolle des Architekten.......................... 254 6 Management der Unternehmensarchitektur .................................... 255 6.1 Abstimmung mit der Strategieentwicklung ............................ 256 6.2 Abstimmung mit dem Portfoliomanagement .......................... 258 6.3 Integration in Umsetzungsprojekten ....................................... 259 6.4 Absicherung der Flexibilität der Architektur .......................... 259 7 Zusammenfassung........................................................................... 265 Literatur ................................................................................................ 266

1

Einleitung

Die Schweizerische Mobiliar Versicherungsgesellschaft (Die Mobiliar) bietet Dienstleistungen für Privatpersonen, Unternehmen und den öffentlichen Sektor an. Gegründet 1826 ist sie die erste private Versicherung der Schweiz. Seit 1948 betreibt die Mobiliar Datenverarbeitung im Unternehmen und seit 1964 erfolgt dies in Verantwortung des Bereichs Informatik. Als in der Mitte der 1990er Jahre der Schweizer Versicherungsmarkt dereguliert wurde, bestand die Applikationslandschaft der Mobiliar aus einer breiten Palette, hauptsächlich eigenentwickelter Applikationen. Die Komplexität dieser gewachsenen Applikationslandschaft ist zum einen ein wesentlicher Treiber der IT-Kosten. Zum anderen erschwert sie die Anpassung der Dienstleistungen der Informatik an die Bedürfnisse der Fachbereiche. Um diese Situation zu überwinden, erfolgte der Aufbau und erfolgt der Betrieb der Unternehmensarchitektur unter Leitung von Peter Kummer als Chef-Architekt. Wie diese in der Mobiliar positioniert wurde und wie ein nutzenstiftendes Betreiben der Unternehmensarchitektur sichergestellt wird beschreibt dieser Beitrag.


2

233

Hintergrund

Das Thema “Architektur” wurde in der Mobiliar erstmals in der Mitte der 1960er Jahre im Zusammenhang mit Hardware-orientierten AssemblerArchitekturen diskutiert (siehe Abb. 1). Unternehmensarchitektur

Business Architektur

Integrations-Architekturen für Informationssysteme

Daten-Architektur

Benutzerschnittstellen-fokussierte Architektur

Hardware-orientierte Architektur

IT in der Mobiliar

1940

Abb. 1:

1950

1960

1970

1980

1990

2000

Historie der Architekturansätze in der Mobiliar

Die Umsetzung modellbasierter Architekturen beginnt 1992 mit der Beschaffung und dem Einsatz der IBM Insurance Application Architecture (IAA), einem Referenzmodell für Daten und Funktionen im Bereich der Assekuranz. Die Architekturleistungen beschränken sich zu dieser Zeit primär auf die Bereitstellung konsistenter Datenstrukturen und die in diesem Zusammenhang einheitliche Umsetzung aller Geschäftsanforderungen. Dabei besitzt die Verwaltung von Artefakten sowie die Vorgabe und Durchsetzung von Richtlinien eine sehr hohe Bedeutung. Hingegen stand zu dieser Zeit die Standardisierung von Geschäftsprozessen sowie des der Applikationslandschaft zugrunde liegenden Technologieportfolios nicht im Mittelpunkt der Architekturaktivitäten. Ende der 1990er Jahre wurde beschlossen, für die Bestandesführung ein Standardsoftwaresystem einzuführen. Dabei wurde davon ausgegangen, dass für die Integration und den Betrieb eines Standardsoftwaresystems Architekturleistungen nur noch in minimalem Umfang erforderlich sind. Deshalb wurde ein Architekturansatz verfolgt, der keine zentrale Koordination von Architekturaktivitäten vorsah. Dies hatte zur Folge, dass „die Architektur“ einen im Wesentlichen reaktiven Charakter besass und kaum in Projekten verankert war. Als Konsequenz davon besass diese Form der Architektur keine Akzeptanz im Unternehmen und zeigte keine Wirkung.

234

A. Dietzsch

Verbunden mit einem Projekt zur prozessorientierten Umgestaltung der Unternehmensstruktur wurde 1999 die Business Architektur (BUSA) aufgebaut. Vor dem Hintergrund der beschriebenen Erfahrungen erfolgte die Entwicklung der Business Architektur in einer zentralen Organisationseinheit. Der Schwerpunkt der Aktivitäten wurde jedoch auf eine aktive Mitwirkung in Projekten gelegt. Zum Ende des Jahres 2001 wurden die Bereiche Geschäftsentwicklung und Informatik zusammengelegt. Damit wurde der Betrachtungsbereich der bis dahin auf die Geschäftsprozesse fokussierten Architektur auf einen unternehmensweiten Ansatz ausgedehnt. Mit einer weiteren Reorganisation der Unternehmensstruktur zum Beginn des Jahres 2003 wurde der Aufgabenbereich der Unternehmensarchitektur um Aufgaben erweitert, die aus der Zusammenführung mehrerer bis dahin weitgehend voneinander unabhängiger Applikationslandschaften resultieren. Die nachfolgenden Kapitel beschreiben, wie die Unternehmensarchitektur in diesem Kontext aufgebaut und als kontinuierlicher, in der gesamten Mobiliar wirkender Prozess etabliert wurde.

3

Grundlagen des Architekturmanagements

3.1

Der Architektur-Begriff

Wie im vorangegangenen Abschnitt dargestellt, wurden in der Mobiliar seit den 1960er Jahren verschiedene Architekturansätze verfolgt. Im Fokus architekturzentrierter Aktivitäten lagen dabei stark unterschiedliche Bereiche. Deshalb hatte sich über den Gegenstand und Wirkungsbereich einer Architektur kein einheitliches Verständnis herausgebildet. Dieses Verständnis bestimmt jedoch die Gestaltungskompetenz und Umsetzungsverantwortung, die mit einem Architekturansatz verbunden werden. Für die Realisierung des übergreifenden Ansatzes einer Unternehmensarchitektur war es deshalb erforderlich, das Konzept der „Architektur“ im Unternehmen allgemeingültig zu bestimmen. Die Vielfalt an Publikationen zum Thema Architektur im Allgemeinen und insbesondere im Bereich der Software-Systementwicklung bietet zahlrei-


235

che Ansätze zur Definition des Begriffs Architektur19. Über eine ausschliesslich auf Strukturen fokussierende Betrachtung geht die Definition des ANSI Standards 1471-2000 hinaus. Dieser beschreibt eine Architektur als grundlegende Organisation eines Systems, bestehend aus seinen Komponenten, deren Beziehungen zueinander sowie der Umgebung und den Prinzipien, die seinen Entwurf und seine Entwicklung bestimmen. Diese Elemente können dabei, in Abhängigkeit von der betrachteten Domäne, physische oder logische Komponenten oder auch bestimmte Prinzipien bzw. Muster sein, die Strukturen organisieren (vgl. O.V. 2000). Damit werden unter dem Begriff „Architektur“ sowohl Betrachtungs- und Wirkungsgegenstand als auch die auf diese angewendeten Prozesse zusammengefasst. Dieses Verständnis war ebenfalls Basis der Definition des Architekturbegriffs in der Mobiliar. Betrachtungs- und Wirkungsgegenstand der Unternehmensarchitektur sind dabei die Strukturen eines Systems. Dieses kann in Anlehnung an Rechtin alle Aspekte des Unternehmens von der Organisation bis hin zu einzelnen Applikationen oder Verbünden mehrerer Systeme umfassen (vgl. Maier/Rechtin 2002).20 Für eine praktische Realisierung einer Unternehmensarchitektur fasst diese Definition den Wirkungsbereich der Architektur jedoch zu weit. Aus diesem Grund wurde in der Mobiliar der Fokus der Architektur auf komplexe Strukturen eingeschränkt. Das heisst, dass durch die Architektur primär solche Systeme betrachtet und gestaltet werden, die eine Vielzahl unterschiedlicher Elemente besitzen, die wiederum durch eine hohe Zahl von Abhängigkeiten miteinander in Beziehung stehen. Für die Mobiliar ist 19

20

In der 1. Hälfte des 16. Jhdt. wird Architekt in der dem griechischen archtekton angelehnten Bedeutung des „Oberzimmermanns“ verwendet. (dabei arch(i) als „das erste sein, vorangehen“ und tekton „Zimmermann, Handwerker“ bzw. téchne „Kunst, Geschick, Handwerk“) (vgl. Pfeifer 1999). Architektur kann deshalb als „die Kunst voranzugehen“ in einem Sinne aufgefasst werden, dass durch die Architektur der Gestaltungsraum für eine Lösung bestimmt wird. Einen umfassenden Überblick über Definitionen des des Begriffs „Software Architecture“ ist unter http://www.sei.cmu.edu/architecture/definitions.html zu finden. Der Begriff „Struktur“ wird für die Menge an Elementen eines Systems sowie die zwischen diesen Elementen bestehenden Beziehungen und die Regeln verwendet, die ein „geordnetes“ Zusammenfügen dieser Elemente gewährleisten. Der Begriff basiert damit auf der ursprünglichen Bedeutung des lat. structura, der „das ordentliche Zusammenfügen, die Ordnung“ bezeichnet (vgl. Pfeifer 1999).

236

A. Dietzsch

deshalb Architektur definiert als eine planvoll geschaffene, komplexe Struktur und die Prozesse, die zu deren Konzeption, Konstruktion und Veränderung erforderlich sind.

3.2

Zweck von Architekturen

In der Mobiliar besteht das Hauptziel des Betreibens einer Unternehmensarchitektur in der Verringerung von Risiken bei Veränderungsprozessen, die sich auf die Struktur des Unternehmens auswirken. Dabei soll durch die Unternehmensarchitektur abgesichert werden, dass alle Veränderungen ausgehend von den Geschäftsprozessen bis zu deren Unterstützung durch adäquate Informationssysteme durchgängig geplant und umgesetzt werden. Die Unternehmensarchitektur soll das Unternehmen in die Lage versetzen Komplexität auf allen Ebenen (Geschäftsprozesse, Applikationen, Technologien) zu beherrschen und damit langfristig Handlungsoptionen zu schaffen und zu bewahren. Diese grundlegenden Ziele bilden die Basis für weitere Teilziele, die mit dem Betreiben der Unternehmensarchitektur in der Mobiliar verbunden sind (siehe Abb. 2).

Ausrichtung der IT an den Geschäftsprozessen ermöglichen

Harmonisieren von Geschäfts-, Funktionalund IT-Strategie(n)

Beitrag zur Erreichung von Geschäftszielen

Risiken bei Veränderungen reduzieren

Bereitstellen von Standards and Richtlinien Komplexität beherrschen Definition einer gemeinsamen begrifflichen Basis

Identifikation von Effizienzpotenzialen Handlungsoptinen schaffen und wahren Bewahren und Kommunizieren von Wissen

Abb. 2:

Ziele des Betreibens einer Unternehmensarchitektur in der Mobiliar

Eines der wichtigsten Ziele in der Mobiliar war es, die erfolgreich aufgebaute und etablierte Business Architektur effektiv mit den Entwicklungsund Betriebsprozessen des Bereichs Informatik zu verbinden. Durch die Unternehmensarchitektur wird sichergestellt, dass die IT-Strategie und die


237

daraus abgeleiteten Massnahmen an der Unternehmensstrategie ausgerichtet sind. Damit wird das Erreichen der Geschäftsziele des Unternehmens durch die Aktivitäten im IT-Bereich unterstützt (siehe Abschnitt 6.1). Nach einer fast 40-jährigen, kontinuierlichen Entwicklung ist die Applikationslandschaft der Mobiliar durch eine hohe Komplexität charakterisiert. Diese resultiert aus einer Vielzahl von Applikationen, die in unterschiedlichen Umgebungen erstellt und betrieben worden sind und werden. Damit wurden die Handhabung und die Reduktion dieser Komplexität zu einem weiteren Ziel der Umsetzung einer Unternehmensarchitektur. Um dies zu erreichen, werden mit der Unternehmensarchitektur der Mobiliar zu nutzende Standards, gemeinsame Dienste, Daten und Richtlinien definiert. Damit wird eine gemeinsame, insbesondere begriffliche Basis für Veränderungen an Prozessen, der Applikationslandschaft und der technologischen Basis gebildet. Als Konsequenz davon schafft die Umsetzung der Unternehmensarchitektur Handlungsspielraum für eine an den Geschäftsanforderungen ausgerichtete Weiterentwicklung der Applikationslandschaft. Daneben ermöglicht die systematische Dokumentation der Elemente der Unternehmensarchitektur sowie der zwischen diesen bestehenden Abhängigkeiten das Lokalisieren von Effizienzpotentialen. Damit wird Wissen über das Informationssystem des Unternehmens gespeichert und es wird möglich, dieses weiterzuentwickeln und zu kommunizieren. Dies wiederum erlaubt effiziente Investitionen, insbesondere in die Weiterentwicklung der Applikationslandschaft.

3.3

Wirkungsebenen von Architekturen

Mit Blick auf die dargestellten Ziele ist es für den Aufbau des Architekturmanagements von wesentlicher Bedeutung, die Ebenen zu kennen, auf denen eine Architektur wirkt. Dabei kann zum einen die Stufe der Abstraktion betrachtet werden. Bei dieser kann man zwischen einer konzeptionellen Ebene und einer Realisierungsebene, auf der Konzeptionen umgesetzt werden, unterscheiden. Zum anderen ist die Wirkung einer Architektur nach ihrem Zeitbezug zu unterscheiden, d.h. danach, ob sie den gegenwärtigen Zustand dokumentiert oder den Rahmen für künftige Lösungen beschreibt (siehe Abb. 3).

Konzeptionelle Ebene

A. Dietzsch Dokumentation der bestehenden Situation in Form von Architekturmodellen. Definition erforderlicher Massnahmen.

Dokumentation der angestrebten Situation in Form von Architekturmodellen. Beschreibung des Vorgehens zur Umsetzung geplanter Massnahmen.

Ist-Architektur

Realisierungsebene

Stufe der Abstraktion

238

Zielarchitektur

Architekturumsetzung

Lösungen, die innerhalb des durch die Zielarchitektur gegebenen Rahmens entwickelt werden.

gegenwartsbezogen

zukunftsbezogen Zeitbezug

Abb. 3:

Wirkungsebenen einer Unternehmensarchitektur

Die wesentlichen Architekturergebnisse auf der konzeptionellen Ebene sind die Ist- und die Zielarchitektur, die das bestehende bzw. geplante Gefüge aus Geschäftsprozessen, Informationssystemen und Technologien abbilden. Die Ist-Architektur ermöglicht die Ausrichtung der IT an den Geschäftsanforderungen, indem sie einen gemeinsamen Rahmen für die Dokumentation der Geschäftsprozesse und des funktionalen Umfangs der Applikationslandschaft bildet. Die Abdeckung der aus den betrieblichen Abläufen resultierenden Geschäftsanforderungen durch die bereitgestellten Informationssysteme kann somit systematisch analysiert werden. Durch die transparente Dokumentation wesentlicher Elemente und Beziehungen zwischen den Prozessen, Informationssystemen und Technologien durch die Ist-Architektur ist es mit der Zielarchitektur möglich, Veränderungen systematisch zu konzipieren. Durch die Fokussierung auf wesentliche Elemente und Beziehungen wird die Komplexität der Veränderungsprozesse und damit letztlich auch der veränderten Systeme beherrschbar. Durch die Architekturumsetzung werden die Potentiale realisiert, die sich aus der Umgestaltung der Ist- zur Zielarchitektur ergeben. Damit trägt die Architektur dazu bei, neue Handlungsoptionen für künftige Veränderungsprozesse zu schaffen bzw. bereits bestehende zu nutzen.


3.4

239

Phasen des Architekturmanagements

Die Prozesse des Architekturmanagements müssen die verschiedenen Wirkungsbereiche einer Architektur berücksichtigen. Dabei ist sowohl die Ebene bereits umgesetzter bzw. geplanter (konkreter) Lösungen als auch deren Konzeption und Erstellung durch das Architekturmanagement abzudecken. Daraus ergaben sich in der Mobiliar drei wesentliche Phasen beim Aufbau des Architekturmanagements. Dies ist: • die Positionierung der Unternehmensarchitektur gegenüber den internen Kunden, • die Gestaltung der Unternehmensarchitektur als Instrument für Veränderungen im Unternehmen sowie • das Management der Unternehmensarchitektur, d.h. die Umsetzung der Architekturkonzepte und das Betreiben der Architekturprozesse. Im Rahmen der Positionierung wird die Unternehmensarchitektur mit Bezug zur Aufbauorganisation und den Prozessen des Unternehmens eingeordnet. Die Positionierung der Architektur erfolgt ausschliesslich auf der konzeptionellen Ebene. Im Rahmen dieses Prozesses werden die durch die Architektur bereitgestellten Leistungen (WAS) und die Form, in der diese den Kunden bereitgestellt werden, festgelegt. Während die Positionierung die Aussensicht auf einen Unternehmensarchitektur-Ansatz bestimmt, wird mit deren Gestaltung die organisatorische Umsetzung des Ansatzes (WIE) definiert. Hierbei wird festgelegt, welche Teilarchitekturen die Unternehmensarchitektur subsumiert und welche Leistungen durch diese bereitgestellt werden. Weiterhin werden die Philosophie der Leistungserbringung und die Form der Organisation der Unternehmensarchitektur bestimmt. Positionierung und Gestaltung der Unternehmensarchitektur bilden Rahmen für die Dokumentation der Ist-Architektur des Unternehmens, die darauf aufbauende Entwicklung einer Zielarchitektur sowie deren Umsetzung. Das Betreiben und Steuern der Prozesse, die für die Realisierung der konzeptionellen Zielarchitektur erforderlich sind, ist der Zweck des Managements der Unternehmensarchitektur. Dabei ist die Einbindung in angrenzende Unternehmensprozesse zu realisieren. Anhand dieser Phasen werden nachfolgend die Positionierung, Ausgestaltung und die Form des Betreibens der Unternehmensarchitektur beschrieben.

240

A. Dietzsch

4

Positionierung der Unternehmensarchitektur

Im Rahmen des Aufbaus der Unternehmensarchitektur in der Mobiliar wurde in einem ersten Schritt der Architekturansatz mit seinen wesentlichen Merkmalen entworfen und mit Bezug zu den Unternehmensprozessen und -strukturen positioniert. Dazu wurden zunächst die Kunden identifiziert und anschliessend die Grundsätze bestimmt, nach denen die Architektur diesen Kunden gegenüber auftritt. Damit wurde festgelegt, in welcher Form die Architekturleistungen erbracht werden.

4.1

Kunden der Architektur

In Abhängigkeit von der Wirkungsebene, auf der Architekturergebnisse entstehen, müssen durch die Architektur unterschiedliche (potenzielle) Kundengruppe berücksichtigt werden (siehe Abb. 4).

.

Konzeptionelle Ebene Realisierungsebene

Stufe der Abstraktion

In Anlehnung an Armour et al. (1999) sind die wesentlichen Kunden der Architektur die Unternehmensleitung, die Auftraggeber, die Entwickler der Prozesse und Informationssysteme, deren Betreiber sowie die ProzessWorker und Anwender der Informationssysteme.

Unternehmensleitung

Ist Architektur -

Auftraggeber

Zielarchitektur

Systementwickler Architekturumsetzung

Systembetreiber

Systembetreiber

gegenwartsbezogen

zukunftsbezogen Zeitbezug

Abb. 4:

Kunden von Architekturergebnissen

• Die Unternehmensleitung ist ein wesentlicher Kunde der Architektur. Sie nutzt die Zielarchitektur als Instrument der Entscheidungsunterstützung indem Vorhaben hinsichtlich ihres Beitrags zu geplanten Veränderungen des Unternehmens beurteilt werden. Die Architektur wird da-


241

bei sowohl zur Unterstützung von Entscheidungen über das gesamte Projektportfolio als auch über einzelne Projekte verwendet. • Auftraggeber veranlassen und finanzieren Projekte. Sie ermöglichen somit die Realisierung der Zielarchitektur. Sie nutzen die Ist-Architektur zum Erkennen von Verbesserungspotentialen und die Zielarchitektur, um bewerten zu können, in welchem Umfang die Realisierung dieser Potentiale vorgesehen ist. Sie bestimmen wesentlich die funktionalen Anforderungen an die Zielarchitektur. Da in der Mobiliar die Prozessverantwortlichen ebenfalls Eigentümer der in ihren Prozessen genutzten Informationssysteme sind, stellen Prozesseigner und -verantwortliche die primären Auftraggeber der Unternehmensarchitektur dar. Die Perspektiven aller Auftraggeber und deren Anforderungen bestimmen den Fokus der Architektur. Sie sind die Grundlage für Akzeptanzkriterien und die Abschätzung von Terminplänen, Budgets, sowie Machbarkeit und Risiken. • Die Entwickler erstellen bzw. integrieren Lösungen im Rahmen von Projekten. Für sie muss die Zielarchitektur eine ausreichend detaillierte Grundlage des Prozess- bzw. Systementwurfs sein. Gleichzeitig muss die Zielarchitektur Freiheitsgrade für die Lösungsfindung bieten, um auf spezifische, nicht vorhersehbare Anforderungen bzw. Restriktionen reagieren zu können. • Betreiber nutzen die Lösungen im Rahmen der Ist-Architektur und

nehmen Anpassungen an diesen vor. Die Architekturdokumentation wird dabei als Richtschnur bei Prozess- und Systemänderungen sowie zur Bewertung und Sicherstellung der Interoperabilität zwischen Applikationen genutzt. Die Betreiber erhalten von den Anwendern direkt Rückmeldung darüber, wie die im Rahmen der Architektur gestalteten Prozesse und Systeme den aus den täglichen Aufgaben resultierenden Anforderungen genügen. Sie sind damit eine wesentliche Quelle für funktionale und nicht-funktionale Anforderungen, die bei der Architekturplanung zu berücksichtigen sind.

4.2

Form der Leistungserbringung

Die Erfahrungen der Mobiliar zeigen, dass ein Architekturansatz nur dann wirksam umgesetzt werden kann, wenn er an den dargestellten Kundengruppen ausgerichtet wird. Über die Schnittstelle zwischen der Unternehmensarchitektur und ihren Kunden wird damit die Aussensicht auf einen Architekturansatz definiert. In Anlehnung an Dikel et al. (2001) wird in der Mobiliar zu diesem Zweck die Metapher „Rhythmus einer Architektur“

242

A. Dietzsch

genutzt. Dieser ist definiert als ”... the recurring, predictable exchange of work products within an architecture group and across their customers and suppliers.” (Dikel et al. 2001, S. 74). Der „Rhythmus einer Architektur“ wird durch die Elemente Inhalt, Tempo und Qualität wie folgt definiert: Rhythmus

Tab. 1:

Inhalt

Der Inhalt beschreibt, was, d.h. welche Artefakte, innerhalb der Architektur sowie mit Kunden ausgetauscht werden.

Tempo

Das Tempo bestimmt, wann die im Inhalt festgelegten Artefakte bereitgestellt werden. Es definiert somit Zeitpunkt oder Frequenz der Bereitstellung von Architekturleistungen.

Qualität

Die Qualität definiert, wie Architekturergebnisse an die Kunden weitergegeben werden. Dabei wird festgelegt wie sichergestellt wird, dass die Architektur frei von Unzulänglichkeiten ist oder in welchen Bearbeitungsstadien Ergebnisse der Architektur weitergegeben werden.

"Rhythmus“-Struktur der Aussensicht eines Architekturansatzes

Um einen Architekturansatz zu positionieren wird deshalb angegeben, was an Ergebnissen wann und wie den Kunden der Architektur bereitgestellt wird. Die Ausgestaltung von Inhalt, Tempo und Qualität durch die Unternehmensarchitektur der Mobiliar wird nachfolgend beschrieben.

4.2.1 Inhalt Die Unternehmensarchitektur der Mobiliar stellt Ergebnisse sowohl für die Fachbereiche als auch für die IT-Entwicklung und den IT-Betrieb bereit. Dabei liegt die Verantwortung für die Erstellung, Umsetzung und Weiterentwicklung konkreter Inhalte innerhalb des durch die Architektur gegebenen Rahmens bei diesen Bereichen. Die Architektur unterstützt die jeweiligen Verantwortlichen und verantwortet eine fachbereichsübergreifende Konsolidierung dieser Aktivitäten. Dabei werden den Kunden der Unternehmensarchitektur die in Tab. 2 aufgeführten Leistungen bereitgestellt. In der Mobiliar umfassen die Kundengruppen der Entwickler und Betreiber alle Verantwortlichen und Mitarbeiter, die ausgehend von den Geschäftsprozessen über die unterstützenden Applikationen bis hin zur Umsetzung der technologischen Basis dieser Applikationen an der Leistungserbringung mitwirken. Betreiber sind damit im wesentlichen Prozessverantwortliche sowie die Verantwortlichen und Mitarbeiter des IT-Betriebs. Entwickler sind in diesem Zusammenhang Business Process Engineers sowie die Systementwickler der IT-Entwicklung.


Kunde

Zweck der Architektur

Unternehmensleitung

•

243

Konsumierte Leistung (Inhalt)

Nutzt die Architektur zur

•

Zielarchitektur

Unterstützung von

•

Architektur-Umsetzungs-

•

Beurteilungen von

•

Beurteilungen für die

Nutzen die Ist-Architektur zur

•

Ist-Architektur

Identifikation von

•

Zielarchitektur

Verbesserungspotenzialen

•

Beurteilungen

Entscheidungen über des Projektportfolio sowie einzelne

planung (Road Map)

Massnahmen

Massnahmen Unternehmensplanung

Auftraggeber

•

•

Nutzen die Zielarchitektur zur

geplanter/laufender

Abschätzung des vorgesehenen

Massnahmen

Umfangs der Realisierung dieser Potenziale

Entwickler

•

Nutzen die Ist-Architektur für

•

Ist-Architektur

das erstellen und integrieren von

•

Lösungsarchitekturen

Lösungen im Rahmen von

•

Schulungen

Nutzen die Lösungen der Ist-

•

Ist-Architektur

Architektur und nehmen

•

Zielarchitektur

Anpassungen an diesen vor

•

Beurteilungen

Projekten •

Nutzen die Zielarchitektur als Basis des Prozess- und Systementwurfs

•

Betreiber

•

Nutzen Ist- und Zielarchitektur

geplanter/laufender

als Richtschnur bei Prozess- und

Infrastrukturmassnahmen

Systemänderungen sowie zur Bewertung bzw. Sicherstellung von deren Interoperabilität

Tab. 2:

Inhalt der Mobiliar Unternehmensarchitektur

4.2.2 Tempo Die Unternehmensarchitektur der Mobiliar wirkt im Wesentlichen im Rahmen von Projekten. Damit wird die Ausrichtung an den Anforderungen der internen Kunden sichergestellt. Aus diesem Grund ist der Zeitpunkt der Bereitstellung der meisten Architekturergebnisse nicht fest definiert. Er wird vielmehr durch den Projektplan, d.h. durch die Anforderun-

244

A. Dietzsch

gen des jeweiligen Auftraggebers, bestimmt. Die Umsetzung relevanter Teile der Zielarchitektur ist dabei Bestandteil der Projektarbeiten. Eine Ausnahme sind die Beurteilungen von Projektanträgen, die auf der Basis von Vorhaben des strategischen Projektportfolios in die jährliche Unternehmensplanung aufgenommen werden sollen. Da die Unternehmensplanung einem festen jährlichen Rhythmus folgt, gelten die in diesem Rahmen festgelegten Phasen und Termine für die Bereitstellung der Architekturbeurteilungen.

4.2.3 Qualität Der Kontext, in dem die Architekturleistungen erbracht werden, ist Ausgangspunkt für die Festlegung der dabei zu realisierenden Qualität. Dabei wird zwischen Leistungen unterschieden, die im Rahmen von Projekten erbracht werden, und solchen, die Ergebnis der konzeptionellen Architekturentwicklung sind. Für Architekturleistungen im Rahmen von Projekten, ist die Projektplanung bestimmend für die erforderliche Qualität eines Architekturergebnisses. Bei der Projektinitialisierung wird mit dem Ergebnisplan des Projektes festgelegt, welche Architekturleistungen zu erbringen sind, welche Abnahmekriterien für diese gelten und durch wen die Abnahme erfolgt. Auch wenn Lösungen aus Projekten als Grundlage der Architekturentwicklung genutzt werden, sind konzeptionelle Architekturergebnisse projektunabhängige, allgemein gültige Ergebnisse der Architekturprozesse. Da diese nicht im Kontext eines bestimmten Projektes entstehen, erfolgt zunächst eine ausschliesslich interne Kontrolle durch die Organisationseinheit „Unternehmensarchitektur“. Die dabei zu realisierende Qualität wird durch die strategischen Schwerpunkte und jährlichen Ziele der Unternehmensarchitektur bestimmt.

4.2.4 Zusammenfassung Die internen Kunden der Unternehmensarchitektur der Mobiliar sind die Entwickler und Betreiber der Lösungen, die Auftraggeber von Projekten sowie die Unternehmensleitung. Gegenüber diesen Kunden werden durch die Unternehmensarchitektur konzeptionelle Leistungen und Leistungen bei der Umsetzung dieser Konzeptionen bereitstellt. Welche Leistungen dabei wann und in welcher Qualität zur Verfügung gestellt werden, bestimmen die Kunden der Architektur. Damit wird si-


245

chergestellt, dass die Interessen der internen Kunden in den Zielen der Architektur mit adäquatem Gewicht berücksichtigt werden. Gleichzeitig bietet sich damit die Möglichkeit, die Positionierung der Unternehmensarchitektur innerhalb der organisatorischen Strukturen und Prozesse kontinuierlich zu überprüfen und zu optimieren. Wie die Unternehmensarchitektur der Mobiliar innerhalb des mit der Gestaltung der Schnittstelle zu den internen Kunden gegebenen Rahmens ausgestaltet wurde beschreibt der nächste Abschnitt.

5

Gestaltung der Unternehmensarchitektur

5.1

Rahmen

Fokus, Philosophie und Organisation bilden die Elemente des internen Aufbaus der Unternehmensarchitektur. Wie bereits dargestellt, wird dieser durch die Definition des Rhythmus’ der Architektur bestimmt (siehe Abb. 5). Unternehmensarchitektur

Fokus

Abb. 5:

Inhalt

Philosophie

Tempo

Organisation

Qualität

Kunden der Architektur

Elemente der Gestaltung einer Unternehmensarchitektur

Dabei bildet der Inhalt, d.h. die den Kunden der Architektur bereitgestellten Leistungen, den Rahmen für den Fokus der Unternehmensarchitektur. Mit dem Fokus eines Architekturansatzes werden die Themenfelder beschrieben, auf denen eine aktive Planung und Umsetzung der Architektur erfolgt. Daraus ergeben sich die Teilarchitekturen des Architekturansatzes. Beispiele für Ausprägungen dieser Facette sind die Anwendungsintegra-

246

A. Dietzsch

tion, Daten- und Prozessstrukturierung, die Konzentration auf das ITTechnologieportfolio oder die Verfolgung des gesamthaften Ansatzes einer Unternehmensarchitektur. Mit Bezug zu den zeitlichen Anforderungen an die Leistungsbereitstellung und die durch die Teilarchitekturen bearbeiteten Bereiche wird die Philosophie des Agierens der Architektur, also die Art und Weise der Planung und Umsetzung bestimmt. Dabei ist grundsätzlich zwischen einem aktiven oder passiven Betreiben der Architektur zu wählen. Schwerpunkt einer passiv organisierten Architektur ist das Formulieren von Vorgaben in Form von Richtlinien, Strategien und Standards. Ergebnisse werden zunächst ohne Mitwirkung der Architektur erstellt und erst anschliessend durch diese auf ihre Konformität zu den getroffenen Vorgaben beurteilt. Ein solcher Ansatz erwies sich in der Mobiliar als nicht erfolgreich. Das ausschliessliche Verwalten von Ergebnissen, die Vorgabe von Richtlinien und deren administrative Durchsetzung als wesentliche Aufgaben der Architektur führten zu geringer Verankerung in Projekten und mangelnder Akzeptanz. Daraus resultierte die Wahrnehmung der Architektur als Ansatz, der nicht an den täglichen Problemen der Kunden ausgerichtet ist. Dies hatte wiederum Widerstände gegen die Architekturumsetzung zur Folge, die schliesslich zum Scheitern dieses Ansatzes führten. Im Gegensatz dazu basiert eine aktive Umsetzung auf der vorausschauenden und direkten Beteiligung der Architektur bei der Erarbeitung von Projektergebnissen. Projekte werden dabei durch Architekten bei der Lösungsfindung und -umsetzung begleitet und unterstützt. Durch diese kooperative Form der Umsetzung kann die Architekturkonformität von Artefakten bereits bei deren Entwicklung abgesichert werden. Während die beschriebenen Nachteile einer passiv organisierten Architektur damit vermieden werden, entsteht bei einer aktiven, an Projekten orientierten Architekturumsetzung die Gefahr einer zu wenig übergreifend ausgerichteten Lösungsfindung. Wie die Unternehmensarchitektur sowohl konzeptionell weiter entwickelt und anschliessend umgesetzt werden kann, wird durch die Form der Organisation der Architektur bestimmt. Diese bestimmt die Abläufe und Strukturen für das Betreiben der Architektur. Die Architektur kann dabei mit einer zentralen bis hin zu einer dezentralen Ausrichtung der Prozesse bzw. Strukturen organisiert werden. Mit der Definition der Organisation wird die Rolle der Architekten sowie deren Verankerung in der Organisation bestimmt.


247

In der Mobiliar hat sich gezeigt, dass nur eine zentrale Organisation die Möglichkeit bietet, die für eine übergreifende, konzeptionelle Weiterentwicklung der Architektur erforderlichen Fähigkeiten zu bündeln und zentral zu koordinieren. Die Rolle des Architekten erfordert dabei weniger ein domänenbezogenes Spezialwissen (z.B. zu einzelnen Geschäftsprozessen und Betriebsarchitekturen) als ein (abstrahierendes) übergreifendes Verständnis des Wirkungsbereichs der Architektur im Unternehmen. Die Erfahrungen in der Mobiliar zeigen jedoch ebenfalls, dass eine erfolgreiche Umsetzung der Architektur nur dann möglich ist, wenn die Architekten (dezentral) dort agieren, wo die Konzepte der entwickelten Zielarchitektur Einfluss auf die Lösungsfindung und -umsetzung haben.

reaktiv

Philosophie

aktiv

Der Raum, innerhalb dessen die Ausgestaltung einer Unternehmensarchitektur erfolgen kann, wird durch Abbildung 6 zusammenfassend dargestellt.

• starker Projektfokus • breite Akzeptanz • Architekten organisatorisch zusammengefasst • kaum übergreifende konzeptionelle Weiterentwicklung der Architektur

• starker Projektfokus • Akzeptanz von der Leistung Einzelner abhängig • Architekten im Unternehmen verteilt • keine übergreifende konzeptionelle Weiterentwicklung der Architektur

• geringer Projektfokus • Konzentration auf übergreifende Vorgaben • übergreifende konzeptionelle Weiterentwicklung der Architektur • Geringe Akzeptanz bei der Umsetzung

• Fokussierung auf individuelle Aufgaben • Architekten im Unternehmen verteilt • keine übergreifende konzeptionelle Weiterentwicklung der Architektur

zentral

... Prozesse Applikationen Technologien

Fokus

Daten dezentral

Organisation

Abb. 6:

Gestaltungsraum für Unternehmensarchitekturen

Der nachfolgende Abschnitt stellt die Gestaltung der Unternehmensarchitektur der Mobiliar im Spannungsfeld der beschriebenen Aspekte Fokus, Philosophie und Organisation dar.

248

5.2

A. Dietzsch

Fokus

Bis zum Jahre 2001 wurden in der Mobiliar Erfahrungen mit Architekturansätzen in verschiedenen Domänen gesammelt (siehe Abschnitt 2). Diese zeigen, dass der Nutzen einer Architektur als Rahmen für systematische Veränderungen stets durch deren Fokus begrenzt wird. Der Nutzen der Architektur steigt dabei mit dem Anwachsen ihres Wirkungsbereichs. Dafür ist es jedoch Voraussetzung, dass die Architektur im Unternehmen akzeptiert ist, ihre Prozesse definiert sind und angewendet werden. Verbunden mit einer Neuorganisation des Bereichs Informatik entschloss man sich deshalb zum Ende des Jahres 2001 mit der Unternehmensarchitektur eine umfassende architektonische Sicht auf das Unternehmen zu schaffen.

5.2.1 Teilarchitekturen Im Folgend ist die Unternehmensarchitektur der Mobiliar in fünf Teilarchitekturen gegliedert, die jeweils vertikal bzw. horizontal Themengebiete zusammenfassen (siehe Abb. 7). Sicht Perspektive

Funktional

Fachlich

Business-Architektur

Systeme

Applikations -Architektur

Technologie

Technische Architektur

Abb. 7:

Daten

Sicherheit

Daten-Architektur

Sicherheits-Architektur

Gliederung der Teilarchitekturen

Die Business-Architektur, die Applikations-Architektur und die Technische Architektur bilden die Ebenen der Unternehmensarchitektur.21 Die Konsolidierung von Daten sowie die Umsetzung von Sicherheitsanforderungen sind Themen, die auf jeder dieser Ebenen Relevanz besitzen. Aus diesem Grund sind die Daten- und Sicherheitsarchitektur als eigenständige, ebenenübergreifende Teilarchitekturen definiert. Die fünf Teilarchitekturen sind durch die folgenden Merkmale charakterisiert:

21

Eine vergleichbare Gliederung findet sich z.B. in Dern (2003).


249

Problembereich der Business-Architektur sind Elemente, die im direkten fachlichen Bezug zum Versicherungsgeschäft stehen. Dies sind z.B. Kunden, Dienstleistungen, Ziele, Geschäftsprozesse, Geschäftsvorfälle und Geschäftsobjekte. Hauptaufgabe der Business-Architektur ist die Konsolidierung der Geschäftsprozesse mit dem Ziel, durch die ausgewogene Standardisierung von Geschäftsprozessen die Effizienz der Leistungserbringung zu erhöhen. Auf dieser Grundlage werden anschliessend die Geschäftsanforderungen auf die durch die Applikationslandschaft bereitgestellten Funktionalitäten abgebildet. Die Dokumentation und Konsolidierung von Zielen, Dienstleistungen, Geschäftsprozessen, Geschäftsvorfällen und Geschäftsobjekten bildet die Basis, um diese Aufgabe erfüllen zu können. Die Informationssysteme, die die Geschäftsprozesse unterstützen, sind Gegenstand der Applikations-Architektur. Diese beschreibt die Beziehungen zwischen den einzelnen Bestandteilen der Applikationslandschaft. Dabei werden Konzepte, wie z.B. Services, Komponenten und die daraus gebildeten Systeme verwendet. Durch die Applikationsarchitektur wird eine den Geschäftsanforderungen adäquate Unterstützung durch die Systeme der Applikationslandschaft abgesichert. Die Hauptaufgabe besteht darin, getrieben durch die Geschäftsanforderungen Veränderungen in der Applikationslandschaft auszulösen und langfristig zu koordinieren. Zu diesem Zweck sind die Beziehungen zwischen den Bestandteilen der Applikationslandschaft, insbesondere die Abhängigkeiten zwischen Systemen, Applikationen und Services, Hauptelemente der Architektur auf dieser Ebene. Die Technische Architektur beschreibt die Design Prinzipien, die bei der Realisierung der Applikationslandschaft zugrunde zu legen sind. Zu ihrem Betrachtungsbereich gehören Teile der Infrastruktur, wie z.B. Hardware und Betriebssysteme aber auch Entwicklungsumgebungen, Programmiersprachen und die technische Infrastruktur für die Applikationsintegration. Die Technische Architektur bestimmt die angestrebte Granularität von Komponenten, die Struktur von deren Schnittstellen und bildet die Fähigkeiten von Technologietypen auf die funktionalen Anforderungen der Applikationslandschaft ab. Sie definiert damit den Rahmen für deren Weiterentwicklung. Im Fokus der Technischen Architektur liegen aus diesem Grund Konzepte zu Plattformen, Datenbanken aber z.B. auch die Konzeption und Umsetzung einer Plattform zur Applikationsintegration. Die Aufgabe der Daten-Architektur ist die Gewährleistung einer konsistenten und stabilen Abbildung der fachlichen Informationen von deren

250

A. Dietzsch

konzeptioneller Betrachtung aus fachlicher Perspektive bis hin zur physischen Realisierung in einem Datenbanksystem. Die Risikobeurteilung und Definition von IT-Schutzzielen auf allen Ebenen der Unternehmensarchitektur sowie die ebenenübergreifende Festlegung und Begleitung der Umsetzung von IT-Sicherheitsstandards ist Gegenstand der Sicherheits-Architektur.

5.3

Philosophie

Insbesondere vor dem Hintergrund der mit verschiedenen Architekturansätzen gesammelten Erfahrungen (siehe Abschnitt 2), ist in der Mobiliar die aktive Architekturumsetzung Kern der Philosophie der Unternehmensarchitektur. Um die Mitwirkung der Architekten bei der Lösungsfindung und -umsetzung abzusichern, besteht für die Unternehmensarchitektur das Ziel, insgesamt mindestens 50% der Bruttoarbeitszeit der Architekten als verrechenbare Architekturleistung, d.h. im Wesentlichen durch Mitarbeit in Projekten zu erbringen. Als Mitglied des Projektteams ist der Architekt damit direkt an der Lösungsfindung und -umsetzung beteiligt und prägt diese. Ist eine solche direkte Beteiligung nicht möglich oder sinnvoll, z.B. bei fehlenden Ressourcen oder einer zu geringen Projektgrösse, wird die Einhaltung der Architekturvorgaben durch die Kontrolle der architekturrelevanten Projektergebnisse sichergestellt. In welcher Form Architekten in ein Projekt eingebunden werden, hängt zum einen von der Bedeutung des Projekts für die Unternehmensentwicklung und zum anderen von den erwarteten Auswirkungen der Projektergebnisse auf die Architektur ab. Dabei werden die zur Verfügung stehenden Architekten prioritär in solchen Projekten eingesetzt, die eine hohe Bedeutung für die Weiterentwicklung des Unternehmens besitzen. Solche Projekte können dabei entweder der Absicherung und Weiterentwicklung wirtschaftlicher Potentiale (z.B. neue Produkte) oder der Beherrschung bzw. Reduktion operationeller Risiken (z.B. Anpassungen an Marktentwicklungen) dienen.


5.4

251

Organisation

Die Unternehmensarchitektur der Mobiliar gliedert sich aus organisatorischer Sicht in drei Prozesse. In diese sind sowohl die Mitarbeiter der zentralen Organisationseinheit „Unternehmensarchitektur“ als auch Spezialisten aus anderen Bereichen der Mobiliar eingebunden. Damit ist sichergestellt, dass sowohl eine konzeptionelle Weiterentwicklung der Architektur als auch die Umsetzung dieser Konzeption erfolgt.

5.4.1 Prozesse Die Prozesse „Architektur entwickeln“, „Architektur vertreten“ und „Architektur beurteilen“ sind die Leistungsprozesse der Unternehmensarchitektur. Sie stellen den (internen) Kunden die Leistungen der Unternehmensarchitektur bereit. Architektur führen

Auftraggeber Verhaltensregeln Methodik

Zielvorgaben

Methode

Zielarchitektur Road Map

Architektur entwickeln

Unternehmensleitung

Auftraggeber

Vorhaben

Abb. 8:

Unternehmensleitung

Ist-Architektur

Betreiber

Lösungsarchitektur

Entwickler

Schulung

Ausbildung

Strategie

strategisches Projektportfolio

Beurteilungsauftrag

Ergebnisse

Entwicklungsanforderung

Unternehmensarchitektur

Architektur vertreten

Architektur beurteilen

Beurteilung

Architekturprozesse der Mobiliar-Unternehmensarchitektur

Im Prozess „Architektur entwickeln“ wird die Unternehmensarchitektur konzeptionell weiterentwickelt. Daneben werden die Prozesse und Hilfsmittel bereitgestellt, die zur Umsetzung der Zielarchitektur erforderlich sind. Leistungen sind u.a. die Pflege der Ist-Architektur sowie Erarbeitung von Soll-Architekturen und der Zielarchitektur. Mit der Zielarchitektur wird ein langfristiger, an den Zielen der Unternehmensstrategie ausgerichteter Rahmen für die Entwicklung von Lösungen bereitgestellt. In diesem Zusammenhang werden die Daten-Architektur, Komponenten der

252

A. Dietzsch

Applikationsarchitektur, Abbildungen der Geschäftsfunktionen auf die Applikationsarchitektur sowie Teilstrategien entwickelt, wie z.B. für Integrationsansätze und die Evolution der Applikationslandschaft. Diese Ergebnisse werden durch die Organisationseinheit „Unternehmensarchitektur“ im Rahmen der Tagesaufgaben der Architekten erstellt. Die Basis bilden die Erfahrungen, die durch die Mitarbeit in Projekten gewonnen wurden. Die konzeptionelle Entwicklung der Architektur wird jedoch nicht im Rahmen von Projekten realisiert. Die im Rahmen der Projektmitarbeit realisierten Aktivitäten der Architekten, fasst der Prozess „Architektur vertreten“ zusammen. Hauptziel ist dabei die Unterstützung der Projekte bei der Umsetzung der konzipierten Ziel-Architektur sowie bei der Wieder- und Weiterverwendung bereits erarbeiteter Ergebnisse. Die Hauptleistungen dieses Prozesses sind: • Sicherstellen einer architekturkonformen Projektrealisierung • Betreuung des Issue- und Change Request-Prozesses in Projekten • Betreiben eines Architekturbüros • Aktive Mitarbeit bei der Entwicklung von Lösungsarchitekturen • Ausbildung von Mitarbeitern innerhalb und ausserhalb von Projekten Die wesentlichen Kunden des Prozesses “Architektur beurteilen” sind Projekte sowie die Geschäftsleitung und deren entscheidungsvorbereitenden Gremien. Der Prozess stellt in diesem Zusammenhang zwei wesentliche Ergebnisse bereit. Zum einen wird die Architekturkonformität der Projektergebnisse sichergestellt, die Architekturrelevanz besitzen, bei deren Erstellung eine aktive Beteiligung der Architektur jedoch nicht möglich war. Dazu werden Projektziele und -ergebnisse hinsichtlich ihrer Ausrichtung an Strategie, Geschäfts- und Prozesszielen sowie deren Auswirkungen auf Synergien, Redundanzen, Technologien und die technische Infrastruktur bewertet. Die Bedeutung eines Projektergebnisses für die Architektur wird dabei in der Phase der Projektinitialisierung bestimmt. Zum anderen erfolgt durch den Prozess „Architektur beurteilen“ ebenfalls die Bewertung des Projektportfolios aus Perspektive des mit der Zielarchitektur definierten Entwicklungspfades (Road Map). Damit wird abgesichert, dass mit dem Projektportfolio zur Umsetzung der Zielarchitektur beigetragen wird.


253

5.4.2 Aufbauorganisation Für die effektive und effiziente Umsetzung der Ziele der Unternehmensarchitektur besitzt die breite Verankerung der Architekturprozesse in der Aufbauorganisation eine besondere Bedeutung. Aus diesem Grund ist die Unternehmensarchitektur der Mobiliar in Form einer Matrixorganisation strukturiert (siehe Abb. 9). Die Mobiliar

Produktentwicklung

IT

Informatik Entwicklung

Versichern

Schaden

Informatik Betrieb

Unternehmensarchitektur Business Architektur Applikations Architektur Technischee Architektur

Abb. 9:

Organisatorische Verankerung der Unternehmensarchitektur

In den dargestellten drei Kernprozessen der Unternehmensarchitektur sind dabei neben den Mitarbeitern der zentralen Organisationseinheit „Unternehmensarchitektur“ Spezialisten anderer Bereiche (z.B. Prozessverantwortliche sowie Verantwortliche aus IT-Betrieb und IT-Entwicklung) organisiert. Damit wird einerseits sichergestellt, dass in den Architekturprozessen ein breites für die konzeptionelle Weiterentwicklung der Architektur erforderliches Wissen vorhanden ist. Andererseits sind ebenfalls spezifische Fähigkeiten vorhanden, die für die Entwicklung realistischer und realisierbarer Konzepte notwendig sind. Die zentrale Organisationseinheit trägt dabei die Verantwortung für die konzeptionelle Architekturentwicklung. Bei der Realisierung der Zielarchitektur werden darüber hinaus Spezialisten verschiedener Bereiche der Mobiliar in die Architekturprozesse integriert. Dabei werden insbesondere im Rahmen des Prozesses „Architektur beurteilen“ die Experten der jeweils betroffenen Unternehmensbereiche in die Bewertung architekturrelevanter Ergebnisse einbezogen.

254

5.5

A. Dietzsch

Anforderungen an die Rolle des Architekten

Aus der beschriebenen Gestaltung der Unternehmensarchitektur resultieren hohe Anforderungen an Mitarbeiter, die in der Rolle eines Architekten tätig sind (vgl. Bredemeyer 2002; Paulish 2002). Diese werden in der Mobiliar in den folgenden Bereichen definiert: • Kompetenz in mehreren der Teilarchitekturen (Business-Architektur, Applikations-Architektur und Technische Architektur) • Fähigkeit zum strategischen Denken • Beratungskompetenz • Fähigkeit zum Führen • Kenntnis der politischen Verhältnisse innerhalb des Unternehmens Mit der Aufgabe einer übergreifenden Koordination entsteht die Notwendigkeit, die Evolution der Teilarchitekturen so abzustimmen, dass ein systematischer Veränderungsprozess für das gesamte Unternehmen resultiert. Ein Architekt muss deshalb eine hohe fachliche Kompetenz in Fragestellungen besitzen, die der Konzeption und Umsetzung von Lösungen innerhalb seiner Teilarchitektur zuzuordnen sind. Daneben muss er jedoch auch die Beziehungen der Elemente seiner Teilarchitektur zu denen der anderen Teilarchitekturen kennen und in ihren Wechselwirkungen bewerten können. Darüber hinaus sind die übergreifend wirkenden Daten- und Sicherheitsarchitekturen aktiv einzubeziehen. Bei der konzeptionellen Entwicklung der Architektur ist es erforderlich, dass architekturrelevante Aussagen der Unternehmensstrategie sowie der Geschäfts- und Funktionalstrategien in der Zielarchitektur operationalisiert und durch eine adäquate Umsetzungsplanung realisierbar werden. Dieses Ziel ist nur dann erreichbar, wenn die Architekten die Fähigkeit strategischen Denkens besitzen. Die Anforderung an Architekten, im Rahmen von Projekten bei der Lösungsfindung und -umsetzung aktiv mitzuwirken, erfordert die Fähigkeit zu beraten und das Vermögen, Entscheide herbeizuführen und deren Umsetzung voranzutreiben. Das übergreifend angelegte Aufgabengebiet eines Architekten ist dabei stets auch mit dem Problem abweichender bzw. konkurrierender Anforderungen der Stakeholder verbunden. Für ein erfolgreiches Agieren in diesem Kontext ist für den Architekten die Kenntnis der politischen Verhält-


255

nisse innerhalb des Unternehmens und ein darauf abgestimmtes Verhalten Voraussetzung. Mit der personellen Zusammensetzung der Unternehmensarchitektur wird ein ausgewogener Mix der Fähigkeiten aller Architekten über die Dimensionen des Architektenprofils realisiert. Abbildung 10 zeigt exemplarisch das Profil eines Business Architekten in der Mobiliar. Business-Kompetenz

ApplikationenKompetenz

TechnologieKompetenz

Strategisches Denken

Politik in der Organisation

Führungsvermögen

Beratungskompetenz

Abb. 10: Beispiel für die Fähigkeiten eines Business Architekten

6

Management der Unternehmensarchitektur

Aufgrund ihres Auftrages besteht für die Unternehmensarchitektur die Notwendigkeit der Koordination mit anderen Unternehmensprozessen, die Veränderungen in der Organisation adressieren (vgl. Bredemeyer 2001). In der Mobiliar sind dies der Prozess der Strategieentwicklung, das (Projekt-) Portfoliomanagement sowie die Prozesse der Projektumsetzung (siehe Abb. 11).

256

A. Dietzsch

Strategieentwicklung

Unternehmensarchitektur Projektumsetzung

Portfoliomanagement

Abb. 11: Schnittstellen der Architekturprozesse zu anderen Unternehmensprozessen

6.1

Abstimmung mit der Strategieentwicklung

Die Unternehmensstrategie der Mobiliar umfasst mehrere Geschäfts- und Funktionalstrategien die in ihrer Gesamtheit eine einheitliche, umfassende und integrierte Planung bilden. Diese bestimmt die wesentlichen langfristigen Zielsetzungen des Unternehmens. Ausgehend von den Zielsetzungen der Strategien wird das strategische Projektportfolio abgeleitet. Es formuliert Massnahmen, die der Umsetzung der strategischen Ziele dienen. Diese umfassen u.a. Vorhaben der Produktentwicklung und -erneuerung, Reorganisationsvorhaben und Massnahmen an der Applikationslandschaft der Mobiliar. Für die Unternehmensarchitektur besteht dabei die Anforderung, die Auswirkungen der geplanten Veränderungen mit der Entwicklung der Zielarchitektur zu harmonisieren. Dies bedeutet, dass mit der Zielarchitektur Vorgaben bezüglich des Rahmens für die Lösungsentwicklung zu definieren sind. Diese Vorgaben müssen sich direkt den Handlungsfeldern der Strategie zuordnen lassen können. Im Gegenzug fliessen Erkenntnisse über Handlungsbedarf innerhalb der Ist-Architektur in den Prozess der Strategieentwicklung ein. Die Zielarchitektur operationalisiert damit die architekturrelevanten Aussagen der Strategien. So werden z.B. geplante Produktentwicklungsmassnahmen mit vorgesehenen bzw. notwendigen Änderungen an der Applikationslandschaft abgeglichen. Die mit diesen Vorhaben verbundenen Veränderungen an Geschäftsprozessen, Applikationen oder Technologien


257

werden bei der Umsetzungsplanung zur Zielarchitektur berücksichtigt. Die Kommunikation dieser Veränderungen erfolgt primär in Form von Architekturprinzipien22. Diese definieren den Rahmen einer architekturkonformen Lösungsfindung und -umsetzung. Sie geben Handlungsanweisungen zu der Art und Weise, in der die Umsetzung erfolgen soll. Ein Prinzip besteht aus vier Elementen: • Grundsätze geben den Handlungsrahmen wieder, der durch die Aussagen der Strategien zu einem Themenbereich der Unternehmensarchitektur definiert wird. • Für diesen Themenbereich wird der Lösungsraum durch die Angabe der jeweils möglichen extremen Positionen beschrieben. • Darin wird die IST-Architektur (IST) positioniert und der mit der Zielarchitektur angestrebte Zustand (SOLL) angegeben. Die Positionierung beschreibt qualitativ die Differenz zwischen dem aktuellen und dem angestrebten Zustand der Unternehmensarchitektur. • Der mit der Umsetzung der Zielarchitektur im thematisierten Bereich zu erreichende Zustand wird durch Angabe von Zielen konkretisiert, die den Erfolg der Architekturumsetzung messbar machen. Abbildung 12 zeigt exemplarisch die Verwendung dieser Elemente zur Beschreibung des Architekturprinzips zu Redundanzen in der Applikationslandschaft.

22

Prinzipien sind allgemein gültige Vorgaben, die auf einer hohen Abstraktionsstufe eine Orientierung für die Realisierung der Zielarchitektur geben. Da nur Änderungen der Unternehmensstrategie und ihrer Teilstrategien Veränderungen an den Architekturprinzipien auslösen, sind Architekturprinzipien die stabilsten Elemente der Unternehmensarchitektur der Mobiliar (vgl. Dikel et al. 2001).

258

A. Dietzsch

Reduktion von Redundanzen Grundsätze: Redundanzen bei Applikationen, Funktionen und Daten sind zu vermeiden. Redundanz ist nur dann zulässig, wenn Anforderungen an Performanz und Verfügbarkeit nicht anders realisiert werden können (z.B. Offline Systeme). Replikationen von operativen Versicherungsdaten sind zu minimieren.

IST Redundanzen Daten und Funktionen liegen in unterschiedlichen Applikationen inhaltlich identisch vor. Redundanzen verursachen zusätzliche Aufwände bei der Entwicklung und Wartung.

SOLL Redundanzfreiheit Von Daten existieren keine Duplikate. Daten stehen unterschiedlichen Applikationen zur Verfügung. Funktionalitäten werden nicht mehrfach implementiert.

Ziele: Die Anzahl redundanter Applikationen, Funktionen und Daten ist reduziert.

Architektur-Richtlinien: • Modelliere Daten in einem übergreifenden Modell 1, aber bilde sie physisch um wenige Applikationsbereiche herum ab (Vertrieb&Vertragsführung, Schaden, Datawarehouse, Partner, Inkasso/Exkasso). • Minimiere die Replikation von operativen Versicherungsdaten (ausser zur lesenden Nutzung), um Kosten und Komplexität zu minimieren und um die Daten möglichst aktuell zur Verfügung zu haben. • Verteile Daten und gewährleiste deren Aktualität gemäss den gestellten Geschäftsanforderungen. • Bestimme Fachbereichs- Verantwortliche für die operativen Versicherungsdaten.

Abb. 12: Das Architekturprinzip zu Redundanzen in der Applikationslandschaft

6.2

Abstimmung mit dem Portfoliomanagement

Wie bereits beschrieben ist es Philosophie der Unternehmensarchitektur der Mobiliar, die Umsetzung der Zielarchitektur schrittweise im Rahmen von Projekten zu vollziehen. Aus diesem Grund ist eine enge Abstimmung der Architekturprozesse mit dem Portfoliomanagement erforderlich. Die Hauptaufgabe des Portfoliomanagements besteht in der mittelfristigen Planung der Projekte, die der Realisierung der Massnahmen des strategischen Projektportfolios dienen. Sind im strategischen Projektportfolio die Geschäftsanforderungen und der daraus folgende Veränderungsbedarf lediglich grob umrissen, so werden die geplanten Massnahmen im Rahmen des Portfoliomanagement-Prozesses detailliert und geordnet. Zusätzlich zum Bezug zur Unternehmensstrategie werden dabei die folgenden Kriterien berücksichtigt: • Langfristige Anforderungen der Architekturumsetzung • Restriktionen bezüglich des verfügbaren Budgets • Zeitliche Abhängigkeiten zwischen einzelnen Projekten • Zielkonflikte zwischen einzelnen Projekten Ergebnis dieser Ordnung des Projektportfolios ist der Masterplan der Mobiliar. Dieser enthält alle geplanten und in Umsetzung befindlichen Vorhaben. Er wird zur mehrjährigen, mittelfristigen Strukturierung des strategischen Projektportfolios genutzt.


259

Durch diese Mechanismen wird abgesichert, dass die Entwicklung der Unternehmensarchitektur sich an den strategischen Zielsetzungen ausrichtet und gleichzeitig Impulse für deren Gestaltung und Umsetzung liefert.

6.3

Integration in Umsetzungsprojekten

Wie dargestellt, ist die aktive Beteiligung von Architekten bei der Lösungsfindung und -umsetzung Philosophie der Unternehmensarchitektur der Mobiliar. Aus diesem Grund ist die Integration der Architekturprozesse mit dem (allgemeinen) Projekt-Vorgehensmodell zwingend erforderlich. Diese Integration erfolgt sowohl auf Stufe der Projektinstitutionen als auch durch die mit dem Vorgehensmodell vorgeschriebenen Aktivitäten. Im institutionellen Rahmen wird der Einbezug der Architektur durch das „Architekturbüro“ realisiert, das für umfangreiche und/oder strategisch bedeutende Projekte zwingend zu implementieren ist. Das Architekturbüro koordiniert u.a. den Issue-Prozess des Projekts. Auf dieser Grundlage wird sichergestellt, dass architekturrelevante Fragestellungen frühzeitig erkannt, bewertet und adäquat bearbeitet werden. Die Integration der Unternehmensarchitektur in das Projekt-Vorgehensmodell wird zum einen durch Vorgabe zu erstellender Ergebnistypen realisiert. Dabei gibt die Unternehmensarchitektur insbesondere in den Phasen der Anforderungserhebung sowie des Grob- und Detaildesigns vor, welche Ergebnistypen (Prozesslandkarte, Business Use Cases, Systemarchitektur, Geschäftsobjektmodell etc.) zu erarbeiten und z.T. in welcher Form diese zu dokumentieren sind. Zum anderen wird durch die Definition der ausführenden Rolle(n) die Beteiligung der Architektur an Schlüsselaktivitäten, insbesondere beim Projektsetup und der Spezifikation, sichergestellt.

6.4

Absicherung der Flexibilität der Architektur

Wie in Abschnitt 4 bereits beschrieben wurde, ist die Ausrichtung an den internen Kunden Ausgangspunkt der Gestaltung der Unternehmensarchitektur der Mobiliar. Die beschriebene Form der Positionierung und Gestaltung bildet seit dem Jahr 2002 die Grundlage der Arbeit der Unternehmensarchitektur. Die Erfahrungen in diesem Zeitraum haben gezeigt, dass für den Erfolg der Architekturbemühungen nicht nur die formale Ausgestaltung von Gremien, Strukturen und Prozessen der Architektur entscheidend ist. Dar-

260

A. Dietzsch

über hinaus ist es erforderlich, Voraussetzungen für ein flexibles, situativ angepasstes Agieren der Architektur in der Zusammenarbeit mit ihren Kunden zu ermöglichen. Zu diesem Zweck wurden für die Unternehmensarchitektur der Mobiliar Grundsätze formuliert, die deren Flexibilität in allen drei Elementen des Rhythmus’ gewährleisten sollen. Die nachfolgende Tabelle fasst diese Grundsätze zusammen. Rhythmus

Tab. 3:

Inhalt

• • •

Zweckgebundene Architekturen Lokale Veränderungen Einfachheit voraussetzen

Tempo

• • •

Schnelle Rückmeldung Zeitscheiben bilden Den nächsten Schritt vorbereiten

Qualität

• • •

Erwarte Instabilität Schrittweise Veränderungen Spezifische Methoden

Grundsätze, um die Flexibilität der Mobiliar-Unternehmensarchitektur zu gewährleisten

6.4.1 Flexibilität im Inhalt Mit der inhaltlichen Relativierung wird festgelegt, wann es zulässig ist, dass ein Architekturergebnis von den umzusetzenden Strukturen oder zu beschreibenden Inhalten abweicht. Die Akzeptanz der Unternehmensarchitektur durch deren Kunden ist ein wesentlicher Treiber für die Grundsätze in diesem Bereich. Um abzusichern, dass alle Bestandteile der Architektur zweckgebunden und mit den jeweiligen Abnehmern abgestimmt sind, werden in der Mobiliar Architekturergebnisse ausschliesslich mit Bezug zu Projekten entwickelt (siehe Abb. 13). Damit wird erreicht, dass zum einen mit jedem Projekt zur Annäherung an die Zielarchitektur beigetragen wird und zum anderen nur solche Ergebnisse erstellt werden, die für die Kunden der Architektur von Nutzen sind. Die Architektur ist damit stets zweckgebunden. Um die Risiken bei der Realisierung der Zielarchitektur zu verringern, werden im Rahmen von Projekten nur lokale Veränderungen realisiert. Dies bedeutet, dass nur die Bereiche der Unternehmensarchitektur bearbeitet werden, die durch den Projektauftrag direkt betroffen sind. Da damit stets nur abgegrenzte Teile der Architektur betrachtet werden, besteht die Möglichkeit, dass ein Projektergebnis inkonsistent zu anderen, nicht betrachteten Teilen der Unternehmensarchitektur ist. Den am Projekt betei-


261

ligten Architekten fällt deshalb die Aufgabe zu, Veränderungen in ihren Auswirkungen zu dokumentieren und zu kontrollieren. Führt ein Projektergebnis zu Inkonsistenzen, so wird die Architekturplanung derart angepasst, dass diese mit nachfolgenden Projekten eliminiert werden. Um die Komplexität der Unternehmensarchitektur beherrschen zu können, ist es ein weiterer Grundsatz, dass stets die Realisierung der einfachsten Lösung zu einem Problem anzustreben ist. Aus der Anwendung dieser Regel resultiert das Ziel Redundanzen, z.B. bei Strukturen von Geschäftsprozessen oder Applikationen, zu reduzieren bzw. zu vermeiden. Ein weiteres resultierendes Ziel ist die “Anspruchsreduktion”. Dabei wird die Bedeutung einer Anforderung und damit ihrer Umsetzung daran gemessen, wie diese auf die Fähigkeit des Unternehmens wirkt, die Geschäftstätigkeit aufrechtzuerhalten sowie zur Umsetzung der Zielarchitektur beizutragen. Bei Anforderungen, die nicht direkt die Reduktion operationeller Risiken oder die strategische Weiterentwicklung adressieren, kann die Einfachheit einer Lösung höher gewichtet werden als die vollständige Abdeckung der Benutzeranforderungen. Die Regeln, die die Flexibilität im Inhalt gewährleisten, lassen sich wie folgt zusammenfassen: • Lösungsarchitekturen werden grundsätzlich im Rahmen von Projekten entwickelt. • Jede Architekturentwicklung erfolgt unter Einbezug der Stakeholder. • Bei der Definition einer Architektur ist die einfachste Lösung eines Problems die beste. • Redundanzen sind grundsätzlich zu vermeiden. • Die Architektur wird niemals als Ganzes verändert. • Bei der Architekturentwicklung werden primär solche Anforderungen

berücksichtigt, die der Aufrechterhaltung oder strategischen Entwicklung des Geschäfts dienen.

6.4.2 Flexibilität im Tempo Die Erfahrungen in der Mobiliar zeigen, dass die Zeitspanne zwischen dem Formulieren eines Problems und der entsprechenden Antwort durch die Architektur ein weiterer kritischer Erfolgsfaktor ist. Insbesondere in Projekten sind kurze Antwortzeiten erforderlich, um eine architekturkonforme Lösungsfindung zu gewährleisten. Da für eine schnelle Rückmeldung eine

262

A. Dietzsch

enge Zusammenarbeit mit dem Kunden erforderlich ist, werden Architekten wie bereits beschrieben als Mitglieder des Projektteams eingesetzt. Damit wird es möglicht, Probleme frühzeitig zu erkennen und Lösungsvarianten proaktiv zu entwickeln. Die ausschliessliche Fokussierung auf projektspezifische Probleme führt jedoch zu einer Architektur, die aus lokal optimierten Einzelelementen besteht. Um die Entwicklung der Unternehmensarchitektur als Ganzes zu planen, werden ausgehend von der Ist-Architektur Zeitscheiben gebildet, mit denen die Schritte zur Realisierung der Zielarchitektur in Form zeitlich aufeinander folgender Soll-Architekturen bestimmt werden. Dabei ist jede Soll-Architektur ein Meilenstein, an dem der Fortschritt der Umsetzung der Zielarchitektur beurteilt wird. Die Projektaktivitäten richten sich jeweils an der nächsten zu erreichenden Soll-Architektur aus. Eine Lösung, die eine solche Ausrichtung nicht aufweist wird nur dann zugelassen, wenn für deren Realisierung, Betrieb und Entsorgung, ein wirtschaftlicher Nutzen nachweisbar ist. Bei einem solchen Vorgehen entstehen fast zwingend Inkonsistenzen zwischen der Planung der Architekturumsetzung und dem jeweils realisierten Ist-Zustand. Deshalb wird mit Hilfe der Soll-Architekturen ebenfalls sichergestellt, dass die Evolution der einzelnen Architekturebenen nicht durch einzelne Inkonsistenzen zwischen Elementen der Architekturelemente verhindert wird (vgl. Nuseibeh 1999). Das Management von Inkonsistenzen wird somit durch die Definition von Zeitplänen für lokale Veränderungen möglich. In der Mobiliar betragen diese Zeiträume zwischen ca. einem halben und bis zu drei Jahren. Die folgenden Regeln bilden die Grundlage für ein flexibles Tempo der Unternehmensarchitektur in der Mobiliar: • Eine schnelle Rückmeldung wird durch die Arbeit der Architekten als Mitglieder der Projektteams sichergestellt. • Jede Soll-Architektur bereitet die nächsten Schritte zur Realisierung der Zielarchitektur vor. • Grundsätzlich muss sich jede Projektaktivität an den Anforderungen der jeweils nächsten Soll-Architektur ausrichten. • Ist für die Realisierung, den Betrieb und die Entsorgung einer provisorischen Lösung ein wirtschaftlicher Nutzen nachweisbar, so ist diese auch dann zulässig, wenn sie zu Inkonsistenzen der Unternehmensarchitektur führt.


263

• Die maximale Lebensdauer einer Inkonsistenz wird durch Zeitscheiben

definiert.

6.4.3 Flexibilität in der Qualität Die Erfahrung hat gezeigt, dass eine Vielzahl verschiedener Treiber auf allen Ebenen der Unternehmensarchitektur wirken. So zwingen neue Produkte, Geschäftsmodelle und rechtliche Regelungen zur Anpassung der Business-Architektur. Die Applikations-Architektur wird wesentlich durch neue Entwicklungen im Bereich von Standardsoftwaresystemen aber auch Nischenprodukten beeinflusst. Veränderungen bei Programmiersprachen, Betriebssystemen und der verfügbaren Hardware wirken dagegen auf die Technische Architektur. Diese ist dadurch einem ständigen Wandel unterworfen. Es wird deshalb davon ausgegangen, dass ohne eine Kontrolle der sich daraus ergebenden Veränderungen die Zahl von Inkonsistenzen zunehmen wird, bis die Architektur ihren Zweck nicht mehr erfüllen kann. Das Architekturmanagement der Mobiliar berücksichtigt dies und geht von einer kontinuierlichen Veränderung und damit der Instabilität der Architektur aus. Das Ziel ist es deshalb, an Stelle der Architektur selbst den Veränderungsprozess der Architektur zu stabilisieren. Wesentliches Element sind dabei die in Abschnitt 6.1 beschriebenen Architekturprinzipien. Sie bieten zum einen die Möglichkeit der Operationalisierung der Architekturziele und zum anderen die Flexibilität, diese anzupassen, ohne die Unternehmensarchitektur strukturell ändern zu müssen. Das Streben nach einer vollständigen Definition einer Architektur vor dem Beginn von Aktivitäten der Umsetzung, führt mit hoher Wahrscheinlichkeit zu einem langen Zeitraum ohne Ergebnisse (vgl. O.V. 2002). In der Mobiliar hat sich dabei, insbesondere bei Projekten mit einem grossen Umfang, gezeigt, dass es ein solcher Ansatz dem Projektmanagement erschwert, den Projektfortschritt zu kontrollieren und zu kommunizieren. Um dennoch eine „Analyse Paralyse“ (vgl. Brown 1998) zu verhindern, werden die durch ein Projekt benötigten Teile der Architektur schrittweise entwickelt. Da dabei je nach Schwerpunkt und Perspektive unterschiedliche Anforderungen an die zu nutzende Methode bestehen, wird durch die Architektur keine umfassende, zwingend zu nutzende Methode vorgegeben. Vielmehr wird davon ausgegangen, dass die Architekten in der Lage sind, mit spezifischen, problemadäquaten Methoden zu arbeiten. Diese projektspezifischen Architekturlösungen werden im Rahmen des Prozesses „Architektur

264

A. Dietzsch

entwickeln“, unabhängig von spezifischen Projekten, inhaltlich und formal in die Unternehmensarchitektur integriert. Unzureichend spezifizierte Teile der Unternehmensarchitektur werden dabei als Inkonsistenzen gehandhabt. Die Regeln, die die Flexibilität im Tempo gewährleisten, lassen sich wie folgt zusammenfassen: • An Stelle der Architektur selbst werden die Veränderungsprozesse stabilisiert. • Prinzipien sind die Basis der Definition der Unternehmensarchitektur. • Architekturlösungen werden projektspezifisch entwickelt. • Projektergebnisse werden unabhängig von spezifischen Projekten in die Architektur integriert und gepflegt. • Verschiedene, an den Teilarchitekturen ausgerichtete Methodenteile existieren, die miteinander gekoppelt sind. Die beschriebenen Grundsätze zur Flexibilisierung der Unternehmensarchitektur setzt Abbildung 13 in Bezug zu den Unternehmensprozessen, mit denen die Unternehmensarchitektur gemeinsam wirkt. Strategie Handlungsbedarf

BusinessArchitektur

ApplikationsArchitektur

Architektur-Prinzipien

Versicherungsmarkt Produkte Rechtsentwicklung Geschäftsmodelle Applikationsmarkt Standardprodukte Nischenlösungen

Technische Architektur

IT-Markt Programmiersprachen Hardware Betriebssysteme

Teilarchitektur

Treiber

IST-Architektur

Projekte

Abb. 13: Strategie der projektbezogenen Architekturumsetzung

Zielarchitektur


7

265

Zusammenfassung

Die Unternehmensarchitektur der Mobiliar wird in der in diesem Beitrag beschriebenen Form seit Beginn des Jahres 2002 betrieben. In dieser Zeit haben sich die folgenden Faktoren als wesentliche Herausforderungen des Architekturmanagements erwiesen. Aufgrund ihres umfassenden Betrachtungsbereichs adressiert die Unternehmensarchitektur Themen in verschiedenen Verantwortungsbereichen. Konflikte zwischen den verschiedenen Interessengruppen treten durch die Arbeit der Architektur zu Tage. Zudem ist die Unternehmensarchitektur stets unvollkommen, da zeitliche und wirtschaftliche Restriktionen es nicht erlauben, die Unternehmensarchitektur gesamthaft und dauerhaft konsistent und aktuell zu halten. Diese Unvollkommenheit der Unternehmensarchitektur ist gegenüber deren Kunden häufig ein Akzeptanzhindernis. Nicht zuletzt ist es problematisch, dass die Unternehmensarchitektur mit ihren Ergebnissen nur indirekt wirkt. Der wirtschaftliche Nutzen der Unternehmensarchitektur ist deshalb kaum seriös nachzuweisen. Trotz dieser Hürden konnte sich die Unternehmensarchitektur der Mobiliar als effizientes und akzeptiertes Instrument etablieren. Einen wesentlichen Beitrag dazu leistete die konsequente Ausrichtung der Unternehmensarchitektur an den internen Kunden. Die Fokussierung auf die Realisierung der Architektur durch Mitwirkung in Projekten sowie das Schaffen der Grundlagen für ein flexibles Agieren beim Kunden, auch ausserhalb des formal vorgegebenen Rahmens, sind aus heutiger Sicht die Begründung für Akzeptanz und Erfolg der Unternehmensarchitektur in der Mobiliar.

266

A. Dietzsch

Literatur Armour, F.J.; Kaisler, S.H.; Liu, S.Y.: Building an Enterprise Architecture Step by Step, in: IT Professional 1 (1999), 4, pp. 31-39. Bredemeyer, D.: Architecting Process, http://www.bredemeyer.com/pdf_files/ ProcessGuide.pdf, Abruf am 2001-08-12. Bredemeyer, D.; Malan, R.: The Role of the Architect, http://www.bredemeyer.com/ pdf_files/role.pdf, Abruf am 2002-06-22. Brown, W.H.; Malveau, R.C.; McCormick III, H.W.; Mowbray, T.J.: AntiPatterns – Refactoring Software, Architectures and Projects in Crisis, New York, 1998. Dern, G.: Management von IT-Architekturen: Informationssysteme im Fokus von Architekturplanung und –entwicklung, Wiesbaden, 2003. Dikel, D.M.; Kane, D.; Wilson, J.R.: Software Architecture: Organizational Principles and Patterns, Upper Saddle River, 2001. Maier, M.W.; Rechtin, E.: The Art Of Systems Architecting, 2. Aufl., Boca Raton, 2002. Nuseibeh, B.; Easterbrook, S.: The Process of Inconsistency Management: A framework for understanding, in: Proceedings of the DEXA Workshop, 1999, pp. 364-368. O.V.: ANSI/IEEE Std. 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems. O.V.: Big Design Up Front, http://xp.c2.com/BigDesignUpFront.html, Abruf am 2002-07-20. Paulish, D.J.: Architecture-Centric Software Project Management: A Practical Guide, Boston, 2002. Pfeifer,W.: Etymologisches Wörterbuch des Deutschen, 4. Aufl., Berlin, 1999.

Measured Integration – Metriken für die Integrationsarchitektur Claus Hagen Credit Suisse Financial Services

Alexander Schwinn Universität St. Gallen

1 2

3

4 5

Einleitung ........................................................................................ 268 IT-Führungsinstrumente.................................................................. 269 2.1 Benchmarking.......................................................................... 270 2.2 Prozesskostenrechnung............................................................ 271 2.3 Target Costing.......................................................................... 272 2.4 Balanced Scorecard.................................................................. 272 2.5 Eignung der Ansätze ................................................................ 274 Integrationsarchitektur und strategische Ziele am Beispiel der Credit Suisse.................................................................................... 275 3.1 Strategische Ziele und Kennzahlen der Integrationsarchitektur ............................................................ 276 3.2 Exemplarischer Aufbau einer Scorecard ................................. 284 Beispiel: Messung von Nutzung, Reuse und Wachstum in einer Servicearchitektur............................................................................ 285 Zusammenfassung........................................................................... 290

268

1

C. Hagen, A. Schwinn

Einleitung

Effektives Architekturmanagement erfordert die Steuerung und Kontrolle der Architekturumsetzung. Es ist notwendig, Messverfahren, Metriken und Kennzahlen zu entwickeln, um Handlungsbedarf aufzeigen, Fortschritte dokumentieren, um Fehlentwicklungen frühzeitig erkennen zu können und daraus Massnahmen abzuleiten. Die Notwendigkeit von Messungen ist im Wesentlichen auf folgende Gründe zurückzuführen: • Architekturmanagement zielt auf die Verbesserung der Strukturen von IT-Systemen. Ohne eine verlässliche Ermittlung des Ist-Zustandes können die richtigen Massnahmen zur Verbesserung kaum ermittelt werden. Metriken können in diesem Sinne wichtige Anhaltspunkte für diejenigen Bereiche liefern, in denen das grösste Verbesserungspotential besteht. • Ob eingeleitete Architekturmassnahmen zielführend sind, lässt sich nur durch kontinuierliche Messung ihres Effektes ermitteln. Metriken sind deshalb ein notwendiges Hilfsmittel, um Fehlentwicklungen zu vermeiden und die Effektivität der eingesetzten Mittel sicherzustellen. • Die IT-Architektur steht in jeder IT-Organisation unter stetem Rechtfertigungsdruck. Der Ansicht, Architektur verursache nur Kosten, nütze aber wenig, kann begegnet werden, wenn durch geeignete Metriken Fortschritte belegt werden können. Der vorliegende Beitrag diskutiert Führungsinstrumente, die zur Steuerung der Architekturentwicklung und -umsetzung im Bereich Integration eingesetzt werden können. Als Beispiel wurde die konkrete Situation des Schweizer Finanzdienstleisters Credit Suisse (CS) gewählt. Der Schwerpunkt der Arbeit liegt auf der Problematik der Definition und Erhebung von Metriken im Integrationsbereich. Dieser Artikel versteht sich nicht als Vorstellung eines generischen und abschliessenden Konzeptes. Die Problematik ist so komplex und situationsabhängig, dass mit schnellen und allgemeingültigen Lösungen nicht zu rechnen ist. Der Artikel will aber mögliche Lösungsansätze aufzeigen, erkannte Schwierigkeiten bei der Umsetzung beschreiben, und zumindest an Einzelbeispielen konkrete Umsetzungen zeigen. Zunächst werden unterschiedliche IT-Führungsinstrumente vorgestellt, die in Wissenschaft und Praxis häufig anzutreffen sind. Es wird untersucht, inwieweit diese Führungsinstrumente zur Messung der Qualität der Integrationsarchitektur geeignet sind. Anschliessend wird die Integrationsarchitektur der Credit Suisse kurz dargestellt und auf deren strategische Ziele

Measured Integration

269

eingegangen. Die Umsetzung dieser strategischen Ziele soll mit geeigneten Führungsinstrumenten unterstützt werden. Mögliche Kennzahlen zur Bewertung der Integrationsarchitektur werden in der Folge diskutiert. Dabei wird insbesondere auf die Problematik der Messbarkeit und Interpretation der Messergebnisse eingegangen. Schliesslich werden anhand eines konkreten Anwendungsgebiets – der Servicearchitektur der Credit Suisse – beispielhaft Kennzahlen und Messergebnisse vorgestellt.

2

IT-Führungsinstrumente

Bevor konkrete Führungsinstrumente im IT-Bereich vorgestellt werden, werden zunächst die Begriffe Kennzahl und Kennzahlensystem eingeführt, die jeweils zu den in der Praxis verwendeten Führungsinstrumenten gehören. Reichmann (1997) definiert Kennzahlen als Zahlen, die quantitativ erfassbare Sachverhalte in konzentrierter Form erfassen. Ein Kennzahlensystem ist eine geordnete Gesamtheit von einzelnen Kennzahlen, die in einer Beziehung zueinander stehen und so als Gesamtheit über einen Sachverhalt vollständig informieren. Kennzahlen dienen zur Verdichtung grosser Datenmengen zu wenigen, aussagekräftigen Kenngrössen (vgl. Jäger-Goy 2001, S. 127). Sie sind Hilfsmittel für die Planung, Steuerung und Kontrolle. Zentrale Eigenschaften einer Kennzahl sind (vgl. Jäger-Goy 2001, S. 127): • Informationscharakter: Kennzahlen sollen eine Beurteilung wichtiger Sachverhalte ermöglichen. • Quantifizierbarkeit: Die Sachverhalte müssen auf einer metrischen Skala gemessen werden können. Der Einsatz von Kennzahlen verlangt, dass Messdaten auch wirklich vorhanden sind und systematisch erfasst werden können. Nur so können Sachverhalte genau quantifiziert werden. Desweiteren werden in der Literatur folgende Anforderungen an eine sinnvolle Einsetzbarkeit von Kennzahlen im Informationsmanagement gestellt (vgl. Jäger-Goy 2001): • Zweckeignung: Der Informationsgehalt der Kennzahl soll möglichst mit dem ursprünglichen Informationsbedarf übereinstimmen. Ein hoher Deckungsgrad zwischen Informationsbedarf und Informationsangebot stellt sicher, dass nicht unbrauchbare Kennzahlen entwickelt werden.

270


• Genauigkeit: Die Anforderung an die Genauigkeit einer Kennzahl wird durch ihre Reliabilität (Zuverlässigkeit) und Validität (Gültigkeit) bestimmt. • Aktualität: Der Zeitraum zwischen der Messung der Kennzahl und ihrer Auswertung sollte möglichst gering sein. • Kosten-Nutzen-Relation: Die Erhebung einer Kennzahl sollte nicht höhere Kosten verursachen, als ihr Erkenntniswert ist (vgl. Haufs 1989). • Einfachheit und Nachvollziehbarkeit: Der Verwender der Kennzahl muss das Messergebnis einfach interpretieren können und das Messergebnis muss zurückverfolgbar sein. Der Einsatz von Kennzahlen hat sich in zahlreichen Bereichen zur Kontrolle und Steuerung von verschiedensten Sachverhalten bewährt. Zunehmend werden Kennzahlen auch im Bereich der Informationssysteme eingesetzt. Im Vordergrund dieses Beitrags steht sowohl das Management der Informationssysteme als auch der Informationstechnologie, insbesondere deren Führung mit Hilfe von Instrumenten. Konkret ist die Integrationsarchitektur der Credit Suisse Betrachtungsgegenstand. Unter dem Begriff Führungsinstrumente werden Methoden, Werkzeuge, Massnahmen und sonstige Hilfsmittel verstanden die das Informationsmanagement bei seinen Aufgaben (Planung, Verabschiedung, Umsetzung und Kontrolle (vgl. Österle et al. 1991)) unterstützen. Im Folgenden werden einige moderne Führungsinstrumente vorgestellt, die im Informationsmanagement Anwendung finden können. Als modern werden diejenigen Instrumente bezeichnet, die auf innovative betriebswirtschaftliche Konzepte zurückzuführen sind. Nach Horváth sind dies die Konzepte Benchmarking, Prozesskostenrechnung, Target Costing und die Balanced Scorecard, die im Folgenden kurz betrachtet werden (vgl. Horváth et al. 1999, S. 317). Anschliessend werden sie hinsichtlich der Eignung zur Führung der Integrationsarchitektur der Credit Suisse untersucht.

2.1

Benchmarking

Seit den 80er Jahren setzen amerikanische und auch europäische Unternehmen in verschiedenen Bereichen Benchmarking ein. Dabei sind die Ausgangsfragestellungen immer „Wie ist die eigene Leistungsfähigkeit im objektiven Vergleich einzuschätzen?“ oder „Welche Leistungsdefizite sind vorhanden?“ (Legner 1999, S. 7). Unter Benchmarking versteht man das systematische Vergleichen mit und das Lernen von anderen Unternehmen.


271

In der Regel erfolgt das Lernen durch Adaption von Best Practices. Legner unterscheidet zwei Arten des Benchmarking: „Messen und Positionieren“ (quantitatives Benchmarking) und „Lernen von erfolgreichen Praktiken“ (qualitatives Benchmarking) (vgl. Legner 1999, S. 8). Während „Messen und Positionieren“ auf den Leistungsvergleich abzielt, um die eigene Position anhand objektiver Kriterien festzustellen und Zielvorgaben abzuleiten, stehen beim Typ „Lernen von erfolgreichen Praktiken“ Gestaltungsempfehlungen und Adaption von Praktiken im Vordergrund (vgl. Legner 1999, S. 9). Zudem unterscheidet die Literatur Benchmarking hinsichtlich der Kriterien Vergleichsobjekt und Vergleichshorizont (vgl. Horváth/Herter 1992, S. 7). Als Vergleichsobjekte können Strategien, Methoden, Prozesse, Funktionen und Produkte herangezogen werden. Der Vergleichshorizont betrachtet den Benchmarking-Partner. Dieser kann intern innerhalb eines Unternehmens (z.B. Vergleich zweier Abteilungen) oder extern (andere Unternehmen) sein. Bei externen Vergleichspartnern wird zudem unterschieden, ob der Partner der gleichen oder einer anderen Branche angehört. Tiefergehende Betrachtungen zum Benchmarking sind beispielsweise in Horváth/Herter (1992) oder Legner (1999) zu finden.

2.2

Prozesskostenrechnung

Die Prozesskostenrechnung soll die kostenwirtschaftliche Transparenz besonders im Gemeinkostenbereich erhöhen und die Kalkulation verbessern (vgl. Jäger-Goy 1999, S. 6). Da die Informationstechnologie in der Regel einen hohen Gemeinkostenanteil hat, eignet sich die Prozesskostenrechung im IT-Bereich im Besonderen. Die Prozesskostenrechung versucht, die Gemeinkosten verursachungsgerecht auf Kostenobjekte zu verrechnen. Die Kostenobjekte sind die Geschäftsprozesse (z.B. Erstellung und Betrieb von Anwendungssystemen, Betrieb von Rechenzentren, Support, usw.). Mit der Prozesskostenrechung werden im einzelnen folgende Ziele verfolgt (vgl. Horváth et al. 1993, S. 612): • Erhöhung der Transparenz in Gemeinkostenbereichen: Durch Abbilden der Prozesse einer Unternehmung soll eine höhere Akzeptanz der Kostenrechnung durch Schaffung von Transparenz erreicht werden. • Förderung des Kostenbewusstseins: Gezieltes Beeinflussen der Gemeinkosten macht die Kostenrechnung zu einem Instrument des Kostenmanagements.

272


• Prozessoptimierungen: Optimierung der Unternehmensprozesse hinsichtlich Effizienz und Effektivität, durch Untersuchung der vorhandenen Prozesse. Nicht wertschöpfende Aktivitäten sind dabei zu beseitigen. • Unterstützung mittel- oder langfristiger Make-or-Buy-Entscheidungen. Ausführliche Information zur Prozesskostenrechung finden sich bei Horváth et al. (1993) oder Schweizer/Küppler (1995).

2.3

Target Costing

Target Costing stellt einen Ansatz zum Kostenmanagement und ein Instrument zur Kostenplanung dar. Es wurde massgeblich von den japanischen Firmen NEC, Sony, Nissan und vor allem Toyota entwickelt (vgl. Jäger-Goy 2001, S. 188). Ausgangspunkt beim Target-Costing ist die Fragestellung, wie viel ein neu zu entwickelndes Produkt kosten darf, und nicht wie viel es kosten wird. Der Ansatz des Target Costing bezieht sich in seiner ursprünglichen Form auf den gesamten Produktlebenszyklus. Hauptziel des Ansatzes ist die Marktorientierung des gesamten Unternehmens. Vor allem das Kostenmanagement soll dabei marktorientiert sein und bereits in frühen Phasen der Produktentwicklung eingesetzt werden. Innerhalb der IT kann Target Costing beispielsweise zur Preisermittlung von IT-Dienstleistungen eingesetzt werden. Ausführliche Information zum Target Costing finden sich in Seidenschwarz (1991), Horváth (1993), Baumöl (1998) oder Niemand (1999).

2.4

Balanced Scorecard

Die Balanced Scorecard (BSC) soll im Gegensatz zu den klassischen, ergebnisorientierten und meist intern fokussierten Führungsinstrumenten sowohl vergangenheits- wie auch zukunftsorientierte Informationen für alle Leistungsebenen liefern. Sie zeichnet sich durch die Betrachtung von langfristigen und kurzfristigen Zielen, finanziellen und nicht-finanziellen Kennzahlen, Früh- und Spätindikatoren sowie von internen und externen Perspektiven in einem ausgewogenen Verhältnis aus (vgl. Jäger-Goy 2001, S. 216). Bei der klassischen Balanced Scorecard werden die finanzielle, die interne Prozess-, die Kunden- und die Lern- und Entwicklungsperspektive unterschieden. Nach Horváth/Kaufmann (1998) lässt sich das ursprüngliche Modell der Balanced Scorecard bedarfsweise modifizieren. Der IT-Bereich einer Unternehmung wäre demnach ein möglicher Einsatz-


273

bereich. Die Balanced Scorecard kann im IT-Bereich eingesetzt werden, um die Entwicklung der IT-Strategie zu unterstützen und sie in operative Zielsetzungen, Kennzahlen und Massnahmen umzusetzen. Es ist zu beachten, dass es bei der Entwicklung einer IT-Balanced Scorecard und einer klassischen Balanced Scorecard Unterschiede gibt. So ist es beispielsweise schwer, Ursache-Wirkungsbeziehungen einzelner IT-Leistungen zu finanziellen Unternehmenszielen (z.B. Steigerung der Umsatz- oder Eigenkapitalsrendite) zu bestimmen. Die Kennzahlen und Massnahmen in der finanziellen Perspektive einer IT-Balanced Scorecard würden sich also eher auf die Wirtschaftlichkeit, das Budget oder den Investitionsplan der IT beziehen (vgl. Kaplan/Norton 1997; Horváth/Kaufmann 1998; Kaplan/Norton 2001). Die Kundenperspektive soll das Verhältnis zu den Kunden der IT-Leistung widerspiegeln. Die interne Prozessperspektive betrachtet die Optimierung von internen Geschäfts- und IT-Prozessen. Die Lern- und Entwicklungsperspektive lässt Grössen, wie beispielsweise das Potential der Mitarbeiter einer IT-Abteilung einfliessen. Typische Kennzahlen wären hier der Mitarbeiterzufriedenheitsindex oder die Mitarbeiterfluktuationsrate. Das Vorgehen zum Aufbau einer Balanced Scorecard erfolgt in drei Hauptschritten. Zuerst müssen strategische Ziele und Aktionspunkte festgelegt werden, um eine systematische Ableitung sicherzustellen und um die Ursache-/Wirkungsbeziehungen transparent zu machen. Im Vordergrund steht die Frage, welche Aktivitäten in den jeweiligen Perspektiven erfolgen müssen. In einem zweiten Schritt müssen die Performance-Treiber identifiziert werden, die ein wirksames Vorgehen sicherstellen. Sie sollen erklären, welchen Faktoren zentral für den Erfolg der Aktivitäten sind. Zuletzt müssen Messgrössen abgeleitet werden, um die Entwicklung der Performance-Treiber messen zu können. Besonders wichtig bei diesem Punkt ist, dass nur geeignete Messgrössen (kontrollierbare, erhebbare, usw.) verwendet werden. Ausführliche Information zur klassischen Balanced Scorecard finden sich bei Kaplan/Norton (1997), zum Einsatz im IT-Bereich vergleiche JägerGoy (2001). Nachdem nun vier unterschiedliche IT-Führungsinstrumente knapp vorgestellt worden sind, wird untersucht inwieweit sich die einzelnen Ansätze zur Messung und Steuerung der Integrationsarchitektur der Credit Suisse eignen.

274

2.5


Eignung der Ansätze

Im Folgenden sollen nun die vier unterschiedlichen vorgestellten Konzepte auf die Nutzbarkeit hinsichtlich der Messung der Qualität und Steuerung der Integrationsarchitektur untersucht werden. Die Prozesskostenrechnung wird in der Literatur kontrovers diskutiert. Vorteile der Prozesskostenrechnung werden in der Möglichkeit der verfeinerten Überwachung der Gemeinkostenbereiche und der dadurch resultierenden Kostentransparenz der Arbeitsabläufe gesehen. Zudem versucht sie eine verursachergerechte Kalkulation von Dienstleistungen zu ermöglichen. Die Prozesskostenrechnung stellt eine gute Basis für das Kostenmanagement dar und leistet einen Beitrag zur Lösung von Organisationsproblemen. Hauptproblem bei der Einführung einer Prozesskostenrechnung ist in dem hohen Aufwand zu sehen, der bei der Einführung der Prozesskostenrechung anfällt. Probleme bei der Datenerfassung und bei der Datengenauigkeit erschweren diese zusätzlich (vgl. Horváth/Kaufmann 1998, S. 46ff.). Für die Messung der Architekturqualität ist die Prozesskostenrechnung nicht geeignet. Dies liegt primär daran, dass der Einfluss der Architektur auf die Prozesskosten schwer quantifiziert werden kann. Eine Grundvoraussetzung beim Benchmarking ist, dass ein Vergleichspartner existiert. Bisher existieren im Architekturbereich aber noch keine Benchmarks, die verwendet werden könnten. Wäre dies der Fall, wäre das Benchmarking sicherlich ein geeignetes Instrument, die Qualität der Integrationsarchitektur der Credit Suisse zu bewerten. Eine Voraussetzung für brauchbare Benchmarks sind aber aussagekräftige Kennzahlen, anhand derer der Vergleich stattfinden kann. Dieser Beitrag fokussiert auf diese Kennzahlen. Beim Target Costing steht vor allem die Kostenperspektive in Bezug auf Produktentwicklung im Vordergrund. Dabei versucht man zu ermitteln, wie viel ein zukünftig zu entwickelndes Produkt kosten darf. Auch hier ist der Einfluss der Architektur auf die Endprodukte nicht zu quantifizieren, weshalb dieser Ansatz nicht geeignet ist. Die Balanced Scorecard, bzw. eine angepasste BSC für das Informationsmanagement erscheint zur Messung der Qualität einer Integrationsarchitektur am Besten geeignet. Hier werden nicht nur monetäre Aspekte berücksichtigt, sondern auch andere Perspektiven in einem ausgeglichen Verhältnis. Sie hilft dabei, die Strategie zu operationalisieren. Das ursprüngliche Konzept der BSC lässt sich bedarfsweise modifizieren. Die BSC liefert einen Denkrahmen, der Freiräume bei der Gestaltung der Perspektiven lässt. Adaptiert man die BSC zur Anwendung auf die Integrati-


275

onsarchitektur der Credit Suisse können als Ausgangspunkt die strategischen Ziele, die bei der Weiterentwicklung der Integrationsarchitektur verfolgt werden, herangezogen werden. Diese wurden in Hagen (2003) bereits definiert und werden noch vorgestellt. In den folgenden Abschnitten wird eine Scorecard zur Messung der Qualität der Integrationsarchitektur der Credit Suisse exemplarisch entwickelt. Anschliessend wird ein Teilbereich detaillierter ausgearbeitet und beschrieben und auf Probleme eingegangen. Zunächst wird die Integrationsarchitektur der Credit Suisse vorgestellt und auf deren strategische Zielsetzungen eingegangen.

3

Integrationsarchitektur und strategische Ziele am Beispiel der Credit Suisse

Innerhalb der IT-Architekturplanung der Credit Suisse hat die Integrationsarchitektur eine grosse Bedeutung. Der Grund sind vor allem Grösse und Komplexität des Unternehmens und seiner IT-Systeme. Der Konzern betreibt heute mehrere IT-Plattformen für unterschiedliche Bereiche des Bank- und Versicherungsgeschäftes, die jeweils durch grosse inhärente Komplexität gekennzeichnet sind. Diese Komplexität hat verschiedene Ursachen: • Grösse: Mehrere hundert produktive Applikationen. • Zeitliche Heterogenität: Die Applikationen sind im Laufe der letzten 30 Jahre entstanden und basieren deshalb auf stark unterschiedlichen Paradigmen und Technologien. Programme aus den 70er Jahren müssen mit gerade erstellten oder gekauften Applikationen interagieren können. • Technische Heterogenität: Unterschiedliche Hardware, Betriebssysteme, Infrastruktur. • Organisatorische Heterogenität: Bei ca. 1000 in-House-Entwicklern und einem Mix aus interner und externer Entwicklung ergibt sich das Problem der losen Kopplung auf Organisationsebene. • Sehr dynamisches Business: Wie in jeder Branche muss der (interne) Anwender in die Lage versetzt werden, möglichst schnell auf Marktund Strategieänderungen reagieren zu können.

276


• Strukturelle Komplexität: Allein auf der Mainframe-Plattform der Credit Suisse existieren viele tausend Programmkomponenten mit sehr komplexen, über Jahre gewachsenen und nur bedingt dokumentierten Beziehungen. • Redundanz: Viele Redundanzen bei Daten und Funktionen. Alle diese Faktoren führen letztendlich zu einer grossen Zahl von gegenseitigen Abhängigkeiten, die zu einem architektonischen Problem werden können. Die Abhängigkeiten reduzieren die Flexibilität, Änderungen schnell und kostengünstig einzubringen. Diese Flexibilität ist nicht zuletzt aufgrund der rasch wechselnden Strategien auf der Anwenderseite zwingend notwendig. Wenn aber jede Änderung eine grosse Zahl von Änderungen an abhängigen Systemen nach sich zieht, werden Modifikationen sehr teuer und schliesslich unmöglich. Eine „gute“ Integrationsarchitektur zeichnet sich durch Reduktion von unkontrollierten Abhängigkeiten aus. Die Integrationsarchitektur ist auf verschiedenen Ebenen definiert. Etwas vereinfacht besteht sie aus (a) Infrastruktur (Middleware) für die Integration von Applikationen und Systemen, (b) Methoden und Prozessen für die Nutzung der Integrationsmittel und für die Qualitätssicherung der Integrationslösungen und (c) Steuerungsmassnahmen zur Verbesserung der Applikationslandschaft in Bezug auf die Integration.

3.1

Strategische Ziele und Kennzahlen der Integrationsarchitektur

Da die zu definierenden Messgrössen als Steuerungsinstrumente zur Verbesserung der Integrationsarchitektur dienen sollen, ist zunächst zu definieren, in welchen Bereichen Verbesserungen erreicht werden sollen. Hier ist eine erste Abweichung vom klassischen Vorgehen der Balanced Scorecard notwendig. Während üblicherweise finanzielle Verbesserungen das überwiegende Ziel der Scorecard-Anwendung sind (wobei nicht-finanzielle Ziele mitbewertet werden), ist im Falle der IT-Architektur der direkte Einfluss auf Finanzergebnisse kaum zu belegen. Deshalb wird eine andere Grösse in den Mittelpunkt gestellt. In Anlehnung an den in letzter Zeit häufig verwendeten Begriff der Agilität eines Unternehmens (d.h. der Fähigkeit zur raschen Anpassung an wechselnde Anforderungen) wird in diesem Beitrag der Begriff der Agilität eines IT-Systems – also die Fähigkeit, das IT-System schnell an neue Anforderungen anpassen zu können, verwendet. Letztendlich muss es das Ziel der Integrationsarchitektur sein, diese Agilität zu steigern und damit die Widerstände der Applikationslandschaft gegen Änderungen oder Erweiterungen zu reduzieren.


277

Verschiedene Teilziele haben letztendlich Einfluss auf diese Agilität und werden deshalb in der Scorecard bewertet. Diese Faktoren sind in Abbildung 1 graphisch dargestellt. Sie werden in der Folge beschrieben, wobei insbesondere auch auf mögliche Kennzahlen eingegangen wird.

Minimale Projektaufwände für die Integration

Optimaler Reuse, Redundanzvermeidung

Agilität der Gesamtplattform

Komplexitätsreduktion der Applikationslandschaft

Abb. 1:

Minimale Infrastrukturkomplexität und -kosten

Optimale Enge der Kopplung

Strategische Teilziele der Integrationsarchitektur

3.1.1 Agilität der Gesamtplattform Die Agilität der Gesamtplattform drückt die „Leichtigkeit” aus, mit der sich Änderungen oder Erweiterungen durchführen lassen. Viele Faktoren können diese Agilität beeinflussen – die IT-Architektur ist nur einer von ihnen. Es wird jedoch davon ausgegangen, dass die IT-Architektur, und insbesondere die Integrationsarchitektur, mit steigender Grösse des ITSystems einen zunehmend signifikanten Einfluss auf die Agilität hat. Direkt messen lässt sich der Einfluss der Integrationsarchitektur auf die Agilität heute nicht – Bedingung dafür wären genauere Analysen der Zusammenhänge zwischen der Komplexität der Inter-Applikations-Strukturen und der Agilität. Hier besteht durchaus noch Forschungsbedarf. Die Agilität selbst ist aber prinzipiell messbar, wenn auch zeitverzögert und nur mit einigem Aufwand. Die Grundidee ist, die Gesamtaufwände für Änderungen oder Erweiterungen am IT-System in einem bestimmten Zeit-

278


raum zu messen und sie anhand der Grösse der durchgeführten Änderungen zu normieren. Die Erfassung dieser Grössen stellt allerdings einige Anforderungen an das IT-Controlling eines Unternehmens. Die Credit Suisse führt derzeit erste Versuche in dieser Hinsicht durch.

3.1.2 Komplexitätsreduktion durch Desintegration der Applikationslandschaft Eine gewachsene Applikationslandschaft mit vielen hundert Applikationen lässt sich nicht als Ganzes steuern. Dazu sind die verschiedenen Abhängigkeiten und Querbeziehungen zwischen den Applikationen zu komplex. Es ist daher zwingend notwendig, die Komplexität der Applikationslandschaft beherrschbar zu machen, indem gezielt „Desintegration“ betrieben wird. Die Gesamtlandschaft wird in handhabbare Einheiten zerlegt, zwischen denen eine nur lose Kopplung existiert. Bei der Credit Suisse wurden zu diesem Zweck so genannte „Applikationsdomänen” definiert. Es handelt sich dabei um Gruppierungen von Applikationen und Daten, die einem gemeinsamen Business-Bereich zugerechnet werden können. Insgesamt sind ca. 20 solche Applikationsdomänen definiert. Ziel der Integrationsarchitektur ist nun, innerhalb dieser Domänen eng zu koppeln und ausserhalb der Domänen lose. Der Effekt ist eine Reduktion von Abhängigkeiten zwischen Applikationen in unterschiedlichen Domänen und damit die Möglichkeit, einzelne Domänen autonom weiterzuentwickeln, ohne dass andere Domänen direkt betroffen sind. Letztendlich verbirgt sich hinter diesem Ansatz das in der Informatik wohlbekannte Prinzip der Kapselung von Daten und Funktionen. Auch wenn (wie bei der Credit Suisse der Fall) die Management-Einheiten bereits definiert sind, werden in der Regel noch eng gekoppelte Abhängigkeiten zwischen den Bereichen bestehen. Dies ist insbesondere der Fall, wenn eine existierende Landschaft „desintegriert“ werden muss. Die Reduktion direkter Abhängigkeiten wird viele Jahre in Anspruch nehmen. Die wichtigste Steuerungsgrösse ist deshalb der Grad der Desintegration zwischen den Management-Einheiten. Um diese Grösse zu erfassen, muss die Anzahl lose gekoppelter kontrollierter Verbindungen zwischen Domänen in Relation zur Gesamtzahl von Verbindungen zwischen den Domänen gesetzt werden. Der entstehende Quotient gibt Auskunft über die Entkopplung der Landschaft. Verfeinerte Werte für bestimmte Bereiche oder Applikationsgruppen können dann Aufschluss über den dringendsten Handlungsbedarf geben.


279

Voraussetzung für die Erhebung geeigneter Kennzahlen sind jedoch technische Hilfsmittel, mit Hilfe derer sich die Beziehungen zwischen Applikationen analysieren lassen. Entsprechende Werkzeuge existieren am Markt. Sie analysieren entweder den Source-Code der Applikationen oder führen Messungen zur Laufzeit durch, um die gewünschten Informationen zu beschaffen. Source-Code-Analysen haben den Vorteil, dass sie die Performance der produktiven Applikationen nicht reduzieren. Sie setzen jedoch eine recht homogene Entwicklungsplattform voraus. In der Credit Suisse ist im Mainframe-Bereich ein Werkzeug zur SourceCode-Analyse seit längerem im Einsatz. Obwohl es ursprünglich nicht für den Zweck der Erstellung von Metriken zur Integrationssituation beschafft wurde, ist es für diesen Zweck gut geeignet. Der Aufbau eines entsprechenden Mess-Systems soll im Jahre 2004 erfolgen.

3.1.3 Optimale Enge der Kopplung Die „optimale“ Kopplung im architektonischen Sinne realisiert für jede Applikationsbeziehung einen Grad der Integration, der weder zu eng noch zu lose ist. Dies kann für unterschiedliche Applikationen sehr unterschiedliche Kopplungen zur Folge haben. Generell gilt: Je „näher“ zwei Applikationen zueinander sind, desto enger wird man koppeln, um Reibungsverluste zu vermeiden. Auf der anderen Seite wird man umso loser koppeln, je „weiter“ zwei Applikationen voneinander entfernt sind. Die optimale Kopplung hat direkten Einfluss auf die Agilität, da bei zu enger Kopplung die Aufwände für Änderungen steigen. Bei zu loser Kopplung steigen Kommunikationskosten und es entsteht vor allem ein RuntimeOverhead (siehe Abb. 2).

280 Kosten

C. Hagen, A. Schwinn Runtime-Overhead

Lose Kopplung (Loose coupling)

Abb. 2:

Resistance to change

Enge Kopplung (Tight coupling)

Optimaler Kopplungsgrad (ideales Gleichgewicht zwischen LaufzeitOverhead und Änderungs-Resistenz)

Das Problem ist hier, dass der optimale Fall hung unterschiedlich ist. Objektive Kriterien lung des richtigen Kopplungsgrad sind nicht sehr schwer, Kennzahlen und Messgrössen zugeben.

für jede Applikationsbezieoder Verfahren zur Ermittbekannt. Es ist daher auch für diese Perspektive an-

Indikatoren für diese Perspektive wären auf der einen Seite die tatsächlichen Kosten für Anpassungen an Schnittstellen oder ganzen Applikationen, aufgrund von Änderungen in gekoppelten Applikationen (sehr hohe Kosten deuten auf eine zu enge Kopplung hin). Auf der anderen Seite müsste der Entwicklungs- und Laufzeitoverhead für lose gekoppelte Systeme gemessen werden (z.B. die für Middleware aufgewendeten MIPS). Diese Zahlen sind jedoch üblicherweise in den Projektentwicklungs- bzw. Unterhaltskosten versteckt und daher nicht direkt messbar. Selbst wenn sie zu beschaffen wären, ergäbe sich darüber hinaus das Problem der richtigen Bewertung. Benchmark-Studien scheinen uns der einzige Weg zu sein, um hier zu aussagekräftigen Steuergrössen zu kommen. Diese fehlen jedoch, vor allem, da das Thema der Steuergrössen für die Architektur noch nicht genügend weit etabliert ist. Als Alternative sind Stichproben an einzelnen Applikationen denkbar. Analysen der Änderungshäufigkeit dieser Applikationen aufgrund von Änderungen im Umfeld sowie Messungen der für die lose Integration anfallenden Laufzeitkosten (beides in Relation zur Komplexität der jeweiligen Applikation) können Anhaltspunkte über einen guten oder schlechten Kopplungsgrad bieten. Das Problem der richtigen Bewertung der Zahlen besteht aber auch hier.


281

In diesem Gebiet wird grosses Potential für zukünftige Forschungsarbeiten gesehen. Klare Kriterien für den idealen Kopplungsgrad, aus denen sich dann später Mess- und Steuerungsmechanismen ableiten lassen, sind von grossem Interesse.

3.1.4 Optimale Wiederverwendung, Redundanzvermeidung Das Ziel der optimalen Wiederverwendung fordert, dass jede Funktionalität nur einmal implementiert und dass jede Information nur einmal gespeichert werden sollte. Im Idealfall lassen sich so die Entwicklungs- und Unterhaltskosten minimieren. Die Integrationsarchitektur muss die geeigneten Mechanismen, Methoden und Prozesse zur Erreichung dieses Ziels bereitstellen. So muss Middleware zur Verfügung stehen, um die zentral implementierte Funktionalität von unterschiedlichen technischen Plattformen aus zu erreichen, und geeignete Design-Grundlagen müssen die Wiederverwendbarkeit der Funktionen sicherstellen. Hauptherausforderung ist es, den optimalen Wiederverwendungsgrad zu erreichen. Dabei muss bereits bei der Entwicklung potentieller wiederverwendbarer Komponenten (z.B. Services) darauf geachtet werden, dass sie bestmöglich wiederverwendbar sind (Design-for-Reuse). Eine wichtige Fragestellung ist die gewählte Granularität: Werden sehr grosse monolithische Komponenten mit umfassender Funktionalität entwickelt, können diese aufgrund ihrer umfangreichen Funktionalität sehr häufig wiederverwendet werden, jedoch entstehen auch zahlreiche Abhängigkeiten. Beispielsweise sind Releasezyklen kürzer, da häufiger Änderungen in umfassenden Komponenten vorgenommen werden müssen als in modularen. Werden auf der anderen Seite die Komponenten zu feingranular entwickelt, reduziert sich der Wiederverwendungsgrad und es entsteht Zusatzaufwand bei der Wartung und bei der Ausführung zur Laufzeit. Ein weiteres Kriterium ist der Spezialisierungsgrad von Services. Werden sehr spezialisierte Services entwickelt, ist das Potential, dass diese wiederverwendet werden, eher gering, da der Anwenderkreis dieser sehr spezialisierten Services beschränkt sein wird. Werden auf der anderen Seite Services zu allgemein entwickelt, kann zwar die Wiederverwendungsquote höher sein, jedoch entsteht Zusatzaufwand für die Implementierung zusätzlicher Logik. Die wichtigste Kennzahl ist hier die durchschnittliche Wiederverwendung pro zentraler Funktion. Zur Ermittlung dieser Zahl sind Repositories notwendig, die über Anzahl und Nutzung der verschiedenen Komponenten und ihrer Schnittstellen Auskunft geben. Dazu könnten ähnliche Tools wie

282


die im vorigen Kapitel erwähnten Source-Code-Analysierer eingesetzt werden. Weitere wichtige Kennzahlen, die Anhaltspunkte bzgl. der Güte der Architektur geben können, sind die Gesamtzahl von Schnittstellen sowie deren Wachstum. Eine sehr grosse Anzahl und ein starkes Wachstum sollten als mögliche Anzeichen für zu grosse Redundanzen Berücksichtigung finden. Allerdings gibt es hier bislang keine Erkenntnisse über die „ideale“ Zahl wiederverwendbarer Funktionen. Bei der Credit Suisse wird zur Ermittlung dieser Zahlen ein dediziertes Schnittstellen-Repository eingesetzt, in dem über die existierenden Schnitttellen und ihre Nutzung Buch geführt wird. Die daraus gewonnen Messgrössen werden in einem folgenden Kapitel genauer erläutert.

3.1.5 Minimale Projektaufwände für die Integration Mitunter einer der am schwierigsten Bereiche ist die Bewertung der Integrationskosten von Projekten. Der Hauptgrund ist, dass die Integrationskosten nicht absolut gewertet werden können, sondern in Relation zum jeweiligen zugrundeliegenden Integrationsproblem gesetzt werden müssen. Eine isolierte Applikation mit nur wenigen Beziehungen zu anderen Applikationen hat wesentlich geringere Integrationskosten als eine Applikation, die viele Daten von sehr unterschiedlichen Systemen beziehen muss. Rückschlüsse auf die Qualität der Integrationsarchitektur lassen sich damit aus den Integrationskosten nur ziehen, wenn diese gewichtet werden. Sie sind abhängig von zahlreichen schwer determinierbaren Grössen wie Anzahl der Schnittstellen, beteiligte Organisationseinheiten, Zustand der Dokumentation, unterschiedliche Semantik, Technik, usw. Dies bedeutet, dass eine Messung der Integrationskosten die Komplexität des Integrationsproblems der jeweiligen Applikation berücksichtigen müsste. Geeignete Bewertungsverfahren für die Integrationskomplexität könnten auch helfen, unterschiedliche Integrationsmethoden empirisch in Relation zu setzen. Ohne ein solches Mass wäre es nur möglich, eine vergleichbare Alternative bei der „Implementierung der Integration“ zu betrachten. Eine Alternativimplementierung ist aber in der Regel aus Kostengründen nicht möglich und wird ausser Betracht gelassen. Damit ist der einzige gangbare Weg ein Vergleich der gewichteten Integrationskosten über mehrere Zeiträume hinweg. Dazu können die gesamten Integrationskosten eines Jahres (Summe über alle Projekte) betrachtet


283

werden und durch die Gesamt-Integrationskomplexität dividiert werden. Dividiert man nun den entsprechenden Bruch aus dem zweiten Vergleichsjahr sollte dass Ergebnis grösser 1 sein. Dies würde ausdrücken, dass die Kosteneffizienz bei vergleichbarer Integrationskomplexität verbessert wurde, also mehr Integrationskomplexität mit weniger Aufwand implementiert worden ist. Auch bleibt weiterhin das Problem des anzustrebenden Zielzustandes. Dieser lässt sich ohne industrieweite Benchmarks nur schwer definieren.

3.1.6 Minimale Infrastrukturkomplexität und -kosten Die Anzahl der eingesetzten Integrationstechnologien hat direkten Einfluss auf die fixen IT-Kosten (da z.B. für jedes Tool Personal bereitstehen muss) und in gewissem Masse auch auf die Implementierungskosten: Je weniger Tools existieren, desto besser können diese unterstützt werden. Zudem steigt mit einer grossen Anzahl Tools die Unsicherheit bei den Entwicklern, was einzusetzen ist, und damit werden in jedem Projekt Aufwände für Analysen notwendig. Auf der anderen Seite ist aber eine gewisse Grundmenge an Technologien notwendig, um „Workarounds“, d.h. die Simulation einer Technologie durch eine andere, zu verhindern. Als Beispiel sei hier der „Nachbau“ einer Servicearchitektur durch Message-orientierte Middleware genannt. Ein solches Vorgehen bringt auf Dauer nur Nachteile, da spezifische Eigenschaften (im Beispielfall z.B. die Zuordnung von Aufrufen zu Ergebnissen und die Fehlerbehandlung, falls Antworten ausbleiben), die in der benutzten Middleware nicht vorhanden sind, aufwendig selbst implementiert werden müssen. Ziel ist es, mit möglichst wenigen Standard-Technologien möglichst viele Anforderungen zu erfüllen. Abbildung 3 verdeutlicht den Zusammenhang und zeigt das theoretische Optimum des Technologieportfolios.

284


Erfüllungsgrad der Anforderungen

Komplexität

100% Erfüllung der Anforderungen

0% Optimales Technologieportfolio

Abb. 3:

Technologievielfalt

Optimales Technologieportfolio

Kennzahlen für den Stand des Technologieportfolios lassen sich wiederum nur sehr schwer direkt ermitteln. Eine indirekte Kenngrösse ist der Gesamtaufwand für die Integrationstechnologie pro Jahr. Eine solche Zahl müsste dann aber wiederum durch Benchmarks bewertet werden, wobei die sehr unterschiedlichen Anforderungen in unterschiedlichen Unternehmen einen Vergleich stark erschweren.

3.2

Exemplarischer Aufbau einer Scorecard

Im Folgenden wird – aus den bisher vorgestellten Kennzahlen und Diskussionen zusammengefasst – vorgestellt, wie eine Scorecard zur Kontrolle und Steuerung der Integrationsarchitektur zusammengestellt werden könnte. Die oben genannten Zielsetzungen werden als strategische Teilziele betrachtet, für die es gilt Leistungsindikatoren und anschliessend Messgrössen abzuleiten. Tabelle 1 stellt diese Teilziele und mögliche Leistungsindikatoren der Teilziele zusammenfassend dar. Im Folgenden wird für das Teilziel „Optimale Wiederverwendung von Services, minimale funktionale Redundanz“ die Servicearchitektur der Credit Suisse untersucht.


285

Übergeordnetes strategisches Ziel: Minimierung der „Resistance to Change“, Agilität der Gesamtplattform Teilziel

Leistungsindikatoren

Reduktion der Komplexität

• •

Optimale Enge der Kopplung

• •

Optimale Wiederverwendung, Redundanzvermeidung

• • •

Minimale Projektkosten für die Integration

Optimales Technologieportfolio/ Minimale Infrastruktur-Kosten

Tab. 1:

4

• •

Anteil der lose gekoppelten Kommunikation zwischen Domänen Einhaltung der Kommunikationsverträge Änderungsaufwand bei Änderungen oder Austausch einer Applikation Laufzeit-Overhead durch Middleware-Nutzung bei loser Kopplung Wiederverwendungsquote von Services Funktionaler Überschneidungsgrad von Services Service-Wachstum

•

Integrationsspezifische Kosten in Projekten Mehr-/Minderaufwände aufgrund der Verwendung der Integrationsarchitektur Projektlaufzeiten

• •

Gesamtkosten der Integrationsinfrastruktur Vergleich durch industrieweite Benchmarks

Mögliche Teilziele und Leistungsindikatoren

Beispiel: Messung von Nutzung, Reuse und Wachstum in einer Servicearchitektur

Die Credit Suisse führt in Teilbereichen bereits regelmässig Messungen durch. Im Folgenden werden einige Ergebnisse vorgestellt. Abbildung 4 zeigt die Nutzung der zentralen CORBA-Infrastruktur (Common Object Request Broker Architecture) als Kern der CS-Servicearchitektur. Aus der Abbildung lässt sich ablesen, dass seit der Einführung der CORBA-Infrastruktur Anfang 2001 die Service-Aufrufe pro Monat kontinuierlich zunahmen. Derzeit werden ca. 55 Mio. Messages pro Monat verarbeitet. Das Wachstum ist im Wesentlichen auf drei Punkte zurückzuführen: (a) Es wurden immer mehr CORBA-Services entwickelt (siehe Abb. 5), (b) immer mehr Projekte verwenden die CORBA-Infrastrukur, die sich nach einer Anlaufphase mittlerweile etabliert hat, (c) durch gezieltes

286


Outphasing von Legacy-Infrastrukturen wurden mehr und mehr Applikationen auf die Servicearchitektur umgestellt.

Abb. 4:

Nutzung der CORBA-Infrastruktur der Credit Suisse 2001-2004 (Messages pro Monat)

Die Nutzungsintensität der Servicearchitektur sagt aber nur teilweise etwas über deren Qualität aus (wenn auch die Bewältigung der sehr hohen Volumen Aussagen über die Qualität der zugrundeliegenden Infrastruktur erlaubt). In dem Wachstum kann jedoch die Etablierung der Infrastruktur gesehen werden. Um Aussagen über die Qualität der Servicearchitektur respektive deren Services machen zu können wurden die Wiederverwendungsquoten und die Wachstumsraten von Services untersucht. Dabei lagen folgende Annahmen zugrunde: 1. In der Einführungsphase der Servicearchitektur wächst die Anzahl der Services linear oder exponentiell, da sukzessive neue Services von den Projekten erstellt werden. Nach einer Sättigungsphase sollte das Servicewachstum rückläufig sein, da ein Grossteil der bankfachlichen Funktionalität in der Servicearchitektur abgebildet ist und nur neue Services entwickelt werden müssen, wenn auch tatsächlich neue bankfachliche Anforderungen entstehen. Alle anderen Projekte können die bereits entwickelten Services wiederverwenden. 2. Die Wiederverwendungsquote soll möglichst hoch sein, d.h., dass mög-

lichst viele Services von mehr als einer Applikation/einem Projekt genutzt werden. Dies sichert getätigte Investitionen in bereits entwickelte Services.


287

under development productive 88 88

87

45 45 93 55 109

98

340

449

500

641

173

00 00 01 03 01 00 02 03 20 20 20 20 20 20 20 20 . . . . . . . . 1 3 7 1 1 3 5 2 .1 .0 .0 .0 .1 .0 .0 .1 23 17 14 23 13 24 04 23

Abb. 5:

Wachstum der Services bei der Credit Suisse 2000-2003

Ziel ist es, durch Wiederverwendung von Services Entwicklungsaufwände zu reduzieren und somit Entwicklungskosten von Anwendungen zu senken. Eine maximale Wiederverwendung garantiert geringe Entwicklungskosten. Umso höher die Wiederverwendungsquote ist, desto höher die Kosteneinsparungen. Es wird angenommen, dass im Verlaufe der Zeit die Wiederverwendungsquote stetig ansteigen sollte, da neue Applikationen vermehrt vorhandene Services nutzen können. Bei der CS-Servicearchitektur betrug die Wiederverwendungsquote 34% (prozentualer Anteil bereits in einem anderen Projekt wiederverwendeter öffentlicher Services). Die durchschnittliche Wiederverwendung pro Service Anfang 2004 lag bei 1.7 (siehe Tab. 2). Bei der Wiederverwendung werden immer nur die öffentlich deklarierten Services berücksichtigt, da nur sie Wiederverwendungspotential besitzen.

288


Öffentliche (Public) Services

650

Interne (Internal) Services

500

Anzahl bereits wiederverwendeter Services

220

Prozentualer Anteil wiederverwendeter Services

34%

Durchschnittliche Wiederverwendung (Reuse) pro Service

1.7

Tab. 2

Anzahl öffentlicher und privater Services und ihre Wiederverwendung (Stand 20.01.2004)

Die Bewertung dieser Zahlen stellt sich als schwierig heraus. Was ist ein idealer Wiederverwendungsgrad? Ist mit einer durchschnittlich doppelten Wiederverwendung das Optimum erreicht, oder ist eine solche Quote ein Anzeichen für Qualitätsmängel? Neben der absoluten Wiederverwendungsquote sollte ebenso die Verteilung der Nutzung betrachtet werden. In Abbildung 6 ist zu erkennen, dass einige wenige Services sehr häufig verwendet werden (z.B. Services, die auf Kundenstammdaten zugreifen), ein Drittel moderaten Reuse aufzeigt, ein grosser Teil der Services aber eher selten wiederverwendet werden. Zu hinterfragen sind hier insbesondere die Services mit sehr seltener Wiederverwendung – hier könnte der Aufwand für ihre Erstellung den generierten Nutzen übersteigen – es sei denn, man erwartet, dass in Zukunft eine höhere Wiederverwendung erwartet wird. Hier ist auf ein grundsätzliches Dilemma hinzuweisen. Sollen Services „auf Verdacht“ wiederverwendbar gestaltet werden oder erst, wenn eine Wiederverwendung belegbar ist? Im ersten Fall ist die Wiederverwendungsquote notwendigerweise eher gering und es werden unter Umständen Aufwände unnötig getätigt. Im zweiten Fall entstehen im Falle der Wiederverwendung zusätzliche Kosten für das Redesign – es besteht die Gefahr einer doppelten Implementierung. Zudem können Veränderungen innerhalb der Applikationslandschaft Auswirkungen auf die Wiederverwendungsquote haben, wenn Applikationen konsolidiert (mehrere Applikationen werden nur noch als eine gezählt) oder entkoppelt (aus bisher einer Applikation werden mehrere) werden. Solche Gründe für eine Verschlechterung der Wiederverwendung sind nicht als Anzeichen für eine Verschlechterung der Architektur zu werten. Lediglich Defizite im Service-Design als Ursache für zu geringen Reuse sind bedenklich. Entweder werden zu hoch spezialisierte Services entworfen, so dass sie von anderen Applikationen nicht wieder verwendbar sind,


289

oder Services werden zu allgemein entworfen, so dass sie ebenfalls nicht oder nur schwer wiederverwendbar sind. In diesem Falle müsste der Entwurf von Services überdacht werden. Die Metriken liefern hier aber keine direkten Aufschlüsse, sondern zeigen auf, wo detailliertere Analysen notwendig sind. 60 50 40 30 20 10

EBVV CIF _Cha nnelId CIFS ent earch Ac GM_ ct Bookin g Depo sitQ s AV_A uery isQu OE_S ery earch CIF_ Create S DEG CRE_Cre WIFT A_Ord d erAtf itSlices RSS_ _Updat e Intere stRate CRE_ A Auto V_AisDe s lo fa INST mbard_U ult pdat e _Dep OE_F osi t_Upda te unctio nHold er ZV_S RiskClass cann ingMis CRE_ AV_AisO rd C DAD ommonD er MIN ata INST _CifL _Workflo w TInst_ U p IP MF_A C_Transadate cc_F low_U ct ion pdate RSAV PI_GetMo OE dif ER_O verdra yPrivate SEC_ ft sSearc h Assig nmen VIP_ ts A AD A CC_Gua VP0 3 C_ ra AD AC CodeCon ntees versio _Rep n o AZ_S rt ingValu es ca CAS_ nningOrd er CAS_ ATMD ai lyData ATMT CIFS _Serv ransaction s ic CRE_ ing_Upd at Cred it_Up e DBH D d _Safe ADMIN_ ate O k e rd e er ping EBV EBVV V_Contra Accounts ct_Up _Iden tif ic da ECO ation_Up te M_Co date nfigu ED_S ration tee H H YP YP_BTM rTable _Enca _U shme pdate ntT H YP erms _Mast KAU er F _Colla imsra KAU te w F ra _ KOS A_Ord Realprope l_Update rty_U erToB p a d la ate NZV_ PayP nce_Updat ath e OE_R PendSeg PIK_ equest _U Upd PRO C p al d K_Pri ceCo culationPri at e PROK mpLooku vate p_ _Pro ductR Upd RealP elations ropert RT RTT_ T_Bond_T ies Orde ools VAT_ r_Proposa FTAP l roduc WI_S ts tatus

0

Abb. 6

Verteilung der Wiederverwendung

Um Rückschlüsse auf Kosteneinsparungen zu ziehen, müssen neben der Wiederverwendungsquote vor allem die Anzahl bereits vorhandener Services, die von anderen Applikationen genutzt werden, herangezogen werden (siehe Abb. 6). Wenn man unterstellt, dass die durchschnittlichen Entwicklungskosten pro Service x betragen, so wurden Einsparungen in Höhe von r*x erzielt, da die bereits vorhandene Funktionalität nicht neu entwickelt werden musste. Die Variable r bezeichnet dabei die gesamte Anzahl wiederverwendeter Services (Mehrfachzählung). Allerdings ergaben Befragungen von Projektleitern, dass der nutzerseitige Aufwand bei Wiederverwendung nicht null ist. So muss beispielsweise im Projekt Know-how aufgebaut werden, um die Syntax und Semantik der Services zu verstehen. Dadurch entsteht ein erhöhter Kommunikationsaufwand zwischen der „wiederverwendenden“ Abteilung und der, die den Service ursprünglich entwickelt hat. Auf der anderen Seite entstehen aber durch die Wiederverwendung von Services Minderaufwände, vor allem in der Wartung, da weniger Services gewartet werden müssen und die Wartung zentral erfolgt. Die Beispiele der Credit Suisse zeigen, wie sich im Bereich Service-Nutzung mit relativ wenigen Daten grundlegende Erkenntnisse über den Zustand der Architektur gewinnen lassen. Fazit ist jedoch, dass Aufschlüsse über Handlungsbedarf und notwendige Massnahmen in der Regel nicht

290


direkt abgeleitet werden können, da das Spektrum der möglichen Ursachen für die Entwicklung einzelner Kennzahlen sehr breit ist.

5

Zusammenfassung

„Only what gets measured gets done“ (Eichstaedt/Kuhnert 2000, S. 34). Diese oft zitierte Aussage verdeutlicht, dass Metriken unerlässlich sind, um die konsequente Durchsetzung von Architekturanliegen und die Führung und Weiterentwicklung der Architektur sicherzustellen. Im vorliegenden Artikel wurden verschiedene Steuerungsmechanismen vorgestellt. Die Scorecard wurde als das wohl geeignetste Mittel für die Messung der Architekturqualität grosser IT-Systeme identifiziert, auch aufgrund mangelnder Verbreitung von Benchmarks in diesem spezifischen Bereich. Dabei wird die Agilität des IT-Systems als primäres Ziel definiert, dem diverse Teilziele untergeordnet sind. Die Definition von Metriken zur Bewertung der Zielerreichung ist in vielen Bereichen schwierig, da entweder die konkreten Einflussgrössen (bzw. ihre Gewichtung) nicht ermittelbar sind oder die Messung zu viel Aufwand erfordern würde. In Bereichen, in denen Zahlen erfassbar sind, fehlen Benchmarks oder andere Kriterien für die Bewertung und Interpretation der gemessenen Werte. Aus ökonomischer Sicht sind für die meisten Unternehmen gerade im Finanzbereich sowohl Kosteneffizienz als auch Flexibilität der IT-Plattform essentiell. Angesichts des sehr hohen Anteils der IT sowohl an den Kosten als auch an der Wertschöpfung in diesem Industriezweig besteht daher ein grosses Interesse am langfristigen Erhalt einer leistungsfähigen Plattform. Forschungsprojekte in diesem Bereich existieren aber bislang kaum. Neben grundsätzlichen Fragen im Kontext von Kenngrössen und Messverfahren erscheint uns auch eine vertiefte Untersuchung der Zusammenhänge der verschiedenen Teilziele und Einflussfaktoren wichtig zu sein. In diesem Sinne sollte dieser Artikel als Anregung verstanden werden, vertiefte Forschung in den genannten Gebieten zu betreiben und so die Grundlagen für die fundierte und effektive Steuerung von IT-Systemen in Grossunternehmen zu schaffen.


291

Literatur Baumöl, U.: Target Costing bei der Softwareentwicklung, München, 1998. Eichstaedt, W.; Kuhnert, M: Balanced Scorecard – Instrument zur gezielten strategischen Ausrichtung von Firmen und Geschäftseinheiten im Henkel-Konzern, 2000. Hagen, C.: Integrationsarchitektur der Credit Suisse, in: Aier, S.; Schönherr, M. (Hrsg.): Enterprise Application Integration – Flexibilisierung komplexer Unternehmensarchitekturen, Berlin, 2003, S. 61-81. Haufs, P.: DV Controlling: Konzeption eines operativen Instrumentariums aus Budgets – Verrechnungspreisen – Kennzahlen, Heidelberg, 1989. Horváth, P.: Target Costing: Marktorientierte Zielkosten in der deutschen Praxis, Stuttgart, 1993. Horváth, P.; Arnaout, A.; Seidenschwarz, W.: Neue Instrumente in der deutschen Unternehmenspraxis, Bericht über die Stuttgarter Studie, in: Egger, A.; Grün, O.; Moser, R. (Hrsg.): Managementinstrumente und -konzepte, Verbreitung und Bedeutung für die Betriebswirtschaftslehre, Stuttgart, 1999. Horváth, P.; Herter, R.: Benchmarking – Vergleich mit den Besten der Besten, in: Controlling, 4 (1992), 1, S. 4-11. Horváth, P.; Kaufmann, L.: Balanced Scorecard – ein Werkzeug zur Umsetzung von Strategien, in: Harvard Business Manager, 5 (1998), S. 39-48. Horváth, P.; Kieninger, M.; Mayer, R.: Prozeßkostenrechnung – oder wie die Praxis die Theorie überholt, in: Die Betriebswirtschaft, 53 (1993), 5, S. 609-628. Jäger-Goy, H.: Innovative Führungsinstrumente für die Informationsverarbeitung, Working Paper, Universität Mainz, Mainz, 1999. Jäger-Goy, H.: Führungsinstrumente für das IV-Management, Dissertation, Johannes-Gutenberg-Universität Mainz, Frankfurt am Main, 2001. Kaplan, R.S.; Norton, D. P.: Balanced Scorecard, Stuttgart, 1997. Kaplan, R.S.; Norton, D.P.: The Strategy-Focused Organization: How Balanced Scorecard Companies thrive in the new Business Environment, Boston/ Massachusetts, 2001. Legner, C.: Benchmarking informationssystemgestützter Geschäftsprozesse, Dissertation der Universität St. Gallen, Wiesbaden, 1999. Niemand, S.: Target Costing für industrielle Dienstleistungen, München, 1999.

292


Österle, H.; Brenner, W.; Hilbers, K.: Unternehmensführung und Informationssystem, 1. Aufl., Stuttgart, 1991. Reichmann, T.: Controlling mit Kennzahlen und Managementberichten: Grundlagen einer systemgestützten Controlling-Konzeption, 5., überarb. und erw. Aufl., München, 1997. Schweizer, M.; Küpper, H. U.: Systeme der Kosten- und Erlösrechnung, 6. Auflage, München, 1995. Seidenschwarz, W.: Target Costing, München, 1991.

Autorenverzeichnis Dr. Andreas Dietzsch

Martin Hafner

Die Mobiliar Schweizerische Mobiliar Versicherungsgesellschaft Bundesgasse 35 CH-3001 Bern E-Mail: [email protected]

Universität St. Gallen Institut für Wirtschaftsinformatik Müller-Friedberg-Straße 8 CH-9000 St. Gallen E-Mail: [email protected] URL: http://www.iwi.unisg.ch

Dr. Claus Hagen

Josef Rupprecht

Credit Suisse Financial Services Lessingstrasse 3 Postfach 600 CH-8070 Zürich E-Mail: [email protected]

DATA MART Consulting GmbH Martin-Behaim-Str. 2 D-63263 Neu-Isenburg E-Mail: [email protected]

Dr. Joachim Schelp

Alexander Schwinn

Universität St. Gallen Institut für Wirtschaftsinformatik Müller-Friedberg-Strasse 8 CH-9000 St. Gallen E-Mail: [email protected] URL: http://www.iwi.unisg.ch


Andreas Siegenthaler

Prof. Dr. Robert Winter

Raiffeisen Informatik AG Wassergasse 24 CH-9001 St. Gallen E-Mail: [email protected]


Felix Wortmann Universität St. Gallen Institut für Wirtschaftsinformatik Müller-Friedberg-Strasse 8 CH-9000 St. Gallen E-Mail: [email protected] URL: http://www.iwi.unisg.ch

Integrationsmanagement: Planung, Bewertung und Steuerung von Applikationslandschaften (Business Engineering) (German Edition)

Integrationsmanagement: Planung, Bewertung und Steuerung von Applikationslandschaften (Business Engineering) (German Edition)

Planung und Steuerung von Innovationsprojekten

Management von operationellen Risiken: Kategorisierung, Bewertung, Steuerung

Zinsderivate: Modelle und Bewertung (German Edition)

Raumflugmechanik: Dynamik und Steuerung von Raumfahrzeugen (German Edition)

Zinsderivate: Modelle und Bewertung (German Edition)

Baukosten bei Neu- und Umbauten: Planung und Steuerung, 4.Auflage

Transport- und Lagerlogistik: Planung, Struktur, Steuerung und Kosten von Systemen der Intralogistik

Bewertung und Verstaerkung von Stahlbetontragwerken (Bauingenieur-Praxis)

Kunst der Markenfuehrung Aufbau Pflege und Bewertung von Marken Edition

Nachweisvermögen von Analysenverfahren: Objektive Bewertung und Ergebnisinterpretation

Echtzeitsysteme: Grundlagen der Planung (eXamen.press) (German Edition)

Planung von Photovoltaik-Anlagen

Nachhaltige Wertschöpfungsnetzwerke: Überbetriebliche Planung und Steuerung von Stoffströmen entlang des Produktlebenszyklus

Ökologische und ökonomische Bewertung von Co-Vergärungsanlagen und deren Standortwahl

Modellierung und Bewertung von Prozessketten zur Herstellung von Biokraftstoffen der zweiten Generation german

Bewertung von Innovationen im Mittelstand

Produktions- und Logistikmanagement: Planung und Gestaltung von Wertschopfungsprozessen (Lehrbuch)

Seehäfen: Planung und Entwurf

Business Engineering in der Praxis (Business Engineering) German

Die Bedeutung und Bewertung der Pleónexie von Homer bis Isokrates

Forsteinrichtung: Adaptive Steuerung und Mehrpfadprinzip

Die Kunst der Markenfuhrung: Aufbau, Pflege und Bewertung von Marken

Portfoliotheorie, Risikomanagement und die Bewertung von Derivaten, 2. Auflage

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Bauaufnahme und Planung im Bestand

Wasserkraftanlagen: Planung, Bau und Betrieb

Test und Verlässlichkeit von Rechnern (eXamen.press) (German Edition)

Simulation von Kraftwerken und wärmetechnischen Anlagen (German Edition)

Graphen- und Netzwerkoptimierung (German Edition)

Integrationsmanagement: Planung, Bewertung und Steuerung von Applikationslandschaften (Business Engineering) (German Edition)