Management komplexer IT-Architekturen: Empirische Analyse am Beispiel der internationalen Finanzindustrie

Christian Schmidt Management komplexer IT-Architekturen Empirische Analyse am Beispiel der internationalen Finanzindus...

Author: Christian Schmidt

73 downloads 1937 Views 1MB 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

Christian Schmidt

Management komplexer IT-Architekturen Empirische Analyse am Beispiel der internationalen Finanzindustrie

Mit einem Geleitwort von Prof. Dr. Peter Buxmann

GABLER EDITION WISSENSCHAFT

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

Dissertation Technische Universität Darmstadt, 2009 D17

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

Geleitwort Das stetige Komplexitätswachstum der Unternehmens-IT führt in der Praxis zu vielfältigen Problemen. Ursächlich hierfür sind einerseits die vielschichtigen und dynamischen Rahmenbedingungen, unter denen die IT-Landschaften von großen Unternehmen sich entwickeln, andererseits aber auch Defizite im Bereich des IT-Managements. So haben insbesondere die traditionellen Planungssysteme mit ihrer Fokussierung auf die konkreten Anforderungen einzelner Stakeholder und einer tendenziell eher kurz- bis mittelfristigen Ausrichtung in der Vergangenheit häufig zu Fehlentwicklungen beigetragen. Vor diesem Hintergrund wird in der Praxis zunehmend die Notwendigkeit einer ganzheitlichen und langfristig orientierten Steuerung der IT auf der Ebene der Makroarchitektur anerkannt. Mit dem IT-Architekturmanagement bzw. Enterprise Architecture Management hat sich hierzu innerhalb der letzten Jahre eine eigene Disziplin herausgebildet. Aufgrund der komplexen Problemstellung und der fehlenden methodischen Reife stellt die Implementierung einer entsprechenden Funktion im Unternehmen jedoch eine besondere Herausforderung für das IT-Management dar. Christian Schmidt widmet sich in seiner Arbeit einer umfassenden wissenschaftlichen Analyse dieses bisher noch wenig erschlossenen Themengebietes. Seine primären Forschungsziele liegen dabei in einer Erfassung und Beschreibung der in der Praxis existierenden Ansätze einerseits sowie einer methodisch fundierten Identifikation von entsprechenden Erfolgsfaktoren andererseits. Zur Beantwortung seiner Forschungsfragen verfolgt Herr Schmidt einen empirischen Forschungsansatz. Er beginnt seine Untersuchung mit einer systematischen Ordnung der zugrundeliegenden Terminologie und leistet damit einen wichtigen Beitrag für die Begriffskonsolidierung in diesem noch jungen Feld. Darauf aufbauend untersucht er die wichtigsten theoretischen Aspekte des Architekturmanagements. Unter Bezugnahme auf die Systemtheorie, die Stakeholder-Theorie, die Theorie der Software-Evolution sowie die Organisationstheorie zeigt er unter anderem, warum und unter welchen Bedingungen es in der Praxis zu einem unkontrollierten Komplexitätswachstum kommen kann, und welche Rolle das Architekturmanagement einnehmen muss, um dies zu verhindern.

vi

Geleitwort

Anschließend widmet sich Herr Schmidt einer umfangreichen empirischen Analyse. Anhand der Ergebnisse einer Expertenbefragung mit 14 Architekturverantwortlichen aus der Kreditwirtschaft stellt er dabei zunächst die Praxis des Architekturmanagements in ihrer ganzen Bandbreite dar. Daraufhin wendet sich Herr Schmidt dem wichtigen Thema der Erfolgsmessung und einer darauf aufbauenden Analyse von Erfolgsfaktoren des Architekturmanagements zu. Im Rahmen einer komparativen Fallstudienuntersuchung analysiert er hierzu zunächst auf qualitativer Ebene die Architekturmanagement-Implementierungen von drei europäischen Großunternehmen hinsichtlich ihrer jeweiligen Erfolgswirkung. Auf der Grundlage einer Studie bei den 500 größten Finanzdienstleistern aus Europa, Nordamerika und Australien bestimmt er anschließend erstmals Wirkungen und Erfolgsfaktoren des Architekturmanagements auf quantitativ-statistischem Wege. Seinen Forschungszielen entsprechend, leitet Herr Schmidt aus den Ergebnissen der theoretischen und empirischen Analyse schließlich konkrete Handlungsempfehlungen für die Praxis ab. Herr Schmidt hat in seiner Arbeit ein bisher wissenschaftlich nur in Ansätzen erschlossenes und sehr praxisrelevantes Thema bearbeitet. Er wird dabei zugleich hohen methodischen Ansprüchen gerecht. Gelungen ist aus meiner Sicht insbesondere die Mischung aus qualitativen und quantitativen methodischen Elementen, welche zu einem besseren Verständnis der komplexen Zusammenhänge beiträgt. Mit Hilfe der Arbeit von Herrn Schmidt können – etwa aus der Beratungspraxis – bekannte Aussagen zum ersten Mal auf ihren wissenschaftlichen Gehalt hin überprüft werden. Die Arbeit von Herrn Schmidt leistet damit einen wichtigen Beitrag zur Weiterentwicklung der Disziplin des Architekturmanagements im Speziellen und der Wirtschaftsinformatik im Allgemeinen. Trotz der Fülle an Inhalten ist die Arbeit vergleichsweise schlank und sehr gut lesbar. Sie empfiehlt sich daher insbesondere auch für auf dem Gebiet tätige Praktiker wie CIOs und IT- bzw. Unternehmensarchitekten. Ich wünsche Herrn Schmidt eine entsprechend weite Verbreitung seiner Arbeit sowohl in der Wissenschaft als auch in der Praxis. Prof. Dr. Peter Buxmann

Vorwort Beim vorliegenden Buch handelt es sich um die leicht gekürzte Fassung meiner am Fachgebiet Information Systems / Wirtschaftsinformatik der Technischen Universität Darmstadt entstandenen Dissertation. Die Grundlage der Arbeit bilden mehrere empirische Studien zur Praxis des Architekturmanagements, die ich zwischen den Jahren 2005 und 2008 in Zusammenarbeit mit zahlreichen Unternehmen aus der Finanzindustrie durchgeführt habe. Der Weg von der ersten Idee bis zum Druck der Arbeit war lang und steinig, mindestens aber genauso spannend und lehrreich. Auf ihm haben mich verschiedene Menschen begleitet und unterstützt, denen ich hierfür herzlich danken möchte. An erster Stelle ist dabei meine Frau Vân zu nennen, die mir mit großer Geduld zur Seite stand und zu keinem Zeitpunkt am Erfolg meines Vorhabens gezweifelt hat. Zu tiefem Dank bin ich weiterhin meinen beiden Betreuern Prof. Dr. Peter Buxmann und Prof. Dr. Zbynek Sokolovsky verpflichtet. Prof. Buxmann hat mich durch seinen hohen wissenschaftlichen Anspruch zu besonderen Leistungen motiviert. Er hat mir zugleich größtmögliche Freiheiten bei der inhaltlichen Auswahl und Entwicklung meines Themas gelassen. Als Zweitgutachter hat auch Prof. Sokolovsky mein Vorhaben von Beginn an begleitet. Seine langjährigen praktischen Erfahrungen bildeten für mich in jeder Hinsicht eine wichtige Inspirationsquelle. Mein besonderer Dank gilt weiterhin To-Uyen Mac, welche mich mit Verve und Charme bei der Durchführung meiner Hauptstudie unterstützt hat, sowie Matthias Kunz, der wesentlichen Anteil an der Fallstudienuntersuchung hatte. Dank gebührt ferner allen Studienteilnehmern für ihr Vertrauen und ihr Engagement. Ohne ihre Mitwirkung wären meine Forschungsergebnisse nicht zustande gekommen. Hervorzuheben sind hierbei Ernst Siegrist (Credit Suisse), Volker Ernst (DZ Bank), Detlev Klage (Finanz Informatik), Thomas Winiarski (GE MoneyBank) und Dr. Sebastian Ritz (Xchanging), welche mich wiederholt unterstützt haben. Zu Dank bin ich schließlich Johannes Wallenborn (IBM), Steffen Lorenz (Software AG) sowie Dr. Stefan Ried (Forrester Research) verpflichtet, die mir bei der Sammlung von Kontaktdaten und der Bekanntmachung meiner Hauptstudie behilflich waren. Herzlich bedanken möchte ich mich außerdem bei allen Mitarbeitern und Doktoranden des Fachgebietes Information Systems / Wirtschaftsinformatik der Technischen Universität Darm-

viii

Vorwort

stadt für das angenehme Arbeitsumfeld, den stets konstruktiven Meinungsaustausch sowie die vielfältige Unterstützung. Mein persönlicher Dank gilt insbesondere Patrick Johnscher, Thomas Widjaja und Sven Schade, die mir auch über die gemeinsame Promotionszeit hinaus freundschaftlich verbunden bleiben. Ich danke ferner Klaus D. Niemann und den Kollegen von act! consulting für die sehr fruchtbare Zusammenarbeit und den mir überlassenen Freiraum zum erfolgreichen Abschluss meiner Promotion. Besonderer Dank gilt schließlich meinen Eltern, welche durch ihre Erziehung und ihren Einfluss auf meinen Bildungsweg den Grundstein für meine spätere Entwicklung gelegt haben. Christian Schmidt

Inhaltsverzeichnis

Abbildungsverzeichnis

xv

Tabellenverzeichnis

xvii

Abkürzungsverzeichnis

xix

1

2

Einführung

1

1.1

Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2

Zielsetzung und Gang der Untersuchung . . . . . . . . . . . . . . . . . .

4

1.3

Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.4

Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Begriffliche Grundlagen

7

2.1

Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.1

Allgemeiner Systembegriff . . . . . . . . . . . . . . . . . . . .

7

2.1.2

System und Modell . . . . . . . . . . . . . . . . . . . . . . . .

11

2.1.3

Betriebliche Informationssysteme . . . . . . . . . . . . . . . . .

12

Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.2.1

Allgemeiner Architekturbegriff . . . . . . . . . . . . . . . . . .

15

2.2.2

Systemtechnischer Architekturbegriff . . . . . . . . . . . . . . .

15

2.2.3

Architektur im Systementwicklungsprozess

. . . . . . . . . . .

18

2.2.4

Architektur von Informationssystemen . . . . . . . . . . . . . .

20

2.2.4.1

IT-Mikroarchitektur . . . . . . . . . . . . . . . . . .

20

2.2.4.2

IT-Makroarchitektur . . . . . . . . . . . . . . . . . .

21

2.2

3

Management der IT-Makroarchitektur

25

3.1

Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.1.1

26

Evolution des Unternehmensinformationssystems . . . . . . . .

x

Inhaltsverzeichnis

3.2

3.3

4

3.1.2

Komplexitätswachstum . . . . . . . . . . . . . . . . . . . . . .

31

3.1.3

Systemevolution am Beispiel der Finanzwirtschaft . . . . . . . .

32

Konzeptioneller Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.2.1

Gegenstand und Funktion . . . . . . . . . . . . . . . . . . . . .

37

3.2.2

Analogie zum Städtebau . . . . . . . . . . . . . . . . . . . . .

39

3.2.2.1

Ähnlichkeit der Problemstruktur . . . . . . . . . . .

39

3.2.2.2

Methodik und Organisation der Stadtplanung . . . . .

41

3.2.2.3

Beurteilung . . . . . . . . . . . . . . . . . . . . . .

44

3.2.3

Theoretisches Framework . . . . . . . . . . . . . . . . . . . . .

45

3.2.4

Einordnung in das Informationsmanagement . . . . . . . . . . .

48

Bestehende Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

3.3.1

TOGAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

3.3.2

Enterprise Unified Process . . . . . . . . . . . . . . . . . . . .

54

3.3.3

Management der IS-Architektur nach Hafner . . . . . . . . . . .

57

Praxis des Architekturmanagements: Ergebnisse einer Expertenbefragung

61

4.1

Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

4.2

Empirische Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.2.1

Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.2.2

Historische Entwicklung und Reifegrad . . . . . . . . . . . . . .

64

4.2.3

Organisationsstruktur . . . . . . . . . . . . . . . . . . . . . . .

65

4.2.4

Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

4.2.5

Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

4.2.6

Instrumente . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

4.2.6.1

Allgemeine Ordnungsinstrumente . . . . . . . . . . .

71

4.2.6.2

Instrumente der Dokumentation und Planung . . . . .

72

4.2.6.3

Instrumente der Architektur-Programmierung . . . .

77

4.2.7

Systemtechnische Gestaltungsziele . . . . . . . . . . . . . . . .

79

4.2.8

Wirkungen

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

4.2.9

Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

Inhaltsverzeichnis

4.2.10

5

xi

Erfolgsfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . .

82

4.3

Zwischenfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

4.4

Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

Fallstudien

87

5.1

Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

5.2

Unternehmen A: eine internationale Universalbank . . . . . . . . . . . .

89

5.2.1

Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . .

90

5.2.2

Implementierung des Architekturmanagements . . . . . . . . . .

90

5.2.2.1

Organisation . . . . . . . . . . . . . . . . . . . . . .

91

5.2.2.2

Aufgaben . . . . . . . . . . . . . . . . . . . . . . .

92

5.2.2.3

Instrumente . . . . . . . . . . . . . . . . . . . . . .

94

5.2.2.4

Zielsetzung . . . . . . . . . . . . . . . . . . . . . .

96

Historische Entwicklung und erzielte Ergebnisse . . . . . . . . .

97

Unternehmen B: eine internationale Automobilbank . . . . . . . . . . . .

98

5.3.1


98

5.3.2


99

5.3.2.1

Organisation . . . . . . . . . . . . . . . . . . . . . .

99

5.3.2.2

Aufgaben . . . . . . . . . . . . . . . . . . . . . . .

100

5.3.2.3

Instrumente . . . . . . . . . . . . . . . . . . . . . .

101

5.3.2.4

Zielsetzung . . . . . . . . . . . . . . . . . . . . . .

103


104

Unternehmen C: ein nationaler IT-Dienstleister . . . . . . . . . . . . . .

105

5.4.1


105

5.4.2


105

5.4.2.1

Organisation . . . . . . . . . . . . . . . . . . . . . .

106

5.4.2.2

Aufgaben . . . . . . . . . . . . . . . . . . . . . . .

107

5.4.2.3

Instrumente . . . . . . . . . . . . . . . . . . . . . .

108

5.4.2.4

Zielsetzung . . . . . . . . . . . . . . . . . . . . . .

109


110

5.2.3 5.3

5.3.3 5.4

5.4.3

xii

Inhaltsverzeichnis

5.5

5.6 6

Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

111

5.5.1

Unternehmen A . . . . . . . . . . . . . . . . . . . . . . . . . .

111

5.5.2

Unternehmen B . . . . . . . . . . . . . . . . . . . . . . . . . .

113

5.5.3

Unternehmen C . . . . . . . . . . . . . . . . . . . . . . . . . .

115

5.5.4

Vergleichende Analyse . . . . . . . . . . . . . . . . . . . . . .

116


117

Wirkungen und Erfolgsfaktoren: eine quantitative Analyse

119

6.1

Konzeptualisierung und Hypothesenentwicklung . . . . . . . . . . . . .

120

6.1.1

Architekturziele . . . . . . . . . . . . . . . . . . . . . . . . . .

121

6.1.1.1

IT-Effizienz . . . . . . . . . . . . . . . . . . . . . .

121

6.1.1.2

IT-Flexibilität . . . . . . . . . . . . . . . . . . . . .

122

6.1.1.3

Zielbeziehungen . . . . . . . . . . . . . . . . . . . .

123

6.1.2

AM-Implementierung . . . . . . . . . . . . . . . . . . . . . . .

123

6.1.3

Forschungsmodell . . . . . . . . . . . . . . . . . . . . . . . . .

127

Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

6.2.1

Studiendesign . . . . . . . . . . . . . . . . . . . . . . . . . . .

130

6.2.2

Operationalisierung . . . . . . . . . . . . . . . . . . . . . . . .

131

6.2.2.1

AM-Ansatz . . . . . . . . . . . . . . . . . . . . . .

131

6.2.2.2

AM-Dauer . . . . . . . . . . . . . . . . . . . . . . .

137

6.2.2.3

IT-Flexibilität . . . . . . . . . . . . . . . . . . . . .

137

6.2.2.4

IT-Effizienz . . . . . . . . . . . . . . . . . . . . . .

137

6.2.2.5

Kontrollvariablen . . . . . . . . . . . . . . . . . . .

139

6.2.3

Datenerhebung . . . . . . . . . . . . . . . . . . . . . . . . . .

141

6.2.4

Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . .

142

6.2.4.1

Auswahl des Verfahrens . . . . . . . . . . . . . . . .

142

6.2.4.2

Der PLS-Ansatz . . . . . . . . . . . . . . . . . . . .

144

6.2.4.3

Anwendung . . . . . . . . . . . . . . . . . . . . . .

146

Empirische Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . .

147

6.3.1

147

6.2

6.3

Stichprobencharakteristik . . . . . . . . . . . . . . . . . . . . .

Inhaltsverzeichnis

xiii

6.3.2

Qualitätskriterien . . . . . . . . . . . . . . . . . . . . . . . . .

148

6.3.3

Deskriptive Analyse . . . . . . . . . . . . . . . . . . . . . . . .

150

6.3.3.1

Implementierungsdauer und Ziele . . . . . . . . . . .

150

6.3.3.2

AM-Implementierung . . . . . . . . . . . . . . . . .

151

6.3.3.3

Zielgrößen . . . . . . . . . . . . . . . . . . . . . . .

155

Evaluierung des Forschungsmodells . . . . . . . . . . . . . . .

157

6.3.4.1

Messmodell . . . . . . . . . . . . . . . . . . . . . .

157

6.3.4.2

Strukturmodell . . . . . . . . . . . . . . . . . . . .

161

6.4

Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . .

163

6.5


165

6.3.4

7

Schlussfolgerungen für die Praxis

167

8

Zusammenfassung und Ausblick

173

Literaturverzeichnis

177

Abbildungsverzeichnis 1.1

Forschungsdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1

Systemkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2

Strukturtypen der Systemkopplung . . . . . . . . . . . . . . . . . . . . . . .

10

2.3

Aufgabenebene und Aufgabenträgerebene des UIS . . . . . . . . . . . . . . .

13

2.4

Definitionen nach IEEE 1471–2000 . . . . . . . . . . . . . . . . . . . . . .

16

2.5

Konzeptuelles Modell des IEEE 1471–2000 . . . . . . . . . . . . . . . . . .

18

2.6

Zachman-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1

Stakeholder des Unternehmensinformationssystems . . . . . . . . . . . . . .

28

3.2

Ansatzpunkte der Stadtplanung . . . . . . . . . . . . . . . . . . . . . . . . .

42

3.3

Konzeptioneller Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

3.4

Funktionen des strategischen Informationsmanagements . . . . . . . . . . . .

49

3.5

TOGAF ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

3.6

EUP-Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

3.7

Vorgehensmodell nach Hafner . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.1

Selbsteinschätzung des Reifegrades

. . . . . . . . . . . . . . . . . . . . . .

65

4.2

Aufgabenbereiche des Architekturmanagements . . . . . . . . . . . . . . . .

69

4.3

Cluster-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

4.4

Matrix-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

4.5

Portfolio-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

4.6

Graphenorientiertes Modell einer Referenzarchitektur . . . . . . . . . . . . .

76

4.7

Architekturprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

4.8

Standard-Katalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

5.1

Architektur-Framework Fall A . . . . . . . . . . . . . . . . . . . . . . . . .

91

6.1

Forschungsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

6.2

Strukturgleichungsmodell in PLS . . . . . . . . . . . . . . . . . . . . . . . .

145

6.3

Teilnehmer nach Regionen . . . . . . . . . . . . . . . . . . . . . . . . . . .

148

6.4

Teilnehmer nach Geschäftsfeldern . . . . . . . . . . . . . . . . . . . . . . .

149

6.5

Teilnehmer nach Anzahl Mitarbeiter . . . . . . . . . . . . . . . . . . . . . .

149

xvi

Abbildungsverzeichnis

6.6

Antwort-Profile AM-Implementierungsdauer . . . . . . . . . . . . . . . . . .

151

6.7

Strukturmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

161

Tabellenverzeichnis 5.1

Vergleichende Übersicht der Fallstudien . . . . . . . . . . . . . . . . . . . .

112

6.1

Operationalisierung der Dimension Architektur-Dokumentation . . . . . . . .

133

6.2

Operationalisierung der Dimension Architektur-Planung . . . . . . . . . . . .

133

6.3

Operationalisierung der Dimension Architektur-Programmierung . . . . . . .

134

6.4

Operationalisierung der Dimension Architektur-Implementierung . . . . . . .

134

6.5

Operationalisierung der Dimension Architektur-Kommunikation & Support . .

135

6.6

Operationalisierung der Dimension Architektur-Governance . . . . . . . . . .

135

6.7

Operationalisierung der Dimension Stakeholder-Partizipation . . . . . . . . .

136

6.8

Operationalisierung der AM-Dauer . . . . . . . . . . . . . . . . . . . . . . .

136

6.9

Operationalisierung der IT-Flexibilität . . . . . . . . . . . . . . . . . . . . .

138

6.10 Operationalisierung der IT-Effizienz . . . . . . . . . . . . . . . . . . . . . .

139

6.11 Operationalisierung Kontrollvariablen . . . . . . . . . . . . . . . . . . . . .

140

6.12 Operationalisierung Zielsetzungen . . . . . . . . . . . . . . . . . . . . . . .

140

6.13 Antwort-Profile Zielsetzungen . . . . . . . . . . . . . . . . . . . . . . . . .

152

6.14 Antwort-Profile AM-Ansatz (1) . . . . . . . . . . . . . . . . . . . . . . . . .

153

6.15 Antwort-Profile AM-Ansatz (2) . . . . . . . . . . . . . . . . . . . . . . . . .

154

6.16 Antwort-Profile Zielgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . .

156

6.17 Messmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . √ 6.18 Korrelationsmatrix mit AV E auf der Diagonalen . . . . . . . . . . . . . .

159 160

Abkürzungsverzeichnis ADL ADM AIX AkEA AM AM-A AM-B AM-C ARIS AS/400 AVE Basel II BPM BSP BauGB Bil. CICS CIO COBOL COM CORBA CRM CTO DB2 DBMS DCOM DoD EA EAI EAM E-Mail EPK

Architecture Description Language Architecture Development Method Advanced Interactive Executive (IBM) Arbeitskreis Enterprise Architecture (GI) Architekturmanagement Architekturmanagement Fallstudie A Architekturmanagement Fallstudie B Architekturmanagement Fallstudie C Architektur Integrierter Informationssysteme Application System 400 (IBM) Average Variance Extracted Zweite Baseler Eigenkapitalvereinbarung Business Process Management Business Systems Planning (IBM) Baugesetzbuch Billionen Customer Information Control System (IBM) Chief Information Officer Common Business Oriented Language Component Object Model (Microsoft) Common Object Request Broker Architecture Customer Relationship Management Chief Technology Officer Database 2 (IBM) Data Base Management System Distributed Component Object Model (Microsoft) Department of Defense Enterprise Architecture Enterprise Application Integration Enterprise Architecture Management Electronic Mail Ereignisgesteuerte Prozessketten

xx

ERP ETL EU EUP EUR FEA FEAF FSA FSB FSC FTP GI HTML HTTP IBM IEEE IFRS IP IS IT J2EE MaH MaK MAK MDA MEMO MiFID Mio. Mrd. MS MVS OLS OMG OS/360 OS/390


Enterprise Resource Planning Extract, Transform, Load Europäische Union Enterprise Unified Process Euro Federal Enterprise Architecture Federal Enterprise Architecture Framework Fallstudie A Fallstudie B Fallstudie C File Transfer Protocol Gesellschaft für Informatik e. V. Hypertext Markup Language Hypertext Transfer Protocol International Business Machines Corporation Institute of Electrical and Electronics Engineers International Financial Reporting Standards Interviewpartner Informationssystem Informationstechnologie Java 2 Platform, Enterprise Edition (Sun) Mindestanforderungen an das Betreiben von Handelsgeschäften Mindestanforderungen an das Kreditgeschäft Mitarbeiterkapazität Model Driven Architecture Multi-Perspective Enterprise Modeling Markets in Financial Instruments Directive Millionen Milliarden Microsoft Corporation Multiple Virtual Storage (IBM) Ordinary Least Squares Object Management Group Operating System 360 (IBM) Operating System 390 (IBM)


PC PDA PDF PL/1 PLS RBV RUP SEC SEM SISP SLA SOA SOAP SOM SPEM SQL STP TCP/IP TAFIM TOGAF UCP UIS UML URL US USD VS WWW XML

Personal Computer Personal Digital Assistant Portable Document Format Programming Language One Partial-Least-Squares Resource Based View Rational Unified Process Section Structured Equation Modeling Strategic Information Systems Planning Service Level Agreement Service-Oriented-Architecture Simple Object Access Protocol Semantisches Objektmodell Software Process Engineering Metamodel Structured Query Language Straight Through Processing Transmission Control Protocol / Internet Protocol Technical Architecture Framework for Information Management The Open Group Architecture Framework Use Case Point Unternehmensinformationssystem Unified Modeling Language Uniform Resource Locator United States United States Dollar Vorstudie World Wide Web Extended Markup Language

xxi

Kapitel 1

Einführung

Seit der Einführung von Informationstechnologie (IT) ab der Mitte des 20. Jahrhunderts ist die Komplexität der betrieblichen IT-Umgebungen kontinuierlich gewachsen. Heute umfassen die IT-Landschaften großer Unternehmen oft mehrere hundert Einzelapplikationen. Diese sind zudem meist über vielfältige Schnittstellenbeziehungen miteinander verbunden und werden häufig auf sehr heterogenen technologischen Plattformen betrieben (vgl. z. B. Lankes et al., 2005, S. 2). Besonders augenfällig ist die Entwicklung der IT-Komplexität bei Finanzdienstleistern wie Banken und Versicherungen. Aufgrund der Informationsintensität ihrer Produkte und Prozesse sind diese in erhöhtem Maße auf den Einsatz von Informationstechnologie angewiesen (Porter und Millar, 1985, S. 153).1 In der Finanzindustrie ist es deshalb zu einer vergleichsweise frühen Adoption sowie einer hohen Durchdringung mit Informationstechnologie gekommen. Im Laufe der Jahrzehnte sind dabei vom allem in größeren Konzernen zum Teil nur noch schwer überschaubare IT-Landschaften entstanden. Diese zählen heute zu den komplexesten vom Menschen geschaffenen Systemen überhaupt (vgl. auch Zachman, 1997, S. 2f.).

1

Finanzprodukte können allgemein als Dienstleistungen angesehen werden, welche die Eigenschaften und / oder Verfügungsrechte von Nominalkapital verändern (Wildemann, 2005, S. 306). Sie werden durch Informationen repräsentiert und heute primär in elektronischer Form verarbeitet (vgl. Rothe, 2003, S. 38ff.; Winter, 2005, S. 577). Die Informationsverarbeitung steht folglich im Zentrum der finanzwirtschaftlichen Leistungserstellung (vgl. Moormann, 2004, S. 5; Stahl und Wimmer, 2003, S. 173).

2

Einführung

In der Praxis schlägt sich die wachsende Komplexität der Unternehmens-IT in einer Vielzahl von Problemen nieder (vgl. z. B. Moormann, 2004, S. 10f.; Buhl und Heinrich, 2004, S. 311; Winter, 2004, S. 318; Namba, 2005, S. 3). So sind einerseits die Anforderungen an ein sicheres und zielorientiertes Management der IT erheblich gestiegen. Damit haben sich auch die operationalen Risiken deutlich erhöht.2 Andererseits sind die durch Wartung und Betrieb der IT verursachten Kosten kontinuierlich angewachsen (vgl. z. B. Namba, 2005, S. 3; Winter, 2004, S. 318).3 Die im Zuge der IT-Einführung durch Prozessautomatisierung erzielten Effizienzgewinne wurden so zu einem Teil wieder aufgehoben. Schließlich hat das Komplexitätswachstum auch zu einer zunehmenden ”Verkrustung” der IT und einem Verlust an Flexibilität gegenüber Veränderungen geführt (”IT-Sklerose”) (vgl. z. B. Buhl und Heinrich, 2004, S. 311; Milleg und Gary, 2007). Dies spiegelt sich vor allem in hohen Entwicklungskosten und einer gestiegenen Produkteinführungszeit (”Time-to-Market”) wider. In vielen Unternehmen wurde so die Handlungsfähigkeit der gesamten Organisation eingeschränkt (vgl. CIO Magazine, 2005a).4 Als Folge dieser Entwicklung besteht heute in zahlreichen Unternehmen eine Divergenz zwischen der strategischen Ausrichtung einerseits und der hierfür verfügbaren IT-Unterstützung andererseits (”Business-IT-Alignment”) (siehe hierzu z. B. Luftman, 2005, S. 271). Entgegen den Erwartungen vieler Entscheidungsträger konnten die beschriebenen Probleme auch durch eine Verringerung der Wertschöpfungstiefe im Bereich des Informationsmanagements nicht grundlegend beseitigt werden. So hat insbesondere die zunehmende Verfügbarkeit von Standardsoftware bisher nicht zu einer nachhaltigen Reduktion der IT-Komplexität in den Unternehmen geführt (s. z. B. CIO Magazine, 2006).5 Ähnliches gilt für die Auslagerung von Teilen der Informationsverarbeitung an externe Dienstleister (Outsourcing).6

2

3

4 5

6

Dies ist aufgrund der Baseler Eigenkapitalvorschriften von besonderer Bedeutung für Banken. Operationale Risiken werden dabei definiert als ”die Gefahr von Verlusten, die in Folge der Unangemessenheit oder des Versagens von internen Verfahren, Menschen und Systemen oder in Folge von externen Ereignissen eintreten” (Basel Committee on Banking Supervision, 2003, S. 2, in eigener Übersetzung). Der Anteil der Wartungs- und Betriebskosten an den IT-Gesamtkosten liegt bei Banken heute typischerweise bei etwa 70% (vgl. Fischer und Rothe, 2004, S. 25; CIO Magazine, 2005b). Insgesamt haben sich die IT-Kosten von Banken im Zeitraum zwischen 1990 und 1998 um 96% (Rechenzentrum) bzw. 142% (IT-Filialkosten) erhöht (Wild, 2001, S. 17f.; Dickamp, 1999). Die Rolle der IT hat sich damit in gewisser Hinsicht vom Innovationstreiber (”Enabler”) zum Innovationsverhinderer (”Disabler”) gewandelt. Eine Ursache hierfür kann in der Unvollständigkeit bzw. in den Qualitätsunterschieden der existierenden Standardlösungen sowie der Notwendigkeit einer entsprechenden Ergänzung und / oder Anpassung an die spezifische Unternehmenssituation gesehen werden. Die Unternehmen verfolgen daher häufig eine ”Best-of-Breed”-Strategie. Es ist offensichtlich, dass mit einer Übertragung der Verantwortlichkeiten nicht zwangsläufig auch eine Konsolidierung der IT-Landschaft einhergeht (vgl. hierzu auch Martinez und Sorrentino, 2000, S. 25).

Problemstellung

3

In Wissenschaft und Praxis setzt sich daher zunehmend die Auffassung durch, dass die Zukunftsfähigkeit der Unternehmens-IT auf Dauer nur durch ein kontinuierliches und langfristig orientiertes Management auf Gesamtarchitekturebene gewährleistet werden kann. Zu diesem Zweck haben viele Organisationen innerhalb der letzten Jahre in den Auf- bzw. Ausbau einer Funktion IT-Architekturmanagement (AM) investiert (s. z. B. Penzel, 2004; Gaertner, 2004; Jung, 2004; Rajput, 2004; Spitzer, 2005; Koch, 2005; Walbaum, 2005; Murer, 2005; Longepe, 2007). In der Praxis werden für entsprechende Funktionen auch die Bezeichnungen IT-Architektur, Unternehmensarchitektur, Enterprise Architecture oder Enterprise Architecture Management (EAM) verwendet. Architekturmanagement ist eine vergleichsweise junge Disziplin, für die sich bis heute keine allgemein anerkannten Standards herausgebildet haben. In den Unternehmen existieren infolgedessen zum Teil sehr unterschiedliche Ansätze. Zur Charakterisierung von Architekturmanagement wird in der Literatur häufig die Metapher der Stadtplanung verwendet (z. B. Schulte, 1997; Sassoon, 1998; Longepe, 2003; Schönherr, 2004, S. 10; Walbaum, 2005; Schulte, 2002; Gaertner, 2004; Rajput, 2004; Niemann, 2005, S. 18).7 Die IT-Landschaft eines Unternehmens wird dabei mit einer realen Stadt in Analogie gesetzt. Die Aufgaben des Architekturmanagements können dann entsprechend in der Entwicklung von Rahmenplänen der Ist- und der Soll-Architektur (”Flächennutzungs- bzw. Bebauungspläne”), der Festlegung sowie Überwachung von Richtlinien und Standards für die Entwicklung neuer Anwendungen (”Bauaufsicht”) sowie in der Implementierung der übergreifenden Infrastruktur (”Flächenerschließung”) gesehen werden.

1.1 Problemstellung Zahlreiche Autoren und Organisationen haben die potentiellen Vorteile eines unternehmensweiten Architekturmanagements herausgestellt (u. a. Dern, 2003; Foegen, 2003; The Open Group, 2003; Schönherr, 2004; Hafner, 2005). In der Praxis ist die Implementierung einer entsprechenden Funktion aber auch mit einer Reihe von Problemen behaftet. So ist der Aufbau eines Architekturmanagements in der Regel zunächst mit zusätzlichen Kosten verbunden. Darüber hinaus können vielfältige Konflikte aufgrund von differierenden Stakeholder-Interessen entstehen. Gleichzeitig treten die positiven Wirkungen oft erst mit einer gewissen zeitlichen Verzögerung auf und sind überdies nur schwer zu quantifizieren. Das Architekturmanagement steht daher in der Praxis oft unter einem gewissen Legitimationsdruck.

7

Im romanischen Sprachraum ist daher auch die Bezeichnung Urbanisation gebräuchlich.

4

Einführung

Vor dem Hintergrund der beschriebenen Probleme besteht derzeit in vielen Unternehmen ein großes Interesse an einer Evaluierung existierender Konzepte des Architekturmanagements sowie an einer Identifikation relevanter Erfolgsfaktoren. Obwohl jedoch die Auseinandersetzung mit dem Themenbereich IT-Architektur bzw. IT-Architekturmanagement bereits mehr als 20 Jahre zurückreicht (z. B. Zachman, 1987; Richardson et al., 1990; Allen und Boynton, 1991; Sowa und Zachman, 1992; Krcmar, 1990; Strunz, 1990; Scheer, 1993a), hat eine wissenschaftliche Aufarbeitung erst in Ansätzen stattgefunden (z. B. Hafner und Winter, 2005; Lankes et al., 2005; Lankhorst, 2005; Aier und Schönherr, 2005; Tabbert, 2003). So existieren bis heute insbesondere kaum empirische Untersuchungen (vgl. Martin und Gregor, 2002, S. 11; Boh und Yellin, 2006, S. 2).8 Dies gilt sowohl im Hinblick auf die Verbreitung und Ausgestaltung von Architekturmanagement in der Praxis als auch in Bezug auf entsprechende Wirkungen und Erfolgsfaktoren.

1.2

Zielsetzung und Gang der Untersuchung

Mit der vorliegenden Arbeit soll ein Beitrag zur Schließung der beschriebenen Forschungslücke geleistet werden. Im Einzelnen werden dabei folgende Forschungsziele verfolgt: • wissenschaftliche Aufarbeitung und Systematisierung des Themengebietes Architekturmanagement • Erfahrungsaufnahme zum Status Quo des Architekturmanagements in der Praxis • empirische Analyse der Wirkungen von Architekturmanagement • Identifikation von Erfolgsfaktoren und Ableitung von Handlungsempfehlungen für die Praxis Die Adressierung der Forschungsziele erfolgt auf Basis eines empirischen Forschungsansatzes bestehend aus mehreren methodischen Bausteinen (vgl. Abbildung 1.1). Den Ausgangspunkt der Untersuchung bildet eine theoretische Betrachtung des Untersuchungsgegenstandes. Dies umfasst insbesondere eine Klärung der relevanten Fachbegriffe sowie die Entwicklung eines konzeptionellen Rahmens. Auf dieser Grundlage erfolgt anschließend eine mehrstufige empirische Analyse. Hinsichtlich der betrachteten Anwenderunternehmen findet dabei eine Konzentration auf die Finanzwirtschaft statt. Diese besitzt

8

Nach Heinrich und Lehner (2005, S. 58) könnte ein möglicher Grund hierfür darin liegen, dass der Untersuchungsgegenstand für die Forschung ”nur schwer zugänglich” ist.

Zielsetzung und Gang der Untersuchung

5

5. Deduktion von Handlungsempfehlungen

3. Fallstudien

4. Hauptstudie

2. Vorstudie

1. Theoretische Basis

Abbildung 1.1: Forschungsdesign

aufgrund der intensiven Nutzung und der hohen Abhängigkeit von Informationstechnologie ein besonderes Anwendungspotential für Architekturmanagement. Eine Branchenfokussierung bietet darüber hinaus den Vorteil einer größeren Homogenität der Kontextfaktoren. Die empirische Analyse umfasst insgesamt drei aufeinander aufbauende Teilstudien: • eine explorative Expertenbefragung mit 14 Architekturverantwortlichen aus der deutschsprachigen Kreditwirtschaft (Vorstudie), • eine vertiefende Fallstudienuntersuchung bei drei Unternehmen aus der europäischen Kreditwirtschaft (Fallstudien) sowie • eine quantitative Breitenstudie mit den 500 größten Finanzdienstleistern aus Europa, Nordamerika und Australien (Hauptstudie).

Aus den gewonnenen Erkenntnissen werden anschließend Handlungsempfehlungen für die Unternehmenspraxis abgeleitet.

6

1.3

Einführung

Abgrenzung

Untersuchungsgegenstand der vorliegenden Arbeit ist das Architekturmanagement als Teilfunktion des betrieblichen Informationsmanagements. Entsprechend der vorherrschenden Ausrichtung in den Unternehmen erfolgt dabei eine Konzentration auf die IT-Makroarchitektur (vgl. hierzu Kapitel 2). Im Rahmen der Arbeit werden in der Praxis bestehende AM-Implementierungen analysiert und evaluiert. Obwohl daraus im weiteren Verlauf konkrete Handlungsempfehlungen abgeleitet werden, ist die Entwicklung einer umfassenden Methodik für das Architekturmanagement nicht Gegenstand der Untersuchung (siehe hierzu Abschnitt 3.3). Nicht betrachtet wird ferner das Sourcing-Verhalten von Unternehmen. Es wird dabei davon ausgegangen, dass es sich beim Outsourcing (in seinen verschiedenen Spielarten) um ein komplementäres Konzept handelt.9

1.4

Überblick

Die Gliederung der Arbeit orientiert sich am Aufbau des zugrundeliegenden Forschungsdesigns (vgl. Abschnitt 1.2). In Kapitel 2 werden zunächst die grundlegenden Begriffe eingeführt. Darauf aufbauend wird in Kapitel 3 ein theoretischer Bezugsrahmen für das Architekturmanagement entwickelt. Anschließend werden die Ergebnisse der Vorstudie präsentiert (Kapitel 4). Es folgt die Beschreibung und Analyse der Fallstudien (Kapitel 5). In Kapitel 6 werden aus den bisherigen Ergebnissen zunächst Hypothesen über die Erfolgswirkungen einer AM-Implementierung abgeleitet. Daraufhin werden die Ergebnisse der Hauptstudie vorgestellt und diskutiert. Auf Basis der gewonnenen Erkenntnisse werden letztlich Handlungsempfehlungen für die betriebliche Praxis formuliert (Kapitel 7). Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick auf den zukünftigen Forschungsbedarf (Kapitel 8).

9

So kann zwar auch das Architekturmanagement theoretisch ausgelagert werden (z. B. im Rahmen eines FullService-Outsourcing-Abkommens). Hierdurch wird jedoch die Problematik der Architektursteuerung auf Unternehmensebene lediglich auf den entsprechenden Auftragnehmer übertragen.

Kapitel 2


Das Themengebiet IT-Architektur bzw. IT-Architekturmanagement ist traditionell durch eine gewisse begriffliche Unschärfe und Heterogenität gekennzeichnet (vgl. Wall, 1996, S. 26; Sinz, 2004, S. 315; Heinrich und Lehner, 2005, S. 51; Dern, 2003, S. 2). In diesem Kapitel erfolgt daher zunächst eine Klärung der verwendeten Grundbegriffe.

2.1 Systeme Der Architekturbegriff wird in der (Wirtschafts-) Informatik in der Regel auf Systeme und hier insbesondere auf Informationssysteme bezogen (z. B. IEEE Computer Society, 2000, S. 3; Sinz, 2004, S. 315; Sinz, 2002, S. 1055). Im Folgenden wird daher unter Rückgriff auf die Systemtheorie zunächst der allgemeine Systembegriff eingeführt. Im Anschluss hieran wird der Begriff des (Unternehmens-) Informationssystems definiert. 2.1.1 Allgemeiner Systembegriff Als interdisziplinäre Grundlagen-Wissenschaft stellt die Allgemeine Systemtheorie einen einheitlichen Beschreibungs- und Analyserahmen zur fächerübergreifenden Untersuchung komplexer Sachverhalte zur Verfügung. Im Mittelpunkt steht dabei der Begriff System. Hier-

8


unter wird allgemein eine verschiedene und untereinander in Beziehung stehende Teile umfassende Ganzheit verstanden. Der Systembegriff lässt sich auf unterschiedliche Sachgebiete anwenden. Typische Beispiele sind etwa das Immunsystem aus dem Bereich der Biologie, das Finanzsystem aus dem Bereich der Wirtschaftswissenschaften oder das Betriebssystem aus der Informatik. Grundgedanke der Systembetrachtung ist es, das Zusammenspiel der Einzelelemente ganzheitlich zu erfassen und zu analysieren. Hintergrund hierfür ist die Erkenntnis, dass die Eigenschaften von Ganzheiten sich aufgrund der bestehenden Wechselbeziehungen grundlegend von denen ihrer Einzelteile unterscheiden können (von Bertalanffy, 1972, S. 25).10 Nach Ropohl (1979, S. 54f.) umfasst der allgemeine Systembegriff insgesamt drei Aspekte (vgl. auch Abbildung 2.1): • das funktionale Systemkonzept • das strukturale Systemkonzept • das hierarchische Systemkonzept Unter funktionalen Gesichtspunkten handelt es sich bei einem System um einen beliebigen, abgrenzbaren Gegenstand des Denkens, der durch bestimmte Zusammenhänge (Funktionen) zwischen seinen äußeren Eigenschaften (Attribute) gekennzeichnet ist (Ropohl, 1979, S. 54). Typischerweise werden dabei Eingangsgrößen (Inputs), Ausgangsgrößen (Outputs) und interne Zustände unterschieden. Das funktionale Systemkonzept fokussiert entsprechend auf das Verhalten einer Ganzheit in ihrer Umgebung (Ropohl, 1979, S. 55). Das strukturale Systemkonzept stellt hingegen den strukturellen Aufbau des Systems in den Mittelpunkt der Betrachtung. Ein System besteht demnach aus Elementen und zwischen diesen bestehenden Beziehungen (Relationen). Dabei geht es um die Vielfalt der möglichen Beziehungsgeflechte und die daraus resultierenden Systemeigenschaften (vgl. Ropohl, 1979, S. 54). Das hierarchische Systemkonzept schließlich thematisiert den rekursiven Charakter von Systemen. Die Elemente eines Systems können demnach selbst als Systeme angesehen werden. Man spricht in diesem Zusammenhang von Subsystemen. Umgekehrt kann jedes System

10

Dies kommt auch im bekannten Kernsatz der Allgemeinen Systemtheorie ”Das Ganze ist mehr als die Summe seiner Teile” zum Ausdruck.

Systeme

9

I. Funktionales Systemkonzept

II. Strukturales Systemkonzept

Input

Element

III. Hierarchisches Systemkonzept

Subsystem

System

Zustand Output

Relation

Supersystem

Abbildung 2.1: Systemkonzepte nach Ropohl (1979, S. 55)

Teil eines umfassenderen Supersystems sein. Beim hierarchischen Systemkonzept steht also die Abgrenzung eines Systems gegenüber seiner Umwelt im Vordergrund (Schulz, 2002, S. 53). Zusammenfassend kann unter einem System eine von ihrer Umwelt bzw. einem Supersystem abgrenzbare Ganzheit verstanden werden, die über Attribute und auf diesen definierte Funktionen verfügt, und die aus mehreren – miteinander in Relation befindlichen – Elementen besteht, welche selbst Subsysteme sein können.11 Die zwischen den Systemelementen bzw. Subsystemen eines Systems definierten Relationen können unterschiedlicher Natur sein. Prinzipiell lassen sich hier zunächst aktive und inaktive Beziehungen unterscheiden (Fuchs, 1973, S. 45). Inaktive Beziehungen sind konzeptioneller Natur und beinhalten keinen Wirkungszusammenhang (z. B. geographische Lagebeziehung, logische Beziehungen). Aktive Beziehungen hingegen sind durch einen Austausch von Strömungsgrößen wie Energie, Materie oder Information gekennzeichnet (Fuchs, 1973, S. 45). In diesem Zusammenhang wird auch von funktionaler Kopplung von Systemelementen gesprochen. Formal handelt es hierbei um eine zweistellige Identitätsrelation zwischen einem Output-Attribut eines Systemelements A sowie einem Input-Attribut eines Systemelements B (Ropohl, 1979, S. 59).

11

Für eine formale Definition des Systembegriffes siehe z. B. Ropohl (1979, S. 57ff.).

10


(1) Reihenkopplung

(2) Rückkopplung

(3) Zentralisierung

(4) Dezentralisierung

Abbildung 2.2: Strukturtypen der Systemkopplung (in Anlehnung an Ropohl, 1979, S. 65)

Im Hinblick auf die Struktur der in einem System bestehenden Kopplungen können verschiedene Strukturtypen unterschieden werden. Häufige Strukturmuster sind etwa die Reihenkopplung, die Rückkopplung, die Zentralisierung sowie die Dezentralisierung (vgl. Abbildung 2.2). Systeme können weiterhin nach verschiedenen Kriterien klassifiziert werden. Im Folgenden werden kurz die wichtigsten Systemeigenschaften skizziert (vgl. hierzu Alpar et al., 2002, S. 28; Ropohl, 1979, S. 67ff.; Fuchs, 1973, S. 61f.). Eine grundlegende Einteilung von Systemen bezieht sich zunächst auf den ”Seinsbereich”. Diesbezüglich lassen sich abstrakte Systeme, welche sich auf rein gedankliche Sachverhalte beziehen (z. B. philosophische Systeme), und konkrete Systeme, welche sich auf reale Gegenstände der erfahrbaren Außenwelt beziehen (z. B. Softwaresysteme), unterscheiden. Nach der Entstehung von Systemen kann weiterhin zwischen natürlichen Systemen, welche sich ohne das Zutun des Menschen entwickelt haben (z. B. Immunsystem), und künstlichen, d. h. vom Menschen geschaffenen Systemen (z. B. Finanzsystem), differenziert werden. Eine andere Einteilung bezieht sich auf die Interaktion von Systemen mit ihrer Umwelt. In dieser Hinsicht werden offene Systeme, bei denen Beziehungen mit der Systemumwelt bestehen, und geschlossene Systeme, bei denen keine solchen Beziehungen existieren, unterschieden. Weiterhin wird von dynamischen Systemen gesprochen, wenn die Attributausprä-

Systeme

11

gungen zeitabhängig variieren können. Im anderen Fall handelt es sich entsprechend um statische Systeme. Auch die Struktur von Systemen kann sich im Zeitverlauf verändern. So können z. B. neue Subsysteme hinzukommen oder zusätzliche Beziehungen geknüpft werden. Systeme, deren Struktur veränderlich ist, können als strukturdynamisch oder flexibel bezeichnet werden (Ropohl, 1979, S. 71). Von besonderer Bedeutung für die Charakterisierung von Systemen sind schließlich die Begriffe Varietät und Komplexität. Beide Begriffe werden in der Literatur uneinheitlich definiert. Im Rahmen dieser Arbeit wird unter der Varietät eines Systems die Anzahl der verschiedenartigen Systemelemente verstanden (vgl. z. B. Fuchs, 1973, S. 46). Der Begriff Komplexität wird hingegen im Sinne der Anzahl unterscheidbarer Relationen verwendet. Nach diesem Begriffsverständnis wächst die maximal mögliche Komplexität mit der Varietät (vgl. Ropohl, 1979, S. 71). 2.1.2 System und Modell Streng genommen impliziert die Anwendung des Systemkonzeptes immer zugleich eine Modellbildung (Ropohl, 1979, S. 90). So können reale Sachverhalte oftmals in unterschiedlicher Weise als System interpretiert und beschrieben werden. Ein System ist daher von einem formalen Standpunkt aus gesehen stets nur ein Modell eines realen oder gedachten Sachverhaltes. Unter einem Modell kann dabei nach der Allgemeinen Modelltheorie eine vereinfachende (Verkürzungsmerkmal) Abbildung (Abbildungsmerkmal) eines Originals verstanden werden, die für einen bestimmten Betrachter, zu einem bestimmten Zeitpunkt und zu einem bestimmten Zweck vorgenommen wird (pragmatisches Merkmal) (Stachowiak, 1973, S. 131ff.). Im Kontext konkreter, künstlicher Systeme (wie sie im Rahmen der Wirtschaftsinformatik vorherrschen, vgl. Abschnitt 2.1.3) wird die Unterscheidung zwischen den Objekten der Seinsebene (z. B. Software-Programmen) und der abstrakten Modellvorstellung häufig verwischt. Aufgrund der bewussten Konstruktion besteht hier in der Regel auch eine enge Kongruenz zwischen den beiden Ebenen. In dieser Arbeit wird der Systembegriff daher – dem allgemeinen Sprachgebrauch folgend – auf die Gegenstände der Seinsebene bezogen (vgl. z. B. auch Ferstl und Sinz, 2001, S. 18f.). Auf der Modellebene wird dagegen explizit von Systemmodellen gesprochen. Systemmodelle können gemäß der oben genannten Definition in vielfältiger Weise zur Abbildung von Systemen verwendet werden. Dabei ist eine Beschreibung des Systems aus un-

12


terschiedlichen Sichten bzw. auf unterschiedlichen Abstraktionsebenen möglich. Diese Fähigkeit zur Komplexitätsreduktion macht Systemmodelle zu einem wichtigen Instrument bei der Steuerung und Regelung komplexer Systeme (vgl. Ferstl und Sinz, 2001, S. 27). 2.1.3

Betriebliche Informationssysteme

Informationssysteme sind spezielle Systeme zur Verarbeitung (d. h. Erfassung, Übertragung, Transformation, Speicherung sowie Bereitstellung) von Informationen (Ferstl und Sinz, 2001, S. 1). Die Wirkungsbeziehungen zwischen den Systemelementen basieren hier entsprechend auf dem Austausch von Informationen (vgl. Buxmann, 1996, S. 1). Die Wirtschaftsinformatik befasst sich primär mit Informationssystemen in Wirtschaft und Verwaltung (Wissenschaftliche Kommission Wirtschaftsinformatik, 1994, S. 80). Diese werden auch als betriebliche Informationssysteme bezeichnet. In struktureller Hinsicht werden betriebliche Informationssysteme meist als soziotechnische Systeme angesehen. So bestehen Informationssysteme nach Krcmar (2005, S. 25) aus menschlichen und maschinellen Elementen. Zum Teil wird darüber hinaus auch eine Aufgabenebene betrachtet (z. B. Ferstl und Sinz, 2001, S. 2; Heinrich, 2001, S. 16). Betriebliche Informationssysteme werden dann als Mensch/Aufgabe/Technik-Systeme verstanden (z. B. Heinrich, 2001, S. 15). Trotz seiner zentralen Bedeutung für die Wirtschaftsinformatik wird der Begriff des betrieblichen Informationssystems in der Literatur bisher unterschiedlich weit gefasst. Einerseits werden hierunter funktions- bzw. anwendungsbezogene Teilsysteme der betrieblichen Informationsverarbeitung verstanden (z. B. Scheer, 1988). So werden etwa Informationssysteme für den Vertrieb, die Beschaffung oder das Risikomanagement unterschieden.12 Nach einer anderen Auffassung handelt es sich bei einem betrieblichen Informationssystem dagegen um das gesamte informationsverarbeitende Teilsystem eines Unternehmens bzw. einer Organisation (z. B. Ferstl und Sinz, 2001, S. 2; Grochla, 1975; Bernus und Schmidt, 2006, S. 2).13 So umfasst das Informationssystem nach Ferstl und Sinz (2001, S. 2) sämtliche Informationsverarbeitungs-Aufgaben sowie die zu deren Bewältigung eingesetzten Aufgabenträger einer Organisation. Im Rahmen der vorliegenden Arbeit erfolgt eine Anlehnung an das Begriffssystem nach Ferstl und Sinz (2001, S. 2). Zur Vermeidung von Mehrdeutigkeiten wird dabei jedoch explizit zwischen Informationssystemen auf Mikroebene (funktions- bzw. anwendungsbezoge-

12 13

Gemäß dieser Sichtweise verfügt ein Unternehmen also in der Regel über mehrere Informationssysteme. Heinrich (2001, S. 178) verwendet hierfür den Begriff ”Informationsinfrastruktur”.

13

IVAufgabe 2

Informationsbeziehungen

IVAufgabe 3

IVAufgabe 4

IVAufgabe 5

Maschineller Aufgabenträger 1

Maschineller Aufgabenträger 2 Kommunikationsbeziehungen

Personeller Aufgabenträger 1

Personeller Aufgabenträger 2

Aufgabenträgerebene

IVAufgabe 1

Aufgabenebene

Systeme

Abbildung 2.3: Aufgabenebene und Aufgabenträgerebene des UIS (in Anlehnung an Ferstl und Sinz, 2001, S. 2)

ne Teilsysteme) und Informationssystemen auf Makroebene unterschieden. Für letztere wird die Bezeichnung Unternehmensinformationssystem (UIS) eingeführt. Das UIS wird dabei als Supersystem aller Informationssysteme eines Unternehmens auf Mikroebene angesehen. Nach Ferstl und Sinz (2001, S. 2) beinhaltet das UIS zunächst eine Menge von Informationsverarbeitungs-Aufgaben, welche durch Informationsbeziehungen miteinander in Verbindung stehen (vgl. Abbildung 2.3). Hierbei kann es sich einerseits um Lenkungsaufgaben (zur Planung, Steuerung und Kontrolle) und andererseits um Durchführungsaufgaben zur Erstellung von informationsbasierten Dienstleistungen (z. B. Finanzprodukte) handeln. Den Informationsverarbeitungs-Aufgaben sind weiterhin entsprechende Aufgabenträger zugeordnet. Dabei können menschliche (von Menschen besetzte Rollen, z. B. als Sachbearbeiter oder Manager) und maschinelle Komponenten unterschieden werden.14 Letztere wiederum werden als Anwendungssysteme (bestehend aus Anwendungssoftware, Systemsoftware sowie

14

Der Anteil der von maschinellen Aufgabenträgern wahrgenommenen Informationsverarbeitungs-Aufgaben entspricht dem Automatisierungsgrad des UIS.

14


Hardwarekomponenten) bezeichnet. Die unterschiedlichen Aufgabenträger stehen darüber hinaus über Kommunikationssysteme in Verbindung. Dabei kann zwischen einer Menschzu-Mensch (z. B. Telefon), einer Mensch-zu-Maschine (z. B. Terminal) sowie einer Maschine-zu-Maschine-Kommunikation (z. B. elektronische Datenschnittstelle) unterschieden werden. Unternehmensinformationssysteme sind konkrete Systeme, denn ihre Elemente (z. B. Hardwarekomponenten, Softwareprogramme) sind Teil der realen Objektwelt. Sie sind zugleich künstlich, da sie von Menschen im Rahmen von Entwicklungsprozessen mehr oder weniger bewusst gestaltet werden. Im Gegensatz zu vielen anderen technischen Systemen handelt es sich hierbei allerdings nicht um einen einmaligen Vorgang, sondern um einen kontinuierlichen Prozess. So erzwingt die große Umweltdynamik in der Regel eine ständige Anpassung des UIS im laufenden Betrieb (s. hierzu ausführlich Abschnitt 3.1.1). Unternehmensinformationssysteme sind entsprechend als strukturdynamische Systeme anzusehen. Unternehmensinformationssysteme sind ferner offene Systeme, die mit ihrer Umwelt interagieren. Sie sind überdies dynamisch, weil sich ihre Attribute im Zeitverlauf ändern. Als Supersysteme sämtlicher Anwendungs- und Kommunikationssysteme eines Unternehmens besitzen Unternehmensinformationssysteme weiterhin eine hohe Varietät und Komplexität. Dies gilt vor allem für Großunternehmen sowie Unternehmen aus informationsintensiven Branchen. Die Komplexität liegt hier in der Regel deutlich über der herkömmlicher technischer Systeme etwa aus dem Bereich des Maschinenbaus (z. B. Autos, Flugzeuge). Zusammenfassend lässt sich festhalten, dass Unternehmensinformationssysteme komplexe Supersysteme darstellen, die aus einer Vielzahl von Subsystemen bestehen, und die als solche besondere Eigenschaften aufweisen, welche sich von denen ihrer Subsysteme grundlegend unterscheiden können. Hieraus ergibt sich unmittelbar die Notwendigkeit einer ganzheitlichen Betrachtung und einer integrierten Steuerung des UIS auf Unternehmensebene.

2.2

Architekturen

Im Folgenden wird der Architekturbegriff eingeführt. Dazu werden ausgehend von den historischen Wurzeln zunächst die verschiedenen Begriffsdimensionen analysiert. Als nächstes wird die Rolle der Architektur bzw. des Architekten im Systementwicklungsprozess betrachtet. Anschließend wird ausführlich auf die Verwendung des Architekturbegriffes im Kontext von Informationssystemen eingegangen.

Architekturen

15

2.2.1 Allgemeiner Architekturbegriff Der Architekturbegriff setzt sich aus den beiden altgriechischen Wortbestandteilen αρχη (arché, ”Anfang”, ”Grundlage”) und τ χνη (techné, ”Handwerk”, ”Kunst”) zusammen. Er geht auf das Bauwesen zurück und lässt sich hier bis auf die Antike zurückverfolgen (s. Vitruvius Pollio, 2004). Heute wird der Begriff im übertragenen Sinne in unterschiedlichen Fachdomänen verwendet. Er hat dabei insbesondere in der (Wirtschafts-) Informatik eine weite Verbreitung gefunden. Beispiele hierfür sind die Bezeichnungen Rechnerarchitektur, Softwarearchitektur, IT-Architektur oder Unternehmensarchitektur, welche sowohl in der Wissenschaft als auch in der Praxis zunehmende Bedeutung erlangt haben. Architektur ist ein unscharfer bzw. mehrdimensionaler Begriff, der je nach Kontext mit unterschiedlichen Bedeutungen belegt wird (vgl. z. B. Krcmar, 1990, S. 396ff.). Dies gilt bereits für den klassischen Architekturbegriff aus dem Bauwesen. So wird unter der Architektur eines Gebäudes primär dessen grundlegende Struktur bzw. Bauweise verstanden. Diese äußert sich u. a. in der Raumaufteilung (z. B. Eingangsbereich, Wohnzimmer, Arbeitszimmer) oder in der Wahl bestimmter Materialien (z. B. Beton, Ziegel). Im übertragenen Sinne wird der Begriff darüber hinaus aber auch für ganze Bautypologien bzw. Baustile (z. B. einer Epoche) verwendet. So spricht man etwa von einer Jugendstil- oder Art-Deco-Architektur. Schließlich wird der Begriff auch für das Berufsfeld des Architekten sowie die diesem zugrundeliegende Wissenschaft gebraucht (vgl. z. B. Wissenschaftlicher Rat der Dudenredaktion, 1994, S. 134). 2.2.2

Systemtechnischer Architekturbegriff

Auch im Kontext der für die (Wirtschafts-) Informatik relevanten technischen bzw. soziotechnischen Systeme wird der Architekturbegriff sehr heterogen verwendet. Dabei lassen sich drei wesentliche Begriffsdimensionen unterscheiden: die ontologische, die deskriptive sowie die pragmatische Begriffsdimension. Die ontologische Begriffsdimension bezieht sich auf den betrachteten Gegenstand selbst. Architektur meint hier entsprechend die grundlegende Struktur eines (existierenden oder geplanten) Systems.15 Architektur wird also als eine Systemeigenschaft aufgefasst, die per se – d. h. unabhängig von expliziten Beschreibungen – existiert. Dies kommt u. a. im Begriff der Systemarchitektur zum Ausdruck, der mehrheitlich in diesem Sinne verwendet wird.

15

Struktur ist dabei in einem umfassenden systemtheoretischen Sinne zu verstehen und nicht auf statische Aspekte beschränkt.

16


architect: The person, team, or organization responsible for systems architecture. architecting: The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture. architectural description (AD): A collection of products to document an architecture. architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. system: A collection of components organized to accomplish a specific function or set of functions. system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. view: A representation of a whole system from the perspective of a related set of concerns. viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

Abbildung 2.4: Definitionen nach IEEE 1471–2000 (aus IEEE Computer Society, 2000, S. 3f.)

Die deskriptive Begriffsdimension bezieht sich stattdessen auf Modelle des betrachteten Gegenstandes. Architekturen werden hier im Sinne der Modelltheorie (vgl. Abschnitt 2.1.2) als zweckorientierte Abbildungen der grundlegenden Struktur eines (existierenden oder geplanten) Systems verstanden. So wird etwa der Begriff Datenarchitektur in der Praxis meist synonym für ein unternehmensweites (grobgranulares) Datenmodell verwendet. Teilweise werden auch die den verschiedenen Architekturmodellen zugrundeliegenden (und diese integrierenden) Ordnungsrahmen bzw. Metamodelle als Architekturen bezeichnet (z. B. Scheer, 2002). Die pragmatische Begriffsdimension schließlich bezieht sich auf den Prozess der Systementwicklung. Architektur meint hier die Prinzipien, Regeln und Handlungsanweisungen, welche die grundlegende Organisation eines Systems bestimmen bzw. welche dessen (Weiter-) Entwicklung leiten. Ein Beispiel für diese Begriffsverwendung ist das Prinzip der Serviceorientierung, welches häufig als ”Service-Orientierte-Architektur” bezeichnet wird. Die in der Literatur gebräuchlichen Architektur-Definitionen lassen sich weitgehend auf eine oder mehrere der drei dargestellten Begriffsdimensionen zurückführen. Ein wichtiger Vertreter des ontologischen Architekturbegriffes ist etwa der IEEE Standard 1471–2000 zur

Architekturen

17

Beschreibung Software-intensiver Systeme (”Recommended Practice for Architectural Description of Software-Intensive Systems”).16 Architektur wird hier definiert als ”the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” (siehe Abbildung 2.4). Der Standard unterscheidet dabei explizit zwischen der Architektur selbst, welche als konzeptionell angesehen wird (”every system has an architecture”), und entsprechenden Architekturbeschreibungen (”Architectural Descriptions”), worunter sämtliche Artefakte zur Beschreibung einer Architektur verstanden werden (IEEE Computer Society, 2000, S. 4, siehe auch Abbildung 2.5). Eine ähnliche Sicht findet sich auch bei Maier und Rechtin. Diese definieren Architektur als ”the structure – in terms of components, connections, and constraints – of a product, process or element” (Maier und Rechtin, 2002, S. 293). Schulz (2002, S. 57) betont demgegenüber den artifiziellen, ordnenden Charakter. Architektur wird hier entsprechend als die einem System ”künstlich aufgeprägte Struktur” verstanden. Zachman kann als klassischer Vertreter eines deskriptiven Architekturbegriffes angesehen werden. Architektur wird hier definiert als ”[...] that set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change)” (Zachman, 1997, S. 5). Ähnliche Begriffsauffassungen finden sich z. B. bei Hafner (2005, S. 31) und Niemann (2005, S. 3). Sinz erweitert diese rein deskriptive Sicht um die pragmatische Dimension und definiert die Architektur eines Systems als ”dessen Bauplan in Form einer Beschreibung seiner Komponenten und ihrer Beziehungen unter allen relevanten Blickwinkeln sowie die dem Bauplan zugrundeliegenden Konstruktionsprinzipien” (Sinz, 2004, S. 315; Sinz, 2002, S. 1055). In ähnlicher Weise versteht Foegen unter einer Architektur ”die Dinge [...], welche die (Grund-) Struktur eines Systems definieren”, wobei unter ”Dingen” sowohl Modelle als auch Modellierungs- und Gestaltungsregeln zusammengefasst werden (Foegen, 2003, S. 57f.). Ein primär pragmatisches Begriffsverständnis schließlich findet sich u. a. bei Ross (2003, S. 32) und Boh et al. (2003, S. 172). Um Mehrdeutigkeiten zu vermeiden, wird der Architekturbegriff in der vorliegenden Arbeit stets im ontologischen Sinne verwendet. Dabei erfolgt eine Orientierung am IEEE Standard 1471–2000. Architektur wird entsprechend auf konzeptioneller Ebene verstanden als die grundlegende Organisation eines Systems. Hiervon werden Architektur-Artefakte als In-

16

Je nach Lesart kann die Position des IEEE 1471–2000 auch als gemischt ontologisch-pragmatisch interpretiert werden.

18


Mission fulfils 1..*

Environment

influences inhabits

has an

System

identifies 1..*

is addressed to 1..*

participates in selects 1..*

Concern

used to cover 1..*

provides

Architectural Description

Stakeholder

has 1..*

Rationale

described by 1

has 1..* is important to 1..*

Architecture

organized by 1..*

Viewpoint

participates in 1..*

View conforms to

identifies 1..*

has source 0..1

Library Viewpoint

establishes methods for 1..*

consists of 1..*

Model aggregates 1..*

Abbildung 2.5: Konzeptuelles Modell des IEEE 1471–2000 Standards (in Anlehnung an IEEE Computer Society, 2000, S. 5)

strumente zur Beschreibung und Steuerung von Architekturen bzw. Systemen unterschieden. Diese können weiter in deskriptive Artefakte (z. B. Architekturmodelle) sowie pragmatische Artefakte (z. B. Architekturprinzipien) unterteilt werden. Ordnungsrahmen zur Strukturierung von Architektur-Artefakten werden überdies als Architektur-Frameworks bezeichnet. 2.2.3

Architektur im Systementwicklungsprozess

Entwurf und Konstruktion technischer bzw. soziotechnischer Systeme sind Gegenstand der verschiedenen Ingenieurwissenschaften (z. B. Maschinenbau, Angewandte Informatik) sowie der ingenieurwissenschaftlichen Ausrichtungen innerhalb der Betriebswirtschaftslehre (”Wirtschaftstechnologie”, vgl. Chmielewicz, 1994). Darüber hinaus hat sich mit dem Systems Engineering eine interdisziplinäre Lehre für die Entwicklung komplexer Systeme etabliert (z. B. Daenzer und Huber, 1994, S. XVIII; Maier und Rechtin, 2002, S. 249f.).

Architekturen

19

In den genannten Fachrichtungen wurden im Laufe der Jahre unterschiedliche Methoden und Vorgehensmodelle für den Entwurf und die Implementierung von Systemen entwickelt. Der Entwicklungsprozess wird dabei in der Regel in verschiedene mehr oder weniger abgegrenzte Phasen mit unterschiedlichen inhaltlichen Schwerpunkten unterteilt. Neben den klassischen linearen Vorgehensmodellen (z. B. Wasserfallmodell nach Royce, 1970) haben vor allem im Bereich des Software Engineering auch iterative und evolutionäre Ansätze eine weite Verbreitung gefunden (z. B. Boehm, 1988; Kruchten, 2000). Unabhängig vom konkreten Vorgehensmodell setzt sich in der Praxis zunehmend eine architekturzentrierte Systementwicklung durch (vgl. Maier und Rechtin, 2002, S. 251f.). Ausgangspunkt hierfür ist die Erkenntnis, dass durch die Festlegung der Systemarchitektur in der Regel alle wesentlichen Eigenschaften eines Systems determiniert werden. So muss die Architektur insbesondere die Erfüllung sämtlicher funktionalen und nicht-funktionalen Anforderungen17 gewährleisten. Hinzu kommt, dass die Systemarchitektur bereits in den frühen Phasen der Systementwicklung angelegt wird und eine nachträgliche Veränderung nur mit großem Aufwand möglich ist. Im Hinblick auf den Erfolg der Systementwicklung kommt der Architekturgestaltung deshalb eine entscheidende Rolle zu. Um der besonderen Bedeutung der Architektur-Entwicklung Rechnung zu tragen, findet in der Praxis zunehmend eine Arbeitsteilung in Analogie zum Bauwesen statt. In diesem Zusammenhang hat sich eine eigene Fachdisziplin, das sogenannte Systems Architecting herausgebildet (vgl. Maier und Rechtin, 2002, S. 8). Der Systemarchitekt ist danach für eine ganzheitliche Betrachtung und Gestaltung des zu entwickelnden Systems verantwortlich. Seine Hauptaufgaben werden in der Interaktion mit den verschiedenen Anspruchsgruppen (Stakeholdern) zur Ermittlung der Systemanforderungen, der Festlegung bzw. Fortschreibung der Systemarchitektur, der Koordination bei der Systemimplementierung sowie der Zertifizierung der implementierten Lösung gesehen (vgl. Maier und Rechtin, 2002, S. 20). Der Architekt ist dabei zwischen Auftraggeber (Kunde) und Auftragnehmer (Implementierung) angesiedelt. Primäre Arbeitsergebnisse des Architekten sind Representationen (Modelle) der Architektur, die vor der Implementierung vom Auftragnehmer weiter detailliert werden müssen (Maier und Rechtin, 2002, S. 18). Obwohl der Schwerpunkt der Tätigkeit in der konzeptionellen Phase der Systementwicklung liegt, begleitet der Architekt den vollständigen Entwicklungszyklus (vgl. IEEE Computer Society, 2000, S. 6; Maier und Rechtin, 2002, S. 23). Er greift dabei jeweils nur soweit in die Details der Implementierung ein, als diese für die Gesamtlösung aus Kunden- bzw. Stakeholdersicht von Bedeutung sind.

17

Zu den unterschiedlichen Formen von Anforderungen siehe z. B. Robertson und Robertson (2006).

20


2.2.4

Architektur von Informationssystemen

Die Anwendung des Architekturbegriffes auf (Unternehmens-) Informationssysteme wird bereits seit den 1980er Jahren diskutiert (z. B. Zachman, 1987). Aufgrund der heterogenen Begriffsverwendung in beiden Domänen konnte sich jedoch auch hier bisher keine einheitliche Terminologie durchsetzen. Nach dem Umfang des zugrundegelegten Informationssystem-Begriffes lassen sich zwei wesentliche Betrachtungsebenen unterscheiden: die Ebene der Mikroarchitektur (”Architektur im Kleinen”) und die Ebene der Makroarchitektur (”Architektur im Großen”) (vgl. hierzu auch Gaertner, 2004, S. 311). 2.2.4.1

IT-Mikroarchitektur

Auf der Ebene der Mikroarchitektur wird die Architektur von einzelnen Informations- bzw. Anwendungssystemen betrachtet. Im Mittelpunkt steht hierbei die Software-Architektur. Darunter wird meist die grundlegende Struktur eines Software-Systems im Sinne seiner wesentlichen Komponenten und Schnittstellen sowie der grundlegenden Ablauflogik verstanden (vgl. Maier und Rechtin, 2002, S. 91). Im Software-Engineering wurden innerhalb der letzten Jahre zahlreiche Methoden entwickelt, welche eine architekturzentrierte Entwicklung unterstützen. Hierzu gehören multi-perspektivische Modellierungsframeworks (z. B. Kruchten, 1995), spezielle Architekturbeschreibungssprachen (Architecture Description Languages, ADL) (z. B. Medvidovic und Taylor, 2000; Medvidovic et al., 2002) oder Entwicklungskonzepte wie die Model-Driven-Architecture (MDA) (Miller und Mukerji, 2003). Darüber hinaus wurde mit der Übertragung des Architektur-Muster-Konzeptes aus dem Bauwesen, d. h. der Identifikation, Klassifikation und Dokumentation bewährter Lösungsmuster (”Patterns”) ein wesentlicher Schritt hin zu einer Professionalisierung der Architektur-Entwicklung geleistet (vgl. Alexander, 1977; Gamma et al., 1995). Parallel hierzu hat sich mit der zunehmenden Komplexität der Entwicklungsvorhaben in der Praxis – analog zu den verwandten Ingenieursdisziplinen – das Berufsbild des IT-Architekten auf Projekt- bzw. Mikroebene etabliert (vgl. Rajput, 2004; Dern, 2003, S. 31).18 Dieser IT-Mikroarchitekt nimmt in der Regel eine Mittlerfunktion zwischen den (meist durch Business Analysten bzw. IT-Koordinatoren repräsentierten) Auftraggebern auf der einen und den für die Implementierung zuständigen Auftragnehmern (IT-Abteilung, externe Dienstleister) auf der anderen Seite ein. Seine Hauptaufgabe wird in der Transformation der funktiona-

18

Andere übliche Bezeichnungen hierfür sind Solution Architect oder Application Architect.

Architekturen

21

len und nicht-funktionalen Systemanforderungen in entsprechende Architekturbeschreibungen des zu entwickelnden Systems gesehen (vgl. Rajput, 2004). Besonderes Augenmerk liegt dabei in der Regel auf der Gestaltung der Schnittstellen gegenüber bestehenden Systemen. Der IT-Mikroarchitekt hat sich hierzu u. a. an den Vorgaben der Makroarchitektur (s. Abschnitt 2.2.4.2) zu orientieren. Seine relative Bedeutung ist nicht zuletzt deshalb gewachsen, weil Anwendungssysteme immer weniger von Grund auf neu entwickelt werden, sondern zunehmend aus vorgefertigten Komponenten (Standardsoftware, Common-of-theShelf-Tools, etc.) zusammengesetzt und in bestehende IT-Landschaften integriert werden müssen (Maier und Rechtin, 2002, S. 90). 2.2.4.2

IT-Makroarchitektur

Im Gegensatz zur Mikroarchitektur, welche sich auf einzelne Informations- bzw. Anwendungssysteme bezieht, erfolgt auf der Makroebene eine ganzheitliche Betrachtung des Unternehmensinformationssystems. Innerhalb der Literatur lassen sich dabei zwei Hauptströmungen unterscheiden. Bei der ersten Strömung wird der Modellierungsaspekt in der Vordergrund gestellt.19 In diesen Bereich fallen insbesondere die zahlreichen Ansätze zur Unternehmens- bzw. Unternehmensinformationssystem-Modellierung wie: • das Framework for Information Systems Architecture nach Zachman (1987) • die Ganzheitliche Informationssystem-Architektur nach Krcmar (1990) • die Architektur integrierter Informationssysteme (ARIS) nach Scheer (1991) • das Semantische Objektmodell (SOM) nach Ferstl und Sinz (1995) • das Business Engineering nach Österle (1995) • die Multiperspektivische Unternehmensmodellierung (MEMO) nach Frank (2002) Ziel dieser Ansätze ist eine ganzheitliche Abbildung des Unternehmens bzw. des Unternehmensinformationssystems in Form integrierter Modelle. Hierzu werden in der Regel unterschiedliche Modellierungsebenen und / oder Sichten definiert. So umfasst etwa das Zach-

19

Hier wird also primär die deskriptive Dimension des Architekturbegriffes angesprochen (vgl. Abschnitt 2.2.1).

22


WHAT? DATA

HOW? FUNCTION

WHERE? NETWORK

WHO? PEOPLE

WHEN? TIME

WHY? MOTIVATION

PLANNER SCOPE

OWNER ENTERPRISE MODEL DESIGNER SYSTEM MODEL BUILDER TECHNOLOGY MODEL SUBCONTRACTOR COMPONENTS

Abbildung 2.6: Zachman-Framework (in Anlehnung an Sowa und Zachman, 1992, S. 600)

man-Framework20 fünf Ebenen für die unterschiedlichen Perspektiven der am Entwicklungsprozess beteiligten Parteien (Planner, Owner, Designer, Builder, Subcontractor) sowie sechs Sichten für die unterschiedlichen logischen Betrachtungswinkel (entsprechend den Fragewörtern Was? Wie? Wo? Wer? Wann? Warum?). In der Kombination entstehen hieraus insgesamt 30 Zellen, welche zur Strukturierung entsprechender Architektur-Modelle eingesetzt werden können (s. Abbildung 2.6). Während das Zachman-Framework lediglich eine Modell-Taxonomie darstellt, beinhalten andere Ansätze auch entsprechende Modellierungssprachen. So stehen etwa bei ARIS Ereignisgesteuerte Prozessketten (EPK) im Mittelpunkt. Bei den meisten Ansätzen werden zudem über ein gemeinsames Metamodell Verknüpfungen zwischen den verschiedenen Sprachen bzw. Sichten hergestellt. Inhaltlich betonen die Ansätze zur Unternehmensmodellierung häufig den Aspekt einer zielkonformen Ausrichtung bzw. Abstimmung zwischen Geschäftsstrategie und IT (BusinessIT-Alignment). Hierzu werden insbesondere Beziehungen zwischen der Geschäftsstrategie, den Geschäftsprozessen sowie den zu deren Unterstützung benötigten Anwendungssystemen hergestellt (z. B. Business Engineering, MEMO).

20

In der erweiterten Version nach Sowa und Zachman (1992).

Architekturen

23

Der generellen Ausrichtung dieser Strömung entsprechend, werden Informationssystembzw. Unternehmensarchitekturen vorwiegend als strukturierte Sammlung von Plänen bzw. Modellen aufgefasst. So versteht etwa Krcmar unter einer Informationssystemarchitektur einen ”Rahmenplan, der Beziehungen aller Informationssysteme zueinander unternehmensweit verdeutlicht” (Krcmar, 1990, S. 395). Ähnliche Definitionen finden sich bei Zachman (1997, S. 5) und Sinz (2004, S. 315). Scheer bezieht den InformationssystemarchitekturBegriff stattdessen auf die Metaebene. Nach seiner Auffassung ist eine InformationssystemArchitektur ein ”Regelwerk zur ganzheitlichen Beschreibung von Informationssystemen” (Scheer, 1993a, S. 83). Die zweite Strömung fokussiert stärker auf Aspekte der Interoperabilität und Standardisierung. Gemäß dieser Sichtweise werden Informationssystemarchitekturen als Rahmenwerke innerbetrieblicher Richtlinien und Standards für den IT-Einsatz aufgefasst.21 So definiert etwa Ross den Begriff Enterprise IT Architecture als ”the organizing logic for applications, data, and infrastructure technologies, as captured in a set of policies and technical choices, intended to enable the firm’s business strategy” (Ross, 2003, S. 32). Ähnliche Positionen werden von (Boh et al., 2003; Boh und Yellin, 2006) vertreten. In der Praxis werden oft Elemente beider Strömungen kombiniert (vgl. hierzu Kapitel 4). Ein wichtiger Impulsgeber für die Auseinandersetzung mit der Makroarchitektur war dabei der sogenannte Clinger-Cohen-Act aus dem Jahre 1996. In diesem – ursprünglich als ”Information Technology Management Reform Act” – bezeichneten US-Bundesgesetz wird von allen Regierungsbehörden (”executive agencies”)22 explizit gefordert, eine ”Information Technology Architecture” zu entwickeln, zu pflegen und umzusetzen (Clinger-Cohen-Act, 1996, SEC.5125.(b)(2)).23 Der Begriff ”Information Technology Architecture” wird dabei jedoch recht vage definiert als ”an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency’s strategic goals and information resources management goals.” (Clinger-Cohen-Act, 1996, SEC.5125.(d)). Als Bezeichnung für die Architektur auf Makroebene setzt sich in der Praxis – analog zu Begriffen wie IT-Strategie oder IT-Controlling – zunehmend die Kurzform IT-Architektur (englisch: IT Architecture) durch (s. auch Heinrich und Lehner, 2005, S. 49).24 Oft wird

21 22 23 24

Es wird hier also die pragmatische Dimension des Architekturbegriffes in den Vordergrund gestellt. Hierzu gehört insbesondere auch das Verteidigungsministerium (Department of Defense, DoD). Hierfür wird der jeweilige CIO persönlich verantwortlich gemacht. Zum Teil werden hiermit aber auch Mikroarchitekturen bezeichnet (z. B. Dern, 2003).

24


stattdessen auch der Begriff Unternehmensarchitektur (englisch: Enterprise Architecture) gebraucht, um die unternehmensweite Sichtweise zu betonen.25 Zur Vermeidung von Mehrdeutigkeiten wird die Architektur des Unternehmensinformationssystems im Folgenden als IT-Makroarchitektur bezeichnet. Für Aufgaben, die im Zusammenhang mit der IT-Makroarchitektur stehen, hat sich – analog zum IT-Architekten auf Projektebene – das Berufsbild des IT-Architekten auf Unternehmens- bzw. Makroebene herausgebildet. Da es sich hierbei jedoch um eine sehr komplexe und zudem dauerhafte Aufgabe handelt, erfolgt in größeren Unternehmen heute meist eine Institutionalisierung in Gestalt einer zentralen Funktion IT-Architekturmanagement. Dies ist Gegenstand des nächsten Kapitels.

25

Meist wird dieser Begriff jedoch weiter gefasst im Sinne von ”Architektur des gesamten Unternehmens”.

Kapitel 3


Viele Unternehmen haben in den letzten Jahren erkannt, dass eine unkontrollierte Evolution des Unternehmensinformationssystems erhebliche Risiken birgt und mittel- bis langfristig zu schwerwiegenden Wettbewerbsnachteilen führen kann. In der Praxis setzt sich daher zunehmend die Auffassung durch, dass zur Erhaltung der Zukunftsfähigkeit und zur Sicherung der Investitionen in die Unternehmens-IT eine übergreifende und langfristig orientierte Steuerung auf der Ebene der Makroarchitektur unumgänglich ist. Ausgangspunkt hierfür ist die Erkenntnis, dass das UIS als Supersystem der einzelnen Informationssysteme eines Unternehmens über spezielle – von den Subsystemen losgelöste – Eigenschaften verfügt, welche durch die Entwicklungsprozesse auf Mikroebene in der Regel nicht in hinreichender Weise berücksichtigt werden (vgl. Abschnitt 2.1.3). Aufgrund der Dauerhaftigkeit des UIS und der bestehenden Umweltdynamik ist eine Architektursteuerung auf Makroebene als kontinuierlicher und fortwährender Prozess anzusehen (vgl. z. B. Foegen, 2003, S. 62f.). Während entsprechende Aufgaben in der Vergangenheit wenn überhaupt oft nur sporadisch und informell wahrgenommen wurden, findet seit einigen Jahren eine zunehmende Institutionalisierung statt (vgl. z. B. Dern, 2003, S. 103ff.; Foegen, 2003, S. 62f.; Schönherr, 2004, S. 10; Murer, 2005, S. 46). Tätigkeiten, die im Zusammenhang mit der Steuerung der IT-Makroarchitektur stehen, werden dazu meist in einer

26


eigenen Funktion konzentriert. Hierfür hat sich im deutschsprachigen Raum die Bezeichnung IT-Architekturmanagement oder kurz Architekturmanagement (englisch: Enterprise IT Architecture Management bzw. Enterprise Architecture Management, EAM) durchgesetzt.26 Architekturmanagement ist eine vergleichsweise junge Disziplin, die sich aus der Praxis heraus entwickelt hat. Eine umfassende theoretische Fundierung liegt daher bisher nicht vor.27 Das gleiche gilt für eine Einordnung in bestehende Ansätze des Informationsmanagements. In diesem Kapitel wird daher zunächst ein theoretischer Bezugsrahmen für das Architekturmanagement entwickelt. Dazu wird als Erstes eine Analyse der Ausgangssituation durchgeführt. Auf dieser Grundlage wird dann ein konzeptioneller Rahmen erarbeitet. Anschließend werden einige bestehende Ansätze für das Management der IT-Makroarchitektur vorgestellt.

3.1

Rahmenbedingungen

In diesem Abschnitt werden die Rahmenbedingungen für ein Management der IT-Makroarchitektur analysiert. Unter Bezugnahme auf die Stakeholder-Theorie und das Forschungsgebiet der Software-Evolution (Program Evolution Dynamics) wird dabei aufgezeigt, dass sich das Unternehmensinformationssystem ohne besonderen regulatorischen Eingriff in einem multipolaren Evolutionsprozess befindet, welcher zu einem unkontrollierten Komplexitätswachstum führen kann. Dies wird anschließend anhand der Entwicklung in der Finanzindustrie illustriert. 3.1.1

Evolution des Unternehmensinformationssystems

Ausgangspunkt der theoretischen Überlegungen ist ein Verständnis des Unternehmensinformationssystems als komplexes, offenes und (struktur-) dynamisches System (vgl. Abschnitt 2.1.3). Als wichtiges Subsystem und zentrale, gemeinschaftliche Ressource eines Unternehmens steht das UIS im Spannungsfeld unterschiedlicher Interessen. Einen geeigneten theoretischen Rahmen zur Beschreibung und Analyse dieses Spannungsfeldes bildet das sogenannte Stakeholder-Konzept. Dieses wurde im Bereich des strategischen Managements entwickelt, um das komplexe Beziehungsgeflecht zwischen Unternehmen und ihrer Umwelt ganzheitlich zu beschreiben und zu analysieren. Nach der Stakeholder-Theorie verfügt jede Organisation über eine Menge von Anspruchsgruppen, sogenannte

26 27

Zum Teil wird in diesem Zusammenhang auch von einem ”Architekturmanagement-Prozess” gesprochen. Als ein erster Ansatz in diese Richtung kann die Arbeit von Hafner (2005) angesehen werden.

Rahmenbedingungen

27

Stakeholder. Der Stakeholder-Begriff wird dabei in der Literatur unterschiedlich weit gefasst.28 Nach der ursprünglichen Definition von Freeman werden hierunter alle Individuen oder Gruppen verstanden, welche die Aktivitäten einer Organisation beeinflussen oder welche von diesen betroffen sein können (Freeman, 1984, S. 46). Dabei lassen sich organisationsinterne und organisationsexterne Anspruchsgruppen unterscheiden. Nach der Stakeholder-Theorie sind alle Stakeholder einer Organisation bestrebt, ihre jeweiligen Interessen zu wahren bzw. ihre individuellen Vorteile zu suchen. Eine Kernaussage der Theorie besagt weiterhin, dass es zwischen den verschiedenen (und oft gegenläufigen) Interessen keine selbstverständliche (naturgegebene) Rangfolge gibt, sondern dass die Stakeholder-Interessen situativ ausbalanciert werden müssen (vgl. Donaldson und Preston, 1995, S. 68). Dies wird als eine wesentliche Aufgabe des Managements angesehen. Das Stakeholder-Konzept wurde später auf andere Domänen übertragen. Es hat insbesondere auch im Bereich der (Wirtschafts-) Informatik bzw. dem Information Systems große Verbreitung gefunden (Pouloudi, 1999, S. 7). Das Konzept wird hier vor allem bei der Entwicklung von Informationssystemen auf Mikroebene eingesetzt. Als Stakeholder werden dabei entsprechend die an der Entwicklung und Nutzung von Informationssystemen beteiligten Gruppen angesehen. Im Folgenden wird das Stakeholder-Konzept auf das Unternehmensinformationssystem angewendet.29 Der Begriff Stakeholder kann hier in Anlehnung an Pouloudi (1999, S. 7) und Freeman (1984, S. 46) definiert werden als die Menge aller Individuen oder Gruppen, welche einen Einfluss auf die Gestaltung des Unternehmensinformationssystems ausüben können und / oder welche hiervon potentiell betroffen sind. Eine mögliche Einteilung der relevanten Stakeholdergruppen zeigt Abbildung 3.1. Dabei wird zwischen externen und internen Stakeholdern differenziert.30 Zu den wichtigsten externen Stakeholdern eines Unternehmens und damit auch des Unternehmensinformationssystems gehören Investoren (Eigentümer, Fremdkapitalgeber), Kunden, Wettbewerber, Gesetzgeber sowie Lieferanten und Partner. Eine besondere Rolle innerhalb der Zulieferer nehmen IT-/ Softwarehersteller und IT-Service-Provider ein. Der Einfluss externer Stakeholder auf das UIS ist in der Regel indirekter Natur und wird über entsprechende interne Stakeholder mediiert. Aufgrund der zunehmenden Automatisierung von

28 29 30

Eine gute Übersicht der verschiedenen Definitionsansätze findet sich in Mitchell et al. (1997, S. 858). Vgl. auch Hafner (2005, S. 20f.). Abgrenzung und Detaillierungsgrad der betrachteten Stakeholdergruppen sind letztlich immer willkürlich und daher in Abhängigkeit von der betrachteten Problemstellung zu wählen (vgl. Pouloudi, 1999, S. 2).

28


Investoren

Wettbewerber

Kunden

Lieferanten / Partner

En

tw ITick lun g

ITAnbieter

UIS

ittsschn Quer tionen funk

Ges ch bere äftsiche

TopManagement

IT- eb tri Be

Gesetzgeber

IT-ServiceProvider

Abbildung 3.1: Stakeholder des Unternehmensinformationssystems

Geschäftsprozessen über Unternehmensgrenzen hinweg ergibt sich aber mehr und mehr auch eine direkte Beziehung (z. B. beim Online-Banking oder zwischen Vertriebs- und Abwicklungsbanken). Typische organisationsinterne Stakeholder sind zunächst die verschiedenen Geschäftsbereiche eines Unternehmens (z. B. Corporate Finance, Global Markets, Asset Management). Dabei kann jeweils zwischen den verantwortlichen Führungskräften auf der einen und den eigentlichen Endanwendern auf der anderen Seite unterschieden werden. Während das Geschäftsbereichsmanagement in der Regel das Ziel der lokalen Umsatz- bzw. Ergebnisoptimierung verfolgt, berühren die Interessen der Endanwender auch Aspekte wie Benutzerfreundlichkeit und Ergonomie. Ähnlich stellt sich die Situation in entsprechenden Querschnittsfunktionen wie z. B. der Rechtsabteilung oder dem Rechnungswesen dar. Als weiterer wichtiger Stakeholder kann das Top-Management (Vorstand, Executive Board) angesehen werden. Aus Top-Management-Perspektive sind häufig die Kosteneffizienz sowie die

Rahmenbedingungen

29

Flexibilität des Unternehmensinformationssystems gegenüber strategischen Entscheidungen von besonderer Bedeutung. Hinzu kommen schließlich die für (Weiter-) Entwicklung und Betrieb der Systemkomponenten zuständigen IT-Abteilungen. Deren Interessen richten sich unter anderem auf eine gute Wartbarkeit und einen problemlosen Betrieb. Die Interessen und Anforderungen der verschiedenen Stakeholder des UIS sind nicht konstant, sondern können sich im Zeitablauf verändern (Pouloudi, 1999, S. 12; Mitchell et al., 1997, S. 868). Hieraus erwachsen in der Praxis stetig neue Impulse für eine Anpassung des UIS. Das UIS steht somit unter einem kontinuierlichen Änderungsdruck. Primäre Impulsgeber sind in der Regel die externen Anspruchsgruppen. So unterliegen etwa die Produktanforderungen der Kunden in dynamischen Märkten starken Veränderungen. Die Auswirkungen auf das UIS können dabei vor allem in informationsintensiven Branchen erheblich sein.31 Ähnliches gilt für die Anforderungen von Zulieferern bzw. Geschäftspartnern.32 Von großer Bedeutung ist weiterhin die aufsichtsrechtliche Regulation auf nationaler und internationaler Ebene. Speziell für Kreditinstitute sind hieraus in den vergangenen Jahren permanent neue Änderungsimpulse erwachsen.33 Auch Investoren können wesentliche Veränderungen am UIS auslösen – etwa durch Forderungen nach einer strategischen Neupositionierung in Form von Fusionen, Übernahmen oder Abspaltungen. Von der Angebotsseite schließlich erwachsen mit dem technologischen Fortschritt immer neue Möglichkeiten für einen Technologieeinsatz.34 Aktuelle Beispiele hierfür bilden etwa Web Services oder Grid-Computing. Außerdem bieten sich mit der zunehmenden Industrialisierung der IT-Wirtschaft neue Optionen für einen Fremdbezug von IT-Komponenten, Anwendungen und entsprechenden Dienstleistungen. Dies hat in der Vergangenheit zu einer stetigen Verringerung der Fertigungstiefe bei den Anwenderunternehmen geführt.

31

32 33

34

Ein typisches Beispiel aus dem Bankgeschäft stellen die Kapitalmarkt-Innovationen der letzten Jahre wie z. B. Kreditderivate und strukturierte Produkte dar. Um in diese Märkte eintreten zu können, mussten die betreffenden Institute zunächst die entsprechenden Produkte (z. B. Credit Default Swaps, Credit Linked Notes) in ihren Informationssystemen abbilden. Entsprechende Änderungen betrafen dabei nicht nur die Vertriebs-, Bestandsführungs- und Abwicklungssysteme, sondern auch den Bereich des Risikomanagements sowie des internen und externen Rechnungswesens. Mit der fortschreitenden Industrialisierung wird dieser Faktor in Zukunft auch für die Finanzwirtschaft an Bedeutung gewinnen (vgl. hierzu Sokolovsky und Löschenkohl, 2005). Als aktuelle Beispiele seien nur die Eigenkapitalvorschriften des Baseler Ausschusses für Bankenaufsicht (Basel II) oder die Richtlinien über Märkte für Finanzinstrumente der EU (MiFID) genannt. Studienergebnissen zufolge erwarteten fast die Hälfte der 60 größten Finanzinstitutionen in Nordamerika und Europa bis Ende 2007 Gesamtkosten für die Erfüllung von Basel II in Höhe von mehr als 60 Mio. USD (davon 36% allein für IT-Systeme und Schnittstellen) (Marlin, 2005). In diesem Zusammenhang wird oft von der ”Enabler-Funktion” der IT gesprochen.

30


Aufgrund der beschriebenen Dynamik ist eine statische Konstruktion bzw. zustandsbezogene Optimierung des UIS im Allgemeinen wenig sinnvoll bzw. unmöglich. Um den sich wandelnden (und in der Regel nicht im Voraus ermittelbaren) Anforderungen der internen und externen Stakeholder gerecht werden zu können, ist stattdessen eine kontinuierliche Adaption des Unternehmensinformationssystems erforderlich. Dieser Anpassungsprozess kann im Sinne der Kybernetik als ein Regelkreis aufgefasst werden, bei dem auf Abweichungen vom Soll-Zustand (aktuelle Anforderungen) mit entsprechenden Eingriffen in das System (Systemänderungen, System Changes) reagiert wird (vgl. hierzu auch Hafner, 2005, S. 74; Gabriel und Beier, 2003, S. 55ff.). Für den Änderungsprozess gelten in der Praxis zwei wichtige Einschränkungen. Zum einen darf der reguläre Betrieb durch die entsprechenden Systemänderungen nicht beeinträchtigt werden. Hieraus würden in den meisten Fällen unabsehbare Schäden für das Unternehmen erwachsen.35 Zum anderen stellen alle Systemänderungen aus ökonomischer Sicht Investitionen dar. Entscheidungen über Systemveränderungen können daher in nach dem Wirtschaftlichkeitsprinzip arbeitenden Organisationen nur auf Basis von entsprechenden KostenNutzen-Betrachtungen gerechtfertigt werden. Aus beiden Einschränkungen folgt, dass die IT mittlerer und großer Unternehmen in der Regel nicht in radikalen Schritten erneuert werden kann. Stattdessen liegt in der Praxis de facto ein evolutionärer Entwicklungsprozess vor. Der Evolutionsprozess ist dabei nicht per se auf ein globales Zielsystem ausgerichtet. Fehlen übergreifende Regulationsmechanismen, so ist vielmehr davon auszugehen, dass die jeweiligen Stakeholder auf Basis der ihnen zur Verfügung stehenden Einflussmöglichkeiten Systemveränderungen im Sinne ihrer jeweiligen Partikularinteressen anstoßen. Dies wird in der Praxis durch verschiedene Faktoren begünstigt. So liegt etwa die Initiierung von ChangeProjekten nach den vorherrschenden IT-Planungssystemen bei den jeweiligen Fachbereichen. Auch die Kostenverrechnung erfolgt meist auftraggeberbezogen.36 Im Ergebnis werden entsprechende Projekte oft sehr stark auf spezifische Stakeholder-Interessen ausgerichtet. Der Lösungshorizont ist dann meist nur lokal und / oder kurzfristig. Die beschriebene Problematik der multipolaren Evolution gilt zunächst unabhängig vom Zentralisierungsgrad der IT-Funktion. Bei einer stärkeren Dezentralisierung ergeben sich darüber hinaus zusätzliche Schwierigkeiten. So wird heute vor allem in großen Organisatio-

35 36

So geht man etwa davon aus, dass Banken einen Totalausfall ihrer IT maximal für zwei Tage überleben können. Bei Industrieunternehmen liegt dieser Wert bei ca. fünf Tagen (Heinrich, 2001, S. 25). Für beides gibt es gute Gründe. Die Argumentation ist daher nicht als Plädoyer gegen solche Systeme anzusehen. Vielmehr soll die Notwendigkeit einer zusätzlichen Architektursteuerung auf Makroebene aufgezeigt werden.

Rahmenbedingungen

31

nen auch die Implementierung von Systemänderungen zunehmend in Arbeitsteilung und von unterschiedlichen Auftragnehmern durchgeführt. Beispielsweise gibt es etwa in diversifizierten Konzernen häufig separate IT-Einheiten für die verschiedenen Unternehmensbereiche (z. B. für Commercial und Investment Banking). Zum Teil unterhalten sogar die Fachbereiche eigene Entwickler-Pools, um schnell auf neue Anforderungen reagieren zu können. Weiterhin nimmt der Anteil unternehmensexterner Fertigung kontinuierlich zu (z. B. Outsourcing, Einsatz von Standard-Software).37 Eine solchermaßen verteilte Implementierung von System Changes kann den oben beschriebenen Effekt der Partikularisierung verstärken, da so auch auf der Implementierungsseite eine übergreifende Sichtweise und Verantwortung zunehmend abhanden kommt. Als Zwischenergebnis der bisherigen Analyse kann festgehalten werden, dass das Unternehmensinformationssystem ohne besonderen regulatorischen Eingriff einem multi-polaren Evolutionsprozess unterliegt. Dieser begünstigt eine lokale Optimierung, da mit den Systemänderungen jeweils partikulare Interessen verfolgt werden. Globale und langfristige SystemAnforderungen werden demgegenüber systematisch vernachlässigt. Es besteht daher die Gefahr, dass unternehmensweite Synergiepotentiale ungenutzt bleiben. 3.1.2

Komplexitätswachstum

Die fortwährende Veränderung des UIS birgt zudem das Risiko eines schleichenden Komplexitätswachstums (vgl. Namba, 2005, S. 3). Einen theoretischen Erklärungsansatz hierfür bietet das Forschungsgebiet der Software-Evolution (Program Evolution Dynamics). Dieses befasst sich mit den Prozessen und Gesetzmäßigkeiten der System-Entwicklung auf Mikroebene. Ausgehend von empirischen Untersuchungen wurden dabei im Laufe der vergangenen 30 Jahre mehrere ”Gesetze” identifiziert.38 Für die vorliegende Betrachtung ist vor allem das Zweite Gesetz der Software-Evolution von Bedeutung. Dieses besagt, dass die Komplexität eines im Einsatz befindlichen Softwaresystems mit der Zeit ansteigt, wenn nicht explizite Maßnahmen ergriffen werden, um dies zu verhindern (Lehman, 1997, S. 1f.).39 Hintergrund dieser Gesetzmäßigkeit ist die empirische Beobachtung, dass im Zuge einer sukzessiven

37 38

39

Dies wird in Zukunft angesichts der Entwicklungen im Bereich ”Software-As-Service” eine neue Qualität gewinnen. Diese sind nach dem Hauptvertreter der Forschungsrichtung auch unter der Bezeichnung Lehman’s Laws of Software Evolution bekannt geworden. Die Herleitung der Gesetzmäßigkeiten basierte ursprünglich auf einer Analyse der Entwicklung des IBM-Betriebssystems OS/360. Die Zusammenhänge wurden später im Rahmen der FEASTProjekte bei einer Reihe weiterer Systeme bestätigt (Lehman, 1998, S. 6; Lehman, 2001, S. 6). Zum Teil wird in diesem Zusammenhang auch der Begriff Entropie gebraucht (z. B. Belady und Lehman, 1976, S. 228). Damit wird eine Analogie zum zweiten Hauptsatz der Thermodynamik hergestellt (vgl. Lehman, 1997, S. 1).

32


Implementierung inkrementeller Systemveränderungen die Beziehungen und Abhängigkeiten zwischen den Systemelementen immer mehr zunehmen und die ursprüngliche Struktur (bzw. Architektur) nach und nach verloren geht (Lehman, 1997, S. 2). Der für die Strukturerhaltung notwendige Aufwand steigt dabei mit zunehmendem Systemalter. Lehman spricht in diesem Zusammenhang auch von sogenannten ”anti-regressiven Aktivitäten”. Hierunter werden Maßnahmen verstanden, die keinen unmittelbaren Wert für die Stakeholder schaffen, sondern der langfristigen Werterhaltung des Systems dienen.40 Obwohl das zweite Gesetz der Software-Evolution sich ursprünglich nur auf die Mikroebene bezieht, erscheint eine Übertragung auf das Unternehmensinformationssystem zulässig (vgl. auch Namba, 2005, S. 3). So wird die Evolution des UIS letztlich durch die vielen einzelnen Entwicklungsprozesse auf Mikroebene bestimmt. Ohne entsprechende strukturgebende bzw. -erhaltende Maßnahmen ist daher auch auf Makroebene von einem kontinuierlichen Komplexitätswachstum auszugehen. Dies kann im Extremfall dazu führen, dass notwendige Systemveränderungen nicht mehr mit vertretbarem Aufwand durchgeführt werden können und somit eine zunehmende ”Verkrustung” des Unternehmensinformationssystems eintritt. Vor allem in informationsintensiven Branchen kann dies zu einer Einschränkung der Wandlungsfähigkeit des gesamten Unternehmens führen. Nach der systemischen Managementtheorie wird hierdurch die Lebensfähigkeit der Organisation gefährdet (vgl. Malik, 1984). 3.1.3

Systemevolution am Beispiel der Finanzwirtschaft

Im Folgenden sollen der beschriebene Evolutionsprozess und die sich daraus ergebenden Konsequenzen kurz anhand der Entwicklung in der Finanzwirtschaft illustriert werden. Diese eignet sich hierfür aufgrund der vergleichsweise langen Entwicklungsgeschichte in besonderer Weise.41 Die Ursprünge des Einsatzes von Informationstechnologie in der Finanzwirtschaft reichen bis in die Mitte des 20. Jahrhunderts zurück. So nahm etwa die Dresdner Bank im Jahr 1958 ihre erste Rechenanlage in Betrieb (Sokolovsky, 1993, S. 411). Der Fokus lag dabei zunächst auf einer Unterstützung der besonders informationsintensiven Prozesse, vor allem im Massengeschäft. Bis zum Ende der 1970er Jahre entstanden dann etappenweise Anwendungen für die Produktion der verschiedenen Finanzprodukte (z. B. Kreditsysteme, Kontokorrentsysteme, Wertpapierhandels- und -abwicklungssysteme, Zahlungsverkehrssys-

40 41

Dazu zählen u. a. die Dokumentation des Systems oder die Durchführung von Restrukturierungsmaßnahmen (Lehman, 2001, S. 4). Vgl. im Folgenden u. a. Moormann (2004) und Krönung (2004).

Rahmenbedingungen

33

teme). Aus Mangel an verfügbarer Standard-Software mussten diese Systeme zum Großteil in Eigenregie entwickelt werden. Die in den 1960er und 1970er Jahren vorhandenen Technologien sowie die damals übliche sparten- bzw. produktorientierte Organisation der Institute führten dabei zur Entstehung von in sich abgeschlossenen, monolithischen Großrechneranwendungen. In den Folgejahren mussten die Anwendungsportfolios aufgrund der dynamischen Entwicklung der Marktanforderungen sowie der stetigen Zunahme der aufsichtsrechtlichen Regulierung stetig erweitert und angepasst werden. So entstanden u. a. weitere Systeme für den Handel und die Abwicklung von Kapitalmarktprodukten (z. B. Zins-, Aktien- und Kreditderivate), dispositive Systeme für die operative und strategische Unternehmenssteuerung (z. B. Markt- und Kreditrisikosteuerung, Collateral Management) sowie Anwendungen zur Vertriebsunterstützung (Customer Relationship Management, CRM). Weiterhin wurden sogenannte ”betriebswirtschaftliche Anwendungen” zur Unterstützung sekundärer Geschäftsprozesse (z. B. Rechnungswesen, Beschaffung, Personalwirtschaft) eingeführt. Mit der zunehmenden Reife des IT-Marktes kamen mehr und mehr vorintegrierte Standard-Software-Pakete (wie z. B. SAP R/3) und andere ”Off-the-Shelf-Tools” zum Einsatz. Die primär fachlich getriebenen Erweiterungsvorhaben führten dabei vor dem Hintergrund des technologischen Fortschritts zu einer sukzessiven Adoption unterschiedlichster Hardware-Plattformen (z. B. S/390, AS/400, Sun Sparc, x86), Betriebssysteme (z. B. OS/390, AIX/Solaris/Linux, Windows NT/2000/2003) und Software-Entwicklungs-Frameworks (z. B. COM, CORBA, J2EE, .NET). Eine besondere Zensur bedeutete in diesem Kontext der Übergang von der Großrechner-basierten (und weitgehend zentralisierten) IT hin zu einer arbeitsplatz-zentrierten und personalisierten IT durch die Einführung flächendeckender und vernetzter Arbeitsplatzrechner (PC). Dies eröffnete den einzelnen Mitarbeitern neue Möglichkeiten bei der Verarbeitung und Auswertung von Daten und begünstigte die Entstehung einer Vielzahl dezentraler Client-Server-basierter Anwendungen. Eine Kopplung bzw. Integration der einzelnen Anwendungen wurde infolge der hohen Komplexität in der Regel nur insoweit realisiert als es zur Unterstützung kritischer Geschäftsprozesse notwendig erschien. Dabei wurden unter dem Einfluss von Partikularinteressen und kurzfristigen Projektzielen häufig nur einfache und problemspezifische Direktschnittstellen geschaffen. Eine Integration von Datenbeständen erfolgte nur in wenigen Fällen. Insbesondere dispositive Systeme und horizontale Anwendungen42 wurden typischerweise redundant

42

Hierunter werden produktspartenübergreifende Systeme verstanden, welche bestimmte Funktionalitäten unternehmensweit bündeln (z. B. CRM) (vgl. auch Winter, 2005, S. 593).

34


ausgelegt.43 Mit dem Aufkommen spezieller Integrationsprodukte zum Beginn des 21. Jahrhunderts (z. B. Enterprise Application Integration, Portale) wurden verstärkt zentralisierte Integrationsansätze verfolgt. Diese waren aber meist auf bestimmte Domänen (z. B. Wertpapier-Routing) beschränkt. Mit der Entstehung neuer Vertriebs- und Kooperationskanäle insbesondere über das Internet sahen sich viele Finanzdienstleister seit dem Ende der 1990er Jahre zu einer grundsätzlichen Reorganisation ihrer IT-Landschaften gezwungen. Primäres Ziel war dabei in der Regel eine Öffnung der Kernanwendungen sowie die Herstellung der Multi-Kanalfähigkeit. Kunden und Geschäftspartnern sollte damit die Möglichkeit gegeben werden, über unterschiedliche Zugangskanäle (wie Internet, Telefon, Mobile Endgeräte, Filiale, Geldautomat) in Kontakt mit dem Unternehmen zu treten. Hierzu wurden meist objektorientierte Komponententechnologien wie CORBA und J2EE eingesetzt. Dabei wurde in der Regel eine neue Anwendungsschicht zwischen den Kernanwendungen und den verschiedenen Vetriebskanälen eingezogen. Gleichzeitig wurde versucht, die monolithischen Großrechneranwendungen aufzuspalten und zentrale Funktionen in Form von wiederverwendbaren Services bereitzustellen (Service-Oriented-Architecture). Hierfür haben sich inzwischen XML / Web Servicebasierte Standards etabliert. Als vorläufiges Ergebnis der skizzierten Entwicklung herrschen heute in vielen Finanzinstituten sehr komplexe und technologisch heterogene Systemlandschaften mit einer großen Anzahl von Einzelanwendungen und Diensten und einem zum Teil nur noch schwer überschaubaren Geflecht von Schnittstellen und Abhängigkeitsbeziehungen vor. So verfügte etwa die Credit Suisse im Jahre 2005 über insgesamt 823 Einzelapplikationen und knapp 900 Services (Tice, 2005). Die LBBW besaß nach eigenen Angaben sogar ca. 1.000 Anwendungen (CIO Magazine, 2005b).44 Den Kern der finanzwirtschaftlichen Anwendungsportfolien bilden auch heute meist noch die in den 1970er Jahren entstandenen Großrechnersysteme. Obwohl technologisch veraltet, wurde eine vollständige Ablösung aufgrund der erheblichen Investitionswerte45 und des hohen Migrationsrisikos in den meisten Fällen verworfen. Auch im Hinblick auf die eingesetzten Technologieplattformen entwickelte sich im Laufe der Zeit ein hohes Maß an Heterogenität. So verfügte beispielsweise die HypoVereinsbank im Jah-

43 44

45

Daten werden hier meist im Batch-Verfahren zu bestimmten Intervallen aus verschiedenen Quellsystemen bezogen. Die Aussagefähigkeit und Vergleichbarkeit solcher Zahlen ist aufgrund der uneinheitlichen Definition des Begriffes ”Anwendung” beschränkt. Trotzdem können die Daten als Indikation für das erreichte Maß an Komplexität dienen. So geht man etwa davon aus, dass für die Neuentwicklung eines Back-Office-Systems im Bereich der Wertpapierabwicklung allein ca. 150 Mio. EUR investiert werden müssten (vgl. Fischer und Rothe, 2004, S. 21).

Rahmenbedingungen

35

re 2004 über ca. 150 verschiedene Produktionsumgebungen (Betriebssystem / Hardware / Release-Kombinationen) (Penzel, 2004, S. 124). Der beschriebene Zustand der Finanzwirtschaftlichen IT-Umgebungen schlägt sich heute in einer Reihe von Problemen nieder. Defizite im Hinblick auf die fachlichen bzw. geschäftspolitischen Anforderungen bestehen u. a. in folgenden Bereichen:46 • mangelnde Prozessorientierung: Die Zersplitterung der Anwendungslandschaften in eigenständige und in sich abgeschlossene Spezial-Anwendungen verhindert eine durchgehende Geschäftsprozessunterstützung. So wird etwa der Kreditprozess für kleine und mittlere Unternehmen nach einer aktuellen Studie nur bei 7% der 500 größten deutschen Banken durch ein einziges Anwendungssystem abgedeckt (Siegel, 2005, S. 8). Eine solche Verteilung der Anwendungsfunktionalität auf unterschiedliche maschinelle Aufgabenträger erschwert ein integriertes Geschäftsprozessmanagement. Hierdurch werden insbesondere ein flexibles Redesign sowie die kontinuierliche Optimierung und Automatisierung von Kernprozessen behindert. • mangelnde Innovationsfähigkeit: Die siloartigen Anwendungsstrukturen und die fehlende Modularität und Standardisierung sowohl auf technischer als auch auf fachlicher Ebene hemmen die Entwicklung innovativer Produkte und Problemlösungen. So müssen etwa im Rahmen des Financial Engineering zunehmend komplexe Produkte aus verschiedenen Basiskomponenten zusammengesetzt werden (”Strukturierte Produkte”). Eine fehlende Interoperabilität der Teilsysteme kann dabei die zügige Anpassung an geänderte Marktanforderungen erschweren. Die hohe Komplexität kann darüber hinaus entsprechende Vorhaben unwirtschaftlich machen. • mangelnde Kundenorientierung: Die produkt- bzw. spartenorientierte Organisation der Anwendungssystemlandschaften behindert eine ganzheitliche Kundenbetreuung im Sinne eines Customer Relationship Managements (CRM). Probleme erwachsen v. a. aus der Tatsache, dass kundenbezogene Informationen und Prozesse über diverse Anwendungen verteilt sind und

46

Die genannten Punkte gelten selbstverständlich nicht für alle Institute in gleicher Weise. In einigen Bereichen wurden innerhalb der letzten Jahre vielerorts deutliche Fortschritte erzielt.

36


daher nicht ohne weiteres integriert verwaltet werden können.47 In vielen Häusern fehlt bis heute eine einheitliche Kundensicht, d. h. eine unternehmensweite Darstellung aller vorhandenen Kundendaten einschließlich der abgeschlossenen Geschäfte (s. hierzu auch Abschnitt 6.3.3). • mangelnde Kooperationsfähigkeit: Die monolithischen Silostrukturen, die historisch gewachsenen Punkt-zu-PunktSchnittstellen sowie die geringe Verbreitung einheitlicher Standards für den zwischenbetrieblichen Leistungsaustausch erschweren ein Aufbrechen von Wertschöpfungsketten und eine stärkere Kooperation mit anderen Finanzdienstleistern. Hierdurch werden eine Verringerung der Wertschöpfungstiefe und die Entstehung von Wertschöpfungsnetzen nach dem Vorbild der Industrie behindert. Auch die Durchführung von Fusionen und Übernahmen wird durch die bestehenden IT-Landschaften oft beeinträchtigt, weil theoretisch vorhandene Synergien sich praktisch nicht realisieren lassen. • mangelnde Mitarbeiterorientierung: Die Vielfalt der Anwendungslandschaften führt in der Regel auch zu heterogenen Benutzerschnittstellen und entsprechenden Medienbrüchen. So existieren etwa beim Kreditprozess für kleine und mittlere Unternehmen zwischen den einzelnen Prozessschritten (Vertrieb, Antragsvorbereitung, Kreditentscheidung, Bearbeitung, Servicing, Riskoüberwachung, Workout) bei jeweils zwischen 20% und 60% der 500 größten deutschen Banken Medienbrüche (Siegel, 2005, S. 7). Dies zieht oft komplexe Interaktionsprozesse nach sich. Die Folge hiervon können eine sinkende Mitarbeitermotivation sowie eine steigende Fehleranfälligkeit sein. • hohe operationale Risiken: Die nur noch schwer überschaubare Gesamtkomplexität der Informationsverarbeitung schlägt sich auch in entsprechenden operationalen Risiken nieder. Für Banken können hieraus nach Basel II zusätzliche Eigenkapitalkosten entstehen. • hohe Kosten: Heterogenität und Redundanzen auf Hardware-, Betriebssystem- und Anwendungsebene führen zusammen mit der ineffizienten Integrationstopologie zu hohen Betriebs-, Wartungs- und Entwicklungskosten. So machen die IT-Kosten von Banken

47

So existierten nach einer Studie aus dem Jahre 2003 in Finanzinstituten im Durchschnitt 43 Systeme für Kundenund Geschäftspartnerdaten (Fuchs, 2005).

Konzeptioneller Rahmen

37

heute zwischen 15% und 20% des gesamten Verwaltungsaufwandes aus (Moormann, 2004).48 Dabei entfallen rund 70% der IT-Ausgaben auf den reinen Anwendungsbetrieb (”Run the Bank”) (Fischer und Rothe, 2004, S. 25; CIO Magazine, 2005b). Für eine zukunftsgerichtete Weiterentwicklung stehen daher nur vergleichsweise geringe Mittel zur Verfügung.49

3.2 Konzeptioneller Rahmen Auf Basis der vorangegangenen Analyse wird in diesem Abschnitt ein konzeptioneller Rahmen für das Architekturmanagement entwickelt. Dazu werden zunächst bestehende Definitionsansätze betrachtet und der Gegenstand einer solchen Funktion bestimmt. Anschließend wird die häufig zitierte Analogie zwischen Architekturmanagement und Stadtplanung untersucht. Auf dieser Grundlage wird dann ein theoretisches Framework für das Architekturmanagement entwickelt. Zum Abschluss wird eine Einordnung des Architekturmanagements in den Aufgabenbereich des Informationsmanagements vorgenommen. 3.2.1

Gegenstand und Funktion

Um den beschriebenen Problemen der multipolaren Systemevolution entgegenzuwirken und eine nachhaltige und an den globalen Zielen orientierte Entwicklung zu gewährleisten, ist ein steuernder Eingriff in den Prozess der UIS-Evolution erforderlich (vgl. z. B. Murer, 2005, S. 47; Spitzer, 2005, S. 605). Viele Unternehmen haben hierzu in den letzten Jahren in den Auf- bzw. Ausbau einer Funktion IT-Architekturmanagement investiert. Obwohl jedoch Architekturmanagement in der Praxis inzwischen weit verbreitet ist (vgl. Kapitel 4), existiert in der Literatur bis heute kein einheitliches Verständnis über den Gegenstand und die Aufgaben einer solchen Funktion. Eine präzise Definition des Begriffes wird daher häufig vermieden. Eine erste Umschreibung wurde im Jahr 2002 vom Arbeitskreis Enterprise Architecture (AkEA) der Gesellschaft für Informatik (GI) erarbeitet. Demnach ”definiert [Architekturmanagement, Anmerkung des Verfassers] die Prozesse, Rollen und Organisationsstrukturen, die für die fortlaufende Entwicklung und Umsetzung unternehmensweiter Architekturen wichtig sind” (Günzel, 2002, S. 5). Diese Definition fokussiert primär auf organisatorische Aspekte bei der (Weiter-) Entwicklung der IT-Makroarchitektur. Eine umfassendere, management-

48 49

Auf Basis der veröffentlichten Geschäftsberichte entspricht dies für das Jahr 2006 etwa einem IT-Kostenvolumen von 3 Mrd. EUR bei der Deutschen Bank und von 800 Mio. EUR bei der Commerzbank. So lag etwa bei der Commerzbank der Anteil der ”freien” IT-Resourcen im Jahr 2005 bei nur ca. 10% (CIO Magazine, 2005c).

38


orientierte Sichtweise findet sich bei Niemann: ”Architekturmanagement plant, organisiert, kontrolliert und steuert die Entwicklung der Unternehmensarchitektur” (Niemann, 2005, S. 3). Eine ähnliche Position wird auch von Schwinn (2005, S. 28) vertreten. Hafner schließlich versteht Architekturmanagement als eine Teilfunktion des Informationsmanagements und nimmt eine weitere Abgrenzung über das zugrundeliegende Zielsystem vor (Hafner, 2005, S. 69). Als zentrales Ziel des Architekturmanagements bestimmt er – unter Bezugnahme auf die Kybernetik zweiter Ordnung – die Sicherstellung der langfristigen Steuerbarkeit des UIS (Hafner, 2005, S. 79ff.). Allen genannten Definitionsansätzen ist zunächst der Bezug zur IT-Makroarchitektur gemein. Kennzeichnend ist darüber hinaus eine Charakterisierung des Architekturmanagements als dauerhafte Aufgabe bzw. Unternehmensfunktion. Hierdurch wird der Erkenntnis Rechnung getragen, dass eine nachhaltige zielorientierte Entwicklung der Makroarchitektur nicht durch eine einmalige Transformation von ”Legacy-Architekturen” erreicht werden kann, sondern als kontinuierlicher Prozess im Unternehmen verankert werden muss. Ausgehend von diesen Gemeinsamkeiten wird unter Architekturmanagement im Folgenden eine Teilfunktion des betrieblichen Informationsmanagements verstanden, welche ein ganzheitliches Management der IT-Makroarchitektur zum Gegenstand hat. Der Begriff Management wird dabei funktional im Sinne von Leitungshandeln in einer Organisation gebraucht (vgl. Heinrich und Lehner, 2005, S. 7).50 Architekturmanagement kann damit als das Leitungshandeln in einer Organisation in Bezug auf die IT-Makroarchitektur angesehen werden.51 Im Hinblick auf die inhaltliche Rolle innerhalb der Unternehmensorganisation wird in der Literatur häufig die koordinierende Funktion des Architekturmanagements herausgestellt (vgl. z. B. auch Birkhölzer und Vaupel, 2003, S. 121; Hafner, 2005, S. 60). Unter Koordination kann dabei allgemein das Management von Abhängigkeiten zwischen Aktivitäten verstanden werden (Malone und Crowston, 1994, S. 90). Im Kontext des Architekturmanagements sind diese Aktivitäten durch die fortlaufenden Veränderungsvorhaben (Projekte) am Unternehmensinformationssystem gegeben. Abhängigkeiten bestehen dagegen aufgrund der Beziehungen zwischen den Elementen bzw. Subsystemen des UIS und den Auswirkungen entsprechender Veränderungen auf die globalen Systemeigenschaften (vgl. Malone und Crowston, 1994, S. 97). Der Zweck von Architekturmanagement kann

50 51

Dies umfasst insbesondere die Teilfunktionen Planung, Entscheidung und Kontrolle. Mit dieser Definition sollen ausführende Tätigkeiten keineswegs aus dem Aufgabenspektrum des Architekturmanagements ausgeschlossen werden. Vielmehr soll der steuernde Charakter hervorgehoben werden.


39

entsprechend in der wechselseitigen Abstimmung der Änderungsvorhaben und deren Ausrichtung an langfristigen und unternehmensweiten Zielen gesehen werden. Die Notwendigkeit hierfür ergibt sich nach der Organisationstheorie als Folge der Arbeitsteilung bei der (Weiter-) Entwicklung des UIS (sowohl in personeller als auch in zeitlicher Hinsicht) (vgl. Kieser und Walgenbach, 2003, S. 18). 3.2.2

Analogie zum Städtebau

Um die Probleme der multi-polaren Systemevolution zu verdeutlichen und hieraus geeignete Lösungsansätze für das Architekturmanagement abzuleiten, wird in der Praxisliteratur häufig die Metapher des Städtebaus bzw. der Stadtplanung verwendet (z. B. Schulte, 1997, S. 6ff.; Sassoon, 1998; Schulte, 2002; Longepe, 2003). Das Unternehmensinformationssystem wird dabei in Analogie zu einer realen Stadt gesetzt. Die Methodik des Analogieschlusses ist in der Wissenschaft weit verbreitet. Bereits mit der Übertragung des Architekturbegriffes auf Informationssysteme wurde ein solcher Schluss vollzogen. Obwohl die logische Beweiskraft des Analogieschlusses beschränkt ist, bietet er grundsätzlich eine gute Möglichkeit, bestehendes Wissen aus bereits erschlossenen Domänen für neue Forschungsfelder nutzbar zu machen. Hierdurch können u. a. bestehende Wissenslücken identifiziert und Anstöße zu neuen Erklärungsmodellen oder Lösungsansätzen gegeben werden. Im Folgenden wird daher die Analogie zwischen Architekturmanagement und Stadtplanung genauer untersucht. 3.2.2.1

Ähnlichkeit der Problemstruktur

Voraussetzung für die Zulässigkeit eines Analogieschlusses ist die Ähnlichkeit der betreffenden Gegenstände in Bezug auf die für eine Vergleichbarkeit wesentlichen Merkmale. Im vorliegenden Fall können diesbezüglich eine Reihe von Gemeinsamkeiten identifiziert werden. So gibt es zwischen Stadt und Unternehmensinformationssystem zunächst deutliche Ähnlichkeiten in struktureller Hinsicht. Beide können als konkrete, künstliche, offene, dynamische und sehr komplexe Systeme angesehen werden, die aus einer Vielzahl von Subsystemen bestehen. Im Fall der Stadt sind diese primär durch die jeweiligen Grundstücke und die darauf errichteten Gebäude gegeben. Dem entsprechen auf der Seite des Unternehmensinformationssystems die Informationsverarbeitungs-Aufgaben und die hierzu eingesetzten Anwendungssysteme.

40


Sowohl bei der Stadt als auch beim Unternehmensinformationssystem kann darüber hinaus eine Infrastrukturebene identifiziert werden. Bei der Stadt umfasst diese z. B. Straßen, öffentliche Verkehrsmittel sowie die Energie- und Wasserversorgung (vgl. Abschnitt 3.2.2.2). Im Fall des Unternehmensinformationssystems können unter der Infrastruktur alle zentralen Einrichtungen und Dienste verstanden werden, die den einzelnen Anwendungen gemeinschaftlich zur Verfügung gestellt werden und die diese zur Ausführung benötigen. Hierzu zählen etwa standardisierte Hardware/Basissystem-Plattformen, Netzwerke und Integrationsdienste sowie sonstige anwendungsübergreifende Services. Eine gemeinsame Infrastruktur bildet eine wichtige Voraussetzung für eine einheitliche Systemintegration und die Realisierung von Synergieeffekten.52 Sowohl die Stadt als auch das UIS unterliegen weiterhin einem kontinuierlichen – und nur begrenzt vorhersagbaren – Evolutionsprozess. Beide sind dabei von einer dynamischen Umwelt umgeben. So sind etwa die Bevölkerungsentwicklung einer Stadt und die Bedürfnisse der dort ansässigen Individuen und Organisationen nur schwer zu prognostizieren. Auf Seiten des UIS liegen die Unsicherheiten u. a. im Bereich der zukünftigen Strategieausrichtung sowie dem technologischen Fortschritt (vgl. Abschnitt 3.1.1). In beiden Fällen wird die Entwicklung des Systems außerdem durch eine Vielzahl von unterschiedlichen Anspruchsgruppen mit zum Teil divergierenden Interessen bestimmt.53 Entsprechende Veränderungen können dabei auf Mikroebene jeweils durch lokale Auftraggeber (Grundstückseigentümer bzw. Bauherren einerseits, interne Stakeholder bzw. Fachbereiche andererseits) initiiert und von unterschiedlichen Auftragnehmern (Bauunternehmen einerseits, IT-Abteilungen und externe IT-Dienstleister andererseits) umgesetzt werden. Schließlich müssen Systemveränderungen in beiden Fällen jeweils ”im laufenden Betrieb” durchgeführt werden. Genauso wie eine Stadt nicht für einen Umbau evakuiert werden kann, darf es bei der Weiterentwicklung des UIS zu keinen gravierenden Betriebsausfällen kommen. Diesen Gemeinsamkeiten zwischen Stadt und UIS stehen auch einige Unterschiede gegenüber, auf die hier ebenfalls kurz hingewiesen werden soll.54 Eine wichtige Divergenz besteht zunächst im Hinblick auf die Komplexität der jeweiligen Subsysteme. So besitzen betriebli-

52

53 54

Eine wichtige Voraussetzung für die Nutzung zentraler Infrastrukturen bildet die Existenz von Standards. So gibt es etwa internationale Standards für den Straßenbau (z. B. Spurbreite) oder die Elektrizitätsversorgung (z. B. 220 Volt). Aufgrund der im Vergleich zum Bauwesen bisher stark unterentwickelten Standardisierung in der IT ist eine Nutzung von Synergien hier deutlich schwieriger. So müssen zur Unterstützung der im Unternehmen existierenden Systeme aus Kompatibilitätsgründen häufig mehrere funktional redundante Infrastrukturelemente bereitgestellt werden. Den internen und externen Stakeholdern des UIS stehen hier die Einwohner und Unternehmen der Stadt gegenüber. Vgl. hierzu auch Namba (2005, S. 49f.)


41

che Informationssysteme in der Regel eine deutlich höhere Komplexität als konventionelle Gebäude. Auch die möglichen Beziehungen zwischen den Subsystemen sind hier weitaus vielfältiger. Während diese im Fall der Stadt im Wesentlichen durch die räumliche Anordnung gegeben sind, können auf der logisch-abstrakten Ebene von Informationssystemen prinzipiell beliebig komplexe Schnittstellen-Beziehungen bestehen. Schließlich ist auch die Entwicklungsdynamik im Bereich der Informationstechnologie als höher einzustufen. Im Ergebnis lässt sich festhalten, dass das Management der IT-Makroarchitektur und die Stadtplanung trotz gewisser Unterschiede eine ähnliche Problemstruktur aufweisen. Es erscheint daher zulässig und zweckmäßig, entsprechende Lösungskonzepte aus dem Bereich der Stadtplanung auf das Architekturmanagement zu übertragen. Hierzu werden im Folgenden zunächst Methodik und Organisation der traditionellen Stadtplanung vorgestellt. 3.2.2.2

Methodik und Organisation der Stadtplanung

Gegenstand der Stadtplanung ist die vorausschauende Planung und Steuerung der Stadtentwicklung. In der Bundesrepublik Deutschland liegt die Verantwortung hierfür bei der jeweiligen politischen Stadtvertretung (Stadt- bzw. Gemeinderat) (Albers, 1996, S. 8). An der Durchführung sind üblicherweise mehrere Behörden der Stadtverwaltung beteiligt. Hierzu zählen insbesondere das Stadtplanungsamt sowie die Bauaufsichtsbehörden. Primäres Ziel der Stadtplanung ist eine nachhaltige städtebauliche Entwicklung, welche gleichermaßen wirtschaftliche, soziale, kulturelle und umweltpolitische Aspekte berücksichtigt. Im Mittelpunkt stehen dabei der Ausgleich der verschiedenen Einzelinteressen sowie die Sicherstellung des Allgemeinwohls (vgl. Albers, 1996, S. 7, S. 9). Hintergrund hierfür ist die empirisch gewonnene Einsicht, dass eine rein marktwirtschaftliche Koordination auf Basis individueller Investitionsentscheidungen von Grundstückseigentümern bzw. Investoren (”der Boden geht zum besten Wirt”) häufig zu Nachteilen für die Allgemeinheit führt. Zu nennen sind in diesem Zusammenhang vor allem die Vernachlässigung sozialer und zukunftsorientierter Aspekte der Stadtentwicklung (vgl. Albers, 1996, S. 14f.). Zur Erreichung dieser allgemeinen Zielsetzung ist ein steuernder Eingriff in den Prozess der Stadtentwicklung erforderlich. Die Art des Eingriffs richtet sich dabei im Idealfall nach dem in Abbildung 3.2 dargestellten Schema.55 So sind Bauvorhaben, die zur Förderung von Partikularinteressen eine Benachteiligung von Gemeininteressen in Kauf nehmen, durch geeignete Regulationsmaßnahmen zu verhindern (vierter Quadrant, links oben). Vorhaben, welche

55

Vgl. hierzu auch Namba (2005, S. 41).

Regulation

marktorientierte

privater Bauvorhaben

Koordination

Aktivitäten)

Partikularinteressen

Vorteil


Nachteil

42

Initiierung gemein-

(keine

schaftlicher Bauvorhaben / Infrastrukturentwicklung

Nachteil

Vorteil Gemeininteressen

Abbildung 3.2: Ansatzpunkte der Stadtplanung (in Anlehnung an Sakamoto, 2000 über Namba, 2005, S. 41)

den Gemeininteressen nicht zuwiderlaufen, können dagegen der dezentralen bzw. marktorientierten Koordination überlassen bleiben (erster Quadrant, rechts oben). Hierdurch wird ein größtmöglicher Freiraum für die Entfaltung individueller Nutzungs- und Gestaltungswünsche erhalten (vgl. Albers, 1996, S. 7). Vorhaben aus der Kategorie des zweiten Quadranten (unten rechts) schließlich gelangen im Rahmen einer rein dezentralen bzw. marktorientierten Koordination üblicherweise nicht zur Umsetzung. Sie müssen deshalb durch die jeweilige Gemeinde initiiert und zentral finanziert werden. Ein wesentliches Element der Stadtplanung bildet in Deutschland die sogenannte Bauleitplanung. Hierbei handelt es sich um ein amtliches Verfahren, das gesetzlich durch das Baugesetzbuch (BauGB) geregelt ist. Die Bauleitplanung umfasst die zwei Kernelemente Flächennutzungsplanung und Bebauungsplanung.56 Den Ausgangspunkt bilden dabei jeweils eine kartografische Erfassung der Ist-Situation sowie eine Analyse der Zielsysteme und Entwicklungstendenzen. Auf dieser Basis werden im Rahmen der Flächennutzungsplanung für die betreffende Gemeinde zunächst die Grundzüge der Bodennutzung auf grob-granularer Ebene festgelegt. So werden in der Regel die Grenzen für Wohn- und Industriegebiete, zentrale

56

Vgl. im Folgenden BauGB sowie (Hangarter, 2006, S. 6).


43

Infrastruktureinrichtungen sowie Grünflächen und Naherholungsgebiete fixiert. Der entstehende Flächennutzungsplan wird anschließend im Rahmen der Bebauungsplanung weiter ausgearbeitet. Dabei werden die bestehenden Flächen weiter unterteilt und detaillierte Regeln für eine jeweilige Nutzung definiert. Auf diese Weise können etwa die Art der baulichen Nutzung, die Bauweise, Bauhöhe, etc. verbindlich vorgegeben werden. Ein Bebauungsplan umfasst daher neben einem zeichnerischen Teil (üblicherweise im Maßstab 1:500 oder 1:200) auch einen Textteil, in dem die zugehörigen Bebauungsvorschriften aufgeführt werden. Zur späteren Nachvollziehbarkeit der Entscheidungen sind zudem jeweils entsprechende Begründungen mit in die Pläne aufzunehmen (vgl. Hangarter, 2006, S. 19). Eine besondere Stellung innerhalb der Bauleitplanung nimmt die Planung der zentralen Infrastruktur ein. Dabei können eine technische Infrastruktur sowie eine soziale Infrastruktur unterschieden werden (vgl. Albers, 1996, S. 169). Die technische Infrastruktur umfasst unter anderem Transportsysteme (Straßen, Nahverkehr, Bahn, Flughäfen), Energieversorgung (Elektrizität, Gas), Kommunikationssysteme (Telefon, Internet, Fernsehen), Wasserversorgung, Abwassersystem sowie die Abfallbeseitigung. Zur sozialen Infrastruktur können zentrale Einrichtungen aus den Bereichen Bildung (z. B. Schulen, Universitäten, Bibliotheken), Gesundheit (z. B. Krankenhäuser), Kultur (z. B. Museen) sowie Sicherheit (z. B. Polizei, Feuerwehr) gezählt werden. Die Elemente der Infrastruktur werden allen Flächennutzern einheitlich zur Verfügung gestellt. Zum Teil ist eine Nutzung auch obligatorisch (z. B. bei der Müllentsorgung). Die Erarbeitung der Bauleitpläne erfolgt typischerweise durch das Stadtplanungsamt der jeweiligen Gemeinde. Für das Planaufstellungsverfahren schreibt der Gesetzgeber dabei einen Mediationsprozess unter Einbeziehung der Öffentlichkeit vor. Im Rahmen dieses Prozesses sind öffentliche und private Belange gegeneinander abzuwiegen und auszugleichen. Der Planungshorizont beträgt üblicherweise ca. 10-15 Jahre für den Flächennutzungsplan und ca. fünf Jahre für den Bebauungsplan. Nach Abschluss der Planungsphase müssen die Bauleitpläne durch den zuständigen Gemeinderat formell beschlossen werden (Albers, 1996, S. 133). Spätere Änderungen sind dann nur durch ein formales Änderungsverfahren (analog zum Aufstellungsverfahren) möglich. Die verabschiedeten Bauleitpläne (und insbesondere der Bebauungsplan) bilden den rechtsverbindlichen Rahmen für die zukünftige Entwicklung der Stadt. Im Hinblick auf die Umsetzung der Planvorgaben können dabei prinzipiell zwei Typen von Bauvorhaben unterschieden werden (vgl. auch Albers, 1996, S. 103). Zum einen können bauliche Maßnahmen durch die

44


Gemeinde selbst in Auftrag gegeben werden. Hiervon wird vor allem im Bereich der Infrastruktur-Entwicklung Gebrauch gemacht. So müssen insbesondere neue Flächen zunächst an bestehende Infrastrukturnetze angeschlossen werden, um eine Nutzung bzw. Entwicklung zu ermöglichen (”Erschließung”). Die hierfür erforderlichen Investitionen sind üblicherweise durch die betreffende Gemeinde (bzw. die ihr angeschlossenen Versorgungsbetriebe) zu tätigen. Andererseits können Bauvorhaben auch von privaten Grundstückseigentümern initiiert werden. Dazu sind von den betreffenden Bauherren zunächst jeweils entsprechende Baugenehmigungen zu beantragen. Die Bauanträge werden dann von den zuständigen Bauaufsichtsbehörden auf ihre Verträglichkeit mit den verabschiedeten Leitplänen geprüft. Bauvorhaben, welche gegen die Vorgaben verstoßen, werden nur in begründeten Ausnahmefällen genehmigt. 3.2.2.3

Beurteilung

Über die beschriebenen Instrumente der Stadtplanung ist eine zielorientierte Steuerung der Stadtentwicklung möglich.57 Dabei wird den Besonderheiten der für die Stadtentwicklung typischen mehrdimensionalen und in hohem Maße dynamischen Interessenkonstellationen Rechnung getragen. So unterliegen sämtliche Planungsschritte einer sorgfältigen Abwägung von Einzel- und Gemeininteressen. Darüber hinaus erfolgt eine formale Einbeziehung der jeweiligen Stakeholder in den Planungsprozess. Dem steht naturgemäß allerdings ein gewisser Zuwachs an Bürokratie gegenüber. Hierdurch können zusätzliche Kosten sowie zeitliche Verzögerungen entstehen. Inhaltlich besitzt die Stadtplanung den Charakter einer Rahmenplanung, bei der lediglich grundlegende Strukturen und Regeln für die zukünftige Entwicklung festgelegt werden, ohne in die Details der Umsetzung vorzugreifen. Der Fokus der stadtplanerischen Tätigkeit liegt entsprechend auf der übergreifenden Gestaltung der Gesamttopologie sowie der Festsetzung bestimmter – für die Außenwirkung relevanter – Aspekte einzelner Gebäude. Dazu werden sowohl konkrete Pläne des angestrebten Zielzustandes (Projektionen bzw. Modelle) erstellt als auch allgemeine (generische) Regeln für die Lenkung von Bauvorhaben definiert (vgl. hierzu auch Albers, 1996, S. 67). Im Sinne der Organisationstheorie kann daher von einem kombinierten Einsatz der beiden Koordinationsmechanismen Planung (Festlegung ei-

57

Obwohl die Methodik der Stadtplanung sich im Laufe des vergangenen Jahrhunderts zu einer vergleichsweise reifen Disziplin entwickelt hat, bildet sie selbstverständlich keine Garantie für eine erfolgreiche Stadtentwicklung. Hierfür gibt es in der Tat zahlreiche Beispiele.


45

nes konkreten Zielzustandes) und Programmierung (Festlegung allgemeiner Regeln)58 gesprochen werden (vgl. hierzu z. B. Kieser und Walgenbach, 2003, S. 108).59 Sowohl die Investitionsverantwortung als auch die konkrete Ausgestaltung individueller Bauvorhaben liegen dagegen in der Verantwortung der jeweiligen Bauherren bzw. Architekten. Lediglich im Bereich der Infrastruktur erfolgt eine zentrale Bereitstellung bzw. Finanzierung durch die Gemeinde. Auf diese Weise kann die Evolution der Stadt auf Makroebene in bestimmte Bahnen gelenkt werden, ohne gleichzeitig eine an der Umweltdynamik bzw. den individuellen Anforderungen ausgerichtete Entwicklung auf Mikroebene zu behindern. Die Methodik der Stadtplanung kann daher als ein hybrider Steuerungsansatz aufgefasst werden, der die Vorteile zentraler (bzw. ordnungspolitischer) und dezentraler (bzw. marktorientierter) Koordination miteinander verbindet. 3.2.3 Theoretisches Framework Der beschriebene Ansatz der Stadtplanung erscheint aufgrund der vergleichbaren Problemstruktur grundsätzlich auch für das Management der IT-Makroarchitektur anwendbar (vgl. hierzu u. a. Schulte, 1997, S. 6ff.; Sassoon, 1998; Schulte, 2002; Longepe, 2003). Dem Architekturmanagement kann dabei im übertragenen Sinne die Rolle von Stadtplanungsamt und Bauaufsichtsbehörden zugewiesen werden. Dieser Gedanke wird im Folgenden der Entwicklung eines theoretischen Frameworks für das Architekturmanagement zugrundegelegt. Ausgangspunkt für ein zielorientiertes Management der IT-Makroarchitektur muss zunächst die Identifikation der übergreifenden und langfristigen Anforderungen an das UIS aus der Perspektive des Gesamtunternehmens darstellen (”Gemeinwohl”). Diese übergeordneten Architekturziele können in Abhängigkeit der internen und externen Unternehmenssituation individuell festgelegt und priorisiert werden. Den Ausgangspunkt sollte dabei die jeweilige Unternehmensstrategie bilden. Zur Erreichung bzw. Sicherstellung der definierten Architekturziele ist ein steuernder Eingriff in den Prozess der UIS-Evolution erforderlich. Die Art dieses Eingriffs hat sich dabei prinzipiell nach dem aus der Stadtplanung bekannten Schema zu richten (vgl. Abbildung

58

59

Hierfür ist in der Literatur zum Teil auch der Begriff Standardisierung gebräuchlich. Im Rahmen der vorliegenden Arbeit wird der Begriff Standardisierung dagegen im systemtheoretischen Sinne von Varietätsreduktion verwendet. Unter Koordinationsmechanismen werden in der Organisationstheorie formale Regelungen zur Abstimmung arbeitsteiliger Prozesse und der Ausrichtung von Aktivitäten auf die Organisationsziele verstanden (Kieser und Walgenbach, 2003, S. 101).

46


3.2). Demnach sind Änderungsvorhaben mit negativen Implikationen für die übergeordneten Architekturziele zu verhindern bzw. entsprechend neu auszurichten. Darüber hinaus können zusätzlich gemeinschaftliche Vorhaben zur Förderung der Architekturziele initiiert werden. Die Entscheidungsfindung im Rahmen des Architekturmanagements setzt in der Regel eine Operationalisierung der definierten Architekturziele voraus. Hierzu bietet sich eine ganzheitliche Rahmenplanung nach dem Vorbild der Bauleitplanung an. Das Ziel einer solchen Architektur-Leitplanung muss es sein, ausgehend von den definierten Architekturzielen verbindliche Strukturen und Regeln für die zukünftige Entwicklung des Unternehmensinformationssystems festzulegen. Dazu können analog zur Stadtplanung grundsätzlich zwei komplementäre Koordinationsmechanismen eingesetzt werden: Architektur-Planung und Architektur-Programmierung. Unter Architektur-Planung ist in diesem Zusammenhang die Entwicklung konkreter Pläne der angestrebten Zielarchitektur zu verstehen. Dabei kann analog zur Stadtplanung die Gesamtfunktionalität des Unternehmensinformationssystems in Subsysteme zerlegt werden, welche sich unabhängig voneinander implementieren (und warten) lassen.60 Die primären Arbeitsprodukte der Architektur-Planung sind mehr oder weniger formale Modelle der SollArchitektur. Wie bei der Stadtplanung sollten die Architekturpläne grundsätzlich auf einer hohen Abstraktionsebene ansetzen und nicht zu sehr in die Implementierung einzelner Informationssysteme vorgreifen. Unter Architektur-Programmierung ist andererseits die Festlegung von allgemeinen Richtlinien und Standards für die Durchführung von Änderungsvorhaben zu verstehen. Diese können sich auf alle Aspekte des Änderungsprozesses beziehen, welche eine Relevanz für die Entwicklung der IT-Makroarchitektur besitzen. Hierzu zählen insbesondere die im Rahmen von Änderungsvorhaben einzusetzenden Methoden und Komponenten. Dabei ist grundsätzlich eine Differenzierung nach Subsystemen möglich. Weiterhin sind unterschiedliche Verbindlichkeitsstufen denkbar. Im Hinblick auf die Umsetzung der Planungsergebnisse gibt es analog zur Stadtplanung wiederum prinzipiell zwei Ansatzpunkte. Zum einen muss sichergestellt werden, dass die von entsprechenden Stakeholdern initiierten (regulären) Änderungsvorhaben mit den definierten Vorgaben der Architektur-Leitplanung im Einklang stehen (passive Architektur-Implemen-

60

Longepe (2003) schlägt hierfür eine hierarchische Aufteilung des UIS in ”Zonen”, ”Distrikte” und ”Blocks” (”Plots”) vor, welche jeweils durch klar definierte Schnittstellen von ihrer Umwelt abzugrenzen sind. Die kleinste Einheit (”Blocks”) steht dabei für in sich abgeschlossene und als Ganzes ersetzbare Anwendungssysteme zur Unterstützung bestimmter betrieblicher Funktionen.


47

Architekturziele

Stakeholder

Partikularinteressen Nachteil Vorteil

Architekturmanagement

Vorhaben-

freie

Regulation

Evolution

(keine

Architektur-

Aktivitäten)

vorhaben

UIS

Nachteil Vorteil Gemeininteressen

VorhabenPlanung

Evolutionsprozess

VorhabenUmsetzung

Abbildung 3.3: Konzeptioneller Rahmen

tierung). Hierzu ist zunächst eine umfassende Kommunikation gegenüber allen relevanten Stakeholdern erforderlich. Darüber hinaus muss die Konformität von Entwicklungsvorhaben mit Zielarchitekturen sowie Richtlinien und Standards geprüft und ggf. durchgesetzt werden. Dafür eignen sich formale Genehmigungsverfahren nach dem Vorbild der Baugenehmigung. Zum anderen kann auch direkt eine aktive Architektur-Implementierung durchgeführt werden. Hierzu können entweder eigene Entwicklungskapazitäten unterhalten oder entsprechende Projekte über das Programmmanagement initiiert werden. Eine aktive Architektur-Implementierung ist vor allem dort notwendig, wo die marktorientierte Koordination versagt. Dies umfasst insbesondere die Durchführung von allgemeinen Reorganisations- bzw. Konsolidierungsmaßnahmen sowie den Aufbau und die Pflege von zentralen Infrastrukturkomponenten

48


(z. B. Integrationsplattformen, wiederverwendbare Services). Durch entsprechende Implementierungsmaßnahmen kann eine Annäherung an die definierten Architekturziele in der Regel deutlich beschleunigt werden. Die bisherigen theoretischen Überlegungen können in Form des in Abbildung 3.3 dargestellten Frameworks zusammengefasst werden. Dieses beschreibt den Stakeholder-getriebenen Evolutionsprozess des Unternehmensinformationssystems. Ausgehend von sich ändernden Anforderungen einzelner Stakeholder werden dabei fortlaufend neue Änderungsvorhaben geplant und realisiert. Als übergeordnete Koordinationsfunktion mit unternehmensweiter Sicht greift das Architekturmanagement in diesen Evolutionskreislauf ein. Es nimmt dabei ausgehend von globalen Architekturzielen eine Gesamtarchitektur-bezogene Steuerung vor. Diese kann je nach Problemstellung primär regulativer oder transformierender Natur sein. Die definierten Architekturziele müssen stets die langfristigen Anforderungen an das UIS aus Gesamtunternehmensperspektive reflektieren. Sie sind daher ebenfalls regelmäßig zu aktualisieren. Als Input hierfür können die Unternehmensstrategie bzw. die langfristigen Anforderungen der verschiedenen Stakeholder dienen. Im Sinne der Kybernetik bildet das Architekturmanagement damit einen zweiten Regelkreis, welcher dem primären Regelkreis der UIS-Evolution übergeordnet ist. 3.2.4

Einordnung in das Informationsmanagement

Nach der grundlegenden Bestimmung von Gegenstand und Aufgaben des Architekturmanagements soll in diesem Abschnitt eine kurze Einordnung in das Informationsmanagement sowie eine Abgrenzung gegenüber den verwandten Funktionsbereichen vorgenommen werden. Nach Heinrich und Lehner (2005, S. 22f.) umfasst das Informationsmanagement – verstanden als das Leitungshandeln in einem Unternehmen in Bezug auf Information und Kommunikation – eine strategische, eine taktische sowie eine operative Aufgabenebene. Die strategische Ebene beinhaltet dabei die Aufgaben der Planung, Überwachung und Steuerung des UIS als Ganzes. Auf taktischer Ebene steht dagegen die Planung, Überwachung und Steuerung einzelner Systemkomponenten (insbesondere einzelner Informationssysteme) im Mittelpunkt. Gegenstand der operativen Ebene sind schließlich die für eine adäquate Nutzung des UIS notwendigen Aufgabengebiete (insbesondere Produktionsbetrieb und Service) (vgl. Heinrich und Lehner, 2005, S. 22f.).


49

IT-Strategie

Portfoliomanagement

Anforderungsmanagement

Architekturmanagement

Programmmanagement

IT-Governance

Abbildung 3.4: Funktionen des strategischen Informationsmanagements (in Anlehnung an Niemann, 2005, S. 9)

Gemäß dieser Untergliederung ist das Architekturmanagement auf der strategischen Ebene des Informationsmanagements einzuordnen. Für die weitere Abgrenzung gibt es unterschiedliche Möglichkeiten. In der Praxis gewinnt dabei zunehmend eine System- bzw. Architektur-orientierte Ausrichtung an Bedeutung. Danach können im Rahmen des strategischen Informationsmanagements die in Abbildung 3.4 dargestellten Funktionsbereiche unterschieden werden (vgl. Niemann, 2005, S. 9, 39ff.). Aufgabe des Anforderungsmanagements ist die Aufnahme und Kanalisierung der aufkommenden Stakeholder-Anforderungen. Dies beinhaltet unter anderem die systematische Erfassung von Änderungswünschen (Change Requests), die Bündelung gleichgerichteter Anforderungen und die Erarbeitung von Projektvorschlägen. Das Anforderungsmanagement ist dabei durch eine nutzerorientierte Sicht auf das UIS gekennzeichnet (vgl. auch Heinrich und Lehner, 2005, S. 58). Entsprechende Aufgaben werden in der Regel von Business Analysten bzw. IT-Koordinatoren im Rahmen des IT-Planungsprozesses wahrgenommen.

50


Einen Gegenpol zum Anforderungsmanagement bildet das Architekturmanagement. Dieses hat eine ganzheitliche Steuerung der IT-Makroarchitektur zum Gegenstand. Ziel ist entsprechend eine nachhaltige und an den Gesamtinteressen ausgerichtete Entwicklung des UIS. Hierzu wird einerseits eine Regulation der UIS-Evolution vorgenommen. Andererseits kann das Architekturmanagement auch selbst Entwicklungen (insbesondere auf der Ebene der Infrastruktur) durchführen bzw. entsprechende Vorhaben in das Portfoliomanagement einbringen. Gegenstand des Portfoliomanagements ist die übergreifende Vorhabensteuerung auf der Ebene der Investitionsentscheidung. Dies umfasst insbesondere die Auswahl und Priorisierung von Projekten bzw. Projektprogrammen. In die Entscheidungsprozesse können dabei gleichermaßen strategische, finanzwirtschaftliche, risikoorientierte sowie architekturbezogene Kriterien einfließen. Das Portfoliomanagement wird häufig durch den CIO persönlich wahrgenommen. Zum Teil existieren hierzu auch entsprechende Entscheidungsgremien (z. B. CIO-Board, Investitionsboard). Das Programmmanagement schließlich befasst sich mit der übergreifenden Steuerung von Projekten bzw. Projektprogrammen während der Projektdurchführung. Umfangreiche Projektprogramme verfügen häufig über vielfältige wechselseitige Abhängigkeiten. Aufgabe des Programmmangements ist daher, die verschiedenen Einzelvorhaben zu koordinieren und eine Gesamtsteuerung aus übergreifender Perspektive vorzunehmen. Der Rahmen für Anforderungs-, Architektur-, Portfolio- und Programmmanagement wird ferner durch IT-Strategie und IT-Governance bestimmt. Die IT-Strategieentwicklung umfasst die Festlegung übergreifender IT-Ziele sowie die grundlegende strategische Positionierung der IT-Funktion im Unternehmen. Hierzu zählen etwa Entscheidungen über die Fertigungstiefe (Sourcing-Strategien, Einsatz Standard-Software), die Schwerpunkte des IT-Einsatzes (Einsatzstrategie) sowie den Umgang mit neuen Technologien (Technologiestrategie). IT-Governance hingegen kann als eine Meta-Funktion angesehen werden, welche die Organisations- und Entscheidungsstrukturen der IT-Funktion definiert.61 Entsprechende Aufgaben werden in der Praxis häufig durch den CIO wahrgenommen. Zum Teil existieren hierfür auch eigene IT-Strategie- bzw. IT-Governance-Ressorts.

61

Vgl. hierzu ausführlich Weill und Ross (2004).

Bestehende Ansätze

51

3.3 Bestehende Ansätze In den vergangen Jahren sind eine Reihe von methodischen Konzepten entwickelt worden, welche das Management der IT-Makroarchitektur mehr oder weniger umfassend unterstützen. Dabei ist zwischen einfachen Methoden für bestimmte Teilaufgaben einerseits und umfassenden Referenz- bzw. Vorgehensmodellen andererseits zu unterscheiden (vgl. hierzu auch Hafner, 2005, S. 90ff.). Zur ersten Kategorie können etwa die in Abschnitt 2.2.4.2 genannten Ansätze zur Unternehmens- bzw. Unternehmensinformationssystem-Modellierung wie das Zachman-Framework oder Planungskonzepte wie das Business Systems Planning (BSP) (IBM Deutschland GmbH, 1982) gezählt werden. Zu den wichtigsten Vertretern der zweiten Kategorie gehören das TOGAF-Framework der Open Group, der Enterprise Unified Process (EUP) nach Ambler et al. (2005) sowie die Practical Guide to Federal Enterprise Architecture (FEA) des CIO Council. Im deutschsprachigen Raum sind darüber hinaus die Ansätze von Dern (2003), Niemann (2005) und Hafner (2005) zu nennen. Nachfolgend werden beispielhaft das TOGAF-Framework, der EUP sowie das Management der IS-Architektur nach Hafner vorgestellt. Bezüglich der übrigen Ansätze sei auf die angegebene Literatur verwiesen. 3.3.1 TOGAF TOGAF (The Open Group Architecture Framework) ist ein Rahmenwerk der Open Group für das Management der IT-Makroarchitektur62 . Erklärtes Ziel der Initiative ist es, ausgehend von den praktischen Erfahrungen der Teilnehmer-Unternehmen einen anerkannten IndustrieStandard zu schaffen. TOGAF geht auf das Mitte der 1990er Jahre durch das US-Verteidigungsministerium entwickelte TAFIM-Framework (Technical Architecture Framework for Information Management) zurück. Es adressierte daher ursprünglich nur den Bereich der technischen Architektur. Erst später erfolgte eine Ausweitung auf die übrigen Architekturebenen. Die nachfolgenden Ausführungen beziehen sich auf die aktuelle Version 8.1 Enterprise Edition.63 Den Kern von TOGAF bildet die sogenannte Architecture Development Method (ADM). Hierbei handelt es sich um ein generisches Vorgehensmodell für die iterative Planung und Implementierung der IT-Makroarchitektur.

62 63

In der TOGAF-Terminologie wird hierfür der Begriff Enterprise Architecture verwendet. Vgl. hierzu im Folgenden The Open Group (2003).

52


Prelim: Prelim: Framework Framework and and Principles Principles

Architecture Architecture Vision Vision Architecture Architecture Change Change ManageManagement ment

ImpleImplementation mentation GoverGovernance nance

Business Business Architecture Architecture

RequireRequirements ments

Migration Migration Planning Planning

Information Information Systems Systems Architecture Architecture

Technology Technology Architecture Architecture Opportunity Opportunity and and Solutions Solutions

Abbildung 3.5: TOGAF ADM (aus The Open Group, 2003)

Im Rahmen der ADM wird zwischen einer Business-, einer Informationssystem- sowie einer Technologiearchitektur unterschieden. Die Informationssystemarchitektur wird darüber hinaus nochmal in eine Anwendungs- und eine Datenarchitektur unterteilt. Ansonsten macht die ADM keine Vorgaben hinsichtlich der einzusetzenden Ordnungsrahmen zur Strukturierung von Architektur-Artefakten (Architektur-Frameworks im engeren Sinne). Das Vorgehensmodell der ADM umfasst acht zyklisch angeordnete Phasen, in deren Mittelpunkt die jeweiligen Anforderungen stehen, sowie eine vorgelagerte Initialisierungsphase (vgl. Abbildung 3.5). In dieser Initialisierungsphase werden zunächst die Methodik des Architekturmanagements definiert (typischerweise auf Basis des TOGAF Frameworks) und die entsprechenden Rollen und Prozesse aufgesetzt. Der ADM-Zyklus beginnt anschließend mit der Erarbeitung einer Architektur-Vision. Hierzu werden die relevanten Stakeholder und deren Anforderungen ermittelt. Davon ausgehend wird dann der grobe Rahmen der Architektur-Entwicklung abgesteckt. In den folgenden drei Phasen werden in einem Top-DownVerfahren die Business-, die Informationssystem- sowie die Technologiearchitektur abgeleitet. Dabei werden jeweils zunächst der Ist-Zustand erfasst (”Baseline Architecture”), der

Bestehende Ansätze

53

Soll-Zustand spezifiziert (”Target Architecture”) sowie eine Abweichungsanalyse durchgeführt. Anschließend werden die verschiedenen Implementierungsoptionen evaluiert und eine entsprechende Migrationsplanung erstellt. Die eigentliche Implementierung ist in der TOGAF-Philosophie grundsätzlich nicht Gegenstand des Architekturmanagements, sondern wird durch entsprechende Auftragnehmer (z. B. Entwicklungsabteilung, externe Partner) ausgeführt. Hierfür werden in der Phase Implementation Governance entsprechende Verträge (”Architecture Contracts”) vereinbart. Auf dieser Grundlage werden anschließend die entwickelten Lösungen geprüft und abgenommen. Die letzte Phase schließlich adressiert das Change Management nach Erreichung der Zielarchitektur. Dies umfasst insbesondere das Monitoring von Umweltveränderungen. Dabei ist jeweils zu entscheiden, ob entsprechende Änderungen im Rahmen des Change Managements adressiert werden können (Vereinfachungen oder inkrementelle Veränderungen) oder ob ein neuer Entwicklungszyklus gestartet werden muss (Re-Architecting). Neben der ADM umfasst das TOGAF-Framework weiterhin das sogenannte Enterprise Continuum. Hierbei handelt es sich um einen Ressourcen-Pool für wiederverwendbare Architektur-Bausteine, die bei der Anwendung der ADM eingesetzt werden können. Dazu zählen insbesondere Referenzarchitekturen und Referenzmodelle. Ein wesentliches Element des Enterprise Continuum ist die TOGAF Foundation Architecture. Diese umfasst das TOGAF Technical Reference Model (Modell und Taxonomie generischer Plattform-Services) sowie die TOGAF Standards Information Base (Datenbank offener Industrie-Standards). Ein weiteres Element des Enterprise Continuums ist das Integrated Information Infrastructure Reference Model. Dieses baut auf der TOGAF Foundation Architecture auf und adressiert den unbeschränkten Informationsaustausch innerhalb des Unternehmens. Ergänzt wird das TOGAF-Framework schließlich durch die sogenannte TOGAF Resource Base. Dabei handelt es sich um eine Sammlung von speziellen Methoden, Guidelines, Templates usw. zur Unterstützung des Architekturmanagements. Die TOGAF Resource Base umfasst insbesondere auch ein Architecture-Governance-Framework mit einem entsprechenden Rollenmodell. Insgesamt stellt TOGAF einen umfassenden anforderungsgetriebenen Ansatz dar, der in der Unternehmenspraxis zunehmende Verbreitung findet. Trotz zum Teil ausführlicher Angaben über die zu erstellenden Entwicklungsergebnisse verfügt der Ansatz allerdings über kein integriertes Metamodell (vgl. Leist und Zellner, 2006, S. 685). Aufgrund der historischen Entwicklung liegt der Fokus zudem auf der technischen Ebene. Kritisiert wird an TOGAF

54


vor allem die sequentielle Anordnung der einzelnen Phasen im Rahmen der ADM (vgl. z. B. Hafner, 2005, S. 100). Dies wird dem evolutionären Charakter der UIS-Entwicklung nur bedingt gerecht. Darüber hinaus ist eine top-down-orientierte Entwicklung der IT-Makroarchitektur aufgrund der hohem Komplexität des UIS meist mit einem großen finanziellen Aufwand und Risiko verbunden. 3.3.2

Enterprise Unified Process

Der Enterprise Unified Process (EUP) nach Ambler et al. (2005) ist ein übergreifendes Vorgehensmodell für den Software-Prozess auf Unternehmensebene.64 Er stellt eine Erweiterung des Rational Unified Process (RUP) dar, welcher sich in der Praxis zu einem de-facto Standard der Software-Entwicklung auf Mikroebene entwickelt hat. Ziel des EUP ist eine vollständige Abdeckung des gesamten Lebenszyklus software-basierter Systeme im Unternehmen. Dazu wird der RUP um die zwei zusätzlichen Phasen Production (Produktion) und Retirement (Stilllegung) sowie die neue Disziplin Operations and Support (Betrieb und Support) erweitert. Darüber hinaus werden die sieben ”Unternehmensdisziplinen” (Enterprise Disciplines) Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration sowie Software Process Improvement eingeführt (vgl. Abbildung 3.6). Diese adressieren verschiedene einzelsystem- bzw. projektübergreifende Aspekte des Informationsmanagements. Zu allen Disziplinen werden dabei Aktivitätendiagramme mit den notwendigen Einzelaufgaben (Tasks), den hierbei erzeugten Arbeitsergebnissen (Work Products) sowie den jeweils verantwortlichen Rollen (Roles) spezifiziert. Im Folgenden wird kurz auf diejenigen Unternehmensdisziplinen eingegangen, welche einen Bezug zum Architekturmanagement aufweisen. Gegenstand der Disziplin Enterprise Business Modeling ist eine ganzheitliche Unternehmensmodellierung. Dies umfasst zunächst die Definition (bzw. Identifikation) der Unternehmensstrategie. Davon ausgehend erfolgt eine Modellierung der Geschäftsprozesse (einschließlich ihrer Umgebung und den zugehörigen Geschäftsregeln) sowie eine Analyse des jeweiligen Automatisierungspotentials. Daneben beinhaltet das Enterprise Business Modeling die Aktivitäten Domänenmodellierung (Terminologie-Glossar und konzeptuelles Datenmodell) sowie Organisationsmodellierung (Aufbauorganisation und Rollenmodell). Die Nutzung der erstellten Artefakte soll darüber hinaus durch einen entsprechenden ProjektSupport sichergestellt werden.

64

Vgl. im Folgenden Ambler et al. (2005) sowie Ambler (2007).

Bestehende Ansätze

55

Phases Development Disciplines

Inception Inception

Elaboration Elaboration

Construction Construction

Transition Transition

Production Production

Retirement Retirement

Business Modeling Requirements Analysis & Design Implementation Test Deployment Support Disciplines Conf. and Change Mgmt. Project Management Environment Operations & Support Initial Initial

Elab1 Elab1

Elab2 Elab2

Con1 Con1

Con2 Con2

Con3 Con3

Trn1 Trn1

Trn2 Trn2

Production Production

Ret1 Ret1

Ret2 Ret2

Iterations Enterprise Disciplines Enterpr. Business Modeling Portfolio Management Enterprise Architecture Strategic Reuse People Management Enterprise Administration SW Process Improvement

Abbildung 3.6: EUP-Lifecycle (aus Ambler, 2007)

Die Disziplin Enterprise Architecture hat die Fortschreibung und Vertretung der IT-Makroarchitektur65 zum Gegenstand. Hierzu werden ausgehend von den Ergebnissen des Enterprise Business Modeling zunächst die fachlichen und technischen Architekturanforderungen identifiziert. Im nächsten Schritt werden dann sogenannte ”Candidate Architectures” definiert. Hierunter werden mögliche Bausteine zur Änderung bzw. Erweiterung der IT-Makroarchitektur verstanden. Die Untersuchung von Candidate Architectures kann auch eine Evaluierung neuer Technologien sowie eine entsprechende Erprobung im Unternehmenskontext beinhalten. Anschließend erfolgt eine Integration der Candidate Architectures in die Unternehmensarchitektur. Dazu werden Modelle der Zielarchitektur erstellt bzw. überarbeitet.66 Eine weitere Aktivität der Disziplin Enterprise Architecture besteht in der Definition von Referenzarchitekturen. Diese sollen als Vorlagen für die Entwicklung von Mikroarchitekturen dienen. Ziel ist es dabei, die Entwicklungsprozesse zu beschleunigen und auf die

65 66

In der EUP-Terminologie wird hierfür der Begriff Enterprise Architecture verwendet. Konkrete Vorgaben bezüglich der einzusetzenden Frameworks werden dabei nicht gemacht.

56


Unternehmensarchitektur auszurichten. Um die Verwendung der Architektur-Artefakte zu unterstützen bzw. sicherzustellen, sieht der EUP auch im Rahmen der EA-Disziplin einen entsprechenden Projekt-Support vor. Die Disziplin Strategic Reuse beschäftigt sich mit der Wiederverwendung von Entwicklungs-Artefakten (z. B. Quellcode, Komponenten, Architekturmuster, Templates) auf Unternehmensebene. Am Anfang steht dabei die Planung eines Wiederverwendungs-Programms (Reuse Program). Davon ausgehend können entsprechende ”Assets” (generalisierte, dokumentierte und erprobte Artefakte) entweder aus bereits bestehenden Entwicklungen gewonnen (”Harvest Existing Asset”), extern beschafft (”Obtain External Asset”) oder neu entwickelt werden (”Develop Asset”). Die Assets müssen anschließend veröffentlicht bzw. zugänglich gemacht67 und kontinuierlich weiterentwickelt werden. Darüber hinaus muss die Verwendung und richtige Adaption der Assets wiederum durch einen entsprechenden Projekt-Support sichergestellt werden. Schließlich soll der Erfolg des Wiederverwendungsprogramms durch geeignete Kennzahlen gemessen und kommuniziert werden. Gegenstand der Disziplin Enterprise Administration sind übergreifende Administrationsaufgaben auf Unternehmensebene. Hierzu werden das Management physischer Assets (z. B. Hardware, Netzwerke), das Management von informationsbezogenen Assets (z. B. Unternehmensdaten) sowie das Management der unternehmensweiten Sicherheit gezählt. Auch die Disziplin Enterprise Administration beinhaltet dabei jeweils einen entsprechenden Support gegenüber Entwicklungsprojekten. Die Disziplin Software Process Improvement schließlich befasst sich mit der Definition und kontinuierlichen Anpassung der Entwicklungsprozesse bzw. der eingesetzten Vorgehensmodelle auf Mikroebene. Ausgehend von einer Anforderungsanalyse können dabei entweder bestehende Vorgehensmodelle (wie z. B. der RUP) angepasst (”Tailoring”) oder eigene Ansätze neu entwickelt werden. Dabei sind unterschiedliche Methodiken für verschiedene Projektklassen möglich (z. B. für Standardsoftware-Implementierung und Individualentwicklung). Anschließend sind die jeweiligen Vorgehensmodelle organisatorisch zu implementieren. Für die Unterstützung bei der Anwendung sieht der EUP wiederum einen entsprechenden Projekt-Support vor. Insgesamt handelt es sich beim EUP um einen relativ umfassenden Ansatz für das unternehmensweite Management der Systementwicklung. Das Management der IT-Makroarchitektur wird dabei explizit durch die Disziplin Enterprise Architecture adressiert. Gleichwohl wei-

67

Z. B. über ein Reuse Repository.

Bestehende Ansätze

57

sen auch die meisten anderen Enterprise Disciplines einen mehr oder weniger großen Bezug zum Architekturmanagement auf. Die Abgrenzung der Teildisziplinen erscheint zudem etwas willkürlich. Als Erweiterung des RUP basiert der EUP auf dem Software Process Engineering Metamodel (SPEM). Die Beschreibung der Disziplinen und deren Abhängigkeiten ist jedoch trotz Angabe entsprechender Prozessmodelle relativ vage. 3.3.3 Management der IS-Architektur nach Hafner Das Management der IS-Architektur nach Hafner ist eine umfassende Methodik für ein proaktives, evolutionäres und bedarfsorientiertes Management der IT-Makroarchitektur.68 Der Ansatz wurde im Rahmen eines Forschungsprojektes der Universität St. Gallen nach den Grundsätzen des Method Engineering entwickelt. Hierzu wurden die AM-Implementierungen von drei Unternehmen analysiert und zu einer generischen Methodik synthetisiert.69 Die Methodik umfasst ein Vorgehensmodell, welches die wesentlichen Aktivitäten des Architekturmanagements und deren Abfolge beschreibt, sowie spezielle Techniken (Einzelmethoden) zur Unterstützung der jeweiligen Aktivitäten. Darüber hinaus existiert ein Dokumentationsmodell, welches die zu erstellenden Ergebnisdokumente beschreibt. Ergänzt wird der Ansatz ferner um ein Rollenmodell. Bezüglich der organisatorischen Implementierung werden dagegen keine Vorgaben gemacht. Die Ergebnistypen der Methodik und deren Beziehungen sind formal in Form eines Metamodells spezifiziert. Das Vorgehensmodell besteht aus insgesamt drei Phasen (vgl. Abbildung 3.7).70 Gegenstand der Phase Architekturführung ist die strategische Weiterentwicklung der Architektur. Die Phase wird hierzu in längerfristigen Zyklen durchlaufen. Dabei werden zunächst die strategischen Anforderungen erhoben. Auf dieser Grundlage werden dann verbindliche und operationalisierbare Architekturprinzipien entwickelt. Mit Hilfe dieser Prinzipien wird anschließend der Ist-Zustand der verschiedenen Architekturbereiche beurteilt. In der Folge werden Maßnahmenkomplexe zur Schließung der identifizierten strategischen Lücken abgeleitet und konsolidiert. Diese werden dann in Form von Roadmaps und Modellen der Zielarchitektur (der Autor spricht hier von ”fundamentalen Architektur-Artefakten”) dokumentiert. Die Phase I endet mit einer Beurteilung der Architektur-Effektivität. Hierzu sollen entsprechende Kennzahlen eingesetzt werden.

68 69 70

Der Autor verwendet hierfür den Begriff IS-Architektur. Vgl. im Folgenden Hafner (2005, S. 201ff.). Diese sind jedoch nicht linear angeordnet. Anstatt von Phasen sollte daher besser von Aufgabenbereichen oder ebenen gesprochen werden.


I.5

I.3 Maßnahmenkomplexe ableiten I.4

Architektureffektivität beurteilen

Fundamentale Architekturartefakte aktualisieren

II.4 Abstimmungen herbeiführen II.1

II.2

II.3

Operative Anforderungen identifizieren

Lösungen entwerfen

Architekturartefakte entwickeln

III.3

III.2

III.1

Architekturzielgruppenprojekte unterstützen

Architekturzielgruppenprojekte beurteilen

Architekturartefakte kommunizieren

Architekturführung

I.2 Architekturbereiche strategisch beurteilen

Architekturweiterentwicklung

I.1 Strategieanforderungen identifizieren

Architekturvertretung

58

Abbildung 3.7: Vorgehensmodell nach Hafner (2005, S. 203)

Gegenstand der Phase II ist die kontinuierliche Weiterentwicklung der Architektur. Dabei sind neben den strategischen Vorgaben aus Phase I zusätzlich operative Anforderungen der verschiedenen Anspruchsgruppen zu berücksichtigen. Phase II besitzt daher eine deutlich kürzere Zyklusdauer. Im Rahmen jeder Iteration werden zunächst die aktuellen Anforderungen identifiziert. Auf dieser Basis werden anschließend sogenannte ”nutzerorientierte Architektur-Artefakte” entwickelt. Hierzu zählt der Autor Entwurfsmuster, konkrete Handlungsrichtlinien (”Direktiven”) oder auch Implementierungskomponenten (”Leitelemente”). Phase III schließlich adressiert die Vertretung und Durchsetzung der Ergebnisse aus den Phasen I und II. Dies betrifft insbesondere die entwickelten (”fundamentalen” bzw. ”nutzerorientierten”) Architektur-Artefakte. Das Vorgehensmodell sieht dabei unterschiedliche Kommunikationskanäle vor. Phase III umfasst weiterhin die Konformitätsprüfung von Zielgruppenprojekten. Darüber hinaus sollen ausgewählte Projekte bei der Durchführung durch das Architekturmanagement begleitet und unterstützt werden. Insgesamt stellt der Ansatz von Hafner eine sehr detaillierte und formale Methodik für die Implementierung eines Architekturmanagements zur Verfügung. Dabei werden jedoch bis-

Bestehende Ansätze

59

her nicht alle wesentlichen Aspekte berücksichtigt. So wird insbesondere die organisatorische Einbettung weitgehend ausgeblendet. Erfahrungen über den praktischen Einsatz der Methodik liegen bisher nicht vor.

Kapitel 4

Praxis des Architekturmanagements: Ergebnisse einer Expertenbefragung

Um einen besseren Einblick in die Praxis des Architekturmanagements zu gewinnen, wurde im Rahmen des vorliegenden Forschungsvorhabens zunächst eine explorativ-deskriptive Vorstudie durchgeführt. Ziel dieser Untersuchung war eine erste Bestandsaufnahme zum Status Quo des Architekturmanagements in der Finanzwirtschaft. In diesem Zusammenhang sollten insbesondere auch die bisherigen Erfolgswirkungen ermittelt sowie auftretende Probleme und mögliche Erfolgsfaktoren identifiziert werden. Die Untersuchungsbefunde sollten dabei als Ausgangspunkt für die nachfolgenden Studien dienen. In diesem Kapitel werden die wesentlichen Ergebnisse der Vorstudie vorgestellt.71 Dazu wird zunächst kurz auf die Studienmethodik eingegangen. Danach werden die Ergebnisse zu den verschiedenen Themenfeldern präsentiert. Das Kapitel schließt mit einem kurzen Zwischenfazit.

71

Vgl. hierzu auch Schmidt et al. (2007).

62

4.1

Praxis des Architekturmanagements

Methodik

Um der deskriptiv-explorativen Zielsetzung der Untersuchung und der Heterogenität des Untersuchungsgegenstandes gerecht zu werden, wurde ein qualitativer Forschungsansatz auf Basis leitfadengestützter Experteninterviews (vgl. hierzu Gläser und Laudel, 2004) gewählt. Aus Kosten- und Praktikabilitätsgründen erfolgte dabei eine Beschränkung auf die deutschsprachige Kreditwirtschaft. Die Identifikation der Experten geschah mit Hilfe einer Suchmaschinen-Recherche. Auf diese Weise konnten insgesamt 28 Kandidaten ermittelt werden. Diese wurden anschließend per E-Mail über das Forschungsvorhaben informiert und um einen entsprechenden Interviewtermin gebeten. Von den angeschriebenen Personen erklärten sich 14 zu einer Studienteilnahme bereit.72 Mit dem Teilnehmerkreis konnte ein relativ breites Spektrum der deutschsprachigen Kreditwirtschaft abgedeckt werden. So haben insbesondere Vertreter aller drei großen deutschen Bankengruppen (Sparkassensektor, Genossenschaftssektor, privater Sektor) an der Untersuchung mitgewirkt. Die Untersuchungsgruppe umfasste darüber hinaus drei Institute aus der Schweiz. Zu den Teilnehmern gehörten sowohl Universal- als auch verschiedene Spezialbanken. Sechs Institute verfügten zum Zeitpunkt der Befragung über eine Bilanzsumme von mehr als 300 Mrd. EUR. Abgerundet wird das Spektrum durch drei auf Banken spezialisierte IT- bzw. Outsourcing-Dienstleister.73 Bei den Interviewpartnern handelte es sich meist um die jeweiligen Leiter des Architekturmanagements der betreffenden Unternehmen.74 In einigen Fällen waren die Teilnehmer auch Leiter von Teilfunktionen innerhalb des Architekturmanagements.75 In großen Konzernen existiert oft noch kein geschäftsfeldübergreifendes Architekturmanagement. Die Interviewpartner repräsentieren hier zum Teil nur spezifische Sparten bzw. Regionen.76 Die übrigen Teilnehmer kamen überwiegend aus dem höheren IT-Management bis hin zum Gesamtleiter IT. Die durchschnittliche Unternehmenszugehörigkeit der Interviewpartner betrug neun Jahre. Die durchschnittliche Berufserfahrung lag bei 19 Jahren (davon durchschnittlich zehn Jahre im Architekturumfeld). Diese vergleichsweise hohen Zahlen können als ein Indiz für

72 73 74 75 76

Zwölf unmittelbar, zwei im Wege einer Nachfassaktion. Streng genommen handelt es sich hierbei um branchenfremde Unternehmen. Diese wurden aufgrund der vergleichbaren Problemstruktur (Management bankbetrieblicher IT-Architekturen) mit in die Studie einbezogen. Z. B. ”Leiter Architekturmanagement”, ”Leiter IT-Architektur” oder ”Leiter Enterprise Architecture”. Z. B. ”Leiter Architekturprozess”. Die Untersuchungsergebnisse beziehen sich in diesen Fällen entsprechend nur auf die betreffenden Konzernteile.

Methodik

63

ein hohes Anforderungsprofil sowie eine hohe Spezifität der Aufgaben im Architekturmanagement gewertet werden. Die Studiendurchführung erfolgte zwischen Dezember 2005 und März 2006. Im Verlauf wurden 14 Einzelinterviews mit einer Dauer von jeweils ca. 90 bis 180 Minuten geführt. Die Teilnehmer wurden dabei zunächst über die Zielsetzung der Studie und den Ablauf des Interviews aufgeklärt. Der anschließende formale Teil wurde mit Hilfe eines Leitfadens strukturiert. Dieser umfasste folgende Themenfelder: • demografische Basisdaten • persönliches Architekturverständnis • übergeordnete Ziele des Architekturmanagements • organisatorische Implementierung des Architekturmanagements • eingesetzte Instrumente (Konzepte, Methoden, Werkzeuge) • Ist-Zustand der IT-Landschaft (optional) • aktuelle Gestaltungsziele bei der Transformation der IT-Landschaft • beobachtete Wirkungen des Architekturmanagements • im Rahmen des Architekturmanagements auftretende Probleme • Erfolgsfaktoren des Architekturmanagements aus Teilnehmersicht • Forschungsbedarf aus Teilnehmersicht Dabei wurden im Wesentlichen offene Fragen gestellt. Auf diese Weise sollten möglichst viele unterschiedliche (und ggf. unerwartete) Informationen erfasst werden. Die offenen Fragen wurden weiterhin durch einige geschlossene Fragen zu bestimmten Themenfeldern ergänzt. Die Gesprächsführung geschah unter Anwendung der ”neutralen Interviewtechnik” mit ”weichen Elementen” (Maßnahmen zur Vertrauensbildung und zur Unterstützung des Redeflusses). Die Dokumentation der Interviews erfolgte über Notizen in einem speziellen Dokumentationsbogen und anschließendes Gedächtnisprotokoll. Auf eine Tonbandaufzeichnung

64


wurde aufgrund der zu erwartenden schlechten Akzeptanz verzichtet. Für die Auswertung der Protokolle wurde eine Form der qualitativen Inhaltsanalyse eingesetzt.77 Dabei wurde ausgehend vom Interviewleitfaden ein offenes Kategorienschema verwendet.

4.2

Empirische Ergebnisse

In diesem Abschnitt werden die empirischen Ergebnisse der Untersuchung vorgestellt. Dazu werden zunächst einige übergreifende Informationen zusammengefasst. Anschließend werden die Ergebnisse ausgewählter Themenfelder im Detail präsentiert. Alle getroffenen Aussagen beziehen sich jeweils auf den Status Quo zum Zeitpunkt der Studiendurchführung. 4.2.1

Überblick

Architekturmanagement wird von allen befragten Teilnehmern als ein wichtiges Betätigungsfeld angesehen. Die von den einzelnen Unternehmen verfolgten Ansätze unterscheiden sich dabei jedoch zum Teil erheblich. Unterschiede gibt es nicht nur bezüglich der Form der Implementierung (Abschnitte 4.2.3 und 4.2.5) und der eingesetzten Mittel (Abschnitt 4.2.6), sondern bereits auf der Ebene der verfolgten Ziele (Abschnitt 4.2.4). Ungeachtet dieser Differenzen wird Architekturmanagement allgemein als ein Kernprozess angesehen, welcher nicht ausgelagert werden sollte. Dies wird mit der integrierenden und strategieumsetzenden Funktion begründet. 4.2.2

Historische Entwicklung und Reifegrad

Architekturmanagement ist in den meisten befragten Unternehmen noch eine relativ junge Disziplin. Es wurde oft erst innerhalb der letzten drei Jahre aufgebaut. Die Entwicklung ist dabei in vielen Fällen noch nicht abgeschlossen. Einige Institute verfügen auch bereits über langjährige Erfahrungen (4 Fälle). Die Anfänge liegen hier zum Teil über zehn Jahre zurück. Im Laufe der Zeit kam es in diesen Unternehmen aber häufig zu einem sukzessiven Akzeptanz- und Bedeutungsverlust des Architekturmanagements bis hin zur (vorübergehenden) Auflösung. Als Ursachen hierfür werden eine zu große Restriktivität und Praxisferne (”Elfenbeinturm”) angegeben. Erst innerhalb der letzten Jahre erfolgte dann vor dem Hintergrund der bestehenden Probleme (vgl. Abschnitt 3.1.3) und dem Trend zu Service-Orientierten-Architekturen (SOA) eine Wiederbelebung.

77

Verfahren in Anlehnung an Gläser und Laudel (2004, S. 191ff.).


65

5

4

4

3-4

4

Anzahl Teilnehmer

4

3 3

2

1

1

2

2-3

1

0

0

1

1-2

0

0

4-5

5

0 3

Reifegrad (Selbsteinschätzung)

Abbildung 4.1: Selbsteinschätzung des Reifegrades

Bisher orientieren sich nur wenige der befragten Häuser bei ihrer Implementierung an bestehenden Standard-Methodologien wie z. B. TOGAF (The Open Group, 2003) (vgl. hierzu Abschnitt 3.3). Die verfolgten Ansätze basieren stattdessen überwiegend auf einer Mischung aus Berater-Konzepten und eigenen Erfahrungen. Die meisten Teilnehmer stufen die Reife ihrer AM-Implementierung nichtsdestotrotz als mittel bis hoch ein. Auf einer Skala von 1 (sehr geringe Reife) bis 5 (sehr hohe Reife) liegt der Durchschnittswert der Selbsteinschätzung bei 3,4 (vgl. Abbildung 4.1). Spezielle Reifegradmodelle wie z. B. das NASCIO Enterprise Architecture Maturity Model (NASCIO, 2003) kommen bisher in keinem der befragten Unternehmen zum Einsatz. 4.2.3 Organisationsstruktur Fast alle befragten Unternehmen verfügen über ein institutionalisiertes Architekturmanagement (12 Fälle). In Großkonzernen bestehen dabei oft weitgehend autonome Teil-Organisationen für verschiedene Konzernbereiche (z. B. Private Banking, Investment Banking). Dies ist in der Regel auf politisch-pragmatische Ursachen zurückzuführen.78 Teilweise ist hier für die Zukunft eine stärkere Integration geplant. Die verschiedenen Organisationsformen lassen sich zunächst danach klassifizieren, inwieweit das Architekturmanagement über eine eigene Primär- und / oder Sekundärorganisation verfügt. Von den teilnehmenden Instituten besitzen derzeit zehn eine eigene Primärorganisa-

78

So gehen etwa die Investmentbanking-Sparten vieler europäischer Großbanken auf die Akquisition von angloamerikanischen Häusern zurück. Diese haben häufig auch im Bereich der IT eine gewisse Autonomie bewahrt.

66


tion. Diese ist in der Regel als IT- bzw. Operations-Querschnittsfunktion ausgelegt. Die Zahl der regulär beschäftigten Mitarbeiter liegt dabei typischerweise zwischen fünf und zehn. In Einzelfällen existieren auch AM-Organisationen mit bis zu 60 Mitarbeitern. Kleinere Häuser verfügen dagegen oft nur über einen einzelnen ”IT-Architekten”, welcher für sämtliche Architekturfragen zuständig ist. Die Ansätze mit Primärorganisation können weiterhin nach dem Grad und den Kriterien der Zentralisierung bzw. Dezentralisierung differenziert werden. Im einfachsten Fall existiert hier lediglich eine integrierte Organisationseinheit. Daneben ist auch eine Trennung der Primärorganisation nach Architekturebenen vorzufinden (z. B. Gruppe Anwendungsarchitektur im Bereich Anwendungsentwicklung und Gruppe Technische Architektur im Bereich Infrastruktur). Vor allem in größeren Häusern werden die zentralen Teams darüber hinaus oft durch dezentrale Architekten (bzw. Architekturgruppen) ergänzt. Diese werden meist bestimmten Teilsegmenten der IT-Landschaft zugeordnet und den zentralen Einheiten funktional unterstellt (föderative Organisation).79 Die Hälfte der befragten Unternehmen verfügt weiterhin über eine Sekundärorganisation bestehend aus ein oder mehreren Entscheidungsgremien (z. B. ”Architekturboard”). Viele andere Institute planen die Einführung solcher Gremien. Diese werden nach dem Vorbild der Stadtplanung vor allem zur Verabschiedung von Architektur-Artefakten (z. B. Abnahme eines Bebauungsplanes) sowie für die Entscheidung über die Architekturkonformität von Änderungsvorhaben eingesetzt. Sie sollen die Einbindung aller für eine erfolgreiche Implementierung relevanten Stellen ermöglichen und überdies eine querschnittliche Sichtweise fördern. Zum Teil erfolgt dabei eine Aufteilung in verschiedene Einzelgremien (sowohl vertikal nach Eskalationsstufen als auch horizontal nach Sachgebieten). In manchen Fällen werden entsprechende Aufgaben auch durch ein allgemeines IT-Board wahrgenommen. Beim Versuch, die Organisationskonzepte der befragten Unternehmen anhand der vorgenannten Kriterien in Gruppen einzuteilen, zeigt sich ein vergleichsweise heterogenes Bild. Am weitesten verbreitet ist unter den teilnehmenden Instituten ein Ansatz mit föderativer Primärorganisation und zusätzlichen Entscheidungsgremien (aktuell 4 Fälle, mehrere in Planung). Als ein wesentlicher Vorteil dieses ”schwergewichtigen” Ansatzes können die gute ”Verankerung” des Architekturmanagements im Unternehmen sowie eine hohe Skalierbarkeit gelten. Dem steht jedoch auch ein vergleichsweise großer Personal- und Koordinationsaufwand entgegen.

79

Hierfür ist auch der Begriff ”Domänenarchitekt” gebräuchlich.


67

Ein alternatives Modell stellt der zurzeit von zwei Teilnehmern verfolgte ”leichtgewichtige” Ansatz dar. Hierbei wird bewusst auf eine Primärorganisation verzichtet und stattdessen lediglich eine Koordination der ansonsten dezentral zuständigen IT-Einheiten auf Gremienebene vorgenommen. Dieser Ansatz kann als eine Reaktion auf negative Erfahrungen mit zu restriktiven und praxisfernen Architekturgruppen verstanden werden. Dem Vorteil geringer Kosten und einer hohen Problemorientierung stehen hier allerdings auch gewichtige Nachteile entgegen. So räumt eines der betroffenen Unternehmen ein, dass aufgrund der fehlenden Primärorganisation oft notwendige operative Aufgaben nicht (bzw. nicht fristgerecht) erledigt werden können.80 4.2.4 Ziele Im Hinblick auf die mit dem Architekturmanagement verfolgten Ziele machen die befragten Unternehmen unterschiedliche Angaben. Oft herrscht diesbezüglich auch eine gewisse Unsicherheit. Stringente Zielsysteme können nur von den wenigsten Häusern angegeben werden. Dies überrascht angesichts knapper IT-Budgets und der ohnehin bestehenden Legitimationsproblematik von Architekturmanagement (vgl. Abschnitt 4.2.9). Als Hauptziele des Architekturmanagements werden am häufigsten eine Senkung der ITKosten, eine Erhöhung der IT-Effizienz und / oder eine Steigerung der IT-Produktivität genannt (zusammen 8 Fälle). Das Architekturmanagement soll demnach vorwiegend zu einem wirtschaftlicheren Einsatz von Informationstechnologie beitragen. An zweiter Stelle folgt das Ziel, die Steuerbarkeit der IT zu erhalten bzw. die Flexibilität gegenüber Änderungen zu erhöhen (zusammen 6 Nennungen). Damit soll vor allem der Zeitaufwand zur Implementierung neuer fachlicher Anforderungen (und insbesondere von Produktinnovationen) nachhaltig gesenkt werden (”Time-to-Market”). Dies wird als ein wesentlicher Erfolgsfaktor für eine Verbesserung des Business-IT-Alignments angesehen. Darüber hinaus sind die Ertragspotentiale von Produktinnovationen nach Ansicht vieler Teilnehmer zunehmend von der Geschwindigkeit der Implementierung abhängig. Das gilt v. a. für dynamische und wettbewerbsintensive Geschäftsfelder wie das Wholesale und Investment Banking (z. B. strukturierte Produkte). Viele weitere der genannten Ziele lassen sich ebenfalls direkt oder indirekt auf das Bestreben zur Verbesserung von IT-Effizienz und / oder IT-Flexibilität zurückführen. Dies gilt etwa für eine Reduktion der IT-Komplexität (4 Nennungen), eine stärkere Standardisierung (2

80

Vgl. hierzu im Detail Fallstudie C, Abschnitt 5.4.

68


Nennungen), die Erhöhung der Wiederverwendung (2 Nennungen) oder eine Verkürzung der Entwicklungszeiten (1 Nennung). Während viele Teilnehmer angeben, mit dem Architekturmanagement der eher kurzfristig und auf partikulare Interessen ausgerichteten Business-Sichtweise eine systemübergreifende und zukunftsorientierte Betrachtung entgegensetzen zu wollen, betonen andere explizit die Business-Orientierung ihres Ansatzes. Für diese Unternehmen stellt daher vor allem auch die Erhöhung des Business-IT-Alignments ein Kernziel von Architekturmanagement dar (2 Fälle). Einige Teilnehmer nennen schließlich generische Ziele wie eine ganzheitliche Planung und Optimierung des IT-Einsatzes oder die Umsetzung der IT-Strategie (jeweils 2 Fälle). Weiterhin wird die Schaffung von Transparenz als ein wichtiges Teilziel von Architekturmanagement angesehen (4 Nennungen). 4.2.5

Aufgaben

Zur Erreichung der verfolgten Ziele werden von den für das Architekturmanagement zuständigen Stellen und Gremien unterschiedliche Aufgaben wahrgenommen. In den meisten Fällen lässt sich dabei eine methodische Nähe zu den Konzepten der Stadtplanung feststellen. Die Angaben der Studienteilnehmer wurden daher in Anlehnung an die Aufgabenbereiche der Stadtplanung zu den in Abbildung 4.2 dargestellten Kategorien verdichtet. Dabei erfolgte weiterhin eine Unterteilung in operative und strategische Aufgaben.81 Viele Teilnehmer sehen eine wichtige Aufgabe des Architekturmanagements zunächst in der Dokumentation der bestehenden Ist-Architektur (9 Nennungen).82 Hierbei werden üblicherweise unterschiedliche Architektursichten unterschieden (vgl. Abschnitt 4.2.6). Neben der internen Verwendung (insbesondere als Ausgangspunkt für die Architektur-Planung) werden die Dokumentationsbestände zum Teil auch zur Informationsversorgung von Stakeholdern wie dem Top-Management und / oder der strategischen Planung eingesetzt. Auf der Grundlage der Architektur-Dokumentation wird in acht Unternehmen eine mehr oder weniger systematische Planung der Makroarchitektur durchgeführt. Dies beinhaltet insbesondere die Entwicklung entsprechender Soll-Architektur-Modelle. Dabei können neben dem gewünschten (und unter Umständen idealisierten) Zielzustand auch verschiedene Zwischenstufen betrachtet werden. Zum Teil werden auch entsprechende Transformationspläne

81 82

Vgl. hierzu auch Niemann (2005, S. 24). Die Architektur-Dokumentation wurde angesichts ihrer grundlegenden Bedeutung für die Architektur-Leitplanung sowie des fehlenden Implementierungsbezuges der strategischen Ebene zugeordnet (vgl. dazu auch Niemann, 2005, S. 24).


69

Strategische Aufgaben

Architektur-Dokumentation

Architektur-Leitplanung

Dokumentation der Ist-Architektur (+++)

Planung der ZielArchitektur (++)

Informationsversorgung von Stakeholdern (++)

Planung der ArchitekturTransformation / Abstimmung mit der Vorhabenplanung (++)

Definition von Richtlinien und Standards für ChangeProjekte (+++)

Management des Technologieportfolios (+)

Operative Aufgaben

Aktive Architektur-Implementierung

Durchführung von Architekturprojekten (++)

Entwicklung und Pflege wiederverwendbarer Komponenten (+)

+ bis zu 4 Nennungen

Passive Architektur-Implementierung

Kommunikation der Architekturvorgaben ggü. Change-Projekten (Publikationen, Schulungen) (++)

Projekt-Support (Beratung, Projektarbeit) (++)

++ zwischen 5 und 8 Nennungen

Prüfung der Architekturkonformität von ChangeProjekten (+++)

+++ mehr als 8 Nennungen

Abbildung 4.2: Aufgabenbereiche des Architekturmanagements

(”Roadmaps”) erarbeitet. Einen wichtigen Teilaspekt bildet in diesem Zusammenhang die Abstimmung mit der Vorhabenplanung bzw. dem Portfoliomanagement. In fast allen befragten Unternehmen werden weiterhin allgemeine Richtlinien und Standards für die Durchführung von Änderungsvorhaben definiert (13 Nennungen). So werden z. B. Architekturprinzipien formuliert und Standardkataloge geführt. In einigen Häusern wird darüber hinausgehend ein umfassendes Technologiemanagement betrieben. Hierzu gehören u. a. das Monitoring technologischer Entwicklungen sowie ein bewusstes Life-Cycle-Management der im Einsatz befindlichen Technologien. Auf der operativen Ebene steht die Kontrolle der Architekturkonformität von Änderungsvorhaben im Vordergrund (11 Nennungen). Die Verbindlichkeit der Architekturvorgaben und die vorhandenen Kontrollmechanismen unterschieden sich dabei von Haus zu Haus. Zum Teil existieren hierzu formale Prüf- und Abnahmeprozesse. So müssen sich die betreffenden

70


Projekte in der Regel zum Projektstart und im weiteren Verlauf zu bestimmten Meilensteinen einem Architektur-Check unterziehen.83 Eine vollständige Abdeckung wird dabei jedoch nur von wenigen Häusern erreicht; zum Teil wird bewusst eine Quote von nicht mehr als 70-80% angestrebt. Im Hinblick auf die Einhaltung der Vorgaben müssen weiterhin häufig Zugeständnisse gemacht werden.84 Verstöße werden bisher nur selten formell sanktioniert. Um die Beachtung und Akzeptanz der Architekturvorgaben zu fördern und den notwendigen Praxisbezug des Architekturmanagements sicherzustellen, werden oft auch verschiedene Maßnahmen der Kommunikation ergriffen. So werden etwa Publikationen verfasst oder entsprechende Schulungen durchgeführt. Ferner werden Beratungsleistungen gegenüber Entwicklungsprojekten erbracht. Zum Teil wird darüber hinaus operative Projektarbeit geleistet.85 Dabei erfolgt in der Regel eine bewusste Selektion strategisch bedeutsamer Vorhaben. Im Rahmen der Projektarbeit stehen die Entwicklung von IT-Mikroarchitekturen und die Sicherstellung der Architekturkonformität im Vordergrund. Bei der Hälfte der befragten Unternehmen können weiterhin dedizierte Architekturprojekte durchgeführt werden (7 Fälle). In einigen Häusern werden sogar ganze ”Architekturprogramme” bestehend aus einer Vielzahl von Einzelprojekten und Laufzeiten von mehreren Jahren aufgelegt. Die Umsetzung erfolgt hierbei üblicherweise im Rahmen des regulären Programmmanagements. Teilweise werden aber auch operative Entwicklungskapazitäten unterhalten, um wiederverwendbare Infrastruktur-Komponenten bereitzustellen und zu pflegen (z. B. bankfachliche Komponentenbibliotheken oder Services). Insgesamt gesehen setzen die Unternehmen bei der Ausgestaltung des Architekturmanagements unterschiedliche Schwerpunkte. Das volle Aufgabenspektrum wird bisher nur von wenigen Instituten abgedeckt. 4.2.6

Instrumente

Bei der Aufgabenerfüllung bedienen sich die befragten Unternehmen unterschiedlicher Konzepte, Methoden und Werkzeuge. Diese wurden hinsichtlich ihres primären Verwendungszweckes in die Gruppen allgemeine Ordnungsinstrumente, Instrumente der Architektur-Dokumentation und -Planung sowie Instrumente der Architektur-Programmierung unterteilt. Im Folgenden werden die wichtigsten Instrumente dieser Gruppen kurz vorgestellt.

83 84 85

Beispielsweise wurden in einer Großbank im Jahr 2005 über 300 Projekte auf Architekturkonformität geprüft. So lag die Ausnahmequote in einer teilnehmenden Großbank im Jahr 2005 bei ca. 3%. Ein vergleichbares Institut nennt sogar eine Quote von ca. 20%. In Einzelfällen werden für Projektarbeit über 50% der Gesamtkapazitäten des Architekturmanagements allokiert.


4.2.6.1

71

Allgemeine Ordnungsinstrumente

Fast alle befragten Institute verwenden einen konzeptionellen Ordnungsrahmen (ArchitekturFramework) zur Strukturierung ihrer Aktivitäten sowie der jeweils erzeugten ArchitekturArtefakte (vgl. Abschnitt 2.2.2). Am weitesten verbreitet ist dabei eine Unterteilung nach Techniknähe in die Ebenen Businessarchitektur (Geschäftsstrategien, Unternehmensziele, Produkte, Prozesse, etc.), Anwendungsarchitektur (Anwendungen, Komponenten, Schnittstellen, etc.) und Infrastrukturarchitektur (Hardware, Betriebssysteme, Middleware, etc.). Der Schwerpunkt der Betrachtung liegt meist auf der Ebene der Anwendungsarchitektur. Die Businessebene wird oft nur insoweit einbezogen als dies für die darunterliegenden Ebenen von Bedeutung ist. Zum Teil werden auch weitere – zu den Hauptebenen orthogonale – Sichten verwendet. Gebräuchlich ist insbesondere die Betrachtung von Informations-, Integrations-, Sicherheits-, Entwicklungs- sowie Betriebsarchitekturen. Der gewählte Ordnungsrahmen bildet in der Regel die konzeptionelle Grundlage für die Architektur-Dokumentation und -Planung. Beim Einsatz eines Metadaten-Repositorys (siehe Abschnitt 4.2.6.2) determiniert er daher die Grobstruktur eines entsprechenden Metamodells. Auch Richtlinien und Standards werden typischerweise bestimmten Architekturebenen oder -sichten zugeordnet. Der Ordnungsrahmen dient darüber hinaus oft als Vorlage für die (Binnen-) Organisation des Architekturmanagements. So werden z. B. häufig Untergruppen oder Rollen nach den Elementen des Ordnungsrahmens definiert (z. B. ”Anwendungsarchitekt”, ”Technischer Architekt”). Unabhängig von dem verwendeten Ordnungsrahmen nehmen viele der befragten Unternehmen eine (vertikale) Segmentierung ihrer IT-Landschaft vor (9 Fälle). Die Segmente werden dabei in der Regel als Domänen bezeichnet.86 Die Domänenbildung erfolgt meist nach fachlichen Kriterien. Häufig zu finden sind Gliederungen nach Bankprodukten (z. B. Wertpapier, Bausparen) und Wertschöpfungsstufen (z. B. Vertrieb, Abwicklung). Teilweise werden auch mehrere und / oder mehrstufige Segmentierungen eingesetzt. Primäres Ziel der Domänenbildung ist die Komplexitätsbeherrschung. So werden die Domänen meist als Planungseinheiten verwendet, für welche separate Zielarchitekturpläne erstellt werden können. Weiterhin werden den einzelnen Domänen oft spezifische Richtlinien und Standards zugeordnet. Vor allem in großen Unternehmen wird ferner die Verantwortung für die Architekturkonformität häufig auf spezielle Mitarbeiter (bzw. Rollen) übertragen (”Domänenarchitekten”). Die Segmentierung bildet schließlich oft auch die Grundlage für eine

86

Im Jargon der Stadtplanungsmetapher ist hierfür auch der Begriff Quartier gebräuchlich.

72


technische Entkopplung der einzelnen Landschaftssegmente im Sinne einer Subsystembildung (siehe hierzu Abschnitt 4.2.7). 4.2.6.2

Instrumente der Dokumentation und Planung

Als Grundlage der Architektur-Dokumentation verwalten alle befragten Unternehmen strukturierte Daten über die Elemente und Beziehungen innerhalb ihrer IT-Makroarchitektur. Art und Umfang dieser Metadatenverwaltung unterscheiden sich dabei von Haus zu Haus. Am unteren Ende der Skala rangieren einfache – in der Regel isolierte – Verzeichnisse der im Einsatz befindlichen Systemelemente. So verfügen etwa alle teilnehmenden Institute über ein Inventar ihrer Anwendungssysteme. Dieses enthält in der Regel Angaben bzgl. Eigentümerschaft, Domänenzuordnung, Versionsnummer, Life-Cycle-Status, Technologie-Plattform oder Architekturkonformität. Zum Teil werden darüber hinaus auch Informationen auf der Ebene von Systemkomponenten, Schnittstellen und Nutzungsbeziehungen vorgehalten. Verbreitet sind außerdem Verzeichnisse der im Einsatz befindlichen Infrastrukturelemente. Das obere Ende der Skala bilden weitgehend integrierte Datenbestände unter Einbeziehung der Businessebene. Dabei werden insbesondere auch die Querbeziehungen zwischen den verschiedenen Architekturebenen erfasst (z. B. von Anwendungen unterstützte Unternehmensziele und Prozesse, verwendete Businessobjekte, genutzte Infrastrukturplattformen). Ferner können analog zur Ist-Situation Daten über zukünftige Szenarien sowie die Auswirkungen von Veränderungsprojekten verwaltet werden. Dieser Entwicklungsstufe lassen sich bislang allerdings nur wenige Institute zurechnen. Als Werkzeuge für die Metadatenverwaltung verwenden die Unternehmen in erster Linie Eigenentwicklungen. Dabei handelt es sich oft um relativ einfache Datenbankanwendungen. Kommerzielle Enterprise Architecture Tools87 sind dagegen bis jetzt kaum im Einsatz.88 Sie werden darüber hinaus nur selten voll ausgenutzt. Die Pflege der Dokumentationsbestände erfolgt in der Regel manuell. Nur wenige Häuser verfügen bisher über eine (teil-) automatisierte Datenversorgung. Als Datenquellen dienen dafür u. a. Entwicklungs-Repositorys und Systems-Management-Werkzeuge. Die verfügbaren Daten werden in unterschiedlicher Weise und je nach Leistungsfähigkeit der eingesetzten Werkzeuge für verschiedene Auswertungen und Analysen herangezogen.

87 88

Siehe hierzu z. B. Sebis (2005) oder James und Handler (2006). Als ein Grund hierfür werden u. a. zu hohe (nicht vertretbare) Lizenzkosten genannt.


73

Vertrieb

Produktion

Filiale 1274

Kredite und Einlagen

4587

PRO

1266

TED

1567

LNS 67778

Handel

4445

PAS

6689

ABA

AM 6720

MM

FOM

8877 6690

IMM

RAT

6730

FX

V3

Call Center 6699

6740

0978

CCC

BTS

Zahlungsverkehr 8890

9981

ZVS

4456

ASY

FBH

6690

SWI

WPS

Internet 2243

3344

PCP

CPC

Zentrale Services CRM 3365

Finance & Control

8675

GDM

7771

SAL

7772

FI

Risikomanagement 7733

CO

7734

RCM

HR 7745

RCC

HR

Abbildung 4.3: Cluster-Modell (stark vereinfacht)

Sie bilden dabei insbesondere die Ausgangsbasis für die Erstellung grafischer Architekturmodelle. Die meisten der befragten Unternehmen verwenden solche Modelle zur Visualisierung verschiedener Aspekte ihrer Ist- bzw. Soll-Architektur. Architekturmodelle stellen dabei nicht zuletzt auch ein wichtiges Mittel der Kommunikation gegenüber den verschiedenen Stakeholdern der IT-Architektur dar. Je nach Gegenstand und Zielgruppe kommen zum Teil sehr unterschiedliche Darstellungsformen zum Einsatz. Auf der Ebene der Anwendungsarchitektur stehen Cluster- und Matrix-Modelle im Vordergrund.89 Cluster-Modelle werden vor allem zur grafischen Repräsentation der bestehenden Domänenstruktur (s. Abschnitt 4.2.6.1) verwendet. Die einzelnen Informationssysteme werden dabei durch Rechtecke symbolisiert, welche räumlich zu Clustern gruppiert werden. Dabei sind mehrere Hierarchieebenen möglich.90 Zum Teil werden in den Modellen auch Schnittstellenbeziehungen zwischen den einzelnen Systemen dargestellt (z. B. durch Pfeilverbindungen). Weiterhin können durch Verwendung von Farbcodes zusätzliche Attribute

89 90

Matthes und Wittenburg (2004) verwenden hierfür den Oberbegriff ”Softwarekarten”. D. h. Cluster können wiederum in anderen Clustern enthalten sein.

74


Kundenbetreuung

1274

Analyse / Entscheidung

0978

8877

Ratenkredite

1266

7734

LNS

ABA

67778

Immobilienkredite

IMM

4587

Förderkredite

3344

RCC

1266

TED

CCC

8675

4445

LNS

ABA

6699

Sparprodukte

PAS

6699

Wertpapiere

Risikomanagement

4445

RAT

PRO

Geschäftsabwicklung

Geschäftsabschluss

CPC

SAL

6617

7733

BTS WPS RCM

6700

Fonds

V3

6720

FOM

Abbildung 4.4: Matrix-Modell (stark vereinfacht)

abgebildet werden (z. B. technische Plattform, Life-Cycle-Status, etc.). Ein Beispiel für ein Cluster-Modell ist in Abbildung 4.3 wiedergegeben. Matrix-Modelle91 erlauben eine strukturierte Darstellung von Anwendungslandschaften entlang von zwei nominal-skalierten Attribute-Dimensionen. Die einzelnen Informationssysteme werden hierzu ebenfalls in Form von Rechtecken symbolisiert. Im Unterschied zu Cluster-Modellen werden diese aber anhand ihrer spezifischen Merkmalsausprägung auf einer zweidimensionalen Matrix positioniert. Am weitesten verbreitet sind dabei unter den befragten Unternehmen Gliederungen nach unterstützten Prozess- bzw. Wertschöpfungsstufen einerseits sowie abgedeckten Bankprodukten andererseits. Zum Teil werden auf den Achsen durch Schachtelung auch weitere Dimensionen abgetragen (z. B. Vertriebskanäle). Außerdem können analog zu den Cluster-Modellen durch Verwendung von Farbcodes zusätzliche Attribute abgebildet werden (z. B. technische Plattform, Life-Cycle-Status).

91

Lankes et al. (2005) verwenden hierfür den Begriff ”Prozessunterstützungskarte”.


75

SAL

hoch

LNS

PAS IMM

Business Value

ABA

MM CCC WPS RAT

BTS

gering

GDM CO

CPC

FX PRO

FI

gering

HR

hoch Architekturkonformität

Abbildung 4.5: Portfolio-Modell (stark vereinfacht)

Matrix-Modelle bieten eine einfache Möglichkeit zur integrierten und leicht verständlichen Darstellung komplexer IT-Landschaften. Sie eignen sich dabei auch gut zur Analyse. So können z. B. bestehende Lücken oder Redundanzen aufgedeckt werden. Weiterhin ist ein Einsatz im Rahmen der Architektur-Planung möglich. Mit Hilfe entsprechende Modelle kann dabei der funktionale ”Zuschnitt” neu zu entwickelnder Systeme festgelegt werden.92 Ein Beispiel für ein Matrix-Modell ist in Abbildung 4.4 wiedergegeben. Weniger gebräuchlich sind im Architekturmanagement die klassischen Portfolio-Modelle (Cash et al., 1992).93 Auch hier werden Informationssysteme in einer zweidimensionalen Matrix (”Portfolio”) positioniert. Im Unterschied zu den dargestellten Matrix-Modellen werden dabei allerdings ordinale bzw. metrisch skalierte Dimensionen verwendet (z. B. Business Value vs. Architekturkonformität). Die Abbildung der einzelnen Systeme erfolgt hier in Form von Kreisflächen mit unterschiedlicher Größe und / oder Farbe. Darüber können zusätzliche Attribute abgebildet werden. Portfolio-Modelle eignen sich v. a. zur strategischen Analyse sowie zur Ableitung von entsprechenden Maßnahmenplänen. Ein Beispiel für ein Portfolio-Modell ist in Abbildung 4.5 dargestellt.

92 93

Diese Anwendung liegt u. a. auch der Methode Business Systems Planning (BSP) zugrunde. Diese werden stattdessen häufig im Rahmen des Portfoliomanagements eingesetzt (bezogen auf Projekte).

76


Zugangskanal

BeraterArbeitsplatz

InternetPlattform

VoicePortal

...

Infrastrukturdienste

Logging Kanalintegrations-

KanalIntegration

BusinessIntegration

Integrationskomponente komponente

Content Integration

Errorhandling

Vorgangs-

VorgangsKomponente Komponente

Geschäfts-

GeschäftsKomponente Komponente

Internationalisierung

BackendIntegration

IntegrationsBroker

Deployment

Autorisierung Integrations-

Backend

IntegrationsAdapter Adapter

Produktions-

ProduktionsSysteme Systeme

...

Abbildung 4.6: Graphenorientiertes Modell einer Referenzarchitektur (Dern, 2003, S. 195)

Innerhalb der übrigen Architekturebenen bzw. -sichten (technische Infrastruktur, Datenarchitektur, Integrationsarchitektur, etc.) überwiegen einfache, graphenorientierte Modelltypen. Die Systemelemente werden dabei in der Regel durch Rechtecke (oder Ellipsen) und die zwischen diesen bestehenden Beziehungen durch entsprechende Verbindungslinien (bzw. -pfeile) repräsentiert. UML94 oder spezielle Architektursprachen95 wie ACME (Garlan et al., 1997) oder ArchiMate (Lankhorst, 2005) kommen so gut wie nicht zum Einsatz. Nur in einer Minderheit der befragten Unternehmen werden Architekturmodelle bisher auch auf der Ebene der Mikroarchitektur verwendet. Das Architekturmanagement gibt dabei meist die zu erstellenden Sichten (Ergebnistypen) und / oder entsprechende Referenzmodelle vor.96 Die eigentliche Modellierung erfolgt dagegen normalerweise innerhalb der betreffenden Entwicklungsprojekte.97 Hierfür werden in der Regel ebenfalls überwiegend pragmatische, graphenorientierte Darstellungsformen verwendet. Probleme entstehen dabei aus Sicht der Teil-

94 95 96 97

Zum Einsatz von UML auf Architekturebene siehe z. B. (Medvidovic et al., 2002). Eine Übersicht findet sich z. B. in Medvidovic und Taylor (2000). Vgl. hierzu ausführlich Abschnitt 4.2.6.3. Z. B. durch einen IT-Mikroarchitekten. Dieser kann allerdings auch Teil der AM-Organisation sein, vgl. Abschnitt 4.2.5.


77

nehmer vor allem durch die notwendige Abstimmung zwischen Architektur- und DesignModellen und die damit verbundene Modell-Pflege. Ein Beispiel für ein graphenorientiertes Modell einer Referenzarchitektur für E-Business-Systeme ist in Abbildung 4.6 dargestellt. Als Modellierungswerkzeuge auf Makroebene verwenden die meisten Unternehmen einfache Tools wie MS Powerpoint oder Visio. Modellierung und Modellpflege erfolgen dabei in der Regel manuell. Die Ablage der Modelle geschieht meist in Form einer geordneten ”Lose-Blatt-Sammlung” auf einem File-Server.98 Nur in wenigen Fällen werden die Modelle der Makroarchitektur mit Hilfe der eingesetzten Metadaten-Repositorys bzw. Enterprise Architecture Tools erzeugt und verwaltet. 4.2.6.3

Instrumente der Architektur-Programmierung

Ein zentrales Instrument des Architekturmanagements stellen fast in allen befragten Unternehmen Architekturprinzipien dar (13 Fälle). Hierunter werden allgemeine Grundsätze und Verfahrensregeln verstanden, welche sowohl als Basis für die Arbeit des Architekturmanagements selbst als auch im Sinne verbindlicher Vorgaben für Entwicklungsprojekte (Architektur-Programmierung) genutzt werden. Die Prinzipien werden dabei oft über mehrere Hierarchieebenen operationalisiert. Durch ihre konsequente Anwendung können auch bei einer in hohem Maße verteilten System-Implementierung bestimmte Systemeigenschaften auf Makroebene sichergestellt werden. In Abbildung 4.7 sind beispielhaft einige typische Architekturprinzipien zusammengestellt. Die meisten Unternehmen verwenden weiterhin Standardkataloge (12 Fälle).99 Darin werden die im Rahmen der (Neu-) Entwicklung zulässigen Technologien und Produkte festgelegt. Durch den Einsatz von Standardkatalogen soll eine Begrenzung des Varietätswachstums erreicht und die Integrationsfähigkeit der eingesetzten Systemelemente gewährleistet werden. Inhaltlich werden Standardkataloge oft nach Diensteklassen unterteilt (z. B. Datenbanken, Betriebssysteme, Middleware). So kann etwa im Bereich Datenbanken der Einsatz relationaler Datenbankmanagementsysteme (oder auch konkreter Implementierungen wie z. B. DB2 6.0) vorgeschrieben werden. Zum Teil werden den einzelnen Standards auch unterschiedliche Verbindlichkeitsstufen zugeordnet (z. B. ”recommended”, ”strongly recommended”, ”must”). Ein Beispiel für einen Standard-Katalog ist in Abbildung 4.8 dargestellt.

98 99

In einem der befragten Institute erstrecken sich allein die Modelle der Infrastruktur-Architektur auf über 150 Powerpoint-Folien. Alternativ werden hierfür auch Bezeichnungen wie Mandatory Product List, Technology Portfolio oder Technology-Set verwendet.

78


ID

Prinzip

Beschreibung

1

Zentralisierung von Transaktionsdaten

Transaktionsdaten bilden die juristische Grundlage der Geschäftstätigkeit des Unternehmens und unterliegen einer hohen Änderungs-Frequenz. Sie werden daher grundsätzlich zentralisiert auf Mainframe-Umgebungen gespeichert.

2

Trennung von operativen und analystischen Daten

Transaktionssysteme und analytische Anwendungen verfügen über sehr unterschiedliche Anforderungen. Die Datenbestände werden daher in separaten Datenbanken vorgehalten.

3

ServiceOrientierung

Zur Erhöhung von Flexibilität und Wartbarkeit wird eine service-orientierte Strukturierung der Anwendungslandschaft angestrebt. Neue Anwendungen werden daher grundsätzlich service-orientiert ausgelegt. Dabei sind bestehende Dienste soweit wie möglich wiederzuverwenden.

4

Mehrsprachenfähigkeit

Die internationale Ausrichtung des Unternehmens erfordert den gleichzeitigen Einsatz von Systemen in unterschiedlichen Ländern. Neue Anwendungen werden daher grundsätzlich mehrsprachenfähig ausgelegt.

5

Mandantenfähigkeit

Die verfolgte Wachstumsstrategie erfordert eine flexible Integration unterschiedlicher juristischer Entitäten. Neue Anwendungen werden daher grundsätzlich mandantenfähig ausgelegt.

6

Integrationsplattform

Eine zentralisierte Systemintegration bildet die Grundlage für eine effiziente Entwicklung und Wartung von Schnittstellen. Neue Anwendungen werden daher einheitlich über eine zentrale Integrationsplattform verbunden.

Abbildung 4.7: Architekturprinzipien (Auszug)

Knapp die Hälfte der befragten Unternehmen nutzt weiterhin Referenzarchitekturen (6 Fälle). Hierunter werden vordefinierte Architektur-Vorlagen für bestimmte Systemklassen auf Mikroebene verstanden (z. B. Referenzarchitektur für Vertriebssysteme, Referenzarchitektur für Transaktionssysteme).100 Referenzarchitekturen beinhalten oft auch Verweise auf die im Rahmen der Implementierung einzusetzenden Standards. Sie werden häufig bestimmten Domänen zugeordnet und gelten dann für alle Entwicklungsprojekte innerhalb der Domäne bindend. Referenzarchitekturen ermöglichen eine Wiederverwendung von Strukturinformationen. Dies kann zu deutlichen Qualitäts- und Produktivitätssteigerungen führen. Darüber hinaus werden die Freiheitsgrade bei der Entwicklung neuer Anwendungen eingeschränkt. Referenzarchitekturen wirken daher ebenfalls standardisierend. In einigen Häusern werden durch das Architekturmanagement auch die einzusetzenden Entwicklungsmethoden und -werkzeuge vorgegeben und wiederverwendbare Komponenten bereitgestellt (z. B. bankfachliche Komponentenbibliotheken, Frameworks, etc.). Zum Teil werden diese zusammen mit Referenzarchitekturen, Prinzipien und Standards zu ganzen Standardplattformen verknüpft. Standardplattformen stellen aufeinander abgestimmte Bün-

100

Vgl. z. B. Heinrich und Lehner (2005, S. 58). Referenzarchitekturen gehen damit über einfache Architektur-Muster hinaus, welche lediglich ein Lösungsprinzip für konkrete Problemsituationen beschreiben.


79

Entwicklung Geschäftsmodellierung: Anforderungsanalyse: Design: Implementierung: Auslieferung: Umgebung: Projektmanagement: Konfigurationsmanagement: Testmanagement:

Allgemeine Services EAI: Data Warehouse: HTTP-Server: FTP-Server: Email-Server: Groupware: Webbrowser: Scheduling:

Security

WfM: Verzeichnisdienste: Namensdienste: Druckdienste: Plattenspeicher: Dokumentenmanagement: Backup: Reporting:

Middleware

Datenbankmanagement

Transaktionsmonitor: Applikationsserver: Messaging Service:

Client-DB: Server-DB: Host-DB:

Betriebssysteme Host:

UNIX-Server: Intel-Server:

Client:

Authorisierung: Authentifizierung: Virenschutz: Verschlüsselung: Firewall/VPN: Proxies/Gateways:

Systems Management SW-Monitoring/ Management: HW-Monitoring/ Management: Netzwerk-Monitoring/ Management: SW-Verteilung: Remote Control: User Help Desk:

Kommunikationssysteme Netzwerk: Telekommunikation: Fax-Dienste:

Abbildung 4.8: Standard-Katalog

del aus technischen Komponenten, Guidelines und Prozessen für Entwicklung und Betrieb von gleichartigen Anwendungen (z. B. Java-Plattform, Mainframe-Plattform) dar. Erklärtes Ziel ist dabei eine weitgehende Standardisierung von Entwicklungs- und Produktionsprozessen bei gleichzeitiger Ausrichtung auf die Architekturziele.101 4.2.7 Systemtechnische Gestaltungsziele Unter inhaltlichen Gesichtspunkten besteht die zentrale Herausforderung des Architekturmanagements in einer zielkonformen Gestaltung der IT-Makroarchitektur. Dazu können jeweils unterschiedliche systemtechnische Gestaltungsziele verfolgt werden (vgl. z. B. Penzel, 2004; Spitzer, 2005). Diese finden in der Regel ihren Niederschlag in den im Rahmen der Architektur-Leitplanung erstellten Architektur-Artefakten (s. Abschnitt 4.2.6). Die Mehrzahl der Studienteilnehmer verfolgt hier zunächst das Ziel einer stärkeren Modularisierung des Unternehmensinformationssystems (10 Fälle). So beabsichtigen viele der

101

So existierten etwa in einer teilnehmenden Großbank im Jahr 2005 fünf Standardplattformen, denen jedoch bisher nur etwa 60% aller Anwendungen zugeordnet werden können.

80


befragten Unternehmen, ihre IT-Landschaft gemäß der definierten Domänenstruktur in Subsysteme zu zerlegen und auf diese Weise zu entkoppeln.102 Hierzu werden Schnittstellen auf den Domänengrenzen definiert und die domänenübergreifende Kommunikation auf diese Domänenschnittstellen beschränkt.103 Auswirkungen von Systemveränderungen lassen sich so lokal begrenzen, wodurch die Wartbarkeit der IT-Landschaft steigt. Darüber hinaus wird auch ein vollständiger Austausch einzelner Anwendungen bzw. ganzer Domänen deutlich vereinfacht. Dies soll nach Aussage einiger Teilnehmer insbesondere auch die ITseitige Umsetzung strategischer Management-Entscheidungen (z. B. Verkauf von Unternehmensteilen, Mergers & Acquisitions) erleichtern. Hierbei können die Clustergrenzen dann im Idealfall als ”Sollbruchstellen” dienen. Das Prinzip der Modularisierung bzw. der Serviceorientierung findet auch über die Domänenentkopplung hinaus breite Anwendung. So werden in vielen Instituten zentrale Dienste definiert, welche von anderen Anwendungen und / oder Diensten genutzt werden können. Hierzu sollen die oft noch durch monolithische Silostrukturen gekennzeichneten Kernanwendungen weiter geöffnet und anderen Anwendungen bzw. Diensten zugänglich gemacht werden. Damit soll insbesondere die Wiederverwendung bestehender Funktionalitäten gefördert werden. Außerdem sollen auf diesem Wege ähnliche Daten und Funktionen zentralisiert und entsprechende Redundanzen in der Systemlandschaft abgebaut werden. Inhaltlich steht dabei häufig die Herstellung von Multikanal- und Mandantenfähigkeit im Vordergrund. Eng verbunden mit dem Konzept der Modularisierung ist die Ausbildung bestimmter Strukturtypen auf Makroebene. Aus systemtheoretischer Sicht geht es hierbei um die Art und Weise der funktionalen Kopplung (d. h. Integration) der einzelnen Systemelemente bzw. Subsysteme. So wird zunehmend auch auf Makroebene eine mehrschichtige Systemarchitektur angestrebt.104 Dabei werden u. a. die Schichten Präsentation, Geschäftslogik und Datenhaltung unterschieden. Ein typisches Beispiel hierfür bildet etwa der Einsatz von Portallösungen zur Integration heterogener Benutzerschnittstellen. Von besonderer Bedeutung ist weiterhin der Einsatz zentraler Integrationsinfrastrukturen zur Konsolidierung der Schnittstellenbeziehungen. Dabei ist ein klarer Trend zu einer prozessorientierten Integration festzustellen. Diese soll zusammen mit der Modularisierung des UIS zu einer höheren Flexibilität der IT beitragen.

102 103 104

Penzel (2004) und Spitzer (2005) sprechen in diesem Zusammenhang auch von sogenannten ”Building Blocks”. Dadurch wird eine Kapselung der Domänen erreicht. Die Schichtenbildung kann aus systemtheoretischer Sicht als eine Kombination von Subsystembildung und Reihenkopplung angesehen werden (vgl. Abschnitt 2.1.1).


81

Ein anderes wichtiges Gestaltungsziel bildet die Standardisierung von Systemkomponenten. So strebt eine Mehrheit der befragten Institute u. a. eine Reduktion der technischen Plattformen bzw. Plattformvarianten sowie eine Ablösung proprietärer Technologien durch offene Standards an (jeweils 8 Fälle). Einige Unternehmen planen darüber hinaus einen stärkeren Einsatz von Standardsoftware (6 Fälle). Aus systemtheoretischer Perspektive zielt die Standardisierung auf eine Reduktion der System-Varietät ab (vgl. Abschnitt 2.1). 4.2.8 Wirkungen Als bisher infolge der AM-Implementierung beobachtete Wirkung nennen sechs der befragten Unternehmen eine Reduktion der Komplexität ihrer IT-Landschaft. So konnten in einigen Fällen die Anzahl von Anwendungen, Schnittstellen und / oder Plattformen deutlich verringert werden. Hierzu wurden teilweise aber auch entsprechende Konsolidierungsprojekte durchgeführt. In anderen Häusern konnte nach Einschätzung der Interviewpartner immerhin eine Begrenzung des Komplexitätswachstums erreicht werden. Sechs Unternehmen berichten weiterhin über eine Senkung der IT-Kosten. So standen den durch das Architekturmanagement verursachten Zusatzkosten etwa in einem konkreten Fall entsprechende Einsparungen in zwei- bis dreifacher Höhe gegenüber (gerechnet über einen Zeitraum von fünf Jahren). In zwei anderen Häusern sind dagegen bisher vorwiegend zusätzliche Kosten entstanden. Dies wird einerseits auf Anlaufkosten (z. B. für die Nachdokumentation), andererseits aber auch auf Wirkungsverzögerungen zurückgeführt.105 Als Erfolg von Architekturmanagement wird außerdem häufig eine Erhöhung der Transparenz angegeben (6 Fälle). Eine Ursache hierfür ist in den durch das Architekturmanagement aufgebauten Dokumentationsbeständen zu sehen. In einigen Unternehmen konnte mit Hilfe des Architekturmanagements ferner eine Steigerung der Entwicklungseffizienz bzw. eine Reduktion der Durchlaufzeiten bewirkt werden (3 Fälle). Von einer Erhöhung der IT-Flexibilität wird hingegen nur in einem Fall explizit berichtet. Insgesamt fällt es den befragten Unternehmen schwer, konkrete Wirkungen des Architekturmanagements anzugeben. Zum einen wird hierfür der zurückliegende Wirkungszeitraum oft noch als zu kurz angesehen. So erwarten einige Teilnehmer nachhaltige Ergebnisse erst mit einer Wirkungsverzögerung von fünf bis zehn Jahren. Zum anderen haben die Unternehmen meist Schwierigkeiten bei der Messung des AM-Erfolges. Bei der großen Mehrheit

105

Aufgrund der Wirkungsverzögerungen können die Overheadkosten des Architekturmanagements in der Anfangsphase meist nicht kompensiert werden.

82


der befragten Institute wird daher bisher keine systematische Erfolgsmessung durchgeführt. In den anderen Fällen überwiegen einfache Kennzahlen (z. B. Anzahl technischer Plattformen, Anzahl wiederverwendbarer Services). Nur ein einziges Institut verfügt bisher über eine spezielle ”Architektur-Scorecard” (siehe hierzu Fallstudie A, Abschnitt 5.2). 4.2.9

Probleme

Architekturmanagement ist in der Praxis mit einer Vielzahl von Problemen behaftet. Schwierigkeiten haben die befragten Unternehmen – wie bereits dargestellt – vor allem bei der Erfolgsmessung. Probleme bereiten dabei neben den bestehenden Wirkungsverzögerungen auch die Operationalisierung der oft qualitativen Architekturziele sowie die effiziente Erhebung entsprechender Daten (zusammen 8 Nennungen). Darüber hinaus gibt es häufig Akzeptanzprobleme bei den von den Maßnahmen des Architekturmanagements betroffenen Stakeholdern (8 Nennungen). So wird die Regulation durch das Architekturmanagement z. B. innerhalb der Anwendungsentwicklung oft als unnötige Schikane empfunden. Dies ist einerseits auf ein fehlendes Architekturwissen, andererseits aber auch auf handfeste Interessenkonflikte zurückzuführen. Schließlich stehen die von einzelnen Entwicklungsprojekten verfolgten Partikularinteressen (nämlich der individuelle Projekterfolg) häufig im Widerspruch zu den globalen und langfristig orientierten Zielsetzungen des Architekturmanagements. Die Kombination aus regulatorischem (d. h. Individualinteressen beschneidendem) Eingriff einerseits und mangelndem (bzw. stark verzögertem) Erfolgsnachweis andererseits führt ferner häufig zu einem gewissen Legitimationsdruck auf das Architekturmanagement. Dies wird meist noch durch ein geringes Architekturverständnis auf Seiten des Managements sowie eine allgemeine Kultur der Kurzfristorientierung verstärkt (zusammen 8 Nennungen). Weitere Probleme werden von den befragten Unternehmen u. a. in einem relativ hohen Initialaufwand, ineffizienten Werkzeugen sowie mangelnden Ressourcen gesehen. Schwierigkeiten gibt es dabei insbesondere auch bei der Beschaffung qualifizierter Mitarbeiter. 4.2.10

Erfolgsfaktoren

Als wichtigen Erfolgsfaktor des Architekturmanagements nennen die meisten Interviewpartner eine intensive Zusammenarbeit mit der Entwicklungsebene und eine konsequente Praxisorientierung (insgesamt 9 Nennungen). Nach Ansicht vieler Teilnehmer spielt dabei neben umfangreicher Kommunikation (z. B. über Schulungen, Publikationen) vor allem auch


83

die konkrete Unterstützung von Entwicklungsprojekten eine wesentliche Rolle. Auf diese Weise kann die Akzeptanz der bestehenden Regularien verbessert werden. Außerdem kann das Architekturmanagement so Feedback-Informationen hinsichtlich der praktischen Umsetzbarkeit der definierten Ziel-Architekturen bzw. der Anwendbarkeit von Richtlinien und Standards aufnehmen. Dies ist eine wichtige Voraussetzung für die Sicherstellung des Praxisbezuges (”Bodenhaftung”). Als erfolgskritisch werden weiterhin ein pragmatischer und kompromissbereiter Umgang mit den von der Regulation betroffenen Stakeholdern (z. B. Projektleiter, Anwendungsentwickler) sowie eine moderate Restriktivität angesehen (7 Nennungen). So sollte die Entscheidungsfreiheit im Rahmen von Entwicklungsprojekten nicht über Gebühr eingeschränkt werden. In begründeten Fällen sollten zudem Ausnahmeregelungen getroffen werden. Im Falle einer Überregulation droht dagegen die Gefahr eines Akzeptanzverlusts sowie einer Umgehung des Architekturmanagements. Für unverzichtbar halten viele Teilnehmer ferner einen nachhaltigen Rückhalt durch IT- und Business-Management (7 Nennungen). Dieser stellt sich nach der Erfahrung einiger Gesprächspartner allerdings erst nach einem gewissen ”Leidensdruck” ein. Große Bedeutung wird in diesem Zusammenhang auch der richtigen Vermittlung des bisherigen Erfolges zugemessen (3 Nennungen). Hierzu können etwa entsprechende Kennzahlensysteme eingesetzt werden. Akzeptanzfördernd wirkt nach Ansicht einiger Teilnehmer weiterhin die integrierte Betrachtung der Business-Architektur. Hierdurch kann die Funktion des Architekturmanagements insbesondere gegenüber der Fachbereichsseite deutlich aufgewertet werden. Als wichtige Erfolgsfaktoren werden weiterhin eine angemessene Ressourcenausstattung und Organisation des Architekturmanagements angesehen (3 Nennungen). Hierbei gilt insbesondere die Existenz eines eigenen Architekturteams als erfolgskritisch. Dieses sollte über ein eigenes Budget und die Möglichkeit zur Durchführung von Architekturprojekten verfügen.106 Daneben sollten alle ”Key Player” im Unternehmen über Architekturboards oder ähnliche Gremien in die relevanten Architekturentscheidungen eingebunden werden. Empfohlen werden weiterhin eine Konzentration auf die wesentlichen Aspekte und die Realisierung schneller Anfangserfolge (3 Nennungen). Für wichtig erachtet werden außerdem eine hinreichende Mitarbeiterqualifikation (4 Nennungen) sowie ein effizienter Werkzeugeinsatz (2 Nennungen). Als entscheidende Faktoren gelten dabei v. a. die Verwendung eines zentralen Repositorys sowie eine weitgehende Automatisierung der Datenversorgung.

106

Anderenfalls wird empfohlen, möglichst viele Architekturthemen in regulären Projekten ”unterzubringen”.

84

4.3


Zwischenfazit

Architekturmanagement ist unter den befragten Instituten bereits weit verbreitet. Es ist dabei fast in allen Häusern als eigenständige Funktion etabliert und institutionalisiert. Gleichwohl stellt es eine relativ junge Disziplin dar, deren Entwicklung noch nicht abgeschlossen ist. So unterscheiden sich die jeweiligen Ansätze zum Teil erheblich. Mögliche Ursachen hierfür können in einem differierenden Architekturverständnis sowie in unterschiedlichen Ausgangssituationen und Rahmenbedingungen der jeweiligen Institute gesehen werden.107 Hinzu kommt, dass bisher keine allgemein anerkannten Referenzmodelle und Methodologien zum Architekturmanagement existieren. Die Mehrheit der befragten Unternehmen verfolgt mit dem Architekturmanagement primär effizienz- und / oder flexibilitätsbezogene Ziele. Im Hinblick auf die wahrgenommenen Aufgaben und die eingesetzten Instrumente ist eine Orientierung an der Methodik der Stadtplanung weit verbreitet. Architekturmanagement umfasst daher in der Regel deutlich mehr als die reine Definition von Architekturstandards. Im Mittelpunkt steht vielmehr eine ganzheitliche und zukunftsorientierte Steuerung des Unternehmensinformationssystems. Hierzu kommen – unabhängig von aktuellen Modethemen wie EAI oder SOA – zunehmend systemtechnische Konzepte ”im Großen” zum Einsatz (z. B. Modularisierung, Entkopplung). Eine wichtige Rolle spielt weiterhin die strukturierte Dokumentation der IT-Makroarchitektur mit Hilfe von Metadaten-Repositorys. Erste Erfolge in den befragten Unternehmen deuten darauf hin, dass die Implementierung eines unternehmensweiten Architekturmanagements zur Lösung der bestehenden Probleme beitragen kann. Dies gilt vor allem im Hinblick auf ein nachhaltiges Komplexitäts- und Kostenmanagement. Oft ist hierfür aber der Wirkungszeitraum noch zu kurz. Für ein tieferes Verständnis der zugrundeliegenden Wirkungsmechanismen sind daher weitere Untersuchungen notwendig.

4.4

Einschränkungen

Die vorliegende Studie ist mit einer Reihe von Einschränkungen verbunden, welche bei der Interpretation der Ergebnisse zu beachten sind. So liegt der Untersuchung aufgrund des gewählten Auswahlverfahrens keine repräsentative Stichprobe zugrunde. Die Ergebnisse können daher nicht ohne weiteres verallgemeinert werden. Ferner ist davon auszugehen, dass

107

Z. B. im Hinblick auf die Komplexität der IT-Landschaft oder die bestehende Wettbewerbsdynamik.

Einschränkungen

85

aufgrund der beschränkten Gesprächsdauer sowie der Offenheit der Fragen nicht alle relevanten Informationen aufgenommen werden konnten. Darüber hinaus sind Verzerrungen aufgrund von subjektiver Informationsfilterung möglich. Ein besonderes Problem ergibt sich zudem aus der Abhängigkeit von den individuellen Aussagen bzw. Einschätzungen der jeweiligen Interviewpartner. Dies beinhaltet nicht zuletzt das Risiko eines auf positive Außendarstellung bedachten Antwortverhaltens.

Kapitel 5

Fallstudien

Im vorangegangenen Kapitel wurde die Praxis des Architekturmanagements auf der Grundlage einer qualitativen Expertenbefragung untersucht. Der Fokus lag dabei auf einer möglichst breit angelegten Erfahrungsaufnahme. Um ein tieferes Verständnis über die unterschiedlichen Möglichkeiten bei der Implementierung von Architekturmanagement sowie deren jeweilige Effektivität zu erhalten, wurde im Anschluss an die Vorstudie eine vertiefende Fallstudienuntersuchung durchgeführt. Dazu wurden drei ausgewählte Unternehmen einer ganzheitlichen, detaillierten Analyse unterzogen. Die Ergebnisse dieser Untersuchung sind Gegenstand des vorliegenden Kapitels. Im nächsten Abschnitt wird zunächst kurz auf die Methodik bei der Studiendurchführung eingegangen. Anschließend werden die drei Fälle ausführlich vorgestellt. Es folgt eine Interpretation der Fälle hinsichtlich der erzielten Erfolge bzw. Misserfolge. Im Rahmen einer vergleichenden Analyse werden abschließend einige verallgemeinernde Schlussfolgerungen gezogen. Diese bilden eine wichtige Grundlage für die Entwicklung von Hypothesen in Kapitel 6.

88

5.1

Fallstudien

Methodik

Das Ziel von Fallstudienuntersuchungen besteht allgemein darin, die konkrete Situation eines oder weniger ausgewählter Forschungsobjekte in ihrem jeweiligen Gesamtkontext darzustellen und zu analysieren. Die Betrachtungsweise ist dabei typischerweise partikularisierend und sehr detailliert (Stake, 1995, S. 1, S. 39f, S. 63f.; Yin, 2002, S. 13). Der vorliegenden Untersuchung wurde ein holistisches Multi-Case-Design zugrundegelegt. Dabei wurden drei Unternehmen betrachtet und pro Fall jeweils eine ganzheitliche Analyse durchgeführt (vgl. Yin, 2002, S. 39ff.). Die Auswahl der Fälle orientierte sich – ausgehend von der vorhandenen Teilnahmebereitschaft – an der Unterschiedlichkeit der verfolgten Ansätze. Hierdurch sollte eine möglichst große methodische Vielfalt abgedeckt werden. Die Grundlage der Auswahlentscheidung bildeten entsprechend die Ergebnisse der Vorstudie und die darüber aufgebauten persönlichen Kontakte.108 Zur Gewährleistung einer hohen Validität und Reliabilität wurden bei der Studiendurchführung mehrere Erkenntnisquellen verwendet (Yin, 2002, S. 97ff.). Diese bilden die Grundlage für die Durchführung einer Datentriangulierung. Im vorliegenden Fall wurden hierzu folgende Erhebungsmethoden eingesetzt: • ein strukturiertes Experteninterview (aus der Vorstudie) • ein offenes Experteninterview • eine schriftliche Befragung (Vorversion des Fragebogens aus der Hauptstudie) • Analyse interner Unternehmensdokumente • Analyse existierender Veröffentlichungen Den Ausgangspunkt bildete das Experteninterview aus der Vorstudie.109 Darauf aufbauend wurde jeweils ein zweites offenes Interview durchgeführt.110 Die Dokumentation erfolgte auch hier in Form eines Gedächtnisprotokolls.111 Zur Qualitätssicherung wurde darüber hinaus eine Abstimmung der Protokolle mit den jeweiligen Interviewpartnern vorgenommen.112

108 109 110 111 112

So entstammen zwei der drei Unternehmen aus der Gruppe der Vorstudienteilnehmer (Fall A und C). Dieses musste für Fall B nachgeholt werden. In den Fällen A und B wurde dieses Interview auf zwei Einzeltermine verteilt. Dies stellt nach Stake keinen Nachteil dar, wenn das Protokoll direkt nach dem Interview angefertigt wird (Stake, 1995, S. 66). Im Fall C musste aufgrund terminlicher Engpässe seitens des Interviewpartners auf eine detailliertere Abstimmung verzichtet werden.

Unternehmen A: eine internationale Universalbank

89

Eine weitere Datenquelle bildete die Beantwortung eines schriftlichen Fragebogens durch die jeweiligen Interviewpartner. Hierbei handelte es sich um eine Vorversion des in Kapitel 6 eingesetzten Instrumentes. Schließlich wurden auch verschiedene interne Unternehmensdokumente sowie öffentlich zugängliche Publikationen ausgewertet. Zur Erhöhung der Studien-Reliabilität wurde weiterhin eine sogenannte Fallstudien-Datenbank aufgebaut (Yin, 2002, S. 102). Diese bildet die Grundlage für eine Trennung zwischen den erhobenen Rohdaten einerseits und den darauf aufbauenden Beschreibungen und Analysen andererseits. Im Rahmen der vorliegenden Untersuchung wurden hierzu Protokolle der durchgeführten Interviews erstellt. Diese wurden zusammen mit den Ergebnissen der schriftlichen Befragung sowie allen sonstigen Dokumenten in strukturierter Form abgelegt. Zur Wissenskonsolidierung wurde darüber hinaus eine verbale Übersichtstabelle erzeugt, in der die wesentlichen Daten aus den unterschiedlichen Quellen integriert wurden (vgl. hierzu Miles und Huberman, 1994, S. 428f.). Ein Auszug dieses Datenspeichers ist in Tabelle 5.1 wiedergegeben. Die Analyse der Fälle erfolgte sowohl deskriptiv als auch explorativ (s. z. B. Yin, 2002, S. 22, S. 30). Jeder Fall wurde dazu zunächst für sich genommen analysiert und ganzheitlich beschrieben (siehe Kapitel 5.2 bis 5.4). Dabei wurde jeweils eine einheitliche Struktur zugrundegelegt. So wurden zu jedem Fall die unternehmensspezifischen Rahmenbedingungen (Kontext), der gewählte Ansatz der AM-Implementierung sowie die Entwicklung der ITArchitektur nachgezeichnet. Im Anschluss an die deskriptive Analyse erfolgte eine interpretative Beurteilung der Fälle im Hinblick auf die erzielten Wirkungen. Auch hier wurden die Fälle zunächst einzeln betrachtet. Den letzten Schritt bildete eine vergleichende Analyse zur Ableitung entsprechender Schlussfolgerungen.

5.2 Unternehmen A: eine internationale Universalbank Bei Unternehmen A handelt es sich um eine traditionsreiche europäische Universalbank mit internationaler Ausrichtung. Der Konzern ist derzeit in den Geschäftsfeldern Private Banking, Investment Banking und Asset Management tätig. Er beschäftige mehr als 50.000 Mitarbeiter und verfügt über eine Bilanzsumme von über 750 Mrd. EUR. Unternehmen A gehört damit zu den 15 größten Banken der Welt.

90

Fallstudien

5.2.1

Rahmenbedingungen

In Unternehmen A werden im Wesentlichen alle IT-Leistungen selbst erstellt. Dies gilt sowohl für die Anwendungsentwicklung als auch für den Betrieb. Lediglich die Betreuung der Arbeitsplatzrechner einschließlich der Telekommunikationseinrichtungen wurde auf einen externen Dienstleister übertragen. Im Rahmen der Anwendungsentwicklung wird außerdem zum Teil mit Offshore-Partnern zusammengearbeitet. Die IT-Funktion von Unternehmen A gliedert sich in fünf Hauptbereiche. Von diesen ist je einer für die Anwendungen der drei Hauptgeschäftsfelder zuständig. Daneben gibt es einen Bereich Shared Services für Geschäftsfeld-übergreifende Anwendungen (z. B. Human Resources). Die Einheit Infrastructure schließlich ist für die Arbeitsplatzausstattung und den Rechenzentrumsbetrieb verantwortlich. Jeder der fünf IT-Bereiche verfügt über einen eigenen CIO mit Strategieverantwortung sowie einen CTO mit Architekturverantwortung (Matrixorganisation). Darüber hinaus gibt es je einen globalen Konzern-CIO und -CTO. Die Analyse im Rahmen der vorliegenden Fallstudie konzentriert sich auf den für das Geschäftsfeld Private Banking zuständigen IT-Bereich. Dieser verfügt über eine komplexe ITLandschaft mit über 750 Anwendungen. Gleichzeitig herrscht eine hohe Änderungsdynamik. So werden in der Regel mehrere hundert Änderungsprojekte gleichzeitig durchgeführt. Insgesamt arbeiten hieran kontinuierlich über 1.000 Entwickler. 5.2.2

Implementierung des Architekturmanagements

Unternehmen A verfügt über ein institutionalisiertes Architekturmanagement. Dieses ist analog zur Struktur der IT-Funktion in fünf weitgehend unabhängige AM-Bereiche113 unterteilt, welche organisatorisch jeweils dem korrespondierenden IT-Bereich zugeordnet sind. Die Analyse im Rahmen der vorliegenden Fallstudie beschränkt sich auf das Architekturmanagement des Geschäftsfeldes Private Banking (nachfolgend AM-A). Dieses nimmt im Gesamtkonzern eine Vorreiterrolle ein und erbringt daher zum Teil auch Leistungen für die anderen Geschäftsfelder. Konzeptionelle Grundlage des AM-A bildet das in Abbildung 5.1 dargestellte ArchitekturFramework. Dieses unterscheidet zwischen einer Anwendungsebene und einer technischen Ebene. Darüber hinaus werden die orthogonalen Sichten Integration Architecture, Securi-

113

Für die Zukunft ist hier eine stärkere Integration geplant. Dies äußert sich aktuell in Bestrebungen zur Vereinheitlichung der Governance-Prozesse sowie im kürzlich vollzogenen Aufbau einer globalen CTO-Organisation.


91

Application Application Architecture Architecture IntegraIntegration tion ArchiArchitecture tecture

Security Security ArchiArchitecture tecture

Technical Technical Architecture Architecture

Systems Systems ManageManagement ment ArchiArchitecture tecture

Architecture Architecture Process Process

Abbildung 5.1: Architektur-Framework Fall A

ty Architecture sowie Systems Management Architecture betrachtet. Weiterhin findet eine fachliche Unterteilung der Anwendungslandschaft in ca. 20 Domänen statt. Dabei werden unterschiedliche Kriterien für die Abgrenzung verwendet. Wichtige Domänen sind z. B. ”Customers” (Kunden), ”Channels” (Zugangskanäle), ”Credits” (Kredite) oder ”Payments” (Zahlungsverkehr). Diese bilden die Grundlage für ein föderatives Management der Anwendungsarchitektur (vgl. Abschnitt 5.2.2.1). 5.2.2.1

Organisation

Zentrales Element des AM-A ist der Organisationsbereich ”IT Architecture”. Dieser ist gemäß der Struktur des eingesetzten Ordnungsrahmens (vgl. Abbildung 5.1) in die sechs Untergruppen Application Architecture, Technical Architecture, Integration Architecture, Security Architecture, Systems Management Architecture und Architecture Process untergliedert. Die fünf erstgenannten Organisationseinheiten sind dabei für die jeweiligen Architekturinhalte zuständig. Die Einheit Architecture Process hingegen kümmert sich um den übergreifenden Architekturprozess und nimmt entsprechende Querschnittsaufgaben wahr. Insgesamt sind im Bereich IT Architecture ca. 40 Mitarbeiter beschäftigt. Darüber hinaus gibt es innerhalb der Anwendungsentwicklung sogenannte Domänenarchitekten. Diese sind jeweils für die Architekturkonformität der von ihnen betreuten Domänen (vgl. Abschnitt 5.2.2.3) verantwortlich. Die Domänenarchitekten werden durch den Leiter der Gruppe Application Architecture koordiniert (föderative Organisation). Hierzu finden alle zwei bis drei Monate entsprechende Treffen statt.

92

Fallstudien

Neben der Primärorganisation umfasst das AM-A eine Reihe von übergreifenden Gremien. Zu nennen ist hier zunächst das sogenannte ”Steering Committee IT Architecture (STC)”. Das STC ist für Entscheidungen über die Architekturentwicklung zuständig. In diesem Gremium werden insbesondere alle Architekturkonzepte, Standards, Guidelines und Roadmaps verabschiedet. Es beinhaltet Repräsentanten aller IT-Bereiche sowie ausgewählter Fachbereiche. Der Anteil der IT-Fachkräfte beträgt ca. 95%.114 Das STC tagt in einem zweimonatlichen Rhythmus. Daneben existiert das sogenannte ”Project Review Board”. Aufgabe dieses Gremiums ist die Konformitätsprüfung von Entwicklungsprojekten. Das Project Review Board beinhaltet dazu Repräsentanten aller relevanten IT-Bereiche (u. a. Architektur, Produktion, Entwicklung). Fachbereichsvertreter sind hier nicht vertreten. Um die Beteiligung der Fachbereiche zu erhöhen, wird außerdem einmal jährlich ein sogenanntes ”Sponsor-Meeting” organisiert. Ziel dieses Treffens ist es, eine Einigung unter den Fachbereichsvertretern über die zukünftige Aufteilung des Entwicklungsbudgets auf die verschiedenen Domänen. Dies soll insbesondere die Kommunikation zwischen den Fachbereichen fördern und ein schnittstellenübergreifendes Denken fördern. Zur aktiven Architektur-Implementierung können weiterhin spezielle Architekturprojekte durchgeführt werden. Diese werden häufig zu ganzen ”Architekturprogrammen” zusammengefasst. Architekturprogramme umfassen in der Regel ca. 10-15 Einzelprojekte und besitzen eine Laufzeit von etwa drei Jahren. Zur Steuerung von Architekturprogrammen wird jeweils ein sogenannter ”Programmsteuerungsausschuss” eingerichtet. 5.2.2.2

Aufgaben

Das AM-A verfügt über ein generisches Prozessmodell mit den vier Teilprozessen bzw. Aufgabengebieten Architektur-Entwicklung, Architektur-Kommunikation, Architektur-Implementierung sowie Architektur-Controlling. Der Teilprozess Architektur-Entwicklung beinhaltet die Festlegung (bzw. Änderung oder Eliminierung) von Architekturelementen wie Domänen, Richtlinien und Standards. Darüber hinaus wird ein umfassendes Technologiemanagement betrieben. Hierzu gehören etwa die Beobachtung neuer und die systematische Ablösung veralteter Technologien (”Phase-Out”).

114

Der Beteiligungsgrad der Fachbereiche war ursprünglich höher. Aufgrund des fehlenden technischen Know-Hows sowie mangelnder Kapazitäten haben diese sich jedoch mehr und mehr zurückgezogen.


93

Ebenfalls dem Bereich Entwicklung zugerechnet wird der Aufbau der notwendigen Infrastrukturen. Entsprechende Entscheidungen werden durch das STC getroffen. Zur Entscheidungsvorbereitung können verschiedene Assessments, Pilottests, etc. durchgeführt werden. Der Teilprozess Architektur-Kommunikation beinhaltet die Information der betroffenen Stakeholder über die geltenden Architekturvorgaben sowie über entsprechende Veränderungen. Hierzu gibt es einerseits eine Online-Dokumentation (”Architektur-Web”).115 Darüber hinaus werden einmal im Monat spezielle Informations-Events veranstaltet, an denen jeweils rund 150 Teilnehmer aus der Anwendungsentwicklung teilnehmen. Diese freiwilligen Veranstaltungen sollen in Zukunft durch entsprechende Pflichtschulungen ergänzt werden. Der Teilprozess Architektur-Implementierung umfasst zunächst den operativen Projekt-Support. Hierzu nehmen Mitarbeiter des AM-A aktiv in entsprechenden Projekten teil. Für die Projektarbeit werden insgesamt rund 25% der verfügbaren Gesamtkapazitäten des AM-A eingesetzt (dies entspricht ca. 10 MAK). Pro Jahr können auf diese Weise zwischen 50 und 100 Projekte aktiv begleitet werden. Die betreffenden Projekte werden dabei in der Regel durch das AM-A selbst ausgewählt. Teilweise wird auch aus den Projekten heraus eine entsprechende Unterstützung angefordert. Ein zweites wichtiges Element der Architektur-Implementierung bilden Projekt-Reviews. Hierbei handelt es sich um einen formalisierten Prozess zur Prüfung von Projekt-Ergebnissen. Dieser muss von allen im betreffenden IT-Bereich durchgeführten Projekten zu bestimmten Meilensteinen durchlaufen werden (100%-Abdeckung). Projekte können sich dazu alle zwei Wochen für ein Review anmelden und ihre Ergebnisse einreichen. Diese werden dann innerhalb von zehn Tagen geprüft (Zusage seitens des Architekturmanagements). Dabei wird ein Review-Bericht erstellt, über welchen anschließend im Project Review Board entschieden wird. Der Review-Prozess wird von der Gruppe ”Architecture Process” geführt. Hierfür wird ein standardisiertes Dokument eingesetzt, welches jeweils von den verschiedenen Architektur-Bereichen (Application Architecture, Technical Architecture, Integration Architecture, etc.) abzuzeichnen ist. Im Falle der Nichtkonformität wird den Projekten die Abnahme verweigert. Falls es anschließend zu keiner Einigung kommt, wird eine informelle Klärung auf Bereichsleiterebene gesucht. In ca. 2-3% aller Fälle müssen hier auch entsprechende Kompromisse seitens des AM-A in Kauf genommen werden.

115

Diese ermöglicht u. a. eine interaktive Navigation durch das bestehende Architektur-Framework inklusive DrillDown-Funktionalität.

94

Fallstudien

Der Teilprozess Architektur-Controlling schließlich befasst sich mit der Gewinnung und Aufbereitung von Daten zur Messung und Bewertung des AM-Erfolges. Das Aufgabenfeld befindet sich allerdings noch im Aufbau. Bisher erfolgt hier eine Konzentration auf ”bekannte und leicht zugängliche Messpunkte”. Zeit- und Ressourcen- bzw. Kosten-basierte Kennzahlen werden dabei durch die Größe ”Use Case Points (UCP)” (in Analogie zu Funktion Points) relativiert und so vergleichbar gemacht (z. B. Entwicklungstage pro UCP). Projekte müssen hierzu jeweils die Anzahl der erzeugten UCPs angeben. Die gemessenen Kennzahlen werden in einem speziellen Kennzahlensystem zusammengefasst. Dieses wird derzeit zu einer umfassenden Architektur-Scorecard (nach dem Vorbild der Balanced Scorecard) weiterentwickelt. Die Architektur-Scorecard beinhaltet u. a. Kennzahlen zur Messung der übergeordneten Ziele IT-Effizienz (z. B. ”Maintenance Costs per UCP”) und IT-Flexibilität (z. B. ”Time-to-Market in days per UCP”). Hinzu kommen systemtechnische Zustandsgrößen wie der Grad der Wiederverwendung von Services (”Ratio of reused Service Interfaces”) oder der Anteil der auf Standard-Plattformen betriebenen Anwendungen (”Average Reuse per public Service Interface”). Darüber hinaus werden interne Steuerungsgrößen wie etwa die Architekturkonformität von Projekten (Anteil der architekturkonformen Projekte pro Kalenderjahr) oder die Prozessleistung des Architekturmanagements (z. B. durchschnittliche Review-Dauer) betrachtet. 5.2.2.3

Instrumente

Ein wesentliches Steuerungsinstrument des AM-A bilden die ”IT Architecture Principles”. Hierunter werden bindende Regeln verstanden, denen sämtliche Design-, Konstruktions- und Änderungsaktivitäten genügen müssen.116 Entsprechende Prinzipien werden für alle Bereiche des Architektur-Frameworks definiert. So sollen etwa auf der Ebene der Anwendungsarchitektur die sogenannten ”Application Landscape Architecture Principles” das Design und die Weiterentwicklung der Anwendungslandschaft steuern. Jedes Prinzip adressiert dazu eine gewünschte Qualitätseigenschaft. Wichtige Prinzipien betreffen etwa die Vermeidung von Datenredundanz, die Verwendung von Architekturmustern oder die Mandantenfähigkeit der Anwendungen. Auf der technischen Ebene steht dagegen die Definition von Standards für die von den Anwendungen zu nutzende Infrastruktur im Vordergrund. Auch die technische Landschaft wird hierzu in Teilsegmente untergliedert. Diese sogenannten ”Technical Domains” (z. B. ”Data

116

Die Konformität sollte dabei stets überprüfbar und nach Möglichkeit auch direkt messbar sein.


95

Management and Databases”, ”Development Environments”) beinhalten jeweils Standardkataloge für spezifische Infrastruktur-Funktionalitäten. Hierbei gilt der Grundsatz, dass für jede notwendige Funktionalität möglichst nur eine Technologie eingesetzt werden soll (”minimales Technologie-Portfolio”). So ist z. B. festgelegt, dass für die Datenhaltung nur relationale (und in Ausnahmefällen hierarchische), nicht jedoch objektorientierte Datenbanksysteme eingesetzt werden dürfen. Weiterhin werden alle zulässigen Hersteller-Produkte aufgeführt. Zusammen bilden die Technical Domains das sogenannte ”Technology Portfolio”. Auf der Basis des Technology Portfolios ist darüber hinaus eine Menge sogenannter ”Application Platforms” definiert. Eine Application Platform umfasst dabei aufeinander abgestimmte technische Komponenten, Prozesse und Guidelines für Entwicklung und Betrieb eines bestimmten Anwendungstyps. Zurzeit existieren fünf solche Plattformen: • Mainframe Transaction Batch • Java Application Platform • Data Warehouse • Enterprise Resource Planning • Hosting Light Bestandteil der Plattformen sind auch entsprechende Referenzarchitekturen für die Anwendungsentwicklung. So enthält etwa die Java Application Plattform eine Referenzarchitektur für Java-basierte Client-Server-Anwendungen. Hierbei werden verschiedene sogenannte ”Towers” (z. B. für komplexe Internet-Anwendungen oder einfache HTML-Anwendungen) unterschieden. Außerdem werden durch die Application Platforms standardisierte Integrationsmechanismen vorgegeben. Um die Synergieeffekte bei Entwicklung und Betrieb von Anwendungen zu erhöhen, sollen in Zukunft möglichst viele Anwendungen auf einer der vordefinierten Plattformen implementiert werden. Ein wichtiges Instrument des AM-A ist weiterhin das sogenannte ”Applikationsportfolio”. Hierbei handelt es sich um eine eigenentwickelte Datenbankanwendung zur Verwaltung sämtlicher Anwendungen des betrachteten Unternehmensbereiches (Anwendungsverzeichnis). Im Applikationsportfolio werden u. a. Daten bzgl. der Domänenzuordnung oder der Architekturkonformatität der verschiedenen Systeme hinterlegt. Das Applikationsportfolio dient dabei auch als Datenbasis für die Messung von Architektur-Kennzahlen. Neben dem

96

Fallstudien

Applikationsportfolio existiert weiterhin eine sogenannte ”Service-Datenbank”. In dieser werden alle bestehenden Services verwaltet (vgl. hierzu Abschnitt 5.2.3). Dazu werden sowohl fachliche Beschreibungen als auch die entsprechenden technischen Schnittstellen-Bindungen hinterlegt. Grafische Auswertungen werden durch die genannten Verzeichnisse nicht direkt unterstützt. Entsprechende Darstellungen werden daher bei Bedarf manuell erstellt (z. B. Übersicht der einzelnen Domänen, Security-Architektur einer Domäne, etc.). Hierbei kommen keine besonderen Architektursprachen zum Einsatz. Als Werkzeug dient ein einfaches Office-Tool. Die Ablage der erzeugten Dokumente erfolgt mit Hilfe von MS Sharepoint. Weitere Instrumente des AM-A bilden eine ausführliche Dokumentation über die Aufgaben und das Selbstverständnis des AM-A sowie ein entsprechender Glossar. 5.2.2.4

Zielsetzung

Leitprinzip des AM-A ist das Konzept der ”Managed Evolution”. Das übergeordnete Ziel des Architekturmanagements besteht demnach darin, einen vernünftigen Ausgleich zwischen dem Wertbeitrag der IT (”Business Value”) und der IT-Effizienz zu finden. Ein wichtiges Teilziel besteht dabei neben einer nachhaltigen Senkung der operativen IT-Kosten vor allem in der Erhöhung der Änderungsflexibilität. Besondere Aufmerksamkeit wird in diesem Zusammenhang der Anpassung an organisatorische Veränderungen (Aufbauorganisation, Geschäftsprozesse), der Mandantenfähigkeit (Nutzung der IT-Plattform durch mehrere juristisch unabhängige Gesellschaften), der Mehrstaatenfähigkeit (Nutzung der IT-Plattform aus unterschiedlichen Ländern heraus) sowie der Multikanalfähigkeit (Nutzung der IT-Plattform über unterschiedliche Zugangskanäle) entgegengebracht. Ein weiteres Ziel besteht darin, den Fachbereichen neue Geschäftsmöglichkeiten aufzuzeigen (”Enabler-Funktion”). Zur Erreichung dieser übergeordneten Ziele werden unterschiedliche systemtechnische Gestaltungsziele verfolgt. Von besonderer Bedeutung ist dabei die Modularisierung (”Componentization”) der IT. Hierzu wird bereits auf der Ebene der Anwendungsdomänen eine weitgehende Trennung und Entkopplung von Subsystemen angestrebt (vgl. hierzu Abschnitt 4.2.7). Ein anderes wichtiges Gestaltungsziel stellt die Reduktion der Varietät dar. Dabei stehen eine Reduktion der technischen Plattformen bzw. Plattformvarianten sowie eine Ablösung proprietärer Technologien durch offene Standards im Vordergrund. Auf der Anwendungsebene wird außerdem in bestimmten Bereichen ein stärkerer Einsatz von Standardsoftware angestrebt.


97

5.2.3 Historische Entwicklung und erzielte Ergebnisse Ende der 1990er Jahre stellte sich die Situation in Unternehmen A wie folgt dar: Nach mehreren Fusionen und Übernahmen bestand die Notwendigkeit zu entsprechenden Integrationsund Restrukturierungsmaßnahmen. Dabei kam es aufgrund einer mangelnden Transparenz bzgl. der Ist-Situation zu einem starken Anwachsen der System-Komplexität. Die Folgen hiervon waren eine abnehmende Flexibilität, ein hoher Änderungsaufwand selbst bei unwesentlichen Systemänderungen, hohe Wartungs- und Betriebskosten sowie eine schlechte Integration der neu entstandenen E-Business-Anwendungen. Als Reaktion auf diese Situation wurde vor ca. zehn Jahren das AM-A ins Leben gerufen.117 Nach eingehender Prüfung der strategischen Optionen wurde dabei das Leitprinzip der ”Managed Evolution” zugrundegelegt. Als primäres Gestaltungsziel wurde die Modularisierung bzw. Serviceorientierung gewählt. Hiermit sollten insbesondere Plattformen und fachliche Applikationsgruppen besser entkoppelt werden. Weiterhin sollten Redundanzen abgebaut und die technische Heterogenität reduziert werden. So wurde u. a. das Ziel verfolgt, die Zahl der Einzelanwendungen um 70% zu verringern. Neben der Etablierung eines ArchitekturProzesses für die passive Architektur-Implementierung wurden hierzu seit der Gründung des AM-A auch mehrere Architektur-Programme durchgeführt. Inhaltlich wurde das AMA kontinuierlich weiterentwickelt. So wurde etwa im Jahr 2002 die föderative DomänenOrganisation eingeführt. Der aktuelle Status-Quo ist etwa seit 2004 gültig. Bis heute konnten durch das AM-A eine Reihe von Erfolgen erzielt werden. Als kurzfristiger Effekt wird vor allem eine deutlich gestiegene Transparenz bzgl. der IT angeführt. Als mittel- bis langfristige Wirkung wird weiterhin über eine messbare Senkung der IT-Komplexität berichtet. Inzwischen ist insbesondere die Standardisierung der technischen Plattformen weit fortgeschritten. Darüber hinaus konnte die Modularisierung bzw. Serviceorientierung schrittweise erhöht werden. Hierzu wurde ein Großteil der traditionellen Großrechneranwendungen angepasst. Heute sind bereits ca. 850 Services im Einsatz. Dies entspricht etwa 50% der Gesamtfunktionalität. Grundlage der Service-Orientierten-Architektur ist eine zentrale Service- und Workflow-Infrastruktur auf Basis von CORBA (”Enterprise Integration Bus”). Darüber wird inzwischen die gesamte Inter-Domänen-Kommunikation abgewickelt (”Managed Interfaces”). Eine Integration von Datenbeständen findet hingegen nicht statt. Trotzdem ist über die Service-Architektur eine integrierte Sicht auf alle Kundendaten gegeben.

117

Die Zahl der beschäftigten Mitarbeiter stieg in den ersten Jahren der Gründung auf die heutige Zahl und ist seitdem in etwa konstant geblieben.

98

Fallstudien

Mithilfe der ergriffenen Maßnahmen konnten die IT-Gesamtkosten gesenkt werden. Darüber hinaus konnte auch die Time-to-Market bei Neuentwicklungen reduziert werden. Dies kann anhand von Kennzahlen belegt werden. Der Aufbau des AM-A wird daher insgesamt als eine erfolgreiche Investition angesehen.

5.3

Unternehmen B: eine internationale Automobilbank

Unternehmen B ist ein Tochterunternehmen eines international tätigen Automobilkonzerns. Als globaler Finanzdienstleister bietet es eine breite Palette an Finanzierungslösungen für die vom Konzern vertriebenen Personen- und Nutzfahrzeuge. Unternehmen B konzentriert sich dabei auf die globale Koordination und zentrale Bereitstellung von Dienstleistungen und Produktlösungen für die in über 40 Ländern agierenden Tochterunternehmen (sogenannte Landesgesellschaften). Es beschäftigt über 10.000 Mitarbeiter und verfügt über eine Bilanzsumme von knapp 100 Mrd. EUR. 5.3.1

Rahmenbedingungen

Die IT-Funktion des Mutterkonzerns ist in vier Sparten unterteilt, welche einem globalen IT-Management unterstehen. Drei dieser Sparten sind jeweils für die Anwendungen eines bestimmten Konzernbereiches zuständig. Die vierte Sparte kümmert sich dagegen um die konzernweite Bereitstellung von Hardware-Infrastruktur und Netzwerken sowie um den ITBetrieb. Die IT-Funktion von Unternehmen B ist innerhalb einer der erstgenannten Sparten angesiedelt. Sie umfasst über 1.500 Mitarbeiter. In das fachliche Aufgabengebiet fallen dabei neben Finanzanwendungen auch Anwendungen aus den Bereichen Marketing, Sales und Aftersales. Die IT-Funktion ist in mehrere Unterbereiche gegliedert. Hierzu gehören einerseits die für die Anwendungsentwicklung zuständigen Organisationseinheiten (sogenannte ”Supplier”). Diesen stehen mehrere Bereiche mit regionaler IT-Verantwortung gegenüber (sogenannte ”Demander”), über welche die einzelnen Landesgesellschaften repräsentiert werden. Hinzu kommt der für Querschnittsaufgaben zuständige Bereich ”Planning & Governance”. Unternehmen B verfügt über eine sehr komplexe IT-Landschaft mit ca. 1.000 Anwendungssystemen. In den Betreuungsbereich der betrachteten IT-Funktion fallen darüber hinaus nochmal rund 2.000 Anwendungen aus den Bereichen Marketing, Sales und Aftersales. Im Hinblick auf die Leistungserstellung wird eine gemischte Sourcingstrategie verfolgt. Auf


99

der Anwendungsebene wird dazu zwischen Differentiation- und Commodity-Systemen unterschieden.118 Letztere sollen mittel- bis langfristig durch Standardsoftware ersetzt und ausgelagert werden. Im Bereich der Anwendungsentwicklung findet außerdem ein zunehmendes Offshoring statt. Auf der Ebene der IT-Infrastruktur sind heute bereits wesentliche Teile ausgelagert. 5.3.2 Implementierung des Architekturmanagements Unternehmen B verfügt über ein institutionalisiertes Architekturmanagement. Vergleichbare Funktionsbereiche existieren auch in zwei weiteren Konzern-IT-Sparten. Die verschiedenen AM-Bereiche sind dabei jedoch als weitgehend unabhängig anzusehen. Die vorliegende Fallstudie konzentriert sich daher auf das Architekturmanagement von Unternehmen B (nachfolgend AM-B). Konzeptionelle Grundlage des AM-B ist ein Ordnungsrahmen bestehend aus den drei Architekturdimensionen Business Architecture, Technology Architecture119 und Information Architecture (”Drei-Säulen-Modell”). Weiterhin werden die vier Domänen Finanzdienste, Marketing, Sales und Aftersales unterschieden. Der Zustand der verschiedenen Domänen ist dabei unterschiedlich weit entwickelt. Im Rahmen der vorliegenden Fallstudie wird aus Gründen der Vergleichbarkeit ausschließlich der Bereich Finanzdienste betrachtet. 5.3.2.1

Organisation

Zentrales Element des AM-B ist das Team ”Enterprise Architecture Management (EAM)”. Dieses ist organisatorisch dem Bereich ”Planning & Governance” zugeordnet. Das EAMTeam umfasst derzeit sieben Mitarbeiter. Darüber hinaus existieren in den einzelnen Ländergesellschaften verschiedene EAM-Koordinatoren, welche für die dezentrale Umsetzung der Architekturvorgaben verantwortlich sind. Neben der Primärorganisation gibt es eine Reihe von Gremien mit architekturbezogenen Aufgabenstellungen. Hierzu zählt zunächst das sogenannte ”Architektur-Council”. Dieses noch im Aufbau befindliche Gremium ist für Entscheidungen bezüglich der IT-Strategie und der IT-Makroarchitektur zuständig. Hier werden insbesondere Standards und Bebauungsplä-

118 119

Unter Differentiation-Systemen werden Anwendungssysteme verstanden, die eine wahrnehmbare Differenzierung aus Kundensicht ermöglichen. Anderenfalls wird von Commodity-Systemen gesprochen. Technology Architecture beinhaltet nach diesem Ansatz sowohl die technische Infrastruktur als auch die Anwendungsebene.

100

Fallstudien

ne verabschiedet. Das Gremium besteht aus Vertretern der verschiedenen IT-Bereiche und IT-Experten mit Fachfunktion. Die Einbindung des EAM-Teams ist bisher noch nicht geklärt. Das Architektur-Council tagt zehnmal im Jahr. Von Bedeutung für das AM-B ist weiterhin das sogenannte ”Project-Management-Council (PM-Council)”. Hierbei handelt es sich um ein übergreifendes Gremium zur Projektsteuerung und -koordination. Im PM-Council wird insbesondere über die Projektanträge von Demandern entschieden. Es umfasst unterschiedliche Stakeholder u. a. aus Fachbereichen, Anwendungsentwicklung und IT-Controlling. Auch das EAM-Team ist in diesem Gremium vertreten und erhält von dort sämtliche Projektanträge zur Architektur-Konformitätsprüfung (s. Abschnitt 5.3.2.2). Das PM-Council tagt einmal im Monat. Des Weiteren existieren unregelmäßig zusammentreffende Austauschkreise zur Koordination und Abstimmung mit den anderen AM-Bereichen im Konzern (z. B. mit dem Infrastrukturbereich). Gegenstand der Treffen sind die gegenseitige Information und ggf. die gemeinsame Erarbeitung von Vorlagen. Eine aktive Architektur-Implementierung über Architekturprojekte findet in Unternehmen B nicht statt. Die Budget-Ausstattung des EAM-Teams wird jedoch insgesamt als ausreichend empfunden. 5.3.2.2

Aufgaben

Eine wichtige Teilaufgabe des AM-B bilden die Architektur-Dokumentation und -Planung. Im Rahmen der Dokumentation erfolgt eine systematische Erhebung, Ablage und Pflege der Ist-Architektur in einem speziellen Architektur-Repository (EAM-Tool). Darauf aufbauend wird eine fünfjährige sowie eine einjährige Bebauungsplanung durchgeführt. Dabei wird jeweils die Zielarchitektur auf grob-granularer Ebene festgelegt. Das EAM-Team fungiert im Rahmen der Dokumentation und Planung jeweils als zentrale Koordinationsstelle. Es gibt hierzu insbesondere die entsprechenden Strukturen (Metamodell ”Base Information Set”, BIS) und Werkzeuge (EAM-Tool) vor. Inhaltlich liegt die Verantwortung dagegen bei den jeweiligen Landesgesellschaften.120 Deren Mitwirkung basiert dabei bisher auf einer freiwilligen Selbstverpflichtung. So nimmt aktuell nur etwa die Hälfte der Landesgesellschaften aktiv an den Dokumentations- und Planungsprozessen teil. Für diese Gesellschaften sind alle Anwendungen im EAM-Tool erfasst und auf der Detailebe-

120

Hierfür sind die genannten EAM-Koordinatoren zuständig.


101

ne des BIS dokumentiert. Die Dokumentationsbestände sind darüber hinaus einmal jährlich zu aktualisieren.121 Für die übrigen Gesellschaften sind bisher nur die wichtigsten Anwendungen im System abgelegt. Die System-Nutzung sowie entsprechende Datenerfassungen finden hier auf freiwilliger Basis statt. Eine weitere wichtige Aufgabe des AM-B besteht in der Definition von Prinzipien (”Guidelines”) und Standards. Entsprechende Entscheidungen werden vom Architektur-Council getroffen. Darüber hinaus werden insbesondere technische Standards aber auch durch den zentralen Infrastruktur-Bereich vorgegeben. Eine zentrale Aufgabe des AM-B liegt ferner in der Sicherstellung der ”EAM-Compliance”. Das EAM-Team wird hierzu aus dem PM-Council heraus mit entsprechenden ProjektKonformitätsprüfungen beauftragt. Diese beziehen sich sowohl auf inhaltliche als auch auf formale Aspekte. In formaler Hinsicht wird insbesondere Umfang und Form der Dokumentation geprüft (”Existiert eine ganzheitliche Architekturbeschreibung?”, ”Ist der Projektgegenstand gemäß den Vorgaben im EAM-Tool modelliert?”). Inhaltlich wird eine Kontrolle bezüglich der Verträglichkeit des Projektgegenstandes mit den geltenden Standards und Prinzipien, der Ist-Landschaft und den allgemeinen IT-Zielen durchgeführt. Nach Abschluss der Prüfung erfolgt eine Rückmeldung an das PM-Council in Form eines Gutachtens. Das Gesamturteil sieht dabei drei Stufen nach dem Prinzip einer Ampel vor (rot: massive Verstöße, gelb: leichte Verstöße, grün: volle Konformität). Die letztendliche Entscheidung über die zu treffenden Maßnahmen liegt beim PM-Council. Ein Projekt kann daher auch bei schlechter Architekturkonformität genehmigt bzw. weitergeführt werden, wenn dies politisch gewollt ist.122 Der Anteil entsprechender Fälle liegt derzeit bei etwa 30%. Als sonstige Aufgaben des EAM-Teams können die (Weiter-) Entwicklung der Methodik und Tools sowie die Definition der Regelprozesse (Metaaufgaben) genannt werden. Darüber hinaus erfolgt ein operativer Projektsupport. Das EAM-Team sieht sich dabei in erster Linie als Berater und Kommunikator. 5.3.2.3

Instrumente

Zentrales Instrument des AM-B bildet ein integriertes EAM-Tool. Dieses basiert auf einer leistungsfähigen Standardsoftware, welche durch intensives Customizing an die speziellen Bedürfnisse von Unternehmen B angepasst wurde.

121 122

Dieses Intervall soll in Zukunft verkürzt werden. Das neu gegründete Architektur-Council verfügt hier allerdings über ein Veto-Recht.

102

Fallstudien

Konzeptionelle Grundlage der Architektur-Dokumentation und -Planung innerhalb des EAM-Tools ist das sogenannte ”Base Information Set (BIS)”. Hierbei handelt es sich um ein Metamodell, welches Struktur und Inhalte der zu erfassenden Datenobjekte definiert. Das BIS unterscheidet dazu insgesamt zwölf Kategorien aus den drei Dimensionen Business-, Technik- und Informationsarchitektur (Drei-Säulen-Modell). Auf Basis dieses Ordnungsrahmens werden zu jeder Anwendung u. a. die unterstützten Geschäftsprozesse und Business-Funktionen (Business-Architektur), die genutzten Geschäftsdaten und Informationsflüsse (Informations-Architektur) sowie die Anwendungs-Komponenten und Plattformen (Technik-Architektur) erfasst. Geschäftsprozessdaten können dabei aus dem für das Geschäftsprozessmanagement eingesetzten Werkzeug importiert werden. Auf der Grundlage des BIS bietet das EAM-Tool umfassende Möglichkeiten zur Auswertung und Analyse der Ist-Architektur. Grundsätzlich lassen sich die Zusammenhänge zwischen allen Kategorien des BIS beliebig visualisieren. Über interaktive Verknüpfungen kann dabei durch unterschiedliche Sichten navigiert werden. So lässt sich zum Beispiel aus der Darstellung ”Alle Anwendungen einer IT-Plattform” auf die Detailebene einer einzelnen Anwendung wechseln (”Drill-Down”). Für diese Anwendung können dann im nächsten Schritt z. B. die nutzenden Organisationseinheiten angezeigt werden. Weitere typische Auswertungen beziehen sich auf die von einer Organisationseinheit bzw. einem Geschäftsprozess genutzten Anwendungen, die von einer Anwendung verwendeten Datenobjekte oder den Fluss von Datenobjekten durch die IT-Landschaft. Neben der Analyse der Ist-Architektur unterstützt das EAM-Tool auch die Planung der ZielArchitektur im Rahmen der Bebauungsplanung. So lassen sich für alle Elemente des BIS beliebige zukünftige Zustände entlang einer Zeitachse erfassen. Dies ermöglicht die Betrachtung unterschiedlicher Szenarien (”What-If-Analysen”). Außerdem wird hierdurch die Voraussetzung für ein systematisches Lifecycle-Management geschaffen. Zur Unterstützung der Architektur-Planung werden darüber hinaus zusätzliche Informationen bezüglich Strategien, Zielen und ”Demands” (aus Zielen abgeleiteter Änderungsbedarf) im EAM-Tool abgelegt und entsprechend verknüpft. Ferner ist die Durchführung von Soll-Ist-Vergleichen bzw. Gap-Analysen möglich. Ein weiteres Instrument des AM-B stellen Architekturprinzipien dar. Hierbei können zwei Ebenen unterschieden werden. Die erste Ebene bezieht sich auf das Architekturmanagement selbst (Meta-Ebene) und umfasst z. B. Modellierungskonventionen. Die zweite Ebene adressiert die entsprechenden Architekturinhalte. Diese sind in Form der sogenannten ”Guiding


103

Principles” definiert. Hierbei handelt es sich um relativ allgemeine Regeln für den Umgang mit Informationstechnologie. Darüber hinaus gibt es in den Entwicklungsbereichen spezifische Richtlinien. Relevant sind weiterhin entsprechende Vorgaben des konzernweiten Infrastruktur-Bereiches. Referenzarchitekturen werden in Unternehmen B nur in Form eines ”Best-Practice-Transfers” verwendet. So werden etwa Architekturmuster, die sich in einer Region (Landesgesellschaft) bewährt haben, auf andere Regionen übertragen. Häufiger werden Referenzarchitekturen im Bereich Infrastruktur eingesetzt. Weitere Instrumente bilden eine standardisierte Anwendungs-Zielarchitektur (”Strategic Target Landscape”) sowie ein entsprechender Prozesskatalog (”Prozesshaus”). Ferner existiert ein Standardkatalog für Fremdsoftware. Dieser ist bisher jedoch noch vergleichsweise umfangreich. Der Standardkatalog wird ebenfalls mit Hilfe des EAM-Tools verwaltet. 5.3.2.4

Zielsetzung

Die primäre Zielsetzung des AM-B liegt in einer Verbesserung der IT-Effizienz. Daneben ist v. a. die Erhöhung bzw. Erhaltung der IT-Flexibilität von Bedeutung. Diese wird aber nur als Mittel zur nachhaltigen Sicherstellung der Effizienz angesehen. Zur Erreichung dieser übergeordneten Ziele werden verschiedene Gestaltungsziele verfolgt. Hierzu zählt zunächst der Abbau von Redundanzen durch die Reduktion von Anwendungen und eine entsprechende Zentralisierung. Darüber hinaus sollen Standard-Leistungen weiter ausgelagert werden. Dies gilt vor allem für nicht differenzierende Anwendungen (Commodities). Weitere Gestaltungsziele bilden die Erhöhung der Wiederverwendung, eine prozessorientierte Integration sowie die Gewährleistung der Datenintegrität. Hierzu wird ein Wandel hin zu Service-Orientierten-Architekturen angestrebt. Konkret wird dies jedoch nur im Rahmen von Neuentwicklungen umgesetzt. Eine Roadmap für eine systematische Systemreorganisation existiert bisher nicht. Ein weiteres wichtiges Ziel des AM-B kann in der Erhöhung der Transparenz gesehen werden. Hierüber soll insbesondere die Strategiekonformität überprüft bzw. das strategische Alignment sichergestellt werden.

104

5.3.3

Fallstudien

Historische Entwicklung und erzielte Ergebnisse

Aufgrund der dezentralen Organisation sowie als Folge von Fusionen und Übernahmen ist in Unternehmen B im Laufe der Jahre eine sehr komplexe und heterogene IT-Landschaft entstanden. Die Systeme der verschiedenen Landesgesellschaften haben sich dabei weitgehend autonom entwickelt. Heute existieren ca. 1.000 Anwendungen alleine im Bereich Financial Services. Darunter befinden sind mehrere hundert Großanwendungen mit einem Alter von zum Teil über 20 Jahren. Darüber hinaus verfügt Unternehmen B über zahlreiche lokale Data-Warehouse- und CRM-Lösungen. Als Reaktion auf diese Entwicklung wurde vor ca. zweieinhalb Jahren das EAM-Team gegründet.123 Zu diesem Zeitpunkt wurde auch das EAM-Tool eingeführt. Damit wurden innerhalb der letzten Jahre wesentliche Teile der IT-Architektur dokumentiert. Darüber hinaus wurde ein entsprechender Planungsprozess aufgesetzt. Außerdem wurden im Sinne einer passiven Architektur-Implementierung entsprechende Projekt-Reviews durchgeführt. Das EAM-Team wurde vor kurzem um das Architektur-Council ergänzt. Die durch das AM-B erzielten Wirkungen sind bisher begrenzt. Als kurzfristiger Effekt wird insbesondere eine deutlich wahrnehmbare Steigerung der IT-Transparenz angegeben. Dies kann im Wesentlichen auf die generierten Dokumentationsbestände im EAM-Tool zurückgeführt werden. Die erhöhte Transparenz ist sowohl im Rahmen der Vorhabenplanung als auch im operativen Geschäft von Nutzen (Projektunterstützung, Reporting). Allerdings konnte aufgrund der unterschiedlichen Akzeptanz in den verschiedenen Ländergesellschaften bis heute nur ein Teil der Ist-Architektur erfasst werden. Eine darüber hinausgehende Wirkung auf die IT-Architektur ist bis jetzt nur in Ansätzen erkennbar. So hat sich der Standardisierungsgrad innerhalb der letzten zweieinhalb Jahre leicht erhöht. Außerdem ist der Anteil der auf zentralen Plattform betriebenen Anwendungen geringfügig gestiegen. Die angestrebte Serviceorientierung der Anwendungslandschaft ist bisher nur Rahmen von Neuentwicklungen realisiert worden. Ein Reengineering von Altsystemen wurde nicht durchgeführt. Der Anteil service-orientierter Anwendungen ist daher vergleichsweise klein. Ein zentraler Integrationsbus (”Enterprise Service Bus”) befindet sich noch in der Entstehungsphase. Dieser wird zudem schwerpunktmäßig nur bei Neuentwicklungen eingebunden.

123

Die Zahl der beschäftigten Mitarbeiter ist seitdem linear von zwei auf sieben angestiegen.

Unternehmen C: ein nationaler IT-Dienstleister

105

5.4 Unternehmen C: ein nationaler IT-Dienstleister Unternehmen C ist ein europäischer IT-Dienstleister für kleine und mittelgroße Kreditinstitute. Es bietet seinen Mandanten als Komplettanbieter ein Anwendungs- und Dienstleistungsportfolio für die Abwicklung des gesamten Bankgeschäftes. Dies schließt sämtliche IT-Dienstleistungen von der Entwicklung und Bereitstellung von Anwendungen über die Beratung und Schulung bis hin zum Rechenzentrumsbetrieb ein. Das Unternehmen betreut derzeit über 200 Mandanten. Diese verfügen über eine gemeinsame Bilanzsumme von über 750 Mrd. EUR. Unternehmen C ist vor einigen Jahren aus einer Fusion mehrerer IT-Dienstleister hervorgegangen und beschäftigt heute über 2.000 Mitarbeiter. 5.4.1 Rahmenbedingungen Unternehmen C verfügt über eine Matrixorganisation. Dabei wird einerseits nach den bei den Mandanten zu unterstützenden Bankbereichen Vertrieb, Abwicklung und Banksteuerung, andererseits nach den internen Wertschöpfungsstufen Anwendungsentwicklung, Produktion, Vertrieb und Portfoliomanagement unterschieden. IT-Leistungen werden im Wesentlichen selbst erstellt. Zusatzleistungen außerhalb der definierten Kernkompetenzen werden zum Teil auch extern zugekauft. Dies gilt sowohl für die Anwendungsentwicklung als auch für die Produktion. Zentrales Produkt von Unternehmen C ist eine integrierte Gesamtbanklösung (nachfolgend System-C genannt). System-C deckt alle Anforderungen einer mittelgroßen, regional operierenden Universalbank ab. Es verfügt über ein offenes Schnittstellenkonzept und erlaubt damit die Einbindung von externen Lösungen.124 Intern besteht das System aus mehreren hundert Einzelanwendungen. Dabei basieren rund 80% der Funktionalität auf Eigenentwicklungen. Auf Basis von System-C werden heute über 60 Millionen Konten verwaltet. 5.4.2 Implementierung des Architekturmanagements Unternehmen C verfügt über ein institutionalisiertes Architekturmanagement (nachfolgend AM-C genannt). Dabei wird jedoch bewusst ein ”leichtgewichtiger” Ansatz verfolgt. So wird insbesondere weitgehend auf eine Primärorganisation verzichtet. Dies wird mit negativen Erfahrungen in einem der Vorgängerinstitute von Unternehmen C begründet. Dort existierte bis vor etwa zehn Jahren ein umfangreiches Architekturteam. Dieses wurde jedoch

124

Dies wird auch für die Zukunft als ein wesentlicher Erfolgsfaktor angesehen.

106

Fallstudien

als zu restriktiv und praxisfern empfunden und nach zunehmenden internen Widerständen schließlich aufgelöst. Konzeptionelle Grundlage des AM-C bildet ein Ordnungsrahmen bestehend aus den drei Ebenen Bankfachliche Architektur, Anwendungsarchitektur sowie Systemarchitektur. Mit der Entwicklungsarchitektur existiert darüber hinaus eine orthogonale Sicht. Die verschiedenen Architekturen werden dabei als Rahmenwerke für die erfolgreiche Bereitstellung von IT-Komponenten und Instrument zur Operationalisierung der IT-Strategie angesehen. Eine Domänenbildung findet nicht statt. 5.4.2.1

Organisation

In Unternehmen C existiert keine reguläre Organisationseinheit für das Architekturmanagement im engeren Sinne. Im Mittelpunkt des AM-C steht stattdessen das sogenannte ”Architekturboard”. Aufgabe des Architekturboards ist die Steuerung der Architekturentwicklung sowie die Kontrolle der Entwicklungsvorhaben auf Architekturkonformität. Es verfügt hierzu insbesondere über ein Vetorecht. Das Architekturboard ist unmittelbar der Geschäftsleitung unterstellt. In ihm sind alle relevanten Geschäftsbereiche von Unternehmen C mit ständigen Mitgliedern vertreten.125 Jedes Mitglied vertritt dabei die Interessen seines eigenen Geschäftsbereiches. Das Architekturboard umfasst zurzeit knapp 20 Mitglieder. Durch die ausschließliche Besetzung mit Stakeholdern (”Leute aus dem echten Leben”) soll der von früher her bekannten ”Elfenbeinturmbildung” entgegengewirkt werden. Das Board tagt regulär in einem zweimonatigen Rhythmus. Zu gegebenem Anlass sind darüber hinaus zusätzliche Treffen möglich. Neben dem Architekturboard existiert außerdem der sogenannte ”Anwendungsplanungsausschuss”. Dieses mit Unternehmensvertretern und Vertretern der Mandanten besetzte Gremium ist für die Ausarbeitung des ”Masterplanes” zuständig. Darin werden die fachlichen Entwicklungsschwerpunkte und Budgets für die nächsten drei Jahre festgelegt. Eine Konkretisierung des Masterplanes erfolgt anschließend in den sogenannten ”Bebauungsplänen”.126 Eine wichtige Rolle kommt weiterhin dem Team ”Basisinfrastruktur” zu. Dieses ist organisatorisch einem spezifischen Geschäftsbereich von Unternehmen C zugeordnet. Das Team Basisinfrastruktur ist u. a. für die Bereitstellung und Verwaltung der Entwicklungskompo-

125 126

Die Ernennung der Mitglieder erfolgt jeweils direkt durch die Geschäftsleitung. Diese werden von Großprojektteams ausgearbeitet und ebenfalls vom Anwendungsplanungsausschuss verabschiedet.


107

nenten und -werkzeuge zuständig. Hierzu zählen insbesondere eine standardisierte Entwicklungsumgebung sowie das zentrale Repository (s. Abschnitt 5.4.2.3). Für die Pflege und Weiterentwicklung des Repositorys existiert darüber hinaus noch das sogenannte ”Repository-Board”. Dieses hat den Zweck, die Anwendungsentwickler an der Weiterentwicklung des Repositorys zu beteiligen und so die Akzeptanz des Systems zu steigern. Zur aktiven Architektur-Implementierung können außerdem spezielle Architekturprojekte durchgeführt werden. Die Beauftragung erfolgt hierbei durch das Architekturboard. Für entsprechende Vorhaben stehen in der Regel jedoch nur unzureichende Mittel zur Verfügung. Eine Transformation der IT-Architektur kann daher im Regelfall nur über den Weg der fachlichen Anforderung realisiert werden. 5.4.2.2

Aufgaben

Primäre Aufgabe des Architekturboards ist die Steuerung und Koordination der Weiterentwicklung von Anwendungs-, System- und Entwicklungsarchitektur. Das Board kann hierzu entsprechende Aufträge vergeben. Es ist weiterhin für die Dokumentation und Veröffentlichung zuständig. Das Architekturboard prüft darüber hinaus die Architekturkonformität von Entwicklungsprojekten. Hierfür wird ein zweistufiges Verfahren eingesetzt. So ist bereits vor dem KickOff die Architekturboard-Relevanz des geplanten Vorhabens zu klären. Der zuständige Projektleiter hat hierzu Kontakt mit dem entsprechenden Architekturboard-Vertreter seines Geschäftsbereiches aufzunehmen. Diese Vorgehensweise ist für sämtliche Projekte verpflichtend (100%-Abdeckung) und wird von der Revision geprüft (”Pflichtergebnistyp”). Architekturboard-relevante Projekte müssen sich anschließend im Architekturboard vorstellen. Im weiteren Verlauf sind die fachliche Spezifikation und das Systemmodell mit dem Architekturboard abzustimmen. Das Gremium hat schließlich ein Unterschrifts- bzw. Vetorecht im Freigabeprozess. In Streitfällen kann eine Eskalation über die Geschäftsführung erfolgen. Der Anteil der gewährten Ausnahmen liegt bei unter 5%. Änderungen der Architekturvorgaben werden in der Regel von den antragstellenden Projekten vorbereitet und anschließend dem Architekturboard zur Entscheidung vorgelegt. Durch diese Vorgehensweise soll eine schnelle und flexible Reaktion auf neue Anforderungen ermöglicht werden.

108

Fallstudien

Als Aufgabe des AM-C kann im weiteren Sinne auch die Bereitstellung von wiederverwendbaren Entwicklungskomponenten sowie die Verwaltung der entsprechenden Entwicklungstools einschließlich Repository durch das Team Basisinfrastruktur angesehen werden. 5.4.2.3

Instrumente

Zentrale Instrumente des AM-C sind zunächst eine standardisierte Arbeitsumgebung für die Anwendungsentwicklung (integrierte Entwicklungsumgebung) sowie das Repository. Die Entwicklungsumgebung beinhaltet neben den üblichen Funktionen unter anderem ein Konfigurationsmanagement für projektspezifische Anpassungen sowie verschiedene Test- und Codeanalysen. Sie erzwingt zudem den Einsatz der vorgegebenen Entwicklungsmethoden und Standards. Das zentrale Repository ermöglicht eine strukturierte Ablage sämtlicher Anwendungskomponenten von den Bildschirmmasken über die dahinterstehenden bankfachlichen Funktionen bis hin zu den zugrundeliegenden Datenstrukturen. Darüber hinaus werden hier Betriebsdaten, Protokolle, Testergebnisse sowie Angaben zu den jeweils verursachten Kosten hinterlegt. Das Repository schafft damit die Voraussetzungen für eine konsequente Wiederverwendung von Komponenten und die erfolgreiche Implementierung einer Service-Orientierten-Architektur (SOA). Inhaltlich liegt der Schwerpunkt bisher auf den serviceorientierten Anwendungen (insbesondere aus dem Bereich Vertrieb). Viele Alt-Anwendungen sind dagegen noch nicht im System erfasst. Auf Basis der vorhandenen Komponenten bzw. Daten ermöglicht das Repository vielfältige Auswertungen. So können insbesondere die Beziehungen zwischen Geschäftsprozessen, Bildschirmmasken, Funktionen und Daten analysiert und die Auswirkungen entsprechender Änderungen abgeschätzt werden.127 Weiterhin können verschiedene grafische Darstellungen der Anwendungslandschaft erzeugt werden (u. a. Matrixmodelle). Das Repository ermöglicht außerdem die Erstellung ganzer Fachspezifikationen sowie die frühzeitige Durchführung entsprechender Wirtschaftlichkeitsberechnungen. Über entsprechende Schnittstellen zur Entwicklungsumgebung bestehen darüber hinaus umfassende Möglichkeiten zur Generierung von Code und Dokumentation. Ergänzt wird dies durch eine weitgehende Testautomatisierung. Auf diese Weise werden den Entwicklern lästige Routine-Tätigkeiten abgenommen. Das Repository schafft damit die Voraussetzungen für eine

127

Z. B. kann ermittelt werden, welche Datenstrukturen von einer bestimmten Maskenänderung betroffen sind oder umgekehrt.


109

Softwareentwicklung nach dem Vorbild der industriellen Fertigung. Für die Pflege des Repositorys sind die jeweiligen Anwendungsentwickler zuständig. Dies ist formal im Rahmen des Anweisungswesens geregelt. Ein weiteres wichtiges Instrument des AM-C bildet das Dokument ”IT-Strategie”. Dieses wird in Abstimmung mit weiteren Gremien durch den Vorsitzenden des Architekturboards erstellt und regelmäßig überarbeitet. In der IT-Strategie werden die geltenden Architekturvorgaben dokumentiert. Hier werden u. a. wichtige Architekturprinzipien (z. B. redundanzfreie Datenhaltung über alle Vertriebskanäle) und Standards (z. B. z/OS für juristische Systeme) definiert. Ausnahmen von den in der IT-Strategie getroffenen Regelungen können jeweils durch das Architekturboard bewilligt werden. Im weiteren Sinne können auch die auf Basis des Masterplans entwickelten Bebauungspläne als Instrumente des AM-C angesehen werden.128 Darin werden die zukünftigen Entwicklungsschritte konkretisiert und Zielszenarien für die verschiedenen Systembereiche festgelegt. Bebauungspläne berücksichtigen dazu neben den fachlichen Vorgaben aus dem Masterplan insbesondere die technologischen Gesichtspunkte aus der IT-Strategie. Darüber hinaus werden verfeinerte Kosten-Nutzen-Betrachtungen angestellt und entsprechende Machbarkeitsaussagen getroffen. Der Planungshorizont beträgt üblicherweise drei Jahre. Masterplan und Bebauungspläne werden jeweils in Powerpoint dokumentiert. 5.4.2.4

Zielsetzung

Als wichtigstes übergeordnetes Ziel des AM-C kann die Erhöhung bzw. Erhaltung der ITFlexibilität angesehen werden. Dies wird als eine wesentliche Voraussetzung für die nachhaltige Erfüllung der Mandanten-Anforderungen betrachtet. Besonderes Augenmerk wird in diesem Zusammenhang vor allem auf die Time-to-Market sowie die Offenheit gegenüber externen Lösungen gelegt. Große Bedeutung kommt außerdem der Erhaltung der IT-Effizienz zu. Hier sieht sich Unternehmen C aber aufgrund von bestehenden Skaleneffekten bereits vergleichsweise gut positioniert. Zentrales Gestaltungsziel zur Erreichung der übergeordneten Ziele ist eine weitere Modularisierung bzw. der Ausbau der Serviceorientierung von System-C. Dabei wird nicht zuletzt die Schaffung voneinander weitgehend unabhängiger Anwendungscluster angestrebt. Dies soll insbesondere die Einbindung von Fremdsoftware durch die Mandanten erleichtern. Darüber

128

Zurzeit existieren ca. zehn Bebauungspläne, welche jeweils bestimmten Großprojekten zugeordnet werden können.

110

Fallstudien

hinaus soll die Standardisierung der IT weiter vorangetrieben werden. Hierzu zählen etwa eine Reduktion der technischen Plattformen sowie die Ablösung proprietärer Technologien durch offene Standards. 5.4.3

Historische Entwicklung und erzielte Ergebnisse

Nach mehreren Fusionen verfügte Unternehmen C zu Beginn des 21. Jahrhunderts über eine heterogene und in hohem Maße redundante Anwendungslandschaft mit mehreren Kernbankensystemen. Diese bestanden zudem vorwiegend aus monolithisch strukturierten CobolAnwendungen mit terminalorientierten Benutzerschnittstellen. Im Rahmen der Post-Merger-Konsolidierung wurde zunächst eines der bestehenden Kernbankensysteme ausgewählt und um ausgewählte Features der anderen Systeme ergänzt. Anschließend wurde beschlossen, das System schrittweise in eine offene, integrierte und service-orientierte Architektur mit standardisierten Schnittstellen zu überführen. Zur Koordination dieses Wandels wurde vor ca. fünf Jahren das Architekturboard gegründet. Seither gab es keine wesentlichen Veränderungen bzgl. Aufbau, Aufgaben und Intensität. Nach Unternehmensangaben konnten durch das AM-C bis heute gute Erfolge erzielt werden. Als konkretes Ergebnis wird insbesondere eine deutliche Senkung der IT-Komplexität genannt. So konnte eine erfolgreiche Konsolidierung der IT-Landschaft zu einem einheitlichen Gesamtbanksystem erreicht werden. Darüber hinaus wurden bereits deutliche Schritte in Richtung Serviceorientierung zurückgelegt. System-C verfügt heute über eine modulare und komponentenorientierte Anwendungsarchitektur. Es ist hierzu einerseits in die horizontalen Schichten Präsentation, Geschäftslogik und Datenhaltung untergliedert. Darüber hinaus besitzt es eine vertikale Gliederung im Sinne einer Baustein-Architektur. Den Kern bildet dabei eine zentrale Integrationsplattform. Über diese können mehr als 1.500 bankfachliche Services angesprochen werden. Die Schnittstellen sind sowohl für interne Entwickler als auch für externe Marktpartner nutzbar. Hierdurch ist die Anbindung neuer Applikationen mit geringem Aufwand möglich. Für den Frontendbereich existiert darüber hinaus eine weitere Integrationsschnittstelle, welche eine Integration webbasierter Anwendungskomponenten in bankfachliche Geschäftsprozesse ermöglicht. Über diese lassen sich Webapplikationen von Verbundpartnern in das Frontend der Gesamtbanklösung verknüpfen. Insgesamt liegen heute ca. 70% der Anwendungen in serviceorientierter Form vor. Dabei wurden neben den JavaSystemen im Frontend auch viele der Cobol-basierten Backend-Anwendungen umgestaltet. Weiterhin wurden die wesentlichen Datenbestände in zentralen Datenbanken integriert. So existiert insbesondere eine vollständig integrierte Kundensicht.

Interpretation

111

Auch im Hinblick auf die Homogenisierung der IT konnten deutliche Fortschritte erzielt werden. So kommt im Front- und Middle-Tier heute vorwiegend Java-Technologie zum Einsatz. Technische Grundlage hierfür bildet eine standardisierte Application Server Plattform auf Unix-Basis. Die juristische Datenhaltung und Transaktionsabwicklung erfolgen dagegen zentral auf einer z/OS - basierten Mainframeumgebung mit einem einheitlichen Datenbankmanagementsystem. Die Standardisierung hat im Ergebnis zu deutlichen Effizienzsteigerungen beigetragen. Dies wird neben den Skaleneffekten bei der Produktion vor allem auch auf eine Bündelung der Einkaufsmacht zurückgeführt. Durch die Verwendung von standardisierten Entwicklungswerkzeugen und des Repositorys konnten außerdem die Entwicklungsprozesse deutlich gestrafft werden. Auf diese Weise konnten insbesondere die Entwicklungskosten deutlich gesenkt werden. Darüber hinaus wird über eine Erhöhung der Transparenz sowie eine gestiegene Produktqualität berichtet.

5.5 Interpretation In diesem Abschnitt wird eine Interpretion der vorgestellten Fälle hinsichtlich der Zusammenhänge zwischen der Art der AM-Implementierung einerseits und den bisher erzielten Ergebnissen andererseits vorgenommen. Tabelle 5.1 fasst dazu die wesentlichen Charakteristika der Fälle nochmal zusammen. Die Fälle werden zunächst einzeln betrachtet. Im Anschluss hieran wird eine vergleichende Analyse durchgeführt. 5.5.1 Unternehmen A Unternehmen A verfügt bereits über langjährige Erfahrungen im Bereich Architekturmanagement. Das AM-A konnte sich über eine Zeitraum von ca. zehn Jahren kontinuierlich entwickeln und bildet heute einen festen Bestandteil der Unternehmensorganisation. Dabei wird ein relativ umfassender Ansatz mit föderativer Primärorganisation sowie einer umfangreichen Personal- und Ressourcenausstattung verfolgt. Auch Qualifikation und Spezialisierungsgrad der Mitarbeiter erscheinen vergleichsweise groß. Ergänzt wird die Primärorganisation durch mehrere separate Entscheidungsgremien. Klar definierte Prozesse und Kompetenzen sorgen gleichzeitig für eine gute organisatorische Einbindung. Dies äußert sich nicht zuletzt in einer lückenlosen Architektur-Governance sowie in einer sehr geringen Ausnahmequote. Inhaltlich liegt der Schwerpunkt der Tätigkeit des AM-A auf einer kontinuierlichen Regulation der UIS-Evolution durch Erarbeitung, Aktualisierung und Kontrolle entsprechender

112

Fallstudien

Unternehmen A Universalbank international ca. 10 Jahre - zentrales Team ITArchitecture - dezentrale Domänenarchitekten - Steering Comitee IT Architecture - Project-Review-Board - ArchitekturprogrammAusschüsse - Architektur-Entwicklung (Festlegung von ArchitekturElementen, Technologiemanagement, Aufbau von Infrastrukturen) - Architektur-Kommunikation (Publikationen, Schulungen) - Architektur-Implementierung (Projekt-Support, Projekt-Reviews) - Architektur-Controlling - Architekturprinzipien - Standardkataloge - Standardplattformen - Referenzarchitekturen - Anwendungsverzeichnis - Serviceverzeichnis - Softwarekarten Ist / Soll (manuell) - Roadmaps - Kennzahlensystem - Glossar

Unternehmen B Automobilbank international ca. 3 Jahre - zentrales Team Enterprise Architecture Management - dezentrale Koordinatoren in Landesgesellschaften - Project-ManagementCouncil - Architektur-Council (im Aufbau)

Unternehmen C IT-Dienstleister für Banken national ca. 5 Jahre - Team Basisinfrastruktur

- Architektur-Dokumentation - Architektur-Planung - Definition von Prinzipien und Standards - EAM-Compliance - operativer Projektsupport

- Architektur-Entwicklung (Festlegung von ArchitekturElementen) - Konformitätsprüfung - Bereitstellung und Verwaltung von Entwicklungskomponenten und werkzeugen

- integriertes EAM-Tool (Base Information Set, Softwarekarten Ist / Soll, Szenariotechnik, GAPAnalysen) - Architekturprinzipien - Standardkataloge

Vetorecht Konformitätsquote aktive ArchitekturImplementierung

ja ca. 97 % ja, mehrere Architekturprogramme

ja (nur Architektur-Council) ca. 70 % nein

übergeordnete Ziele

- IT-Effizienz - IT-Flexibilität - IT als Enabler - Transparenzsteigerung - Komplexitätsreduktion / Erhöhung des Standardisierungsgrades - Erhöhung der Modularität / Serviceorientierung - Kostensenkung

- IT-Effizienz - IT-Flexibilität

- integriertes EAM- / Komponenten-Repository (Wiederverwendung, Fachspezifikation / Prototyping, Wirtschaftlichkeitsrechnungen, What-If-Analysen, Auswertungen, Softwarekarten) - standardisierte Entwicklungsumgebung - IT-Strategie (Architekturprinzipien, Standards) - Bebauungspläne / Roadmaps ja ca. 95 % ja, in der Regel aber nur im Kontext fachlicher Änderungsanforderungen - IT-Flexibilität - IT-Effizienz

Branche Ausrichtung Alter des AM Primärorganisation

Sekundärorganisation

Aufgaben

Instrumente

Wirkungen

- Transparenzsteigerung - leichte Erhöhung des Standardisierungsgrades

- Architekturboard

- Transparenzsteigerung - Komplexitätsreduktion / Erhöhung des Standardisierungsgrades - Erhöhung der Modularität / Serviceorientierung - Kostensenkung - Qualitätsverbesserung

Tabelle 5.1: Vergleichende Übersicht der Fallstudien

Interpretation

113

Architektur-Artefakte (passive Architektur-Implementierung). Dabei kommt insbesondere eine breite Palette an Instrumenten der Architektur-Programmierung von Architekturprinzipien über Standardkataloge bis hin zu integrierten Standardplattformen zum Einsatz. Zur Akzeptanzsteigerung werden außerdem umfangreiche Maßnahmen der Kommunikation ergriffen. Großes Gewicht wird ferner auf die operative Begleitung von Projekten gelegt. Dies hat zu einer hohen Bekanntheit und Akzeptanz des Architekturmanagements geführt. Der Grad der Partizipation von Business-Vertretern erscheint trotzdem eher gering ausgeprägt. Darüber hinaus wird in Unternehmen A eine aktive Architektur-Implementierung betrieben. Hierzu werden umfangreiche Investitionen in entsprechende Architektur-Programme getätigt. Ein Schwerpunkt liegt dabei auf der Schaffung eines zentralen Integrationsbusses. Weiterhin erfolgt ein systematisches Erfolgs-Controlling. Unternehmen A verfügt hierzu als einziges der betrachteten Häuser über eine spezielle Architektur-Scorecard. Weniger weit entwickelt erscheint in Unternehmen A der Bereich der Architektur-Dokumentation. So ist die Metadatenverwaltung bisher auf isolierte Anwendungs- und Serviceverzeichnisse beschränkt. Grafische Modelle müssen daher mit relativ hohem Aufwand manuell erstellt werden. Die Verwaltung entsprechender Artefakte erfolgt weitgehend unstrukturiert. Eine Integration mit der Entwicklungsebene ist nicht gegeben. Insgesamt kann Unternehmen A als klassisches Beispiel für eine erfolgreiche AM-Implementierung angesehen werden. So konnten seit der Einführung des AM-A sowohl die ITGesamtkosten reduziert als auch die Time-to-Market verbessert werden. Der Erfolg kann dabei im Wesentlichen auf die gute organisatorische Einbindung und Ressourcenausstattung sowie auf die aktive Architektur-Implementierung zurückgeführt werden. Darüber hinaus werden die Möglichkeiten im Bereich Kommunikation und Support voll ausgereizt. Dies kann als ein wesentlicher Faktor für die langfristige Aufrechterhaltung der Akzeptanz des Architekturmanagements angesehen werden. Schließlich wurde mit dem Aufbau eines Architektur-Controllings ein wichtiger Schritt zur Entschärfung der Legitimationsproblematik unternommen. 5.5.2 Unternehmen B Mit einem Alter von unter drei Jahren verfügt Unternehmen B bisher über die geringsten Erfahrungen im Architekturmanagement. Ähnlich wie in Unternehmen A wurden auch hier eine föderative Primärorganisation sowie verschiedene architekturbezogene Gremien implementiert. Die Entwicklung ist dabei aber noch nicht vollständig abgeschlossen. So sind ins-

114

Fallstudien

besondere die Prozesse und Kompetenzen bisher nicht eindeutig geregelt. Darüber hinaus ist die Ressourcenausstattung gemessen an der Komplexität der IT vergleichsweise klein. Inhaltlich liegt der Schwerpunkt des AM-B auf der ganzheitlichen Dokumentation und Planung der IT-Makroarchitektur. Hierzu wird ein verhältnismäßig umfangreiches Instrumentarium bestehend aus einem komplexen Metamodell sowie einem modernen EAM-Repository eingesetzt. Die Datenerfassung erfolgt dabei dezentral durch die jeweiligen EAM-Koordinatoren. Das AM-B ist hierzu allerdings auf die freiwillige Kooperation der verschiedenen Stakeholder angewiesen. Weniger weit entwickelt sind in Unternehmen B die operativen Aufgabenbereiche. Für eine erfolgreiche Regulation der UIS-Evolution fehlt es bisher insbesondere an einer wirksamen Architektur-Governance. So sind Richtlinien und Standards in der Regel nicht verbindlich. Die durchgeführten Architektur-Reviews besitzen darüber hinaus nur empfehlenden Charakter. Dies schlägt sich nicht zuletzt in einer vergleichsweise hohen Ausnahmequote nieder. Eine aktive Architektur-Implementierung findet überdies nicht statt. Das AM-B konnte bisher nur mäßige Erfolge erzielen. Zwar konnte die Transparenz kurzfristig erhöht werden. Nachhaltige Wirkungen auf die IT-Architektur sind dagegen nicht feststellbar. So verfügt Unternehmen B auf Anwendungsebene nach wie vor über eine vergleichsweise ineffiziente und unflexible IT. Dies kann einerseits auf das junge Alter des AM-B zurückgeführt werden. Weitere Ursachen für die mangelnde Wirksamkeit können in der schlechten organisatorischen Verankerung bzw. der unzureichenden Architektur-Governance sowie der fehlenden aktiven Architektur-Implementierung gesehen werden. Insgesamt ist Fall B typisch für die im Rahmen der Neu-Implementierung von Architekturmanagement auftretenden Probleme. So ist der Rückhalt des Managements bisher eher gering. Dies kann als eine wesentliche Ursache für die unzureichende Ressourcen- und Kompetenzausstattung angesehen werden. Auch die Akzeptanz bei den verschiedenen Stakeholdern ist bisher begrenzt. In diesem Zusammenhang haben sich vor allem der Umfang der zu erfassenden Daten sowie die Komplexität des EAM-Tools negativ ausgewirkt.129 Hinzu kommt, dass ein über die geschaffene Transparenz hinausgehender Nutzen des Architekturmanagements bisher aufgrund des jungen Alters und der fehlenden aktiven ArchitekturImplementierung kaum nachgewiesen werden kann.130

129 130

Für die Zukunft ist daher eine Vereinfachung des BIS geplant. So fehlen insbesondere die aus psychologischer Sicht wichtigen ”Quick-Wins”.

Interpretation

115

5.5.3 Unternehmen C Unternehmen C kann im Bereich Architekturmanagement auf eine ca. fünfjährige Historie zurückblicken. Aufgrund negativer Erfahrungen in einem der Vorgängerinstitute wird dabei bewusst ein ”leichtgewichtiger” Ansatz ohne umfassendes Architekturteam verfolgt. Die Architektur-Steuerung wird stattdessen über ein vergleichsweise breit besetztes Architekturboard vorgenommen. Für infrastrukturbezogene Aufgaben existiert darüber hinaus eine kleine operative Organisationseinheit. Der von Unternehmen C gewählte Ansatz ermöglicht eine umfassende Partizipation der relevanten Stakeholder und bildet damit die Voraussetzung für eine hohe Akzeptanz. Klar definierte Verfahren und Kompetenzen sowie ein uneingeschränkter Management-Support sorgen außerdem für eine gute Architektur-Governance mit einer relativ geringen Ausnahmequote. Insgesamt wirken die Prozesse aber weniger formal als in Unternehmen A. So birgt insbesondere die dezentrale Feststellung der ”Architekturboard-Relevanz” durch den jeweiligen Geschäftsbereichsvertreter das potentielle Risiko einer Umgehung des Architekturboards.131 Darüber hinaus sind die eingesetzten Prinzipien und Standards deutlich weniger differenziert. Kennzeichnend für den Ansatz von Unternehmen C ist weiterhin eine konsequente Entwicklungsorientierung. Im Mittelpunkt stehen dabei eine standardisierte Entwicklungsumgebung sowie ein zentrales Komponenten-Repository. Dieses dient sowohl zur Verwaltung wiederverwendbarer Komponenten und Services als auch zur Architektur-Dokumentation und -Planung. Hierdurch wird der Erfassungsaufwand deutlich reduziert. Gleichzeitig bietet das Repository über eine allgemeine Erhöhung der Transparenz hinaus einen konkreten Nutzen für die Entwicklungsabteilungen. Dies gilt insbesondere für die Vorhabenplanung sowie im Hinblick auf eine erfolgreiche Wiederverwendung bestehender Komponenten. So bildet das Repository letztlich eine wichtige Grundlage für das erfolgreiche Management einer Service-Orientierten-Architektur. Dieser Zusatznutzen kann als eine wesentliche Ursache für die gute Akzeptanz des Repositorys (im Vergleich zu Fall B) angesehen werden. Der relativ gute Zustand von System-C im Hinblick auf Kosteneffizienz und Änderungsflexibilität deutet darauf hin, dass der von Unternehmen C gewählte Ansatz trotz seines begrenzten Umfangs durchaus effektiv ist und daher als praktikable Alternative zu den klassischen ”schwergewichtigeren” AM-Implementierungen angesehen werden kann. Die Stärken des

131

Möglicherweise existiert daher auch eine entsprechende Dunkelziffer von Architekturboard-relevanten Projekten, die jedoch nicht als solche deklariert werden.

116

Fallstudien

Ansatzes liegen neben dem vergleichsweise geringen Kostenaufwand vor allem in der guten Verankerung bei den Stakeholdern (und hier insbesondere den Entwicklungsabteilungen). Der Verzicht auf ein zentrales Architekturteam sorgt dabei für die größtmögliche Praxisnähe. Damit wird insbesondere die Legitimationsproblematik entschärft. Umgekehrt ergeben sich hieraus aber auch Probleme. So stellt der gewählte Ansatz hohe Anforderungen an die betreffenden Mitglieder des Architekturboards. Diese befinden sich oft in einem Interessenkonflikt zwischen den eigenen Bereichsinteressen und den übergreifenden Architekturinteressen. Außerdem bleibt aufgrund der Doppelbelastung häufig keine Zeit für eine adäquate Entscheidungsvor- bzw. -nachbereitung. Dies kann sich negativ auf Qualität und Geschwindigkeit der Entscheidungen auswirken.132 5.5.4

Vergleichende Analyse

Alle drei betrachteten Unternehmen verfügen über ein institutionalisiertes Architekturmanagement. Im Rahmen der AM-Implementierung werden dabei jedoch unterschiedliche Schwerpunkte gesetzt. So stehen in Fall A die übergreifende Definition von Strukturen, Regeln und Standards sowie deren konsequente Durchsetzung im Rahmen eines GovernanceFrameworks im Vordergrund. In Unternehmen B liegt der Schwerpunkt dagegen stärker im Bereich der integrierten Dokumentation und Planung der IT-Architektur. In Fall C schließlich wird besonderes Augenmerk auf eine Integration von Architekturmanagement und Anwendungsentwicklung gelegt. Im Hinblick auf die bisher erzielten Erfolge zeigt sich ein differenziertes Bild. So konnten in allen Fällen die Transparenz bezüglich der IT-Landschaft deutlich verbessert werden. Dies ist eine wesentliche Voraussetzung für die Beherrschung der Komplexität und eine zielorientierte Architektursteuerung. Wie die Fälle zeigen, kann eine gute Transparenz darüber hinaus zu einer Beschleunigung bei Neuentwicklungen und einer Senkung der Entwicklungskosten beitragen. Nachhaltige Veränderungen an der IT-Architektur konnten hingegen nur in den Fällen A und C beobachtet werden. Die wesentlichen Ursachen hierfür können in der Durchführung aktiver Architektur-Transformationen sowie in der Implementierung wirksamer GovernanceStrukturen gesehen werden. In Fall B wirkt sich darüber hinaus das geringe Alter des Architekturmanagements und die damit verbundene mangelnde Akzeptanz negativ aus. Dies kann als ein Indiz für die Existenz entsprechender Wirkungsverzögerungen angesehen werden.

132

Vor dem Hintergrund der negativen Erfahrungen mit spezialisierten Architekturgruppen soll in Unternehmen C bis auf weiteres trotzdem an der bestehenden Organisationsform festgehalten werden.

Einschränkungen

117

Insgesamt verfügen alle drei AM-Implementierungen über spezifische Stärken und Schwächen. So deckt insbesondere keiner der betrachteten Ansätze das volle Spektrum an Aufgaben und Instrumenten ab. Im direkten Vergleich erscheint Fall A als der Ansatz mit dem höchsten Reifegrad. Nichtsdestotrotz bestehen auch hier zahlreiche Möglichkeiten zur Optimierung. Dies gilt insbesondere im Hinblick auf die Werkzeugunterstützung. Wie Fall B zeigt, kann ein integriertes EAM-Tool zu einer deutlichen Verbesserung der Dokumentations-, Analyse- und Planungsprozesse beitragen. Eine anwenderfreundliche und interaktive Darstellung von Architektur-Artefakten kann dabei auch einen wesentlichen Beitrag zur Erhöhung der Akzeptanz leisten. Gleichzeitig dürfen die betreffenden Stakeholder aber durch ihre Mitwirkungspflichten bei der Pflege der Daten nicht überfordert werden. Zur Lösung dieser Problematik bietet sich eine enge Kopplung zwischen EAM-Repository einerseits und Entwicklungsrepository bzw. Entwicklungsumgebungen andererseits nach dem Vorbild von Fall C an.

5.6 Einschränkungen Analog zur Vorstudie sind auch bei der Interpretation der Fallstudienergebnisse eine Reihe von Einschränkungen zu beachten. So sind einerseits die betrachteten Fälle aufgrund der zum Teil sehr unterschiedlichen Rahmenbedingungen nur bedingt miteinander vergleichbar. Andererseits kann auch hier – trotz Verwendung multipler Erkenntnisquellen – nicht ausgeschlossen werden, dass die Darstellung der Fälle Lücken und / oder Verzerrungen enthält. Als mögliche Ursachen hierfür kommen wiederum der beschränkte zeitliche Rahmen für die Durchführung der Interviews sowie die hohe Komplexität und Heterogenität des Untersuchungsgegenstandes in Betracht. Ähnlich wie bei der Vorstudie ergibt sich ein besonderes Problem zudem aus der Abhängigkeit des Forschers von den jeweiligen Unternehmensvertretern. So basieren die verarbeiteten Informationen zum Großteil auf individuellen Aussagen bzw. subjektiven Einschätzungen der jeweiligen Interviewpartner und nicht auf objektiv überprüfbaren Fakten. Dies birgt nicht zuletzt das Risiko einer auf positive Außendarstellung bemühten Informationsverzerrung.133

133

Um diesen Effekt zu begrenzen, wurde eine Anonymisierung der Fälle zugesagt und auf eine Tonbandaufzeichnung verzichtet.

Kapitel 6


In den beiden vorangegangenen Kapiteln wurde die Praxis des Architekturmanagements ausführlich beschrieben und qualitativ analysiert. Dabei zeigte sich ein vergleichsweise heterogenes Bild. Als ein zentrales Problem konnte die schwierige Erfolgsmessung und die damit verbundene Legitimationsproblematik identifiziert werden (vgl. Abschnitt 4.2.9). So wird der Nutzen eines übergreifenden Managements der IT-Makroarchitektur in den Unternehmen immer noch von vielen Stakeholdern in Zweifel gezogen. Dies kann einerseits auf bestehende Interessenkonflikte, andererseits aber auch auf entsprechende Misserfolge in der Vergangenheit zurückgeführt werden. Im Rahmen der durchgeführten Untersuchungen zeigte sich denn auch, dass die Unternehmen mit ihren jeweiligen Ansätzen bisher unterschiedlich gute Ergebnisse erzielen konnten (vgl. Abschnitt 5.5). Grundsätzlich stellt sich damit die Frage nach der generellen Wirksamkeit sowie den entsprechenden Erfolgsfaktoren bei der Implementierung von Architekturmanagement. Die bisher erfolgte qualitativ orientierte Analyse konnte diesbezüglich nur erste Anhaltspunkte liefern. Zur Gewinnung wissenschaftlich abgesicherter Aussagen sind dagegen quantitative Daten erforderlich. Nach dem Kenntnisstand des Autors wurde diesbezüglich bisher erst eine empirische Untersuchung durchgeführt (Boh und Yellin, 2006). Die betreffende Studie konzen-

120


trierte sich jedoch auf den Einsatz von Architektur-Standards. Sie wird dem holistischen Ansatz eines übergreifenden Managements der IT-Makroarchitektur daher nur bedingt gerecht. Im Hinblick auf die Wirkungen wurden ferner ausschließlich systemtechnische Zielgrößen wie die Heterogenität oder der Integrationsgrad betrachtet. Für die Erfolgsmessung (und Legitimation) sind dagegen übergeordnete Ziele wie die IT-Flexibilität oder die IT-Effizienz von größerer Bedeutung (vgl. auch Abschnitt 4.2.4). Zur Adressierung dieser Forschungslücke wurde im Rahmen der vorliegenden Arbeit eine quantitative empirische Studie konzipiert und durchgeführt. Ziel war es dabei, das Konzept des Architekturmanagements ganzheitlich zu erfassen und seine Effektivität im Hinblick auf die Erreichung übergeordneter Architekturziele zu evaluieren. Konkret sollten dabei folgende Fragen beantwortet werden: (1) verfügen Unternehmen, welche in umfassenderer Weise und / oder seit längerer Zeit eine Funktion Architekturmanagement implementiert haben, über eine höhere IT-Flexibilität und / oder IT-Effizienz, und wenn ja, (2) was sind die kritischen Erfolgsfaktoren zur Erreichung dieser Ziele? Im Folgenden werden das Studiendesign sowie die wesentlichen Ergebnisse der Studie vorgestellt. Dazu wird zunächst der Untersuchungsgegenstand konzeptualisiert. Hieran schließt sich die Formulierung der Hypothesen an. Daraufhin wird die Methodik bei der Studiendurchführung dargestellt. Es folgt die Präsentation der wichtigsten Studienergebnisse sowie deren Diskussion und Interpretation.

6.1

Konzeptualisierung und Hypothesenentwicklung

Um den Zusammenhang zwischen Umfang und Dauer der AM-Implementierung einerseits und der Erreichung der Architekturziele andererseits quantitativ untersuchen zu können, ist zunächst eine entsprechende Konzeptualisierung erforderlich. Hierunter ist eine genaue Definition der betrachteten Sachverhalte und eine Bestimmung deren semantischer Struktur zu verstehen. Dies beinhaltet insbesondere eine Zerlegung komplexer Konzepte in die im Kontext der zu untersuchenden Forschungsfrage relevanten semantischen Dimensionen (vgl. z. B. Lewis et al., 2005, S. 389ff.; Diekmann, 2004; Schnell et al., 2005).134

134

Die Auswahl und Granularität der Dimensionen hat sich dabei neben inhaltlichen Gesichtspunkten vor allem auch nach forschungspraktischen Aspekten zu richten. So darf insbesondere der Umfang des resultierenden Messinstrumentes (vgl. Abschnitt 6.2.2) eine bestimmte Obergrenze nicht überschreiten, da ansonsten die Praktikabilität stark eingeschränkt wird.


121

Im weiteren Verlauf dieses Abschnitts wird zunächst die Konzeptualisierung der Zielgrößen dargestellt. Hierauf folgt die Konzeptualisierung der AM-Implementierung. Anschließend werden formale Hypothesen über die vermuteten Zusammenhänge formuliert. 6.1.1 Architekturziele Architekturmanagement stellt keinen Selbstzweck dar. Wie in Abschnitt 3.2.3 aufgezeigt, hat es sich stattdessen an übergeordneten Architekturzielen auszurichten. Diese können in Abhängigkeit der internen und externen Situation individuell festgelegt und priorisiert werden. Den Ausgangspunkt sollte dabei die jeweilige Unternehmensstrategie bilden. Nach Allen und Boynton (1991, S. 436) liegen die übergeordneten Architekturziele typischerweise in einer Erhöhung bzw. Aufrechterhaltung der IT-Flexibilität einerseits sowie der IT-Effizienz andererseits. Dies konnte durch die qualitativen Untersuchungen in den Kapiteln 4 und 5 im Wesentlichen bestätigt werden. Im Rahmen der quantitativen Studie erfolgt daher eine Konzentration auf die beiden Zielgrößen IT-Effizienz und IT-Flexibilität.135 6.1.1.1

IT-Effizienz

Unter IT-Effizienz kann unter Bezugnahme auf den allgemeinen betriebswirtschaftlichen Effizienzbegriff (Drucker, 1974) das Verhältnis zwischen der Leistung der IT-Funktion und dem hierfür notwendigen Aufwand verstanden werden. Die Leistung ist dabei über Umfang und Qualität der Geschäftsprozessunterstützung bzw. -automatisierung durch Bereitstellung entsprechender maschineller Aufgabenträger (Anwendungssysteme einschließlich Kommunikationseinrichtungen) gegeben. Der Aufwand hingegen entspricht den Gesamtkosten der IT-Funktion (unabhängig davon, ob entsprechende Leistungen intern oder extern erbracht werden). Die IT-Effizienz wird in wesentlichem Maße durch die Architektur des Unternehmensinformationssystems bestimmt. So ist etwa davon auszugehen, dass funktionale Redundanzen zu erhöhten Wartungs- und Betriebskosten führen. Weiterhin ist anzunehmen, dass die Kosten mit zunehmender System-Varietät ansteigen. Hierfür können Skaleneffekte bei Produktion und Beschaffung verantwortlich gemacht werden. Schließlich kann auch ein Zusammenhang zwischen der IT-Effizienz und der Struktur der Systemkopplung unterstellt werden. So ist etwa davon auszugehen, dass eine zentralisierte Integrationstopologie aufgrund der geringe-

135

Hiervon abweichende Zielsetzungen werden damit vernachlässigt. Dies wird vor dem Hintergrund der notwendigen inhaltlichen Fokussierung quantitativer Studien bewusst in Kauf genommen.

122


ren Anzahl von Schnittstellen mit deutlich geringeren Wartungs- und Entwicklungskosten verbunden ist als eine komplexe Struktur aus dezentralen Direktschnittstellen. Ein hoher Grad an IT-Effizienz kann wesentlich zu einer Minimierung der Gesamtkosten im Unternehmen beitragen.136 Dies kann sich unmittelbar in einer höheren Profitabilität niederschlagen. Der Wert eines primär auf Effizienz ausgerichteten Unternehmensinformationssystems zeigt sich dabei vor allem in großvolumigen und eher stabilen Märkten. In einem solchen Umfeld kann ein effizientes UIS einen nachhaltigen Wettbewerbsvorteil im Sinne der Ressourcen-Theorie (Resource-Based-View of Strategy, RBV) darstellen.137 6.1.1.2

IT-Flexibilität

IT-Flexibilität bezeichnet den Grad, in dem das Unternehmensinformationssystem einfach (d. h. schnell und mit möglichst geringem Aufwand) an geänderte Anforderungen angepasst werden kann (vgl. hierzu auch Beimborn et al., 2006, S. 589; Tallon und Kraemer, 2003, S. 2; Duncan, 1995, S. 44; Clemons und Row, 1991; Schwinn, 2005, S. 5). Flexibilität ist eine wichtige Voraussetzung für den effektiven Umgang mit Umweltdynamik (Byrd und Turner, 2000, S. 170). Ein flexibles UIS kann daher vor allem in dynamischen und innovationsintensiven Märkten einen wesentlichen strategischen Wettbewerbsvorteil darstellen (Duncan, 1995, S. 38, S. 44). Auch die IT-Flexibilität wird in wesentlichem Maße durch die IT-Makroarchitektur bestimmt. In Anlehnung an Byrd und Turner (2000) kann IT-Flexibilität entsprechend über die beiden Hauptdimensionen Modularität und Integration konzeptualisiert werden.138 Modularität bezeichnet dabei die Fähigkeit, leicht und ohne größere Nebeneffekte Systemkomponenten hinzuzufügen, zu ändern oder zu entfernen. Integration wird hingegen verstanden als die Fähigkeit, Verbindungen zwischen beliebigen Systemkomponenten herzustellen (Konnektivität) und Informationen auszutauschen (Kompatibilität) (Byrd und Turner, 2000, S. 171). Die Vorzüge einer flexiblen IT-Infrastruktur wurden in verschiedenen Studien nachgewiesen. So konnte etwa Ness (2005) zeigen, dass IT-Flexibilität sich positiv auf die IT-Effekti-

136 137 138

Das gilt vor allem für die Finanzindustrie, bei der die IT-Kosten einen großen Teil des Verwaltungsaufwandes ausmachen (vgl. hierzu Kapitel 3.1.3). Nach dem RBV ist eine Unternehmensressource dann als strategisch einzustufen, wenn sie wertvoll und knapp ist und gleichzeitig nur schwer substituiert, imitiert oder transferiert werden kann (vgl. Mata et al., 1995). Vgl. hierzu auch Tallon und Kraemer (2003, S. 10) sowie Ness (2005, S. 3). Byrd und Turner (2000) betrachten daneben ursprünglich auch eine personelle Ebene.


123

vität auswirkt.139 Chung et al. (2005) konnten weiterhin einen Zusammenhang zwischen der Flexibilität der IT-Infrastruktur und der Fähigkeit eines Unternehmens zur individualisierten Massenfertigung (”Mass-Customization”) feststellen. Tallon und Kraemer (2003) zeigten schließlich, dass die IT-Flexibilität einen positiven Einfluss auf das strategische Alignment140 besitzt und zu einem höheren Wertbeitrag der IT (IT Business Value) führt. 6.1.1.3

Zielbeziehungen

Zwischen den Zielgrößen IT-Effizienz und IT-Flexibilität bestehen komplexe Wechselbeziehungen. So setzt die Erzeugung und Aufrechterhaltung von Flexibilität (z. B. durch den Aufbau und die Pflege einer Service-Orientierten-Architektur) in der Regel besondere Investitionen voraus. Dies kann sich kurzfristig in einer Abnahme der IT-Effizienz niederschlagen. Umgekehrt beinhaltet eine einseitige Optimierung der IT-Effizienz (z. B. durch eine weitgehende Plattform-Standardisierung) oft eine Reduktion der IT-Flexibilität. Aus kurzfristiger Perspektive ist daher von einer konfliktären Zielbeziehung auszugehen. Langfristig gesehen kann eine höhere IT-Flexibilität dagegen zu einer Senkung der Änderungskosten (Entwicklungskosten) führen und somit wiederum einen positiven Einfluss auf die IT-Effizienz ausüben. Das Ausmaß dieser langfristigen Wirkungsbeziehung ist allerdings vom Grad der nicht-antizipierten Umweltdynamik im betrachteten Wirkungszeitraum abhängig und insofern nur schwer abzuschätzen. Aus diesen Überlegungen wird deutlich, dass von der Höhe der IT-Flexibilität zu einem bestimmten Zeitpunkt nicht ohne weiteres auf die Höhe der IT-Effizienz geschlossen werden kann und umgekehrt. Im Rahmen der vorliegenden Studie werden die Interdependenzen zwischen IT-Flexibilität und IT-Effizienz deshalb nicht weiter untersucht.141 Es wird jedoch davon ausgegangen, dass beide Ziele bis zu einem gewissen Grad gleichzeitig verfolgt und erreicht werden können. 6.1.2 AM-Implementierung Nach dem Verständnis dieser Arbeit bildet das Architekturmanagement eine dauerhaft im Unternehmen zu verankernde Funktion (vgl. Abschnitt 3.2.1). Eine Analyse der Effektivität

139 140 141

IT-Effektivität wird dabei definiert als ”the delivery of reliable and quality service to the business supporting its long-term goals” (Ness, 2005, S. 4). Definiert als ”fit between information technology and business strategy” (Tallon und Kraemer, 2003, S. 2). So werden insbesondere keine Hypothesen über entsprechende Zusammenhänge formuliert.

124


sollte daher sowohl den Umfang des gewählten Ansatzes (AM-Ansatz) als auch die zeitliche Spanne der Implementierung (AM-Dauer) berücksichtigen. Wie in den Kapiteln 4 und 5 deutlich wurde, existieren in der Praxis bisher vielfältige Formen der AM-Implementierung. Der AM-Ansatz kann daher als ein komplexes multidimensionales Konstrukt angesehen werden. Für die Auswahl und Differenzierung entsprechender Facetten bzw. Dimensionen gibt es prinzipiell unterschiedliche Möglichkeiten. Aus Mangel an einer umfassenden theoretischen Fundierung wird hierzu im Folgenden auf die Ergebnisse der Vorstudie zurückgegriffen. Dabei erfolgt eine Konzentration auf formale Aspekte der AM-Implementierung.142 Gemäß Kapitel 4.2.5 können die in der Praxis wahrgenommenen Aufgaben des Architekturmanagements in die strategischen Aufgabenbereiche Architektur-Dokumentation und Architektur-Leitplanung sowie die operativen Aufgabenbereiche aktive und passive Architektur-Implementierung untergliedert werden. Diese bilden daher einen geeigneten Rahmen für eine einheitliche Charakterisierung der verschiedenen Ansätze. Um den unterschiedlichen Gewichtungen innerhalb der Architektur-Leitplanung Rechnung zu tragen, kann diese weiterhin in die beiden Unterkategorien Architektur-Planung und Architektur-Programmierung zerlegt werden (vgl. Abschnitt 3.2.3). Darüber hinaus ist eine Differenzierung des Aufgabenbereiches der passiven Architektur-Implementierung in die beiden Teilbereiche Architektur-Kommunikation & -Support sowie Architektur-Governance naheliegend. Vor dem Hintergrund der Akzeptanz- und Legitimationsproblematik des Architekturmanagements (vgl. Abschnitt 4.2.9) erscheint schließlich auch der Grad der Stakeholder-Partizipation als ein wesentliches Merkmal der AM-Implementierung, das bei der Konzeptualisierung zu berücksichtigen ist. Der AM-Ansatz wird daher im Rahmen der vorliegenden Studie über die sieben Teildimensionen Architektur-Dokumentation, Architektur-Planung, Architektur-Programmierung, (aktive) Architektur-Implementierung, Architektur-Kommunikation & -Support, Architektur-Governance sowie Stakeholder-Partizipation konzeptualisiert. Im Folgenden werden die einzelnen Dimensionen im Detail betrachtet und ihr jeweiliger Bezug zum AM-Erfolg herausgearbeitet. • Architektur-Dokumentation: Die Dimension Architektur-Dokumentation bezieht sich auf den Umfang der Architektur-Dokumentation im Hinblick auf Gegenstand und Methodik. Unter Architektur-

142

Inhaltliche Aspekte sind einer standardisierten Erfassung aufgrund der hohen Unternehmensspezifität nur bedingt zugänglich. Vgl. zu dieser Problematik z. B. auch Segars und Grover (1998).


125

Dokumentation wird dabei der Prozess der Analyse und Beschreibung der existierenden IT-Makroarchitektur (einschließlich strukturierter Ablage und regelmäßiger Aktualisierung entsprechender Artefakte) verstanden. Ein angemessener und aktueller Dokumentationsbestand bildet eine Grundvoraussetzung für eine rationale Architektursteuerung auf Makroebene. Er kann darüber hinaus ganz allgemein die Entscheidungsqualität bei der Planung und Umsetzung von Systemveränderungen verbessern. So kann z. B. die Identifikation bereits bestehender Systemkomponenten und Beziehungen deutlich erleichtert werden. Dies kann zu einer verbesserten Systemintegration beitragen. Darüber hinaus können die Wiederverwendung von Systemkomponenten erleichtert und entsprechende Redundanzen vermieden werden (vgl. Heinrich und Lehner, 2005, S. 50). • Architektur-Planung: Die Dimension Architektur-Planung bezieht sich auf den Umfang der ArchitekturPlanung im Hinblick auf Gegenstand und Methodik. Unter Architektur-Planung wird dabei der Prozess der zielgeleiteten Entwicklung von Beschreibungen der zukünftigen IT-Makroarchitektur verstanden (einschließlich strukturierter Ablage und regelmäßiger Aktualisierung der entsprechenden Artefakte).143 Entsprechende Pläne bilden die Grundlage für eine anforderungsgerechte Gestaltung des Unternehmensinformationssystems auf Makroebene. Sie ermöglichen dabei insbesondere eine Ex-ante-Verifikation der geforderten Systemeigenschaften. Die Ziel-Architektur-Pläne stellen darüber hinaus eine wichtige Vorgabe für die Auswahl bzw. Ausrichtung der durchzuführenden Änderungsvorhaben im Rahmen der (aktiven und / oder passiven) ArchitekturImplementierung dar. • Architektur-Programmierung: Die Dimension Architektur-Programmierung bezieht sich auf den Umfang der Architektur-Programmierung im Hinblick auf Inhalt und eingesetzte Instrumente. Unter Architektur-Programmierung wird dabei die Vorgabe von allgemeinen Richtlinien und Standards für die Durchführung von Änderungsvorhaben verstanden. Hierüber können bestimmten Problemklassen erprobte und aufeinander abgestimmte Lösungsmuster bzw. -komponenten zugeordnet werden.144 Auf diese Weise lässt sich der Lösungsraum von Change-Projekten zugunsten einer zielkonformen Ausrich-

143 144

Konkret kann es sich dabei um eine Vielzahl von Einzelplänen für bestimmte Systemausschnitte handeln (vgl. Abschnitt 2.2.4.2). Außerdem sind unterschiedliche Szenarien und Zeithorizonte möglich. Im Gegensatz zur Architektur-Planung liegt der Ansatzpunkt daher auf einer generischen Ebene.

126


tung einschränken. So kann im Wege der Architektur-Programmierung insbesondere die Systemvarietät kontrolliert werden. Dies kann sich aufgrund von Skaleneffekten positiv auf die Entwicklung der Wartungs- und Betriebskosten auswirken (vgl. Boh und Yellin, 2006, S. 174). Darüber hinaus kann damit die Systemintegration deutlich erleichtert werden (vgl. Buxmann et al., 1999). • Architektur-Implementierung: Die Dimension Architektur-Implementierung bezieht sich auf den Umfang der aktiven Architektur-Implementierung. Hierzu zählen insbesondere die Durchführung von allgemeinen Reorganisations- bzw. Konsolidierungsprojekten sowie Aufbau und Pflege von zentralen Infrastrukturkomponenten (z. B. Integrationsplattformen, wiederverwendbare Services). Durch entsprechende Implementierungsmaßnahmen kann eine Annäherung an die definierten Architekturziele in der Regel deutlich beschleunigt werden (vgl. Abschnitt 5.5). Eine Bereitstellung zentraler Infrastrukturkomponenten kann sich zudem positiv auf die Wiederverwendung im Rahmen der passiven Architektur-Implementierung auswirken. Dies kann längerfristig zu einer Senkung der Entwicklungs- und Betriebskosten beitragen. Die Verfügbarkeit von ”nützlichen” Komponenten kann sich darüber hinaus in einer höheren Standardkonformität niederschlagen. • Architektur-Kommunikation & -Support: Die Dimension Architektur-Kommunikation & -Support bezieht sich auf den Umfang der ergriffenen Kommunikations- und Support-Maßnahmen. Unter Kommunikation wird dabei die Vermittlung von Architekturentscheidungen sowie den damit zusammenhängenden Regularien im Unternehmen verstanden. Dies betrifft sowohl die verabschiedeten Zielarchitekturpläne (Architektur-Planung) als auch entsprechende Richtlinien und Standards (Architektur-Programmierung). Unter Support wird weiterhin eine über die reine Kommunikation hinausgehende Unterstützung von Stakeholdern bei der Planung und Implementierung architekturkonformer Lösungen verstanden. Hierzu zählen insbesondere die Erbringung von Beratungsleistungen gegenüber Entwicklungsprojekten sowie entsprechende Projektarbeit. Eine klare Kommunikation von Architekturentscheidungen bildet eine Grundvoraussetzung für deren wirksame Implementierung im Rahmen einer passiven Architektur-Implementierung. So setzt die Architektur-Konformität von Änderungsvorhaben zunächst deren Bekanntheit bei den betreffenden Stakeholdern voraus. Entsprechende Support-Maßnahmen können darüber hinaus zu einer verbesserten Akzeptanz beitragen.


127

• Architektur-Governance: Die Dimension Architektur-Governance bezieht sich auf den Umfang der Architektur-Governance. Hierunter wird der Grad der Verbindlichkeit und Durchsetzbarkeit von Architekturentscheidungen auf Basis formaler Regelungen und Prozesse verstanden. Dies gilt wiederum sowohl für die verabschiedeten Zielarchitekturpläne (Architektur-Planung) als auch für entsprechende Richtlinien und Standards (ArchitekturProgrammierung). Eine angemessene Architektur-Governance ist von wesentlicher Bedeutung für die wirksame Umsetzung von Architekturentscheidungen im Rahmen der passiven Architektur-Implementierung (vgl. Abschnitt 5.5). Ohne sie kann die Ziel-Konformität von Änderungsvorhaben nicht gewährleistet werden. • Stakeholder-Partizipation: Die Dimension Stakeholder-Partizipation bezieht sich auf das Ausmaß der Stakeholder-Beteiligung. Hierunter wird die Einbeziehung der verschiedenen Anspruchsgruppen in die Entscheidungsprozesse des Architekturmanagements verstanden. Durch eine adäquate Stakeholder-Partizipation kann sichergestellt werden, dass die getroffenen Architekturentscheidungen den langfristigen Anforderungen der Stakeholder gerecht werden und dass individuelle Interessen in angemessener Weise ausgeglichen werden. Die Partizipation kann darüber hinaus einen positiven Einfluss auf die Akzeptanz des Architekturmanagements haben. Nach den Ergebnissen der qualitativen Untersuchungen ist ein längerfristiger Erfolg des Architekturmanagements ohne eine angemessene Stakeholder-Beteiligung unwahrscheinlich (vgl. Abschnitte 4.2.2). Auf der Grundlage der vorgenommenen Konzeptualisierung können nun formale Hypothesen über die Zusammenhänge zwischen Umfang und Dauer der AM-Implementierung einerseits und den betrachteten Zielgrößen andererseits formuliert werden. 6.1.3

Forschungsmodell

Vor dem Hintergrund der bisherigen theoretischen und empirischen Analyse kann davon ausgegangen werden, dass der AM-Ansatz eines Unternehmens einen Einfluss auf die Erreichung der Architekturziele hat (vgl. hierzu Abschnitte 4.2.10, 5.5.4 und 6.1.2). Unter der Annahme einer allgemeinen Effizienz- und Flexibilitätsorientierung145 ist daher ein positiver Zusammenhang zwischen dem beobachtbaren Umfang des AM-Ansatzes einerseits und dem

145

Vgl. Abschnitt 6.1.1. Dies ist im Rahmen der Studiendurchführung durch entsprechende Kontrollvariablen zu prüfen.

128


bestehenden Grad an IT-Flexibilität und IT-Effizienz andererseits zu vermuten. Hinsichtlich der IT-Effizienz wird dabei unterstellt, dass die zusätzlich durch das Architekturmanagement verursachten Koordinationskosten durch entsprechende Einsparungen überkompensiert werden können (vgl. z. B. Ball et al., 2004, S. 3756). Die Ergebnisse der durchgeführten qualitativen Studien deuten darauf hin, dass dies grundsätzlich möglich ist (vgl. Abschnitte 4.2.8 und 5.2.3). Damit können die ersten beiden Hypothesen formuliert werden: H1a:

Unternehmen, die einen umfangreicheren AM-Ansatz (im Hinblick auf Architektur-Dokumentation, Architektur-Planung, Architektur-Programmierung, Architektur-Implementierung, Architektur-Kommunikation & -Support, Architektur-Governance sowie Stakeholder-Partizipation) verfolgen, besitzen im Durchschnitt eine höhere IT-Flexibilität.

H1b:

Unternehmen, die einen umfangreicheren AM-Ansatz (im Hinblick auf Architektur-Dokumentation, Architektur-Planung, Architektur-Programmierung, Architektur-Implementierung, Architektur-Kommunikation & -Support, Architektur-Governance sowie Stakeholder-Partizipation) verfolgen, besitzen im Durchschnitt eine höhere IT-Effizienz.

Neben dem inhaltlichen Umfang ist für die Erfolgswirkung des Architekturmanagements auch die Zeitspanne der AM-Implementierung von Bedeutung. Dies ergibt sich aus dem kontinuierlichen Charakter der Architektursteuerung auf Makroebene sowie den auftretenden Wirkungsverzögerungen (vgl. Abschnitt 4.2.8 und Abschnitt 5.5.4). So führen vor allem die regulativen Eingriffe im Rahmen der passiven Architektur-Implementierung in der Regel erst nach mehreren Jahren zu sichtbaren Auswirkungen auf die IT-Makroarchitektur. Unternehmen mit einer langjährigen AM-Implementierung sollten daher (bei vergleichbarem AM-Ansatz) eine bessere Zielerreichung aufweisen als Unternehmen mit einer kürzeren AM-Historie. Dies wird auch durch die Ergebnisse der durchgeführten Fallstudienuntersuchung untermauert (vgl. Abschnitt 5.5.4). Damit können zwei weitere Hypothesen formuliert werden:146 H2a:

146

Unternehmen mit einer höheren AM-Implementierungsdauer verfügen im Durchschnitt über eine größere IT-Flexibilität.

Hierbei wird auch im historischen Rückblick eine allgemeine Effizienz- und Flexibilitätsorientierung unterstellt.

Methodik

129

DOC

CON

PLN FLX

H1a +

PRG

COM

MOD H2a +

IMP

EAM

DUR

H2b + COS

H1b +

EFF GOV

PAR

COM: Kompatibilität CON: Konnektivität COS: Architektur-Kommunikation & -Support DOC: Architektur-Dokumentation DUR: AM-Implementierungsdauer EAM: AM-Ansatz EFF: IT-Effizienz

FLX: IT-Flexibilität GOV: Architektur-Governance IMP: Architektur-Implementierung MOD: Modularität PAR: Stakeholder-Partizipation PLN: Architektur-Planung PRG: Architektur-Programmierung

Abbildung 6.1: Forschungsmodell

H2b:

Unternehmen mit einer höheren AM-Implementierungsdauer verfügen im Durchschnitt über eine größere IT-Effizienz.

Die Hypothesen H1a – H2b bilden gemeinsam das Forschungsmodell der quantitativen Studie. Dieses ist zusammenfassend in Abbildung 6.1 dargestellt.

6.2 Methodik Im Folgenden wird ausführlich auf die Methodik bei der Studiendurchführung eingegangen. Dazu wird zunächst das grundsätzliche Studiendesign skizziert. Es folgt eine Darstellung der Variablen-Operationalisierung. Danach wird die Vorgehensweise bei der Datenerhebung beschrieben. Anschließend wird das für die Datenauswertung eingesetzte Analyseverfahren vorgestellt.

130

6.2.1


Studiendesign

Zur empirischen Prüfung der in Abschnitt 6.1 postulierten Hypothesen wurde eine quantitative Feldstudie nach der Querschnittsmethode konzipiert (Ex-Post-Facto-Design). Um branchenabhängige Einflussfaktoren auszuschließen und eine hohe Homogenität der Kontextfaktoren zu erreichen, erfolgte dabei eine Beschränkung auf die Finanzindustrie. Diese eignet sich hierfür aufgrund des großen Anwendungspotentials (vgl. Abschnitt 1.3 und 3.1.3) sowie der hohen Verbreitung von Architekturmanagement (vgl. Kapitel 4) in besonderer Weise. Zur Vermeidung kulturell bedingter Probleme wurde die Studie weiterhin auf die sogenannte ”Westliche Welt” (d. h. Europa, Nordamerika und Australien) beschränkt. Hierdurch sollte insbesondere der auf sprachliche Barrieren zurückzuführende Ausfall (Non-Response) minimiert werden. Aus Gründen der Relevanz und zur Vermeidung von größenbedingten Verzerrungen erfolgte ferner eine Begrenzung auf große und mittlere Unternehmen. Die Grundgesamtheit wurde daher definiert als die Menge der 500 größten Finanzdienstleister in der Europäischen Union, in Nordamerika und in Australien nach aktueller Bilanzsumme. Als Stichprobenverfahren wurde entsprechend die Vollerhebung gewählt. Aufgrund der mangelnden Verfügbarkeit einer zentralen Übersicht der weltgrößten Finanzdienstleister musste zunächst eine entsprechende Liste aus mehreren Quellen zusammengestellt werden. Hierzu gehörten insbesondere das Forbes 2000 Ranking für 2006 (gefiltert nach Banking, Insurance und Diversified Financials) und das TOP 1000 World Banks Ranking 2006 des Magazins The Banker. Dabei wurden alle Firmen mit Hauptsitz außerhalb der Zielregion (Europa, Nordamerika und Australien) entfernt. Anschließend wurden die verbleibenden Unternehmen nach Bilanzsumme sortiert. Die obersten 500 Unternehmen wurden schließlich als Untersuchungs-Frame definiert. Als nächstes wurde für alle Unternehmen der Grundgesamtheit nach entsprechenden Kontaktpersonen recherchiert. Primäres Ziel war dabei die Identifikation eines architekturverantwortlichen Managers (z. B. Chief Architect, Enterprise Architect, Head of IT Architecture). In den Fällen, in denen entsprechende Funktionen nicht existierten oder keine Kontaktpersonen identifiziert werden konnten, wurde stattdessen der Leiter der IT-Abteilung gewählt (z. B. CIO, Leiter IT). Bei Firmen, die ihre IT-Funktion vollständig an einen zentralen ServiceProvider ausgelagert hatten, wurde entsprechend auf den Service-Provider ausgewichen. Die relevanten Kontaktdaten wurden über Suchmaschinen, Social-Networking-Plattformen sowie durch individuelle Telefon-Anfragen ermittelt. Darüber hinaus stellten ein großes Beratungsunternehmen mit langjährigen Erfahrungen im Bereich Architektur(-management) so-

Methodik

131

wie ein großer Hersteller von Integrationssoftware entsprechende Kontakte zu einigen ihrer Kunden her. 6.2.2 Operationalisierung Wie in den Sozial- und Wirtschaftswissenschaften üblich, handelt es sich bei den theoretischen Konstrukten des Forschungsmodells um komplexe Größen, die sich einer direkten objektiven Messung entziehen. Man spricht daher auch von sogenannten latenten Variablen. Die Messung von latenten Variablen erfolgt in der empirischen Sozialforschung üblicherweise mit Hilfe von mehreren Indikator-Variablen (sogenannten Items) (Diekmann, 2004; Schnell et al., 2005). Diese bilden zusammen das Messmodell des jeweiligen Konstruktes. Die Spezifikation der verwendeten Messmodelle wird entsprechend als Operationalisierung bezeichnet.147 Dabei ist zwischen einer reflektiven und einer formativen Operationalisierung zu unterscheiden (vgl. hierzu Jarvis et al., 2003). Aus Gründen der leichteren Handhabung wurden im Rahmen der vorliegenden Studie ausschließlich reflektive Messmodelle verwendet. Zur Gewährleistung einer hinreichenden Konstrukt-Reliabilität wurden dabei pro Konstrukt jeweils mindestens vier Indikatoren eingesetzt. Mehrdimensionale Konstrukte (wie der AM-Ansatz oder die IT-Flexibilität) wurden zuvor in ihre entsprechenden Teildimensionen zerlegt. Grundsätzlich wurden bei der Operationalisierung soweit wie möglich bereits bestehende Messmodelle aus der Literatur wiederverwendet bzw. erweitert. Sofern nicht anders vermerkt, erfolgte die Messung der manifesten Variablen jeweils in geschlossener Form auf einer 5-Punkte-Likert-Skala mit den Endpunkten ”strongly disagree” und ”strongly agree”. Zur Vermeidung von methodischen Artefakten wurden weiterhin eine Reihe von inversen Items verwendet. Im Folgenden wird die Operationalisierung der wichtigsten Konstrukte im Detail dargestellt. 6.2.2.1

AM-Ansatz

Ein Messinstrument zur ganzheitlichen Erfassung des von einer Organisation verfolgten AM-Ansatzes wurde in der Literatur bisher nicht vorgeschlagen. Im Rahmen der vorliegenden Studie musste daher zunächst ein neues Messinstrument entwickelt werden. Da-

147

Die Operationalisierung beinhaltet damit selbst Hypothesen über den Zusammenhang von latenten Variablen und Indikatoren (sogenannte ”Korrespondenzregeln”). Man spricht daher auch von einer ”Messtheorie”.

132


bei erfolgte eine Orientierung an der Operationalisierung des Strategic Information Systems Planning (SISP) Approach durch Segars und Grover (1998), Doherty et al. (1999) sowie Warr (2005). Auf Basis der vorgenommenen Konzeptualisierung (vgl. Abschnitt 6.1.2) wurde der AM-Ansatz entsprechend als ein multi-dimensionales Konstrukt mit den sieben Teildimensionen Architektur-Dokumentation, Architektur-Planung, Architektur-Programmierung, Architektur-Implementierung, Architektur-Kommunikation & -Support, Architektur-Governance sowie Stakeholder-Partizipation operationalisiert. Die Items zur Messung der einzelnen Dimensionen wurden soweit möglich aus der Literatur entnommen. Als Quelle dienten dazu neben Boh und Yellin (2006) unter anderem auch die oben genannten Arbeiten aus dem Bereich des SISP. Weitere Items wurden auf Basis der qualitativen Studienergebnisse aus den Kapiteln 4 und 5 generiert. Insgesamt wurde bei der Zusammenstellung der Items das Ziel verfolgt, alle wichtigen Charakteristika der betreffenden Dimensionen durch jeweils mindestens ein Item abzudecken (Lewis et al., 2005, S. 392). Die semantische Skalierung der Items wurde zudem so gewählt, dass die Obergrenzen (bzw. bei inversen Items die Untergrenzen) dem theoretisch bzw. sachlogisch optimalen Erfüllungsgrad der jeweiligen Charakteristika entsprachen.148 Nachfolgend werden die Operationalisierungen der einzelnen Dimensionen im Detail betrachtet. Für die Dimension Architektur-Dokumentation wurden die in Tabelle 6.1 dargestellten Items verwendet. Diese spiegeln die wichtigsten Charakteristika eines idealen Dokumentationsprozesses wider. Hierzu zählen die Erfassung der wesentlichen Systemkomponenten und Beziehungen (DOC1-2), deren strukturierte und Werkzeug-unterstützte Ablage (DOC3-5) sowie eine regelmäßige Aktualisierung (DOC6). Die Operationalisierung der Dimension Architektur-Planung erfolgte anhand der in Tabelle 6.2 dargestellten Items. Diese adressieren die wesentlichen Eigenschaften eines idealen Planungsprozesses. Dazu gehören u. a. die Abdeckung aller wichtigen Architekturebenen und -domänen (PLN3-4), die Anwendung von systemtechnischen Gestaltungskonzepten (PLN2), die Berücksichtigung unterschiedlicher Zeithorizonte und Szenarien (PLN1) sowie die regelmäßige Aktualisierung der Pläne (PLN5). Für die Operationalisierung der Dimension Architektur-Programmierung wurden verschiedene Items von Boh und Yellin (2006) und Duncan (1995) wiederverwendet bzw. adaptiert.

148

So ist etwa eine vollständige und detaillierte Dokumentation der IT-Landschaft aufgrund des hohen Aufwandes wenig effektiv. Der optimale Erfüllungsgrad kann hier stattdessen in einer zeitnahen Erfassung (und Aktualisierung) der für die Architektursteuerung wesentlichen Elemente und Zusammenhänge gesehen werden (vgl. Tabelle 6.1).

Methodik

133

ARCHITEKTUR-DOKUMENTATION ID

Item

Skala

DOC1

We maintain architectural descriptions documenting the organization's key information processing ressources

DOC2

Our architectural descriptions reveal the major dependencies between business processes, applications, data and infrastructure components

DOC3

We employ graphical modelling languages (e. g., UML) to create (semi-) formal models of the Enterprise IT Architecture

5-Punkte-LikertSkala, begrenzt durch strongly agree / strongly disgree

DOC4

Our architectural descriptions are based on a common meta-model

DOC5

Architectural descriptions are stored within an integrated repository tool

DOC6

Our documentation of the Enterprise IT Architecture is updated continuously

Tabelle 6.1: Operationalisierung der Dimension Architektur-Dokumentation

ARCHITEKTUR-PLANUNG ID

Item

PLN1

We create target architecture plans for multiple scenarios and time horizons (e. g., 1-year-plan, 5-years-plan)

Referenz

PLN2

Architecture planning often involves the application of systems engineering concepts "in the large" (e. g., modularisation, decoupling)

PLN3

Architecture planning covers all relevant architectural domains (e. g., business, application, infrastructure and data architecture)

PLN4

Architecture planning is not restricted to certain segments of the overall IT landscape (e. g., loan applications)

PLN5

We frequently adjust architecture plans to better adapt them to changing conditions

Skala 5-Punkte-LikertSkala, begrenzt durch strongly agree / strongly disgree

Grover u. Segars (2005)

Tabelle 6.2: Operationalisierung der Dimension Architektur-Planung

Diese beziehen sich auf die verschiedenen Anwendungsbereiche von Richtlinien und Standards. Hierzu gehören allgemeine Architektur- bzw. Entwicklungsprinzipien (PRG1), Kataloge der zulässigen Standard-Komponenten (PRG2), Referenzarchitekturen (PRG3) sowie Daten- und Prozessstandards (PRG4-5).

134


ARCHITEKTUR-PROGRAMMIERUNG ID

Item

Referenz

Skala

PRG1

We make use of architecture principles to guide systems development and maintenance projects (e. g., service-orientation)

Boh u. Yellin (2006)

PRG2

Our organization employs standard catalogs to restrict the use of IT components and technologies (e. g., DBMS, operating systems)


PRG3

We utilize reference architectures to standardize the design of individual applications (e. g., Web Application Architecture)


PRG4

Our organization has defined data to be shared across business units

Duncan (2005)

PRG5

Our organization has determined business process components to be shared across business units

Duncan (2005)

Tabelle 6.3: Operationalisierung der Dimension Architektur-Programmierung

Die Operationalisierung der Dimension Architektur-Implementierung erfolgte anhand der in Tabelle 6.4 dargestellten Items. Item IMP1 bezieht sich dabei auf die generelle Möglichkeit durch Durchführung von Architektur-Projekten. Die übrigen Items adressieren die verschiedenen Ansatzpunkte für die Bereitstellung gemeinsamer Infrastrukturkomponenten.

ARCHITEKTUR-IMPLEMENTIERUNG ID

Item

Skala

IMP1

We may carry out non-business-driven projects to accelerate architectural transformations

IMP2

We build and maintain common integration infrastructures to facilitate application integration (e. g., EAI platform)


IMP3

We create and operate shared technical services (e. g., security)

IMP4

Our organization develops and maintains reusable application services

Tabelle 6.4: Operationalisierung der Dimension Architektur-Implementierung

Für die Operationalisierung der Dimension Architektur-Kommunikation & -Support wurden die in Tabelle 6.5 dargestellten Items verwendet. Diese beziehen sich sowohl auf die Ergebnisse der Architektur-Planung (COS1) als auch auf die geltenden Richtlinien und Standards. Dabei werden die unterschiedlichen Kommunikationskanäle von der Veröffentlichung (COS2) über Beratungsdienste (COS3) und Schulungsangebote (COS4) bis hin zu operativer Projektarbeit (COS5) abgedeckt.

Methodik

135

ARCHITEKTUR-KOMMUNIKATION & -SUPPORT ID

Item

Skala

COS1

Target architecture plans are communicated to all relevant stakeholder groups

COS2

The documentation of rules and standards can be accessed easily by all relevant stakeholders (e. g., via the intranet)

COS3

Stakeholders are provided with consulting services concerning the application of rules and standards


COS4

Architects work within projects to ensure the application of rules and standards

COS5

We arrange training courses for stakeholders to learn about rules and standards

Tabelle 6.5: Operationalisierung der Dimension Architektur-Kommunikation & Support

Die Operationalisierung der Dimension Architektur-Governance erfolgte anhand der in Tabelle 6.6 dargestellten Items. Diese adressieren sowohl die Planintegration und -konformität (GOV1-2) als auch die Einhaltung der geltenden Richtlinien und Standards (GOV3-8). Dabei wurden verschiedene Items von Grover und Segars (2005) sowie Boh und Yellin (2006) wiederverwendet.

ARCHITEKTUR-GOVERNANCE ID

Item

Referenz

Skala

GOV1

We constantly evaluate and review conformance to architecture plans


GOV2

Architecture Planning is well integrated with other IT planning activities (e. g., project portfolio management)

GOV3

We have in place well defined review and approval processes to ensure project conformance to rules and standards


GOV4

Internal directives require the compliance with rules and standards for all projects

GOV5

Violations of rules and standards are tracked and sanctioned consistently

GOV6

Projects violating rules and standards will not be approved

GOV7

Our organization uses formal processes to handle exceptions to rules and standards conformance

GOV8

Most of our rules and standards are mandatory



Tabelle 6.6: Operationalisierung der Dimension Architektur-Governance

136


ARCHITEKTUR-PARTIZIPATION ID

Item

PAR1

Business managers participate in the process of architecture planning

Referenz

PAR2

Target architecture plans are approved by governance committees representing all relevant stakeholders (e. g., architecture board)

PAR3

Top-management is actively involved in architecture planning

PAR4

Architecture planning is a relatively isolated organizational activity (INV) Grover u. Segars (2005)

PAR5

We ensure adequate stakeholder participation in setting rules and standards


PAR6

Business analysts are involved in the process of setting rules and standards


PAR7

Rules and standards are set by governance committees representing all relevant stakeholders (e. g., architecture board)

PAR8

Missing rules and standards are defined quickly when needed


Skala 5-Punkte-LikertSkala, begrenzt durch strongly agree / strongly disgree

Tabelle 6.7: Operationalisierung der Dimension Stakeholder-Partizipation

AM-DAUER ID

Item

Skala

Please estimate for how long your organization has been engaged in these activities in terms of a continuous process DUR1

Documenting the Enterprise IT Architecture, i. e. creating (and maintaining) architectural descriptions of the existing architecture

DUR2

Planning the Enterprise IT Architecture, i. e. creating (and maintaining) architectural descriptions of the future architecture

DUR3

Setting (and governing) architecture rules and standards (e. g., architecture principles, technical standards)

DUR4

Building (and maintaining) common infrastructure and / or application services (e. g., integration middleware, business services)

5-Punkte-Skala [10 Years, don't know]

Tabelle 6.8: Operationalisierung der AM-Dauer

Für die Operationalisierung der Dimension Stakeholder-Partizipation wurden schließlich die in Tabelle 6.7 dargestellten Items verwendet. Diese beziehen sich auf die Stakeholder-Beteiligung bei der Erstellung von Zielarchitektur-Plänen (PAR1-4) sowie bei der Festsetzung von Richtlinien und Standards (PAR5-8). Dabei wurden im ersten Fall Items des SISP Ap-

Methodik

137

proach nach Grover und Segars (2005) und im zweiten Fall Items von Boh und Yellin (2006) wiederverwendet. 6.2.2.2

AM-Dauer

Zur Umgehung von Definitions- bzw. Interpretationsschwierigkeiten wurde auch die AMDauer nach funktionalen (und nicht nach institutionellen) Gesichtspunkten operationalisiert. Als Bezugspunkt wurden dabei die vier primären Teilaufgaben Architektur-Dokumentation, Architektur-Planung, Architektur-Programmierung sowie Architektur-Implementierung verwendet. Die Studienteilnehmer sollten hierzu entsprechend die Zeitspanne des bisherigen Engagements abschätzen (s. Tabelle 6.8). 6.2.2.3

IT-Flexibilität

Zur Messung der IT-Flexibilität wurde eine Adaption des Messinstrumentes von Byrd und Turner (2000) verwendet. Dieses ist innerhalb der Information Systems Forschung bereits vielfach eingesetzt worden (u. a. von Chung et al., 2003, Chung et al., 2005, Ness, 2005 sowie Tallon und Kraemer, 2003). Bei der Auswahl der Items erfolgte eine Orientierung an der Relevanz bzw. der Inhaltsvalidität zum Zeitpunkt der Befragung.149 Die verwendeten Items sind in Tabelle 6.9 zusammengefasst. Sie können jeweils einer der drei Subdimensionen Konnektivität (CON1-4), Kompatibilität (COM1-5) sowie Modularität (MOD15) zugeordnet werden. 6.2.2.4

IT-Effizienz

Soweit bekannt, wurde innerhalb der Wirtschaftsinformatik bzw. dem Information Systems bisher kein Versuch zur Entwicklung eines Messinstrumentes für die IT-Effizienz unternommen. Dies überrascht angesichts der Bedeutung von Kostensenkungen und Effizienzsteigerungen für die Unternehmenspraxis. Messinstrumente wurden allerdings für die verwandten Konstrukte Komparative IT-Produktionskostenvorteile (z. B. Dibbern et al., 2005) sowie ITEffektivität entwickelt (z. B. Ness, 2005; Xia und King, 2004). Effizienz wurde darüber hinaus auch in anderen Wissenschaftszweigen operationalisiert.150 Ausgehend von der Definition aus Abschnitt 6.1.1.1 und unter Verwendung der oben genannten Quellen wurde für die vorliegende Studie ein neues Messinstrument für die IT-Effizienz

149 150

So kann ein Teil der ursprünglichen Items heute als veraltet gelten. So verwendet etwa Stock (2003) ein Instrument zur Messung der Team-Effizienz.

138


IT-FLEXIBILITÄT ID

Item

Referenz

Skala

CON1

Our organization has a high degree of systems interconnectivity

Tallon u. Kraemer (2003), Ness (2005)

CON2

Our organization provides multiple interfaces or entry points to external suppliers and customers (e. g., web access, EDI)

Byrd u. Turner (2000), Tallon u. Kraemer (2003), Ness (2005), Chung u. a. (2005)

5-Punkte-Likert-Skala, begrenzt durch strongly agree / strongly disgree

CON3

Computer hardware can easily be added to, modified, or removed from the existing IT infrastructure

Chung u. a. (2005)

CON4

New locations or acquisitions are quickly assimilated into our IT infrastructure

Byrd u. Turner (2000)

COM1

Our key applications are integrated using common integration middleware

Tallon u. Kraemer (2003), Ness (2005), Boh u. Yellin (2006)

COM2

Applications can be easily transported and used across multiple platforms

Byrd u. Turner (2000), Tallon u. Kraemer (2003), Ness (2005)

COM3

Our user interfaces provide transparent access to most applications

Byrd u. Turner (2000)

COM4

A common view of our customer is available to any authorized user

Byrd u. Turner (2000), Boh u. Yellin (2006)

COM5

Our business is not limited by our choice of operating system


MOD1

The development of new applications is facilitated by the existence of reusable application components (e. g., services)

Byrd u. Turner (2000), Tallon u. Kraemer (2003), Ness (2005), Chung u. a. (2005)

MOD2

Functionality can be quickly added to applications based on user requests

Tallon u. Kraemer (2003), Ness (2005)

MOD3

Business rules (e. g., pricing policies) are mainly hard-coded into applications (INV)


MOD4

Legacy systems complicate the development of new applications (INV)


MOD5

Our key business processes can be rearranged without major system changes

Tabelle 6.9: Operationalisierung der IT-Flexibilität

Methodik

139

IT-EFFIZIENZ ID

Item

Skala

EFF1

Our IT services are produced in a rather cost efficient way

EFF2

There is only little room for cutting IT costs without falling below the required level of service

EFF3

Our overall IT costs are lower than that of comparable competitors

5-Punkte-Likert-Skala, begrenzt durch strongly agree / strongly disgree

EFF4

We have a number of redundancies in our application landscape that could be removed in order to decrease IT costs (INV)

EFF5

There are various opportunities for lowering IT costs by standardizing system components and processes (INV)

Tabelle 6.10: Operationalisierung der IT-Effizienz

entwickelt. Dabei wurde eine eindimensionale Struktur zugrundegelegt (vgl. Tabelle 6.10). Die verwendeten Items nehmen jeweils aus unterschiedlichen Blickwinkeln Bezug auf die Definition der IT-Effizienz (vgl. Abschnitt 6.1.1.1). 6.2.2.5

Kontrollvariablen

Die betrachteten Zielgrößen IT-Flexibilität und IT-Effizienz können außer von der AM-Implementierung von einer Reihe weiterer Einflussfaktoren abhängig sein. Um eine Kontrolle entsprechender Drittvariableneffekte zu ermöglichen, wurden neben den exogenen und endogenen Variablen auch folgende Kontrollvariablen in die Untersuchung einbezogen: • Unternehmensgröße • Unternehmensalter • Dezentralisierungsgrad des Unternehmens • Diversifikationsgrad des Unternehmens • Wettbewerbsintensität • Häufigkeit von Fusionen und Übernahmen • Zentralisierungsgrad der IT-Funktion

140


KONTROLLVARIABLEN ID

Item

Referenz

Skala

SIZ

Please indicate the number of employees working for your organization

Chung u. a. (2005)

5-Punkte-Skala [50.000]

AGE

Our organization has a long-standing tradition

DEC

Our organization follows a divisional structure

DIV

Our organization operates in various different markets

CMP

Our organization operates in a very competitive environment

MER

Our organization has gone through a number of mergers and / or acquisitions in the past years

ITO

The IT function within our organization is mostly centralized

5-Punkte-Likert-Skala, begrenzt durch strongly agree / strongly disgree Chung u. a. (2005)


Tabelle 6.11: Operationalisierung Kontrollvariablen

Die Kontrollvariablen wurden mittels der in Tabelle 6.11 dargestellten Indikatoren gemessen. Darüber hinaus wurde die generelle Bedeutung verschiedener Ziele für die Unternehmen erhoben. Damit sollte insbesondere die unterstellte Flexibilitäts- und Effizienzorientierung verifiziert werden (vgl. Abschnitt 6.1.3). Die verwendeten Indikatoren sind zusammenfassend in Tabelle 6.12 dargestellt.

ZIELE ID

Item

Skala

Please indicate the general importance of the following objectives to your organization OBJ1

Reducing (and / or retaining) the overall IT costs

OBJ2

Improving (and / or maintaining) the overall efficiency of the IT function

OBJ3

Improving (and / or maintaining) the overall flexibility of IT

OBJ4

Improving (and / or maintaining) the aligment between business and IT

OBJ5

Reducing (and / or maintaining) IT complexity

OBJ6

Reducing (and / or retaining) the time-to-market

Tabelle 6.12: Operationalisierung Zielsetzungen

5-Punkte-LikertSkala, begrenzt durch very unimportant / very important

Methodik

141

6.2.3 Datenerhebung Aufgrund der Stichprobengröße erfolgte die Datenerhebung in schriftlicher Form. Hierzu wurde aus den für die Konstruktmessung erforderlichen Items ein Fragebogen mit einer Bearbeitungsdauer von ca. 20 Minuten erstellt. Die Gestaltung des Fragebogens orientierte sich an den Grundsätzen der Total Design Method nach Dillman (1978). So wurde insbesondere großer Wert auf ein einheitliches und seriöses Design sowie auf eine leichte Handhabung und Verständlichkeit gelegt. Hierzu wurde der Fragebogen um entsprechende Einstiegs- und Filterfragen ergänzt. Außerdem wurden Hinweise zur verwendeten Terminologie integriert. Die ursprüngliche Version des Fragebogens wurde von verschiedenen Forschern und Praktikern begutachtet. Deren Kommentare und Anregungen wurden anschließend in den Fragebogen eingearbeitet. Danach wurde ein Pretest mit mehreren Mitgliedern der Ziel-Population durchgeführt. Die Testteilnehmer wurden dabei gebeten, den Fragebogen auszufüllen und währenddessen alle ihre Gedanken laut zu artikulieren (”Thinking-Aloud-Test”). Auf diese Weise konnten Verständnisschwierigkeiten und sonstige auftretende Probleme ermittelt werden. Nach Abschluss des Tests wurden die Teilnehmer darüber hinaus um eine allgemeine Beurteilung des Fragebogens im Hinblick auf Inhalt, Länge und Design sowie um entsprechende Verbesserungsvorschläge gebeten. Auf der Grundlage des Teilnehmer-Feedbacks wurde der Fragebogen schrittweise überarbeitet. Dabei wurden mehrere Items gelöscht und der Fragebogen insgesamt deutlich gestrafft. Der Pretest wurde nach der vierten Iteration beendet, da keine substantielle Revision mehr notwendig war. Die finale Version des Fragebogens wurde anschließend in Form eines Online-Fragebogens (HTML) implementiert. Hierfür wurde die Standardsoftware Globalpark Surveycenter 5.0 eingesetzt. Zusätzlich wurde eine Papier-Version erstellt (PDF). Beide Versionen wurden anschließend über ein Studien-Portal im World Wide Web (WWW) zugänglich gemacht. Das Studienportal beinhaltete neben den Fragebögen zusätzliche Hintergrund-Informationen über das Forschungsprojekt und die beteiligten Wissenschaftler. Der Zugang zum Portal wurde über spezielle Teilnahmecodes (”Tokens”) reglementiert. Dadurch konnten ein unauthorisierter Zugang sowie eine Mehrfachteilnahme ausgeschlossen werden. Vor dem endgültigen Studienstart wurde noch ein Pilot-Test mit 10% der Zielpopulation durchgeführt. Der Pilot-Test ergab eine Rücklaufquote von 10% innerhalb von einer Woche und ohne Nachfassen. Dies wurde als Indiz für eine ausreichend hohe Gesamt-Beteiligung gewertet. Da ansonsten keine Probleme auftraten, wurde die Studie anschließend sukzessive ausgerollt.

142


Die Datenerhebung erfolgte zwischen Januar und Juli 2007. Die Teilnehmer wurden dabei jeweils per E-Mail zur Studienteilnahme eingeladen. Das Anschreiben enthielt eine kurze Beschreibung der Forschungsziele sowie einen Link zum Studien-Portal. Als Anreiz für eine Studienteilnahme wurde den Teilnehmern weiterhin ein kostenloser Forschungsbericht zu den Studienergebnissen versprochen. Es wurden jeweils zwei Nachfassaktionen durchgeführt in Intervallen von ca. zwei bis vier Wochen. Insgesamt wurden 85 Fragebögen vollständig ausgefüllt. Dies entspricht einer Quote von 17% bezogen auf die Zielpopulation. Die Rücklaufquote liegt damit im oberen Bereich der bei vergleichbaren Studien üblichen Resultate.151 Mit 36% war die Rücklaufquote in den deutschsprachigen Ländern (Deutschland, Schweiz, Österreich) besonders hoch. 6.2.4

Datenanalyse

Die Auswertung der Daten erfolgte zunächst mit den Mitteln der deskriptiven Statistik. Zur Prüfung der postulierten Hypothesen wurde anschließend der Partial-Least-Squares-Ansatz (PLS) nach Wold eingesetzt. Im Folgenden wird zunächst die Auswahl des Verfahrens begründet. Anschließend wird der PLS-Ansatz kurz vorgestellt. 6.2.4.1

Auswahl des Verfahrens

Für die Untersuchung komplexer Wirkungszusammenhänge hat sich in den Sozial- und Wirtschaftswissenschaften innerhalb der letzten Jahre die Analyse von Strukturgleichungsmodellen (Structured Equation Modeling, SEM) zu einem Quasi-Standard entwickelt (vgl. Bliemel et al., 2005b, S. 10). Entsprechende Verfahren werden dabei in Abgrenzung zu den traditionellen Verfahren der multivariaten Statistik (wie etwa der Multiplen Regression, der Varianzanalyse oder der Faktoranalyse) häufig als multivariate Verfahren der zweiten Generation bezeichnet (vgl. Fornell, 1987, S. 412). Multivariate Verfahren der zweiten Generation verfügen gegenüber den traditionellen Verfahren über eine Reihe von Vorteilen (vgl. hierzu z. B. Chin und Newsted, 1999, S. 308). Sie erlauben insbesondere eine simultane Analyse der Wirkbeziehungen zwischen mehreren Variablen. Die vermuteten Beziehungen werden hierzu in Form eines linearen Gleichungssystems formuliert (Strukturgleichungssystem bzw. Strukturmodell). Auf diese Weise lassen sich auch komplexe Zusammenhänge untersuchen. Darüber hinaus wird der Einsatz von la-

151

Nach einer Untersuchung von Harzing (1997) liegen die Quoten bei internationalen Mail-Surveys typischerweise nur zwischen 6% und 16%.

Methodik

143

tenten, d. h. nicht direkt messbaren, Variablen unterstützt. Die Beziehungen zwischen den latenten Variablen und den zu ihrer Messung eingesetzten Indikatoren werden hierzu ebenfalls in Form eines linearen Gleichungssystem spezifiziert (Messgleichungssystem bzw. Messmodell). Ausgehend von der Modellspezifikation liegt das Ziel der SEM-Verfahren in der Schätzung der Modellparameter anhand vorliegender empirischer Daten. Dabei erfolgt eine integrierte Betrachtung von Struktur- und Messmodellen. Auf diese Weise ist eine explizite Berücksichtigung von Messfehlern möglich, wodurch tendenziell eine höhere Modellgüte erreicht werden kann (vgl. Gefen et al., 2000, S. 4). Innerhalb der SEM-Verfahren können im Wesentlichen zwei Ansätze unterschieden werden: die Varianzstrukturanalyse und die Kovarianzstrukturanalyse. Ziel der weit verbreiteten Kovarianzstrukturanalyse ist eine möglichst gute Reproduktion der Kovarianzstruktur der Ausgangsdatenmatrix (Herrmann et al., 2006, S. 38). Unter der Annahme einer korrekten Modellspezifikation ermöglicht das Verfahren dabei eine optimale Parameterschätzung. Es eignet sich daher vor allem für die konfirmatorische Forschung, d. h. die Überprüfung ausgereifter und theoretisch fundierter Forschungsmodelle (vgl. Gefen et al., 2000, S. 24f.). Die Kovarianzstrukturanalyse stellt allerdings auch sehr hohe Anforderungen an die empirischen Daten. So wird insbesondere eine Multinormalverteilung der manifesten Variablen vorausgesetzt (Chin und Newsted, 1999, S. 309). Darüber hinaus sind verhältnismäßig große Stichproben erforderlich, um konsistente Parameterschätzungen zu erhalten.152 Eine flexible Alternative zur Kovarianzstrukturanalyse stellt die Varianzstrukturanalyse in Form des PLS-Ansatzes dar. Im Gegensatz zur Kovarianzstrukturanalyse liegt das primäre Ziel hier in der Maximierung der erklärten Varianz (R2 ) der abhängigen Variablen. PLS eignet sich daher besser für vorhersage-orientierte Anwendungen sowie für die TheorieEntwicklung (Gefen et al., 2000, S. 25). Gleichzeitig sind die Anforderungen an die empirischen Daten deutlich moderater. So wird insbesondere keine Normalverteilungsannahme getroffen. Darüber hinaus sind deutlich kleinere Stichproben möglich.153 Aufgrund der besseren Eignung wurde im Rahmen der vorliegenden Studie der PLS-Ansatz verwendet. Eine wesentliche Rolle für die Auswahl spielten die geringeren Anforderungen an die Stichprobengröße. Außerdem handelt es sich bei dem betrachteten Untersuchungsgegenstand um ein noch weitgehend unerschlossenes Forschungsfeld, für das bisher keine geschlossene Theorie im Sinne einer konfirmatorischen Forschung existiert. Stattdessen adressiert die Studie eine eher managementorientierte Problemstellung mit Entscheidungs-

152 153

Typischerweise werden 200 Fälle als Untergrenze angesehen (vgl. Chin und Newsted, 1999, S. 314). Als Untergrenze werden hier häufig nur 30 - 50 Fälle genannt.

144


relevanz. Das primäre Interesse liegt daher auf einer guten Erklärung der Veränderung bzw. Vorhersage der Zielvariablen (Herrmann et al., 2006, S. 45; Fornell und Bookstein, 1982, S. 443). Hierfür ist PLS aufgrund einer stärkeren Orientierung an den empirischen Daten deutlich besser geeignet. 6.2.4.2

Der PLS-Ansatz

Der PLS-Ansatz wurde 1977 von Wold konzipiert und anschließend von verschiedenen Autoren weiterentwickelt (Chin und Newsted, 1999, S. 315). Aufgrund der vergleichsweise großen Flexibilität im Hinblick auf seine Anwendung hat das Verfahren in den letzten Jahren innerhalb der betriebswirtschaftlichen Forschung zunehmend an Bedeutung gewonnen. Dies gilt insbesondere für den Bereich des Information Systems (vgl. z. B. Marcoulides und Saunders, 2006). Im Folgenden werden kurz die wesentlichen Charakteristika des PLS-Ansatzes vorgestellt. Für eine detailliertere Darstellung sei an dieser Stelle auf die einschlägige Literatur verwiesen (z. B. Chin, 1998; Chin und Newsted, 1999; Götz und Liehr-Gobbers, 2004; Bliemel et al., 2005a). Wie bei SEM-Verfahren üblich, können in PLS zunächst zwei Modellebenen unterschieden werden: die Ebene des Strukturmodells sowie die Ebene des Messmodells (siehe Abbildung 6.2). Das Strukturmodell (auch als inneres Modell bezeichnet) beschreibt dabei die hypothetisierten Beziehungen zwischen den betrachteten exogenen und endogenen Variablen. Das Messmodell (auch als äußeres Modell bezeichnet) beinhaltet dagegen die Beziehungen zwischen den latenten Variablen und den zu ihrer Messung eingesetzten Indikatoren. Eine Besonderheit von PLS stellt die Unterstützung von Konstrukten zweiter Ordnung (Second Order Factors) dar. Hierbei werden einfache Konstrukte zu einem übergeordneten Faktor aggregiert. Dies ermöglicht eine problemadäquate Abbildung komplexer Sachverhalte. Konstrukte zweiter Ordnung können dabei insbesondere auch als Mediatoren zur Bündelung einer Reihe von exogenen Faktoren dienen (Dibbern, 2004, S. 140). Auf diese Weise lässt sich die Modellkomplexität deutlich reduzieren. Der PLS-Algorithmus umfasst im Wesentlichen zwei Stufen.154 In der ersten Stufe werden konkrete Schätzwerte für die latenten Variablen (”Component Scores”) generiert. Hierzu werden zusätzliche Gewichtungskoeffizienten eingeführt, mit deren Hilfe sich die latenten Variablen als gewichtete Summe der manifesten Variablen ausdrücken lassen (Betzin und Henseler, 2005, S. 54). Diese Gewichtskoeffizienten werden nun in einem ite-

154

Vgl. hierzu im Folgenden ausführlich Betzin und Henseler (2005).

Methodik

145

δ11

x11

δ12

x12

δ13

x13

ξ1

ζ

η

δ21

x21

δ22

x22

δ23

x23

y1

ε1

y2

ε2

y3

ε3

ξ2

Messmodell der exogenen Variablen

Strukturmodell

Messmodell der endogenen Variablen

Abbildung 6.2: Strukturgleichungsmodell in PLS

rativen Verfahren geschätzt. Ausgehend von einer (trivialen) Ausgangslösung werden dazu in jeder Iteration für alle latenten Variablen die Component Scores jeweils abwechselnd aus dem Messmodell (äußere Approximation) sowie aus dem Strukturmodell (innere Approximation) heraus neu berechnet und anschließend die entsprechenden Gewichtskoeffizienten aktualisiert (vgl. Chin, 1998, S. 302). Hierzu werden auf lokaler Ebene jeweils einfache bzw. multiple Regressionen durchgeführt (daher die Bezeichnung partiell). Auf diese Weise werden jeweils die Residualvarianzen minimiert. Die erste Stufe endet, sobald die Gewichte ein definiertes Konvergenzkriterium erreicht haben. Ausgehend von den geschätzten Gewichten bzw. den daraus resultierenden Component Scores werden auf der zweiten Stufe des Verfahrens die eigentlichen Modellparameter bestimmt (Betzin und Henseler, 2005, S. 50). Hierzu werden wiederum gewöhnliche einfache bzw. multiple Regressionen durchgeführt. Das Ergebnis bilden Schätzer für die Pfadkoeffizienten des Strukturmodells sowie die Indikatorladungen des Messmodells. Die Pfadkoeffizienten beschreiben dabei die Stärke der Beziehungen im Strukturmodell. Die Itemladungen hingegen beziehen sich auf den Zusammenhang zwischen einem Indikator und seinem jeweiligen Konstrukt.

146


Trotz der iterativen Vorgehensweise ist die Lösung des PLS-Verfahrens hinsichtlich der Erklärungskraft des Gesamtmodells optimal (Götz und Liehr-Gobbers, 2004, S. 722). Aufgrund der fehlenden Verteilungsannahmen existieren für PLS jedoch keine globalen Gütemaße bezüglich der Modellanpassung. Die Modellbeurteilung erfolgt daher zum einen über die Vorhersagekraft in Bezug auf die abhängigen Variablen. Hierfür ist jeweils das Bestimmtheitsmaß (d. h. der Anteil der erklärten Varianz) der abhängigen Variablen zu ermitteln. Weiterhin kann die Prognoserelevanz mit Hilfe des Stone-Geisser-Tests überprüft werden. Darüber hinaus sind Höhe und Vorzeichen der Modellparameter zu untersuchen. Die Stabilität der geschätzten Parameter ist dabei mit Hilfe von nicht-parametrischen ResamplingVerfahren wie Bootstrapping oder Jackknifing zu bestimmen.155 Aufgrund der iterativen Vorgehensweise und der partiellen Natur des Verfahrens sind die Anforderungen an die Stichprobengröße minimal. Diese richten sich ausschließlich nach den jeweils durchgeführten OLS-Regressionen (vgl. Chin und Newsted, 1999, S. 326ff.). Ausschlaggebend für den notwendigen Stichprobenumfang ist daher das Maximum der in ein Konstrukt eingehenden Variablen bzw. formativen Indikatoren.156 In Abhängigkeit von der vermuteten Effektstärke kann über eine entsprechende Power-Analyse (Cohen, 1988) auf die Anzahl der notwendigen Fälle geschlossen werden. Als ”Daumenregel” werden dabei üblicherweise zehn Fälle pro Predikator angegeben (vgl. Chin, 1998, S. 311; Chin und Newsted, 1999, S. 327). 6.2.4.3

Anwendung

Die Anwendung des PLS-Verfahrens erfolgte auf Basis der Standard-Software SmartPLS 2.0 (Ringle et al., 2005). Ausgehend von den Hypothesen H1a – H2b wurde hierzu zunächst ein entsprechendes Strukturmodell erzeugt. Anschließend wurden die Messmodelle gemäß der Operationalisierung aus Abschnitt 6.2.2 spezifiziert. Um eine problemadäquate Abbildung der komplexen Konstrukte AM-Ansatz und IT-Flexibilität zu gewährleisten, wurde hierfür jeweils ein Faktor zweiter Ordnung angelegt. Für das Konstrukt IT-Flexibilität wurde dabei in Übereinstimmung mit Byrd und Turner (2000) ein molekularer Ansatz gewählt.157 Der AM-Ansatz wurde hingegen im molaren Modus spezifiziert, da sich die einzelnen Dimensionen nicht notwendigerweise gegenseitig beeinflussen,

155 156 157

Siehe hierzu z. B. Efron und Tibshirani (1993). In der grafischen Darstellung entspricht dies der größten Anzahl der in ein Modellkonstrukt eingehenden Pfeile. Zu den unterschiedlichen Möglichkeiten bei der Modellierung von Konstrukten höherer Ordnung siehe Chin und Gopal (1995).


147

sondern weitgehend unabhängige Elemente darstellen (vgl. Chin und Gopal, 1995, S. 59). Für die Messung der Konstrukte zweiter Ordnung wurde jeweils der ”Repeated Indicator Approach” nach Wold (1982) verwendet. Vor der Durchführung der Datenanalyse wurde eine Datenbereinigung durchgeführt. Dabei wurden drei Datensätze aufgrund von inhaltlichen Inkonsistenzen bzw. aufgrund von Ausreißern von der weiteren Analyse ausgeschlossen. Die Anforderungen an die Stichprobengröße wurden durch den resultierenden Datensatz problemlos erfüllt. Die Parameterschätzung erfolgte zunächst auf Basis der vollständigen Indikatormenge. Zur Optimierung der Güteeigenschaften wurden anschließend in einem iterativen Prozess einzelne Items entfernt. Die Auswahl der Items orientierte sich dabei an den in Abschnitt 6.3.4.1 dargestellten Kriterien. Zur Ausbalancierung der Konstrukte zweiter Ordnung wurde weiterhin eine Angleichung der Indikatorzahl auf Dimensionsebene vorgenommen. Die Parameter des Strukturmodells wurden durch diese Maßnahmen nur unwesentlich beeinflusst. Für die Signifikanzprüfung der Modellparameter wurde der Bootstrapping-Algorithmus eingesetzt. Dabei wurden 500 Resamples von der Größe der Originalstichprobe erzeugt.

6.3 Empirische Ergebnisse In diesem Kapitel werden die empirischen Ergebnisse der quantitativen Studie vorgestellt. Dazu werden zunächst die Stichprobeneigenschaften untersucht. Es folgt eine deskriptive Analyse ausgewählter Datenelemente. Hieran schließt sich die Evaluierung des Forschungsmodells und die Prüfung der Hypothesen an. 6.3.1

Stichprobencharakteristik

Die Abbildungen 6.3 bis 6.5 zeigen die Verteilung der Stichprobe nach Regionen, Geschäftsfeldern sowie Unternehmensgröße. Wie aus Abbildung 6.3 ersichtlich ist, stammen die Studienteilnehmer aus insgesamt 17 Ländern. Der Schwerpunkt liegt dabei auf Deutschland (31%) und der Schweiz (18%). Dies kann einerseits auf die geografische Nähe und die höhere Bekanntheit der durchführenden Forschungseinrichtung, andererseits aber auch auf die vergleichsweise große Anzahl von Finanzdienstleistern in diesen Ländern zurückgeführt werden. Etwa 30% der Teilnehmer haben ihren Hauptsitz in anderen europäischen Staaten. Die restlichen 21% verteilen sich auf Nordamerika (16%) und Australien (5%).

148


Germany (31%) Switzerland (18%) United States (14%) Australia (5%) Spain (5%) United Kingdom (4%) Sweden (4%) Norway (4%) Austria (4%) Denmark (2%) Canada (2%) Italy (2%) Greece (2%) Belgium (1%) Netherlands (1%) Ireland (1%) Portugal (1%)

Abbildung 6.3: Teilnehmer nach Regionen

Die Stichprobe umfasst alle Arten von Finanzdienstleistern, angefangen von reinen Kreditbanken (23%) über Universalbanken (22%), Allfinanzkonzerne (20%), Versicherungen (18%) bis hin zu reinen Investmentbanken (6%). Der Grundgesamtheit entsprechend handelt es sich bei den Unternehmen jeweils um mittlere bis große Organisationen. So verfügten nur 11% der Teilnehmerunternehmen zum Zeitpunkt der Befragung über weniger als 1.000 Mitarbeiter. Etwa ein Viertel der Stichprobe bilden Großkonzerne mit mehr als 25.000 Mitarbeitern und einer Bilanzsumme von bis zu 1,5 Bil. USD. 6.3.2

Qualitätskriterien

Die gleichzeitige Messung der exogenen sowie der endogenen Variablen unter Verwendung des selben Messinstrumentes und bei den selben Zielpersonen bildet im Rahmen der vorliegenden Studie eine potentielle Quelle für Common Methods Bias (allgemeiner Methodenfehler). Zur näheren Untersuchung dieser Problematik wurde Harman’s Single Factor Test durchgeführt (Harman, 1967). Die Analyse ergab 20 Faktoren mit einem Eigenwert größer eins. Der Anteil der erklärten Varianz der Faktoren lag dabei jeweils zwischen 2% und 10%. Der Verdacht auf Common Methods Bias konnte daher nicht erhärtet werden.158

158

Nach Harman (1967) liegt Common Methods Bias dann vor, wenn die Analyse einen einzelnen Faktor ergibt, welcher einen Großteil der Varianz erklärt.


149

Commercial Bank (23%) Investment Bank (6%) Universal Bank (22%) Insurance (18%) Allfinance (20%) Other (11%)

Abbildung 6.4: Teilnehmer nach Geschäftsfeldern

< 1.000 Employees (11%) 1.001 - 10.000 Employees (46%) 10.001 - 25.000 Employees (19%) 25.001 - 50.000 Employees (15%) > 50.000 Employees (9%)

Abbildung 6.5: Teilnehmer nach Anzahl Mitarbeiter

150


Die Stichprobe wurde weiterhin auf Non-Response-Bias getestet. Non-Response-Bias bezeichnet systematische Verzerrungen, die aufgrund der Teilnahmeverweigerung bestimmter Teilnehmergruppen entstehen können. Non-Response-Bias wurde durch einen Vergleich zwischen Früh- und Spätantwortern geprüft. Dieser Ansatz basiert auf der Annahme, dass Teilnehmer, die weniger bereitwillig sind zu antworten, Totalverweigerern ”ähnlicher” sind (Armstrong und Overton, 1977). Für den Test wurden alle Studienteilnehmer nach der Zeitspanne zwischen der jeweiligen Ersteinladung und dem Eingang des vollständigen Fragebogens sortiert. Auf Basis dieser Sortierung wurden die 25% frühesten und die 25% spätesten Antworten miteinander in allen Variablen verglichen. Hierbei zeigten sich keine signifikanten Unterschiede (t-Test, p < 0.05). Stichprobenverzerrungen aufgrund von Teilnahmeverweigerungen konnten damit nicht nachgewiesen werden. Die Stichprobe kann daher im Hinblick auf die Modellvariablen als repräsentativ bezüglich der Grundgesamtheit angesehen werden. 6.3.3

Deskriptive Analyse

In diesem Abschnitt wird zunächst eine deskriptive Analyse der Daten vorgenommen. Dazu werden die Häufigkeitsverteilungen ausgewählter Variablen betrachtet. Diese eröffnen einen umfassenden Einblick in die internationale Praxis des Architekturmanagements. 6.3.3.1

Implementierungsdauer und Ziele

Wie aus Abbildung 6.6 ersichtlich ist, werden Aufgaben des Architekturmanagements in fast allen befragten Unternehmen wahrgenommen. Dabei ist innerhalb der letzten ein bis sechs Jahre ein klarer Anstieg zu verzeichnen. Nur etwa 10% der Firmen verfügen über eine Historie von über zehn Jahren. Interessanterweise liegt die Anwendungsdauer im Bereich der Architektur-Dokumentation und -Planung im Durchschnitt etwas unterhalb der anderen Aufgabenfelder. Gemäß Tabelle 6.13 werden alle erhobenen Ziele von der überwiegenden Mehrheit der Teilnehmer als wichtig bzw. sehr wichtig eingestuft. So konnte insbesondere die hohe Bedeutung effizienz- und flexibilitätsbezogener Ziele bestätigt werden.159

159

Die Erhöhung bzw. Aufrechterhaltung von IT-Effizienz und IT-Flexibilität wurde nur von jeweils 4% der Unternehmen als eher unwichtig bezeichnet.


151

Architektur-Dokumentation

Architektur-Planung

50%

50%

40%

40%

30%

30%

20%

20%

10%

10%

0%

0% not at all

10 Years Years Years Years

not at all

1-3 4-6 7-10 > 10 Years Years Years Years

Architektur-Implementierung

Architektur-Programmierung 50%

50%

40%

40%

30%

30%

20%

20%

10%

10%

0%

Management komplexer IT-Architekturen: Empirische Analyse am Beispiel der internationalen Finanzindustrie

Neugestaltung von Unternehmensnetzwerken in der Finanzindustrie am Beispiel Anlagegeschäft

Am Beispiel meines Bruders

Am beispiel meines bruders

Erfolg von Wirtschaftsverbänden: Am Beispiel der Schweiz

Integrierte Kommunikation in mehrstufigen Markten. Theoretische und empirische Analyse am Beispiel der Schweizer Mobilfunkbranche (Basler Schriften zum Marketing, 22)

Wissensbasierte Montageplanung in der Digitalen Fabrik am Beispiel der Automobilindustrie

Originäre Ausgründungen aus etablierten Unternehmen: Eine empirische Analyse der Ausgründungsentscheidung

Die Auswirkungen der Nachhaltigkeitsberichterstattung auf den Kapitalmarkt: Eine empirische Analyse

Ökonomische Wirkungen einer Veräußerungsgewinnbesteuerung: Eine empirische Analyse

Empirische Analyse sozialer Probleme: Das wissenssoziologische Programm

Unternehmens-Podcasting. Eine empirische Analyse ausgewählter Erfolgsfaktoren

Philosophie und Nationalsozialismus - am Beispiel Heideggers

Die internationale Politische Okonomie des Risikos: Eine Analyse am Beispiel der Diskussion um die Reformierung der Finanzmarkte

Vertrauensentwicklung im interkulturellen Management: Ein empirischer Beitrag am Beispiel der deutsch-französischen Zusammenarbeit

Wertschöpfung durch Kundenintegration: Eine empirische Untersuchung am Beispiel von Strukturierten Finanzierungen

Ein prozessorientiertes Modell zur Verrechnung von Facility Management Kosten am Beispiel der Funktionsstelle Operations

Management kulturubergreifender Geschaftsbeziehungen: Eine Untersuchung am Beispiel der Zusammenarbeit zwischen deutschen und chinesischen Unternehmen

Qualitätsmessung in Dienstleistungscentern: Konzeptionierung und empirische Überprüfung am Beispiel eines Verkehrsflughafens

Kennzahlenmodell zur Erfolgsbewertung des E-Commerce: Analyse am Beispiel eines Mehrkanaleinzelhandlers

Wettbewerb durch Netzzugang?: Eine ökonomische Analyse am Beispiel des deutschen Briefmarktes

Automobile Erlebniswelten als Kommunikationsmittel: Eine verhaltenswissenschaftliche Analyse am Beispiel des Premiummarktes in Deutschland und Singapur

Tarifwahlverhalten im Business-to-Business-Bereich. Empirisch gestützte Analyse am Beispiel Mobilfunktarife

Internationalisierung mit produktbegleitenden Dienstleistungen und hybriden Produkten: Eine pfadorientierte Analyse am Beispiel deutscher Maschinenbauunternehmungen

Betriebsbegleitende Prozessplanung in der Montage mit Hilfe der Virtuellen Produktion am Beispiel der Automobilindustrie

Modellierung komplexer Gebaudefassaden in der Computergraphik

Analyse der Unternehmensumwelt im Dienstleistungssektor: Empfehlungen zur Methodenselektion und -erweiterung am Beispiel großer Finanzdienstleistungsunternehmen auf Basis einer empirischen Untersuchung

Internetbasierte Anwendungen in der FuE-Kooperation. Eine empirische Analyse basierend auf der Adaptive Structuration Theory

Modellierung komplexer Gebaudefassaden in der Computergraphik

Kulturelle Grundlagen der Medialisierung in Sudkorea: Eine qualitative Studie am Beispiel der Fernsehnutzung

Von der nationalen zur internationalen Literatur

Management komplexer IT-Architekturen: Empirische Analyse am Beispiel der internationalen Finanzindustrie

Neugestaltung von Unternehmensnetzwerken in der Finanzindustrie am Beispiel Anlagegeschäft

Am Beispiel meines Bruders

Am beispiel meines bruders

Erfolg von Wirtschaftsverbänden: Am Beispiel der Schweiz

Integrierte Kommunikation in mehrstufigen Markten. Theoretische und empirische Analyse am Beispiel der Schweizer Mobilfunkbranche (Basler Schriften zum Marketing, 22)

Wissensbasierte Montageplanung in der Digitalen Fabrik am Beispiel der Automobilindustrie

Originäre Ausgründungen aus etablierten Unternehmen: Eine empirische Analyse der Ausgründungsentscheidung

Die Auswirkungen der Nachhaltigkeitsberichterstattung auf den Kapitalmarkt: Eine empirische Analyse

Ökonomische Wirkungen einer Veräußerungsgewinnbesteuerung: Eine empirische Analyse

Empirische Analyse sozialer Probleme: Das wissenssoziologische Programm

Unternehmens-Podcasting. Eine empirische Analyse ausgewählter Erfolgsfaktoren

Philosophie und Nationalsozialismus - am Beispiel Heideggers

Die internationale Politische Okonomie des Risikos: Eine Analyse am Beispiel der Diskussion um die Reformierung der Finanzmarkte

Vertrauensentwicklung im interkulturellen Management: Ein empirischer Beitrag am Beispiel der deutsch-französischen Zusammenarbeit

Wertschöpfung durch Kundenintegration: Eine empirische Untersuchung am Beispiel von Strukturierten Finanzierungen

Ein prozessorientiertes Modell zur Verrechnung von Facility Management Kosten am Beispiel der Funktionsstelle Operations

Management kulturubergreifender Geschaftsbeziehungen: Eine Untersuchung am Beispiel der Zusammenarbeit zwischen deutschen und chinesischen Unternehmen

Qualitätsmessung in Dienstleistungscentern: Konzeptionierung und empirische Überprüfung am Beispiel eines Verkehrsflughafens

Kennzahlenmodell zur Erfolgsbewertung des E-Commerce: Analyse am Beispiel eines Mehrkanaleinzelhandlers

Wettbewerb durch Netzzugang?: Eine ökonomische Analyse am Beispiel des deutschen Briefmarktes

Automobile Erlebniswelten als Kommunikationsmittel: Eine verhaltenswissenschaftliche Analyse am Beispiel des Premiummarktes in Deutschland und Singapur

Tarifwahlverhalten im Business-to-Business-Bereich. Empirisch gestützte Analyse am Beispiel Mobilfunktarife

Internationalisierung mit produktbegleitenden Dienstleistungen und hybriden Produkten: Eine pfadorientierte Analyse am Beispiel deutscher Maschinenbauunternehmungen

Betriebsbegleitende Prozessplanung in der Montage mit Hilfe der Virtuellen Produktion am Beispiel der Automobilindustrie

Modellierung komplexer Gebaudefassaden in der Computergraphik

Analyse der Unternehmensumwelt im Dienstleistungssektor: Empfehlungen zur Methodenselektion und -erweiterung am Beispiel großer Finanzdienstleistungsunternehmen auf Basis einer empirischen Untersuchung

Internetbasierte Anwendungen in der FuE-Kooperation. Eine empirische Analyse basierend auf der Adaptive Structuration Theory

Modellierung komplexer Gebaudefassaden in der Computergraphik

Kulturelle Grundlagen der Medialisierung in Sudkorea: Eine qualitative Studie am Beispiel der Fernsehnutzung

Von der nationalen zur internationalen Literatur

Recommend Documents