Wertorientiertes Management von IT-Architekturen 9783835055162, 383505516X, 9783835008953, 3835008951 [PDF]

Zitiervorschau

Michael Durst Wertorientiertes Management von IT-Architekturen

WIRTSCHAFTSINFORMATIK

Michael Durst

Wertorientiertes Management von IT-Architekturen Mit einem Geleitwort von Prof. Dr. Freimut Bodendorf

Deutscher Universitäts-Verlag

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

Dissertation Universität Erlangen-Nürnberg, 2007

1. Auflage Dezember 2007 Alle Rechte vorbehalten © Deutscher Universitäts-Verlag | GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Frauke Schindler / Anita Wilke Der Deutsche Universitäts-Verlag ist ein Unternehmen von Springer Science+Business Media. www.duv.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-8350-0895-3

Geleitwort Die hohe Komplexität der Informationstechnologie bereitet den Chief Information Officers zunehmend Kopfzerbrechen. Die Fachbereiche fordern die schnelle Integration von über Jahrzehnte gewachsenen Applikationslandschaften zur Beschleunigung der Wertschöpfungsketten. Gleichzeitig soll die Informationstechnologie einerseits mit hoher Flexibilität auf neue Geschäftsmodelle reagieren und diese ermöglichen und andererseits zu geringen Kosten verfügbar sein. Unternehmenszusammenschlüsse und -auflösungen, kurze Lebenszyklen von Softwareprodukten und neue Organisationsformen in Entwicklung und Betrieb von Applikationen sind zusätzliche Herausforderungen an die IT-Bereiche. Der effiziente und effektive IT-Einsatz steht nach Jahren der steigenden IT-Budgets wieder im Vordergrund. Die Balance aus Flexibilität und Kosteneffizienz verlangt nach Transparenz, technologischen und organisatorischen Standards und nach neuen Methoden zur Steuerung der IT. Geschäftsprozesse, Fachabteilungen, Landesgesellschaften, Applikationen und Informationstechnologien stehen in einem komplexen Wirkzusammenhang. Dieses Buch widmet sich der Strukturierung dieses Wirkgeflechts mit dem Ziel der Transparenz und damit der Möglichkeit zur Komplexitätsreduktion in der IT. Der Autor betrachtet die Verflechtungen zwischen Geschäft und IT sowohl statisch als auch dynamisch. Die statische Betrachtung resultiert in einem Modell zur Strukturierung und Verwaltung der IT-Architektur im Unternehmen. Aus der dynamischen Betrachtung folgt ein Vorgehensmodell zur Reduzierung der Komplexität in der IT auf ein Maß, das gleichzeitig Flexibilität und Kosteneffizienz ermöglicht. Kennzahlen zur Bewertung und Steuerung der IT-Architektur ergänzen die Modelle. Eine vom Autor entwickelte Software veranschaulicht die Anwendung der vorgestellten Modelle im Unternehmen. Dank der Kombination aus wissenschaftlicher Methodik mit zahlreichen Praxisbeispielen ist dieses Buch für Wissenschaftler und Praktiker, die sich mit dem Thema Management von IT-Architekturen auseinandersetzen, lesenswert.

Prof. Dr. Freimut Bodendorf

Vorwort Die vorliegende Arbeit entstand während meiner Zeit als wissenschaftlicher Mitarbeiter am Lehrstuhl Wirtschaftsinformatik II der Friedrich-Alexander-Universität Erlangen-Nürnberg. Neben den Aufgaben in Forschung und Lehre hatte ich während dieser Zeit die Gelegenheit, mit der damaligen Siemens Business Services GmbH & Co. OHG und der BIK Beratungsgesellschaft für Informations- und Kommunikationsmanagement mbH Beratungsprojekte durchführen zu dürfen. Die Forschungslücke einerseits und die Erfahrungen in unterschiedlichen Unternehmen andererseits haben zum Thema dieser Arbeit geführt. Für viele wertvolle Hinweise, anregende Diskussionen und kritische Anmerkungen im Laufe der Jahre danke ich meinem Doktorvater Prof. Dr. Freimut Bodendorf. Herzlicher Dank gebührt auch Prof. Dr. Michael Amberg für das Korreferat und die hervorragende Beratung bezüglich des Feinschliffs der Ausarbeitung. Helmut Bindel, Harald Hertneck, Dr. Jürgen Klein, Dr. Stefan Reinheimer und Stefan Krappen haben mich an ihrem Wissen teilhaben lassen und waren zu jeder Zeit hilfsbereite Ansprechpartner. Dank ihnen und vielen weiteren ehemaligen Kollegen aus der Unternehmensberatung haben die in dieser Arbeit beschriebenen Konzepte und Realisierungsansätze eine hohe praktische Relevanz - danke! Viele ehemalige Kolleginnen und Kollegen an der Universität haben einen bedeutenden Beitrag zu dieser Arbeit geleistet. Besonderen Dank schulde ich Dr. Christian Bauer, Prof. Dr. Peter Bradl, Hinnerk Brügmann, Dr. Robert Butscher, Daniel Frohschammer, Kai-Uwe Götzelt, Prof. Dr. Susanne Robra-Bissantz, Dr. Mustafa Soy und Stefan Winkler. Robert, .DL8ZH XQG -XOLDQ .HFN ZDUHQ GLH EHVWHQ %URNROOHJHQ GLH PDQ VLFK YRUVWHOOHQ NDQQ ± danke schön dafür! Ich bedanke mich weiterhin herzlichst bei Hinnerk, Jochen Gary und Stephan Maget, die mit ihren Studien- und Diplomarbeiten einen erheblichen Beitrag zu dieser Arbeit geleistet haben. Stets hilfsbereit, humorvoll und motivierend sind mir Angelika Helle, Brigitte Knobloch, Dr. Florian Lang, Dr. Marc Langendorf, Dr. Manfred Schertler-Rock, Dr. Andreas Schobert, Dr. Sascha Uelpenich, Dr. Bernd Weiser und Dr. Roland Zimmermann zur Seite gestanden.

VIII

Vorwort

Mit dem einen oder anderen Bier werde ich mich die nächsten Jahre über erkenntlich zeigen! Ohne Claudia Schlenker hätte ich diese Arbeit wahrscheinlich nie fertig bekommen, vielen herzlichen Dank dafür. Meine kleine Schwester Ilona hat ihre Doktorarbeit dann doch noch vor mir abgegeben, ich gratuliere ihr herzlich und danke ihr für die vielen anregenden Gespräche und Diskussionen! Meine Eltern Heidi und Eugen haben die Arbeit ermöglicht, ihnen ist sie gewidmet.

Dr. Michael Durst

Inhaltsverzeichnis Abbildungsverzeichnis .........................................................................................XV Tabellenverzeichnis..............................................................................................XIX Abkürzungsverzeichnis .......................................................................................XXI 1

Einführung ........................................................................................................ 1

1.1

Problemstellung ............................................................................................ 1

1.2

Zielsetzung und Vorgehensweise................................................................ 4

1.3

Aufbau der Arbeit.......................................................................................... 5

2

Komplexität von IT-Architekturen ................................................................... 9

2.1

Komplexität im Allgemeinen ........................................................................ 9

2.2

Komplexität in der IT................................................................................... 12

2.2.1

Komplexitätstreiber ................................................................................ 13

2.2.2

Auswirkungen auf Kosten und Erlöse .................................................... 16

2.3

IT-Organisation ........................................................................................... 18

2.3.1

Standardisierungsproblem ..................................................................... 23

2.3.2

Zentralisierung/ Dezentralisierung ......................................................... 26

2.4 3

Komplexitätsmanagement ......................................................................... 30 Modellierung von IT-Architekturen ............................................................... 33

3.1

Übersicht ..................................................................................................... 33

3.2

Begriffsbestimmung ................................................................................... 34

3.3

Betrachtete Ebenen .................................................................................... 38

3.4

IT-Bebauungsplan....................................................................................... 38

3.5

IT-Infrastruktur ............................................................................................ 46

3.6

Übergreifendes Modell ............................................................................... 53

3.7

IT-Architektur-Management ....................................................................... 53

X

Inhaltsverzeichnis

3.7.1

IT-Architektur-Management-Prozesse ................................................... 54

3.7.2

IT-Architektur im Zeitverlauf ................................................................... 56

4

Strategiekonforme IT-Projekte ...................................................................... 57

4.1

Übersicht ..................................................................................................... 57

4.2

Ausgangssituation...................................................................................... 58

4.3

IT-Strategieobjekte...................................................................................... 59

4.4

Evaluation der Strategiekonformität von IT-Projekten ............................ 61

4.4.1

Voraussetzungen ................................................................................... 61

4.4.2

Aufbau der Evaluation............................................................................ 61

4.4.3

Herleitung der Evaluationselemente ...................................................... 62

4.4.4

Beschreibung der Evaluationselemente................................................. 64

4.4.5

Festlegen der Gewichtung ..................................................................... 66

4.4.6

Berechnen des Strategic Fit Index ......................................................... 67

4.4.7

Visualisierung der Ergebnisse ............................................................... 67

4.5 5

Ablauf........................................................................................................... 68 Bewertung von IT-Architekturen ................................................................... 71

5.1

Übersicht ..................................................................................................... 71

5.2

Ausgangssituation...................................................................................... 72

5.2.1

Bedeutung von Technologiestandards................................................... 73

5.2.1.1 Skaleneffekte...................................................................................... 73 5.2.1.2 Verbundeffekte ................................................................................... 74 5.2.1.3 Erfahrungskurveneffekte .................................................................... 74 5.2.2 5.3

IT-Architektur-Vertrag ............................................................................ 74

Kennzahlen zur Bewertung der IT-Architektur-Konformität.................... 75

5.3.1

Konformität der Softwarearchitektur....................................................... 75

5.3.2

Bewertung der Technologien ................................................................. 77

5.3.3

Bewertung einzelner Applikationen........................................................ 79

5.3.4

Bewertung der Applikationslandschaft ................................................... 80

5.4

Kennzahlen zur Bewertung der Zukunftsfähigkeit................................... 81

5.4.1

Erfüllung der Technologieanforderungen............................................... 81

5.4.2

Verwendungsintensität der Cluster ........................................................ 82

Inhaltsverzeichnis

5.4.3 5.5

XI

Bewertung der Soll-IT-Infrastruktur ........................................................ 82

Bewertung von IT-Projekten ...................................................................... 83

5.5.1

Einführung neuer Applikationen ............................................................. 83

5.5.2

Integrationsprojekte ............................................................................... 86

5.5.3

Erneuerungsprojekte.............................................................................. 86

5.5.4

Erweiterungsprojekte ............................................................................. 87

5.6 6

Anwendung der Kennzahlen...................................................................... 87 Wertbeitrag von IT-Architekturen.................................................................. 89

6.1

Übersicht ..................................................................................................... 89

6.2

Ausgangssituation...................................................................................... 90

6.3

Wertbeitrag der IT ....................................................................................... 90

6.3.1

Wertbeitrag der IT als Ganzes ............................................................... 92

6.3.2

Wertbeitrag einzelner Investitionsvorhaben ........................................... 92

6.4

Wirkung der IT-Architektur......................................................................... 93

6.4.1

Effizienz und Effektivität......................................................................... 93

6.4.2

Einfluss der IT-Architektur...................................................................... 94

6.5

Bestimmung des Wertbeitrags .................................................................. 97

6.5.1

Abstand zur Wertschöpfung................................................................... 98

6.5.2

Messung des Wertbeitrags .................................................................... 98

6.5.3

Ganzheitlichkeit/ Zurechnung ................................................................ 98

6.5.4

Datenbeschaffung.................................................................................. 99

6.5.5

Prognoseproblem................................................................................... 99

6.5.6

Zeitliche Verzögerung ............................................................................ 99

6.6

Vorhandene Bewertungsansätze............................................................... 99

6.6.1

Ansatz von Principia .............................................................................. 99

6.6.2

Ansatz von Leser, Scheibehenne und Alt ............................................ 100

6.6.3

Ansatz von Birkhölzer und Vaupel ....................................................... 102

6.6.4

Bewertung............................................................................................ 102

6.7

Kennzahlen................................................................................................ 103

6.7.1

Reifegradmodell für die IT-Architektur ................................................. 105

6.7.2

Gestaltungsziele der IT-Architektur...................................................... 108

XII

Inhaltsverzeichnis

6.7.2.1 Gestaltungsziele der IT-Infrastruktur ................................................ 108 6.7.2.2 Gestaltungsziele der IT-Bebauungsplanung .................................... 109 6.7.3

Qualitative Nutzenanalyse ................................................................... 110

6.7.3.1 Wirkungsbereiche............................................................................. 110 6.7.3.2 Wirkungsdimensionen ...................................................................... 111 6.7.3.3 Zusammenhänge zwischen den Wirkungsbereichen ....................... 111 6.7.3.4 IT-Beschaffung ................................................................................. 112 6.7.3.5 IT-Betrieb ......................................................................................... 113 6.7.3.6 IT-Projekte........................................................................................ 117 6.7.3.7 IT-Planung........................................................................................ 121 6.7.3.8 Unterstützung der Geschäftsprozesse ............................................. 123 6.7.3.9 Strategische Optionen...................................................................... 127 6.7.4

Kennzahlen für die IT-Architektur......................................................... 129

6.7.4.1 Kennzahlen und Kennzahlensysteme .............................................. 129 6.7.4.2 Spezifische Kennzahlen der IT-Infrastruktur .................................... 131 6.7.4.3 Spezifische Kennzahlen des IT-Bebauungsplans ............................ 133 6.7.4.4 Allgemeine Kennzahlen der IT-Infrastruktur ..................................... 135 6.7.4.5 Allgemeine Kennzahlen des IT-Bebauungsplans ............................. 137 6.7.4.6 Kennzahlengruppen ......................................................................... 140 6.7.5

Spezifikation der Ist- und Soll-IT-Architektur........................................ 143

6.7.5.1 Festlegen von Zielen mittels IT-Architektur-Kennzahlen .................. 143 6.7.5.2 Bestimmung der Zielerfüllung........................................................... 144 6.7.5.3 Identifikation von Handlungsbedarfen .............................................. 146 6.7.6

Bewertung der Soll-IT-Architektur ........................................................ 150

6.7.6.1 Nutzenbestimmung .......................................................................... 151 6.7.6.2 Kosten der IT-Architektur ................................................................. 152 6.7.6.3 Wertbeitrag von IT-Architektur-Zielen............................................... 153 6.7.6.4 Ausgewählte IT-Architektur-Kennzahlen als Treiber ........................ 156 6.7.6.5 Wertbeitrag von IT-Architektur-Maßnahmen .................................... 159 6.7.6.6 Gesamtbetrachtung.......................................................................... 163 6.8

Implementierung ....................................................................................... 165

6.8.1

Bewertung der IT-Architektur ............................................................... 165

6.8.2

Steuerung der IT-Architektur................................................................ 166

7 7.1

IT-Architektur-Management-Portal.............................................................. 167 Übersicht ................................................................................................... 167

Inhaltsverzeichnis

XIII

7.2

Ausgangssituation.................................................................................... 168

7.3

Anforderungen .......................................................................................... 168

7.4

Softwarearchitektur .................................................................................. 171

7.4.1

Framework........................................................................................... 171

7.4.2

Benutzerschnittstelle............................................................................ 173

7.4.3

Applikationsserver................................................................................ 174

7.4.4

Datenbankserver.................................................................................. 175

7.5

Modellierung.............................................................................................. 175

7.5.1

Datenmodell......................................................................................... 175

7.5.2

Administration ...................................................................................... 179

7.5.3

Reporting ............................................................................................. 179

7.5.3.1 Listen................................................................................................ 179 7.5.3.2 Bebauungsplan ................................................................................ 180 7.5.3.3 IT-Infrastruktur.................................................................................. 181 7.5.3.4 Hyperbolischer Browser ................................................................... 183 7.5.3.5 Lebenszyklen ................................................................................... 184 7.5.4 7.6

Controlling............................................................................................ 185

Implementierung ....................................................................................... 187

7.6.1

Datenmodell......................................................................................... 187

7.6.2

Administration ...................................................................................... 191

7.6.3

Reporting ............................................................................................. 192

7.6.4

Controlling............................................................................................ 193

7.6.5

Benutzeroberfläche.............................................................................. 194

7.6.5.1 Symbole ........................................................................................... 195 7.6.5.2 Navigation ........................................................................................ 196 7.7

Anwendungsfälle ...................................................................................... 201

7.7.1

Hinzufügen einer neuen Applikation .................................................... 201

7.7.2

Hinzufügen einer neuen Technologie .................................................. 204

7.7.3

Hinzufügen von Plattformen................................................................. 206

7.7.4

Hinzufügen von Clustern...................................................................... 206

7.7.5

Hinzufügen von Layern ........................................................................ 206

7.7.6

Hinzufügen von Prozessen und Sparten.............................................. 207

XIV

Inhaltsverzeichnis

7.8

Evaluation.................................................................................................. 207

7.9

Anwendung ............................................................................................... 209

8

Schlussbemerkungen .................................................................................. 213

8.1

Zusammenfassung ................................................................................... 213

8.2

Ausblick ..................................................................................................... 214

Literaturverzeichnis............................................................................................. 217 Anhang ................................................................................................................. 241

Abbildungsverzeichnis Abbildung 1-1

Gestaltungsdimensionen der IT..................................................................5

Abbildung 1-2

Vorgehensmodell........................................................................................6

Abbildung 2-1

Auswirkungen steigender Komplexität .....................................................11

Abbildung 2-2

Einordnung des IT-Bereichs in das Gesamtunternehmen........................12

Abbildung 2-3

Klassifizierung von Komplexitätstreibern ..................................................14

Abbildung 2-4

Principal-Agent-Beziehungen im Unternehmen........................................19

Abbildung 2-5

IT-Bereich mit zentralen und dezentralen Abteilungen.............................27

Abbildung 2-6

Prozess der Applikationseinführung .........................................................28

Abbildung 2-7

Variant Mode and Effects Analysis ...........................................................30

Abbildung 3-1

Einordnung von Kapitel 3 .........................................................................33

Abbildung 3-2

ISA-Konzept als Kreiselmodell .................................................................36

Abbildung 3-3

Stufenkonzept hierarchischer Prozessmodelle.........................................37

Abbildung 3-4

Abbildung der Architekturebenen .............................................................38

Abbildung 3-5

IT-Bebauungsplan (schematisch) .............................................................39

Abbildung 3-6

Klassifikation von Softwarekarten.............................................................40

Abbildung 3-7

IT-Bebauungsplan (Beispiel) ....................................................................42

Abbildung 3-8

Softwarekarte mit sehr hoher Komplexität................................................44

Abbildung 3-9

IT-Bebauungsplan (Prozessvergrößerung) ..............................................45

Abbildung 3-10

Teil-Bebauungsplan (Beispiel)..................................................................45

Abbildung 3-11

Strukturierung der IT-Infrastruktur ............................................................47

Abbildung 3-12

IT-Infrastruktur (Beispiel) ..........................................................................48

Abbildung 3-13

IT-Infrastruktur (Beispiel 1 für Layer Middleware).....................................48

Abbildung 3-14

IT-Infrastruktur (Beispiel 2 für Layer Middleware).....................................49

Abbildung 3-15

IT-Infrastruktur (Beispiel für Plattform E-Business) ..................................50

Abbildung 3-16

Typische IT-Architektur mit monolithischen Applikationen .......................51

Abbildung 3-17

IT-Architektur mit Plattformen ...................................................................52

Abbildung 3-18

Modell der IT-Architektur als Entity-Relationship-Diagramm ....................53

Abbildung 3-19

Vorgehensmodell des IT-Architektur-Managements ................................55

Abbildung 4-1

Einordnung von Kapitel 4 .........................................................................57

Abbildung 4-2

Unterschiedliche Zielsysteme im IT-Bereich.............................................58

Abbildung 4-3

Ableiten von Strategieobjekten.................................................................59

XVI

Abbildungsverzeichnis

Abbildung 4-4

Strategieobjekte einer IT-Strategie ...........................................................60

Abbildung 4-5

Hierarchischer Aufbau der Evaluation ......................................................62

Abbildung 4-6

Konzept der Ermittlung von Evaluationselementen ..................................63

Abbildung 4-7

Evaluation auf verschiedenen Planungsebenen.......................................63

Abbildung 4-8

Standardisierte Bewertung der Evaluationselemente...............................64

Abbildung 4-9

Detaillierung der Zielevaluation ................................................................66

Abbildung 4-10

Visualisierung mit der Konformitätsspinne................................................68

Abbildung 4-11

Prozess der Evaluation.............................................................................68

Abbildung 5-1

Einordnung von Kapitel 5 .........................................................................71

Abbildung 5-2

Bestandteile der Bewertung von IT-Architekturen ....................................72

Abbildung 5-3

Zusammenhang der Kennzahlen .............................................................73

Abbildung 5-4

Berechnung der Auswirkung neuer Applikationen (Beispiel)....................84

Abbildung 6-1

Einordnung von Kapitel 6 .........................................................................89

Abbildung 6-2

Ansatzpunkte für Verbesserungen durch IT (Beispiele) ...........................91

Abbildung 6-3

Verfahren zur IT-Investitionsanalyse und -entscheidung..........................93

Abbildung 6-4

Wirkung der IT-Architektur auf die IT-Leistung .........................................94

Abbildung 6-5

Wertbeitrag des IT-Architektur-Managements..........................................96

Abbildung 6-6

Monetäre Effekte der IT-Architektur..........................................................97

Abbildung 6-7

Ansatz von PRINCIPA...............................................................................100

Abbildung 6-8

Ansatz von LESER, SCHEIBEHENNE und ALT............................................100

Abbildung 6-9

Wirkungsnetzwerk ..................................................................................101

Abbildung 6-10

Vergleich des IT-Nutzens mit und ohne explizite IT-Architektur .............104

Abbildung 6-11

Zusammenhang zwischen Gestaltung und Wirkung der IT-Architektur ..........................................................................................108

Abbildung 6-12

Zusammenhänge zwischen den Wirkungsbereichen .............................112

Abbildung 6-13

Wirkung der IT-Architektur auf die Kosten in der IT-Beschaffung ..........112

Abbildung 6-14

Wirkung der IT-Architektur auf die Flexibilität in der IT-Beschaffung......113

Abbildung 6-15

Wirkung der IT-Architektur auf die Kosten im IT-Betrieb ........................114

Abbildung 6-16

Wirkung der IT-Architektur auf die Qualität im IT-Betrieb .......................116

Abbildung 6-17

Wirkung der IT-Architektur auf die Flexibilität im IT-Betrieb ...................117

Abbildung 6-18

Wirkung der IT-Architektur auf den Zeitbedarf bei IT-Projekten .............118

Abbildung 6-19

Wirkung der IT-Architektur auf die Kosten von IT-Projekten ..................120

Abbildung 6-20

Wirkung der IT-Architektur auf die Qualität in IT-Projekten ....................121

Abbildung 6-21

Wirkung der IT-Architektur auf den Zeitbedarf der IT-Planung...............122

Abbildung 6-22

Wirkung der IT-Architektur auf die Qualität der IT-Planung....................123

Abbildung 6-23

Wirkung der IT-Architektur auf die Kosten der Geschäftsprozessunterstützung..........................................................................................124

Abbildung 6-24

Wirkung der IT-Architektur auf die Qualität der Geschäftsprozessunterstützung..........................................................................................125

Abbildungsverzeichnis

Abbildung 6-25

XVII

Wirkung der IT-Architektur auf die Flexibilität der Geschäftsprozessunterstützung..........................................................................................127

Abbildung 6-26

Wirkung der IT-Architektur auf strategische Optionen............................128

Abbildung 6-27

Anwendung der IT-Architektur-Kennzahlen............................................130

Abbildung 6-28

Analyse zum Handlungsbedarf Standardisierung der Technologien (Beispiel).................................................................................................147

Abbildung 6-29

Analyse des Streuungsgrades (Beispiel)................................................149

Abbildung 6-30

Zusammenhang zwischen Zielen, Maßnahmen und Wertbeitrag ..........151

Abbildung 6-31

Gestaltung und Bewertung der IT-Architektur ........................................152

Abbildung 6-32

IT-Architektur-Benchmarking ..................................................................155

Abbildung 6-33

Abschätzung der Kosteneinsparungen in der IT-Beschaffung ...............156

Abbildung 6-34

Abschätzung der Kosteneinsparungen im IT-Betrieb .............................157

Abbildung 6-35

Abschätzung der Kosteneinsparungen bei IT-Projekten ........................158

Abbildung 6-36

Abschätzung der Kosteneinsparungen bei der IT-Unterstützung der Geschäftsprozesse...........................................................................159

Abbildung 6-37

Bewertung von einzelnen IT-Architektur-Maßnahmen ...........................161

Abbildung 6-38

Vorgehen bei einer Cluster-Standardisierung (Beispiel).........................162

Abbildung 6-39

Gesamtbetrachtung der IT-Architektur-Wirkung .....................................163

Abbildung 6-40

Bewertungs- und Steuerungsprozess ....................................................165

Abbildung 7-1

Einordnung von Kapitel 7 .......................................................................167

Abbildung 7-2

Funktionsweise des ITMAP-Frameworks ...............................................173

Abbildung 7-3

Technologien im ITMAP-Framework ......................................................175

Abbildung 7-4

Entity-Relationship-Diagramm für ITMAP...............................................178

Abbildung 7-5

Technologieliste in ITMAP ......................................................................180

Abbildung 7-6

Bebauungsplan in ITMAP .......................................................................181

Abbildung 7-7

IT-Infrastruktur in ITMAP ........................................................................182

Abbildung 7-8

Liste der Prozesse in ITMAP ..................................................................183

Abbildung 7-9

Hyperbolischer Browser .........................................................................184

Abbildung 7-10

Soll-Lebenszyklus einer Technologie .....................................................185

Abbildung 7-11

Variablenbelegung durch den Anwender in ITMAP................................187

Abbildung 7-12

Relationenmodell....................................................................................189

Abbildung 7-13

Klassendiagramm der Datenabstraktion ................................................190

Abbildung 7-14

Listengenerierung...................................................................................191

Abbildung 7-15

Dynamisch generiertes Diagramm in ITMAP..........................................192

Abbildung 7-16

Ähnliche Plattformen ..............................................................................194

Abbildung 7-17

Bereiche der Benutzeroberfläche ...........................................................195

Abbildung 7-18

Symbole in ITMAP ..................................................................................196

Abbildung 7-19

Reporting-Übersicht in ITMAP ................................................................197

Abbildung 7-20

Controlling-Übersicht in ITMAP ..............................................................198

Abbildung 7-21

&OXVWHUGHWDLODQVLFKWLQ0DVNHÄ%HOHJXQJ&OXVWHU³ 198

XVIII

Abbildungsverzeichnis

Abbildung 7-22

0DVNHÄ.HQQ]DKOHQ3ODWWIRUPHQ³ 199

Abbildung 7-23

0DVNHÄ7HFKQRORJLHQGLHYRQ3ODWWIRUPHQYHUZHQGHWZHUGHQ³200

Abbildung 7-24

$QZHQGHUOLVWH 200

Abbildung 7-25

3UR]HVVÄ$SSOLNDWLRQDQOHJHQ³ 202

Abbildung 7-26

0DVNHÄ$SSOLNDWLRQEHDUEHLWHQ³ 203

Abbildung 7-27

0DVNHÄ'RNXPHQWDWLRQHUVWHOOHQ³ 204

Abbildung 7-28

3UR]HVVÄ7HFKQRORJLH]X$SSOLNDWLRQ]XZHLVHQ³ 205

Abbildung 7-29

0DVNHÄ&OXVWHUHUVWHOOHQ³206

Abbildung 7-30

0DVNHÄ3UR]HVVHUVWHOOHQ³ 207

Abbildung 7-31

3UR]HVVÄ,73URMHNWIUHLJHEHQ³210

Abbildung 8-1

9HUlQGHUXQJGHU,7$UFKLWHNWXUGXUFK,7$UFKLWHNWXU0DQDJHPHQW 214

Tabellenverzeichnis Tabelle 2-1

Pay-Off-Matrix beim Standardisierungsdilemma ......................................24

Tabelle 2-2

Pay-Off-Matrix beim Standardisierungsdilemma mit Beispielwerten ........25

Tabelle 2-3

Pay-Off-Matrix bei dezentraler Struktur ....................................................29

Tabelle 2-4

Pay-Off-Matrix bei dezentraler Struktur mit Beispielwerten ......................29

Tabelle 5-1

IT-Architektur-Vertrag ...............................................................................75

Tabelle 5-2

Beispielhafte Softwarearchitektur der Applikation Online-Shop ...............76

Tabelle 5-3

Soll-/ Ist-Vergleich Online-Shop................................................................77

Tabelle 5-4

Bewertung des Fit.....................................................................................78

Tabelle 5-5

Begründungen für die Bewertung des Fit .................................................79

Tabelle 5-6

Bewertung einer Applikation mit dem AAF ...............................................80

Tabelle 5-7

Berechnung des AFI (Beispiel).................................................................81

Tabelle 5-8

Berechnung des TRF ...............................................................................82

Tabelle 5-9

Berechnung der Verwendungsintensität...................................................82

Tabelle 5-10

Kosten-Nutzen-Bilanz von Integrationsprojekten......................................86

Tabelle 5-11

Berechnung des Nutzens von Erneuerungsprojekten ..............................87

Tabelle 5-12

Kennzahlenübersicht ................................................................................88

Tabelle 6-1

Bewertung von Ansätzen zur Bemessung des Nutzens von IT-Architektur-Maßnahmen.....................................................................103

Tabelle 6-2

Reifegradmodell für das IT-Architektur-Management (Level 1 und 2)........................................................................................106

Tabelle 6-3

Reifegradmodell für das IT-Architektur-Management (Level 0 und 3 - 5) ..................................................................................107

Tabelle 6-4

Betrachtete Wirkungsdimensionen .........................................................111

Tabelle 6-5

Spezifische Kennzahlen der IT-Infrastruktur...........................................132

Tabelle 6-6

Spezifische Kennzahlen des IT-Bebauungsplans ..................................134

Tabelle 6-7

Allgemeine Kennzahlen der IT-Infrastruktur (Teil 1) ...............................136

Tabelle 6-8

Allgemeine Kennzahlen der IT-Infrastruktur (Teil 2) ...............................137

Tabelle 6-9

Allgemeine Kennzahlen des IT-Bebauungsplans (Teil 1).......................138

Tabelle 6-10

Allgemeine Kennzahlen des IT-Bebauungsplans (Teil 2).......................139

Tabelle 6-11

Kennzahl BA.A.4.2 (Beispiel) .................................................................139

Tabelle 6-12

Kennzahlengruppen der IT-Infrastruktur.................................................141

XX

Tabellenverzeichnis

Tabelle 6-13

Kennzahlengruppen des IT-Bebauungsplans.........................................142

Tabelle 6-14

Bestimmung der Zielerfüllung für eine Kennzahlengruppe (Beispiel).....145

Tabelle 6-15

Projekterfahrungen (Beispiele) ...............................................................154

Tabelle 6-16

Benchmark der HACKETT GROUP (Beispiel) ............................................156

Tabelle 7-1

Entitätstypen im Datenmodell von ITMAP ..............................................177

Tabelle 7-2

Kennzahlen in ITMAP .............................................................................186

Tabelle 7-3

Nomenklatur des Datenmodells in der Implementierung........................188

Tabelle 7-4

Anforderungserfüllung von ITMAP..........................................................208

Abkürzungsverzeichnis AA

Architektur-Artefakt

AAF

Application Architectural Fit

AFI

Application Fitness Index

AHP

Analytical Hierarchy Process

API

Application Programming Interface

CAD

Computer Aided Design

CIO

Chief Information Officer oder Chief Information Office

CMS

Content Management System

CRM

Customer Relationship Management

CPU

Central Processing Unit

DAO

Datenabstraktionsobjekt

DB

Database

DBMS

Database Management System

DMAV

Data Model Action View Framework

DV

Datenverarbeitung

EA

Enterprise Architecture

ERM

Enterprise Resource Management

ERP

Enterprise Resource Planning

ETL

Extract, Transform, Load

EVA

Economic Value Added

FB

Fachbereich

FTE

Full Time Equivalent

FTP

File Transfer Protocol

GIS

Geoinformationssystem

GPS

Global Positioning System

HTML

Hypertext Markup Language

IE

Internet Explorer

IM

Informationsmanagement

IRR

Internal Rate of Return

IS

Informationssystem

ISA

Informationssystem-Architektur

XXII

Abkürzungsverzeichnis

ISO

International Organization for Standardization

IT

Informationstechnologie

ITIL

Information Technology Infrastructure Library

ITMAP

IT-Architektur-Management-Portal

IuK

Information und Kommunikation

IV

Informationsverarbeitung

IVB

IV-Bereich

JDBC

Java Database Connectivity

KMS

Knowledge Management System

LAMP

Linux, Apache, MySQL, PHP

LAN

Local Area Network

M&A

Mergers & Acquisitions

MS

Microsoft

MVC

Model View Controller

NOA

Net Operating Assets

NOPAT

Net Operating Profit after Taxes

NPV

Net Present Value

ODBC

Open Database Connectivity

OLAP

Online Analytical Processing

OR

Operations Research

OS

Operating System

OSI

Open Systems Interconnection Reference Model

PDF

Portable Document Format

PHP

Hypertext Preprocessor

PNG

Portable Network Graphics

REJ

Rapid Economic Justification

ROI

Return on Investment

RSS

Really Simple Syndication

SAN

Storage Area Network

SCM

Supply Chain Management

SFI

Strategic Fit Index

SHU

Schaden, Haftpflicht, Unfall

SMS

Short Message Service

SQL

Structured Query Language

SO

Strategieobjekt

SSO

Single Sign-On

SUV

Sports Utility Vehicle

SVG

Scalable Vector Graphics

SW

Software

TCO

Total Cost of Ownership

Abkürzungsverzeichnis

TOGAF

The Open Group Architecture Framework

TRF

Technology Requirement Fulfillment

TRFI

Technology Requirement Fulfillment Index

TVO

Total Value of Opportunity

UML

Unified Modeling Language

URL

Uniform Ressource Locator

VBA

Visual Basic for Applications

WACC

Weighted average Cost of Capital

WAN

Wide Area Network

WAP

Wireless Application Protocol

WMS

Workflow Management System

XHTML

Extensible Hypertext Markup Language

XML

Extensible Markup Language

XXIII

Kapitel 1 Einführung 1 Einführung 1.1

Problemstellung

Unternehmen aller Branchen gaben im Jahr 2005 durchschnittlich fünf Prozent 1 ihres Umsatzes für Informationstechnologie (IT) aus [Gomo05, 16], weltweit sind ein Drittel aller Investitionen IT-bezogen [MaSS03, 59]. Dabei wird der Anteil der IT-Ausgaben, der für Innovationen eingesetzt wird, im Verhältnis zu dem Anteil, der für den laufenden Betrieb der Informationstechnologie verwendet wird, immer kleiner [Mill02]. Viele Autoren geben bis zu 80 Prozent als nicht-wahlfreie IT-Ausgaben vom Gesamtbudget an [Gans04, 400; ZaSB04, 181]. Diese Quote hat sich in den vergangenen Jahren laufend erhöht [Niem05, 31; Pfei03, 43]. In Kombination mit einer Stagnation der IT-Budgets [DiSc04, 1; MSBA02, 9; Dern03, 12] heißt das, dass für IT-getriebene Innovationen immer weniger Budget zur Verfügung steht 2. Um dieses Dilemma 3 zu beseitigen, müssen einerseits der Betriebskostenanteil des IT-Budgets bei mindestens gleich bleibender Qualität verringert und andererseits das wahlfreie Budget effizient eingesetzt werden. Dazu sind zum einen Ineffizienzen im IT-Betrieb zu beseitigen und zum anderen unternehmensweite ITStandards

zur

Vereinfachung

und

Beschleunigung

der

Softwareentwicklung

und

-implementierung einzuführen. Der Wertbeitrag der IT entsteht nach Dietrich durch die Bereitstellung einer auf die Unternehmensstrategie angepassten Infrastruktur, der Geschäftsprozessgestaltung durch die

1

2

3

Es finden sich auch abweichende Angaben, z. B. ein bis zehn Prozent bei [Karg03, 379] oder 0,5 - 25 Prozent bei [KaÖs06, 277]. Nach einem stetigen Anstieg der IT-Ausgaben in den 1990er Jahren [ZaBG04, 3] ist in den letzten Jahren je nach Branche eine Abschwächung des Anstiegs oder gar eine Reduzierung zu beobachten [Gomo05, 5 f.]. MAYER ET AL. sprechen in einer Studie aus dem Jahr 2 YRQGHUÄ,QYHVWLWLRQVIDOOH³ 'LH QLFKW wahlfreien Ausgaben für die IT steigen bei stagnierenden Budgets. Dadurch bleibt immer weniger Budget für Investitionen übrig [MSBA02, 9].

2

Einführung

IT und durch die Unterstützung von betrieblichen Innovationen [Diet04, 46 f.]. Die ITArchitektur als Ä*HVDPWKHLWDOOHU.RPSRQHQWHQ7HFKQRORJLHQXQGRUJDQLVDWRULVFKHQ0D‰ QDKPHQ >«@ GLH GLH LP 8QWHUQHKPHQ YRUNRPPHQGHQ )XQNWLRQHQ 3UR]HVVH XQG 'DWHQ DEELOGHQ XQG GHUHQ =XVDPPHQVSLHO HUP|JOLFKHQ´ [KrSe03, 29] hat dabei innerhalb der IT den gleichen Stellenwert wie die Architektur im klassischen Sinne für ein Neubaugebiet: Nachdem die grobe Vorstellung der Bebauung bekannt ist (Einsatzzweck der Gebäude für Industrie oder Wohnen, geplante Bewohnerzahl, zu bebauende Fläche), werden Architekten beauftragt, die Bebauung inklusive der Infrastruktur zu entwerfen. Der Architekt bestimmt dabei nicht, ob ein Freibad oder ein Bürgerzentrum entstehen soll, sondern nur, wo und in welcher Ausgestaltung unter gegebenen Rahmenbedingungen es entstehen wird. In der Umsetzung ist der Architekt als Berater beteiligt und sorgt für die Einhaltung der Pläne. Ebenso bestimmt die IT-Architektur nicht die Geschäftsprozesse, sondern liefert lediglich die Pläne für die Bebauung und die Infrastruktur der IT im Unternehmen. Sie unterstützt damit indirekt auch die IT-getriebenen Innovationen, indem die Infrastruktur so konstruiert wird, dass innovative Technologien schnell und kostengünstig eingeführt werden können. Das genannte Neubaugebiet hätte im übertragenen Sinne ausreichende Energie-, Verkehrs- und Abwasserkapazität, um das Freibad später um ein Hallenbad zu ergänzen. Eine Umgehungsstraße kann nahtlos an eine Autobahn angebunden werden und das bestehende Müllverbrennungskraftwerk wird endlich voll ausgelastet. Ineffizienzen im IT-Betrieb entstehen durch einen hohen Komplexitätsgrad und ITInnovationen werden durch fehlende Technologiestandards erschwert [Diet06, 232; Nati05, 1; HaSW04, 56]. Die über die letzten 30 Jahre beständig zunehmende Anzahl an ITDienstleistungen (Variantenkomplexität) zur Befriedigung der heterogenen Anforderungen der Geschäftsbereiche (Kundenkomplexität) hat zu einer hohen Differenzierung bei der Produktion von IT-Dienstleistungen geführt und erzwingt damit eine hohe Koordinationskomplexität. Bei der Nutzung von IT verfolgen einzelne Abteilungen häufig unterschiedliche Entwicklungswege ohne Abstimmung [WeSB02a, 57]. So werden Einzelfallentscheidungen ohne eine übergreifende Gesamtsicht auf die IT der Organisation getroffen. ADAM und JOHANNWILLE stellen allgemein für fertigende Unternehmen fest: Ä%HL KRKHU 8QVLFKHUKHLW GHU'DWHQXQGJUR‰HU'\QDPLNQHLJHQ2UJDQLVDWLRQHQ]XDOVHIIL]LHQWHUNDQQWHQGH]HQWUD OHQ (QWVFKHLGXQJVNRPSHWHQ]HQ 'XUFK 'H]HQWUDOLVLHUXQJ XQG 6HOEVWVWHXHUXQJ ZHUGHQ 0RWLYDWLRQVNUlIWHIUHLJHVHW]WVRGD‰GLH4XDOLWlWGHU3UREOHPO|VXQJHQSULQ]LSLHOOVWHLJWXQG GLH/|VXQJHQVFKQHOOHUJHQHULHUWZHUGHQN|QQHQ0LWGHU=HUOHJXQJYRQ(QWVFKHLGXQJVIHO GHUQJHKHQDEHUGLH%H]LHKXQJHQ]ZLVFKHQGHQ(QWVFKHLGXQJHQGHU7HLOEHUHLFKHYHUORUHQ XQG HV JHOLQJW KlXILJ QXU XQ]XUHLFKHQG IU GLH HLQ]HOQHQ (QWVFKHLGXQJVIHOGHU %HVFKDI IXQJ3URGXNWLRQ$EVDW]XVZ =LHOH]XILQGHQGLHNRQVLVWHQW]XP8QWHUQHKPHQV]LHOVLQG >«@ 'LH .RPSOH[LWlWVIDOOH KDW LKUH 8UVDFKH KlXILJ GDULQ GD‰ (QWVFKHLGXQJHQ EHU GLH .RPSOH[LWlW QXU DXV VSH]LHOOHU )XQNWLRQVVLFKW JHWURIIHQ ZHUGHQ RKQH GLH LQGLUHNWHQ .RV WHQZLUNXQJHQ LQ DQGHUHQ %HUHLFKHQ ]X EHDFKWHQ´ [AdJo98, 6] Diese Erkenntnis aus der

Einführung

3

Industrie lässt sich auf die IT übertragen: Ä'LH %HWUDFKWXQJ GHU ,7/HLVWXQJVHUVWHOOXQJ DOV )HUWLJXQJVSUR]HVV HUODXEW HV HUIROJUHLFKH 0DQDJHPHQWDQVlW]H XQG PHWKRGHQ DXV GHU LQGXVWULHOOHQ)HUWLJXQJDXIGLH,7/HLVWXQJVHUVWHOOXQJ]XEHUWUDJHQ³und weiter:Ä,QGHU,7 /HLVWXQJVHUVWHOOXQJGRPLQLHUHQKHXWHGLHMHQLJHQ)UDJHVWHOOXQJHQPLWGHQHQVLFKGLH,QGXV WULHLQGHQHU-DKUHQDXVHLQDQGHUJHVHW]WKDW³ [ZaBP05, 33] Als Treiber werden dabei u. a. Komplexität und Standardisierung genannt. Über die Jahre ist so eine hoch komplexe IT mit einer Vielfalt aus Eigenentwicklungen und Standardlösungen gewachsen [BuES04, 144 f.; MaSS03, 58; Gitt04, 63]. Dieser Zustand wird noch verstärkt durch Umstrukturierungen, Übernahmen, Verkäufe und die erzwungene

Umsetzung

fundamentaler

IT-Innovationen

[HaWi05, 629;

BuES04, 144;

Cook96, 13; MaSS03, 59]. Die Komplexität im IT-Bereich ist für viele Unternehmen kaum noch beherrschbar [Rost03, 2; Gitt04, 62; SaWi03, 498]. Laut einer Studie der ECONOMIST INTELLIGENCE UNIT betreiben vier von fünf IT-Bereichen weltweit mehrere völlig verschiedene Applikationsumgebungen und 40 Prozent der Konzerne mit einem Umsatz über acht Mrd. Dollar haben Probleme, diese Umgebungen zu verwalten [Scho04]. Des Weiteren äußerten 84 Prozent von 400 befragten IT-Leitern in Europa, dass sie ihr IT-Portfolio nicht überschauen können und deswegen bis zu 40 Prozent der IT-Projekte scheitern [Thol05a]. Die Folge der Komplexität sind hohe IT-Betriebskosten [GaMa05, 75; HaWi05, 628; Karg03, 383; Gitt04, 62] und die Bindung knapper Entwicklungsressourcen [BuES04, 151 f.]. Da die Mittel für Innovationen fehlen, veraltet die IT [Wint05, 586] und ist damit für GLH bQGHUXQJHQ GHV Ä*HVFKlIWV³ 4 nicht flexibel genug [SaWi03, 499; JoHA02, 2; MSBA02, 6 und 9]. Entsprechend wird die schlechte Abstimmung von Geschäft und IT bzw. eine sukzessive Abkopplung von Organisation- und Prozessarchitekturen auf der einen Seite und der IT-Architektur auf der anderen Seite kritisiert [HaWi05, 628 f.]. Die IT erfüllt damit nicht die gegebenen Anforderungen der Geschäftsprozesse und wird als hoher Kostenfaktor wahrgenommen. Ein wertorientiertes Management der IT-Architektur ermöglicht die Reduktion von nichtnotwendiger Komplexität und die zielgerichtete Gestaltung und Verwaltung von notwendiger Komplexität in der IT. NATIS stellt dazu fest: Ä$FRQVLVWHQWV\VWHPDWLFDUFKLWHFWXUHRIFODULW\ LVWKHUHIRUHWKHNH\WRFRQTXHULQJFRPSOH[LW\LQ,7³ [Nati05, 7]. Die vorliegende Arbeit stellt einen Ansatz vor, wie eine aktiv gesteuerte, unternehmensweite IT-Architektur den Wertbeitrag der IT verbessert.

4

 0LW Ä*HVFKlIW³ ZLUG GDV *HVFKlIWVPRGHOO HLQHV 8QWHUQHKPHQV RGHU 7HLOH GDYRQ *HVFKlIWVSUR zesse) bezeichnet.

4

1.2

Einführung

Zielsetzung und Vorgehensweise

In der Literatur stößt man im Zusammenhang mit dem Wertbeitrag der IT und dem Wertbeitrag der Geschäftsprozesse zum Unternehmenserfolg immer wieder auf die Begriffe der Effizienz und Effektivität, z. B. bei AMBERG: Ä'HU(LQVDW]HLQHUHIIHNWLYHQ>«@XQGHIIL]LHQWHQ>«@,QIRUPDWLRQVYHUDUEHLWXQJLVW LQ 8QWHUQHKPHQ XQYHU]LFKWEDU XP .RVWHQ ]X VHQNHQ GLH 4XDOLWlW ]X VWHLJHUQ GLH 3URGXNWLYLWlW ]X HUK|KHQ XQG GLH :HWWEHZHUEVSRVLWLRQ ]X YHUEHVVHUQ³ >$PEH@ Das IT-Architektur-Management hat nach HAFNER und WINTER ÄJHQHUHOO ]XP =LHO GLH *HVFKlIWV XQG 3UR]HVVDUFKLWHNWXU DXI GHU HLQHQ 6HLWH VRZLH GLH $SSOLNDWLRQV XQG ,7 $UFKLWHNWXU DXI GHU DQGHUHQ 6HLWH HIIHNWLY XQG HIIL]LHQW PLWHLQDQGHU ]X NRRUGLQLHUHQ³ [HaWi05, 629]. Das übergeordnete Ziel des Managements der IT-Architektur einer Organisation ist damit die Realisierung einer dauerhaft effizienten und effektiven IT-Architektur. Eine effiziente und effektive IT-Architektur wiederum ist essenzieller Bestandteil einer effizienten und effektiven Leistungserbringung in der IT. Daher lautet die dieser Arbeit zugrunde liegende Frage: Ä:LHNDQQ,7$UFKLWHNWXU0DQDJHPHQWGLH(IIL]LHQ]XQG(IIHNWLYLWlWGHU,7HUK|KHQ"³ Komplexität in der IT entsteht einerseits aus dem technischen Fortschritt heraus 5 (strukturell begründete Komplexität) und ist andererseits organisatorisch begründet durch rationale individuelle Entscheidungen auf Abteilungsebene, die zu kollektiv schlechten Ergebnissen auf Gesamtunternehmensebene führen (organisatorisch begründete Komplexität). Die ,7$UFKLWHNWXUDOVÄ%HVFKUHLEXQJYRQ6WUXNWXUHQ³>.UFP@VWHOOWGLH.RPSOH[LWlWLQGHU IT einer Organisation dar. Diese Darstellung ermöglicht das Verwalten der Komplexität und das Aufdecken von Redundanzen und Lücken in der Versorgung der Geschäftsprozesse PLW ,7'LHQVWOHLVWXQJHQ'LH 0|JOLFKNHLW GHU 9HUZDOWXQJ XQG 6WHXHUXQJ QRWZHQGLJHU .RP plexität in der IT generiert schließlich den eigentlichen Wertbeitrag von IT-Architekturen. Ziel dieser Arbeit ist es, eine integrierte Methode sowie ein zugehöriges Instrument zum 0DQDJHPHQW YRQ ,7$UFKLWHNWXUHQ ]X HQWZLFNHOQ 6WUXNWXULHUXQJV XQG 'DUVWHOOXQJVP|J lichkeiten von IT-Architekturen einerseits und Lösungsansätze zur Komplexitätsreduktion in GHU ,7 GXUFK ,7$UFKLWHNWXU0DQDJHPHQW DQGHUHUVHLWV VLQG GLH 6FKZHUSXQNWH ,P =HQWUXP VWHKHQHLQ9HUIDKUHQ]XU*HZlKUOHLVWXQJGHU6WUDWHJLHNRQIRUPLWlWYRQ,7$UFKLWHNWXUHQHLQ 9HUIDKUHQ]XU%HZHUWXQJYRQ,7$UFKLWHNWXU(QWVFKHLGXQJHQXQGHLQH6RIWZDUH]XU'DUVWHO OXQJ XQG 9HUZDOWXQJ YRQ ,7$UFKLWHNWXUHQ 6WUDWHJLHNRQIRUPH ,7$UFKLWHNWXUHQ JHZlKUOHLV

5

 /DXIHQGZLUGQHXH+DUGXQG6RIWZDUHHLQJHVHW]WRKQHLP*HJHQ]XJDOWH+DUGXQG6RIWZDUHLQ gleichem Maße zu entfernen.

Einführung

5

ten die Umsetzung der in der IT-Strategie vorgegebenen Standards und tragen damit zur Reduzierung der strukturellen Komplexität bei.

1.3

Aufbau der Arbeit

Abbildung 1-1 ordnet die IT-Architektur in den Unternehmenskontext ein. ....welche Produkte für welche Kunden auf welchen Märkten

Unternehmensstrategie

WAS?

bestimmt

bestimmt

beeinflusst

IT-Strategie IT-Trends

unterstützt beeinflusst

Abbildung 1-1

IT-Architektur

....mit welchen Prozessen

bestimmt

unterstützt/ modelliert

WOMIT?

IT-Governance

Geschäftsprozesse/ Geschäftsmodell

WIE?

....welche IT zur Unterstützung welcher Prozesse

Gestaltungsdimensionen der IT

Die IT-Architektur wird bestimmt von der IT-Strategie, die sich wiederum aus der Unternehmensstrategie ableitet. Das Geschäftsmodell und die Prozesse zur Ausübung der Geschäftstätigkeit werden durch die Unternehmensstrategie bestimmt und von der Informationstechnologie in Form von IT-Dienstleistungen unterstützt. Technologische Innovationen beeinflussen das Geschäftsmodell und die IT-Strategie. Sie ermöglichen neue Geschäftsmodelle oder verändern bestehende Strukturen der Geschäftstätigkeit. Die ITGovernance stellt dabei sicher, dass die IT an der Unternehmensstrategie ausgerichtet wird [Niem05, 29] und operationalisiert damit die IT-Strategie. Die Begriffe auf der linken Seite der Abbildung stellen die Frage nach dem Unternehmenszweck: Welche Produkte 6 sollen verkauft werden (WAS?), wie sollen diese Produkte hergestellt oder beschafft werden (WIE?) und mit welcher Art von Informationstechnologie soll die Erstellung der Produkte unterstützt werden (WOMIT?). Abgeleitet aus Abbildung 1-1 ergibt sich ein Vorgehensmodell für die vorliegende Arbeit (Abbildung 1-2). Die Ziffern bezeichnen dabei die Kapitel der Arbeit.

6

Ein Produkt kann sowohl ein Sachgut oder eine Dienstleistung sein.

6

Einführung

IT-Strategie

4

Strategiekonforme ITInvestitionen

strategische Sicht

IT-Projekte

Architekturkonforme ITProjekte

architektonische Sicht IT-Architektur

Modellierung von ITArchitekturen

3 5 Applikationen 7

Wertbeitrag von ITArchitektur-Management

6

Technologien

Bewertung/ Steuerung

Abbildung 1-2

Softwareunterstützung des Managements von ITArchitekturen

Darstellung

Vorgehensmodell

Zunächst wird die Entstehung von Komplexität in der IT und deren Folgen erläutert (Kapitel 2). Der Definition des Begriffs Komplexität im Allgemeinen folgt die Beschreibung der Komplexität in der Informationstechnologie und deren Auslöser. Mit der Modellierung von IT-Architekturen in Kapitel 3 beginnt der Kernteil der Arbeit. Nach Klärung der Begrifflichkeiten werden die Anforderungen an IT-Architekturen beschrieben und der Stand der Forschung dargelegt. Die IT-Architektur wird in Betrachtungsebenen gegliedert und ein generisches Modell zur Beschreibung und Darstellung von ITArchitekturen entwickelt. Dieses Modell bildet die Grundlage für alle folgenden Kapitel. Kapitel 4 zeigt ein Verfahren zur Gewährleistung von strategiekonformen IT-Architekturen. Dieses wird in einem Vorgehensmodell operationalisiert. Die in Kapitel 5 vorgestellten Kennzahlen unterstützen die Durchsetzung von Standards innerhalb der IT-Architektur. Mehrere Indizes ermöglichen die Überwachung und Steuerung von Investitionsentscheidungen in der IT hin zu einer hohen Standardkonformität und dienen damit zur Reduzierung der organisatorisch begründeten Komplexität in der IT. Kapitel 6 zeigt den Wertbeitrag von IT-Architektur-Management auf. Anhand von Kennzahlen wird transparent, wie das Management von IT-Architekturen Wert für die IT generiert. Dieses Kennzahlenkonstrukt dient zur langfristigen Bewertung der Entscheidungsqualität im IT-Architektur-Management. Die in Kapitel 7 vorgestellte Software IT-Architektur-Management-Portal implementiert das Modell aus Kapitel 3 zur Beschreibung und Darstellung von IT-Architekturen. Die Indizes und Kennzahlen aus den Kapiteln 4 bis 6 sind ebenfalls integriert. Die Software unterstützt das IT-Architektur-Management umfassend durch verschiedene Sichten auf die Architektur und durch automatisch generierte Auswertungen und Analysen.

Einführung

7

Kapitel 8 fasst die Ergebnisse dieser Arbeit zusammen und gibt Anregungen für weitere Forschungsaktivitäten.

Kapitel 2 Komplexität von IT-Architekturen 2 Komplexität von IT-Architekturen 2.1

Komplexität im Allgemeinen ³-HGHU OLHEW GLH 9LHOIDOW GRFK NDXP MHPDQG PDJ GLH .RPSOH[LWlW 'LH LVW KHL‰W HVDQDOOHPVFKXOG$EHUZHQQZLUHVXQV]XHLQIDFKPDFKHQZLUGDOOHVNRPSOL ]LHUW´>/RWW@

Nach PILLERLVW.RPSOH[LWlWÄ>«@GDV=XVDPPHQWUHIIHQHLQHUVWUXNWXUHOOHQ9LHOVFKLFKWLJNHLW UHVXOWLHUHQG DXV GHU $Q]DKO XQG 'LYHUVLWlW GHU (OHPHQWH HLQHV 6\VWHPV VRZLH GHUHQ JH JHQVHLWLJH 9HUNQSIXQJ XQG GHU G\QDPLVFKHQ 9HUlQGHUOLFKNHLW GHU JHJHQVHLWLJHQ %H]LH KXQJHQ GHU 6\VWHPHOHPHQWH³ >3LOO@ 3ATZAK beschreibt Komplexität abstrakt als .RPELQDWLRQ DXV .RQQHNWLYLWlW XQG 9DULHWlW >3DW]@ 1DFK *$//$*+(5 und APPENZELLER LVW HLQ NRPSOH[HV 6\VWHP Ä>«@ WR EH RQH ZKRVH SURSHUWLHV DUH QRW IXOO\ H[ SODLQHGE\DQXQGHUVWDQGLQJRILWVFRPSRQHQWSDUWV³>*D$S@ Der Komplexitätsgrad eines Unternehmens wiUGGXUFK.RPSOH[LWlWVWUHLEHUEHVWLPPWGLH VLFK DXV HLQHU 9LHO]DKO H[WHUQHU XQG LQWHUQHU )DNWRUHQ ]XVDPPHQVHW]HQ >3L:D@ ([ WHUQH .RPSOH[LWlWVWUHLEHU VLQG ]% GHU DXV GHU *OREDOLVLHUXQJ UHVXOWLHUHQGH :HWWEHZHUE die individueller werdenden Kundenwünsche oder moderne technische Entwicklungen >3L:D@'DPLWHLQ8QWHUQHKPHQ3URGXNWHHUVWHOOHQNDQQVLQGLQQHUEHWULHEOLFKH$EOlX IH XQG 3URGXNWLRQVIDNWRUHQ QRWZHQGLJ 'LH 9LHOVFKLFKWLJNHLW XQG 9HUlQGHUOLFKNHLW GLHVHU LQWHUQHQ )DNWRUHQ XQG $EOlXIH EHVWLPPHQ HEHQIDOOV GHQ *UDG GHU .RPSOH[LWlW >3L :DI@ 'LH 'LIIHUHQ]LHUXQJ XQG ,QGLYLGXDOLVLHUXQJ GHV 3URGXNWSRUWIROLRV ]XU %HIULHGLJXQJ YRQ .XQGHQZQVFKHQ NDQQ GDEHL LQ GLH VR JHQDQQWH .RPSOH[LWlWVIDOOH IKUHQ >$G-R@ ,PPHU PHKU 3URGXNWYDULDQWHQ EHL QDKH]X JOHLFK EOHLEHQGHP 0DUNWYROXPHQ IKUHQ ]X HL QHPJHULQJHUHQ$EVDW]MH3URGXNW>$G-R@*OHLFK]HLWLJQHKPHQGLH.RPSOH[LWlWVNRVWHQ LP8QWHUQHKPHQ]X(VKDQGHOWVLFKGDEHLXP)DNWRUYHUEUlXFKHGLHDXVGHU.RPSOH[LWlW

10

Komplexität von IT-Architekturen

des Leistungsprogramms, der Kundenstruktur, der Produkte sowie dem Programm und der Organisation der Leistungserstellung resultieren [AdRo95; Meff00, 1043] (nach [BöKr05, 456]). Diese Komplexitätskosten können zu erheblichen Wettbewerbsnachteilen führen. So steht zu Beginn bei vielen Unternehmen in der industriellen Fertigung ein relativ einfaches Produktionsprogramm, das im Laufe der Zeit durch Sonderwünsche der Abnehmer um immer mehr Varianten erweitert wird. Gleichzeitig gehen die Stückzahlen der einzelnen Produkte zurück. Durch eine Quersubventionierung der Nischenprodukte aufgrund mangelnder Kenntnis der tatsächlichen Herstellungskosten entsteht ein Wettbewerbsnachteil bei dem eigentlichen Kerngeschäft, den Standardprodukten [PiWa99, 15]. Im Vertrieb sind höhere Ressourcenbedarfe für die Bearbeitung heterogener Märkte und für die kundenspezifische Angebotserstellung notwendig. In der Produktion wächst die Anzahl der verwendeten Komponenten oder die Zahl der Aufträge mit geringen Wiederholeffekten. Sowohl für den Fremdbezug als auch für die Eigenerstellung steigt der Ressourcenbedarf durch eine aufwendigere Koordination, Beschaffungslogistik oder Leistungserstellung. Diese höheren Ressourcenbedarfe führen zu steigenden Kosten [BöKr05, 457]. Die daraus resultierende Komplexitätsfalle lässt sich auf die Informationstechnologie übertragen: Die IT unterstützt alle Unternehmensfunktionen und ist dementsprechend von gleicher Komplexität wie die unterstützte Unternehmensfunktion. Da Informationstechnologie Unternehmensfunktionen zusätzlich vernetzt und auch überbetriebliche Vernetzung herstellt, ist die Komplexität speziell in dieser Domäne sogar noch höher. Abbildung 2-1 zeigt die Auswirkungen steigender Komplexität, gegliedert nach den Kerngeschäftsprozessen der industriellen Produktion.

Komplexität von IT-Architekturen

Forschung und Entwicklung ‡ (UVWHOOHQXQG9HUZDOWHQ ]XVlW]OLFKHUWHFKQLVFKHU 8QWHUODJHQ ‡ 3IOHJH]XVlW]OLFKHU Stammdaten ‡ =XVlW]OLFKH7HVWOlXIH ‡ $XIZHQGLJHUHV Simultaneous Engineering

Abbildung 2-1

Einkauf / Logistik ‡ +|KHUH(LQVWDQGVSUHLVH durch geringere 6WFN]DKOHQ ‡ 'LVSRVLWLRQVDXIZDQGIU PHKU3RVLWLRQHQ ‡ =XQDKPHGHU Verhandlungsgespräche mit Lieferanten ‡ +|KHUHU$XIZDQGIU Qualitätssicherung von ]XJHOLHIHUWHQ Komponenten ‡ +|KHUHU$XIZDQGGHU 5HFKQXQJVSUIXQJ

11

Fertigung / Montage ‡ *HULQJHUH/RVJU|‰HQ ‡ +|KHUH5VWNRVWHQ ‡ 6LQNHQGHU Auslastungsgrad der Fertigungsanlagen ‡ *HULQJHUH6WFN]DKOHQMH Auftrag ‡ *HULQJHUH3URGXNWLYLWlW durch geringere Lerneffekte ‡ /HHUNDSD]LWlWHQEHL 1DFKIUDJHUFNJDQJ ‡ +|KHUHU Koordinationsaufwand ‡ 8PIDQJUHLFKHUH Qualitätskontrollen ‡ +|KHUH.RVWHQGXUFK Abstimmung mit externen =XOLHIHUHUQ

Kundendienst / Vertrieb ‡ $XIZHQGLJHUH'LVWULEXWLRQ ‡ +|KHUHU Schulungsaufwand ‡ +|KHUH0DUNHWLQJNRVWHQ ‡ =XVlW]OLFKH Bedienungsanleitungen/ 'RNXPHQWDWLRQVXQWHUODJHQ

Auswirkungen steigender Komplexität 7

'LH 3UR]HVVH ODXWHQ IU GLH ,7 GDQQ VWDWW Forschung und Entwicklung, Einkauf/ Logistik, Fertigung/ Montage und Kundendienst/ Vertrieb Plan, Source, Make und Deliver >=D%U 17]. 'DHLQHJHZLVVH9DULDQWHQYLHOIDOW]XU%HIULHGLJXQJYRQ.XQGHQZQVFKHQQRWZHQGLJLVW EHVWHKWGLH6FKZLHULJNHLWEHLGHU5HGX]LHUXQJYRQ.RPSOH[LWlWLQGHU:DKOGHV.RPSOH[L WlWVQLYHDXV 'HU .RPSOH[LWlWVJUDG LQ GHU 3URGXNWSDOHWWH PXVV VR ZHLW UHGX]LHUW ZHUGHQ GDVV=XVDW]NRVWHQGLHGXUFKGLH]XVlW]OLFKH.RPSOH[LWlWHQWVWHKHQGXUFKHQWVSUHFKHQGH 0HKUHUO|VHPLQGHVWHQVNRPSHQVLHUWZHUGHQ>3L:D@'DV=LHOLP.RPSOH[LWlWVPDQD gement ist daher ÄGLH.RPSOH[LWlWVLQQYROO]XUHGX]LHUHQXQGGLHYHUEOHLEHQGH5HVWNRPSOH [LWlW VRXYHUlQHU ]X EHKHUUVFKHQ³ >$GDP@ $'$0 stellt weiterhin fest, dass 0D‰QDKPHQ LQ GHQ %HUHLFKHQ Organisation, &RQWUROOLQJLQVWUXPHQWH und 5HGX]LHUXQJ GHV Koordinationsbedarfs ein Abrutschen in die Komplexitätsfalle verhindern. Im Bereich OrgaQLVDWLRQ VLQG GDEHL XQWHU %HDFKWXQJ GHV 6XEVLGLDULWlWVSULQ]LSV 8 GH]HQWUDOH .RPSHWHQ]HQ ]XU5HGX]LHUXQJGHVVWHLJHQGHQ.RRUGLQDWLRQVEHGDUIVDXV]XEDXHQ,QQRYDWLYH&RQWUROOLQJ LQVWUXPHQWHPVVHQGLH$XVZLUNXQJHQYon Variantenentscheidungen auf den Erfolg sichtbar und dabei die entstehenden Komplexitätskosten transparent machen. KoordinationsEHGDUIHVLQG]%GXUFKJHULQJHUH)HUWLJXQJVWLHIHQ]XUHGX]LHUHQ>$GDP@

7

 9HUlQGHUWHQWQRPPHQDXV>3L:D@  1DFK GHP 6XEVLGLDULWlWVSULQ]LS VROO HLQH VWDDWOLFKH $XIJDEH VRZHLW ZLH P|JOLFK YRQ GHU MHZHLOV XQWHUHQE]ZNOHLQHUHQ(LQKHLWZDKUJHQRPPHQZHUGHQ'HU*HVDPWVWDDWVROOHUVWGDQQHLQJUHL IHQZHQQGLH3UREOHPHDXIGHU(EHQHGHU*HPHLQGHRGHU5HJLRQ%XQGHVODQG QLFKW]XEHZlOWL JHQVLQG'DV6XEVLGLDULWlWVSULQ]LSZLUGKLHUDXI8QWHUQHKPHQXQGLKUH2UJDQLVDWLRQVKLHUDUFKLHQ angewandt.

8

12

Komplexität von IT-Architekturen

2.2

Komplexität in der IT

Moderne IT-Bereiche erbringen Dienstleistungen für das eigene Unternehmen, indem sie die Geschäftsprozesse und -produkte mit IT-Dienstleistungen versorgen. Die Geschäftsbereiche treten dabei als Kunden gegenüber dem IT-Bereich auf [ZaBP05, 10] (vgl. Abbildung 2-2). Unternehmen Geschäftsbereich (Interner Kunde)

IT-Dienstleister (Externer Lieferant) Externer Markt

IT-Bereich (Interner Lieferant)

Interner Markt

Anwender Anwender

Externer Kunde

Anwender Anwender

Abbildung 2-2

Einordnung des IT-Bereichs in das Gesamtunternehmen9

Der IT-Bereich ist interner Lieferant für IT-Dienstleistungen. Er erbringt dabei DienstleistunJHQVHOEVWRGHUNDXIWGLHVHYRQH[WHUQHQ'LHQVWOHLVWHUQ]X$XFKN|QQHQ±MHQDFK'HILQL WLRQ GHU $XIJDEHQ GHV ,7%HUHLFKV ± GLH 'LHQVWOHLVWXQJHQ GHV ,7%HUHLFKV DQ H[WHUQH Kunden verkauft werden. Die Summe der vom IT-Bereich erbrachten IT-Dienstleistungen wird als IT-Portfolio bezeichnet. IT-Dienstleistungen, auch IT-Produkte genannt, werden von ZARNEKOW in vier Kategorien eingeteilt [Zarn04, 43 - 49]: x

Kategorie 1 - Ressourcenorientierte IT-Produkte

x

Kategorie 2 - Lösungsorientierte IT-Produkte

x

Kategorie 3 - Prozessorientierte IT-Produkte

x

Kategorie 4 - Geschäftsproduktorientierte IT-Produkte

Die Kategorien unterscheiden sich im Grad der Geschäftsorientierung und der Komplexität der IT-Dienstleistung. Kategorie 1 bezeichnet geschäftsprozessunabhängige Basisdienstleistungen, die der Kunde selbst kombiniert, um einen Mehrwert zu erhalten. Beispiele sind CPU-Zeit 10 oder Speicherkapazität auf einer Festplatte im Netzwerk. Kategorie 2 bildet Applikationen ab, die Lösungen für konkrete Aufgabenstellungen bieten. Beispie-

9 10

Verändert entnommen aus [ZaBP05, 11]. CPU steht für Central Processing Unit (Hauptprozessor).

Komplexität von IT-Architekturen

13

le sind CAD-Lösungen 11 oder eine Standardsoftware zur Textverarbeitung. Kategorie 3 umfasst alle Applikationen, die einen oder mehrere Geschäftsprozesse unterstützen. Sie umfassen sämtliche IT-Dienstleistungen, die für diese Unterstützung notwendig sind. BeiVSLHOH VLQG Ä6FKDGHQVYRUJDQJ DQOHJHQ³ Ä.XQGHQGDWHQ HUIDVVHQ³ RGHU Ä=DKOXQJVYRUJDQJ YHUEXFKHQ³.DWHJRULHVXEVXPLHUW,7'LHQVtleistungen, die als Teile eines Produkts oder als Produkt selbst an Kunden des Unternehmens verkauft werden. Ein solches Produkt ist HLQ HOHNWURQLVFKHV =XJWLFNHW RGHU HLQ 7DULIDQJHERW HLQHV 7HOHNRPPXQLNDWLRQVDQELHWHUV IU mobiles Telefonieren. Die IT-Dienstleistungen der Kategorien 1 bis 3 sind nach BODENDORF den indirekten Dienstleistungen zuzuordnen. Sie unterstützen den Leistungserstellungsprozess eines 8QWHUQHKPHQV'LH,73URGXNWHDXV.DWHJRULHGDJHJHQVLQGGLUHNWH'LHQVWOHLVWXQJHQGLH ein Endprodukt oder eine Komponente eines Endprodukts darstellen [Bode99, 5]. Die Dienstleistungen der Kategorien 1 bis 3 werden zwischen dem IT-Bereich und den Geschäftsbereichen ausgehandelt. Die IT-Dienstleistungen der vierten Kategorie werden an externe Kunden (ob Endverbraucher oder Unternehmenskunde sei hier gleichgesetzt) verkauft und unterliegen damit anderen marktlichen Mechanismen. Komplexität entsteht dabei einerseits extern (kundenbezogene Komplexität) und andererseits innerhalb des ITBereichs bei der Erstellung der IT-Dienstleistungen. Im Rahmen dieser Arbeit ist eine Applikation eine Kombination aus technischen und organisatorischen Gestaltungselementen, die eine direkte oder indirekte Prozessleistung erbringt und bezeichnet damit IT-Produkte der .DWHJRULHQELV Grundsätzlich stellen BÖHMANN und KRCMAR fest: Ä%HL XQWHUQHKPHQVEH]RJHQHQ ,7 /HLVWXQJHQYHUXUVDFKHQ]XQlFKVWDOOJHPHLQGLHKHWHURJHQHQIXQNWLRQDOHQXQGQLFKWIXQNWLR QDOHQ $QIRUGHUXQJHQ VRZLH GLH $QIRUGHUXQJHQ DQ GLH ,QWHJUDWLRQ LQ EHVWHKHQGH 6\VWHP ODQGVFKDIWHQ HLQH KRKH 9DULHWlW 'LH $QSDVVEDUNHLW DQ GLH %HGDUIVYHUOlXIH EHU GLH =HLW YHUVWlUNWGLHVH9DULHWlWEHLGHQQHXHQ/HLVWXQJVDQJHERWHQGDGLH/HLVWXQJHQZHGHUODQJ IULVWLJ IHVWJHVFKULHEHQ ZHUGHQ QRFK 9HUlQGHUXQJHQ DQ GHQ /HLVWXQJHQ LP 9HUWUDJV]HLW UDXPNXQGHQVSH]LILVFKLPSOHPHQWLHUWZHUGHQ³>%|.U@ 2.2.1

Komplexitätstreiber

WILDEMANN klassifiziert Komplexitätstreiber grundlegend nach externen kundenbezogenen XQGLQWHUQHQ.RPSOH[LWlWVWUHLEHUQ>:LOG@YJOAbbildung 2-3).

11

&$' steht für &RPSXWHU$LGHG'HVLJQ (Computergestützte Konstruktion).

14

Komplexität von IT-Architekturen

Komplexitätstreiber Anzahl der einbezogenen Einheiten (organisationsund produktbezogen) Externe kundenbezogene Komplexitätstreiber

Anzahl der Aktionen zwischen den Einheiten

Anzahl der Beziehungen zwischen den Einheiten

Variabilität der Aktionen und Beziehungen

Interne Komplexitätstreiber Strukturelle Komplexitätstreiber

IuK bezogene Komplexitätstreiber

Individuelle Komplexitätstreiber

Anforderungsvielfalt

Funktionsorientierung Vielzahl von Hierarchieebenen

Hochgradiges Bringprinzip

Machtstreben

Globalisierung

Informationsasymmetrie

Abschieben von Verantwortung

Medienbrüche

Mangel an Sozial- und Fachkompetenz

Länderspezifika

Länge der Entscheidungsprozesse

Nachfrageschwankungen

Übermaß an Kontrollinstanzen

Ausprägung des Formularwesens

Lieferantenvielzahl

Trennung von Aufgabe, Verantwortung und Kompetenz

Dynamik der Märkte Sortimentsgröße Kundenanzahl

Schnittstellendichte

Unpassende IuKSysteme

Bereichsegoismen

Mangel an Motivation und Identifikation mit den Unternehmenszielen Negative Emotionen

Nicht notwendige produktbezogene Vielfalt

Abbildung 2-3 Klassifizierung von Komplexitätstreibern 12

Nahezu alle aufgeführten Aspekte sind auf die Informationstechnologie übertragbar. KRÜGER und SEELMANN-EGGEBERT nennen speziell für die IT kurze Innovationszyklen, dynamische Unternehmensprozesse, Mergers & Acquisitions und neue Kommunikationsund Vertriebsplattformen wie das Internet als Komplexitätstreiber [KrSe03, 19]. WILDEMANN spricht weiterhin von der Produktgestaltung als Auslöser hoher prozessuraler Komplexität: Ä'HU*UXQGOLHJWLQHLQHP0L‰YHUVWlQGQLV]ZLVFKHQNRQVWUXNWLYUHDOLVLHUWHUXQGNXQGHQQXW ]HQRULHQWLHUWHU 9DULDQ]³ [Wild98, 51]. Übertragen auf IT-Dienstleistungen bedeutet dies, dass der Kunde (Geschäftsbereich) den Nutzen hoher Varianz im Portfolio und in der Generierung der Dienstleistungen (Varianz auf Strukturebene) nur dann zu schätzen weiß, wenn dadurch ein Mehrwert entsteht. Interne Komplexität in der IT entsteht vor allem dadurch, dass Entscheidungen in frühen Phasen des Lebenszyklus einer Applikation den größten Kostenblock in der späteren Betriebsphase determinieren. ZARNEKOW ET AL. zeigen, dass der Zusammenhang zwischen Kostenverursachung und Kostenentstehung im Lebenszyklus von IT-Produkten nahezu

12

Verändert übernommen aus [Wild98, 48]. ,X. steht für ,QIRUPDWLRQ XQG .RPPXQLNDWLRQ und entspricht dem in dieser Arbeit verwendeten IT.

Komplexität von IT-Architekturen

15

identisch mit dem Verlauf in der industriellen Fertigung ist [ZaBP05, 43]. Die Anforderungs-, Analyse- und Designphase verursachen ca. 15 Prozent der Gesamtkosten einer Applikation, determinieren jedoch 70 Prozent. Diese fallen in den späteren Phasen Betrieb und Wartung an. Lange hat man diesen Zusammenhang in der IT vernachlässigt und so werden mit jeder neuen Applikation auch neue Technologien, Programmiersprachen, Hardwareplattformen und Softwarearchitekturkonzepte in die Produktion (entspricht dem Rechenzentrum) hineingetragen. Im Gegenzug werden bestehende Applikationen, deren Lebenszyklus nur für wenige Jahre geplant war, erst nach Jahrzehnten oder gar nicht abgeschaltet 13. Das so genannte Jahr 2000-Problem hat dieses Vorgehen verdeutlicht: Bei der Entwicklung von vornehmlich Individualsoftware waren die wenigsten Programmierer und Softwaredesigner davon ausgegangen, dass die Applikation bis zum Jahr 2000 oder länger in Betrieb sein würde [Knol97, 7]. Die Kosten zur Anpassung der Applikationslandschaft an den Jahrtausendwechsel haben im Jahr 1998 bis zu 50 Prozent der IT-Budgets von Unternehmen verbraucht [KnMi99, 150]. Warum Lebenszyklen in der IT nicht so konsequent eingehalten werden wie in der Industrie zeigt folgendes Beispiel aus der Automobilbranche. Während in der Automobilindustrie bei den meisten Herstellern zwar laufend Nischenmodelle und Modellvarianten hinzukommen und die Auswahl an Fahrzeugtypen noch nie so groß war wie heute 14, so werden doch laufend Fahrzeugmodelle durch nachfolgende Generationen abgelöst und darauf hin nicht mehr angeboten. Der Lebenszyklus ist bereits zu Beginn der Produktion definiert und wird nur in Ausnahmefällen verändert 15. Lediglich die Ersatzteilversorgung und Reparatur wird über einen längeren Zeitraum hinweg gewährleistet. In der IT hingegen ist zum Zeitpunkt der Planung einer Applikation zumeist nicht klar, wie lange diese in Betrieb sein wird. Eine Lebensversicherung mit monatlichen Beiträgen, die über einen Rechenalgorithmus kalkuliert wird, kann eine Laufzeit von etlichen Jahrzehnten haben. Für ein bestimmtes Lebensversicherungsprodukt müssen die Einzahlungen, der aktuelle Beitragssatz und Kontostand inklusive einem Mahnverfahren für laufende Beitragszahlungen usw. noch über Jahrzehnte elektronisch abgebildet werden. Auch falls das Produkt nur für kurze Zeit am Markt angeboten wird, müssen diejenigen Kunden, die einen entsprechenden Vertrag abgeschlossen haben, zuverlässig bedient werden. Falls nun zum Zeitpunkt des Vertragsabschlusses das Produkt mit einer in COBOL programmierten Software auf Basis einer Mainframe Hardware kalkuliert wurde, so ist die Wahrscheinlichkeit hoch, dass diese Software noch über Jahrzehnte in Betrieb sein wird. Die Computertechnologie zur Herstellung 13

14

15

BAUMÖL stellt dazu fest, dass die Langlebigkeit von Applikationen daraus resultiert, dass Anpassungen aufwendig sind und eine inhärente Unberechenbarkeit der Konsequenzen von Veränderungen an der bestehenden Architektur besteht [Baum06, 315]. Genannt seien hier Nischenmodelle wie Geländefahrzeuge oder so genannte Sport Utility Vehicles (SUV), Kombivarianten, Coupes, Cabrios und Mischfahrzeuge, für die immer neue Kategorien JHIXQGHQZHUGHQZLHHWZDGHU0HUFHGHV%HQ]Ä5³.DWHJRULHÄ7RXUHU³ RGHUGHU9:*ROI3OXV Als Beispiel sei der VW Käfer genannt, der zwischen 1938 und 2003 aufgrund der anhaltenden Nachfrage hergestellt wurde.

16

Komplexität von IT-Architekturen

GHV %HLVSLHOSURGXNWV Ä/HEHQVYHUVLFKHUXQJ  7\S ;³ GDJHJHQ YHUlQGHUW VLFKLP /DXIH GHU-DKUH'LH9HUVLFKHUXQJVJHVHOOVFKDIWNDQQQXQHQWZHGHUGHQ3URJUDPPFRGHEHLMHGHU 5HFKQHURGHU6RIWZDUHJHQHUDWLRQQHXLPSOHPHQWLHUHQRGHUDEHUGLH6RIWZDUHVRODQJHDXI GHP 0DLQIUDPH ZHLWHU SIOHJHQ ELV HQWZHGHU GHU +DUGZDUH+HUVWHOOHUNHLQH 8QWHUVWW]XQJ PHKU OLHIHUW RGHU GDV 3HUVRQDO GDV GHQ 3URJUDPPFRGH YHUVWHKHQ NDQQ LQ 5HQWH JHKW 16 'LH(QWVFKHLGXQJ]XU$EO|VXQJHLQHU$SSOLNDWLRQZLUGLQYLHOHQ)lOOHQVRODQJHKHUDXVJH ]|JHUW ELV GDV :LVVHQ LP 8QWHUQHKPHQ JlQ]OLFK YHUVFKZXQGHQ LVW XQG LP )DOOH HLQHU QRWZHQGLJHQ :DUWXQJ WHXUH H[WHUQH ([SHUWHQ HLQJHNDXIW ZHUGHQ PVVHQ  *OHLFK]HLWLJ ZHUGHQODXIHQGQHXH$SSOLNDWLRQHQLQGDV,73RUWIROLRPLWDXIJHQRPPHQGDHLQHUVHLWVGLH *HVFKlIWVEHUHLFKH QHXH ,7/|VXQJHQ ]XU 5HDOLVLHUXQJ LQQRYDWLYHU 3URGXNWH XQG *H VFKlIWVPRGHOOHIRUGHUQXQGDQGHUHUVHLWV7HFKQRORJLHVSUQJHLQGHU,7QHXH*HVFKlIWVPR GHOOHXQG3UR]HVVYHUEHVVHUXQJHQHUVWHUP|JOLFKHQYJO$EELOGXQJ  'LH 9HUQHW]XQJ GHU $SSOLNDWLRQHQ XQWHUHLQDQGHU XQG EHU 8QWHUQHKPHQVJUHQ]HQ KLQ ZHJHUK|KWGLH.RPSOH[LWlWQRFKZHLWHU6REHWUHLEW]%GLH&UHGLW6XLVVHFD$SSOLND WLRQHQ GLH HLQ NRPSOH[HV PLWHLQDQGHU YHUZREHQHV *HIOHFKW HUJHEHQ GDV DXI XQWHUVFKLHGOLFKHQWHFKQLVFKHQ3ODWWIRUPHQEHWULHEHQZLUG>+D6:@ 'LH .RPSOH[LWlW LQ GHU ,7$UFKLWHNWXU NDQQ DQDORJ ]XU %HEDXXQJVSODQXQJ HLQHU 6WDGW EHWUDFKWHW ZHUGHQ /$$57= (7 $/ HUZHLWHUQ GDV %HLVSLHO DXV $EVFKQLWW  XQG YHUZHLVHQ GD]X DXI 3DULV 'LH *HElXGH $SSOLNDWLRQHQ  VWDPPHQ DXV YLHOHQ -DKUKXQGHUWHQ XQG GLH QHQXQWHUVFKLHGOLFKHQ=ZHFNHQZLH:RKQHQ$UEHLWHQ.XOWXUXQG9HUZDOWXQJ)RUWODXIHQG ZHUGHQEHVWHKHQGH*HElXGHGXUFKQHXHHUVHW]WXQGDX‰HUKDOEGHUELVKHULJHQ6WDGWJUHQ ]HQZHUGHQPRGHUQH6WDGWYLHUWHOZLH/D'pIHQVHDXIGHUJUQHQ:LHVHHUULFKWHW'LH,QIUD VWUXNWXU LQ )RUP YRQ 6WUD‰HQ %UFNHQ 6FKLHQHQ :DVVHU XQG 6WURPYHUVRUJXQJ XVZ YHUNQSIWDOOH*HElXGHPHKURGHUZHQLJHUJXW>/D69@'LH+HUDXVIRUGHUXQJEHLGHU 6WDGWSODQXQJ EHVWHKW QLFKW GDULQ IRUWODXIHQG DOOH VFKHLQEDU YHUDOWHWHQ *HElXGH GXUFK PRGHUQH ]X HUVHW]HQ VRQGHUQ HLQH JH]LHOWH NRQWLQXLHUOLFKH $QSDVVXQJ GHU 6WDGWWHLOH *HElXGHXQGGHU,QIUDVWUXNWXUDQGLH%HGDUIHGHU%HZRKQHU]XJHZlKUOHLVWHQRKQHGDEHL GXUFK EHUPl‰LJH .RPSOH[LWlW QHJDWLYH (IIHNWH ZLH 9HUNHKUVVWDXV EHUIOOWH 8%DKQHQ RGHU6WURPDXVIlOOH]XULVNLHUHQ 2.2.2

Auswirkungen auf Kosten und Erlöse

Ä(FKWH³ .RPSOH[LWlWVNRVWHQ VLQG QDFK :,/'(0$11 QXU VROFKH GLH DXV HLQHU .RPSOH[LWlW HQWVWHKHQ GLH ]X NHLQHU (UK|KXQJ GHV .XQGHQQXW]HQV IKUW >:LOG@ 'DV YRP ,7 16

 =XU %HDUEHLWXQJ GHV -DKU 3UREOHPV ZXUGHQVR JHQDQQWH Ä'95HQWQHU³ UHDNWLYLHUW XQG GLH 6WXQGHQVlW]HIU&2%2/3URJUDPPLHUHUKDEHQVLFKLQGLHVHP=XVDPPHQKDQJYRQ0LWWH ELV0LWWHPHKUDOVYHUGRSSHOW>.QRO@   (LQ $UWLNHO GHU &20387(5:2&+( GD]X Ä,Q GHQ .HOOHUQ LQVEHVRQGHUH GHU 9HUVLFKHUXQJV XQG %DQNHQNRQ]HUQH DEHU DXFK PLWWHOVWlQGLVFKHU 8QWHUQHKPHQ VWHKHQ ,70RQVWHU DXI GHQHQ LQ 3/ &2%2/ RGHU $VVHPEOHU JHVFKULHEHQH XQG IU GLH 8QWHUQHKPHQ XQYHU]LFKWEDUH .HUQDQ ZHQGXQJHQXQWHUYRUJHEOLFKYHUDOWHWHQ09690RGHU96(%HWULHEVV\VWHPHQODXIHQ'LHZDJW QLHPDQGPHKUDQ]XIDVVHQZHLOVLFKNHLQHUPHKUGDPLWDXVNHQQWVDJWHLQ%HUDWHUGHUQLFKWJH QDQQWZHUGHQZLOO³>&RPS@

Komplexität von IT-Architekturen

17

Bereich angebotene Portfolio an Dienstleistungen wird vom Kunden wahrgenommen, die Komplexität der Produktion dieser Dienstleistungen bleibt jedoch verborgen. Je geringer diese Komplexität ist, umso günstiger können die IT-Dienstleistungen angeboten werden und der Kundennutzen steigt. Das folgende Beispiel erläutert den Zusammenhang: Der Geschäftsbereich Unternehmenskommunikation eines Energieversorgungsunternehmens möchte ein Intranet zur Publikation aktueller Meldungen einrichten. Der IT-Bereich schlägt nach Analyse aller Anforderungen ein Content Management System (CMS) eines bestimmten Herstellers vor. Die vom IT-Bereich dazu an den Geschäftsbereich gelieferte Kostenkalkulation beinhaltet die Softwarelizenzen, ein Datenbanksystem, einige Server, Installationsund Testaufwände usw. Der Geschäftsbereich Unternehmenskommunikation stellt nun fest, dass der vom Bereich Vertrieb betreute Internetauftritt bereits auf einem CMS betrieben wird und ist überrascht über den hohen Kostenvoranschlag des IT-Bereichs. Tatsächlich zeigt sich, dass aufgrund der mangelnden Transparenz in der IT-Architektur ein Angebot für eine eigenständige Applikation erstellt und die Möglichkeit der Nutzung bestehender Komponenten nicht in Betracht gezogen wurde. Der IT-Bereich erstellt ein neues Angebot, das nur noch zehn Prozent der Kosten des ersten Angebots ausmacht. Das Resultat für den DQIRUGHUQGHQ *HVFKlIWVEHUHLFK EOHLEW JOHLFK Ä=HLWQDKH 9HU|IIHQWOLFKXQJ XQWHUQHKPHQV LQWHUQHU0HOGXQJHQDQDOOH0LWDUEHLWHU³ QLFKWHUIRUGHUOLFKH0HKUNRVWHQGXUFKK|KHUH.RP plexität wurden vermieden. Diese Art von Vorfällen treten erfahrungsgemäß in allen großen Unternehmen auf und führen dazu, dass die Kunden des IT-Bereichs immer weniger bereit sind, hohe Kosten für individuelle Applikationen zu tragen [BöKr04, 79]. Informationstechnologie wird zunehmend als Commodity (Massengut) wahrgenommen, das bedarfsgerecht eingekauft werden kann. Die Komplexität in der Erstellung der Dienstleistung ist für die Kunden irrelevant und schafft keinen Mehrwert. Die in Abbildung 2-1 gezeigten Auswirkungen von steigender Komplexität sind auf den IT-Bereich übertragbar, lediglich die Begrifflichkeiten sind anzupassen. Grundsätzlich gilt: Je mehr überlappende Technologien (Technologien mit sehr ähnlicher oder gleicher Funktionalität) innerhalb eines Unternehmens zum Einsatz kommen, desto höher sind die Komplexitätskosten. In einem konkreten Fall in der Automobilindustrie im Jahr 2003 wurden z. B. zehn verschiedene Datenbanksysteme 18 identifiziert, die noch dazu in unterschiedlichen Versionen 19 im Einsatz waren 20. Jedes Datenbanksystem benötigt eigene Lizenzverwaltungsmechanismen, Administratoren, Server, usw. Auf die Frage, warum beispielsweise

18

19

20

SAP DB, MS SQL, Oracle, IBM UDB, MySQL, IDMS, IMS DB, Sybase, Gemstone und VDS Object Database. Alleine für Oracle waren folgende Versionen im produktiven Betrieb: 7.3.4, 8i, 8.0.5, 8.1.6, 8.1.7 und 9i. Die COMPUTERWOCHE]XHEHQGLHVHU3UREOHPDWLNÄ6RJDEHV 32 verschiedene Datenbankprodukte, 15 Betriebssysteme und mehr als 30 Programmiersprachen. Dass diese Vielfalt hohe ITKosten verursacht, versteht siFKYRQVHOEVW³>&RPS@

18

Komplexität von IT-Architekturen

eine Customer-Relationship-Management-Applikation auf einem (neu beschafften) MS SQL Datenbanksystem implementiert wurde anstelle eine bestehende Oracle-Installation zu QXW]HQZDUGLH$QWZRUWGHV]XVWlQGLJHQ3URMHNWOHLWHUVVLQQJHPl‰Ä8QVZDUQLFKWEHNDQQW dass wir die bestehende Oracle Installation nutzen können und dass es überhaupt eine JLEW³bKQOLFKH%HLVSLHOHVLQGDXVGHU$XWRPRELOLQGXVWULHEHNDQQW%HLGHU(QWZLFNOXQJHLQHU QHXHQ0RGHOOUHLKHZLUGHLQ=XOLHIHUHUPLWGHU(QWZLFNOXQJHLQHV)HQVWHUKHEHUPRWRUVEHDXI WUDJW ± REZRKO SDVVHQGH )HQVWHUKHEHUPRWRUHQ EHUHLWV EHL DOOHQ DQGHUHQ 0RGHOOUHLKHQ LP (LQVDW]VLQGXQGGHU.XQGHQXUDQGHU)XQNWLRQÄ)HQVWHUHOHNWULVFK|IIQHQXQGVFKOLH‰HQ³ LQWHUHVVLHUW LVW >$QGUI@ .RPSOH[LWlW LP QLFKW ZHWWEHZHUEVUHOHYDQWHQ %HUHLFK YHUXU sacht somit Kosten 21, die sich auf die Wettbewerbsfähigkeit auswirken, da der Deckungsbeitrag der einzelnen Produkte sinkt.

2.3

IT-Organisation

Die Annahme der Neuen Institutionellen Ökonomie, nachdem in Organisationen tätige Individuen eigenständige, organisationsunabhängige Ziele verfolgen, trifft auf den IT%HUHLFK HEHQVR ]X ZLH DXI GLH *HVFKlIWVEHUHLFKH HLQHV 8QWHUQHKPHQV 'LHV NDQQ ]X HL gennützigem (opportunistischem) Verhalten führen, das den übergeordneten Zielen eines 8QWHUQHKPHQV QLFKW I|UGHUOLFK RGHU JDU KLQGHUOLFK LVW 22. Die Principal-Agent-Theorie als ZHVHQWOLFKHU %HVWDQGWHLO GHU 1HXHQ,QVWLWXWLRQHOOHQ gNRQRPLH EHWUDFKWHW HLQ 8QWHUQHKPHQ DOV1HW]YRQ%H]LHKXQJHQ,P5DKPHQGHU'HOHJDWLRQYRQ$XIJDEHQVLQGGLH9HUWUDJVSDUW ner aufgeteilt in Prinzipal (Auftraggeber) und Agent (Auftragnehmer) [Jost01, 11]. Der IT%HUHLFKDJLHUWDOV$JHQWGHU*HVFKlIWVEHUHLFKHXQGGHU*HVFKlIWVOHLWXQJ,QEHLGHQ%H]LH hungen treten Informationsasymmetrien, Konflikte und damit verbundene Kosten auf. Abbildung 2-4 skizziert den Zusammenhang.

21

22

P,//(5 und W$5,1*(5 JHEHQ 3UR]HQW GHU *HVDPWNRVWHQ HLQHV $XWRPRELOKHUVWHOOHUV DOV GLUHNW YRQ GHU .RPSOH[LWlW GHV 3URGXNWSURJUDPPV DEKlQJLJ DQ >3L:D@ )U GLH ,7 GUIWH dieser Anteil noch höher liegen. Diese und tiefer gehende Ausführungen zur Neuen Institutionellen Ökonomie in Anwendung auf die Organisation der Informationsverarbeitung finden sich bei [MeKn98, 3 - 8.].

Komplexität von IT-Architekturen

19

Geschäftsleitung (2) (1)

Geschäftsbereich

IT-Bereich (3)

Abbildung 2-4

Principal-Agent-Beziehungen im Unternehmen 23

Die Geschäftsleitung ist in den Beziehungen (1) und (2) der Prinzipal, die Geschäftsbereiche und der IT-Bereich agieren als Agenten. In Beziehung (3) fungiert der IT-Bereich als Agent des jeweiligen Geschäftsbereichs [GuKe90, 282]. Dieses Beziehungsgeflecht führt zu Konflikten in der Aufgabenerfüllung des IT-Bereichs: Einerseits verlangt die Unternehmensleitung nach unternehmensweit optimalen IT-Dienstleistungen, andererseits verlangen die Geschäftsbereiche nach IT-Dienstleistungen, die ihre spezifischen Anforderungen bedienen. Um Synergieeffekte zu erzielen versucht der IT-Bereich übergreifende Standards einzuführen. Dabei werden die unterschiedlichen Anforderungen der einzelnen Geschäftsbereiche mehr oder minder umfassend erfüllt. Im Extremfall kann eine Entscheidung zugunsten eines unternehmensweiten Standards dazu führen, dass ein gesamtbetriebliches Optimum entsteht, jedoch für jeden einzelnen Geschäftsbereich ein suboptimaler Zustand eintritt [GuKe90, 284]. Dieser führt bei den Geschäftsbereichen zu strategischem Verhalten 24 in den Verhandlungen mit dem IT-Bereich oder aber zu Aktivitäten im Kompetenzbereich des IT-Bereichs, um die Versorgung mit IT-Dienstleistungen zur Erfüllung einer möglichst hohen Zahl von lokalen, geschäftsbereichsspezifischen Anforderungen zu verbessern. Strategisches Verhalten äußert sich z. B. in dem Aufstellen von Anforderungen an Applikationen, die zur Lösung des eigentlichen Problems nicht zwingend notwendig wären und in der vom IT-Bereich vorgeschlagenen Standardapplikation nicht enthalten sind 25. Die rein geschäftsbereichsbezogene Sichtweise verursacht die Nichteinhaltung von Standards: Ä,Q VRPH FDVHV HYHQ ZKHQ LW LV RUJDQL]DWLRQDOO\ RSWLPDO WR KDYH D VWDQGDUG WKH GHSDUW PHQWVPD\ SLFNGLIIHUHQWV\VWHPV7KLVRFFXUVEHFDXVHWKHGHSDUWPHQWVLJQRUHWKHH[WHU QDOLWLHVLQPDNLQJFKRLFHV³ [DeSS95, 101]

23 24

25

Verändert übernommen aus [GuKe90, 282]. Nach JOST EHGHXWHW VWUDWHJLVFKHV 9HUKDOWHQ GDVV ÄHine Partei bei ihren Entscheidungen die Wechselwirkungen ihrer Interaktion mit der DQGHUHQ3DUWHLHLQEH]LHKW³>-RVW@ Ein Geschäftsbereich fordert z. B. für alle Arbeitsplätze eine aufwendige Bildbearbeitungssoftware, die dann überwiegend zum Bearbeiten von privaten Digitalfotografien eingesetzt wird.

20

Komplexität von IT-Architekturen

MERTENS und KNOLMAYER sehen auch im IT-Bereich ein hohes Potenzial für opportunistisches Verhalten, da zum einen unternehmensunabhängiges Spezialwissen zur Erledigung der zugewiesenen Aufgaben erforderlich und zum anderen der Nutzen der erbrachten ITDienstleistungen schwer messbar ist [MeKn98, 5]. Bei der Gestaltung der IT-Architektur bestehen weiterhin Informationsasymmetrien zwischen den Mitarbeitern der Geschäftsbereiche und jenen des IT-Bereichs. Die Geschäftsbereichsmitarbeiter kommen mit Informationstechnologie zumeist durch PC-Anwendungen 26 und Internetapplikationen 27 in Kontakt. Die Komplexität von unternehmensweiten IT-Lösungen wird dadurch oftmals unterschätzt, die Simplifizierung von genannten Applikationstypen durch die Medien führt zu einer Fehleinschätzung des Entwicklungsaufwandes bei den Mitarbeitern der Geschäftsbereiche. Weiterhin wird oft bemerkt, dass Mitarbeiter der Geschäftsbereiche und des IT-Bereichs QLFKW ÄGLH JOHLFKH 6SUDFKH VSUHFKHQ³ 28 Das IT-spezifische Spezialwissen führt oftmals zu einer Ausdrucksweise, die den Mitarbeitern der Geschäftsbereiche unverständlich ist, die Mitarbeiter der zentralen IT-Abteilung leiden unter der daraus resultierenden Ausgrenzung [MeKn98, 84]. Von den Geschäftsbereichen wird der IT-Bereich daher oftmals als zu bürokratisch, die Entwicklung von Applikationen als zu langsam und zu teuer empfunden. Geschäftsbereiche betreiben zur Umgehung der Bürokratie des IT-Bereichs, zur Erhöhung eigener Budgets und zur Durchsetzung von geschäftsbereichsspezifischen Anforderungen oftmals selbst Applikationsentwicklungsprojekte 29, ohne den IT-Bereich einzubeziehen und umgehen damit die Aufgabenteilung im Unternehmen, die dem IT-Bereich die Versorgung mit ITDienstleistungen exklusiv zugesteht 30. Dabei werden unternehmensweite Technologiestandards und Vorgaben wie etwa zur Dokumentation und Qualitätsicherung zumeist nicht eingehalten [BrBr93, 460]. Das folgende Beispiel illustriert die Problematik: Der Geschäftsbereich Retail 31 bei einem Sportartikelhersteller möchte Ladenausstattungen (Regale, Produktpräsentationsdisplays, Schaufenstermaterialien usw.) über einen Onlineshop an Handelsketten und Einzelhandelsgeschäfte vertreiben. Dadurch sinken die Kosten der Katalogerstellung, die Preise

26

Beispiele hierfür sind Textverarbeitungs-, Tabellenkalkulations- und Zeichenprogramme oder einfache Applikationen zum Bearbeiten von digitalen Bildern. Browserbasierte E-Mail-Applikationen, Suchmaschinen, Onlineshops und Auktionsplattformen sind Beispiele für Internetapplikationen. 28 Die COMPUTERWOCHE VFKUHLEW GD]X Ä,79HUDQWZRUWOLFKH müssen die im Unternehmensgeschäft übliche Sprache beherrschen, andernfalls werden sie von Anwendern und Kollegen nicht als Partner, sondern lediglich als ComputHU)UHDNVZDKUJHQRPPHQ>@³>&RPS@ 29 Die Applikationen werden dabei entweder von Mitarbeitern des Geschäftsbereichs implementiert oder auf dem externen Markt für IT-Dienstleistungen eingekauft. 30 Eigenentwicklungen durch Mitarbeiter in Geschäftsbereichen werden als End-User Computing bezeichnet. Diese Art der Applikationsentwicklung kam mit der Verbreitung des Minicomputers in den 80er Jahren auf [GuKe90, 280]. 31  Ä5HWDLO³ VWHKW KLHU IU Ä.OHLQ (LQ]HO +DQGHO³ 'HU *HVFKlIWVEHUHLFK Retail aus dem Beispiel organisiert die Verteilung der Waren an die eigenen Händler, an Franchisenehmer und an Handelsketten und freie Einzelhändler. 27

Komplexität von IT-Architekturen

21

können dynamisch angepasst werden (je nach Abnahmemenge), die Verfügbarkeit der Waren wird online angezeigt und dreidimensionale Produktdarstellungen ermöglichen dem potenziellen Käufer eine präzise Vorstellung von der Ware. Der IT-Bereich erhält den Auftrag, ein Angebot für eine entsprechende Applikation vorzulegen. Das Angebot beinhaltet den Betrieb des Shops auf einer bestehenden Onlineshop-Software, die bereits in anderen Geschäftsbereichen eingesetzt wird. Einzig die Realisierung der dreidimensionalen Darstellung der Waren lässt sich nicht in die bestehende Shopsoftware integrieren. Die bestehende Shopsoftware ist zudem an die Kundendatenbank und die zentrale CRM-Applikation angebunden. Der IT-Bereich kalkuliert 90.000,- Euro und verspricht eine Implementierung innerhalb von acht Monaten, da im Projektportfolio zunächst andere Projekte Vorrang haben. Das Angebot ist für den Retail-Bereich nicht befriedigend, dieser schreibt das Projekt auf dem externen Markt für IT-Dienstleistungen aus und holt Angebote zur Realisierung ein. Nach mehreren Verhandlungsrunden liegt schließlich ein Angebot in Höhe von 80.000,Euro vor, das alle Anforderungen erfüllt und in vier Monaten realisiert werden kann. Laut den internen Geschäftsregeln muss der IT-Bereich die Möglichkeit der Nachbesserung erhalten 32. Tatsächlich könnte der IT-Bereich die gewünschte Funktionalität zu ähnlichen Kosten wie der externe Anbieter anbieten, eine Integration in die bestehende Shopsoftware und die Nutzung der vorhandenen Kundendaten wäre dann jedoch nicht möglich. Weiterhin PVVWHGHU,7%HUHLFK±ZLHGHUH[WHUQH$QELHWHUDXFK±2SHQ6RXUFH6RIWZDUHNRPSRQHQ ten 33 einsetzen, für die entsprechende Hardware angeschafft und später betrieben werden muss. Da der IT-Bereich die Realisierung auch im zweiten Angebot erst in acht Monaten zusichern kann und der Retail-Bereich auf einer schnelleren Realisierung beharrt, erhält der externe IT-Dienstleister den Auftrag zur Implementierung der Applikation. Nach Abnahme der Applikation durch den Retail-Bereich werden Hardware und Programmcode an den ITBereich zum Betrieb übergeben. Synergien mit bestehender Hardware sind aufgrund der Softwarearchitektur nicht möglich. Nach anfänglicher hoher Zufriedenheit des RetailBereichs mit der Applikation kommt bei den Endanwendern nach einigen Monaten der Wunsch auf, den Login-Vorgang wie bei allen anderen Applikationen abzuwickeln. Weiterhin verwenden die Anwender viel Zeit auf den manuellen Kundendatenabgleich zwischen der individuellen Shop-Applikation und der CRM-Applikation. Nachdem ein Kunde die Rechnung nicht beglichen hat und dieser Vorgang wochenlang unbemerkt blieb, ohne dass eine Mahnung versendet wurde, wünscht der Retail-Bereich außerdem eine Einbettung des Bezahlverfahrens in das zentrale Mahnwesen. Die geforderten Anpassungen werden vom IT-Bereich als so genannte Change Requests 34 formuliert und kosten insgesamt 30.000,32

33

34

Beispiele für Geschäftsregeln zur Vergabe von Applikationsentwicklungen finden sich bei [MeKn98, 87]. Der Ausdruck Open Source bedeutet, dass es jedermann erlaubt ist, Einblick in den Quelltext einer Software zu nehmen und diesen Quelltext beliebig weitergeben und verändern zu dürfen. Ein Change Request ist eine Änderungsanforderung und bezeichnet im Änderungswesen von ITProjekten und Applikationen einen formalisierten Wunsch nach Veränderung einer oder mehrerer Eigenschaften einer bestimmten Software.

22

Komplexität von IT-Architekturen

Euro. Bei der anfangs vom IT-Bereich vorgeschlagenen Lösung hätte eine Integration des Bezahlverfahrens in das zentrale Mahnwesen auf der Basis von Standardschnittstellen nur 5.000,- Euro gekostet. So belaufen sich die Gesamtkosten der Applikation nach diesen Änderungen auf 110.000,- Euro. Nach dem ursprünglichen Vorschlag des IT-Bereichs hätten sich die Gesamtkosten nach den Integrationsmaßnahmen auf 95.000,- Euro summiert. Als Nebeneffekt der ursprünglichen Lösung wären die Kosten aller Applikationen, die auf die zentrale Datenbank zugreifen, gesunken, da die Datenbankinstallation nach Anzahl GHU3UR]HVVRUHQXQGQLFKWQDFK$Q]DKOGHU'DWHQEDQNLQVWDQ]HQEHUHFKQHWZLUG±HLQQHXHU Prozessor war nicht notwendig. Weiterhin stellt sich nach der Inbetriebnahme der Applikation heraus, dass zur Anzeige der dreidimensionalen Modellzeichnungen die Freischaltung von diversen Ports im Netzwerk notwendig ist, worauf wiederum das Sicherheitskonzept überarbeitet werden muss und der Bandbreitenkonsum so hoch ist, dass andere Applikationen beeinträchtigt werden. Eine Untersuchung über die Nutzung der Applikation zeigt später, dass das Vorhandensein von dreidimensionalen Modellen nicht kaufentscheidend ist, da es sich um Business-to-Business-Geschäftsbeziehungen handelt. Die dargestellten Auswirkungen der Principal-Agent-Beziehungen in der Applikationsentwicklung werden je nach Unternehmen unterschiedlich behandelt. IT-Projekte 35 werden YRQ ÄDXVVFKOLH‰OLFK GXUFK GHQ ,7%HUHLFK RKQH (LQEH]LHKXQJ GHU *HVFKlIWVEHUHLFKH³ ELV ÄDXVVFKOLH‰OLFK GXUFK GHQ *HVFKlIWVEHUHLFK³ UHDOLVLHUW (LQH JUXQGVlW]OLFK SUDJPDWLVFKH Herangehensweise liegt zumeist zwischen den Extremen: Ä'HU ,9% ZLUG LP DOOJHPHLQHQ $QIRUGHUXQJHQ GHU )% 36 QLFKW HLQIDFK DEOHKQHQ N|QQHQ³ [MeKn98, 86]. WEILL und ROSS stellen zwar fest, dass die erfolgreichsten Konstellationen bei Entscheidungen in den BereiFKHQ Ä,7$UFKLWHFWXUH³ XQG Ä,7 ,QIUDVWUXFWXUH 6WUDWHJLHV³ 37 LQ GHQ $XVSUlJXQJHQ Ä%XVLQHVV 0RQDUFK\³ RGHU Ä,7 0RQDUFK\³ HUIROJHQ GLH (QWVFKHLGXQJ EH]JOLFK GHV ,7 ,QYHVWPHQWV MHGRFK HQWZHGHU DOV Ä%XVLQHVV 0RQDUFK\³ RGHU DOV Ä'XRSRO\³ RUJDQLVLHUW ZHUGHQ VROOWH >:H5R@ %HL Ä0RQDUFK\³$XVSUlJXQJHQ HQWVFKHLGHW HQWZHGHU GHU ,7%HUHLFK RGHU die Unternehmensleitung eigenständig über das Vorgehen. Beim Duopol bestimmen der ITBereich und ein weiterer Bereich (entweder eine Stabsstelle oder ein Geschäftsbereich) gemeinsam die Gestaltung des IT-Portfolios. Eine Untersuchung von 256 Unternehmen zeigt, dass Entscheidungen im Bereich der IT-Architektur zumeist ausschließlich vom ITBereich oder als Duopol getroffen werden, während die Daten zur Entscheidungsvorlage föderalistisch 38 oder duopolistisch entstehen. Die Anforderungen zur Realisierung einer neuen Applikation oder zur Erweiterung von bestehenden Applikationen kommen zumeist 35

 Ä,73URMHNWH³ZHUGHQQDFK+HLQULFKGHILQLHUWDOVÄ>«@3URMHNWH]XU6FKDIIXQJQHXHURGHUZHVHQW OLFKYHUlQGHUWHU,QIRUPDWLRQVV\VWHPH>«@³>+HLQ@ 36 ,9% steht für ,9%HUHLFK und entspricht dem hier verwendeten ,7%HUHLFK, )% steht für )DFKEH UHLFK und entspricht dem hier verwendeten *HVFKlIWVEHUHLFK. 37 Die von WEILL und ROSS definierten Entscheidungsfelder ,7$UFKLWHFWXUH und ,7 ,QIUDVWUXFWXUH 6WUDWHJLHV werden in dieser Arbeit als ,7$UFKLWHNWXU bezeichnet. 38 Der föderale Archetyp umfasst alle Geschäftsbereiche und den IT-Bereich in gleichberechtigter Befugnis [WeRo04, 59].

Komplexität von IT-Architekturen

23

aus den Geschäftsbereichen. Der IT-Bereich kann zwar aus einem Innovationsmanagement heraus Vorschläge unterbreiten, über genauere Kenntnis der Geschäftsprozesse verfügen jedoch zumeist die Geschäftsbereiche, die diese Prozesse selbst entwickelt haben [BuES04, 91]. 2.3.1

Standardisierungsproblem

Bei der Einführung von Softwarestandards in Unternehmen entsteht die gesamtunternehmerisch beste Entscheidung, wenn die Standards zwischen den Geschäftsbereichen ausgehandelt werden [DeSS95, 97 - 106]. Falls von Geschäftsbereichen Applikationen gefordert werden, die ein spezifisches Problem lösen und nicht mit anderen Applikationen kommunizieren, ist möglicherweise eine Best of Breed 39 Selektion für einzelne Geschäftsbereiche als Ausnahmefall gesamtunternehmerisch sinnvoll. Im Falle von unternehmensweiten Lizenzen für Applikationen (so genannte site license oder corporate license) kann es zum Shadow-Rider-Verhalten 40 kommen: Geschäftsbereiche verschleiern zunächst ihre wahren Anforderungen, um sich nicht beim initialen Erwerb von unternehmensweiten Lizenzen beteiligen zu müssen. Sobald die Lizenz für eine Applikation erworben und im Unternehmen verfügbar ist, verlangt der Geschäftsbereich nach kostenfreier Nutzung dieser Applikation. Als Beispiel führen DEWAN ET AL. die Einführung einer CAD-Software an: Geschäftsbereich 1 bevorzugt die Applikation ME10, Geschäftsbereich 2 bevorzugt VISIOTechnical. Jede Applikation hat spezifische Vor- und Nachteile und jeder Geschäftsbereich kann anhand von unterschiedlichen Anforderungen begründen, warum die geforderte Applikation auch die spezifisch bessere ist. Beide Geschäftsbereiche könnten auch mit der jeweils anderen Applikation arbeiten, nur eben mit etwas mehr Einarbeitung oder Zeitaufwand. Auf Unternehmensebene bedeutet eine Entscheidung zugunsten einer der beiden Applikationen eine Ersparnis von Lizenzkosten, einen geringeren Trainings- und Unterstützungsaufwand, eine größere Anwendergruppe der Applikation und eine höhere Flexibilität im Einsatz der Mitarbeiter [DeSS95, 98]. Die Autoren kommen durch Verwendung eines nichtkooperativen spieltheoretischen Modells ohne Informationsasymmetrien zu folgendem Schluss: Subventionen an denjenigen Geschäftsbereich, der sich bereit erklärt, die präferierte Applikation des anderen Geschäftsbereichs als Standard zu akzeptieren verursachen weniger Kosten, als die Folgekosten der externen Effekte einer Entscheidung gegen einen Standard [DeSS95, 102].

39

40

 Ä%HVW RI %UHHG³ EH]HLFKQHW KLHU GLH $XVZDKO GHU IU HLQH NRQNUHWH 3UREOHPVWHOOXQJ EHVWH 6RIW warelösung. Es handelt sich dabei um eine Kombination aus Trittbrettfahrerverhalten und dem Verzögern der Kaufentscheidung, um monetäre Vorteile zu erzielen. Das Resultat ist im dargestellten Fall ein Wohlfahrtsverlust für das Unternehmen, da der Geschäftsbereich, der die Entscheidung zugunsten eines Standards verzögert, zusätzlich Wechselkosten verursacht.

24

Komplexität von IT-Architekturen Als Zwei-Personen-Nicht-Nullsummen-Spiel 41 modelliert lautet die Problemstellung:

Zwei Geschäftsbereiche beantragen beim IT-Bereich unabhängig voneinander zur gleichen Zeit die Erstellung einer Applikation nach jeweils individuellen Anforderungen. Die Softwarearchitektur der einzelnen Applikation ist für den Geschäftsbereich irrelevant, die größtmögliche Erfüllung der gestellten Anforderungen bestimmt die Verhandlungsstrategie. Der IT-Bereich hat nur beschränkte Ressourcen zur Realisierung der Anforderungen zur Verfügung und möchte zur Komplexitätsvermeidung so viele Gemeinsamkeiten (Standards) wie möglich nutzen. Die Geschäftsbereiche haben jeweils in einem Vorprojekt untersucht, wie eine Applikation zur Lösung des Problems gestaltet sein müsste. Die Parameter im Spiel sind: x

p (Problemlösung): Lösung des ursprünglichen Problems des Geschäftsbereichs. Dies ist der eigentliche Grund, weshalb überhaupt der Bedarf nach einer neuen Applikation entstanden ist.

x

z (Zusatzfunktionalität): Funktionalitäten, welche die vom Geschäftsbereich bevorzugte Applikation zusätzlich bietet. Diese Anforderungen sind bei der Suche nach Problemlösungen durch die Geschäftsbereiche erst entstanden. Es wird angenommen, dass keine standardkonforme Lösung diese Zusatzfunktionalitäten bietet. Weiterhin ist zu erwarten, dass eine vom IT-Bereich geforderte Änderung des Geschäftsbereichsvorschlages in eine architekturkonforme Lösung weiteren Anpassungs- und Planungsaufwand verursachen wird. Der Nutzen besteht somit auch darin, ohne weiteren Planungsaufwand das Applikationsentwicklungsprojekt wie vom Geschäftsbereich vorgesehen zu realisieren.

x

s (Standardisierungsnutzen): Nutzen, der den Geschäftsbereichen durch das Einhalten der Standards in der IT-Architektur entsteht und damit das gesamtunternehmerische Optimum unterstützt.

Tabelle 2-1 zeigt die Pay-Off-Matrix des Spiels. Die kursiv gedruckten Ergebnisse sind der Pay-Off von Geschäftsbereich 1, die fett gedruckten der von Geschäftsbereich 2. Geschäftsbereich 2

Geschäftsbereich 1

Tabelle 2-1

41

Architektur 1

Architektur 2

Architektur 1

(p+z1+s, p+s)

(p+z1, p+z2)

Architektur 2

(p, p)

(p+s, p+z2+s)

Pay-Off-Matrix beim Standardisierungsdilemma

Zur Erläuterung siehe [Gard03, 63 - 65].

Komplexität von IT-Architekturen

25

Die bevorzugte Softwarearchitektur zur Erfüllung aller Anforderungen von Geschäftsbereich 1 ist Architektur 1 und von Geschäftsbereich 2 Architektur 2. Für den Fall, dass beide Geschäftsbereiche auf ihrer bevorzugten Lösung bestehen, wird kein Nutzen durch Standardisierung realisiert. Für den Fall, dass sich beide Geschäftsbereiche auf eine Architektur einigen, wird für denjenigen Geschäftsbereich, der die von ihm präferierte Architektur durchsetzt, der Zusatznutzen z und zusätzlich der Standardisierungsnutzen s realisiert, während der andere Geschäftsbereich nur den zusätzlichen Standardisierungsnutzen s realisiert. Für die Werte p = 0 (irrelevant 42), s = 9, z1 = 15 und z2 = 12 ergibt sich ein Gleichgewicht in der für das Unternehmen nicht optimalen Nichtstandardisierung. In Tabelle 2-2 ist das Nash-Gleichgewicht 43 im grauen Feld dargestellt. Geschäftsbereich 2

Geschäftsbereich 1

Tabelle 2-2

Architektur 1

Architektur 2

Architektur 1

(24, 9)

(15, 12)

Architektur 2

(0, 0)

(9, 21)

Pay-Off-Matrix beim Standardisierungsdilemma mit Beispielwerten

Das gesamtunternehmerische Optimum mit dem Wert 33 wäre erreicht, wenn sich beide Geschäftsbereiche auf Architektur 1 einigen würden. Zur Verdeutlichung der gewählten Zahlen dient folgendes Beispiel: Beide Geschäftsbereiche möchten in einem Intranet aktuelle Meldungen, Kontaktinformationen und Dateien bereichsintern und -übergreifend austauschen. Geschäftsbereich 1 hat ein Konzept erarbeitet, das auf einem CMS basiert und zusätzlich zur Erfüllung der Basisanforderungen die Möglichkeit anbietet, dass jeder Mitarbeiter eine persönliche Seite anlegen und bearbeiten kann. Das CMS benötigt UNIX als Betriebssystem auf dem Server und verlangt eine Oracle Datenbank. Geschäftsbereich 2 hat dagegen von einem externen Berater ein Konzept erstellen lassen, das auf einem Knowledge Management System (KMS) basiert. Das KMS erfordert Windows als Serverbetriebssystem und eine MS SQL Datenbank. Mit dem KMS könnten die Mitarbeiter über die Basisanforderungen hinaus Dateien verschlagworten und versionieren. Beide Lösungen kosten gleich viel, der Standardisierungsnutzen wäre die um die Hälfte kürzere Implementierungsdauer bei der zweiten Installation und würde zu gleichen Teilen auf die Geschäftsbereiche wirken (indem die gesamten Installationskosten geteilt werden). Negative

42

43

p kann als irrelevant angenommen werden, da es bei beliebigem Spielausgang jeder Partei zugute kommt. Das Nash-Gleichgewicht beschreibt in Spielen einen Zustand eines strategischen Gleichgewichts, von dem ausgehend kein einzelner Spieler für sich einen Vorteil erzielen kann, indem er allein seine Strategie verändert.

26

Komplexität von IT-Architekturen

übergeordnete Effekte 44 treten zu einem späteren Zeitpunkt ein und spielen für die Geschäftsbereiche zunächst keine Rolle. Der Zusatznutzen durch die gewünschten Funktionalitäten erscheint den Geschäftsbereichen größer, als der Nutzen eines Standards. Sie werden folglich auf ihren Konzepten und Forderungen beharren und das dargestellt ParetoOptimum wählen. Um ein Kaldor-Hicks-Optimum 45 zu erzielen muss s > z sein. Der IT-Bereich oder die übergeordnete Unternehmensleitung kann dazu regulierend eingreifen und die externen Effekte so ausgleichen, dass für beide Geschäftsbereiche das Nashgleichgewicht auch das Unternehmensoptimum ist. Dazu dienen entweder Subventionen oder Strafzahlungen. Im obigen Beispiel würde ein Beharren der Geschäftsbereiche auf einer jeweils individuellen Lösung folglich entweder zu Strafzahlungen (wodurch z < s würde) oder zu Subventionen (die s > z werden lassen) führen, um die Entscheidung zugunsten eines gesamtunternehmerischen Optimums zu beeinflussen. 2.3.2

Zentralisierung/ Dezentralisierung

Das in Abschnitt 2.3.1 vorgestellte Modell von DEWAN ET AL. vernachlässigt organisatorische Determinanten [Krcm05, 225]. Insbesondere bei divisionalen Organisationsstrukturen mit eigenverantwortlichen Geschäftsbereichen wird in der IT-Organisation ein Kompromiss zwischen zentralen und dezentralen IT-Abteilungen (als Bestandteile des IT-Bereichs) gewählt [Hein02, 47]. 94 Prozent aller IT-Bereiche sind hybrid organisiert, also weder völlig zentral noch vollkommen dezentral [MeKn98, 50]. Abbildung 2-5 zeigt eine typische hybride Organisationsstruktur.

44

45

U. a. Integrationskosten, falls die Applikationen Daten austauschen sollen, höhere Schulungskosten wegen der unterschiedlichen Benutzeroberflächen, eine geringere Flexibilität der Mitarbeiter, die bei einem Bereichswechsel Umschulungen benötigen, weniger Synergieeffekte in der Softwarearchitektur, da unterschiedliche Datenbanken betrieben werden usw. Eine Entscheidung ist dann effizient, wenn die Nutzengewinne der Begünstigten größer sind als die Nutzenverluste der Benachteiligten.

Komplexität von IT-Architekturen

27

Unternehmensleitung Zentrale ITAbteilung Geschäftsbereich 1

Abbildung 2-5

Geschäftsbereich 2

Geschäftsbereich 3

Beschaffung

Beschaffung

Beschaffung

Produktion

Produktion

Produktion

Vertrieb

Vertrieb

Vertrieb

Verwaltung

Verwaltung

Verwaltung

IT-Abteilung

IT-Abteilung

IT-Abteilung

IT-Bereich mit zentralen und dezentralen Abteilungen 46

Die zentrale IT-Abteilung betrachtet das gesamte Unternehmen und legt unabhängig von den Anforderungen der einzelnen Geschäftsbereiche eine langfristige, strategische Stoßrichtung fest. Sie bleibt dabei weitgehend fachunabhängig und definiert unternehmensweite Standards für die Informationssysteme und Prozesse der IT. Der einzelne Geschäftsbereich nimmt dagegen eine operative Sichtweise ein und sieht Applikationen primär als kurz- bis mittelfristige Problemlösung an 47. Nach MACK entstehen Projektvorschläge entweder aus den Geschäftsbereichen (Bottom-up) oder aus der zentralen IT-Abteilung heraus (Topdown). Die Mehrheit der Unternehmen verfolgt eine Bottom-up-Herangehensweise [Mack04, 9]. Falls in einer solchen Konstellation ein Geschäftsbereich eine neue Applikation einführen möchte, ist die IT-Abteilung des Geschäftsbereichs dafür zuständig. Diese sucht nach einer geeigneten Problemlösung und stellt diese dann der zentralen IT-Abteilung vor. Die unterschiedlichen Sichtweisen der zentralen IT-Abteilung und der IT der Geschäftsbereiche führen dazu, dass die Vorgaben der IT-Strategie und -Architektur in IT-Projekten nach dem Bottom-up Ansatz oft nicht eingehalten werden 48. Konformität zur IT-Strategie und -Architektur bedeutet für ein Projekt möglicherweise einen Mehraufwand, da z. B. bei der 46 47

48

Verändert übernommen aus [Hein02, 48]. MACK VWHOOW GD]X IHVW Ä,Q D VHQVH LW >,73URjektvorschläge aus den Geschäftsbereichen, Anmerkung des Verfassers] represents a capacity for limited strategic thinking as an organization operates by proposing numerous projects that frequently compete with each other but not building to a strategic objective. It unleashes the tactical conflict of many projects, often reflecting individual or group bias and exposing the possibility for the prisoner dLOHPPD³>0DFN@ HAFNER ET AL VWHOOHQ GD]X IHVW Ä%H]RJHQ DXI GLH IDFKOLFKH $UFKLWHNWXU ZLUG GHU NXU]IULVWLJHQ  Umsetzung fachlicher Anforderungen der Vorrang vor einer langfristig geplanten Zielarchitektur GHUJHVDPWHQ$SSOLNDWLRQVODQGVFKDIWHLQJHUlXPW³>+D6:@

28

Komplexität von IT-Architekturen

Implementierung Standards eingehalten werden müssen und Ressourcen für die Umsetzung der in der IT-Strategie vorgesehen Prozesse, Techniken und Methoden im Geschäftsbereich nicht ausreichend verfügbar sind. Dieser Mehraufwand wird im IT-Projektteam nicht immer akzeptiert, da das Projektbudget vom Geschäftsbereich gestellt wird [Mack04, 49]. Die zentrale IT-Abteilung versucht hingegen, durch eine für das Gesamtunternehmen verpflichtende IT-Strategie die IT optimal zu konfigurieren. Im IT-Projekt überwiegen dagegen die Interessen der Geschäftsbereiche. Es entsteht ein Konflikt zwischen dem gesamtunternehmerischen Optimum und den individuellen Wünschen [Mack04, 10], zwischen langfristigen Strategiezielen und kurzfristigen Projektzielen. Abbildung 2-6 skizziert den typischen Ablauf einer Applikationseinführung. Problem im Geschäftsbereich

Suche nach Applikationen IT-Abteilung Geschäftsbereich

Bewertung von Alternativen Entscheidung für eine Applikation Kostenkalkulation Vorschlag für IT-Projekt zur Applikationseinführung Entscheidung über Projektdurchführung Zentrale ITAbteilung

Abbildung 2-6

Prozess der Applikationseinführung 49

Ein Teil der Planung eines IT-Projekts erfolgt meist im Geschäftsbereich, bevor die zentrale IT-Abteilung überhaupt darüber entscheidet, ob und wie das IT-Projekt durchgeführt wird. Dies ist oft sinnvoll, da die Idee zu einem IT-Projekt zumeist dort entsteht, wo ein bestimmtes Problem durch IT-Unterstützung zu lösen ist, nämlich im Geschäftsbereich. Diese Praxis kann jedoch zu Situationen führen, in denen Belange der IT-Architektur unberücksichtigt bleiben, da zumindest für einige Komponenten in der Softwarearchitektur einer neuen Applikation im Unternehmen de jure und de facto Standards bereits vorliegen, die im Bottomup Vorgehen unberücksichtigt bleiben. Falls dies der Fall ist, sind die Akteure des ZweiPersonen-Nicht-Nullsummen-Spiels nun der Geschäftsbereich, der eine neue Applikation einführen und die zentrale IT-Abteilung, die eine Lösung auf Basis bestehender Standards erzielen möchte. Übertragen auf das Beispiel aus Abschnitt 2.3.1 würde Geschäftsbereich 1 49

Verändert und vereinfacht übernommen aus [GrMD05, 22].

Komplexität von IT-Architekturen

29

weiterhin ein CMS zur Einführung in einem IT-Projekt vorschlagen, die zentrale IT-Abteilung jedoch die Nutzung der bestehenden Groupware empfehlen. Diese erfüllt die Basisanforderungen, ermöglicht jedoch nicht den vom Geschäftsbereich gewünschten Zusatznutzen. Die daraus resultierende Pay-Off-Matrix zeigt Tabelle 2-3. Geschäftsbereich

Standard

Standard

Non-Standard

(s, p+s)

(0, p+z)

(0, p)

(0, p+z)

Zentrale IT Non-Standard Tabelle 2-3

Pay-Off-Matrix bei dezentraler Struktur

Die zentrale IT-Abteilung (in der Abbildung Zentrale IT) wird immer auf Standard spielen, da für sie bei Non-Standard immer 0 resultiert. Der Geschäftsbereich erhält dann bei Standard den gewünschten Basisnutzen und zusätzlich einen Standardisierungsnutzen (im Beispiel eine um die Hälfte verkürzte Implementierungsdauer). Bei Non-Standard, also dem Beharren auf der ursprünglich geplanten Lösung, erhält der Geschäftsbereich neben dem Basisnutzen den Zusatznutzen z. Mit den Beispielwerten aus Abschnitt 2.3.1 ergibt sich die in Tabelle 2-4 gezeigte Konstellation. Geschäftsbereich

Standard

Standard

Non-Standard

(9, 9)

(0, 15)

Zentrale IT Non-Standard Tabelle 2-4

Pay-Off-Matrix bei dezentraler Struktur mit Beispielwerten

Der Geschäftsbereich wird zur Maximierung des eigenen Nutzens immer Non-Standard spielen. Der maximale Unternehmensnutzen (im Beispiel 18) ergibt sich, wenn der Geschäftsbereich bestehende Standards nutzt. Wie bereits in Abschnitt 2.3.1 dargestellt kann eine standardkonforme Entscheidung nur erzielt werden, wenn für den Geschäftsbereich der Standardisierungsnutzen größer dem Zusatznutzen ist. Dazu stellen LOHMEYER ET AL. fest: Penalties for noncompliance should be set and enforced: a business unit might, for example, be charged the total cost of ownership for a noncompliant technology (including all overhead and extra maintenance and support costs), whereas for a compliant technology it would be charged for only the development costs. [LoPR02, 45]

30

Komplexität von IT-Architekturen

Kapitel 5 zeigt einen entsprechenden Ansatz zur Berechnung der regulierenden Transferleistungen, um ein Unternehmensoptimum bezüglich der Standardkonformität von neuen Applikationen zu erzielen.

2.4

Komplexitätsmanagement

Im Komplexitätsmanagement gilt es, ÄGDVULFKWLJH0D‰DQ3URGXNWIXQNWLRQDOLWlWNRPSOH[LWlW DP 0DUNW ]X SODW]LHUHQ XQG GLHVHQ .XQGHQQXW]HQ PLW PLQLPDOHU XQWHUQHKPHQVLQWHUQHU .RPSOH[LWlW ]X UHDOLVLHUHQ³ [EvSW98, 31] BÖHMANN und KRCMAR stellen allgemein fest, dass vor der Beherrschung der Komplexität die Reduktion stehen muss [BöKr05, 449]. Als grundlegende Strategien des Komplexitätsmanagements führen PILLER und WARINGER die Komplexitätsreduktion, -vermeidung und -beherrschung an [PiWa99, 28]. Die Autoren stimmen darin überein, dass die reine Beherrschung von hoher Komplexität nicht genügt, um Komplexitätskosten ausreichend zu reduzieren. Die möglichst genaue Abbildung komplexer Systeme führt zu immer komplexeren Modellen, die Erstellung und Pflege dieser Modelle wiederum verursacht hohe Kosten. Zur Beherrschung der Komplexität besagt $VKE\¶V *HVHW] GHU HUIRUGHUOLFKHQ 9DULHWlW dass es unmöglich ist, ein System ohne die GDIU HUIRUGHUOLFKH 9DULHWlW XQWHU .RQWUROOH ]X EULQJHQ ]X UHJXOLHUHQ ]X OHQNHQ >$VKE I@,Q%H]XJQDKPHGDUDXIVFKUHLEW0ALIK, dass HLQ6\VWHPPLWHLQHUJHJHEHQHQ.RP SOH[LWlW QXU PLW +LOIH HLQHV PLQGHVWHQV HEHQVR NRPSOH[HQ 6\VWHPV XQWHU .RQWUROOH >JH EUDFKWZHUGHQNDQQ@>0DOL@QDFK>&KUL@  (LQH 0HWKRGH ]XU 9HUULQJHUXQJ XQG %HKHUUVFKXQJ GHU 9DULDQWHQYLHOIDOW XQG GDPLW GHU Komplexität ist die 9DULDQW0RGHDQG(IIHFWV$QDO\VLV>(Y6:I@YJO$EELOGXQJ 

9DULDQWHQ beherrschen

Ziel: Kundenwünsche mit weniger 9DULDQWHQYLHOIDOW realisieren

Auswahl

e ert nti ng rie no taltu nte es ria tg 9a oduk Pr

9DULDQWHQDQDO\VH

B

tu er ew

ng

$EELOGXQJ 9DULDQW0RGHDQG(IIHFWV$QDO\VLV 50

Die Aktivitäten in der 9DULDQWHQDQDO\VH sind dabei: x 7UDQVSDUHQ]EH]JOLFKGHU9DULDQWHQYLHOIDOWHU]HXJHQ 50

 9HUHLQIDFKWEHUQRPPHQDXV>(Y6:@

Komplexität von IT-Architekturen

31

x

Variantenvielfalt auf Teile-, Baugruppen- und Produktebene analysieren

x

Kundenrelevante Varianten identifizieren

Die Aktivitäten und Ergebnisse in der variantenorientierten Produktgestaltung sind: x

Vielfalt frühzeitig reduzieren und gestalten

x

Varianten erst am Ende der Wertschöpfungskette entstehen lassen

x

Anzahl der Funktionsträger reduzieren

x

Schnittstellen vereinheitlichen

Die Aktivitäten in der Bewertung sind: x

Variantenabhängige Tätigkeiten bestimmen

x

Kostenverursachende Produktmerkmale pro Tätigkeit ermitteln

x

Ressourcenverzehr in Abhängigkeit der Produktmerkmale bestimmen

x

Verbrauchs- und Kostenfunktion aufstellen [EvSW98, 32]

Die Analyse des Ist-Zustandes (Variantenvielfalt) ist die Grundvoraussetzung, um Ursachen der Komplexität zu erkennen und Maßnahmen zu deren Reduzierung treffen zu können [EvSW98, 32]. In der IT eignen sich dazu so genannte Enterprise Architecture Tools 51, deren Verbreitung kontinuierlich zunimmt [Jame04, 2]. Nach EVERSHEIM ET AL. ist das Ziel der variantenorientierten Produktgestaltung, auf Basis der Variantenanalyse die notwendigen Produktvarianten so spät wie möglich in der Wertschöpfungskette entstehen zu lassen. Dazu dienen Standardisierung und Modularisierung [EvSW98, 32]. MAUNE schlägt ein Variantenmanagement in den fünf Stufen Variantenfestlegung,

Variantenbegrenzung,

Variantenreduzierung,

Variantenbeherrschung

und

Variantenverlagerung vor [Maun01, 14]. Die Standardisierung und Modularisierung sind dabei Bestandteile des Schritts Variantenbegrenzung. BÖHMANN und KRCMAR wenden den Ordnungsrahmen von BLISS 52 auf variantenreiche IT-Dienstleistungen an. Anhand eines Fallbeispiels wird die Komplexität in den Schritten Standardisierung und Prozessorientierung, Verschiebung der Entkopplungspunkte, Modularisierung, Bündelung und Programmund Kundenbereinigung reduziert [BöKr05, 457 - 466]. Auf die gezeigten Ansätze zur Komplexitätsreduktion übertragen liefert Kapitel 3 dieser Arbeit ein Modell zur strukturierten Erhebung und Darstellung von IT-Architekturen (entspricht der Variantenanalyse). Die Verfahren aus den Kapiteln 4 und 5 ermöglichen eine kennzahlengestützte Variantenreduzierung, einerseits auf Ebene der Strategie (Variantenbegrenzung und -reduzierung im Rahmen der Programm- und Kundenbereinigung) und

51 52

So benannt u. a. bei [Peyr04, 1] und bei [Sche04]. [Blis00, 197 - 202].

32

Komplexität von IT-Architekturen

andererseits auf Ebene der Standardisierung und Modularisierung. Das Modell in Kapitel 6 ermöglicht die Bewertung von Entscheidungen, die die IT-Architektur betreffen (entspricht dem Schritt Bewerten aus Abbildung 2-7), vor allem in Bezug auf ihren Beitrag zur Komplexität. Die in Kapitel 7 vorgestellte Applikation implementiert die in den Kapiteln 3 bis 6 vorgestellten Modelle und Kennzahlen und ermöglicht die fortlaufende Steuerung (und damit die Beherrschung) der Komplexität in der IT-Architektur.

Kapitel 3 Modellierung von IT-Architekturen 3 Modellierung von IT-Architekturen 3.1

Übersicht

Dieses Kapitel beschreibt nach einer Begriffsbestimmung (Abschnitt 3.2) Modelle zur Abstraktion von IT-Architekturen (Abschnitt 3.3). Die zugrunde liegenden Modelle ITBebauungsplan und IT-Infrastruktur werden detailliert dargestellt (Abschnitte 3.4 und 3.5). Abschnitt 3.6 integriert den IT-Bebauungsplan und die IT-Infrastruktur zu einem übergreifenden Modell. Die Aktivitäten im Rahmen des Managements von IT-Architekturen werden in Abschnitt 3.7 vorgestellt. Abbildung 3-1 zeigt die Einordnung in das gesamte Vorgehensmodell. Strategiekonforme ITInvestitionen

IT-Strategie

4

strategische Sicht

IT-Projekte

Architekturkonforme ITProjekte

architektonische Sicht IT-Architektur

Modellierung von ITArchitekturen

3 5 Applikationen 7

Wertbeitrag von ITArchitektur-Management

6

Bewertung/ Steuerung

Abbildung 3-1 Einordnung von Kapitel 3

Technologien

Softwareunterstützung des Managements von ITArchitekturen

Darstellung

34

3.2

Modellierung von IT-Architekturen

Begriffsbestimmung Ä7KHVH SLFWXUHV DUH PHDQW WR HQWHUWDLQ \RX 7KHUH LV QR VLJQLILFDQW PHDQLQJ WR WKHDUURZVEHWZHHQWKHER[HV³>&%%*LL[@ 53

Nach VITRUVIUS (geschrieben um 20 vor Christus) soll die Architektur die Forderungen nach solider Bauweise, Zweckdienlichkeit und Anmut erfüllen (Firmitas, Utilitas, Venustas) 54. Ä$UFKLWHNWXU LVW GDV NXQVWYROOH NRUUHNWH XQG JUR‰DUWLJH 6SLHO GHU XQWHU GHP /LFKW YHUVDP PHOWHQ%DXN|USHU³ definiert LE CORBUSIER [LeCo63, 38] und GROPIUS stellt fest: Ä1XUYROO NRPPHQH+DUPRQLHLQGHUWHFKQLVFKHQ=ZHFN)XQNWLRQVRZRKOZLHLQGHQ3URSRUWLRQHQGHU )RUPHQNDQQ6FK|QKHLWKHUYRUEULQJHQ³. VON GERKAN schreibt: Ä$UFKLWHNWXULVWXQDEKlQJLJ GDYRQZLHSURIDQRGHUDQVSUXFKVYROOGHU=ZHFNLVWGHPVLHGLHQWOHW]WOLFKGLH*HVDPWKHLW GHUGXUFK0HQVFKHQKDQGYHUlQGHUWHQ8PZHOWXQGGDPLWHLQHNXOWXUHOOH/HLVWXQJGHU0HQ VFKHQ³ 55 KRCMAR leitet aus klassischen Architekturdefinitionen ab, dass ÄHLQH,QIRUPDWLRQV V\VWHP$UFKLWHNWXU HLQH QHXH XQG XPIDVVHQGH .XQVW >VHLQ N|QQWH@ DQ GHQ =ZHFN JHEXQGHQ,QIRUPDWLRQXQG.RPPXQLNDWLRQEHUHLW]XVWHOOHQ³ [Krcm90, 396]. Der Begriff ,7$UFKLWHNWXU in dieser Arbeit lehnt sich an die Definition von BIRKHÖLZER und VAUPEL an: Ä,7$UFKLWHNWXUNDQQPDQDOVGLH/HKUHXQG.XQVWGHU6WUXNWXULHUXQJYRQ,7 6\VWHPHQ EHVFKUHLEHQ 6LH EHVFKlIWLJW VLFK PLW GHQ )UDJHQ ZLH ,76\VWHPH VWUXNWXULHUW ZHUGHQ ZLH YHUVFKLHGHQH ,76\VWHPH LQWHUDJLHUHQ XQG ZLH GLH .RPSOH[LWlW YRQ ,7 8PJHEXQJHQPLW+LOIHJHHLJQHWHU6WUXNWXULHUXQJEHKHUUVFKWZHUGHQN|QQHQ>«@³ [BiVa03, 11]. Der Begriff ,7$UFKLWHNWXU bezieht sich sowohl auf die Tätigkeit eines IT-Architekten als auch auf das Ergebnis dessen Tätigkeit [Wall96, 34; BiVa03, 19] mit dem Ziel, Informationssysteme (Applikationen) zu beschreiben und zu konstruieren. Die statische Sichtweise auf das Ergebnis wird im Rahmen dieser Arbeit als IT-Architektur bezeichnet, die dynamische (der Prozess zur Zielerreichung) als IT-Architektur-Management. Die Mehrzahl der Definitionen von IT-Architektur verbindet diese Sichten, vgl. [Boar99, 30; BiVa03, 19; WeRo04, 30]. Der übergreifende Architekturbegriff in einem Unternehmen ist die Unternehmensarchitektur ((QWHUSULVH$UFKLWHFWXUH) 56. Demnach erzeugen Unternehmen nicht nur Produkte oder Dienstleistungen und bieten diese an, sondern können selbst als Produkt verstanden werden, das wie jedes andere von einem Architekten entworfen und gebaut werden muss [BeNS03, 1]. Dies geschieht im Rahmen des %XVLQHVV (QJLQHHULQJ [Wint03, 88; 53

 (UOlXWHUXQJ GHU $XWRUHQ Ä$ VSHDNHU DW D UHFent software architecture conference, coming to a complex but ultimately inadequate boxes-and-linesHYHU\ZKHUHYLHZJUDSKRIKHUV\VWHP¶VDUFKL tecture and deciding that trying to explain it inIURQWRIDFURZGZRXOGQRWEHDJRRGLGHD³ 54 Vitruvius: De architectura libri decem, Liber I, Capitulum III. Zitiert nach BIBLIOTHECA AUGUSTANA: http://www.fh-augsburg.de/~harsch/Chronologia/Lsante01/Vitruvius/vit_ar01.html, Abruf am 2006-12-20. 55 Letztere beiden zitiert nach http://de.wikiquote.org/wiki/Architektur, Abruf am 2006-12-07. 56  Ä7KHHQWHUSULVHDUFKLWHFWXUHLVWKHRUJDQL]LQJORJLFIRUEXVLQHVVSURFHVVHVDQG,7LQIUDVWUXFWXUH reflecting the integration and standardization requirements of the compDQ\¶V RSHUDWLQJ PRGHO³ [RoWR06, 9]

Modellierung von IT-Architekturen

35

ÖsBl05, 78]. Die Unternehmensarchitektur versucht dabei, eine umfassende, integrierte Sichtweise auf die Organisation einzunehmen und deren Bestandteile abzubilden. Aufgrund der hohen Komplexität des Modellierungsproblems werden Teilarchitekturen gebildet [NoNB04, 173 f.]. Als eine solche Teilarchitektur hat die IT-Architektur die Applikationen des Unternehmens und deren Umgebung, insbesondere die Geschäftsprozesse, als Fokus. In der Literatur hat sich jedoch bis jetzt kein einheitliches Verständnis über den Begriff ITArchitektur etabliert [KrSe03, 26; Wall96, 26; Nunn03, 1; Boll04; BYDH03, 173] und dieser wird entsprechend auf unterschiedlichen Detaillierungsebenen in wechselndem Kontext verwendet 57. Als Grundlage für diese Ausarbeitung wird IT-Architektur verstanden als eine Investition [Jone03, 3] in die strukturierte [Krcm90, 396], abstrahierte [AiDo05, 608; Dern03, 18] Gesamtsicht und Organisation der Applikationen eines Unternehmens [BYDH03, 172]. Sie stellt nach der Definition von KRÜGER und SEELMANN-EGGEBERT ÄGLH*HVDPWKHLWDOOHU.RP SRQHQWHQ 7HFKQRORJLHQ XQG RUJDQLVDWRULVFKHQ 0D‰QDKPHQ GDU GLH GLH LP 8QWHUQHKPHQ YRUNRPPHQGHQ )XQNWLRQHQ 3UR]HVVH XQG 'DWHQ DEELOGHQ XQG GHUHQ =XVDPPHQVSLHO HUP|JOLFKHQ³ [KrSe03, 29]. Die IT-Architektur wird aus der IT-Strategie abgeleitet, ist Teil dieser [BlBe03, 85 f.; Nunn03, 3] und beeinflusst diese [SaWi02, 44]. Mögliche Bestandteile einer IT-Architektur sind Prinzipien, Leitlinien, Standards, Regeln und Abbildungen, die die Weiterentwicklung der IT-Strukturen im Rahmen des ITArchitektur-Managements ermöglichen [Boar99, 30; BoLT00, 46]. In dieser Hinsicht wird ITArchitektur oft mit der Stadtplanung verglichen, welche die geordnete Entstehung von Gebäuden (Applikationen) innerhalb einer Stadt (IT-Bebauung) regelt und die Infrastruktur dazu bereit stellt [Broa05; Cook96, 20 f.; VSFT04, 2; LaSV00, 118 - 127; Mert04, 315; Zach97, 4 und 9]. Die IT-Architektur definiert technologische und organisatorische Vorgaben für die IT, an denen sich alle Maßnahmen des IT-Einsatzes und der IT-Bereitstellung orientieren [GeAh01, 102]. ZACHMAN gibt den Modellen einen besonderen Stellenwert, da seiner Meinung nach Prinzipien allein nicht ausreichen, um die IT-Architektur zu beherrschen: Ä,ZRXOGDUJXHSULQFLSOHVDUHQLFHEXWWKHUHLVQRVXEVWLWXWHIRUDUFKLWHFWXUHDFWXDO PRGHOV ZKHQWKLQJVJHWFRPSOLFDWHGDQGVWDUWWRFKDQJH³ [ZachoJ, 2]. Architekturmodelle bieten einen strukturierten, ganzheitlichen Überblick über die ITArchitektur eines Unternehmens. Dazu ermöglichen sie die Gestaltung komplexer Strukturen durch Vereinfachung ohne dabei übermäßig und damit unzulässig zu simplifizieren [Pohl00, 31]. Ein Architekturmodell bietet verschiedene Sichten auf die IT-Architektur und teilt diese mit dem Ziel der Komplexitätsreduktion in Ebenen ein [Wall96, 38; Pohl00, 46;

57

Beispiele für verschiedene Architekturausprägungen finden sich bei [KrSe03, 26 - 28]. WALL EHOHJWGDVVÄGLH%HJULIIH,QIRUPDWLRQVV\VWHP$UFKLWektur, Informationsarchitektur, InformatikarchiWHNWXU $QZHQGXQJVV\VWHPDUFKLWHNWXU $QZHQGXQJVDrchitektur oder Unternehmensarchitektur in ZHLWJHKHQGV\QRQ\PHU%HGHXWXQJJHEUDXFKW³ZHUGHQ>:DOO@

36

Modellierung von IT-Architekturen

Krcm90, 398] 58. Abbildung 3-2 zeigt das ISA (Informationssystem-Architektur)-Kreiselmodell von KRCMAR, das ein solches Ebenenkonzept verfolgt [Krcm90, 399 - 402]. Die vorliegende Ausarbeitung fokussiert insbesondere auf die Ebenen Prozess-, Applikations- und Technologiearchitektur (in Abbildung 3-2 dick umrandet).

Strategie

Prozessarchitektur

AnwendungsArchitektur

Abbildung 3-2

AufbauorganisationsArchitektur

Da Archi

ten tektur

Infra

struktur

KommunikationsArchitektur

ISA-Konzept als Kreiselmodell 59

Die Prozessarchitektur 60 beschreibt das Zusammenwirken der Geschäftsprozesse auf verschiedenen Ebenen [Wint03, 102], d. h. den Gesamtzusammenhang der Leistungsentwicklung, -erstellung und des -vertriebs in einem Unternehmen [Wint04, 317]. Geschäftsprozesse bilden die betrieblichen Abläufe ab [Krcm05, 119] und bestehen aus einer Folge von mindestens zwei logisch zusammenhängenden Aktivitäten [Wint03, 103; Wall00, 214] die mit einem bestimmten Input eine messbare Leistung erbringen [KrSe03, 99]. Die Prozessarchitektur ist Teil der Geschäftsarchitektur, die über die Ablauforganisation auch die Aufbauorganisation definiert [Foeg03, 59]. Eine vertikale Prozessauflösung (bzw. -zerlegung oder -dekomposition) ergibt eine Prozesshierarchie. Durch die horizontale Prozessauflösung werden Prozesse auf der gleichen Hierarchieebene getrennt, z. B. auf oberster Ebene in Prozessgruppen (vgl. Abbildung 3-3).

58

59 60

Eine Übersicht über Architekturmodelle bietet z. B. [Hild01, 171 - 185], weitere Beispiele finden sich bei [MaSc03, 273 - 279]. Verändert übernommen aus [Krcm90, 399]. Eine Übersicht über Modelle und Techniken auf Prozessebene findet sich z. B. bei [Wint03, 101 107].

Modellierung von IT-Architekturen

37

Vertikale Prozessauflösung

Horizontale Prozessauflösung

Prozessgruppe X

Level 1: Prozessgruppen

X.1

X.2

X.n

X.2.1

X.2.2

X.2.m

« n: Anzahl der Prozessübersichten innerhalb von Prozessgruppe X m: Anzahl der Prozesselemente innerhalb der Prozessübersicht X.2

Abbildung 3-3

Level 2: Prozessübersichten

Level 3: Prozesselemente Level 4-6: Aktivitäten auf Objekt-, Verrichtungs-, Feldebene

Stufenkonzept hierarchischer Prozessmodelle 61

Das Ergebnis ist ein hierarchisches Prozessmodell, das Über-/ Unterordnungsbeziehungen und Vorgänger-/ Nachfolgerbeziehungen enthält [Krcm05, 121]. Die Prozesse definieren Anforderungen an und beziehen Unterstützungsleistungen von Applikationen [PiRe03, 144]. Die Applikationsarchitektur beschreibt das Zusammenwirken der Applikationen innerhalb eines Unternehmens [Wint03, 107]. Insbesondere enthält diese Geschäftsapplikationen, also Informationssysteme, die Abläufe innerhalb des Unternehmens und zu anderen Unternehmen automatisieren [LoPR02]. Sie enthält alle Regeln, Vorschriften und Konzepte, die dem Aufbau der Applikationslandschaft zugrunde liegen [Pohl00, 11]. Im Gegensatz zur Softwarearchitektur, die den inneren Aufbau einzelner Applikationen, involvierte Technologien und deren Beziehungen darstellt [Fink02, 655; Foeg03, 57 und 59], zielt die ApplikaWLRQVDUFKLWHNWXU DXI GLH $EELOGXQJ GHU ÄZusammenhänge der Anwendungslandschaft zur Unterstützung der Geschäftsprozess ab³>+D:L@$SSOLNDWLRQHQEH]LHKHQ8QWHUVWW zungsleistungen von der Technologiearchitektur [PiRe03, 145]. Die Technologiearchitektur beschreibt, welche Informations- und Kommunikationstechnologien in den Applikationen eines Unternehmens genutzt werden [Krcm90, 400]. Diese EHVWHKW XD DXV GHU ÄMenge aller Hardware- und aller systemnahen Softwarekomponenten³GLHGLH/DXI]HLWXQG0DQDJHPHQWXPJHEXQJIU(QWZLFNOXQJ7HVWXQG3URGXNWLRQYRQ Applikationen bilden [Dern03, 27]. Die IT-Infrastruktur wird bei der Entwicklung von Applikationen für die Geschäftsprozesse applikationsübergreifend eingesetzt [Liu02, 14] und nimmt eine Kategorisierung und Organisation der Technologien vor [MSTI03, 30]. WEILL ET AL. sehen die Infrastruktur als ÄFHQWUDOO\FRRUGLQDWHGVKDUHG,7VHUYLFHV³ [WeRo04, 27].

61

 ,Q$QOHKQXQJDQ>/X*%@

38

Modellierung von IT-Architekturen

3.3

Betrachtete Ebenen

In dieser Arbeit wird eine IT-Architektur mittels der Modelle IT-Bebauungsplan und ITInfrastruktur repräsentiert (vgl. Abbildung 3-4). IT-Architekur-Ebene Prozessarchitektur

Modell (Repräsentation)

IT-Bebauungsplan

Applikationsarchitektur Technologiearchitektur

Abbildung 3-4

IT-Infrastruktur

Abbildung der Architekturebenen

Der IT-Bebauungsplan verknüpft die Prozess- und Applikationsarchitektur, die IT-Infrastruktur verknüpft die Technologie- und Applikationsarchitektur.

3.4

IT-Bebauungsplan ³'HU%HEDXXQJVSODQHQWKlOWGLHUHFKWVYHUELQGOLFKHQ)HVWVHW]XQJHQIUGLHVWlG WHEDXOLFKH2UGQXQJ´ 62

Der IT-Bebauungsplan 63 bildet die Prozess- und Applikationsarchitektur ab, indem er die Applikationen nach Geschäftsprozessen organisiert und Prozesse und Applikationen integriert darstellt [HeSc04, 32 f.] (vgl. Abbildung 3-5).

62 63

Zitiert nach Baugesetzbuch (BauGB), §8 (1). Synonyme Begriffe sind Unternehmensbebauungsplan, IS-Plan, Informationssystemplan, ITMasterplan oder Rahmenarchitekturplan [GaMa05, 37].

Modellierung von IT-Architekturen

39

Prozess Prozess 1

Prozess 2

Prozess 3

Prozess n

Sparte

Sparte 1

Sparte 2

Applikation unterstützt mehrere Prozesse

Applikation unterstützt mehrere Sparten

Sparte n

Übergreifend

Abbildung 3-5 IT-Bebauungsplan (schematisch)

Im Gegensatz zu dem oben zitierten Zweck des Bebauungsplans im Städtebau kann der ITBebauungsplan Ist- und Soll-Zustände abbilden. Die Abdeckung von Geschäftsfunktionalität in den Prozessen durch die IT steht im Zentrum der Betrachtung. NIEMANN definiert Bebauungsplanung als ÄGDV IDFKOLFK JHWULHEHQH 9RUJHKHQ ]XU (QWZLFNOXQJ HLQHU 6ROO6WUXNWXU HLQHU $QZHQGXQJVODQGVFKDIW >«@ 'LH $QZHQGXQJVODQGVFKDIW XPIDVVW GLH %HUHLFKH *H VFKlIWV $QZHQGXQJV XQG 6\VWHPDUFKLWHNWXU HUODXEW DOVR ]% GLH 5HIHUHQ]LHUXQJ *H VFKlIWVSUR]HVV ! $QZHQGXQJVV\VWHP ! ,QIUDVWUXNWXU³ [Niem05, 157]. Übertragen auf die Begrifflichkeiten und Modelle in dieser Arbeit bedeutet das, dass der Bebauungsplan die Geschäftsprozesse mit den Applikationen verknüpft und die IT-Infrastruktur die Applikationen mit den dahinter liegenden Technologien. Als weitere Dimension werden im ITBebauungsplan Sparten (auch Geschäftsbereiche, Niederlassungen, Produktgruppen usw. sind möglich) abgebildet [Niem05, 121]. Eine Applikation wird im Rahmen der Modellierung einem oder mehreren Prozessen und einer oder mehreren Sparten zugeordnet [CEB01, 36 f.; Eul00, 86]. Abbildung 3-5 zeigt ein Beispiel, in dem zusätzlich Spartenübergreifende Applikationen (Applikationen, die keiner speziellen oder allen Sparten zugeordnet sind) angedeutet sind. Die Prozessorientierung in der IT wird kontrovers diskutiert [Wall00, 210], gilt mittlerweile jedoch als State-of-the-Art [Sinz04]. Alternativ kann sich der IT-Bebauungsplan an so genannten Funktionsdomänen orientieren [KrSe03, 128 f.; LaMS03, 77]. Der IT-Bebauungsplan ist der Softwarekartografie zuzuordnen, deren Ziel nach LANKES ET AL. ist, ÄNRP SOH[H $QZHQGXQJVODQGVFKDIWHQ LQ 8QWHUQHKPHQ V\VWHPDWLVFK GDU]XVWHOOHQ XQG GDPLW GLH %HVFKUHLEXQJ %HZHUWXQJ XQG *HVWDOWXQJ YRQ $QZHQGXQJVODQGVFKDIWHQ ]X YHUEHVVHUQ³ [LaMW05, 1443]. Aus Gründen der Übersichtlichkeit werden oft nur die funktional wichtigen Applikationen im IT-Bebauungsplan abgebildet. Kriterien zur Klassifizierung von Applikatio-

40

Modellierung von IT-Architekturen

nen finden sich z. B. bei [KrSe03, 162 - 166]. Voraussetzung für die Erstellung eines ITBebauungsplans ist das Vorliegen der Dokumentation und Modellierung der Geschäftsprozesse. Sind diese Informationen nicht verfügbar, steigt der Aufwand zur Erstellung des ITBebauungsplans entsprechend an. LANKES ET AL. 64 haben in einer umfassenden Untersuchung verschiedene Typen von Softwarekarten identifiziert, die alle die Applikation als zentrales Objekt behandeln. Die Autoren unterscheiden zunächst zwischen Softwarekarten mit Kartengrund und ohne Kartengrund zur Verortung. Bei Softwarekarten mit Kartengrund spielt die geografische Position der Elemente eine Rolle, bei Karten ohne Kartengrund hat die Positionierung der Elemente keine Bedeutung. Bei den Softwarekarten mit Kartengrund werden drei Typen unterschieden: Cluster-, Prozessunterstützungs- und Intervallkarten (vgl. Abbildung 3-6). Softwarekarte Ohne Kartengrund

Mit Kartengrund Matrixkarte

Intervallkarte Abbildung 3-6

Clusterkarte Prozessunterstützungskarte

Klassifikation von Softwarekarten

Bei den Clusterkarten bilden logische Einheiten (so genannte Cluster) die Basis der OrdQXQJ6ROFKH&OXVWHUN|QQHQ]%)XQNWLRQVEHUHLFKHJHQDQQWVLQGXDÄ&XVWRPHU0DQD JHPHQW³Ä%XVLQHVV$GPLQLVWUDWLRQ³ RGHU2UJDQLsationseinheiten (z. B. Personalverwaltung, Einkauf oder Vertrieb) sein. Die Cluster können beliebig angeordnet werden. Die Prozessunterstützungskarte verortet die dargestellten Elemente an den Geschäftsprozessen und an möglichen weiteren organisatorischen Ausprägungen. Auf der x-Achse werden die Geschäftsprozesse, auf der y-Achse Organisationseinheiten, Systemklassen oder Zeitintervalle abgetragen. Auf einer Intervallkarte werden auf der x-Achse die Zeit und auf der y-Achse z. B. Applikationen, IT-Projekte oder Organisationseinheiten eingetragen. Sie lehnt sich stark an das Gantt-Diagramm an. Softwarekarten ohne Kartengrund sind z. B. UMLKlassendiagramme. Sie dienen zumeist der Strukturierung von konkreten Problemen und nicht der Darstellung von Applikationslandschaften ganzer Unternehmen. Aufgrund der Unterscheidung zwischen IT-Infrastruktur und IT-Bebauungsplan wird in dieser Arbeit mit einer Softwarekarte von Typ Prozessunterstützungskarte im ITBebauungsplan und mit dem Kartentyp Clusterkarte bei der IT-Infrastruktur gearbeitet. Die Intervallkarte kommt innerhalb beider Modelle zur Visualisierung von Lebenszyklen zum Einsatz. Softwarekarten ohne Kartengrund werden im Rahmen der in Kapitel 7 vorgestellten 64

Dem folgenden Absatz liegt der Beitrag [LaMW05, 1449 - 1457] zu Grunde.

Modellierung von IT-Architekturen

41

Applikation IT-Architektur-Management-Portal als hyperbolische Bäume zur Visualisierung von Übersichtsdiagrammen eingesetzt. Abbildung 3-7 zeigt ein Beispiel eines IT-Bebauungsplans. Der Plan stellt den IstZustand bei einem Versicherungskonzern dar 65.

65

Der Bebauungsplan aus dem Beispiel basiert auf [Klei04, 349], [Niem05, 167] und Projekterfahrungen.

Abbildung 3-7

übergreifende Systeme

Rückversicherung

sonstige

KFZ

SHU

AD-System alt

FJA/COR Sonder-Policen

GoFIS

Pflegevers.

DB, SHU, KFZ

Audatex

Schaden

Exkasso

RL-Rechnungslegung

Informatica

DWH auf DB2

CRM

DWH - SHU

GADIS

Cognos

DW BKV

Arbeitskorb (3), DMS (4), Texterstellung (3), Outputsystem (1) für alle Produkte

Geschäftsprozess Session Manager

DB Kunde für SHU, KFZ.

Agentur Inkasso Inkasso SAP FS RI (RV-Anwendung)

Betrug

Adresse, Kundendatenbank

RVS

Moped

KFZ alt

KFZ

Spezialversich.

SHU 2

SHU alt

SHU neu

Beihilfe

Med

Krankensysteme

Rückversicherung

IT-Bebauungsplan (Beispiel)

K-Risiko

Produktentw.

Fonds Gesundheit neu

Makler

Kranken Firmenkundenportal

Restschuldversicherung

Schaden

Produktentw.

XYZ

Bestand neu

Schden III

Leben

BAV Portal KFZ

Bestandsführung alt

Exkasso

Produktentw.

Mahn/Inkasso

Sparte

Makler Inkasso

Rechnungswesen und Verwaltung

IRechnungswesen alt SAP FI/CO SAP MM; SAP SD Intranet Procurement FM-Data Zweigaufteilung HR Altsystem (Personal) PEN (Personal) Personaleinsatzplanung

Inkasso/ Exkasso

Vertriebssteuerung

Provision

Schaden/ Leistung

Provision & Vermittlerverwaltung Provision alt

Antrag/ Bestand

Alt Schaden

Exkasso . Leben alt Ink. ISonder-Policen Exk. SHU neu Exk. SHU alt

Vertrieb

Provision RER Vertriebslogbuch VERE VIS

Produktentwicklung

Unternehmenssteuerung

Konzerninformationssystem

Prozess

42 Modellierung von IT-Architekturen

Modellierung von IT-Architekturen

43

Im Beispiel kommen neben der Verortung der Applikationen anhand von Geschäftsprozessen und Sparten zur weiteren Erläuterung Farben und Formen zum Einsatz. Im Allgemeinen bestehen bei grafischen Visualisierungen die folgenden Variationsmöglichkeiten [MaWi04, 15 f.]: x

Farbe: Farben können zur Kennzeichnung der Zugehörigkeit zu oder Abgrenzung von einer Gruppe verwendet werden oder auf bestimmte Zustände hinweisen. Im Beispiel gibt die Einfärbung eines Rechtecks (das eine Applikation repräsentiert) den momentanen Status im Lebenszyklus der Applikation an. So bedeutet Grün, dass die Applikation momentan entwickelt wird, Blau zeigt an, dass die Applikation produktiv im Einsatz ist.

x

Form: Im Beispiel sind alle Applikationen als Rechtecke dargestellt. Farbige Punkte auf den Rechtecken besagen, auf Basis welches Betriebssystems die Applikation implementiert ist. Ein gelber Punkt steht für BS2000, ein schwarzer für Windows und ein hellblauer für UNIX.

x

Räumliche Positionierung: Es ist möglich, Objekte entlang von Achsen ähnlich einer Tabelle anzuordnen. Weiterhin können Beziehungen durch räumliche Nähe ausgedrückt werden. Schließlich lässt sich durch Überlagerung die Zugehörigkeit von Unterobjekten zu einem Objekt darstellen. Im Beispiel gibt die Position der Rechtecke Auskunft über die Zugehörigkeit einer Applikation zu Geschäftsprozessen und Sparten.

x

Größe: Mit der Größe von Objekten lassen sich quantifizierbare Aspekte darstellen wie etwa die Anzahl der Anwender einer Applikation oder die Höhe der Lizenzkosten pro Zeiteinheit. Der IT-Bebauungsplan in Abbildung 3-7 nutzt diese Art der Informationsvermittlung nicht.

x

Verbindungen: Verbindungslinien können Kommunikationsbeziehungen in verschiedenen Ausprägungen wie etwa lesender/ schreibender Zugriff, Aufruf einer Funktion oder auch den Start eines Prozesses repräsentieren. Verbindungen werden in der hier vorgestellten Softwarekarte nicht dargestellt.

Nicht alle der genannten Varianten lassen sich problemlos kombinieren. So ist es schwierig, Elemente sowohl entlang von Achsen als auch in räumlicher Nähe anzuordnen, ohne nachteilige Überschneidungen oder übermäßigen Platzverbrauch zu beanspruchen. Auch die Darstellung von Verbindungen zwischen Applikationen über Schnittstellen und/ oder Datenströme führt zu sehr unübersichtlichen und damit nahezu wertlosen Darstellungen, wie das Beispiel in Abbildung 3-8 demonstriert.

44

Modellierung von IT-Architekturen

Abbildung 3-8

Softwarekarte mit sehr hoher Komplexität 66

Der in dieser Arbeit vorgestellte IT-Bebauungsplan verzichtet daher auf die grafische Darstellung von Schnittstellen, die jedoch im Datenmodell erfasst werden. Um die Übersichtlichkeit des IT-Bebabuungsplans zu gewährleisten, kommen die Visualisierungen Farbe und räumliche Positionierung sowie in beschränktem Maß die Form zum Einsatz. So dienen die gestrichelten Umrandungen von Rechtecken dazu, Applikationen abzubilden, die zu mehreren Prozessen oder Produkten gehören. Diese Prozesse oder Produkte sind jedoch auf der x- oder y-Achse nicht unmittelbar nebeneinander abgetragen. In Abbildung 3-9 ist der Prozess Vertrieb fokussiert dargestellt. Die Applikation Fonds bedient die Sparten Leben und sonstige, die Applikation Firmenkundenportal alle bis auf Kranken und die Applikation Makler kommt bei den Sparten Leben und SHU zum Einsatz.

66

Übernommen aus [CEB01, 13].

Modellierung von IT-Architekturen

Abbildung 3-9

45

IT-Bebauungsplan (Prozessvergrößerung)

Da in großen Unternehmen Hunderte von Applikationen im Einsatz sind, wird ein ITBebauungsplan in der vorgestellten Ausprägung schnell unübersichtlich. Wie in der klassischen Kartografie sind auch hier verschiedene Maßstäbe vorstellbar. Der Quadrant Vertrieb und Leben etwa kann als eigener Teil-Bebauungsplan dargestellt werden, um einen höheren Detaillierungsgrad zu erzielen (vgl. Abbildung 3-10). Vertrieb Kundenakquise

Antrag

Risikoprüfung

Policenerstellung

Leben

Kapital

Risiko

Rente

Abbildung 3-10 Teil-Bebauungsplan (Beispiel)

Je nach Anzahl und gewünschter Detaillierung können weitere Teil-Bebauungspläne erstellt werden. Bereits im betrachteten Beispiel zeigt sich der Aufwand der Erstellung des IT-

46

Modellierung von IT-Architekturen

Bebauungsplans und der Teil-Bebauungspläne, falls diese nicht aus strukturierten Datenbeständen automatisiert erstellt werden. Nahezu alle Softwarekarten in Unternehmen werden bislang mit den Softwarewerkzeugen Visio oder PowerPoint von Microsoft manuell erstellt [MaWi04, 10]. Hier besteht ein großer Bedarf an Softwareunterstützung. Kapitel 7 stellt ein entsprechendes Werkzeug vor.

3.5

IT-Infrastruktur

Die IT-Infrastruktur umfasst die strukturierte Sammlung aller Technologien eines Unternehmens. Die Bestandteile des hier vorgestellten Modells sind Technologien und Plattformen. Unter dem Begriff Technologie wird in dieser Arbeit eine Soft- oder Hardwarekomponente oder auch eine Programmiersprache, ein Protokoll oder ein Standard verstanden. DERN definiert die IT-Infrastruktur folgendermaßen: Ä$OV,7%DVLVLQIUDVWUXNWXUZLUGGLH0HQJHDOOHU +DUGZDUHXQGDOOHUV\VWHPQDKHQ6RIWZDUHNRPSRQHQWHQYHUVWDQGHQGLHGLH/DXI]HLWXQG 0DQDJHPHQWXPJHEXQJ IU (QWZLFNOXQJ 7HVW XQG 3URGXNWLRQ YRQ ,QIRUPDWLRQVV\VWHPHQ ELOGHQ³ [Dern03, 27]. Plattformen erfüllen Grundfunktionalitäten und sind applikations- und geschäftsprozessübergreifend gestaltet. Plattformen sind als Dienste der Infrastruktur zu verstehen, die allen Applikationen zur Verfügung stehen [KaLR04, 2 f.], z. B. eine Mobile Business Plattform [Kühl05, 18]. BIRKHÖLZER und VAUPEL definieren Plattform als Ä6DPP OXQJYRQJHPHLQVDPHQ(OHPHQWHQXQG.RPSRQHQWHQ³ mit dem Ziel der Wiederverwendung in unterschiedlichen Applikationen [BiVa03, 157]. Plattformen dienen der in Abschnitt 2.4 dargestellten Verschiebung der Entkopplungspunkte zur Komplexitätsreduktion 67. Es handelt sich um eine so genannte auftragsneutrale Vorfertigung (oder Vorkonfiguration) von ITDienstleistungen, die dann in Applikationen zum Einsatz kommen [BöKr05, 457]. Die Technologien werden anhand eines Schichtenmodells 68 in einer zweistufigen Ordnung in Layer und Cluster detailliert. Das Ziel dabei ist eine funktionale Abstraktion von einzelnen Technologien. Abbildung 3-11 zeigt die IT-Infrastruktur mit Plattformen und Technologien und die Strukturierung der Technologien.

67

68

Der Entkopplungspunkt ist die letzte Stelle im Materialfluss, ab der die weiteren Bearbeitungsschritte nur ausgeführt werden, wenn dafür ein Kundenauftrag vorliegt. Im Extremfall der rein kundenorientierten Produktion liegen die Entkopplungspunkte ganz am Anfang, d. h. alle Prozesse werden erst nach der Auftragsannahme durchgeführt, so dass keinerlei Unsicherheit bezüglich des späteren Absatzes besteht. Kundenaufträge sind das auslösende Element und die Prozesse sind rein reaktiv. Für alle Prozesse, deren Entkopplungspunkt später liegt, ist dieser enge Kundenbezug nicht gegeben, so dass Prognosen über die zu erwartenden Aufträge angefertigt werden müssen [Meyr03, 942]. Eine ähnliche Einteilung in Schichten findet sich bei [HeBe02], [FEA03, 15 f.], [Liu02, 16], [MSTI03, 32 und 49] und [CEB01, 14 f.].

Modellierung von IT-Architekturen

47

Technologien Cluster 1

Cluster 2

Cluster n

Plattformen Layer 1 Plattform 1

Layer 2

Plattform 2

Plattform 3 Layer n Plattform n

Abbildung 3-11 Strukturierung der IT-Infrastruktur

Cluster bilden so genannte Funktionalgruppen und fassen Technologien entsprechend ihrer Funktion zusammen. Als logische, abstrakte Komponente [Dern03, 235] kann ein Cluster in Softwarearchitekturen auch als Platzhalter für konkrete Technologien dienen. Alle Technologien und Cluster werden in Layer nach einem abstrahierten ISO/OSI-Modell strukturiert, wobei sich je nach Unternehmen u. U. eine andere Aufteilung ergibt. Ein Layer gliedert Cluster nach ihrer übergeordneten Funktion. LIU strukturiert Technologien in einem so genannten IT infrastructure framework z. B. nach Network environment, Computing environment, Development environment und Business applications als Layer. Innerhalb dieser Layer finden sich zur weiteren Konkretisierung Cluster, z. B. Database servers, Application servers, Integration servers und Common services/middleware im Layer Development environment [Liu02, 16]. Ein Beispiel zeigt Abbildung 3-12.

48

Modellierung von IT-Architekturen

Plattformen

Technologien Applikationsentwicklung

Middleware Komponenten

Modeling / Case Tools

Development

Configuration Management

Design

Testing

Documentation

User Management

Database Middleware

Directory Services

Enterprise Application Integration

Transaction Monitors

ETL (Extraction, Transformation & Loading)

Optimization

Specifications & Languages

Messaging

Object Request Brokers

Datenmanagement

Data Mining

OLAP

DB-Clients

DBMS

Reporting

Database Admin Tools

Internet und Mobile Technologien

Application Servers

Portal Servers

Search Engine

Web Infrastructure

Enterprise Content Management

Remote Access

File Transfer

Web Servers

Global Backbone

WAN

Voice

Border Gateway Networks (Extranet)

LAN

Wireless

Name Services

Server OS

Storage Technologies

Telekommunikation und Netzwerk

Server- und Datenspeicherumgebung Clientspezifikation

Mobile Business

Content Management

E-Business

Customer Relationship Management

Server Hardware

Hardware Desktop

Antivirus

Compression

Hardware Notebook

Browser

Runtime

Project Management Customer Interface

Hardware Tower

Browser Plug-In

Drawing

Office Automation

Client OS

Groupware

E-Mail

Pervasive Computing

Abbildung 3-12 IT-Infrastruktur (Beispiel)

Zur Darstellung des Ist- oder Soll-Zustandes der IT-Infrastruktur werden alle Technologien im Unternehmen Clustern zugeordnet und in diesen dargestellt. Die folgenden beiden Abbildungen zeigen jeweils beispielhaft den Layer Middleware, in Abbildung 3-13 den IstZustand bei einem Automobilhersteller und in Abbildung 3-14 den Ist-Zustand bei einem Unternehmen aus der Energieversorgerbranche.

Abbildung 3-13 IT-Infrastruktur (Beispiel 1 für Layer Middleware)

Modellierung von IT-Architekturen

49

Abbildung 3-14 IT-Infrastruktur (Beispiel 2 für Layer Middleware)

Die Schriftfarbe der einzelnen Technologien weist auf den Status im Lebenszyklus hin (weitere Erläuterungen bietet Kapitel 7, vgl. auch Abschnitt 3.4, S. 42). Die Beispiele verdeutlichen den Vorteil der Strukturierung in Layer und Cluster: unnötige Komplexität kann bereits bei einer Sichtprüfung der IT-Infrastruktur identifiziert werden. In Abbildung 3-13 sind viele Technologien (> 3) in den Clustern Database Middleware, Directory Services und Systems Management aufgelistet. In Abbildung 3-14 zeigt sich eine ähnliche Häufung im Cluster Directory Services. Eine solche Häufung gibt Hinweise auf mögliche Redundanzen, die weiter Untersucht werden sollten. Im ersten Beispiel hat sich nach einer Untersuchung der Häufungen heraus gestellt, dass im Cluster Database Middleware sieben von 13 Technologien kurzfristig abgelöst werden können, im Cluster Directory Services nur zwei der bisher fünf Technologien notwendig sind und im Cluster Systems Management nur die Technologie Tivoli Framework 3.7 notwendig ist, um die geforderten Aufgaben in der Serveradministration zu bearbeiten. Im zweiten Beispiel hat eine Untersuchung ergeben, dass als Directory Service die Single User Management genannte Technologie genügt und alle anderen Technologien kurz- bis mittelfristig abgelöst werden können. Plattformen bieten eine Auswahl an Technologien an, die durch Programmkomponenten erweitert werden können, um so genannte Basisdienste für Applikationen bereit zu stellen. Je mehr Basisdienste in einer Plattform vorhanden sind, umso weiter verschiebt sich der Entkopplungspunkt der einzelnen Applikation, die die Plattform nutzt. Die in Abbildung 3-15 dargestellte E-Business Plattform beinhaltet alle Technologien, die zur Erstellung von EBusiness Applikationen benötigt werden.

50

Modellierung von IT-Architekturen

Plattform: E-Business

Abbildung 3-15 IT-Infrastruktur (Beispiel für Plattform E-Business) 69

Durch einheitliche Datenbanken und Programmiersprachen und eine vorgegebene Softwarearchitektur ermöglicht die Plattform eine einfache Integration von Applikationen und die Nutzung von gemeinsamer Hardware und Lizenzen. Zusätzlich bietet die E-BusinessPlattform eine Single Sign-On 70 Komponente, die eine Verwaltung der Anwender auf Basis des unternehmensweiten Verzeichnisdienstes ermöglicht. Eine weitere Komponente gewährleistet die regelmäßige Sicherung der Datenbestände. Die folgenden Abbildungen demonstrieren die Verschiebung der Entkopplungspunkte ohne und mit Plattformen in der IT-Architektur. Abbildung 3-16 zeigt den typischen Aufbau einer IT-Architektur bestehend aus monolithischen Applikationen.

69 70

Es handelt sich um die E-Business-Plattform eines Automobilherstellers. Single Sign-On (SSO) bedeutet, dass ein Benutzer nach einer einmaligen Authentifizierung auf alle Applikationen, für die er berechtigt ist, zugreifen kann, ohne sich jedes Mal neu anmelden zu müssen.

Modellierung von IT-Architekturen

51

Abbildung 3-16 Typische IT-Architektur mit monolithischen Applikationen 71

Die Applikationen 1, 2 und 3 könnten z. B. die Geschäftsprozesse Customer Relationship Management (CRM), Enterprise Resource Management (ERM) und Supply Chain Management (SCM) unterstützen. Die Applikationen sind dreischichtig konstruiert, wobei die Datenhaltung in einer oder mehreren Datenbanken zumeist auf einem zentralen Server erfolgt. Die Applikationslogik und die Benutzerschnittstelle sind je nach Softwarearchitektur entweder auf dem Arbeitsplatzrechner des Anwenders abgelegt oder auf einem zentralen Server, auf den mit einem Internetbrowser oder einem Terminal zugegriffen wird. Abbildung 3-17 zeigt die Situation unter Nutzung einer Plattform.

71

Verändert übernommen aus [Wood04, 33].

52

Modellierung von IT-Architekturen

Applikation 1

Applikation 2

Applikation 3

Benutzerschnittstelle

Benutzerschnittstelle

Benutzerschnittstelle

Portal

Plattformbestandteile

Applikationslogik

Gemeinsame Applikationslogik wie Single Sign-On, Authentifizierung und Autorisierung, Anwenderverwaltung, Verschlüsselung etc. Gemeinsame Technologien wie Applikationsserver, Konfigurationsmanagement, Entwicklungs- und Testumgebung etc.

Gemeinsam genutzte Datenbanksysteme

Abbildung 3-17 IT-Architektur mit Plattformen

Alle verwendeten Datenbanken basieren nun auf der gleichen Technologie und/ oder nutzen gemeinsame Ressourcen (Server). Alle Applikationen sind serverbasiert und verwenden den gleichen Applikationsserver, das gleiche Konfigurationsmanagement und die gleiche Entwicklungs- und Testumgebung. Der Loginvorgang, die Benutzerverwaltung und die Verschlüsselung der Daten sind ebenfalls zentrale Komponenten, die alle Applikationen nutzen und die Benutzeroberfläche wird einheitlich im browserbasierten Unternehmensportal abgebildet. Um die spezifischen Funktionalitäten der einzelnen Applikation zu erzielen ist folglich ein wesentlich geringerer Programmieraufwand notwendig und eine mögliche Integration der Applikationen wird vereinfacht. Die Nutzung von Plattformen in der IT-Architektur kann mit einer Entwicklung in der Automobilindustrie in den 1990er Jahren verglichen werden, dem sogenannten Lean Manufacturing [WoJR90]. Seither versuchen Automobilhersteller, auf Basis von einigen wenigen Plattformen und standardisierten Komponenten und Modulen die immer differenzierteren Kundenwünsche mit einer breiten Produktpalette zu bedienen, ohne dabei die Komplexität in der Produktion zu erhöhen [Wood04, 18]. Der Entkopplungspunkt in eine Modellreihe hinein wird so spät wie möglich angesetzt. So diente im Jahr 2004 etwa die Plattform PQ35 im Volkswagen-Konzern als Basis für die Modelle Audi A3, Seat Altea, VW Bora, VW Caddy Van, VW Golf, VW Golf Plus, VW Golf SUV, VW Jetta, Seat Leon, Skoda Octavia, Seat Toledo, VW Touran und Audi TT [AuPr04, 13]. Im DaimlerChrysler Konzern werden im Modell Chrysler 300C Fahrwerkteile, Getriebe und Dieselmotoren von Mercedes verwendet, die auch in der E-Klasse zum Einsatz kommen, der Chrysler Crossfire basiert zu großen Teilen auf dem Mercedes SLK [Koch06, 76].

Modellierung von IT-Architekturen

3.6

53

Übergreifendes Modell

Die in den Abschnitten 3.4 und 3.5 dargestellten Bestandteile des Modells der IT-Architektur zeigt Abbildung 3-18 als Entity-Relationship-Diagramm.

Sparte

Prozess

m

m

unterstützt

n

Applikation

n

unterstützt

n

gehört zu

n

verwendet

verwendet

m

m

n

Technologie

n

gehört zu

n

gehört zu

m

Plattform

1

Cluster

1

Layer

Abbildung 3-18 Modell der IT-Architektur als Entity-Relationship-Diagramm

Der zentrale Bestandteil im IT-Bebauungsplan ist die Applikation und in der IT-Infrastruktur die Technologie. Die Schnittstellen zwischen den Modellen sind zum einen Applikation zu Technologie und zum zweiten Applikation zu Plattform. Eine Applikation kann mehrere Plattformen nutzen (z. B. die E-Business Plattform und die Collaboration Plattform aus Abbildung 3-12). Kapitel 7 detailliert das Modell.

3.7

IT-Architektur-Management

Eine dynamische Sichtweise des IT-Architektur-Managements ergänzt im Folgenden die ITArchitektur-Modelle. Dazu werden Prozesse des IT-Architektur-Managements und die Entwicklung der IT-Architektur im Zeitverlauf beschrieben. Jede Organisation verfügt über eine IT-Architektur, die in ihrer Gesamtheit sowie in Teilen gewachsen oder geplant bzw. implizit oder explizit vorhanden ist [BiVa03, 29; McNu88 zitiert nach Krcm90, 397; Sinz04, 315]. Ein geplantes Vorgehen und eine aktive Gestaltung erfolgt im Rahmen des IT-Architektur-Managements. Dies umfasst die notwendigen Modelle [Sinz04, 315], Prozesse, Rollen sowie Organisationsstrukturen und die strategische Aus-

54

Modellierung von IT-Architekturen

richtung, um die IT-Architektur zu gestalten [Werr02, 8]. Das IT-Architektur-Management zielt auf die Erstellung [Foeg03, 63], Verwaltung, Optimierung und systematische und nachhaltige Weiterentwicklung [HaSW04, 61] der IT-Architektur ab. Dabei entstehen normative IT-Architekturen (so genannte Reißbrett-Architekturen), die einen Soll-Zustand beschreiben [Sinz04, 316]. Das IT-Architektur-Management steht im Spannungsfeld Ä]ZLVFKHQ GHQ VWUDWHJLVFKHQ =LHOHQ GHQ IDFKOLFKHQ $QIRUGHUXQJHQ GHQ WHFKQRORJLVFKHQ 5DKPHQEHGLQ JXQJHQXQGGHULQ)RUPYRQ3URMHNWHQUHDOLVLHUWHQ:HLWHUHQWZLFNOXQJGHU'96\VWHPHXQG 8QWHUQHKPHQVVWUXNWXUHQ³ [Foeg03, 64]. Die IT-Architektur-Modelle werden durch Vorgehensmodelle zur Gestaltung der ITArchitektur ergänzt [Pohl00, 11]. POHLAND beschreibt und bewertet Konzepte zur ISPlanung, die über mehrere Ebenen (Prozess-, Applikations- und Technologiearchitektur) eine Architektur aufbauen [Pohl00, 55 - 76]. Insbesondere sind die Strategische Informationsplanung, das Business Systems Planning, Information Systems Study und das St. Gallener Informations-Management zu erwähnen. Es ist zu unterscheiden zwischen der Planung der Geschäftsprozesse und der unterstützenden Applikationen, auch wenn sich mittlerweile mehr als drei Viertel der IT-Entscheider in deutschen Konzernen vorrangig als Prozessoptimierer verstehen [Reit05]. Grundlegend ist die Definition der IT-ArchitekturManagement-Prozesse und einer IT-Architektur-Strategie. 3.7.1

IT-Architektur-Management-Prozesse

HAFNER und WINTER untersuchen evolutionäre Vorgehensmodelle zur IT-Architektur (Enterprise Architecture Management von IBM [Werr02], IT-Architektur-Management nach DERN [Dern03], IT-Architektur-Engineering nach KRÜGER und SEELMANN-EGGEBERT [KrSe03] 72) und leiten aus der Praxis anhand der Synthese von Fallstudien ein Vorgehensmodell für das Management der Applikationsarchitektur 73 ab [HaWi05, 636]. Darauf aufbauend können IT-Architektur-Management-Prozesse definiert werden, die zumindest in Teilen auch bei [Jung04, 313; Foeg03, 64; Nunn03, 17; Jame02, 2 f.; Diet02, 15 - 17 und Wint04, 4] postuliert werden (vgl. Abbildung 3-19).

72

73

Es fehlt z. B. TOGAF (The Open Group Architecture Framework), das weit verbreitete und frei verfügbare Vorgehensmodell der Open Group [Open05]. Entspricht dem in vorliegender Arbeit verwendeten ,7%HEDXXQJVSODQ.

Modellierung von IT-Architekturen

55

Strategieanforderungen identifizieren

Weitere Anforderungen identifizieren

Architekturzielgruppen identifizieren

Aktuelle Architekturen beurteilen

Anforderungen verwalten

Architekturartefakte kommunizieren

Architekturprinzipien aktualisieren

Architekturartefakte pilotieren

Architekturverbreitung und -effektivität messen

Architekturartefakte (AA) entwickeln

Architektur-Führung

Architekturartefakte integrieren ArchitekturEntwicklung

ArchitekturKommunikation

ArchitekturzielgruppenProjekte unterstützen AA-Implementierungen bereitstellen ArchitekturzielgruppenProjekte beurteilen ArchitekturVertretung

Abbildung 3-19 Vorgehensmodell des IT-Architektur-Managements 74

Die so genannten Architekturartefakte (AA) bezeichnen Modelle wie den IT-Bebauungsplan oder die IT-Infrastruktur. Die IT-Architektur-Strategie wird in enger Abstimmung mit den Anforderungen der ITStrategie erarbeitet [BiVa03, 149]. Kapitel 4 zeigt das Vorgehen dazu auf. Zur Beurteilung der Ist-Architektur wird deren Effektivität und Effizienz gemessen. Kapitel 6 stellt einen Ansatz dazu vor. Im Schritt Architekturprinzipien aktualisieren werden die Vorgaben aus der IT-Architektur-Strategie mit den Maßnahmen, die aus der Beurteilung der Ist-Architektur abgeleitet wurden, abgeglichen. Die Verwaltung der Anforderungen stellt sicher, dass alle Anforderungen an die IT-Architektur laufend aktuell an zentraler Stelle im Unternehmen vorliegen. Bei der Pilotierung, Entwicklung und Integration der Architekturartefakte werden die Modelle IT-Infrastruktur und IT-Bebauungplan schrittweise erstellt. Nach Festlegen der gewünschten Struktur (Zahl und Bezeichnung der Layer, Identifikation der Cluster, gewünschte Modellierungstiefe im Bebauungsplan) wird sukzessive die Soll-IT-Architektur entwickelt. Die Kommunikation der Modelle verankert die IT-Architektur in der Organisation und veranlasst z. B. Schulungen und Workshops für die betroffenen Zielgruppen 75 [Broa05; MASL04, 48] oder arbeitet mit einem sogenannten IT-Architektur-Portal [Jung04, 314], wie

74 75

Übernommen aus [HaWi05, 643]. Zielgruppen der IT-Architektur sind z. B. Softwareentwickler, Applikationsverantwortliche in Geschäftsbereichen, Softwarezulieferer usw.

56

Modellierung von IT-Architekturen

es in Kapitel 7 vorgestellt wird. Auch der Wertbeitrag der IT-Architektur muss kommuniziert werden, damit diese angenommen wird. In der nächsten Phase wird die IT-Architektur durch die Unterstützung und Überwachung von IT-Projekten umgesetzt. Die Überwachung von IT-Projekten dient zur Kontrolle und Beobachtung von Abweichungen von den IT-Architektur-Vorgaben [Jame02, 2]. Kapitel 5 stellt einen Ansatz zur Überwachung der Konformität von IT-Projekten zur IT-Architektur vor. Durch die permanente Überarbeitung der IT-Architektur und die Rückkopplung zur ITArchitektur-Strategie und IT-Architektur-Entwicklung aus den Projekten wird eine kontinuierliche Weiterentwicklung der Architektur erreicht [Nunn03, 17]. Die Bereitstellung von Plattformen (AA-Implementierungen bereitstellen) ermöglicht Kosten- und Zeiteinsparungen in Softwareprojekten und liefert so einen weiteren Beweggrund zur Einhaltung der Vorgaben der IT-Architektur in IT-Projekten. 3.7.2

IT-Architektur im Zeitverlauf

Die IT-Architektur dient als Basis für die zukünftige Ausgestaltung und Weiterentwicklung der gesamten Informationstechnologie eines Unternehmens [MaSc03, 240]. FORRESTER RESEARCH nennt drei Ansätze bei der IT-Architektur-Modellierung [Peyr04, 5 f.]: Der Topdown-Ansatz wird v. a. in der Planung verwendet und stellt ausgehend von den Anforderungen der Geschäftsprozesse sowie der IT-Strategie eine Soll-Architektur auf [HaWi05, 632]. Beim Bottom-up-Ansatz wird der aktuelle Zustand der IT möglichst genau modelliert, um die Auswirkungen von Änderungen an einzelnen Bestandteilen nachvollziehen zu können. Das Änderungsmanagement verknüpft beide Sichten und verbindet durch das Einbringen einer Zeitdimension über IT-Projekte das Top-down-Bild der IT-Architektur mit dem Ist-Zustand. In der IT-Architektur-Strategie wird entsprechend die Soll-ITArchitektur beschrieben und angegeben, wie diese ausgehend von der Ist-IT-Architektur erreicht werden kann [Boll04; CIOC01, 5]. Ein Migrationsplan gibt die dazu notwendigen Schritte vor [CIOC01, 5].

Kapitel 4 Strategiekonforme IT-Projekte 4 Strategiekonforme IT-Projekte 4.1

Übersicht

Dieses Kapitel beschreibt nach der Ausgangssituation (Abschnitt 4.2) die Ableitung von ITStrategieobjekten (Abschnitt 4.3) zur Messung der Strategiekonformität von IT-Projekten (Abschnitt 4.4). Abschnitt 4.5 zeigt den Ablauf der Messung der Strategiekonformität von ITProjekten im Unternehmen. Praxisbeispiele verdeutlichen die Methodik. Abbildung 4-1 zeigt die Einordnung in das Vorgehensmodell. Strategiekonforme ITInvestitionen

IT-Strategie

4

strategische Sicht

IT-Projekte

Architekturkonforme ITProjekte

architektonische Sicht IT-Architektur

Modellierung von ITArchitekturen

3 5 Applikationen 7

Wertbeitrag von ITArchitektur-Management

6

Bewertung/ Steuerung

Abbildung 4-1

Einordnung von Kapitel 4

Technologien

Softwareunterstützung des Managements von ITArchitekturen

Darstellung

58

Strategiekonforme IT-Projekte

4.2

Ausgangssituation

Die IT-Geschäftsbereiche entwickeln in IT-Projekten zusammen mit Geschäfts- und Prozessverantwortlichen neue Applikationen. In einer Studie im Frühjahr 2004 befragte die Unternehmensberatung BEARINGPOINT Führungskräfte im deutschsprachigen Raum u. a. mit dem Ergebnis, dass bei der Definition von IT-Projekten der IT-Bereich mit 53 Prozent und die Geschäftsbereiche mit 34 Prozent beteiligt sind [KrZi04, 5]. Dabei haben der CIO 76 als Leiter der zentralen IT-Abteilung und die IT-Abteilungen der Geschäftsbereiche eine unterschiedliche Sichtweise auf die IT im Unternehmen (vgl. Abbildung 4-2). Strategisch

Operativ

ƒ Gesamtunternehmensfokus ƒ Langfristig ƒ Prozessunabhängig ƒ Geschäftsbereichsunabhängig ƒ Standardfixiert

CIO CIO

ƒ Bereichsfokus ƒ Kurz- bis mittelfristig ƒ Direkter Prozessbezug ƒ Geschäftsbereichsspezifisch ƒ Projektfixiert

Zentrale ITAbteilung

IT-Abteilung Geschäftsbereich

IT Strategie

Strategie ITITStrategie SW-Projekte IT-Projekte

Abbildung 4-2

Unterschiedliche Zielsysteme im IT-Bereich 77

Die zentrale IT-Abteilung betrachtet das gesamte Unternehmen und legt unabhängig von den Anforderungen der einzelnen Geschäftsbereiche in den verschiedenen Projekten eine langfristige, strategische Stoßrichtung fest. Sie bleibt dabei fachunabhängig und definiert Standards für die Applikationen und die Prozesse des IT-Bereichs. Der Geschäftsbereich nimmt eine kurz- bis mittelfristige, operative Sichtweise ein, die auf den vom IT-Projekt betroffenen Bereich fokussiert ist. Ziel des Geschäftsbereichs dabei ist es, eine optimale *HVFKlIWVSUR]HVVXQWHUVWW]XQJ ]X HU]LHOHQ ± EHUJHRUGQHWH ,7EHUHLFKVLQWHUQH =LHOH ZLH die Standardisierung von Technologien spielen dabei keine Rolle. Tatsächlich führt die unterschiedliche Sichtweise von CIO und Geschäftsbereichen dazu, dass die definierte ITStrategie in den IT-Projekten oft nicht eingehalten wird. Unterbleibt eine Auswirkungsanaly-

76

77

CIO steht für Chief Information Officer oder Chief Information Office. Letzteres bezeichnet den Bereichsleiter des IT-Bereichs und den dazugehörigen Mitarbeiterstab. Verändert übernommen aus [BoDu06, 1415].

Strategiekonforme IT-Projekte

59

se von IT-Projekten z. B. auf die IT-Architektur im Unternehmen, dann besteht die Gefahr, dass ein IT-Projekt die IT-Strategie unterläuft [MaSc03, 263 f.]. Aus Sicht des CIO genügt es deshalb nicht, die IT-Strategie nur zu definieren, sondern es muss auch deren Umsetzung in den einzelnen Projekten sichergestellt werden [BoDu06, 1415].

4.3

IT-Strategieobjekte

Ä'DV $EOHLWHQ YRQ 7HLOVWUDWHJLHQ LVW HUIRUGHUOLFK ZHQQ GLH $XVVDJHQ GHU ,96WUDWHJLH ]X JURE VLQG XP GLH VWUDWHJLVFKH 0D‰QDKPHQSODQXQJ VWHXHUQ ]X N|QQHQ >«@³ [Hein99, 1124 f.]. Die IT-Strategie wird dazu in mehrere strategische Aspekte unterteilt, für die einzelne Strategien zu entwerfen sind, die wiederum aufeinander abgestimmt werden müssen [Horv03, 724; HoRi01, 13]. Man spricht von Strategieobjekten [HePooJ, 8] bzw. Planungsobjekten [Horv03, 722]. Von den strategischen Zielen ausgehend werden auf hierarchisch untergeordneten Planungsstufen, d. h. den Strategieobjekten, Teilziele identifiziert [Horv03, 205]. Strategische Ziele werden entweder direkt einem konkreten Strategieobjekt zugeordnet oder es werden jeweils Ziele für mehrere Strategieobjekte abgeleitet. Ein hierarchisches Zielsystem mit zwei Ebenen entsteht. Zur Erfüllung der übergeordneten strategischen Ziele müssen die Ziele der Strategieobjekte erreicht werden (vgl. Abbildung 4-3).

Strategische Ziele

IT-Leitlinien

Ableiten von

Strategieobjekt 1

Strategieobjekt 2

Strategieobjekt n

Teilziele

Teilziele

Teilziele

Abbildung 4-3

Ableiten von Strategieobjekten

In der Literatur finden sich viele Beispiele für eine Untergliederung der IT-Strategie in mehrere Objekte. GARTNER benennt fünf grundsätzliche Strategieobjekte einer IT-Strategie: Infrastruktur, Service, Applikationen, Integration und das Sourcing von Personal [Mack03, 8]. Im Informationsmanagement (IM) nach dem Zürcher Ansatz [Rühl96, 32] wird dagegen zwischen IS-Strategie (Informationssystem), IT-Strategie (Informationstechnologie) und IM-Strategie (Informationsmanagement) unterschieden. Die IS-Strategie stellt sicher, dass die Unternehmensaktivitäten von geeigneten Informationssystemen unterstützt werden, während sich die IT-Strategie auf die dazu notwendige Technologie konzentriert. Die IM-Strategie liefert hierzu das Führungskonzept. HEINRICH baut die Objektstruktur der

60

Strategiekonforme IT-Projekte

IT-Strategie anhand der Managementbereiche Investitionen, Architektur, Plattformen und Systeme, Entwicklung und Beschaffung, Personal, Integration, Qualität, Technologien, Controlling, Projekte, Daten, Produktion und Problemmanagement sowie Sicherheits- und Katastrophenmanagement auf [Hein99, 1123]. MAICHER/SCHWARZE benennen das Anwendungsportfolio und die Softwarestrategie, die IT-Infrastruktur sowie das Management und die Organisation der Informatik als Kategorien für strategische Themen [MaSc03, 234 f.]. Grundsätzlich ist davon auszugehen, dass es bei der Vielzahl an theoretischen Konzepten zur IT-Strategie und dem IT-Management auch in verschiedenen Unternehmen unterschiedliche Sichtweisen zur IT-Strategie gibt, insbesondere was strategische Ziele und die Aufteilung in Strategieobjekte betrifft. So beschreibt WEILL z. B. drei völlig verschiedene strategische Ausrichtungen für die IT (Operational Excellence, Customer Intimacy, Product or Service Leadership) [WeRo04, 158 - 170], für die wiederum unterschiedliche Ziele zur Umsetzung definiert werden können 78. Abbildung 4-4 zeigt einen eigenen Vorschlag zur Strukturierung der Handlungsfelder in der IT-Strategie in Strategieobjekte. Dabei sind die oben genannten Ansätze eingeflossen, um ein möglichst umfassendes Portfolio an Strategieobjekten zu ermöglichen. Strategische Ziele

IT-Management

Personal

Sourcing

Infrastruktur

Softwareentwicklung

Service

Betrieb

Finanzierung

Applikationen

Innovation

Strategieobjekte

IT-Architektur

Organisationsarchitektur

Abbildung 4-4

Strategieobjekte einer IT-Strategie 79

In jedem Strategieobjekt ist in Teilzielen der Soll-Zustand festgelegt. So könnte z. B. im Strategieobjekt Personal HLQ 7HLO]LHO Ä=HUWLIL]LHUXQJ YRQ 3UR]HQW DOOHU 3URMHNWOHLWHU ]XP Certified Associate in Project ManagementELV]XP³ODXWHQ

78 79

Eine Beschreibung von IT-Strategien findet sich auch bei [Krcm05, 293 f.]. Verändert übernommen aus [DuGa06, 70].

Strategiekonforme IT-Projekte

4.4

61

Evaluation der Strategiekonformität von IT-Projekten

Im Folgenden wird ein Ansatz zur kennzahlenbasierten Evaluation der Strategiekonformität von IT-Projekten vorgestellt, der die Beziehung zwischen den Objekten der IT-Strategie und einem IT-Projekt untersucht. 4.4.1

Voraussetzungen

Voraussetzung für die Evaluation ist die Existenz der Vergleichsobjekte IT-Projekt und ITStrategieobjekt. So müssen zum einen Informationen zu einem IT-Projekt, das bewertet werden soll, vorliegen. Zum anderen wird vorausgesetzt, dass es überhaupt eine ITStrategie, also eine Beschreibung wie die IT aussehen soll und wie dieser Soll-Zustand zu erreichen ist, im Unternehmen gibt. Im Rahmen des strategischen Planungsprozesses werden dazu IT-Leitlinien und strategische Ziele für die IT vom Management festgelegt und dokumentiert. Das Management strukturiert die Strategie anhand von Strategieobjekten. Managementkonzepte und -methoden hängen vom jeweiligen Unternehmen ab. Eine wesentliche Anforderung an die Evaluationsmethode ist deshalb, eine hohe Adaptivität an die Gegebenheiten im jeweiligen Unternehmen zu gewährleisten. Es können also keine strategieobjektgebundenen Kennzahlen vergeben werden, sondern diese sind ausgehend von den strategischen Zielen zu entwickeln. Andererseits sollen diese möglichst unverändert für die Bewertung mehrerer IT-Projekte herangezogen werden können. 4.4.2

Aufbau der Evaluation

Ziel der Bewertung ist die Bestimmung einer Spitzenkennzahl (Strategic Fit Index), welche die Konformität eines Projekts p zu der unternehmensspezifischen IT-Strategie in Prozent ausdrückt (SFIp). Zur Bestimmung des SFI wird eine Konformitätskennzahl separat für jedes Strategieobjekt der IT-Strategie ermittelt. Über eine relative Gewichtung der Strategieobjekte wird der SFI als Gesamtfit des IT-Projekts gegenüber der IT-Strategie errechnet. Bei einem Wert von 100 Prozent ist ein IT-Projekt vollständig konform, bei 0 Prozent nicht konform zur IT-Strategie. Um die Konformität des IT-Projekts zu den Strategieobjekten zu ermitteln, werden Evaluationselemente eingeführt. Für jedes Strategieobjekt werden ein oder mehrere Evaluationselemente festgelegt, über die ein IT-Projekt letztendlich bewertet wird (vgl. Abbildung 4-5).

62

Strategiekonforme IT-Projekte

SFI [%]

Gewichtung

Gewichtung

Gewichtung

Strategieobjekt 1

Strategieobjekt 2

Strategieobjekt n

Konformität [%]

Konformität [%]

Konformität [%]

Gewichtung

Gewichtung

Gewichtung

Evaluationselement 2.1

Evaluationselement 2.2

Evaluationselement 2.m

Konformität [%]

Konformität [%]

Konformität [%]

ITProjekt p n: Anzahl der Strategieobjekte m: Anzahl der Evaluationselemente für das Strategieobjekt 2

Abbildung 4-5

4.4.3

Hierarchischer Aufbau der Evaluation

Herleitung der Evaluationselemente

Die Konformität eines IT-Projekts gegenüber den einzelnen Strategieobjekten wird anhand des Beitrags zur Erfüllung der jeweiligen Ziele des Objekts ermittelt. Je besser ein ITProjekt die Ziele eines Strategieobjekts erfüllt, d. h. zu ihrer Umsetzung beiträgt, desto höher ist seine Konformität zum Strategieobjekt. Die Ziele eines Strategieobjekts werden in so genannte Evaluationselemente gegliedert, um eine Messung der Konformität vornehmen zu können. Abbildung 4-6 visualisiert die Ermittlung dieser Evaluationselemente für ein Strategieobjekt. Jedes Einzelziel eines Strategieobjekts wird isoliert betrachtet und danach beurteilt, ob ein IT-Projekt direkt nach der Erfüllung des Ziels bewertet werden kann. Ist dies der Fall, wird das Ziel der Menge der Evaluationselemente hinzugefügt. Stellt sich heraus, dass aufgrund des Charakters eines Ziels noch keine Aussage darüber getroffen werden kann, ob ein IT-Projekt zur Zielerfüllung beiträgt, wird dieses Ziel in Unterzielen verfeinert und konkretisiert.

Strategiekonforme IT-Projekte

63

Menge der Ziele eines Strategieobjekts

Menge der Evaluationselemente eines Strategieobjekts Für die Evaluation

Ziel entnehmen

geeignet

Ziel hinzufügen

nicht geeignet irrelevant

Unterziele hinzufügen

Abbildung 4-6 Konzept der Ermittlung von Evaluationselementen

Die generierten Unterziele werden dann der Menge der Ziele hinzugefügt und später geprüft. Wird das Ziel als irrelevant für die Messung eingeschätzt, wird es nicht in die Menge der Evaluationselemente aufgenommen bzw. nicht detailliert. Dies wird für jedes Strategieobjekt der IT-Strategie durchgeführt. Auf Ebene der strategischen Ziele für die gesamte IT eines Unternehmens ist die Beurteilung der Konformität eines IT-Projekts kaum möglich, da ein Bezug zwischen Projekt und Ziel nur selten direkt hergestellt werden kann (vgl. Abbildung 4-7). Planungsebene

Beispiel

Strategische Ziele

IT-Projekt

Reduzierung der Komplexität in der IT

Ziel

Konsolidierung der Infrastruktur

Konkretisierung

Einhaltung von technologischen Standards

Projekt

Strategieobjekt IT-Architektur

Abbildung 4-7

Evaluation auf verschiedenen Planungsebenen

Die grauen Pfeile deuten an, dass ein Abgleich zwischen IT-Projekt und Strategieobjekt nicht stringent möglich ist. Der Beitrag eines IT-Projekts zum strategischen Ziel Reduzierung der Komplexität in der IT kann nicht unmittelbar festgestellt werden. Für das Strategieobjekt IT-Architektur wird z. B. das Ziel Konsolidierung der Infrastruktur abgeleitet, wodurch die Komplexität der IT verringert wird. Im Beispiel ist eine weitere Konkretisierung des Ziels Reduzierung der Komplexität in der IT notwendig, erst die Einhaltung von technologischen Standards als präzises Ziel ist ausreichend, um ein IT-Projekt zu evaluieren. Zur Überprüfung der Einhaltung von technologischen Standards dient das Modell der IT-Infrastruktur. Anhand der Erfüllung dieses letzten Unterziels kann ein IT-Projekt nun konkret beurteilt ZHUGHQÄ+lOWHVGLH6WDQGDUGVHLQ"³ LQGHPGLHLQGHU,7$UFKLWHNWXUGHILQLHUWHQ6WDQGDUGV mit den im IT-Projekt verwendeten Technologien verglichen werden (vgl. Kapitel 5 zur detaillierten Vorgehensweise). Dieses Ziel dient dann als Evaluationselement.

64

Strategiekonforme IT-Projekte

Die Konkretisierung verschiedener Ziele führt unter Umständen zu den gleichen abgeleiteten Zielen, die entsprechend nur einmal in der Menge der Ziele bzw. der Evaluationselemente betrachtet werden müssen. Das Ableiten von Unterzielen kann mehrstufig erfolgen, bis eine ausreichende Detaillierung erreicht ist. Die Unterziele werden der Menge der Ziele eines Strategieobjekts hinzugefügt, ohne dabei eine Zielhierarchie vorzugeben. Alle Ziele eines Strategieobjekts werden auf einer Ebene betrachtet. 4.4.4

Beschreibung der Evaluationselemente

Auf Ebene der Evaluationselemente wird die Konformität des IT-Projekts zur IT-Strategie gemessen. Zur Aggregation der Konformitäten hin zur Spitzenkennzahl Strategic Fit Index ist eine einheitliche Metrik erforderlich. Abbildung 4-8 zeigt einen Vorschlag zur Standardisierung. Vollständig konform Überwiegend konform Skala

Teilweise konform In Ansätzen konform Nicht konform

Gewichtung

Element

Treiber

G

0

25

50

75

100

i.1 i.2 « i.m Abbildung 4-8

Standardisierte Bewertung der Evaluationselemente 80

Die Evaluationselemente eines Strategieobjekts werden in der Tabelle in der ersten Spalte erfasst. Für jedes Element wird ein Treiber identifiziert, der in der zweiten Spalte eingetragen wird. Der Treiber ist eine Umformulierung des Evaluationselements in eine Frage. Für das Ziel Einhaltung von technologischen Standards wird die Frage Hält das IT-Projekt die Standards ein? zum Treiber. Für das Ziel Technologisches Risiko reduzieren wäre ein Beispiel für den Treiber Wurden die im Projekt eingesetzten Technologien bereits in anderen Projekten erfolgreich implementiert? Die dritte Spalte enthält eine Gewichtung der Evaluationselemente. Diese kann prozentual erfolgen. Die Bewertung erfolgt durch fünf Felder, denen jeweils eine Aussage zuge80

i = Index des betrachteten Strategieobjekts und m = Anzahl der Evaluationselemente des Strategieobjekts.

Strategiekonforme IT-Projekte

65

ordnet ist, etwa nicht konform oder vollständig konform. Die Beschreibungen der Felder werden an den jeweiligen Treiber angepasst. Auf das obige Beispiel (Ziel: Technologisches Risiko reduzieren, Treiber: Wurden die im Projekt eingesetzten Technologien bereits in anderen Projekten erfolgreich implementiert?) bezogen könnte die Beschreibung der Skalenwerte wie folgt lauten: Technologie wurde noch nie getestet, Technologie wurde im Labor getestet, Technologie wurde in einem Pilotprojekt eingesetzt und Technologie wurde schon oft eingesetzt. Die Beurteilung des IT-Projekts erfolgt durch Ankreuzen des Feldes, dessen Aussage am ehesten auf den Treiber zutrifft. Für manche Elemente ist die Konformität nicht graduell bewertbar, sondern das Projekt ist konform oder nicht. Entsprechend wird die Skala für diese Elemente auf die beiden Werte 0 und 100 Prozent reduziert. Nach KRCMAR werden ÄGLH5DKPHQDXVVDJHQIUGDV,0>«@HLQHUVHLWVYRP8QWHUQHK mensleitbild und den Bereichsleitbildern abgeleitet, andererseits aber werden diese auch ZLHGHUYRQGHUNRQNUHWHQ*HVWDOWXQJGHV,0EHHLQIOXVVW³ [Krcm05, 292]. Dieser Gedankengang lässt sich auf die Ebene der Strategieobjekte übertragen. Die Ziele eines Strategieobjekts hängen auch von der konkreten Gestaltung des Bereichs ab, auf den diese sich beziehen. Konkrete Gestaltung meint dabei Prinzipien, Methoden, Zustände usw., die für das Management des Bereichs entscheidend sind. Über den Bezug zu den Managementinstrumenten werden die Strategieobjekte detailliert [MaSc03, 235]. Die Ziele für die ITArchitektur orientieren sich z. B. an einem möglichen Soll-Zustand der IT-Architektur und an den verwendeten Methoden für das Management der IT-Architektur. Im Beispiel mit dem Ziel Einhaltung von technologischen Standards nutzt das betrachtete Unternehmen das Modell der IT-Infrastruktur als Methode, um die Technologiearchitektur zu steuern (vgl. Abbildung 4-9).

66

Strategiekonforme IT-Projekte

Strategieobjekt IT-Architektur

Konformität

Ziel

Treiber

Einhaltung von technolog. Standards

G

Hält das Projekt die Standards ein?

0

25

50

75

100

50

« Cluster

Layer Applikationsentwicklung

Middleware Komponenten

Datenmanagement

Internet und mobile Technologien

Telekommunikation und Netzwerk

Server- und Datenspeicherumgebung Clientspezifikation

Abbildung 4-9

Modeling / Case Tools

Development

Optimization

Specifications & Languages

Configuration Management

Design

Testing

Documentation

User Management

Database Middleware

Directory Services

Enterprise Application Integration

Messaging

Object request brokers

Transaction Monitors

ETL (Extraction, Transformation & Loading)

Data Mining

OLAP

DB-Clients

DBMS

Reporting

Database Admin Tools

Application Servers

Portal Servers

Search Engine

Web Infrastructure

Enterprise Content Management

Remote Access

File Transfer

Web Servers Border Gateway Networks (Extranet)

Fit

Fit

Fit

Fit

Global Backbone

WAN

Voice

LAN

Wireless

Name Services

Server OS

Storage Technologies

IT-Projekt

Fit

Fit Server Hardware

Hardware Desktop

Antivirus

Compression

Project Management

Hardware Notebook

Browser

Customer Interface

Office Automation

Hardware Tower

Browser Plug-In

Drawing

Runtime

Client OS

Groupware

E-Mail

Pervasive Computing

Fit

Detaillierung der Zielevaluation

Diese Methode bildet einen Teil der konkreten Gestaltung des Strategieobjekts ITArchitektur. Im Beispiel wird für jeden Layer geprüft, ob das IT-Projekt die vorgegebenen Standards einhält. Aus dieser Einschätzung wird der Wert für die Konformität zum übergeordneten Ziel ermittelt. 4.4.5

Festlegen der Gewichtung

Die Elemente einer Ebene im Bewertungsbaum (Strategieobjekte, Evaluationselemente) sind wie Abbildung 4-5 zeigt zu gewichten, um eine rechnerische Verdichtung zur übergeordneten Kennzahl hin zu ermöglichen. Der Analytical Hierarchy Process (AHP) ist eine verbreitete Methode, mit der Gewichte für mehrere Kriterien einer Analyse erzeugt werden können. Hier werden n Strategieobjekte (SO) der IT paarweise miteinander verglichen, um die relative Wichtigkeit zweier Strategieobjekte zu ermitteln. Zur Beurteilung dient eine 3UlIHUHQ]VNDOD PLW QHXQ 6WXIHQ ZREHL PLW ij 62i und SOj JOHLFKZHUWLJ XQG PLW ij 62i außerordentlich wichtiger als SOj eingestuft wird. Wenn SOj wichtiger als SOi ist, werden QHJDWLYH :HUWH HLQJHVHW]W %HL Q 6WUDWHJLHREMHNWHQ VLQG òQQ  9HUJOHLFKH QRWZHQGLJ deren Ergebnisse in eine Matrix eingetragen werden (Strategieobjekt x Strategieobjekt). Die

Strategiekonforme IT-Projekte

67

nachfolgende exakte Berechnung der Gewichte ist komplex (siehe z. B. [LaHä03]) und kann mit einem einfacheren Verfahren umgangen werden. Dazu werden für jede Zeile der Matrix das geometrische Mittel 81 berechnet und alle berechneten Mittelwerte summiert. Die Division des geometrischen Mittels jeder Zeile durch die Summe (Normalisierung) ergibt die Gewichte für jede Zeile, also für die Strategieobjekte. Alternativ eignet sich die Delphi-Methode, bei der Fachleute in mehreren Runden die Gewichtung vornehmen und ab der zweiten Runde die anonymisierten Einschätzungen ihrer Kollegen in ihre Überlegungen einbeziehen. Um die finale Gewichtung zu erhalten, werden entweder die Einzelergebnisse gemittelt oder die Anonymität in einer Gruppendiskussion aufgelöst. 4.4.6

Berechnen des Strategic Fit Index

Für ein Strategieobjekt SOi berechnet sich der Fit aus den Evaluationselementen über die m

Formel SOi

¦ Gewichtung  EE

i  x Fit  EEi  x

mit m = Anzahl der Evaluationselemente des

x 

Strategieobjekts. Der SFI eines Projekts p errechnet sich analog aus den gewichteten Konn

formitätsindizes der Teilstrategien SFIp

¦ GewichtungSO

i  p Fit  SOi  p

mit n = Anzahl

i 

der Strategieobjekte. 4.4.7

Visualisierung der Ergebnisse

Nach abgeschlossener Bewertung liegt eine Beurteilung der Konformität je Evaluationselement, Strategieobjekt und insgesamt als SFI vor. Eine Visualisierung erleichtert die Kommunikation der Ergebnisse. Für jedes bewertete IT-Projekt werden dazu in einer Spinnengrafik (sog. Kiviat Diagramm) die für die Evaluation relevanten Strategieobjekte jeweils einer Achse zugeordnet. Auf jeder Achse wird der erreichte Fit pro Teilstrategie angetragen. Abbildung 4-10 zeigt das Visualisierungsprinzip.

81

Geometrisches Mittel: GM y

n

y u y u  u yn

68

Strategiekonforme IT-Projekte

Gesamtfit des ITProjektes

SFI: 73 % Strategieobjekt 1

Strategieobjekt 2

Bewertung des IT-Projektes

Grundfläche

Strategieobjekt n

Strategieobjekt 3

Maximal erreichbare Fit für dieses Strategieobjekt

Tatsächlich erreichter Fit

80% 100%

«

«

Abbildung 4-10 Visualisierung mit der Konformitätsspinne

Die abgebildete Grundfläche veranschaulicht die relative Gewichtung der Strategieobjekte. Innerhalb der Grundfläche wird eine abgehobene Fläche eingezeichnet, die die tatsächliche Bewertung des IT-Projekts repräsentiert. Der SFI, der die gewichteten Einzelergebnisse der Strategieobjekte zusammenfasst, wird in einem separaten Feld angegeben.

4.5

Ablauf

Im Folgenden wird das Vorgehen zur Evaluation von IT-Projekten anhand ihrer Konformität zur IT-Strategie im Unternehmen erläutert. Abbildung 4-11 skizziert den Gesamtprozess. Organisatorische Ebene

Input

Prozessschritt

Für ein Unternehmen

Für jedes Projekt

IT-Strategie ‡ ,7/HLWOLQLHQ ‡ 6WUDW=LHOH ‡ 6WUDWHJLHREMHNWH

Strategieobjekte und deren Ziele beschreiben

‡ =LHOH]XJHRUGQHW ‡ 'RNXPHQWDWLRQ Output

Abbildung 4-11

Projektvorschlag ‡ 3URMHNWDQWUDJ ‡ 3URMHNWGHILQLWLRQ ‡ 3URMHNWVSH]LILNDWLRQ

Strategieobjekte gewichten

‡ (UJHEQLVVH$+3 Delphi ‡ 6XEMHNWLYH Einschätzung

Evaluationselemente beschreiben

‡ =LHOH überprüft ‡ 9HUIHLQHUWH=LHOH

Prozess der Evaluation

Evaluationselemente gewichten

‡ (UJHEQLVVH$+3 Delphi ‡ 6XEMHNWLYH Einschätzung

Bewertung durchführen

‡ %HZHUWXQJGHU Evaluationselemente je Strategieobjekt

Strategic Fit Index errechnen

‡ )LWMH6WUDWHJLH objekt ‡ *HVDPWILW

Strategiekonforme IT-Projekte

69

In den ersten vier Schritten wird ausgehend von der IT-Strategie ein unternehmensspezifisches Evaluationssystem generiert. Dies ist einmalig im Unternehmen durchzuführen, wenn man von einer konstanten IT-Strategie ausgeht. Ändert sich die IT-Strategie, so ist auch das Evaluationssystem anzupassen oder ggf. neu herzuleiten. Die letzten beiden Schritte (Bewertung durchführen und Strategic Fit Index errechnen) werden für jedes zu bewertende IT-Projekt durchgeführt. Im ersten Schritt erfolgt die Erhebung des Ist-Zustands der IT-Strategie. Falls nötig werden Strategieobjekte abgeleitet und beschrieben. Im zweiten Schritt erfolgt die relative Gewichtung der Strategieobjekte zueinander. Durch die Gewichtung werden Schwerpunkte in der Strategie und damit auch in der Messung der Konformität von IT-Projekten gesetzt. Im dritten Schritt erfolgt die Ermittlung der Evaluationselemente für jedes Strategieobjekt, also der Messpunkte in der IT-Strategie, über welche die Konformität des IT-Projekts letztendlich beurteilt wird. Für jedes Strategieobjekt enthält die Menge der Evaluationselemente nun alle Ziele, anhand derer der Fit eines IT-Projekts zum Strategieobjekt bewertet werden soll. Für jedes Evaluationselement wird festgelegt, wie die Konformität zum zugehörigen Ziel gemessen wird. Dies kann direkt durch die Beschreibung eines Treibers oder eines detaillierteren Messprinzips erfolgen. Im vierten Schritt werden die Evaluationsobjekte für jedes Strategieobjekt relativ zueinander gewichtet. Im fünften Schritt erfolgt die Bewertung durch einen Abgleich des IT-Projekts mit den Evaluationselementen. Grundsätzlich ist festzustellen, dass eine Bewertung in einer späten Phase eines IT-Projekts detaillierter erfolgen kann als in einer frühen Konzeptionsphase, der mögliche Änderungsaufwand aufgrund von Nichtkonformität jedoch mit steigender Detaillierung eines Projekts stark zunimmt. Die Prüfung der Strategiekonformität sollte folglich in einem frühen Stadium verankert werden. Im sechsten Schritt wird zunächst der Fit pro Strategieobjekt errechnet. Anschließend erfolgt die Bestimmung des Gesamt-SFI. Welche konkreten Auswirkungen der SFI hat, ist unternehmensspezifisch zu definieren. Beispielsweise kann ein SFI zwischen 80 Prozent und 90 Prozent bedeuten, dass der CIO sich mit dem Projektleiter über Verbesserungsmöglichkeiten im Projekt berät. Bei einem SFI zwischen 80 Prozent und 50 Prozent muss das Projekt

vor

einer

Durchführung

verpflichtend

geändert

werden

und

bei

einem

SFI < 50 Prozent wird das Vorhaben abgelehnt bzw. kann nur mit einer Ausnahmegenehmigung des CIO durchgeführt werden.

Kapitel 5 Bewertung von IT-Architekturen 5 Bewertung von IT-Architekturen 5.1

Übersicht

Dieses Kapitel beschreibt nach der Ausgangssituation (Abschnitt 5.2) Kennzahlen zur Bewertung der Architekturkonformität von IT-Projekten (Abschnitt 5.3) und Kennzahlen zur Bewertung der Qualität und Zukunftsfähigkeit der IT-Infrastruktur (Abschnitt 5.4). Abschnitt 5.5 zeigt, wie IT-Projekte mit den eingeführten Kennzahlen bewertet werden. In Abschnitt 5.6 wird die Anwendung der Kennzahlen im Unternehmen dargestellt. Abbildung 5-1 zeigt die Einordnung in das gesamte Vorgehensmodell. Strategiekonforme ITInvestitionen

IT-Strategie

4

strategische Sicht

IT-Projekte

Architekturkonforme ITProjekte

architektonische Sicht IT-Architektur

Modellierung von ITArchitekturen

3 5 Applikationen 7

Wertbeitrag von ITArchitektur-Management

6

Bewertung/ Steuerung

Abbildung 5-1

Einordnung von Kapitel 5

Technologien

Softwareunterstützung des Managements von ITArchitekturen

Darstellung

72

5.2

Bewertung von IT-Architekturen

Ausgangssituation

Die Bewertung der aktuellen Qualität der IT-Architektur erfolgt einerseits durch eine IstAnalyse der Applikationen in Bezug auf ihre Konformität mit der Soll-IT-Infrastruktur. Weiterhin erfolgt eine Beurteilung der Technologien in der Soll-IT-Infrastruktur im Hinblick auf ihre Zukunftsfähigkeit (vgl. Abbildung 5-2). Bewertung von IT-Architekturen

Bewertung der Qualität der IT-Arch.

Applikationen

Technologien

%HZHUWXQJDXI«

Bewertung von IT-Projekten Architekturprojekte

Geschäftsbereichsprojekte

Zukunftsfähigkeit Konformität

Abbildung 5-2

Bestandteile der Bewertung von IT-Architekturen

IT-Projekte werden kategorisiert in so genannte Architekturprojekte und Geschäftsbereichsprojekte. Letztgenannte haben eine Applikation zum Ziel, die ein Problem im Geschäftsbereich löst. Erstgenannte verbessern die Qualität der IT-Infrastruktur, indem nicht konforme Softwarearchitekturen auf konforme Technologien migriert, veraltete Technologien in der ITInfrastruktur durch moderne ersetzt werden oder die Soll-IT-Infrastruktur um neue Technologien erweitert wird. Architekturprojekte werden hinsichtlich ihrer Zukunftsfähigkeit oder ihres Beitrags zur Verbesserung der IT-Infrastruktur bewertet und Geschäftsbereichsprojekte hinsichtlich ihrer Konformität zur Soll-IT-Infrastruktur. Das in Kapitel 4 vorgestellte Konzept zur Sicherstellung der Strategiekonformität von IT-Projekten wird damit erweitert um Kennzahlen zur Operationalisierung dieser Strategiekonformität im Bereich der ITArchitektur. Die Kennzahlen Application Architectural Fit (AAF), Application Fitness Index (AFI), Technology Requirement Fulfillment (TRF), Technology Requirement Fulfillment Index (TRFI) und Verwendungsintensität sind für die zentrale IT-Abteilung, die Geschäftsbereiche und die Unternehmensleitung von Bedeutung (vgl. Abbildung 5-3).

Bewertung von IT-Architekturen

73

Eingabewerte

Kennzahlen und Zielgruppen

Fit

AAF

AFI

Erfüllungsgrade Anforderungskriterien und Gewichtungen

Abbildung 5-3

TRF

Zentrale IT-Abteilung

TRFI

Unternehmensleitung

Zukunftsfähigkeit

Verwendungsintensität

Architekturqualität

Applikationsgewichtungen

Architekturkonformität

Geschäftsbereich

Clustergewichtungen

Aussage

Zusammenhang der Kennzahlen

Die zentrale IT-Abteilung berechnet mit dem AAF den Kostenaufschlag für nicht standardkonforme IT-Projekte und kommuniziert diesen an die Geschäftsbereiche. Die Verwendungsintensität und der TRF dienen zur Beurteilung von Architekturprojekten. AFI und TRFI werden von der Unternehmensleitung zur Beurteilung der Qualität der IT-Architektur herangezogen. 5.2.1

Bedeutung von Technologiestandards

Die Abstraktion der IT-Infrastruktur und der Applikationen zeigt, wie die Softwarearchitektur der einzelnen Applikationen den Ist-Zustand der IT-Infrastruktur ergibt (vgl. Kapitel 3). Kosteneinsparungen in der IT-Infrastruktur entstehen dabei durch die Reduktion von Komplexitätskosten sowie aus Skalen-, Verbund- und Erfahrungskurveneffekten [Hung01, 188 - 197], die im Folgenden kurz erläutert werden. 5.2.1.1 Skaleneffekte Skaleneffekte (Economies of Scale) bezeichnen die Abhängigkeit der Produktionsmenge von der Menge der eingesetzten Produktionsfaktoren [Hung01, 189]. Positive Skaleneffekte treten ein, wenn die Produktionsmenge stärker steigt, als die eingesetzten Faktoren. Beispiele für positive Skaleneffekte in der IT-Infrastruktur sind: x

Lizenzkosten: Mehrere Applikationen teilen sich eine Lizenz, z. B. für eine Datenbank wie Oracle. Es müssen weniger Lizenzen erworben werden, die Lizenzkosten sinken [Youn03a, 2].

74

Bewertung von IT-Architekturen

x

Installations- und Wartungskosten: Installations- und Wartungskosten müssen nur einmal für die jeweilige Technologie aufgebracht werden und nicht für jede einzelne Applikation.

x

Kapazitätsauslastung: Eine zentrale Verwaltung der Technologien ermöglicht eine genauere Planung der Kapazität 82 der einzelnen Technologien, was zu einer verbesserten Kapazitätsauslastung führt. Falls sich z. B. mehrere Applikationen einen Applikationsserver teilen, kann die Kapazität der Hardware des Applikationsservers optimal ausgelastet werden.

x

Verhandlungsmacht: Durch die Bündelung der Einkaufsaktivitäten steigt die Verhandlungsmacht gegenüber Lieferanten. Höhere Rabatte im Vergleich zum Erwerb einzelner Applikationen sind so möglich [Nunn03, 5; Liu02, 14 und 19 f.; Meta02b, 19].

5.2.1.2 Verbundeffekte Verbundeffekte (Economies of Scope) bewirken Kosteneinsparungen durch Synergien bei der Produktion mehrerer Produktlinien [Hung01, 190]. Beispiele sind eine verbesserte Maschinenauslastung durch zusätzliche Produktion von anderen Produkten auf der gleichen Maschine oder eine Fixkostendegression in der Forschung bei Produkten mit verwandter Technologie. Bei der IT-Infrastruktur treten diese Effekte dadurch auf, dass Plattformen Technologien bündeln und Dienste für unterschiedliche Applikationen bereitstellen. Die Plattform E-Business aus Abbildung 3-15 beinhaltet Technologien, deren Kompatibilität gewährleistet ist. IT-Projekte, die diese Plattform nutzen, sparen Planungskosten, da die Kompatibilität der Technologien nicht mehr geprüft werden muss. 5.2.1.3 Erfahrungskurveneffekte Erfahrungskurveneffekte beruhen auf der lerntheoretischen Erkenntnis, dass Menschen bei Wiederholung einer bestimmten Tätigkeit lernen. Die Ausübung einer bestimmten Tätigkeit fällt bei wiederkehrenden Aktivitäten zunehmend leichter [Hung01, 191]. Die durch das ITArchitektur-Management geförderte Standardisierung in der IT-Infrastruktur erhöht die Erfahrung der Mitarbeiter im Umgang mit den einzelnen Technologien. Einarbeitungs- und Schulungsaufwände fallen nur bei einer Erweiterung der IT-Infrastruktur an. Zudem können mit zunehmender Erfahrung die Wartungsarbeiten an der Technologiearchitektur schneller und kostengünstiger durchgeführt werden, da sich bei der Verwendung von Technologiestandards diese Tätigkeiten meist wiederholen oder zumindest sehr ähneln. 5.2.2

IT-Architektur-Vertrag

Zur Gewährleistung der Einhaltung von Technologiestandards können Strafgebühren für das betreffende IT-Projekt bei der Nutzung nicht konformer Technologien so gestaltet wer82

Mit Kapazität ist hier Leistungsfähigkeit einer Technologie gemeint. Dabei kann es sich z. B. um das Speichervolumen, die maximale Anzahl paralleler Benutzerzugriffe, den Datendurchsatz in einem Netzwerk oder die Verarbeitungsgeschwindigkeit von Anfragen an eine Datenbank handeln.

Bewertung von IT-Architekturen

75

den, dass man sämtliche anfallenden Kosten, die durch nicht konforme Technologien entstehen, dem verantwortlichen Geschäftsbereich zurechnet [LoPR02, 45]. Grundlage für den im Folgenden dargestellten Ansatz ist ein imaginärer Vertrag zwischen den Geschäftsbereichen und der zentralen IT-Abteilung: Die Geschäftsbereiche sichern zu, die Soll-ITArchitektur bei ihren Projektvorschlägen weitgehend einzuhalten. Die Nichtkonformität eines IT-Projekts stellt einen Vertragsbruch dar, der durch eine Nonkonformitätsstrafe einen Kostenaufschlag mit sich bringt. Der Schaden einer nicht konformen Applikation wird in Form eines Kostenaufschlages projektbezogen berechnet und dient zur Deckung der prognostizierten zusätzlich anfallenden Kosten im IT-Bereich. Der Kostenaufschlag wird zur Finanzierung von möglichen späteren Integrationsprojekten zur Steigerung der Architekturkonformität von Applikationen erhoben. Die zentrale IT-Abteilung ihrerseits verpflichtet sich, die Interessen der Geschäftsbereiche bei der Weiterentwicklung der IT-Architektur zu berücksichtigen. Bei Nichterfüllung der Bedarfe der Geschäftsbereiche werden entsprechende Projekte zur Weiterentwicklung initiiert (vgl. Tabelle 5-1). Geschäftsbereich )RUGHUXQJLPÄ,7$UFKLWHNWXU 9HUWUDJ³ Rechte bei Nichterfüllung

Tabelle 5-1

Zentrale IT-Abteilung

Problemlösung

Konformität der IT-Projekte

Initiierung von IT-Projekten zur Weiterentwicklung der ITInfrastruktur

Kostenaufschlag für Nichtkonformität

IT-Architektur-Vertrag

Ein Indikator zum Abgleich der Bedarfe an Funktionalitäten der Geschäftsbereiche mit der bestehenden Technologiearchitektur wird in Abschnitt 5.3 vorgestellt. Die IT-Architektur wird so gezielt nach den Anforderungen der Geschäftsbereiche unter gleichzeitiger Vermeidung von nicht notwendiger Komplexität weiterentwickelt.

 .HQQ]DKOHQ]XU%HZHUWXQJGHU,7$UFKLWHNWXU.RQIRUPLWlW Für jede vorhandene Applikation wird zunächst einzeln eine Bewertung der Konformität mit der Soll-IT-Infrastruktur vorgenommen, um anschließend die gesamte Applikationslandschaft des Unternehmens beurteilen zu können.  .RQIRUPLWlWGHU6RIWZDUHDUFKLWHNWXU Die einzelnen Bestandteile der Softwarearchitektur jeder einzelnen Applikation werden zunächst den Layern und dann den Clustern zugeordnet. Tabelle 5-1 zeigt z. B. die Softwarearchitektur einer Applikation Online-Shop.

76

Bewertung von IT-Architekturen

Layer Applikationsentwicklung

Middleware Komponenten

Datenmanagement

Internet und mobile Technologien

Telekommunikation und Netzwerk

Server- und Datenspeicherumgebung Clientspezifikation

Tabelle 5-2

Cluster Configuration Management

Technologie -

Design

-

Development

Zend Studio 5

Documentation

Microsoft Office

Modeling/ Case Tools

-

Optimization

-

Specifications & Languages

PHP, HTML

Testing

-

Versionsmanagement

-

Database Middleware

ODBC

Directory Services

-

Enterprise Application Integration

-

ETL (Extraction, Transformation & Loading)

-

Messaging

-

Object Request Brokers

-

Transaction Monitors

-

User Management

Proprietäre Benutzerverwaltung

Data Mining

-

DBMS

MySQL 4.x

OLAP

-

Reporting

-

DB-Clients

phpMyAdmin 2.x

Database Admin Tools

MySQL Administrator

Application Servers

Apache 1.x

Enterprise Content Management

-

File Transfer

Smart FTP

Portal Servers

-

Remote Access

-

Search Engine

-

Web Infrastructure

-

Web Servers

Apache 1.x

Border Gateway Networks (Extranet)

-

Global Backbone

-

LAN

-

Name Services

-

Voice

-

WAN

-

Wireless

-

Server Hardware

FujitsuSiemens PRIMERGY RX200

Server OS

Suse Linux Enterprise 10

Storage Technologies

Local Hard Disk

Antivirus

-

Browser

Microsoft IE 6

Browser Plug-In

-

Client OS

Microsoft Windows XP

Groupware

-

Compression

-

Customer Interface

-

Drawing

-

E-Mail

-

Hardware Desktop

-

Hardware Notebook

-

Hardware Tower

-

Office Automation

-

Pervasive Computing

-

Project Management

-

Runtime

-

Beispielhafte Softwarearchitektur der Applikation Online-Shop

Bewertung von IT-Architekturen

77

Im nächsten Schritt zeigt ein Vergleich mit der Soll-IT-Infrastruktur, welche Technologien der Softwarearchitektur konform zum Unternehmensstandard sind (vgl. Tabelle 5-3). Layer

Technologien OnlineShop (Ist-Zustand)

Cluster

nein

Specifications & Languages PHP, HTML

Visual C#

nein

Middleware Komponenten

Database Middleware

ODBC

-

nein

User Management

Proprietäre Benutzerverwaltung Microsoft Active Directory

nein

Datenmanagement

DBMS

MySQL 4.x

Microsoft SQL Server 2005

nein

DB-Clients

phpMyAdmin 2.x

Microsoft SQL Server Client

nein

Database Admin Tools

MySQL Administrator

nein

Application Servers

Apache 1.x

Microsoft SQL Server Management Studio Microsoft Internet Information Server 5.x

File Transfer

Smart FTP

SecureFTP 2.x

nein

Web Servers

Apache 1.x

nein

Server Hardware Server OS

FujitsuSiemens PRIMERGY RX200 Suse Linux Enterprise 10

Storage Technologies

Local Hard Disk

Microsoft Internet Information Server 5.x FujitsuSiemens PRIMERGY RX200 Microsoft Windows Server 2003 SAN

Browser

Microsoft IE 6

Microsoft IE 6

ja

Client OS

Microsoft Windows XP

Microsoft Windows XP

ja

Internet und mobile Technologien

Server- und Datenspeicherumgebung Clientspezifikation

Tabelle 5-3

Zend Studio 5

Documentation

Microsoft Office

konform

Visual Studio 2005 Professional Edition Microsoft Office

Applikationsentwicklung

Development

Technologien SollIT-Infrastruktur

ja

nein

ja nein nein

Soll-/ Ist-Vergleich Online-Shop

Die Spalte konform gibt zunächst an, ob die jeweilige Technologie konform zum Standard ist. Später werden die betroffenen Cluster einer Applikation bezüglich ihrer Bedeutung innerhalb der Softwarearchitektur gewichtet. Die Summe der Gewichte beträgt 100 Prozent. Durch die Gewichte kann der IT-Architekt 83 die Bedeutung von ausgewählten Clustern betonen (vgl. Tabelle 5-6). 5.3.2

Bewertung der Technologien

Im nächsten Schritt wird die Architekturkonformität auf der Ebene der Technologien bewertet. Dazu wird als Kennzahl ein Konformitätsindex, im Folgenden Fit genannt, eingeführt. Für jedes Cluster wird diejenige Technologie, die die Applikation tatsächlich verwendet, mit dem/ den entsprechenden Element(en) der Soll-IT-Infrastruktur verglichen. Stimmen diese überein, entspricht dies einem Fit von 100 Prozent. Für nicht konforme Technologien schätzt der IT-Architekt den Schaden. Diese Schätzung betrachtet die Migrationskosten hin zu konformen Technologien. Aufgrund dieser Schätzung bestimmt der IT-Architekt die Höhe des Fit. Tabelle 5-4 zeigt für das Beispiel das Ergebnis der Bewertung.

83

Die Rolle IT-Architekt gehört zur zentralen IT-Abteilung und verantwortet die unternehmensweite IT-Architektur. Sie kann sich auf mehrere Stellen aufteilen und in Form einer ITArchitekturabteilung strukturiert sein.

78

Bewertung von IT-Architekturen

Layer

Cluster

Applikationsentwicklung

Middleware Komponenten

Datenmanagement

Internet und mobile Technologien

Server- und Datenspeicherumgebung

Tabelle 5-4

Development

Zend Studio 5

Documentation

Microsoft Office

Technologien Soll-ITInfrastruktur

Fit (%)

Visual Studio 2005 Professional Edition

50

Microsoft Office

100

Specifications & Languages PHP, HTML

Visual C#

0

Database Middleware

ODBC

-

0

User Management

Proprietäre Benutzerverwaltung Microsoft Active Directory

DBMS

MySQL 4.x

Microsoft SQL Server 2005

70

DB-Clients

phpMyAdmin 2.x

Microsoft SQL Server Client

70

Database Admin Tools

MySQL Administrator

70

Application Servers

Apache 1.x

Microsoft SQL Server Management Studio Microsoft Internet Information Server 5.x

90

File Transfer

Smart FTP

SecureFTP 2.x

Web Servers

Apache 1.x

Server Hardware

FujitsuSiemens PRIMERGY RX200 Suse Linux Enterprise 10

30

0

Storage Technologies

Local Hard Disk

Microsoft Internet Information Server 5.x FujitsuSiemens PRIMERGY RX200 Microsoft Windows Server 2003 SAN

Browser

Microsoft IE 6

Microsoft IE 6

100

Client OS

Microsoft Windows XP

Microsoft Windows XP

100

Server OS

Clientspezifikation

Technologien OnlineShop (Ist-Zustand)

0 100 0 90

Bewertung des Fit

Tabelle 5-5 zeigt die Bewertung des Fit der einzelnen Technologien durch den IT-Architekten. Sie erfolgt aus der Erfahrung des IT-Architekten heraus. Die Objektivität der Bewertung wird durch Regeln erhöht. So sind die einzelnen Entscheidungen zu begründen und im Zweifelsfall unter Einbeziehung von weiteren IT-Architekten oder von neutralen Gutachtern zu validieren.

Bewertung von IT-Architekturen

Technologien Online-Shop (IstZustand)

Technologien Soll-ITInfrastruktur

79

Fit (%)

Begründung

Zend Studio 5

Visual Studio 2005 Professional Edition

50

Die Entwicklungsumgebung verursacht keine hohen Kosten und spielt für den laufenden Betrieb eine untergeordnete Rolle.

Microsoft Office

Microsoft Office

100

-

PHP, HTML

Visual C#

0

Die Programmiersprache der Applikation kann nur mit einer vollständigen Neuprogrammierung des Quellcodes in Visual C# geändert werden. Der bestehende PHP- und HTML-Code ist nicht wiederverwendbar.

ODBC

-

0

Der Datenbankkonnektor spielt in diesem Fall keine Rolle.

Proprietäre Benutzerverwaltung MySQL 4.x

Microsoft Active Directory

30

Microsoft SQL Server 2005

70

phpMyAdmin 2.x

Microsoft SQL Server Client

70

MySQL Administrator

Microsoft SQL Server Management Studio Microsoft Internet Information Server 5.x

70

Eine Migration der Benutzerverwaltung auf das zentrale Verzeichnis ist mit mäßigem Aufwand möglich. Für eine Datenbankmigration liegen Softwarewerkzeuge vor, der Code muss nur minimal angepasst werden. Der Datenbankclient kann zusammen mit dem DBMS ausgetauscht werden - nur Schulungsaufwand entsteht. Die DBMS Administration kann zusammen mit dem DBMS ausgetauscht werden - nur Schulungsaufwand entsteht. Der Applikationsserver kann nur mit einer vollständigen Neuprogrammierung der Applikation ausgetauscht werden.

Smart FTP

SecureFTP 2.x

90

Apache 1.x

Microsoft Internet Information Server 5.x

0

FujitsuSiemens PRIMERGY RX200 Suse Linux Enterprise 10

FujitsuSiemens PRIMERGY RX200 Microsoft Windows Server 2003

100 0

Das Betriebssystem des Servers kann nur mit einer vollständigen Neuprogrammierung der Applikation geändert werden.

Local Hard Disk

SAN

90

Die Daten können mit wenig Aufwand von den lokalen Festplatten in das Storage Area Network verschoben werden.

Microsoft IE 6

Microsoft IE 6

Apache 1.x

Microsoft Windows XP Microsoft Windows XP

Tabelle 5-5

5.3.3

0

Ein Austausch der Datentransfersoftware ist kostengünstig realisierbar. Der Webserver kann nur mit einer vollständigen Neuprogrammierung der Applikation ausgetauscht werden. -

100

-

100

-

Begründungen für die Bewertung des Fit

Bewertung einzelner Applikationen

Die Bewertungen ermöglichen eine Aussage über die Architekturkonformität einer einzelnen Applikation. Dazu werden die Gewichtungen der einzelnen Cluster mit dem jeweiligen Fit multipliziert und die Ergebnisse kumuliert (vgl. Tabelle 5-6). Die auf diese Weise errechnete Kennzahl wird

AAF

¦G

c

Application

u Fit c

Architectural

Fit (AAF)

benannt.

In

der

Berechnung

ist c das in der Softwarearchitektur der Applikation verwendete

c

Cluster, Gc die Gewichtung des Clusters c und Fitc die Konformität der tatsächlich verwendeten Technologie mit der Technologie aus der Soll-IT-Infrastruktur. Diese Kennzahl gibt Auskunft darüber, wie hoch die Konformität der Applikation mit der Soll-IT-Infrastruktur ist und liegt zwischen 0 und 100 Prozent. Ein AAF von 100 Prozent entspricht einer vollständigen Architekturkonformität der Softwarearchitektur einer Applikation, während 0 Prozent auf eine absolute Nichtkonformität hindeutet.

80

Bewertung von IT-Architekturen

Technologien Online- Technologien Soll-ITShop (Ist-Zustand) Infrastruktur

Gc (%)

Fit (%)

Fitgewichtet (%)

5

50

2,5

2

100

2

15

0

0

3

0

0

User Management Proprietäre Benutzerverwaltung Microsoft Active Directory

10

30

3

DBMS

MySQL 4.x

Microsoft SQL Server 2005

10

70

7

DB-Clients

phpMyAdmin 2.x

Microsoft SQL Server Client

5

70

3,5

Database admin tools Applications Servers

MySQL Administrator

Microsoft SQL Server Management Studio Microsoft Internet Information Server 5.x

5

70

3,5

15

0

0

Cluster Development

Zend Studio 5 Microsoft Office

Visual Studio 2005 Professional Edition Microsoft Office

Documentation Specifications & Languages Database Middleware

PHP, HTML

Visual C#

ODBC

-

Apache 1.x

File Transfer

Smart FTP

SecureFTP 2.x

5

90

4,5

Web Servers

Apache 1.x

10

0

0

Server Hardware

FujitsuSiemens PRIMERGY RX200 Suse Linux Enterprise 10

Microsoft Internet Information Server 5.x FujitsuSiemens PRIMERGY RX200 Microsoft Windows Server 2003 SAN

3

100

3

5

0

0

2

90

1,8

Server OS Storage Technologies Browser

Local Hard Disk Microsoft IE 6

Microsoft IE 6

3

100

3

Client OS

Microsoft Windows XP

Microsoft Windows XP

2

100

2

Application Architectural Fit (AAF)

Tabelle 5-6

5.3.4

100

35,8

Bewertung einer Applikation mit dem AAF

Bewertung der Applikationslandschaft

Nach der Bewertung jeder einzelnen Applikation werden die Applikationen nach Ihrer Bedeutung im Unternehmen gewichtet. Die Summe der Gewichtungen ergibt 100. Der höchste Wert wird der geschäftskritischsten Applikation im Unternehmen zugeordnet. Die AAFs (vgl. Tabelle 5-6) werden gewichtet und summiert, um den Architectural Fitness Index (AFI) zu erhalten:

AFI

¦G

a

u AAFa ,

wobei Ga die Gewichtung der

a

Applikation a ist (vgl. Tabelle 5-7). Mit dem AFI wird die Konformität der Ist-Applikationslandschaft bewertet.

Bewertung von IT-Architekturen

81

Ga

AAF (%)

AAFgewichtet (%)

%HVFKZHUGHPDQDJHPHQW ,QWHUQHWDXIWULWW 2QOLQH6KRS $XIWUDJVHUIDVVXQJ ...

    

    

    

Architectural Fitness Index (AFI)

100

Applikation

50,92

7DEHOOH %HUHFKQXQJGHV$),%HLVSLHO 

Der Zielwert des AFI kann in der IT-Strategie innerhalb des Strategieobjekts IT-Architektur YRUJHJHEHQZHUGHQ]%Ä'HU=LHOZHUWGHV$),]XP6WLFKWDJLVW3UR]HQW³ 'HU8QWHUVFKLHG]ZLVFKHQ=LHOZHUWXQGWDWVlFKOLFKHP:HUW]XP6WLFKWDJJLEW$XVNXQIWEHU die Zielerreichung ('AFI = AFIIst - AFISoll). Ein negatives '$),VWHKWIUHLQH=LHOYHUIHKOXQJ HLQSRVLWLYHVIUHLQH=LHOEHU HUIOOXQJ(LQSRVLWLYHV'AFI als Bestandteil des Mitarbeiter]LHOV\VWHPVIKUW]X%RQXV]DKOXQJHQIU,7$UFKLWHNWHQXQG3URMHNWOHLWHU'LH'XUFKVHW]XQJ GHU,7$UFKLWHNWXU6DQGDUGVZLUGGDPLWDXILQGLYLGXHOOHU(EHQHPRWLYLHUW

5.4

Kennzahlen zur Bewertung der Zukunftsfähigkeit

1DFKGHU%HZHUWXQJGHU$UFKLWHNWXUNRQIRUPLWlWGHU$SSOLNDWLRQVODQGVFKDIWZLUGGLH6ROO,7 ,QIUDVWUXNWXUKLQVLFKWOLFKLKUHU=XNXQIWVIlKLJNHLWEHXUWHLOW=XQlFKVWZHUGHQ.ULWHULHQIHVWJH legt, nach denen die Technologien zu bewerten sind (hier Anforderungskriterien genannt). 'LHVHOHLWHQVLFKDXVGHP6WUDWHJLHREMHNWIT-Architektur der IT-Strategie ab und können in HLQHP3UR]HVVJHQHULHUWZHUGHQGHUGHPLQ$EVFKQLWWEHVFKULHEHQHQJOHLFKW*UXQG VlW]OLFKQHQQW]%:ATTGLH.ULWHULHQPerformance, Availability und SecurityDOVQLFKWIXQN WLRQDOH $QIRUGHUXQJHQ DQ 7HFKQRORJLHQ >:DWW@ &+81* ET AL. gliedern die QLFKWIXQNWLRQDOHQ $QIRUGHUXQJHQ DQ 6RIWZDUH LQ GHQ .DWHJRULHQ Performance, Design, Adaptation und General XQG ELHWHQ GDUXQWHU HLQHQ .DWDORJ DQ %HZHUWXQJVNULWHULHQ DQ >&1 0) an den Geschäftsbereich, der das ITProjekt initiiert hat. Falls es sich um ein IT-Projekt der zentralen IT-Abteilung handelt, gibt 'AFI an, wie hoch der Beitrag zur Verbesserung der IT-Infrastruktur ist. Bei Auswahlentscheidungen zwischen mehreren Projektanträgen unter Budgetrestriktionen dient das 'AFI eines Projekts als Nutzenindikator für die IT-Architektur. Abbildung 5-4 veranschaulicht das Vorgehen. Neue Applikation Cluster Directory Services & User Management DBMS DB-Clients Applications Servers Web Servers LAN Server Hardware Server OS Browser

Gewichtung (%)

Fit (%)

Fitgewichtet (%)

4

100

4

20 12 10 12 8 12 12 10

30 30 100 100 100 0 0 100

6 4 10 12 8 0 0 10

Application Architectural Fit (AAF)

Applikation

53,60

Gewichtung

Beschwerdemanagement Internetauftritt Online-Shop Auftragserfassung Neue Applikation ...

9 22 18 17 12 22

Architectural Fitness Index (AFI)

100

Abbildung 5-4

AAF (%) AAFgewichtet (%) 62,00 100,00 35,80 10,30 53,60 42,00

5,58 22,00 6,44 1,75 6,43 9,24 51,45

Berechnung der Auswirkung neuer Applikationen (Beispiel)

Der AFI verändert sich durch die neue Applikation aus dem Beispiel (vgl. Abbildung 5-4) von 50,92 (vgl. Tabelle 5-7) auf 51,45. 'AFI beträgt damit 0,53. Eine Belohnung (für die Verbesserung der IT-Architektur) oder eine Strafzahlung (für die Verschlechterung der IT-Architektur) ist abhängig von der Höhe der Projektkosten. Im Zuge der Weiterentwicklung des Unternehmens und der IT-Architektur muss gewährleistet werden, dass Geschäftsprozesse und die unterstützenden Applikationen flexibel umstrukturiert, verknüpft und erweitert werden können. Proprietäre Technologien in der Softwarearchitektur einzelner Applikationen erhöhen den Aufwand um Umstrukturierungen, Verknüpfungen oder Erweiterungen zu realisieren. Applikationen, die gänzlich oder in Teilen nicht dem

Bewertung von IT-Architekturen

85

vorgegebenen Standard entsprechen, werden daher im Zuge der Unternehmensentwicklung auf standardkonforme Technologien migriert. Der Aufwand zur Migration einer Applikation ist dabei umso höher, je niedriger die IT-Architektur-Konformität ist. Bei vollständiger Nichtkonformität bedeutet dies, dass ein IT-Projekt nochmals vollständig implementiert werden muss. Eine Strafzahlung für hundertprozentige Nichtkonformität zu den Vorgaben der IT-Architektur ist daher mindestens so hoch wie die Gesamtkosten des Projekts. Nur in diesem Fall ist in der zentralen IT-Abteilung genügend Budget für eine vollständige Reimplementierung auf konforme Technologien vorhanden. Der Kostenaufschlag für eine Applikation a berechnet sich aus einem Kostenaufschlagsfaktor multipliziert mit den Projektkosten:

Kostenaufschlaga

  AAFa u Projektkostena . 

Falls das IT-Projekt zur Erstellung der neuen Applikation aus Abbildung 5-4 angenommene Projektkosten von 100.000,- Euro verursacht, beträgt der Kostenaufschlag 46.400,- Euro 85. Dieser Kostenaufschlag kann als so genannte Integrationsversicherung bezeichnet werden und dient dem Investitionsschutz der IT-Projekte. Die Geschäftsbereiche kalkulieren den Kostenaufschlag bereits bei der Planung von IT-Projekten mit ein und werden dadurch dazu angehalten, die Standards der IT-Infrastruktur einzuhalten. Unter Einbeziehung eines Korrekturfaktors k kann die Höhe der Kostenaufschläge variiert werden. Der Korrekturfaktor wird mit dem Kostenaufschlag multipliziert. Je höher dieser Korrekturfaktor ist, umso härter wird Nichtkonformität von IT-Projekten sanktioniert. Da die neue Applikation in dem Beispiel den AFI erhöht, kann die Argumentation aus dem Geschäftsbereich lauten, dass das Projekt einen positiven Einfluss auf die ITArchitektur hat und daher keine Strafzahlung zu akzeptieren sei. Dagegen spricht, dass die Qualität der gesamten IT-Architektur für das einzelne Projekt keine Bedeutung hat, da der Bestand an alten, nicht konformen Applikationen 86 einen AFI von 100 Prozent immer verhindern wird. Allerdings ist eine Kompromisslösung zur Belohnung von Konformität zur ITArchitektur denkbar, bei der z. B. ab einem AFI größer der Zielvorgabe aus dem Strategieobjekt IT-Architektur 87 der Kostenaufschlag halbiert und ab einer Konformität von 90 Prozent gänzlich gestrichen wird. Dazu kann bei einem AAF von 100 Prozent eine Bonuszahlung aus der zentralen IT-Abteilung erfolgen, die einen gewissen Anteil der Projektkosten deckt.

85 86 87

KostenaufschlagNeue Aplikation Vgl. Abschnitt 2.2.1. Vgl. Abschnitt 5.3.4.

   u  ¼ 

86

Bewertung von IT-Architekturen

5.5.2

Integrationsprojekte

Der Nutzen von Integrationsprojekten wird daran gemessen, inwieweit die IT-ArchitekturKonformität erhöht wird. Dazu werden die Veränderungen von AAF und AFI berechnet. Durch Bildung der Differenz aus bisherigem AAF (AAFalt) und neuem AAF (AAFneu) und anschließender Multiplikation mit der Applikationsgewichtung erhält man den möglichen Gewinn an AFI-Punkten ('AFI) durch das Integrationsprojekt. Um Integrationsprojekte zu priorisieren werden die gewonnenen AFI-Punkte den entstehenden Kosten gegenüber gestellt (vgl. Tabelle 5-10). Kosten

Nutzen

*URENRQ]HSWLRQ )HLQNRQ]HSWLRQ 3URJUDPPLHUXQJ 7HVW ,QVWDOODWLRQ 3LORWLHUXQJ 3URGXNWLRQ (LQVSDUXQJHQ

¼ ¼ ¼ ¼ ¼ ¼ ¼ ¼

%HVFKZHUdemanagement $XIWUDJVerfassung

¼

6,43 AFI-Punkte 5,70 AFI-Punkte

12,13 AFI-Punkte

Tabelle 5-10 Kosten-Nutzen-Bilanz von Integrationsprojekten

Als Kennzahl für die Wirtschaftlichkeit eines Integrationsprojekts dienen die Kosten pro AFIPunkt. Diese werden aus dem Quotienten aus den Kosten des Integrationsprojekts und den gewonnenen AFI-Punkten berechnet:

Kosten je AFI - Punkt

¦

Projektkosten . Gewonnene AFI - Punkte

Im Beispiel aus Tabelle 5-10 kostet ein AFI-Punkt 3.792,25 Euro. Anhand dieser Kennzahl lassen sich alternative Integrationsprojekte bewerten. Je geringer die Kosten pro AFI-Punkt, umso wirtschaftlicher ist ein Projekt aus Sicht der IT-Architektur. Falls die Kosten eines Projekts durch höhere Einsparungen als Ausgaben negativ sind, ist die Berechnung der Kosten je AFI-Punkt irrelevant, da die gewonnenen AFI-Punkte kostenfrei sind. 5.5.3

Erneuerungsprojekte

Erneuerungsprojekte dienen der Weiterentwicklung der Soll-IT-Infrastruktur. Eine Technologie wird dabei modernisiert oder ersetzt (vgl. Tabelle 5-11). Erneuerungsprojekte dienen der Sicherung der Zukunftsfähigkeit der IT-Architektur. Der Nutzen von Erneuerungsprojekten bemisst sich aus der Verbesserung des TRFI. Durch Bildung der Differenz des neuen (TRFneu) und alten TRF (TRFalt) und anschließender Multiplikation mit der Verwendungsintensität erhält man den Zugewinn an TRFI-Punkten ('TRFI) durch das Erneuerungsprojekt:

Bewertung von IT-Architekturen

'TRFI

87

TRFneu  TRFalt u Verwendungsintensität . 

Datenmanagement DBMS 15,95 neu alt Microsoft SQL Server 2005 Oracle 10g Technologie: (%) E Erfüllungsgrad (%) Egewichtet (%) Anforderungskriterium Gewichtung (%) Erfüllungsgrad (%) gewichtet Kosten 20 60 12,00 50 10,00 Funktionalität 20 100 20,00 100 20,00 Leistungsfähigkeit 10 80 8,00 100 10,00 Hochverfügbarkeit 5 80 4,00 100 5,00 Skalierbarkeit 10 90 9,00 100 10,00 Bedienbarkeit 15 70 10,50 80 12,00 Sicherheit 20 80 16,00 100 20,00 Technology Requirement Fulfillment (TRF) 79,50 87,00 Layer: Cluster: Verwendungsintensität:

Tabelle 5-11

Berechnung des Nutzens von Erneuerungsprojekten

Tabelle 5-11 zeigt ein Beispiel, in dem die Technologie Microsoft SQL Server 2005 im Cluster DBMS durch die Technologie Oracle 10g ersetzt wird. Der Zugewinn an TRFIPunkten beträgt 1,2 88. Um einen Vergleich mit anderen Projekten dieser Klasse durchführen zu können, werden die gewonnenen TRFI-Punkte den entstehenden Kosten gegenüber gestellt. Analog zu den Integrationsprojekten entsteht eine Kosten-Nutzen-Bilanz. 5.5.4

Erweiterungsprojekte

Bei Durchführung eines Erweiterungsprojekts wird eine neue Technologie hinzugefügt. Die Bildung der Kosten-Nutzen-Bilanz erfolgt analog der Vorgehensweise bei den Integrationsprojekten.

5.6

Anwendung der Kennzahlen

Die vorgestellten Kennzahlen adressieren die Geschäftsbereiche, die zentrale IT-Abteilung und die Geschäftsleitung (vgl. Tabelle 5-12).

88

Der Wert ist gerundet und berechnet sich folgendermaßen:

'TRFI

   u 1 . 

88

Bewertung von IT-Architekturen

Kürzel

Kennzahl

Beschreibung / Einsatz

Application Architectural Fit

AFI

Application Fitness Index Architekturkonformität der gesamten ITArchitektur. Dient als Messgröße zur Steuerung von Zielvorgaben.

Zentrale IT-Abteilung, Geschäftsleitung

TRF

Technology Requirement Zukunftsfähigkeit einer Technologie, gemessen Fulfillment an den jeweiligen Anforderungen. Dient zur Bewertung einzelner Technologien.

Zentrale IT-Abteilung

TRFI

Technology Requirement Zukunftsfähigkeit der IT-Architektur. Dient als Fulfillment Index Messgröße zur Steuerung von Zielvorgaben.

Zentrale IT-Abteilung, Geschäftsleitung

Tabelle 5-12

Architekturkonformität einer Applikation. Dient der Bewertung von einzelnen Applikationen.

Zielgruppe(n)

AAF

Geschäftsbereich, Zentrale IT-Abteilung

Kennzahlenübersicht

Die Kennzahlen erweitern bestehende Kennzahlensysteme im IT-Management, wie z. B. die IT Balanced Scorecard. In der von KÜTZ vorgeschlagenen IT Balanced Scorecard [Kütz03, 137] ersetzt der AFI die Kennzahl Konformität zu Konzernstandards in der Schlüsselkenngröße Geschäftsprozessunterstützung. Der TRFI fließt in den Parameter ITManagement-Performance ein. Da in diesen auch andere Kennzahlen einfließen, wird der TRFI unternehmensindividuell gewichtet.

Kapitel 6 Wertbeitrag von IT-Architekturen 6 Wertbeitrag von IT-Architekturen 6.1

Übersicht

Dieses Kapitel beschreibt nach der Ausgangssituation (Abschnitt 6.2) Ansätze zur Bewertung des Wertbeitrags von IT im Allgemeinen (Abschnitt 6.3). Abschnitt 6.4 zeigt die Wirkung der IT-Architektur auf die IT und das Geschäftsmodell eines Unternehmens. Die Bewertung von IT-Architekturen und eine Auswahl von vorhandenen Bewertungsansätzen zeigen die Abschnitte 6.5 und 6.6. Kennzahlen für die IT-Architektur und deren Operationalisierung werden in den Abschnitten 6.7 und 6.8 vorgestellt. Abbildung 6-1 zeigt die Einordnung in das gesamte Vorgehensmodell. Strategiekonforme ITInvestitionen

IT-Strategie

4

strategische Sicht

IT-Projekte

Architekturkonforme ITProjekte

architektonische Sicht IT-Architektur

Modellierung von ITArchitekturen

3 5 Applikationen 7

Wertbeitrag von ITArchitektur-Management

6

Bewertung/ Steuerung

Abbildung 6-1

Einordnung von Kapitel 6

Technologien

Softwareunterstützung des Managements von ITArchitekturen

Darstellung

90

Wertbeitrag von IT-Architekturen

6.2

Ausgangssituation

Unternehmen erstellen durch die Kombination von Produktionsfaktoren Produkte und Dienstleistungen, um damit Gewinne zu erwirtschaften. Diese Wertschöpfung bildet die Grundmotivation der Aktivitäten eines Unternehmens [KrSe03, 39 f.]. Die Transformation der Produktionsfaktoren in Güter oder Dienstleistungen mit einem höheren Geldwert schafft einen Mehrwert. Das Konzept der Wertorientierung begründet sich in der ShareholderValue-Analyse, die Unternehmensaktivitäten entsprechend dem Wert, den diese für die Anteilseigner generieren, betrachtet. Eine wichtige Steuerungsgröße des Wertbeitrags ist der Economic Value Added (EVA) [Webe04, 248], oder auch Geschäftswertbeitrag, der die absolute Nettogröße eines Gewinns nach Abzug der Kapitalkosten für das eingesetzte Gesamtkapital angibt 89. Das Ziel beim Entwurf von Geschäftsprozessen und bei deren Unterstützung durch IT liegt in der Steigerung der Unternehmensleistung. Kann ein solcher Mehrwert nicht nachgewiesen werden, ist der entsprechende Aufwand in Frage zu stellen [PiRe03, 195]. Das Verhältnis von Nutzen und Kosten bestimmt den Wert einer Investition [Meta02b, 18]. Jede Investition in die IT-Architektur und jede Tätigkeit in diesem Aufgabengebiet sollte folglich der Wertschöpfung dienen [KrSe03, 40].

6.3

Wertbeitrag der IT

Viele Versuche wurden unternommen, um den Beitrag der IT für den Erfolg von Unternehmen nachzuweisen und messbar zu machen [VaZe02, 2]. Bis heute ist der Wertbeitrag der IT nicht präzise definiert und es gibt keine allgemein akzeptierte Best Practice [Step05, 7 und 11]. Nach PORTER generiert die IT als sekundäre, unterstützende Aktivität Wert [Port85, 37 und 125]. VENKATRAMAN erweitert diese Sichtweise und propagiert fünf Stufen, wie IT auf das Geschäft wirken kann [Venk94]. Auf Stufe eins unterstützt die IT funktional das Geschäft und erhöht damit die Produktivität einzelner Aktivitäten. Es folgt die Unterstützung von Geschäftsprozessen auf Stufe zwei durch die Integration von Applikationen und Daten auf Basis einer einheitlichen IT-Infrastruktur. Die Stufen drei und vier führen zu einer Neustrukturierung der Geschäftsprozesse aufgrund der besseren Gestaltungsmöglichkeiten durch die IT. Auf Stufe fünf bestimmt die IT die Ausrichtung des Geschäfts [VaZe02, 11 15; MaSc03, 232 f.].

89

Der EVA ist eine Performancekennziffer zur Unternehmensbewertung und berechnet sich folgenGHUPD‰HQ(9$ 123$7±:$&&[LQYHVWLHUWHV.DSLWDOZREHL NOPAT für Net Operating Profit after Taxes (operativer Gewinn nach Steuern) und WACC für Weighted average Cost of Capital (gewichteter Mittelwert von Fremd- und Eigenkapitalkosten) steht. Ein Unternehmen erwirtschaftet dann einen Wert für Investoren, wenn die Rendite auf das eingesetzte Kapital die Kapitalkosten übersteigt. Multipliziert man diese Überrendite mit dem investierten Kapital, erhält man die jährliche Wertsteigerung bzw. Wertvernichtung eines Unternehmens (EVA).

Wertbeitrag von IT-Architekturen

91

Die Auswirkungen der IT auf das Geschäft lassen sich verschiedenen Wirkungsdimensionen zuordnen. Abbildung 6-2 fasst die Kategorisierung von POTTHOF [Pott98, 10 - 16] und mögliche Ansatzpunkte für die Wirkung von IT zusammen. Strategie und Wettbewerb

Qualität

Flexibilität

Wettbewerbsvorteile durch besondere Produktmerkmale, besondere Servicemerkmale, besondere logistische Merkmale

Höhere Produktqualität durch verbesserte Fertigungs- und Prüfprozesse

Flexibilitätssteigerung durch höhere Anpassungsgeschwindigkeit oder mehr Entscheidungsmöglichkeiten

Produktivität

Kosten

Mitarbeiter

Produktivitätssteigerungen durch Zeiteinsparung bei der Leistungserstellung oder ein verbessertes InputOutput-Verhältnis

Abbildung 6-2

Direkte Kosteneinsparungen dort, wo IT eingesetzt wird. Indirekte Kosteneinsparungen in anderen Unternehmensbereichen. Geringere Kosten innerhalb der IT

Wirkung auf Mitarbeiterzufriedenheit

Ansatzpunkte für Verbesserungen durch IT (Beispiele)

Ähnliche Dimensionen finden sich z. B. bei SHANG und SEDDON [ShSe02, 277], deren Modell auch von PFEIFER angewandt wird [Pfei03, 100 f.]. DAVENPORT, HARRIS und CANTRELL benennen für den Nutzen von ERP-Applikationen u. a. bessere Entscheidungen durch das Management, verbesserten Kundenservice und höhere Kundenbindung, reduzierte Durchlaufzeiten, weniger Personalaufwand und einen höheren Umsatz [DaHC02, 25]. Der Nutzen von IT kann als direkt monetär (z. B. höherer Umsatz durch ein Web-Portal), quantitativ (z. B. Zeiteinsparung durch ein WMS) oder qualitativ (z. B. höhere Kundenbindung durch einen SMS-Benachrichtigungs-Dienst) klassifiziert werden [Pott98, 28]. In der Debatte über den Wert der IT lassen sich zwei Untersuchungsansätze unterscheiden: Die Diskussion um den Wert der IT als Ganzes und die Bestimmung des Wertbeitrags einzelner IT-Projekte. Zu beiden Themen finden sich zahlreiche Veröffentlichungen 90.

90

Eine ausführliche Diskussion der empiriebasierten Veröffentlichungen zum Thema Wertbeitrag der IT findet sich bei [Pfei03, 45 - 93]. Eine Diskussion von Investitionsentscheidungen in ITProjekte mit Fallstudien unternimmt [Pott98, 73 - 124].

92

Wertbeitrag von IT-Architekturen

6.3.1

Wertbeitrag der IT als Ganzes

Die mangelnde Messbarkeit des IT-Nutzens wird als Produktivitätsparadoxon der IT bezeichnet [Pfei03, 14 - 16; PiRe03, 196 - 198; RüSS03, 763]. PFEIFER fasst seine Bestandsaufnahme empirischer Untersuchungen wie folgt zusammen: Ä'DV 3URGXNWLYLWlWVSDUDGR[RQ >«@ EHVWHKW QLFKW ZHLWHU >«@ ,Q GHU *HVDPWEH WUDFKWXQJ]HLJWGLH,7HLQHSRVLWLYHXQGHUKHEOLFKH$XVZLUNXQJDXIGLH/HLVWXQJV IlKLJNHLW YRQ 8QWHUQHKPHQ -HGRFK HUJLEW VLFK HLQH KRKH %DQGEUHLWH GLHVHU $XVZLUNXQJHQ XQG VR QXW]HQ HLQLJH 8QWHUQHKPHQ ,7 ZHVHQWOLFK HIIHNWLYHU DOV DQGHUH³>3IHLI@ Da jedes Unternehmen prinzipiell Zugriff auf dieselben Technologien hat 91, ist deren Management entscheidend für den IT-Wertbeitrag [VaZe02, 4]. PFEIFER identifiziert so genannte ,7:HUWKHEHO und untersucht die Wirkung des IT-Ausgabeverhaltens, der Gestaltung der IT-Organisation (z. B. zentral versus dezentral), der IT-Managementverfahren (z. B. das Management von IT-Investitionen) und der Mitarbeiterführung im IT-Bereich (z. B. Mitarbeiterentwicklung) auf den Unternehmenserfolg [Pfei03, 126 - 129]. Die Gestaltung der IT-Architektur im Rahmen des IT-Architektur-Managements kann als Werthebel interpretiert werden, der den Erfolg oder Misserfolg der IT und damit des Unternehmens entscheidend beeinflusst. ZACHMAN stellt dazu fest: ³>«@ LQ WKH VW &HQWXU\ LW >,7$UFKLWHFWXUH@ ZLOO EH WKH GHWHUPLQLQJ IDFWRU WKH IDFWRUWKDWVHSDUDWHVWKHZLQQHUVIURPWKHORVHUVWKHVXFFHVVIXODQGWKHIDLOXUHV WKHDFTXLULQJIURPWKHDFTXLUHGWKHVXUYLYRUVIURPWKHRWKHUV´>=DFK@ 6.3.2

Wertbeitrag einzelner Investitionsvorhaben

Mehr als 90 Prozent der Unternehmen haben kein Modell, um den Wertbeitrag der IT für das Geschäft zu quantifizieren [Meta02a, 5]. Qualitative und quantitative Verfahren zur Analyse und Beurteilung von Einzelentscheidungen in der IT, ergänzt durch Sensitivitätsund Risikoanalysen, sind jedoch weit verbreitet. Abbildung 6-3 listet die Verfahren auf.

91

Vgl. [Carr03], den Auslöser der sog. Carr-Debatte zum strategischen Nutzen der IT.

Wertbeitrag von IT-Architekturen

93

Allgemeine Ansätze Qualitative Verfahren ‡ 3RUWIROLR0RGHOO ‡ $UJXPHQWHQELODQ] ‡ &KHFNOLVWH ‡ 1XW]HIIHNWNHWWH ‡ 3UR]HVVDQDO\VH ‡ 1XW]ZHUWDQDO\VH ‡ %DODQFHG 6FRUHFDUG

Quantitative Verfahren

Spezifische Ansätze Sensitivitäts- und Risikoanalysen

‡ .ODVVLVFKH ,QYHVWLWLRQV rechnung (ROI, 139,553D\EDFN 3HULRG

‡ $PRUWLVDWLRQV rechnung

‡ 3UR]HVVNRVWHQ rechnung

‡ 6]HQDULRDQDO\VH

‡ 7RWDO&RVWRI 2ZQHUVKLS

‡ 6LPXODWLRQ ‡ 6HQVLWLYLWlWVDQDO\VH ‡ 5LVLNRDQDO\VH

‡ 7RWDO9DOXHRI2SSRUWXQLW\ ‡ 7RWDO(FRQRPLF ,PSDFW ‡ 5(-)UDPHZRUN ‡ $SSOLHG ,QIRUPDWLRQ (FRQRPLFV ‡ 3HUIRUPDQFH 0DQDJHPHQW6FRUHFDUG ‡«

‡ 259HUIDKUHQ

$EELOGXQJ 9HUIDKUHQ]XU,7,QYHVWLWLRQVDQDO\VHXQGHQWVFKHLGXQJ 92

,7,QYHVWLWLRQVHQWVFKHLGXQJHQVROOWHQDXIHLQHU0HWKRGHQNRPELQDWLRQEDVLHUHQ>3RWW@ (QWVSUHFKHQG JLEW HV HLQH 5HLKH YRQ $QVlW]HQ GLH JU|‰WHQWHLOV DOOJHPHLQH 9HUIDKUHQ NRPELQLHUHQ>+LSS@'HUTotal Value of Opportunity792 NRPELQLHUW]%GHQ7&2 PLWTXDOLWDWLYHQ9HUIDKUHQZLHGHU%DODQFHG6FRUHFDUG

6.4

Wirkung der IT-Architektur

'LH ,7$UFKLWHNWXU ZLUNW EHU GLH 0RGHOOLHUXQJ 2UJDQLVDWLRQ XQG 6WHXHUXQJ GHU $SSOLND WLRQVODQGVFKDIWXQGGHU]XJUXQGHOLHJHQGHQ,7,QIUDVWUXNWXUGLUHNWDXIGLH,78QWHUVWW]XQJ GHU*HVFKlIWVSUR]HVVH>/H6$/LX@6LHVWHXHUWGDPLWGHQ:HUWEHLWUDJGHU,7 LP 8QWHUQHKPHQ >+D6:@ 'HU :HUW GHU ,7 ZLUG HQWVFKHLGHQG YRQ GHU ,7$UFKLWHNWXU EHHLQIOXVVW >%RDU@ XQG XPJHNHKUW ]HLJW VLFK GHU :HUW GHU ,7$UFKLWHNWXU LP :HUW GHU IT: Ä7KHYDOXHRI($ 93>«@LVPDQLIHVWHGLQWKHZRUNRIRWKHUV´>0HWDD@ 6.4.1

Effizienz und Effektivität

,Q GHU ,7 EH]LHKW VLFK GLH (IIL]LHQ]QDFK %52*/, DXI GHQ 5HVVRXUFHQYHUEUDXFK ]XU (UVWHO OXQJ HLQHU 2XWSXW(LQKHLW >%URJ@ 'LH ,7.RVWHQ VROOHQ EHL JOHLFK EOHLEHQGHP 2XWSXW PLQLPLHUWZHUGHQ'LHVHU$XIIDVVXQJIROJHQ.(03,6XQG5,1*%(&.GLH,7(IIL]LHQ]DOVGDV WieGHU8QWHUVWW]XQJGHU*HVFKlIWVSUR]HVVHEH]HLFKQHQXQGGLHVHUGLH,7.RVWHQXQGGLH 4XDOLWlWGHU,73URMHNWH]XRUGQHQ>.5$%@'LH,7(IIHNWLYLWlWEHVFKUHLEWLQZLHZHLWGLH (UZDUWXQJHQ GHU *HVFKlIWVEHUHLFKH DQ GLH ,7 HUIOOW ZHUGHQ >.DUQD@ (QWVSUHFKHQG ZLUG GHU JHQHULHUWH :HUW DXV 6LFKW GHV *HVFKlIWVEHUHLFKV XQDEKlQJLJ YRP HUIRUGHUOLFKHQ 0LWWHOHLQVDW] EHWUDFKWHW >+HLQ 0HWDE@ %HL GHU ,7(IIHNWLYLWlW JHKW HV GDUXP

92 93

 9HUlQGHUWEHUQRPPHQDXV>+LSS3RWW@ ($ VWHKW IU (QWHUSULVH $UFKLWHFWXUH XQG HQWVSULFKWKLHU GHP LQ YRUOLHJHQGHU $UEHLW YHUZHQGHWHQ ,7$UFKLWHNWXU

94

Wertbeitrag von IT-Architekturen

ÄZLH IXQNWLRQDO GLH HLQ]HOQHQ 6\VWHPH VLQG ZLH YHUIJEDU XQG LQ ZHOFKHP 0D‰H VLH WDW VlFKOLFKJHQXW]WZHUGHQ³ [KRAB98, 17], also das :RIU der IT-Unterstützung [KRAB98, 7]. Die Erhöhung der IT-Effizienz bedeutet, die Kosten für IT-Leistungen so weit wie möglich zu senken oder die IT-Leistungen bei gleich bleibenden Kosten zu erhöhen. Eine zunehmende IT-Effektivität wird durch die bessere Abdeckung der Anforderungen der Geschäftsbereiche durch die IT erreicht [JoHA02, 6; VaZe02, 7]. 6.4.2

Einfluss der IT-Architektur

Die IT-Architektur plant und steuert die Struktur der IT in der Organisation [Dern03, 18] mit dem generellen Ziel, die IT-Kosten zu reduzieren und die Qualität der IT zu erhöhen [MSTI03, 38]: Ä>«@YDOXHIURPDQ($SHUVSHFWLYHLVWKHFRPELQDWLRQRIERWKLPSURYHGILQDQFLDO HIILFLHQF\DQGLPSURYHGEXVLQHVVSHUIRUPDQFH³>0HWDE@ Abbildung 6-4 zeigt den Zusammenhang zwischen der Qualität der IT-Architektur und dem Unternehmenserfolg. Die IT-Architektur wirkt auf die IT-Effizienz und -Effektivität. Effizienzverbesserungen äußern sich in reduzierten Kosten bei gleich bleibender ITLeistung. Das eingesparte Budget kann entweder direkt den Gewinn des Unternehmens erhöhen oder in Maßnahmen zur Verbesserung der IT-Effektivität investiert werden. Im ersten Fall sinkt das IT-Budget, im zweiten Fall bleibt es gleich hoch. IT-Architektur

organisiert

Applikationen IT-Leistung

Beispiele: ‡ :HQLJHU/L]HQ]NRVWHQ ‡ :HQLJHU6XSSRUWNRVWHQ ‡ :HQLJHU%HWULHEVNRVWHQ ‡ 6FKQHOOHUH,7(QWZLFNOXQJ ‡ +|KHUH4XDOLWlWLP%HWULHE

Abbildung 6-4

Geschäft

Direkte Unterstützung der Prozessleistung durch IT

IT-Effektivität (IT-Einsatz verbessern) Frei werdendes Budget

ArchitekturQualität

Beispiele: ‡ 8PIDVVHQGHUH ,78QWHUVWW]XQJ der Geschäftsprozesse ‡ (OLPLQLHUHQYRQ5HGXQGDQ]HQLQ der IT-Unterstützung

unterstützen

IT-Effizienz

Prozessleistung Direkte Unterstützung des Unternehmenserfolgs durch Prozessleistung

Unternehmenserfolg

Mehr Gewinn

(IT-Kosten senken)

Wirkung der IT-Architektur auf die IT-Leistung 94

Eine Verbesserung der IT-Effektivität äußert sich in einer höheren Prozessleistung. Ein WMS verkürzt die Durchlaufzeiten und verringert die Fehlerhäufigkeit z. B. im Prozess 94

Teile verändert übernommen aus [KRAB98, 17].

Wertbeitrag von IT-Architekturen

95

Rechnungseingangsprüfung. Dieser Prozess kann dadurch mit weniger Personal durchgeführt werden und die Beschwerden von Zulieferern gehen aufgrund der geringeren Fehlerquote zurück. Die Einsparungen im Personal äußern sich in einem höheren Unternehmensgewinn, die Zuliefererzufriedenheit führt zu höheren Verhandlungsspielräumen und somit ebenfalls zu einem höheren Unternehmensgewinn. IT-Effizienz und IT-Effektivität sind somit nicht unabhängig voneinander. Eine höhere ITEffizienz führt durch reduzierte IT-Kosten nicht unbedingt zu mehr Gewinn für das Unternehmen, sondern lässt sich alternativ in eine höhere IT-Effektivität transformieren (vgl. Abbildung 6-5). Die IT-Kosten können in Kosten für den IT-Betrieb (nicht-wahlfreie Kosten) und Kosten für Innovationen in Form von IT-Projekten (wahlfreie Kosten) eingeteilt werden [JaPr02, 1566 f.; JoHA02, 3 f.], wobei erstere bis zu 80 Prozent des IT-Budgets ausmachen (vgl. Abschnitt 1.1). Viele Unternehmen erwarten durch die zunehmende Komplexität der IT einen Anstieg der nicht-wahlfreien Ausgaben [JaPr02, 1561]. Gleichzeitig werden bei Einsparungsmaßnahmen meist die Investitionen für IT-Projekte gekürzt, was zu einer Überalterung der IT und weiter ansteigenden Betriebskosten (z. B. durch höhere Wartungskosten) führt. Da notwendige Änderungen der IT nicht durchgeführt werden, wird die IT unflexibel und die Unterstützung der Geschäftsprozesse verschlechtert sich [PfHo03]. In dieser Investitionsfalle [MSBA02, 9; JaPr02, 1560] sehen sich nach einer GARTNER-Studie 72 Prozent der IT-Verantwortlichen [Thol05b]. Ermöglicht die IT-Architektur z. B. durch unternehmensweite Standardisierung der IT niedrigere IT-Betriebskosten und IT-Projektkosten (höhere ITEffizienz), wird IT-Budget für neue Projekte frei [PfHo03; BuES04, 10]. IT-Projekte zur Modernisierung der IT, zur Entwicklung neuer Fähigkeiten oder für Effizienzsteigerungen werden über voraus gegangene IT-Kosteneinsparungen erst finanzierbar (höhere ITEffektivität) [JaPr02, 1566 f.; JoHA02, 3 f.; Rost03, 2; BuES04, 110].

96

Wertbeitrag von IT-Architekturen

Verbesserung durch IT-Architektur-Management

Ist-Situation

IT-Projekt 1

Zusätzliche IT-Projekte

IT-Projekt 2 IT-Projekt n

Einsparungen in Projekten

IT-Projekt 2 IT-Projekt n

65%*

IT-Betrieb

IT-Projekt 1

Einsparungen im Betrieb

50%* IT-Betrieb

* Werte beispielhaft

IT-Budget

Abbildung 6-5

IT-Budget

Wertbeitrag des IT-Architektur-Managements

Das frei werdende Budget durch Einsparungen im IT-Betrieb und bei den Projektkosten wird im Beispiel aus Abbildung 6-5 für zusätzliche IT-Projekte eingesetzt. Dieses Budget könnte ebenso dazu dienen, die Gesamtkosten der IT zu senken. Die flexible Anpassung der IT an geänderte Anforderungen aus den Geschäftsprozessen ist oft entscheidend zur Erzielung eines hohen Wertbeitrags. Die Flexibilität der IT gilt als einer der Haupteinflussfaktoren auf die Reaktionsgeschwindigkeit des Geschäfts selbst: Ä,QWURGXFLQJDQHZSURGXFWRUVHUYLFHDGGLQJDQHZFKDQQHOSDUWQHURUWDUJHWLQJ D QHZ FXVWRPHU VHJPHQW ± DQ\ RI WKHVH FDQ SUHVHQW XQIRUHVHHQ FRVWV FRP SOH[LWLHV DQG GHOD\V LQ D EXVLQHVV WKDW UXQV HQWHUSULVH DSSOLFDWLRQV 7KH H[ SHQVH DQG GLIILFXOW\ FDQ EH VR JUHDW WKDW VRPH FRPSDQLHV DEDQGRQ QHZ EXVLQHVVLQLWLDWLYHVUDWKHUWKDQDWWHPSWRQHPRUHFKDQJHWRWKHLUHQWHUSULVHDS SOLFDWLRQV´>%U+D@ Derzeit dauern viele Änderungen in der IT zu lange, sind zu teuer oder können nicht umgesetzt werden [LaMS03]. Insbesondere die starke Fragmentierung der Technologien und die Trägheit durch hohe Komplexität gelten als Hinderungsgrund für eine flexible IT [SaWi03, 500]. Die Qualität der IT-Architektur ist damit ausschlaggebend für die Flexibilität der IT [KrSe03, 46; Ross03a, 1]. Die Flexibilität der Geschäftsprozesse und damit der IT wird immer wichtiger, da veränderte Wettbewerbsbedingungen eine höhere Anpassungsfähigkeit von Unternehmen verlangen [PiRe03, 4] 95. Diese Flexibilität gilt zunehmend als

95

Vgl. dazu auch [GlBH01, 13; Mert04; SaWi03, 498 f.; Youn03b, 1].

Wertbeitrag von IT-Architekturen

97

Wettbewerbsfaktor [KrSe03, 45]. Das IT-Architektur-Management reduziert die Komplexität der IT-Architektur und erhöht damit die Flexibilität in der IT-Unterstützung. Abbildung 6-6 fasst die Wirkung auf den Wertbeitrag zusammen. Verbesserung durch IT-Architektur-Management

Ist-Situation

Wertbeitrag Gewinn Gewinn Wertbeitrag Prozesskosten Höhere IT-Effektivität Prozesskosten IT-Kosten Höhere IT-Effizienz

Unternehmensumsatz

Abbildung 6-6

IT-Kosten

Unternehmensumsatz

Monetäre Effekte der IT-Architektur 96

Eine Verbesserung der IT-Effektivität verspricht Effektivitäts- und Effizienzsteigerungen in den Geschäftsprozessen, d. h. geringere Kosten und höhere Umsätze in den Prozessen [BuES04, 10 f.]. Der Wertbeitrag der besseren Organisation der IT durch die IT-Architektur besteht in dem Potenzial, die IT-Kosten zu senken, durch eine höhere IT-Effektivität die Kosten der Geschäftsprozesse zu verringern und die Produktivität der Geschäftsprozesse durch eine bessere IT-Unterstützung zu erhöhen. Der in Abbildung 6-6 größer eingezeichnete Teil des Wertbeitrags reduziert somit Kosten, der kleiner eingezeichnete erhöht den Umsatz und damit (bei einer positiven Umsatzrendite) auch den Gewinn des Unternehmens.

6.5

Bestimmung des Wertbeitrags

Während die Geschäftsbereiche die lokalen 97 Kosten der IT-Architektur bestimmen können [BiVa03, 149 - 151] und sich auch die Kosten der Planung der IT-Architektur z. B. in Form von Personentagen bestimmen lassen, kann der Wertbeitrag einer IT-Architektur nicht einfach isoliert berechnet werden [Nunn03, 1; BiVa03, 148]. Bei TOGAF heißt es dazu:

96 97

Verändert übernommen aus [BuES04, 11]. Lokale Kosten sind diejenigen Kosten, die direkt im Geschäftsbereich anfallen.

98

Wertbeitrag von IT-Architekturen

Ä7KHYDOXHRIDWHFKQLFDODUFKLWHFWXUHLVLPPHDVXUDEOHDQGWKHFRVWE\FRPSDUL VRQ>«@LVWULYLDO³>2SHQ@ Insbesondere die Verbesserungen der IT-Effektivität sind schwierig zu messen [Meta02b, 18]. Die Gründe für die Schwierigkeiten bei der Bestimmung des Wertbeitrags von IT-Architekturen sind [Kaib02, 37; PiRe03, 199; Hube99, 111]:

6.5.1

x

Abstand zur Wertschöpfung (Abschnitt 6.5.1)

x

Messung des Wertbeitrags (Abschnitt 6.5.2)

x

Ganzheitlichkeit/ Zurechnung (Abschnitt 6.5.3)

x

Datenbeschaffung (Abschnitt 6.5.4)

x

Prognoseproblem (Abschnitt 6.5.5)

x

Zeitliche Verzögerung (Abschnitt 6.5.6)

Abstand zur Wertschöpfung

Die Geschäftsprozesse eines Unternehmens werden von der IT durch Applikationen unterstützt. Diese sind nur selten unmittelbar an der Wertschöpfung beteiligt [VaZe02, 4]. Der Wert der IT ist damit von dem unterstützten Geschäftsprozess abhängig. Eine unmittelbare Zuordnung des monetären Nutzens einer Applikation ist zumeist nicht möglich. Eine CRMApplikation z. B. unterstützt etliche Geschäftsprozesse und die Datenbestände dienen wiederum anderen Applikationen (z. B. der Applikation zur Steuerung von Werbemaßnahmen). 6.5.2

Messung des Wertbeitrags

Die Messung des Wertbeitrags der IT im Ganzen, aber auch einzelner Projekte, ist für ein Unternehmen nicht trivial (vgl. Abschnitt 6.3). Da die IT-Architektur indirekt über die Applikationen auf die Geschäftsprozesse wirkt, ist deren Nutzenmessung von der Messung des Beitrags der IT abhängig. 6.5.3

Ganzheitlichkeit/ Zurechnung

Wenn die IT-Architektur die IT verändert, ändern sich meist auch (gewollt) die Ablauf- und Aufbauorganisation eines Unternehmens [Kaib02, 37]. Der daraus entstehende Nutzen kann dann nicht mehr nur der IT-Architektur zugeordnet werden, da man auch den geänderten Rahmenbedingungen Rechnung tragen muss [ReBa95, 118]. IT-Architektur wirkt übergreifend auf das Unternehmen und entsprechend wird der Mehrwert unternehmensweit verteilt [Liu02, 15; ReBa95, 118; Step05, 10; KrSe03, 111], was dessen Lokalisierung erschwert: Ä0LW]XQHKPHQGHU5HLFKZHLWHHLQHU,7$UFKLWHNWXUZLUGGLH%HUHFKQXQJ>«@VR PLWLPPHUVFKZLHULJHU³>%L9D@

Wertbeitrag von IT-Architekturen

99

Ein Nutzen ist oftmals auch mehreren Maßnahmen zuzuordnen [Meta02b, 18]. Außerdem entstehen die Kosten meist an anderer Stelle als der Nutzen, z. B. in verschiedenen Geschäftsbereichen [Kaib02, 37], so dass kein direkter Zusammenhang zwischen Kosten und Nutzen hergestellt werden kann [Jone03, 4; MSTI03, 38; KrSe03, 111]. Erschwert wird die Zurechnung durch opportunistisches Verhalten und damit dem Risiko von Subjektivität in der Beurteilung [Broa05; Nunn03, 5; ReBa95, 118]. Ein Netz komplexer Wirkungszusammenhänge (z. B. das Multifaktoren- [Hube99, 113] und Situationsproblem [PiRe03, 199] zwischen verschiedenen IT-Projekten (Verbundproblematik) [Kaib02, 37]), dem davon abhängigen Nutzen der IT-Architektur [ReBa95, 118] und externen Einflüssen (z. B. das Marktwachstum) macht es damit schwierig, den Nutzen einzelnen IT-Projekten bzw. der gesamten IT-Architektur zuzuordnen. 6.5.4

Datenbeschaffung

Der Nutzen der IT-Architektur wirkt geschäftsbereichsübergreifend (vgl. Abschnitt 6.4.2). Entsprechend sind unternehmensweite Kennzahlen zu identifizieren [BiVa03, 148]. Die Datenbeschaffung ist schwierig, da für die IT selten ein unternehmensweites Berichtswesen besteht [LeSA04, 236] und insbesondere für die IT-Architektur nur wenige oder keine Kennzahlen vorliegen. 6.5.5

Prognoseproblem

Das Potenzial von IT-Projekten für das Geschäft ist oft nicht klar, da sich später zusätzliche Einsatzfelder ergeben können [Kaib02, 38; RüSS03, 768; PiRe03, 199]. Die Wirkung der ITArchitektur ist nicht genau bekannt und viele Wirkungen sind schwer vorauszusagen [Wagl98, 132; Jone03, 4]. Um die Gefahr einer Fehleinschätzung zu vermeiden, äußert sich der IT-Bereich eher zurückhaltend und der Nutzen wird als zu gering eingestuft [Hube99, 112]; geplante Einspareffekte werden andererseits manchmal nicht wie geplant erreicht [KrSe03, 111; BoLT00, 44]. 6.5.6

Zeitliche Verzögerung

Die Wirkung von Maßnahmen in der IT-Architektur tritt oft mit einer zeitlichen Verzögerung ein [Nunn03, 5; Lope02, 2; Meta02b, 18]. Insbesondere bei IT-Architektur-Projekten sind die Vorteile zumeist nicht kurzfristig zu realisieren und eine Nutzenermittlung wird entsprechend behindert [Wood04, 73; Kaib02, 37; Liu02, 15].

6.6

Vorhandene Bewertungsansätze

Untersuchungen zum Wertbeitrag der IT liegen zahlreich vor. Nur wenige Ansätze beschäftigen sich jedoch mit dem Wert der IT-Architektur [Saha04, 12]. Im Folgenden werden drei Ansätze kurz vorgestellt und bewertet. 6.6.1

Ansatz von Principia

Der Ansatz von PRINCIPIA [Prin03] beschreibt die in Abbildung 6-7 gezeigten Aktivitäten.

100

Wertbeitrag von IT-Architekturen

Verständnis für IT-Architektur herstellen

Abbildung 6-7

Strategischen Nutzen identifizieren

Spezifische Business Cases identifizieren

Interessensgruppen adressieren

Kosten und Nutzen berechnen

Projekte mit großem Nutzen aufzeigen

Ansatz von PRINCIPA

Zuerst etabliert man ein einheitliches Verständnis für den Begriff der IT-Architektur und entwickelt eine IT-Architektur-Strategie. Im zweiten Schritt wird der (strategische) Nutzen der IT-Architektur identifiziert (z. B. geringere IT-Kosten, höhere Flexibilität usw.). Für jedes Verbesserungspotenzial der IT-Architektur ist ein Business Case zu generieren und wo möglich die Auswirkung auf Kennzahlen des Geschäfts zu zeigen [Nunn03, 14 und 16; Jone03, 15]. Die identifizierten Nutzenpotenziale sollen bestimmte Interessensgruppen des Unternehmens, z. B. Führungskräfte oder Mitarbeiter des IT-Bereichs, adressieren [Ross04, 4; Ross03a, 2 - 4]. Soweit möglich wird anhand des durch IT-Architektur generierten Nutzens und deren Kosten ein ROI berechnet. Insbesondere sollte nach PRINCIPIA mit leicht verständlichen Nutzenpotenzialen im Hinblick auf Effizienz- und Prozessverbesserungen sowie strategischen Vorteilen argumentiert werden. 6.6.2

Ansatz von Leser, Scheibehenne und Alt

Den Ansatz der Deutschen Telekom AG stellen LESER, SCHEIBEHENNE und ALT vor [LeSA04, 233 - 253]. Im Prozess der Zielfindung (vgl. Abbildung 6-8) werden aus Anforderungen an die IT-Architektur Erfolgsfaktoren abgeleitet. Prozess 1: Zielfindung

Erfassung der Anforderungen

Ableitung der Erfolgsfaktoren

Erhebung des aktuellen Status bzgl. der Erfolgsfaktoren

Definition der Zielsetzungen und Maßnahmen

Erhebung des qualitativen Nutzens

Absichtserklärung

Erstellung eines Wirkungsnetzwerks

Erfassen des aktuellen Status bzgl. der Führungsgrößen

Abschätzung der Potenziale der Maßnahmen

Erstellen von Zahlungsreihen

Prozess 2: Potenzialanalyse Zuordnen von Gestaltungsobjekten zu den Anforderungen

Abbildung 6-8

Ableitung von Führungsgrößen

Architekturentscheid herbeiführen

Ansatz von LESER, SCHEIBEHENNE und ALT 98

Die Anforderungen an die IT-Architektur werden in einem oder mehreren Workshops erhoben. Nach Ableitung der Erfolgsfaktoren der IT-Architektur im Unternehmen werden bestehende Aktivitäten zur Verbesserung der IT-Architektur an den Erfolgsfaktoren bewertet. Zur Erfüllung der Anforderungen werden IT-Architektur-Projekte definiert und diesen (methodisch nicht näher spezifiziert) ein Nutzen in den Dimensionen Kosten, Zeit und Qualität zugewiesen.

98

Verändert übernommen aus [LeSA04, 239].

Wertbeitrag von IT-Architekturen

101

Im zweiten Prozess wird das Nutzenpotenzial dieser IT-Architektur-Projekte bestimmt. Dazu werden den Anforderungen Gestaltungsobjekte der IT-Architektur, z. B. Prozesse oder Applikationen, zugeordnet und jeweils so genannte Führungsgrößen als messbare Merkmale abgeleitet, anhand derer die Erfüllung der Anforderungen gemessen werden kann. Führungsgrößen sind z. B. Anzahl nicht zufriedenstellend durch IS unterstützter Prozessinstanzen, Einsparung durch Wiederverwendung von Lösungen oder Time-toMarket zur Erfüllung neuer Anforderungen. Die Nutzenpotenziale und Führungsgrößen werden in einem Wirkungsnetzwerk zusammengeführt und quantifiziert (vgl. Abbildung 6-9).

Abbildung 6-9

Wirkungsnetzwerk 99

Das Wirkungsnetzwerk ist in eine Matrix mit den Dimensionen Nutzenpotenziale (Kosten, Zeit, Qualität) und IT-Prozesse (Planung, Entwicklung, Produktion und Business Alignment 100) strukturiert [HaSW04, 63]. Die Führungsgrößen werden mit Ist- und Soll-Zahlen, die durch die identifizierten Maßnahmen erreicht werden sollen, belegt und eine Veränderung der Gesamtkosten der IT-Prozesse und des Unternehmensumsatzes bestimmt. Entsprechend der Differenz der Ergebnisse ergibt sich der Nutzen der IT-ArchitekturProjekte.

99 100

Übernommen aus [LeSA04, 245]. Warum Business Alignment als IT-Prozess bezeichnet wird ist ebenso wie die Quantifizierung des Zusammenhangs der Führungsgrößen mit qualitativen Nutzendimensionen (z. B. Wiederverwendung, Flexibilität, Transparenz) unklar.

102

6.6.3

Wertbeitrag von IT-Architekturen

Ansatz von Birkhölzer und Vaupel

BIRKHÖLZER und VAUPEL unterscheiden zwischen der IT-Architektur als Ganzes und den einzelnen Bestandteilen ebendieser [BiVa03, 147 - 154]. Übertragen auf die vorliegende Arbeit sind Bestandteile der IT-Architektur u. a. Applikationen und Technologien. Für die ITArchitektur als Ganzes geben die Autoren keine Methode zur Wertbestimmung an. Für die einzelnen Bestandteile erfolgt eine so genannte Preisbildung. Jedem Nutzer eines Bestandteils der IT-Architektur wird dazu ein Kundenwert zugewiesen 101. Die Konsolidierung von Datenbanktechnologien nutzt z. B. dem Rechenzentrum (der Betrieb wird günstiger) und allen Applikationen, die aufgrund der einheitlichen Technologie einfacher Daten austauschen können. Der Nutzen eines IT-Architektur-Projekts wird quantifiziert und auf die Nutzer verteilt, so dass ein Preis entsteht. Falls kein Preis bestimmt werden kann (z. B. da der Nutzen geringer als die Kosten ist), ist das IT-Architektur-Projekt nicht wirtschaftlich und damit abzulehnen. Die unternehmensweiten Vorteile durch IT-Architekturen bleiben bei der Einzelbetrachtung von IT-Architektur-Projekten in diesem Ansatz unberücksichtigt. 6.6.4

Bewertung

Im Wesentlichen fehlt beim ersten und dritten Ansatz eine methodische Herleitung der Nutzenpotenziale aus qualitativer und quantitativer Sicht. Bei allen Vorgehensweisen erfolgt eine Operationalisierung nur andeutungsweise oder gar nicht, so dass letztendlich die Herleitbarkeit der Ergebnisse nicht immer nachvollziehbar ist. Die Bewertung der Ansätze zeigt Tabelle 6-1.

101

Wie dies genau erfolgen soll, wird nicht beschrieben.

Bewertungskriterium

Pr in ci pi a

Ansatz

B un irkh d öl Va ze up r el

103

L Sc ese un he r, d ibe A h l t en ne

Wertbeitrag von IT-Architekturen

Relativer Aufwand des Verfahrens

+

±

o

Einfache Nachvollziehbarkeit des Verfahrens

+

±

±

Kontinuierliche Analyse möglich

±

+

±

Methodische Herleitung qualitativer Nutzenaspekte

o

+

o

Methodische Herleitung quantitativer Nutzenaspekte

o

+

±

Erfassung der IT-Architektur-Kosten

±

±

+

Abbildung von Abhängigkeiten zwischen Nutzenpotenzialen

±

o

±

Beispielhafte Operationalisierung

±

o

±

Legende: + Positive Beurteilung / o Keine Aussage / ± Negative Beurteilung

Tabelle 6-1

Bewertung von Ansätzen zur Bemessung des Nutzens von IT-Architektur-

Maßnahmen

Der relative Aufwand des Verfahrens wird positiv bewertet, wenn der Aufwand geringer als bei den anderen Verfahren ist. Bei der Abbildung von Abhängigkeiten zwischen Nutzenpotenzialen erfolgt eine negative Bewertung, wenn die Abhängigkeiten keine Berücksichtigung finden.

6.7

Kennzahlen

Die Entwicklung der Effizienz und Effektivität der IT im Unternehmen ohne und mit ITArchitektur-Management zeigt den Wertbeitrag der IT-Architektur auf [GlBH01, 6; Prin03; Meta02b, 20; CEB01, 32 f.; Wagl98, 132; Hubb97, 3]. Ohne bedeutet dabei eine Fortführung der aktuellen IT-Architektur ohne explizites IT-Architektur-Management, d. h. die ITArchitektur entsteht implizit und wird nicht mit den in Kapitel 3 beschriebenen Modellen explizit geplant. Mit IT-Architektur-Management meint die Definition von konkreten Zielen (Gestaltungsziele, IT-Architektur-Maßnahmen, IT-Architektur-Standards usw.) anhand derer die Soll-IT-Architektur entwickelt wird. Abbildung 6-10 visualisiert, wie sich der Wertbeitrag der IT-Architektur mit und ohne IT-Architektur-Management entwickelt.

Wertbeitrag von IT-Architekturen

6.7.1

105

Reifegradmodell für die IT-Architektur

Der Nutzen einer IT-Architektur hängt insbesondere von ihrer strukturellen Gestaltung ab. Entsprechend spielen in den folgenden Abschnitten so genannte Gestaltungsziele eine entscheidende Rolle. Durch eine Änderung der Gestaltung der IT-Architektur im Rahmen des IT-Architektur-Managements wird ein Nutzen generiert. Um die Gestaltung der ITArchitektur zielgerichtet verändern zu können, ist ein gewisser Reifegrad im Umgang mit der IT-Architektur notwendig. Reifegradmodelle (so genannte Capability Maturity Models) sind ein Ansatz zur Verbesserung von Prozessen und Fähigkeiten durch deren Bewertung in mehreren aufeinander aufbauenden Stufen [CaMe05]. Reifegradmodelle der ITArchitektur bewerten die Reife des IT-Architektur-Managements eines Unternehmens [Nasc03, 4]. Diese wird anhand der IT-Architektur-Prozesse, IT-Architektur-Strategie, Dokumentation der IT-Architektur, IT-Architektur-Governance und IT-Architektur-Kommunikation gemessen 102 (vgl. Tabelle 6-2 und Tabelle 6-3). Der Wertbeitrag der IT-Architektur kann umso höher ausfallen, je höher der Reifegrad der genannten Kriterien im Unternehmen ausgeprägt ist. Kriterium

Beschreibung

/HYHO±,QLWLDO

/HYHO±8QGHU'H YHORSPHQW

IT-Architektur-

Durch die Prozesse wird sichergestellt, dass die ITArchitektur geplant, weiterentwickelt und umgesetzt wird. Mit den Modellen Bebauungsplan und ITInfrastruktur bilden diese die Grundlage für das ITArchitektur-Management.

Die IT-Architektur-Prozesse sind in einzelnen ITAbteilungen der Geschäftsbereiche definiert. Dies geschieht überwiegend ad hoc und teilweise inkonsistent ohne unternehmensweite Abstimmung.

Die grundlegenden ITArchitektur-Prozesse sind unternehmensweit definiert, aber nur zum Teil umgesetzt. An der Umsetzung wird gearbeitet.

IT-Architektur-Modelle strukturieren und beschreiben die IT-Architektur.

Die Modelle werden nur lokal innerhalb der zentralen IT-Abteilung genutzt. Die Informationsgrundlage ist bruchstückhaft.

Die Modelle sind unternehmensweit eingeführt. Die Informationsgrundlage ist bruchstückhaft, wird aber laufend verbessert. Die Modelle unterstützen teilweise Entscheidungen im IT-ArchitekturManagement.

Prozesse [Open03; Nasc03, 8 - 13; Ross04, 3;

BoLT00, 46]

IT-ArchitekturModelle

(IT-Infrastruktur, IT-Bebauungs plan) [Boar01, 56 - 58]

102

Weiterführende Literatur zu IT-Architektur-Reifegradmodellen findet sich z. B. bei [FEA03], [Nasc03] oder [Open03].

106

Wertbeitrag von IT-Architekturen

Kriterium

Beschreibung

/HYHO±,QLWLDO

/HYHO±8QGHU'H

IT-ArchitekturStrategie

Die IT-Architektur-Strategie definiert die Soll-ITArchitektur und legt Regeln für die Erreichung der SollIT-Architektur fest.

Die IT-Architektur-Strategie existiert rudimentär in Einzelaussagen für spezifische Themen der ITArchitektur.

Eine übergreifende ITArchitektur-Strategie wird entwickelt. Es existieren erste übergreifende Prinzipien und ITArchitektur-Regeln. ZielArchitektur und Migrationsplan werden in Teilen erarbeitet.

Entscheidend für die Umsetzung einer geplanten ITArchitektur ist die Kommunikation ihrer Inhalte und ihres Nutzens an die Geschäftsleitung und die Geschäftsbereiche.

Die Notwendigkeit der Kommunikation wurde erkannt. Die vorhandene ITArchitektur-Dokumentation ist lokal auf Abruf verfügbar, wird aber nicht aktiv kommuniziert.

Ein erster Kommunikationsprozess ist angedacht. Die IT-ArchitekturDokumentation ist zentral, z. B. über das Intranet, verfügbar.

Die Umsetzung der ITArchitektur hängt davon ab, inwieweit sich IT-Projekte an IT-Architektur-Vorgaben wie Standards und ITArchitektur-Prozesse halten und wie Abweichungen gehandhabt werden.

Konformität wird als wichtig erachtet, aber nur sporadisch und unstrukturiert erfasst. Die Durchsetzung ist unklar.

Ein Prozess zur Bestimmung der Konformität von IT-Projekten wird entwickelt, um sicherzustellen, dass die IT-Projekte konform zur IT-Architektur sind.

YHORSPHQW

[Zysk02; Boar01, 56 - 58]

Kommunikation

[Open03; Nasc03, 8 - 13; Boar01, 56 - 58; Nunn03, 15; ArKL99, 35; BoLT00, 43 - 47] Konformität von IT-Projekten

[Nasc03, 8 - 13; Zysk02]

Tabelle 6-2

Reifegradmodell für das IT-Architektur-Management (Level 1 und 2)

Kriterium

/HYHO±'HILQHG

/HYHO±0DQDJHG

/HYHO±2SWLPL]LQJ

IT-ArchitekturProzesse

Die IT-Architektur-Prozesse sind detailliert definiert und umgesetzt. Sie werden größtenteils eingehalten.

Die IT-Architektur-Prozesse sind fester Bestandteil der übrigen Unternehmensprozesse. Die Qualität der Prozesse wird anhand von Metriken gemessen.

Die IT-ArchitekturProzesse werden kontinuierlich verbessert.

IT-ArchitekturModelle

Die IT-Architektur-Modelle werden übergreifend im ITArchitektur-Management verwendet. Der Ist-Zustand ist soweit erforderlich erhoben.

Die IT-Architektur-Modelle sind fester Bestandteil des IT-Architektur-Managements und werden kontinuierlich auf den neuesten Stand gebracht und Metriken werden entwickelt.

Die Qualität der ITArchitektur-Modelle wird strukturiert erfasst und diese werden kontinuierlich verbessert.

Wertbeitrag von IT-Architekturen

107

Kriterium

/HYHO±'HILQHG

/HYHO±0DQDJHG

/HYHO±2SWLPL]LQJ

IT-ArchitekturStrategie

Ziel- und Soll-Architektur sind auf Basis der Geschäfts- und ITAnforderungen definiert und werden sporadisch angepasst. Ein Migrationsplan definiert gezielt IT-Projekte.

Ziel- und Soll-Architektur werden in einem formellen Prozess kontinuierlich an Veränderungen der Geschäfts- und ITAnforderungen angepasst. Die Erfüllung der Anforderungen im Rahmen der Migration wird mit Metriken überprüft.

Der Prozess zur Entwicklung der IT-ArchitekturStrategie und die Ausrichtung der IT-ArchitekturStrategie an den Geschäfts- und ITAnforderungen werden kontinuierlich verbessert.

Kommunikation

Die IT-Architektur ist definiert und deren Dokumentation wird aktiv und verständlich an die Geschäftsbereiche kommuniziert. IT-ArchitekturTrainings finden statt. Die IT-ArchitekturDokumentation wird sporadisch auf den neuesten Stand gebracht.

Die IT-ArchitekturDokumentation wird kontinuierlich angepasst und zielgruppenspezifisch kommuniziert. Die Qualität, Verständlichkeit und Wirksamkeit der Kommunikation wird gemessen.

Die IT-ArchitekturDokumentation wird bei jeder IT-bezogenen Entscheidung in der Organisation mit einbezogen. Der Kommunikationsprozess wird ständig überwacht und verbessert.

Konformität von IT-Projekten

Ein formaler Prozess zur Bewertung der Konformität ist übergreifend eingeführt und fester Bestandteil der IT-Architektur-Prozesse. Abweichungen von der ITArchitektur müssen begründet werden.

Die Konformität wird bei jedem Projekt bestimmt. Dies erfolgt objektiv über Kennzahlen. Die Qualität des Prozesses der Konformitätsmessung wird verfolgt.

Informationen aus der Bestimmung der Konformität werden für Aktualisierungen der ITArchitektur-Standards genutzt. Der Prozess Durchsetzung der Konformität wird kontinuierlich verbessert.

/HYHO±1RQH

Über alle Kategorien sind keine Aktivitäten im IT-Architektur-Management zu verzeichnen.

Tabelle 6-3

Reifegradmodell für das IT-Architektur-Management (Level 0 und 3 - 5)

Die verschiedenen Reifegrade können mit Kennzahlen weiter detailliert und überwacht werden. Beispiele sind Durchschnittliche Dauer zur Errechnung des Kostenaufschlags für ein nicht konformes IT-Projekt oder Anzahl architekturkonforme IT-Projekte [Nunn03, 16]. Im Folgenden wird insbesondere auf die Gestaltung der IT-Architektur mithilfe von ITArchitektur-Modellen unter Einhaltung einer IT-Architektur-Strategie eingegangen. Ein minimaler Reifegrad von 3 - Defined für die Dokumentation der IT-Infrastruktur, die Dokumentation der IT-Bebauung sowie für die IT-Architektur-Strategie wird als grundlegende Voraussetzung angenommen. Die Einführung der IT-Architektur-Modelle und das Erarbeiten einer IT-Architektur-Strategie generiert, wie in Kapitel 6.7.3 gezeigt wird, auch ohne weitere Maßnahmen bereits einen Mehrwert. Ziel der IT-Architektur ist dabei die Bereitstellung von Modellen für einen ganzheitlichen Überblick und eine höhere Nachvollziehbarkeit im Hinblick auf die Zusammenhänge der IT [Krcm05, 41].

108

6.7.2

Wertbeitrag von IT-Architekturen

Gestaltungsziele der IT-Architektur

Den IT-Architektur-Modellen kommen zwei Aufgaben zu: Sie ÄXQWHUVWW]HQGLH$QDO\VHXQG *HVWDOWXQJ NRPSOH[HU EHWULHEOLFKHU 6\VWHPH $OV %HVFKUHLEXQJVPRGHOOH HUIDVVHQ VLH GLH ,VW6LWXDWLRQHLQHV8QWHUQHKPHQVDOV*HVWDOWXQJVPRGHOOHGLHQHQVLHQRUPDWLYDOV9RUODJH IU VHLQH *HVWDOWXQJ³ [Sinz04]. Die in den Abschnitten 6.7.2.1 und 6.7.2.2 beschriebenen Gestaltungsziele zeigen auf, welche Ergebnisse die Soll-IT-Architektur verfolgt. Eine der Aufgaben der zentralen IT-Abteilung ist es, diese Ziele vorzugeben und in Maßnahmen umzusetzen [Jone03, 6]. Für jedes Gestaltungsziel der IT-Architektur wird ein aus Sicht des Unternehmens optimaler Zustand angestrebt [Kaib02, 24]. Je nach Unternehmen werden unterschiedliche Gestaltungsziele identifiziert bzw. deren Relevanz abweichend beurteilt. Die Gestaltungsziele wirken innerhalb des IT-Bereichs auf die IT-Beschaffung, den ITBetrieb, die IT-Projekte und die IT-Planung und außerhalb des IT-Bereichs auf die Geschäftsprozesse der Geschäftsbereiche und die strategischen Optionen 103 (Abschnitt 6.7.3.1). Abbildung 6-11 zeigt den Zusammenhang zwischen Gestaltung und Wirkung.

Gestaltungsbereiche

IT-Arch.-Modelle

IT-Infrastruktur

IT-Bebauung

Nutzung der IT-Infrastruktur

Technologien

Redundanzgrad

Nutzung der IT-Bebauung

Service-Orientierung

Funktionale Vollständigkeit

IT-Arch.-Strategie

Vollständigkeit

Prozessorientierte Integration

Wirkungsbereiche

IT-intern

IT-extern

IT-Beschaffung

IT-Betrieb

Geschäftsprozessunterstützung

IT-Projekte

IT-Planung

Strategische Optionen

Abbildung 6-11 Zusammenhang zwischen Gestaltung und Wirkung der IT-Architektur

6.7.2.1 Gestaltungsziele der IT-Infrastruktur Standardisierung der Technologien Ausgehend von der in Kapitel 2 beschriebenen Komplexitätskrise ist das Ziel der ITArchitektur eine höhere Standardisierung der IT, d. h. die Vereinheitlichung von Technologien und Applikationen [Buxm96, 8]. Umfangreiche Softwarearchitekturen werden entspre103

6WUDWHJLVFKH2SWLRQHQ sind neue Geschäftsmodelle, die durch den Einsatz von Informationstechnologie möglich werden. Die Kombination aus GPS (Global Positioning System), GIS (Geoinformationssystem) und Wegfahrsperre ermöglicht es einem Automobilhersteller z. B., einen kostenpflichtigen Service zum Auffinden von gestohlenen Fahrzeugen anzubieten.

Wertbeitrag von IT-Architekturen

109

chend der IT-Infrastruktur in ihre Technologien zerlegt und in Layer und Cluster eingeordnet. Dies zielt auf eine Katalogisierung und dadurch einen besseren Zugriff auf wieder verwendbare Komponenten [Reza95, 40; Krcm05, 191] sowie letztendlich auf eine höhere Standardisierung [Wood04, 21] und eine höhere Wiederverwendung der Technologien in Softwarearchitekturen im Rahmen einer modularen Softwareentwicklung ab [Reza95, 39; Wood04, 53]. Standards werden je Cluster definiert, d. h. der Einsatz der als Standard festgelegten Technologie in der Soll-IT-Infrastruktur ist in IT-Projekten erlaubt. Service-Orientierung Anstatt eine IT-Infrastruktur für einzelne Applikationen vorzuhalten, wird diese im Unternehmen applikationsübergreifend anhand des Modells der IT-Infrastruktur organisiert. Plattformen bieten stabile, zentrale, wieder verwendbare Infrastruktur-Services für alle ITProjekte an. Auf diese Weise wird die IT-Infrastruktur von den Applikationen entkoppelt. Die IT-Infrastruktur kann z. B. eine Datenbank/ Betriebssystem/ Hardware-Kombinationen wie Oracle 10g/ Linux/ IBM System p5 anbieten. Im Rahmen der Wiederverwendung werden Plattformen als Teile einer Applikation verstanden, die als Sockel für die Erstellung von Applikationsvarianten oder anderen Applikationen zum Einsatz kommen [Reza95, 38 f.]. Mit steigender Nutzung von Plattformen durch Applikationen erhöht sich die Nutzung der Plattform-Technologien, was sich positiv auf die Standardisierung auswirkt. Vollständigkeit Mithilfe der IT-Architektur wird erfasst, welche Technologien der IT-Infrastruktur in Applikationen und damit in Geschäftsprozessen tatsächlich eingesetzt werden. Möglicherweise fehlende Technologien werden so identifiziert. Falls eine neue Technologie benötigt wird, um eine Anforderung aus den Geschäftsprozessen zu erfüllen, wird sie nach einer Evaluierung in die IT-Infrastruktur aufgenommen. Im Laufe der Zeit werden Lücken in der Technologieversorgung geschlossen und eine vollständige Versorgung der Geschäftsprozesse mit Technologien gewährleistet. 6.7.2.2 Gestaltungsziele der IT-Bebauungsplanung Redundanzgrad Ziel der IT-Bebauungsplanung ist eine bessere Analyse und Gestaltung der Applikationslandschaft im Unternehmen. Dazu werden die Applikationen den Geschäftsprozessen und Sparten zugeordnet. Ähnlich der Standardisierung in der IT-Infrastruktur wird im IT-Bebauungsplan die Abdeckung der Geschäftsprozesse geschäftsbereichsübergreifend gelöst. Wurde innerhalb einer oder mehrerer Geschäftsbereiche in verschiedenen Applikationen Geschäftsprozesslogik mehrfach realisiert, gilt es, diese Überlappungen aufzudecken [DeAn04, 65] und Redundanzen in der Applikationslandschaft zu eliminieren [KrSe04, 340]. Nach einer Unternehmensfusion können z. B. mehrere Applikationen redundant für die Auftragsvergabe und -verfolgung im Außendienst vorhanden sein [BrHa03], obwohl eine

110

Wertbeitrag von IT-Architekturen

Applikation für die Erfüllung der gewünschten Funktionalität ausgereicht hätte. Das Ziel ist die Wiederverwendung ganzer Applikationen orientiert an den Geschäftsprozessen [Reza95, 38; FeLo05, 19 f.]. Funktionale Vollständigkeit Die IT-Bebauungsplanung verbindet die Geschäfts- und Prozessarchitekturen mit der ITArchitektur [HaWi05, 628 f.]. Ziel ist eine möglichst vollständige Unterstützung der aktuellen und geplanten Geschäftsprozesse durch Applikationen. Lücken in der IT-Unterstützung der Geschäftsprozesse werden anhand des IT-Bebauungsplans aufgedeckt und mit vorhandenen Applikationen, die z. B. in anderen Geschäftsbereichen schon eingesetzt werden, oder mit neu einzuführenden Applikationen geschlossen. Prozessorientierte Integration Eine Applikation soll einen Geschäftsprozess möglichst durchgängig unterstützten, Lücken in der Prozessunterstützung verursachen Fehler und Kosten 104. Die Applikationen werden dazu entsprechend des Prozessablaufs horizontal integriert [Karn05b]. 6.7.3

Qualitative Nutzenanalyse

Die Nutzenpotenziale, die von der Verwendung der in Kapitel 3 dargestellten IT-ArchitekturModelle ausgehen, werden im Folgenden anhand einer qualitativen Wirkungsanalyse mit den Gestaltungszielen verknüpft. In der Literatur wird der Nutzen der IT-Architektur überwiegend als Effekt von reduzierten Komplexitätskosten, Synergien und Skaleneffekten beschrieben [JoHA02, 11]. Im Gegensatz dazu werden nachfolgend kausale Wirkungszusammenhänge mit Zwischenschritten zwischen den Gestaltungszielen und dem Nutzen der IT-Architektur beschrieben. In Wirkungsketten werden die Auswirkungen von Investitionen in die IT-Architektur umfassend detailliert und strukturiert [Pott98, 18; Mert85]. Den Gestaltungszielen werden Nutzenpotenziale zugeordnet, um die Verbesserungen in den einzelnen Gestaltungszielen durch Maßnahmen in der IT-Architektur bewerten zu können. 6.7.3.1 Wirkungsbereiche Die Nutzenpotenziale von IT-Architekturen lassen sich auf oberster Ebene in die Bereiche IT-intern (bestehend aus IT-Beschaffung, IT-Betrieb, IT-Projekte und IT-Planung [LeSA04, 236]), Wirkung auf die Geschäftsbereiche und strategische Optionen unterteilen [Prin03]. IT-Beschaffung: IT-Beschaffung meint den Einkauf von Technologien und Dienstleistungen für den IT-Bereich. IT-Betrieb: Der IT-Betrieb ÄLVWGDIUYHUDQWZRUWOLFKGDVVEHUHLWJHVWHOOWH,6 105MHGHU]HLWYHU IJEDU VLQG XP GLH *HVFKlIWVSUR]HVVH ]X XQWHUVWW]HQ³ [LeSA04, 237]. Grundlage dafür sind Dienstleistungsprodukte des IT-Bereichs [Hein02, 52].

Wertbeitrag von IT-Architekturen

111

IT-Projekte: Dieser Bereich dient der Erstellung neuer und der Anpassung vorhandener Applikationen. IT-Planung: Aufgaben der IT-Planung sind die Entwicklung von Zielen und die Aufstellung von Plänen für die Bereiche IT-Projekte und IT-Betrieb [Hein02, 52]. Im vorliegenden Kontext wird dies insbesondere auf die Definition und Überwachung von IT-Projekten bezogen. IT-Unterstützung der Geschäftsprozesse: Dieser Bereich erfasst die Wirkung der ITArchitektur auf die Geschäftsprozesse. Strategische Optionen: Durch eine bessere IT-Architektur können neue Geschäftsmodelle realisiert werden, deren Auswirkungen in diesem Wirkungsbereich erfasst werden. 6.7.3.2 Wirkungsdimensionen Innerhalb der Wirkungsbereiche werden die Auswirkungen von Investitionen in die ITArchitektur anhand der folgenden Wirkungsdimensionen weiter strukturiert [LeSA04, 241 f.; Kaib02, 25; Krcm90, 399; WiPi97, 6 - 11; PiRe03, 4]. Die Wirkungsdimensionen sind Kosten, Zeitbedarf, Qualität und Flexibilität. Dabei ist die Erhebung eines IT-ArchitekturNutzens nicht für jede Kombination aus Wirkungsbereich und -dimension sinnvoll. Tabelle 6-4 zeigt, welche Kombinationen messbar sind. Ein Kreis markiert sinnvolle Kombinationen,

Flexibilität

IT-Beschaffung

Qualität

Wirkungsbereich

Zeitbedarf

Wirkungsdimension

Kosten

ein Querstrich nicht sinnvolle Kombinationen.

z

±

±

z

IT-Betrieb

z

±

z

z

IT-Projekte

z

z

z

±

IT-Planung

±

z

z

±

Geschäftsprozessunterstützung

z

±

z

z

Strategische Optionen

±

±

±

±

Tabelle 6-4

Betrachtete Wirkungsdimensionen

6.7.3.3 Zusammenhänge zwischen den Wirkungsbereichen Wie oben dargestellt zielt die IT-Architektur letztendlich auf eine höhere Effizienz und Effektivität im Wirkungsbereich Geschäftsprozessunterstützung ab, die über die Dimensionen Kosten, Qualität und Flexibilität der Unterstützung bestimmt werden. Prinzipiell wirken sich alle Verbesserungen in den IT-internen Wirkungsbereichen auf den IT-externen Wirkungs104

105

Fehler entstehen bei der Datenübernahme zwischen Applikationen, Kosten entstehen durch den Zeitaufwand der Datenübernahme oder durch Technologien, die für eine automatische Datenübernahme betrieben werden. IS steht für Informationssysteme und entspricht dem Begriff Applikationen.

112

Wertbeitrag von IT-Architekturen

bereich Geschäftsprozessunterstützung aus (vgl. Abbildung 6-12). Die strategischen Optionen ergeben sich aus einzelnen Innovationen bei Technologoien und Applikationen und werden gesondert betrachtet.

Abbildung 6-12 Zusammenhänge zwischen den Wirkungsbereichen

Die Verknüpfungen zwischen den Wirkungsbereichen werden in den folgenden Abschnitten beschrieben. 6.7.3.4 IT-Beschaffung Die IT-Architektur kann in der IT-Beschaffung Kosteneinsparungen und Flexibilitätsverbesserungen bewirken (vgl. Abbildung 6-13).

Abbildung 6-13 Wirkung der IT-Architektur auf die Kosten in der IT-Beschaffung

Wertbeitrag von IT-Architekturen

113

Eine hohe Standardisierung der Technologien und Applikationen ermöglicht eine Bündelung des Einkaufs und schafft damit die Voraussetzung für ein strategisches Einkaufsmanagement [BuES04, 110 und 158; ITRe02; Ross04, 1; WeSB02b, 14]. Die Vereinheitlichung der Technologien ermöglicht größere Abnahmemengen je Technologie, damit steigt die Einkaufsmacht (vgl. Abschnitt 5.2.1.1). Eine klare IT-Architektur-Strategie erhöht die Nachhaltigkeit von Kaufentscheidungen, da die Soll-IT-Architektur klare Vorgaben für Technologien und Applikationen macht. Weniger Lieferanten aufgrund der Standardisierung ermöglichen ein intensiveres Management der Lieferantenbeziehungen [Youn03a, 2]. Daraus resultieren niedrigere Verwaltungskosten. Eine hohe Standardisierung der Technologien und Applikationen ermöglicht flexible Entscheidungen über die Fertigungstiefe im IT-Betrieb [BuES04, 159; Liu02, 15] (vgl. Abbildung 6-14). Je homogener die IT-Landschaft ist, umso kürzer ist die Zeitspanne, die ein Outsourcingpartner braucht, um die Technologien und Applikationen in seinem Rechenzentrum zu betreiben.

Abbildung 6-14 Wirkung der IT-Architektur auf die Flexibilität in der IT-Beschaffung

Je höher der Nutzungsgrad von Plattformen, desto einfacher kann die IT-Infrastruktur unabhängig von den Applikationen betrieben und der Betrieb entsprechend extern vergeben werden. Beim Offshoring von IT-Projekten wird insbesondere die Kommunikation als problematisch betrachtet [DeSo01, 3]. Eine hohe Transparenz der IT-Infrastruktur und der ITBebauung vereinfacht bei einer Fremdvergabe die Strukturierung des Projekts und die Kommunikation mit dem Auftragnehmer über die Einbindung der neuen Applikation in die bestehende IT-Architektur [Sinz04]. 6.7.3.5 IT-Betrieb Die IT-Architektur bewirkt Kosteneinsparungen sowie eine höhere Qualität und Flexibilität im IT-Betrieb (vgl. Abbildung 6-15, Abbildung 6-16 und Abbildung 6-17).

114

Wertbeitrag von IT-Architekturen

Abbildung 6-15 Wirkung der IT-Architektur auf die Kosten im IT-Betrieb 106

Die Reduzierung der Komplexität im IT-Betrieb ist ein Treiber für niedrigere Kosten [BYDH03, 173; LeSA04, 247; MaSS03, 60 f. und 64]. Plattformen bündeln Wartungs- und Supportaktivitäten 107 für mehrere Applikationen, da diese nur einmalig für die Plattform und nicht einzeln für die Softwarearchitektur jeder Applikation anfallen [KaLR04, 3; Nunn03, 5; Reza95, 39]. Durch Plattformen werden Skaleneffekte realisiert [CIOC01, 6]. Je höher der Grad der Standardisierung, desto weniger Technologien müssen gewartet werden [Meta02b, 19; ReWy03, 40; Ross04, 1; Ross03a, 2]. Ein Beispiel sind die Kosten für Datenschutz und -sicherung, die durch Standardisierung und Plattformen verringert werden [BuES04, 148].

106 107

Der Einfluss anderer Wirkungsbereiche ist als grau hinterlegtes Sechseck gekennzeichnet. Supportaktivitäten bezeichnen hier Unterstützungsleistungen für die Nutzer von Applikationen. Dazu gehört das Vergeben und Zurücksetzen von Passwörtern oder die Verwaltung von Benutzerrechten.

Wertbeitrag von IT-Architekturen

115

Wenige Technologien erlauben eine Spezialisierung des IT-Personals und setzen damit Erfahrungskurveneffekte frei [Prin03]. Die höhere Expertise bewirkt Produktivitätssteigerungen bei Wartung und Support [BYDH03, 173; Youn03a, 2]. Ein besseres Lebenszyklusmanagement durch höhere Transparenz in der IT-Architektur (dank der Modelle der ITArchitektur) erlaubt die frühzeitige Ausmusterung alter, kostenintensiver Technologien und Applikationen und damit eine höhere Aktualität der IT-Architektur [Youn03a, 2; Zach97, 13]. Eine hohe Einkaufsmacht durch die Standardisierung kann zu kostenlosen Zusatzleistungen, z. B. bei der Wartung, durch Lieferanten führen [Youn03a, 2]. Die Anzahl der Schnittstellen sinkt [BuES04, 148; Jame03, 1; LaMS03], da standardisierte Technologien die Schnittstellen zwischen Applikationen und der IT-Infrastruktur vereinheitlichen. Die Integration von Applikationen entlang der Geschäftsprozesse reduziert ebenso Schnittstellen. Je höher der Standardisierungsgrad, desto weniger Technologien existieren und entsprechend niedriger ist auch die Anzahl möglicher Schnittstellen zwischen diesen. Eine höhere Qualität im Betrieb reduziert weiterhin die Anzahl der Problemfälle und weniger Wartungspersonal ist notwendig [BuES04, 148; MaSS03, 61; Nunn03, 5; Open04, 2; Youn03a, 2]. Weniger Vielfalt bei den Technologien verringert die Abhängigkeit vom Spezialwissen einzelner Mitarbeiter [BYDH03, 173]. Damit können - wenn man auf verbreitete Standards setzt - freie Stellen einfacher besetzt [Nunn03, 5] und die durchschnittlichen Löhne im IT-Bereich gesenkt werden [BuES04, 148]. Weniger Spezialisten müssen abrufbar sein, um den Betrieb aufrecht zu erhalten [Karn05a, 5; Ross03a, 2]. Entsprechend sinken die Kosten für Weiterbildungsmaßnahmen [Liu02, 20; Newm03; Nunn03, 5; Prin03; Ross03a, 2; Ross04, 1]. Damit sinken insgesamt die Personalkosten. Eine höhere Auslastung der Hardwareressourcen durch Standardisierung der Technologien [BuES04, 154; KaLR04, 13; Youn03a, 1] führt zu niedrigeren Einkaufskosten und wirkt sich damit positiv auf Abschreibungsaufwand, Kapitalbindung sowie Kosten für Ersatzteile aus [Ross03a, 2]. Standardisierung ermöglicht darüber hinaus die Zentralisierung von Standorten [BuES04, 154; ITRe02]. Insgesamt können also die Kosten im IT-Betrieb gesenkt werden [Jone03, 3; Newm03; Nunn03, 3; Prin03]. Eine höhere Qualität im IT-Betrieb kann durch stabilere Applikationen erreicht werden [Ross03a, 2] (vgl. Abbildung 6-16). Durch Standardisierung steigt die Expertise bei der Wartung von Technologien, Probleme werden dadurch schneller gelöst.

116

Wertbeitrag von IT-Architekturen

Abbildung 6-16 Wirkung der IT-Architektur auf die Qualität im IT-Betrieb

Die IT-Architektur-Modelle liefern Informationen, die das Verständnis für Applikationen, Technologien und deren Zusammenhänge erhöhen [DeAn04, 66]. Durch Standardisierung sind weniger Applikationen und Technologien im Einsatz, Ursachen für Probleme lassen sich dadurch schneller identifizieren [Nunn03, 5; Youn03a, 1]. Entscheidend bei Kapazitätserweiterungen im IT-Betrieb ist der Einsatz von Plattformen [BuES04, 15]. Der Einsatz einer zentralen Plattform für IT-Sicherheit in möglichst vielen Applikationen ermöglicht z. B. eine konsistente Verwendung von Verschlüsselung, Authentifizierung, Virenabwehr usw. [Prin03], die unternehmensweit eine hohe Sicherheit auch bei verteilten Applikationen gewährleistet [Liu02, 15; Youn03b, 2]. Plattformen erleichtern Backup und Recovery [Nunn03, 5], das damit nicht mehr für jede Applikation separat, sondern übergreifend erfolgt. Sicherheitsmanagement wird durch die Transparenz in den ITArchitektur-Modellen erleichtert [ICFC04]. IT-Architektur verbessert das Lebenszyklusmanagement und fördert damit die proaktive Ausmusterung von veralteten, sicherheitskritischen Technologien, die den Standards nicht mehr entsprechen [Youn03a, 2]. Flexibilität im IT-Betrieb bezieht sich auf die Anpassung der Applikationen an eine Änderung der Leistungsmengen [Brog96, 110]. Auch die (geringfügige) Anpassung von bestehenden Applikationen 108 wird hier eingeordnet, solange diese nicht separat im Rahmen eines eigenen IT-Projekts erfolgt (vgl. Abbildung 6-17).

108

Solche Anpassungen werden üblicherweise als Change Request bezeichnet [Lind04, 142].

Wertbeitrag von IT-Architekturen

117

Abbildung 6-17 Wirkung der IT-Architektur auf die Flexibilität im IT-Betrieb

IT-Architektur-Management ermöglicht eine höhere Flexibilität im IT-Betrieb [Nunn03, 5; Youn03b, 1] durch den Einsatz von Plattformen, die die Technologien von den Applikationen abkoppeln [KaLR04, 3; Liu02, 14]. Solange an der Schnittstelle zu den Applikationen (Entkopplungspunkt) derselbe Dienst angeboten wird, können alle Technologien einer Plattform flexibel verändert werden. Diese Änderungen wirken sich dann nicht auf die Applikationen aus. Damit sinkt die Abhängigkeit der Applikationen von spezifischen Softwarearchitekturen

und

Technologien

und

die

Portabilität

wird

erhöht

[Open04, 2].

Veränderungen im Ressourcenbedarf der Geschäftsprozesse erfordern Skalierbarkeit von den Applikationen und der IT-Infrastruktur. Die Kapazität von Plattformen lässt sich unabhängig von deren Verwendung erweitern [BrHa03]. Je höher der Standardisierungsgrad ist, umso schneller lässt sich die Kapazität der Applikationen verändern, da bei deren Umgestaltung weniger Komplexität gehandhabt werden muss. Anforderungen der Geschäftsprozesse werden so schneller umgesetzt, die Skalierbarkeit steigt [BYDH03, 173; Liu02, 20; Nunn03, 5; Prin03; Ross04, 1; Ross03a, 2]. Je höher der Standardisierungsgrad ist, umso schneller lassen sich Aktualisierungen und Neuerungen in Clustern der IT-Infrastruktur umsetzen, da nur wenige Technologien betroffen sind [Nunn03, 5; Open04, 2; Ross04, 1]. Die höhere Transparenz durch Nutzung des Modells der IT-Infrastruktur erleichtert zusätzlich die Verteilung von Aktualisierungen und Neuerungen, da betroffene Technologien leichter identifiziert werden können. 6.7.3.6 IT-Projekte Bei der Entwicklung und Einführung neuer Applikationen lassen sich Zeit- und Kosteneinsparungen sowie eine höhere Qualität der Applikationen erreichen (vgl. Abbildung 6-18, Abbildung 6-19 und Abbildung 6-20).

118

Wertbeitrag von IT-Architekturen

Abbildung 6-18 Wirkung der IT-Architektur auf den Zeitbedarf bei IT-Projekten

IT-Architektur-Management

ermöglicht

einen

kürzeren

Softwareentwicklungsprozess

[CIOC01, 5; Knox04, 2; MSTI03, 39; Open04, 4; Perk04; Ross04a, 2; WeSB02b, 1; Zach97, 13] und Zeitgewinne bei der Einführung von Standardsoftware [ZachoJ, 4]. Die Zeiteinsparungen werden im Folgenden anhand der Phasen eines IT-Projekts beschrieben, vgl. dazu [GaMa04, 193]. In der Analyse- und Designphase können anhand der dokumentierten Softwarearchitekturen in der IT-Architektur neue Softwarearchitekturen schneller erstellt werden [FoAt02, 11; Ross04, 1]. Die IT-Architektur-Modelle verschaffen einen unternehmensweiten Überblick [Jame03, 2] und erleichtern damit das Design und die Einpassung einer neuen Applikation. Die technische Spezifizierung von Technologien, die über Plattformen verwendet werden, müssen in IT-Projekten nicht detailliert betrachtet werden [KaLR04, 3; WeSB02b, 10]. Bei der Auswahl einer konkreten Technologie für die Softwarearchitektur ist bei höherem Standardisierungsgrad weniger Zeit für die Evaluation einzelner Technologien notwendig, da die IT-Architektur bereits konkrete Vorgaben bzw. Vorschläge macht [Liu02, 15]. Eine hohe Transparenz durch die Nutzung der Modelle erleichtert die Auswahl von Standardsoftware und deren Einpassung in die bestehende IT-Architektur [ZachoJ, 4].

Wertbeitrag von IT-Architekturen

119

Der für IT-Projekte notwendige Zeitaufwand bei der Implementierung wird entscheidend vom Wiederverwendungsgrad beeinflusst [Perk04; Reza95, 38; Youn03a, 2]. Je mehr und öfter Technologien wieder verwendet werden, umso höher sind die Einsparungen. Grundlage hierfür ist die Annahme, dass Wiederverwendung im Durchschnitt weniger Aufwand erzeugt als Neuentwicklung [Reza95, 98 und 222]. Plattformen müssen nur einmal konfiguriert werden und können dann in mehreren Applikationen eingesetzt werden. Die Entwickler verwenden weniger Aufwand für die IT-Infrastruktur [KaLR04, 3], was ein wesentlicher Erfolgsfaktor bei IT-Projekten ist [MBPS04, 423] 109. Die Produktivität von Softwareentwicklern steigt aufgrund kürzerer Lernkurven [Prin03; Lope02, 4] durch die Standardisierung der Entwicklungsumgebung [Finn98; Jame03, 3]. Weiterhin wird durch eine höhere Transparenz durch die Modelle der IT-Architektur die Kommunikation in IT-Projekten erleichtert und die Lösung von Problemen beschleunigt [Jame03, 2; ZachoJ, 3]. In der Phase der Integration in die bestehende IT-Architektur wird die Anzahl und damit der Zeitbedarf der notwendigen Funktions- und Integrationstests reduziert [Nunn03, 5] und damit die Installation vereinfacht [Ross03a, 2; ZachoJ, 4]. Die Funktionsweise wieder verwendbarer standardisierter Technologien bzw. Plattformen muss nur einmalig und nicht für jede einzelne Applikation getestet werden. Durch die Verwendung von Plattformen kann die Anzahl der Testfälle sinken. Eine standardisierte Testumgebung spart Zeit, da eine solche nicht für jedes IT-Projekt separat entwickelt und betrieben werden muss. In einer standardisierten IT-Architektur können neue Applikationen schneller integriert werden [MaSS03, 63; BYDH03, 173]. Durch den geringeren Zeitbedarf für IT-Projekte ist langfristig weniger Entwicklungspersonal notwendig und die Personalkosten sinken [Jone03, 3; Lope02, 4; MaSS03, 60; Open04, 2] (vgl. Abbildung 6-19). Daraus resultieren niedrigere Entwicklungskosten [Knox04, 2].

109

KING beschreibt ein Beispiel für eine schnelle Realisierung einer Applikation durch die Verwendung von Plattformen [King04].

120

Wertbeitrag von IT-Architekturen

Abbildung 6-19 Wirkung der IT-Architektur auf die Kosten von IT-Projekten

Wie im IT-Betrieb reduziert Standardisierung die Anforderungen an die Mitarbeiter. Damit sind weniger Spezialisierungen notwendig und niedrigere Gehälter möglich. Je homogener die Technologien und die Entwicklungswerkzeuge sind, umso weniger Kosten müssen für Weiterbildungsmaßnahmen aufgewendet werden, um Expertise über alle Technologien vorhalten zu können. Wenige Entwicklungswerkzeuge verringern die Lizenz- bzw. Anschaffungskosten für ebendiese. Neben dem Einfluss des Zeitbedarfs bei IT-Projekten und den Kosten der ITBeschaffung wird wie im IT-Betrieb die Flexibilität der IT-Beschaffung als Einflussgröße auf die IT-Projekte identifiziert, da diese durch einfacheres Offshoring gesenkt werden können. Die Qualität von IT-Projekten wird anhand der Anforderungserfüllung gemessen. Die Modelle der IT-Architektur können die Kommunikation über die Anforderungen verbessern (vgl. Abbildung 6-20).

Wertbeitrag von IT-Architekturen

121

Abbildung 6-20 Wirkung der IT-Architektur auf die Qualität in IT-Projekten

Für standardisierte Technologien und Plattformen ist eine hohe Qualität sichergestellt, da diese in verschiedenen IT-Projekten Verwendung finden. Je größer der Anteil bereits bewährter, ausgereifter Technologien ist, umso weniger Fehler sind in einer neuen Applikation zu erwarten [Reza95, 38 und 222]. Die höhere Expertise der Entwickler durch Standardisierung kann helfen, Fehler zu vermeiden. Insgesamt hat die IT-Architektur das Potenzial, die Qualität von Applikationen zu erhöhen [CIOC01, 6]. 6.7.3.7 IT-Planung In der IT-Planung sind Verbesserungen in den Wirkungsdimensionen Zeitbedarf und Qualität möglich (vgl. Abbildung 6-21 und Abbildung 6-22).

122

Wertbeitrag von IT-Architekturen

Abbildung 6-21 Wirkung der IT-Architektur auf den Zeitbedarf der IT-Planung

Die IT-Architektur-Strategie ist das Ergebnis der strategischen Planung für die IT-Architektur und gibt konkrete Gestaltungs- und damit Investitionsziele vor. Formale, institutionalisierte IT-Planungsprozesse versprechen einen schlanken Entscheidungsprozess und damit Zeitersparnisse im Vergleich zu einer Planung ohne Strategie und ohne ein institutionalisiertes Vorgehen [Meta02b, 21]. Schon allein durch die Einführung der strukturierten ITInfrastruktur und der IT-Bebauung wird der notwendige Zeitaufwand für die Beschaffung der Informationsgrundlage für die IT-Planung reduziert. Insbesondere werden die Daten nur einmalig erfasst sowie zentral gepflegt, sind vielfach abrufbar und müssen damit nicht für jede Teilplanung separat neu beschafft werden [DeAn04, 66]. Die IT-Architektur-Modelle verbessern die Kommunikation zwischen den Geschäftsbereichen und dem IT-Bereich [CIOC01, 6; LaMS03; LaRo03, 1; MaSS03, 63; Meta02a, 6; Ross04, 2]. Die Folge ist eine bessere Abstimmung zwischen Geschäft und IT [Ross03a, 2] bei der Definition von IT-Projekten [CIOC01, 5; SaWi02, 42] (vgl. Abbildung 6-22).

Wertbeitrag von IT-Architekturen

123

Abbildung 6-22 Wirkung der IT-Architektur auf die Qualität der IT-Planung

Die bessere Kommunikation und Informationsversorgung erleichtern das Erkennen von ITPotenzialen für das Geschäft [Meta02b, 21]. IT-Architektur stärkt das IT-Programm-Management [Meta02b, 19], also die Verwaltung mehrerer IT-Projekte, die sich anhand der klareren Ziele besser priorisieren lassen. Synergien zwischen IT-Projekten verschiedener Geschäftsbereiche sind leichter zu identifizieren [BuES04, 109]. So werden redundante ITProjekte vermieden [FEA03, 63] bzw. der Nutzen eines IT-Projekts durch dessen Ausdehnung auf weitere Geschäftsbereiche multipliziert [BuES04, 109]. Auch die Governance der IT-Projekte, also deren Überwachung hinsichtlich der Erfüllung der Anforderungen, kann von der höheren Transparenz durch IT-Architektur-Modelle profitieren [CIOC01, 6; FEA03, 64]. Mit Hilfe der IT-Architektur-Modelle lassen sich projektübergreifende, unternehmensweite Themen, z. B. IT-Sicherheit [Liu02, 15] oder die Konformität zu gesetzlichen Bestimmungen [CIOC01, 6], leichter planen und steuern. 6.7.3.8 Unterstützung der Geschäftsprozesse Jeder bisher beschriebene Nutzen kann über die Verknüpfungen zwischen den Wirkungsbereichen implizit als Verbesserung der IT-Unterstützung der Geschäftsprozesse interpretiert werden (vgl. Abschnitt 6.7.3.3). Der im Folgenden beschriebene Nutzen des ITArchitektur-Managements bezieht sich explizit auf die Verbesserung der IT-Unterstützung der Geschäftsprozesse. Daraus resultieren Verbesserungen der Prozesskosten, Durchlauf-

124

Wertbeitrag von IT-Architekturen

zeiten, Flexibilität oder der Qualität der Geschäftsprozesse [Krcm05, 121] (vgl. Abschnitt 6.3). Die Verbesserung der IT-Unterstützung der Geschäftsprozesse durch IT-ArchitekturManagement wird in den Wirkungsdimensionen Kosten (Effizienz), Qualität und Flexibilität (Effektivität) beschrieben (vgl. Abschnitt 6.7.3.2). Die Geschäftsbereiche können durch eine Verbesserung der IT-Architektur die ITKosten senken [Prin03; Ross04, 1; Youn03a, 2] (vgl. Abbildung 6-23).

Abbildung 6-23 Wirkung der IT-Architektur auf die Kosten der Geschäftsprozessunterstützung

Niedrigere Kosten von IT-Projekten [MSTI03, 39] resultieren einerseits aus den Einsparungen im IT-Projekt selbst sowie einer besseren IT-Planung, die durch das Erkennen von Synergien die Kosten senken kann. Die Anzahl der IT-Projekte, die durch eine falsche Ausrichtung nicht planmäßig abgeschlossen werden bzw. das vorgesehene Budget überschreiten, nimmt ab. IT-Projekte, die keinen klaren Geschäftszielen dienen oder mit anderen kollidieren, werden mit höherer Wahrscheinlichkeit vor deren Durchführung identifiziert, eine Fehlinvestition so vermieden. Je einfacher sich die Applikationslandschaft an geänderte Geschäftsprozesse anpassen lässt, desto weniger Kosten entstehen bei einer Änderung der Geschäftsprozesse [Open04, 2]. Neben den IT-Investitionskosten sinken die laufenden IT-Kosten [Ross04, 2]. Falls mehrere Applikationen die gleiche Funktionalität erfüllen, können bei Eliminierung dieser Redundanz die laufenden Kosten ganzer Applikationen eingespart werden. Wie in Abschnitt 6.7.3.5 gezeigt, sind Einsparungen im IT-Betrieb möglich, die an die Geschäftsprozesse weitergegeben werden [Hite03 nach Saha04]. Die Schulungskosten sinken, da durch weniger Applikationsredundanzen und höhere Standardisierung weniger Applikationen im Einsatz sind [Nunn03, 5]. Die Mitarbeiter müssen daher, z. B. bei einem Wechsel zwischen

Wertbeitrag von IT-Architekturen

125

Geschäftsbereichen, auf weniger Applikationen geschult werden, die Wechselkosten sinken. Weiterhin kann eine höhere Qualität der IT-Unterstützung durch zusätzliche Applikationen erreicht werden, falls Lücken in der Unterstützung der Geschäftsprozesse oder Sparten geschlossen werden (vgl. Abbildung 6-24).

Abbildung 6-24 Wirkung der IT-Architektur auf die Qualität der Geschäftsprozessunterstützung

Alle Vorteile, die Geschäftsprozessen durch die Nutzung einer Applikation entstehen, können als Nutzen der IT-Architektur interpretiert werden, falls aufgrund des IT-ArchitekturManagements das Potenzial dieser Applikation freigesetzt wurde. Gemeint ist z. B. die Neueinführung einer Applikation für bestimmte Geschäftsprozesse und Sparten zur Schließung einer Lücke in der Geschäftsprozessunterstützung, die im IT-Bebauungsplan identifiziert wurde. Höherer Automatisierungsgrad und Höheres IT-Potenzial als Nutzen der ITArchitektur beziehen sich auf diese IT-Potenziale. So führt ein höherer Automatisierungsgrad zu weniger Medienbrüchen und Personalbedarf [LeNe02]. Weniger Medienbrüche führen zu weniger Fehlern [Ross04, 2] und damit zu einer höheren Produktivität. Durch eine durchgängige IT-Unterstützung sinken die Prozesskosten [Karn05b] und die Qualität und Produktivität der Prozesse steigt. Daneben steigt die Interoperabilität der Applikationen an [Jame03, 2; Nunn03, 3], wenn diese standardisierte Technologien nutzen [ReWy03, 40].

126

Wertbeitrag von IT-Architekturen

Durch die höhere Qualität im Betrieb steigt die Stabilität und Sicherheit der Applikationen. IT-bedingte Störungen in den Geschäftsprozessabläufen können reduziert werden [Ross04, 2] und die höhere Verlässlichkeit führt zu Produktivitätsverbesserungen in den Prozessen [Young03a, 2; Ross04, 2; Rost03, 2]. Plattformbestandteile, wie z. B. Single Sign-On oder eine einheitliche Hilfe-Funktionalität für mehrere Applikationen [MBPS04, 423; Prin03], erleichtern die Bedienbarkeit der Applikationen und tragen dazu bei, IT-Kosten für z. B. Passwortabfragen zu reduzieren. Die Verringerung der Applikationsanzahl ermöglicht es den Nutzern, sich auf wenige Applikationen zu konzentrieren und darin Experten zu werden [Ross03a, 2]. Die Datenqualität steigt, da Datenredundanzen verschwinden. Standardisierung erleichtert den Zugriff auf Daten, da die Vielfalt der Applikationen und damit die Vielfalt deren Schnittstellen gesenkt wird [Nunn03, 5; Open04, 2; Jame03, 2]. Weiterhin können Kosteneinsparungen in der Verbesserung der Effektivität, d. h. einer höheren Qualität der IT-Unterstützung resultieren, z. B. durch die Neueinführung oder Erweiterung von Applikationen. Über die IT-Architektur kann die Flexibilität der IT-Unterstützung der Geschäftsprozesse und damit die Fähigkeit zur Veränderung von Geschäftsprozessen verbessert werden (vgl. Abschnitt 6.4) [CIOC01, 5; Hite03 nach Saha04; Zach97, 14; Meta02a, 5 f.; Meta02b, 21; MSBA02, 10 und 36; DeAn04, 66; Nunn03, 5; Open04, 2]. WEILL, SUBRAMANI und BROADBENT definieren Flexibilität (Strategic Agility) als ÄWKH VHW RI EXVLQHVV LQLWLDWLYHV DQ HQWHUSULVHFDQUHDGLO\LPSOHPHQW´ [WeSB02a, 61; WeSB02b, 10]. Je mehr Änderungen der IT-Unterstützung in einem bestimmten Zeitraum erfolgen können, umso höher ist die ITFlexibilität [Ross03c, 2]. Die IT-Architektur erhöht die IT-Flexibilität alleine durch die Strukturierung in der IT-Infrastruktur und im IT-Bebauungsplan [Prin03; Ross3a, 2]. Das Schichtenprinzip und die Zerlegung in Einzelbausteine sind Designprinzipien in der Softwareentwicklung, um die Flexibilität zu erhöhen (vgl. Abbildung 6-25).

Wertbeitrag von IT-Architekturen

127

Abbildung 6-25 Wirkung der IT-Architektur auf die Flexibilität der Geschäftsprozessunterstützung

Flexibilität erfordert eine schnelle Applikationsentwicklung [Ross03c, 2]. Die Geschäftsprozesse können dadurch früher von neuen Applikationen profitieren [Youn03a, 2]. Auch die verbesserte Fähigkeit zur IT-Planung wirkt sich positiv auf die Flexibilität der IT aus, da notwendige Änderungen schneller erkannt und implementiert werden können. Nach SAUER und WILLCOCKS reagieren viele Unternehmen auf die zunehmende Volatilität im Geschäft mit einer Verkürzung der IT-Entwicklungs- und IT-Planungszyklen [SaWi02, 41]. Auch im IT-Betrieb lassen sich Applikationen und die IT-Infrastruktur aufgrund der IT-Architektur leichter anpassen und erweitern. Letztendlich wirkt sich die höhere Effizienz auch auf die Effektivität aus: Durch die Reduzierung des IT-Budgets hinsichtlich der nicht-wahlfreien ITBetriebskosten wird mehr Budget für Innovationen in der IT und damit für Projekte frei. Damit sind mehr Projekte möglich [Youn03a, 2]. Unternehmen mit besserer IT-Architektur können damit eine schnellere Reaktion auf Marktveränderungen [Ross04, 1], kürzere Produkteinführungszeiten [Open04, 3; Zach97, 14; MaSS03, 64], höhere Wachstumsraten [Open04, 3] und höhere Umsätze mit neuen Produkten realisieren [WeSB02b, 1; WeSB02a, 58]. 6.7.3.9 Strategische Optionen Die IT-Architektur verbessert die Übersicht über genutzte und v. a. nicht genutzte ITPotenziale. Die höhere Qualität der IT-Unterstützung zielt auf die bessere Abdeckung der vorhandenen Geschäftsprozesse durch IT ab. Darüber hinaus kann dem Einsatz von neuen Technologien eine Änderung der Geschäftsprozesse folgen und kann so weitere Potenziale auf Ebene der Geschäftsprozesse freisetzen (vgl. Abbildung 6-26).

128

Wertbeitrag von IT-Architekturen

Abbildung 6-26 Wirkung der IT-Architektur auf strategische Optionen

Die Imitation einer IT-Architektur ist meist nicht kurzfristig möglich und diese kann damit eine Basis von Wettbewerbsvorteilen sein [WeSB02b, 10]. BYRD und TURNER weisen nach, dass die Flexibilität der IT-Infrastruktur mit höheren Wettbewerbsvorteilen korreliert [ByTu01]. Flexiblere Geschäftsprozesse ermöglichen es einem Unternehmen, schneller und innovativer als Wettbewerber mit neuen Produkten oder auf neuen Märkten aufzutreten [Ross04, 2]. Daraus resultierende First Mover Vorteile 110 wie höhere Preise, höherer Marktanteil oder das Diktieren von Standards ergeben sich daraus [Lope02, 4]. Die niedrigeren Kosten der IT-Unterstützung können die Basis von Kostenvorteilen sein. Weiterhin verbessert eine IT-Architektur die Möglichkeit der Zusammenarbeit mit Lieferanten und Kunden in einem Wertschöpfungsnetzwerk [Boar01, 53 - 55]. Standardisierung und damit weniger Redundanzen vermindert die Vielfalt der Applikationen pro Geschäftsprozess und somit auch die Vielfalt der Datenbestände. Es wird angenommen, dass sich die Kommunikation und Interaktion der Applikationen eines Geschäftsprozesses mit derer eines

110

Als First Mover werden Unternehmen bezeichnet, die einen neuen Markt als erste signifikant bearbeiten. Beispiele sind eBay für Online-Auktionen und Amazon für den Buchhandel über das Internet.

Wertbeitrag von IT-Architekturen

129

externen Partners durch eine reduzierte Vielfalt verbessert [Ross04, 2; Ross03a, 2; West03, 320; BYDH03, 173]. Durch eine höhere Flexibilität der IT lassen sich unternehmensübergreifende Geschäftsprozesse schneller und kostengünstiger unterstützen und wieder auflösen [Youn03b, 2; Boar01, 51]. Dies kann ein Vorteil gegenüber Wettbewerbern sein [Boar01, 54]. Die leichtere Durchführbarkeit von Fusionen und Unternehmensübernahmen ist ein weiterer strategischer Vorteil durch IT-Architektur-Management [Ross04, 2; Youn03b, 2]. Viele M&A-Vorhaben scheitern, da die IT nicht integriert werden kann. Standardisierte IT gilt als einer der Erfolgsfaktoren für Unternehmensfusionen und -übernahmen, da die Integration dadurch schneller und kostengünstiger möglich ist und damit mehr Synergien freigesetzt werden können [Popo01]. HEROLD beschreibt z. B. die Anwendung des IT-Bebauungsplans bei der Due Diligence 111 der IT von Akquisitionsobjekten [Hero03, 224 - 228]. 6.7.4

Kennzahlen für die IT-Architektur

Die Qualität der IT-Architektur wird in Bezug auf die Gestaltungsziele über IT-ArchitekturKennzahlen erfasst. In der Literatur findet sich keine Zusammenstellung von IT-ArchitekturKennzahlen. Zwar gibt es Hinweise auf deren Notwendigkeit und einige Einzelkennzahlen, z. B. bei [KrSe03, 154], doch existiert insbesondere in Bezug auf die in Kapitel 3 vorgestellten IT-Architektur-Modelle keine Kennzahlsystematik, obwohl eine solche generell für die Validierung von Modellen gefordert wird [Wint04, 2]. Die Einführung eines Kennzahlensystems muss sich an der jeweiligen Steuerungsaufgabe orientieren [Kütz03, 44]. Entsprechend werden die IT-Architektur-Kennzahlen auf Basis der im Kapitel 6.7.2 beschriebenen Gestaltungsziele entwickelt. 6.7.4.1 Kennzahlen und Kennzahlensysteme Eine Kennzahl erfasst einen Sachverhalt quantitativ in konzentrierter Form und beschreibt dabei den Zustand eines Systems [Kütz03, 4; Webe04, 241]. Dabei ist eine Kennzahl meist nur ein Abbild der Realität, das diese vergröbert, aber charakteristisch darstellt. Die ITArchitektur-Kennzahlen dienen zur Erfassung von Zuständen der IT-Architektur. Merkmale von Kennzahlen sind der Informationscharakter, d. h. die Beurteilung des dargestellten Zusammenhangs, die Quantifizierbarkeit, also die Messung auf einer metrischen Skala, und die Informationsform, die für die einfache Darstellung komplexer Sachverhalte steht [Kütz03, 4 und 41 f.]. Da Einzel-Kennzahlen nur eine begrenzte Aussagekraft haben [Webe04, 254; WiPi97, 2] und vieldeutig interpretierbar sind [Kütz03, 43], werden mehrere Kennzahlen in einem Kennzahlen-System in einen sachlogischen Zusammenhang gestellt. KÜTZ bietet eine Übersicht über IT-Kennzahlensysteme [Kütz03, 44 f. und 153 - 297]. Das im Folgen-

111

Due Diligence bedeutet sorgfältige Prüfung und bezeichnet eine systematische Stärken/ Schwächen Analyse von Unternehmen bei Fusionen oder Übernahmen.

130

Wertbeitrag von IT-Architekturen

den beschriebene Kennzahlensystem zur IT-Architektur lässt sich der Kategorie der Ordnungssysteme zuordnen, da die Kennzahlen alle dem Gegenstandsbereich der ITArchitektur zuzurechnen sind und entsprechend nach sachlichen bzw. inhaltlichen Kriterien gruppiert werden. Die Kennzahlen sollen das IT-Architektur-Management bei Gestaltungs-, Planungs-, Überwachungs- und Steuerungsaufgaben unterstützen [WiPi97, 1]. Die IT-ArchitekturKennzahlen ermöglichen die quantitative Beschreibung des Ist-Zustands der IT-Architektur. Daraus werden Handlungsbedarfe abgeleitet und die Soll-IT-Architektur wird mit den Kennzahlen beschrieben. Die Kennzahlen können jederzeit Auskunft über den Zustand der ITArchitektur zwischen Ist- und Ziel-Zustand geben und dienen damit der Überwachung der Migration (vgl. Abbildung 6-27). Ist-Zustand erfassen

Handlungsbedarf ableiten

‡ %HVFKUHLEXQJGHU,VW,7$UFKLWHNWXU

‡ ,GHQWLILNDWLRQYRQYHUEHVVHUXQJVIlKLJHQ Bereichen

Soll-Zustand beschreiben

‡ 4XDQWLWDWLYH%HVFKUHLEXQJGHU6ROO,7 Architektur

Migration überwachen

‡ 9HUIROJXQJGHU0LJUDWLRQYRP,VW ]XP=LHO Zustand

Abbildung 6-27 Anwendung der IT-Architektur-Kennzahlen

Für die Realisierung von Kennzahlen sind zunächst die Datenquellen und Basisgrößen festzulegen [Kütz03, 44]. Die IT-Architektur-Kennzahlen beziehen sich auf die ITInfrastruktur und den IT-Bebauungsplan. Im Folgenden wird zwischen allgemeinen und spezifischen Kennzahlen unterschieden. Spezifische Kennzahlen sind einem Bestandteil eines IT-Architektur-Modells zugeordnet 112. Diese dienen als Basisdaten für allgemeine Kennzahlen, die Informationen über mehrere spezifische Kennzahlen aggregieren 113. All112 113

Z. B.: Anzahl Plattformen, in denen die Technologie Oracle 9g eingesetzt wird. Z. B.: Anzahl Plattformen, in denen eine Technologie durchschnittlich eingesetzt wird:

¦ TP u i

i

¦ Einsatzhäufigkeit TP in allen Plattformen  §¨ T  TP ·¸ ¦ ¸¹ ¨¦ © ¦ TP ¦T i

i

i

i

i

i

i

i

i

wobei TP für eine Technologie, die in einer Plattform eingesetzt wird, steht und T für eine Technologie (gleichgültig, ob diese in einer Plattform eingesetzt wird, oder nicht). Falls z. B. 120 von insgesamt 400 Technologien der IT-Infrastruktur durchschnittlich in drei Plattformen eingesetzt werden, ergibt sich ein Wert von 1,6 für diese Kennzahl.

Wertbeitrag von IT-Architekturen

131

gemeine Kennzahlen beschreiben quantitative Eigenschaften übergreifend für die ITArchitektur. 6.7.4.2 Spezifische Kennzahlen der IT-Infrastruktur Das Modell der IT-Infrastruktur besteht aus den Bestandteilen Layer, Cluster, Technologie und Plattform (vgl. Abschnitt 3.5). Die Kennzahlen für jeden dieser Bestandteile zeigt Tabelle 6-5.

132

Cluster

Technologie

Bestandteil

Wertbeitrag von IT-Architekturen

Kürzel

Applikation

Ausprägung [0;’[

Anzahl Applikationen, die Technologie X nutzen

(direkter Input)

IS.T.1.2

Anteil Applikationen, die Technologie X nutzen

Anzahl Applikationen, die Technologie X nutzen {IS.T.1.1} / Anzahl Applikationen {IA.A.1.1} (vgl. Tabelle 6-8)

IS.T.2.1

Anzahl Plattformen, die Technologie X nutzen

(direkter Input)

IS.T.2.2

Anteil Plattformen, die Technologie X nutzen

Anzahl Plattformen, die Technologie X nutzen {IS.T.2.1} / Anzahl Plattformen {IA.P.1} (vgl. Tabelle 6-7)

IS.T.3

Lieferant Technologie X

(direkter Input)

{Freitext}

IS.C.1

Anzahl Technologien im Cluster X

(direkter Input)

[0;’[

IS.C.2.1

Anzahl Nutzungen von Technologien des Clusters durch Applikationen

[0;’[

IS.C.2.2

Dstl. Anzahl Applikationen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster X

Summe aller Technologien im Cluster X (Anzahl Applikationen, die Technologie X nutzen {IS.T.1.1}) Anzahl Nutzungen von Technologien des Clusters durch Applikationen {IS.C.2.1} / Anzahl Technologien im Cluster X {IS.C.1}

IS.C.2.3

Dstl. Anteil Applikationen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster X

[%]

IS.C.2.4

Anzahl Nutzungen von Technologien des Clusters durch Plattformen

IS.C.2.5

Dstl. Anzahl Plattformen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster X

Dstl. Anzahl Applikationen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster X {IS.C.2.2} / Anzahl Applikationen {IA.A.1.1} Summe aller Technologien im Cluster X (Anzahl Plattformen, die Technologie X nutzen {IS.T.2.1}) Anzahl Nutzungen von Technologien des Clusters durch Plattformen {IS.C.2.4} / Anzahl Technologien im Cluster X {IS.C.1}

IS.C.2.6

Dstl. Anteil Plattformen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster X

IS.L.1 IS.L.2 IS.A.1.1

Dstl. Anzahl Plattformen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster X {IS.C.2.5} / Anzahl Plattformen {IA.P.1} (vgl. Tabelle 67) Anzahl der potenziell redundanten Anzahl Technologien im Cluster X {IS.C.1} Technologien je Cluster X 1 Anzahl Technologien im Layer X (direkter Input) Anzahl Cluster im Layer X (direkter Input) Anzahl Technologien die von Applikation X (direkter Input) genutzt werden

IS.A.1.2

Anzahl Plattformen, die von Applikation X genutzt werden

IS.P.1

Anzahl Technologien, die von Plattform X (direkter Input) genutzt werden Anzahl Applikationen, die Plattform X (direkter Input) nutzen Anteil Applikationen, die Plattform X nutzen Anzahl Applikationen, die Plattform X nutzen {IS.P.2.1} / Anzahl Applikationen {IA.A.1.1} (vgl. Tabelle 6-8) Anzahl der um > Z % ähnlichen Anzahl Plattformen, die mindestens Z % Plattformen für Plattform X gleiche Technologien einsetzen wie Plattform X

IS.P.2.1 Plattform

Formel / Bestimmung

IS.T.1.1

IS.C.3 Layer

Bezeichnung

IS.P.2.2

IS.P.3

Tabelle 6-5

(direkter Input)

[%]

[0;’[

[%]

[0;’[

[0;’[

[0;’[

[%]

[0;’[ [0;’[ [0;’[ [0;’[

[0;’[

[0;’[ [0;’[ [%]

[0;’[

Spezifische Kennzahlen der IT-Infrastruktur 114

Für jede Kennzahl werden ein Kürzel 115, eine Bezeichnung, ggf. die Berechnung und die Ausprägung angegeben. Beim Schlüsselwort Summe, gefolgt von einer runden Klammer,

Wertbeitrag von IT-Architekturen

133

wird für alle bezeichneten Bestandteile der Wert in Klammern summiert. Beim Schlüsselwort Anzahl, gefolgt von einer runden Klammer, werden alle Bestandteile gezählt, die der Bedingung in der Klammer entsprechen. Ausgewählte Kennzahlen werden im Folgenden kurz erläutert. Für die Kennzahl IS.C.2.2 Dstl. Anzahl Applikationen, die eine Technologie aus Cluster X nutzen, je Technologie im Cluster 116 wird je Technologie im betrachteten Cluster die Anzahl Applikationen, welche diese Technologie nutzen, summiert und durch die Anzahl der Technologien im Cluster geteilt. Anhand dieser Kennzahl kann z. B. die relative Wichtigkeit eines Clusters festgestellt werden. Die Kennzahl IS.T.1.1 Anzahl Applikationen, die Technologie X nutzen ist ein Indikator für den durchschnittlichen Aufwand für die Migration einer Technologie - je mehr Applikationen eine Technologie nutzen, umso höher wird der Aufwand einer Migration sein. 6.7.4.3 Spezifische Kennzahlen des IT-Bebauungsplans Das Modell der IT-Bebauung besteht aus den Bestandteilen Applikation, Prozess, Matrixfeld und Sparte (vgl. Abschnitt 3.4). Matrixfeld ist ein Feld, das aus der Kombination eines Prozesses mit einer Sparte gebildet wird (vgl. Abbildung 3-5). Tabelle 6-6 zeigt die Kennzahlen für den IT-Bebauungsplan 117.

114 115

116 117

Dstl. steht für durchschnittlich. IS steht für Infrastruktur spezifisch, T für Technologie, C für Cluster, L für Layer, A für Applikation und P für Plattform. Das Berechnungsbeispiel gilt auch für IS.C.2.4, IS.C.2.5 und IS.C.2.6. BS steht für Bebauungsplan spezifisch, A für Applikation, PR für Prozess, S für Sparte und M für Matrixfeld.

134

Wertbeitrag von IT-Architekturen

Bestandteil

Kürzel

Bezeichnung

[0;’[

Anzahl unterstützter Prozesse je Applikation X

BS.A.1.2

Anteil unterstützter Prozesse je Applikation Anzahl unterstützter Prozesse je Applikation X X {BS.A.1.1} / Anzahl Prozesse {BA.P.1}

BS.A.2.1

Anzahl unterstützter Sparten je Applikation (direkter Input) X und Prozess Y (Matrixfeld XY)

BS.A.2.2

Anteil unterstützter Sparten je Applikation X und Prozess Y (Matrixfeld XY)

BS.A.3.1

Anzahl unterstützter Sparten je Applikation Summe aller Prozesse Y, die von Applikation X und Prozess (Mittelwert je Applikation) X unterstützt werden (Anzahl unterstützter Sparten je Applikation X und Prozess Y {BS.A.2.1}) / Anzahl aller Prozesse Y, die von Applikation X unterstützt werden (Anzahl unterstützter Sparten je Applikation X und Prozess Y > 0 {BS.A.2.1})

BS.A.3.2

Anteil unterstützter Sparten je Applikation X und Prozess (Mittelwert je Applikation)

Summe aller Prozesse Y, die von Applikation X unterstützt werden (Anteil unterstützter Sparten je Applikation X und Prozess Y {BS.A.2.2}) / Anzahl aller Prozesse Y, die von Applikation X unterstützt werden (Anteil unterstützter Sparten je Applikation X und Prozess Y > 0 {BS.A.2.2})

BS.A.4.1

Anzahl zusammenhängender Prozessübergänge je Applikation X

(direkter Input)

BS.A.4.2

Anteil zusammenhängender Prozessübergänge je Applikation X

Anzahl zusammenhängender Prozessübergänge je Applikation X {BS.A.4.1} / (Anzahl Prozesse {BA.A.1} -1)

BS.PR.1

Anzahl Applikationen je Prozess X

(direkter Input)

[0;’[

BS.PR.2.1

Dstl. Anzahl unterstützter Sparten je Applikation und Prozess X (Mittelwert je Prozess)

Summe aller Applikationen Y, die Prozess X unterstützen (Anzahl unterstützter Sparten je Applikation Y und Prozess X {BS.A.2.1}) / Summe aller Applikationen Y, die Prozess X unterstützen (Anzahl unterstützter Sparten je Applikation Y und Prozess X > 0 {BS.A.2.1})

[0;’[

BS.PR.2.2

Dstl. Anteil unterstützter Sparten je Applikation und Prozess X (Mittelwert je Prozess)

Summe aller Applikationen Y, die Prozess X unterstützen (Anteil unterstützter Sparten je Applikation Y und Prozess X {BS.A.2.2}) / Summe aller Applikationen Y, die Prozess X unterstützen (Anteil unterstützter Sparten je Applikation Y und Prozess X > 0 {BS.A.2.2})

[%]

BS.PR.3

Streuungsgrad über die Sparten je Prozess Standardabweichung über alle Sparten Y des X Prozesses X

[0;’[

Anzahl Applikationen je Sparte X

(direkter Input)

[0;’[

Anzahl Applikationen je Prozess X und Sparte Y (Matrixfeld XY)

(direkter Input)

[0;’[

Sparte BS.S.1 Matrix- BS.M.1 feld

Tabelle 6-6

(direkter Input)

Ausprägung

BS.A.1.1

Applikation Prozess

Formel / Bestimmung

Anzahl unterstützter Sparten je Applikation X und Prozess Y {BS.A.2.1} / Anzahl Sparten {BS.S.1}

[%]

[0;’[

[%]

[0;’[

[%]

[0;’[

[%]

Spezifische Kennzahlen des IT-Bebauungsplans

Prozess in der Kennzahlenbezeichnung und Kennzahlenformel steht für die jeweils gewählte Detailebene in der IT-Bebauung und wird im konkreten Fall durch Prozessgruppe, Prozessübersicht bzw. Prozesselement ersetzt (vgl. Abbildung 3-3).

136

Wertbeitrag von IT-Architekturen

Bestandteil

Kürzel

IA.T.1.1 IA.T.1.2

Anzahl Technologien Anzahl Applikationen

IA.T.1.3

Anteil Technologien Applikationen

Technologie

IA.T.2

IA.T.3.1

IA.T.3.2

IA.T.4.1

IA.T.4.2

Cluster

IA.C.1 IA.C.2 IA.C.3.1

Layer

IA.C.3.2 IA.L.1 IA.L.2.1 IA.L.2.2 IA.P.1 IA.P.2.1

IA.P.2.2

Plattform

Bezeichnung

Summe aller Technologien X = Anzahl Applikationen {IA.A.1}

Anzahl Applikationen {IA.T.1.2} / Anzahl Technologien {IA.T.1.1} Anzahl Lieferanten über alle Summe aller Technologien X Technologien ((verschiedene) Lieferant Technologie X {IS.T.4}) Anzahl der potenziell redundanten Summe aller Cluster X (Anzahl der Technologien über alle Cluster potenziell redundanten Technologien je Cluster X {IS.C.3}) Anteil der potenziell redundanten Anzahl der potenziell redundanten Technologien über alle Cluster Technologien über alle Cluster {IA.T.3.1} / Anzahl Technologien {IA.T.1.1} Anzahl Applikationen, von denen eine Summe aller Technologien X der Technologie der Infrastruktur dstl. Infrastruktur (Anzahl Applikationen, die genutzt wird Technologie X nutzen {IS.T.1.1}) / Anzahl Technologien Infrastruktur {IA.T.1.} Anzahl Plattformen, von denen eine Summe aller Technologien X der Technologie der Infrastruktur dstl. Infrastruktur (Anzahl Plattformen, die genutzt wird Technologie X nutzen {IS.T.2.1}) / Anzahl Technologien Infrastruktur {IA.T.1.3} Anzahl Cluster Summe aller Layer X (Anzahl Cluster im Layer X {IS.L.2}) Dstl. Anzahl Technologien je Cluster Anzahl Technologien {IA.T.1.1} / Anzahl Cluster {IA.C.1} Anzahl Cluster mit Anzahl Technologien Summe aller Cluster X (Anzahl >Z Technologien im Cluster X {IS.C.1} > Z) Anteil Cluster mit Anzahl Technologien Anzahl Cluster mit Anzahl Technologien > Z >Z {IA.C.3.1} / Anzahl Cluster {IA.C.1} Anzahl Layer Summe aller Layer X Dstl. Anzahl Cluster pro Layer Anzahl Cluster {IA.C.1} / Anzahl Layer {IA.L.1} Dstl. Anzahl Technologien pro Layer Anzahl Technologien {IA.T.1.1} / Anzahl Layer {IA.L.1} Anzahl Plattformen Summe aller Plattformen X Anzahl Technologien der Infrastruktur, Summe aller Technologien X der die von Plattformen genutzt werden Infrastruktur (Anzahl Plattformen, die Technologie X nutzen {IS.T.2.1} > 0) Anteil Technologien der Infrastruktur, Anzahl Technologien der Infrastruktur, die die von Plattformen genutzt werden von Plattformen genutzt werden {IA.P.2.1} / Anzahl Technologien Infrastruktur {IA.T.1.3}

IA.P.3.1

Anzahl Applikationen, von denen eine Plattform dstl. genutzt wird

IA.P.3.2

Anteil Applikationen, von denen eine Plattform dstl. genutzt wird

IA.P.4.1

Anzahl potenziell redundanter Plattformen

IA.P.4.2

Anteil potenziell redundanter Plattformen

Tabelle 6-7

Formel / Bestimmung

Summe aller Plattformen X (Anzahl Applikationen, die Plattform X nutzen {IS.P.2.1}) / Anzahl Plattformen {IA.P.1} Anzahl Applikationen, von denen eine Plattform dstl. genutzt wird {IA.P.3.1} / Anzahl Applikationen {IA.A.1} Summe aller Plattformen X (Anzahl um Z% ähnlicher Plattformen für Plattform X {IS.P.3} > 0) Anzahl potenziell redundanter Plattformen {IA.P.4.1} / Anzahl Plattformen {IA.P.1}

Allgemeine Kennzahlen der IT-Infrastruktur (Teil 1)

Ausprägung [0;’[ [0;’[ [%] [0;’[

[0;’[

[%]

[0;’[

[0;’[

[0;’[ [0;’[ [0;’[ [%] [0;’[ [0;’[ [0;’[ [0;’[

[%]

[0;’[

[0;’[

[0;’[

[%]

Wertbeitrag von IT-Architekturen

Bestandteil

Kürzel

Formel / Bestimmung

IA.A.1

Anzahl Applikationen

IA.A.2

Dstl. Anzahl Technologien je Applikation Summe aller Applikationen X (Anzahl Technologien der Infrastruktur, die von Applikation X genutzt werden {IS.A.1.1}) / Anzahl Applikationen {IA.A.1} Anzahl Technologien der Infrastruktur, Summe aller Technologien X der die mehr als Z-mal von Applikationen Infrastruktur (Anzahl Applikationen, die genutzt werden Technologie X nutzen {IS.T.1.1} > Z) Anteil Technologien der Infrastruktur, Anzahl Technologien der Infrastruktur, die die mehr als Z-mal von Applikationen mehr als Z-mal von Applikationen genutzt genutzt werden werden {IA.A.3.1} / Anzahl Technologien Infrastruktur {IA.T.1.3} Anzahl Applikationen, die Plattformen Summe aller Applikationen X (Anzahl nutzen Plattformen, die von Applikation X genutzt werden {IS.S.1.2} >0) Anteil Applikationen, die Plattformen Anzahl Applikationen, die Plattformen nutzen nutzen {IA.A.4.1} / Anzahl Applikationen {IA.A.1} Dstl. Anzahl genutzter Plattformen je Summe aller Applikationen X (Anzahl Applikation Plattformen, die von Applikation X genutzt werden {IS.S.1.2}) / Anzahl Applikationen {IA.A.1}

IA.A.3.1

Applikation

Bezeichnung

137

IA.A.3.2

IA.A.4.1

IA.A.4.2

IA.A.4.3

Tabelle 6-8

Summe aller Applikationen X

Ausprägung [0;’[ [0;’[

[0;’[

[%]

[0;’[

[%]

[0;’[

Allgemeine Kennzahlen der IT-Infrastruktur (Teil 2)

Die Kennzahl IA.T.3.2 Anteil der potenziell redundanten Technologien über alle Cluster bezieht die Summe der potenziell redundanten Technologien, die mittels IA.T.3.1 je Cluster bestimmt werden, auf die Gesamtzahl der Technologien IA.T.1.1. Die Kennzahl IA.P.3.1 Anzahl Applikationen, von denen eine Plattform dstl. genutzt wird gibt an, in wie vielen Applikationen eine Plattform im Schnitt eingesetzt wird. Dazu wird der Mittelwert über die spezifische Kennzahl IS.P.2.1 Anzahl Applikationen, die Plattform X nutzen über alle Plattformen gebildet. Eine Kennzahl zur Wiederverwendung von Technologien ist IA.A.3.2 Anteil Technologien, die mehr als Z-mal von Applikationen genutzt werden. Um diese zu bestimmen, werden (über die Kennzahl IS.T.1.1 Anzahl Applikationen, die Technologie X nutzen für jede Technologie) diejenigen Technologien gezählt, die mehr als Z-mal in Applikationen eingesetzt werden (IA.A.3.1) und mit der Gesamtzahl der Technologien (IA.T.1.3) ins Verhältnis gesetzt. 6.7.4.5 Allgemeine Kennzahlen des IT-Bebauungsplans Tabelle 6-9 und Tabelle 6-10 zeigen die allgemeinen Kennzahlen des IT-Bebauungsplans auf 119.

119

BA steht für Bebauungsplan allgemein.

138

Bestandteil

Wertbeitrag von IT-Architekturen

Formel / Bestimmung

Ausprägung

BA.A.1

Anzahl Applikationen

Anzahl über alle Applikationen X im IT-Bebauungsplan

[0;’[

BA.A.3.1

Dstl. Anzahl unterstützter Prozesse je Applikation

[0;’[

BA.A.3.2

Dstl. Anteil unterstützter Prozesse je Applikation Dstl. Anzahl unterstützter Sparten je Applikation und Prozess (Mittelwert)

Summe aller Applikationen X (Anzahl unterstützter Prozesse je Applikation X {BS.A.1.1}) / Anzahl Applikationen {BA.A.1} Dstl. Anzahl unterstützter Prozesse je Applikation {BA.A.3.1} / Anzahl Prozesse {BA.PR.1} Summe aller Applikationen X und Prozesse Y (Anzahl unterstützter Sparten je Applikation X und Prozess Y {BS.A.2.1}) / Anzahl über alle Applikationen X und Prozesse Y (Anzahl unterstützter Sparten je Applikation X und Prozess Y > 0 {BS.A.2.1})

Kürzel

Applikationen

BA.A.4.1

[%] [0;’[

BA.A.4.2

Dstl. Anteil unterstützter Sparten je Applikation und Prozess (Mittelwert)

Summe aller Applikationen X und Prozesse Y (Anteil unterstützter Sparten je Applikation X und Prozess Y {BS.A.2.2}) / Anzahl über alle Applikationen X und Prozesse Y (Anteil unterstützter Sparten je Applikation X und Prozess Y > 0 {BS.A.2.2})

[%]

BA.A.4.3

Anzahl Applikationen mit dstl. Spartenunterstützung < Z%

Anzahl über alle Applikationen X (Anteil unterstützter Sparten je Applikation X und Prozess {BS.A.3.1} < Z%)

[0;’[

BA.A.4.4

Anteil Applikationen mit dstl. Spartenunterstützung < Z%

Anzahl Applikationen mit dstl. Spartenunterstützung < Z% {BA.A.4.3} / Anzahl Applikationen {BA.A.1}

[%]

BA.A.5.1

Dstl. Vollständigkeit der Unterstützung der Prozessgruppen je Applikation

[%]

BA.A.5.2

Dstl. Vollständigkeit der Unterstützung der Prozessübersichten je Applikation

Summe aller Applikationen X (Vollständigkeit der Unterstützung der Prozessgruppen je Applikation X {BS.A.4}) / Anzahl Applikationen {BA.A.1} Summe aller Applikationen X (Vollständigkeit der Unterstützung der Prozessübersichten je Applikation X {BS.A.4}) / Anzahl Applikationen {BA.A.1}

BA.A.6.1

Dstl. Anzahl zusammenhängender Prozessübergänge je Applikation

BA.A.6.2

Dstl. Anteil zusammenhängender Prozessübergänge je Applikation

BA.PR.1 BA.PR.2.1

Anzahl Prozesse Dstl. Anzahl Applikationen je Prozess

BA.PR.2.2

[%]

Summe aller Applikationen X (Anzahl zusammenhängender Prozessübergänge je Applikation X {BS.A.4.1}) / Anzahl Applikationen {BA.A.1} Summe aller Applikationen X (Anteil zusammenhängender Prozessübergänge je Applikation X {BS.A.4.2}) / Anzahl Applikationen {BA.A.1} (direkter Input) Summe aller Prozesse X (Anzahl Applikationen je Prozess X {BS.P.1}) / Anzahl Prozesse {BA.PR.1}

[0;’[

Anzahl Prozesse mit Anzahl Applikationen je Prozess > Z Anteil Prozesse mit Anzahl Applikationen je Prozess > Z

Summe aller Prozese X (Anzahl Applikationen je Prozess X {BS.P.1} > Z) Anzahl Prozesse mit Anzahl Applikationen je Prozess > Z {BA.PR.2.2} / Anzahl Prozesse {BA.PR.1}

[0;’[

Anzahl Prozesse mit Anzahl Applikationen je Prozess < Z Anteil Prozesse mit Anzahl Applikationen je Prozess < Z

Summe aller Prozese X (Anzahl Applikationen je Prozess X {BS.P.1} < Z) Anzahl Prozesse mit Anzahl Applikationen je Prozess < Z {BA.PR.2.4} / Anzahl Prozesse {BA.PR.1}

[0;’[

Summe aller Prozesse X (Streuungsgrad über die Sparten je Prozess X {BS.P.3}) / Anzahl Prozesse {BA.PR.1} Anzahl Prozesse mit Streuungsgrad über Summe aller Prozesse X (Streuungsgrad über die die Sparten > Z Sparten je Prozess X {BS.P.3} > Z) Anteil Prozesse mit Streuungsgrad über Anzahl Prozesse mit Streuungsgrad über die Sparten die Sparten > Z > Z {BA.PR.3.2) / Anzahl Prozesse {BA.PR.1}

[0;’[

BA.PR.4.1

Anzahl Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z%

Summe aller Prozesse X (Dstl. Anteil unterstützter Sparten je Applikation und Prozess X {BS.P.2.2} < Z%)

[0;’[

BA.PR.4.2

Anteil Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z%

Anzahl Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z% {BA.PR.4.1} / Anzahl Prozesse {BA.PR.1}

BA.PR.2.3

BA.PR.2.4 BA.PR.2.5 Prozesse

Bezeichnung

BA.PR.3.1

BA.PR.3.2 BA.PR.3.3

Tabelle 6-9

Dstl. Streuungsgrad über die Sparten je Prozess

Allgemeine Kennzahlen des IT-Bebauungsplans (Teil 1)

[%]

[0;’[ [0;’[

[%]

[%]

[0;’[ [%]

[%]

Wertbeitrag von IT-Architekturen

Matrixfelder

Sparten

Bestandteil

Kürzel

139

Bezeichnung

Ausprägung

Formel / Bestimmung

BA.S.1

Anzahl Sparten

(direkter Input)

[0;’[

BA.S.2

Dstl. Anzahl Applikationen je Sparte

Summe aller Sparten X (Anzahl der Applikationen je Sparte X {BS.S.1}) / Anzahl Sparten {BA.S.1.1}

[0;’[

BA.M.1

Anzahl Matrixfelder

Anzahl Prozesse {BA.PR.1} * Anzahl Sparten {BA.S.1})

[0;’[

BA.M.2.1

Dstl. Anzahl Applikationen je Matrixfeld Prozess/Sparte

[0;’[

BA.M.2.2

Anzahl Matrixfelder Prozess/Sparte mit Anzahl Applikationen < Z

BA.M.2.3

Anteil Matrixfelder Prozess/Sparte mit Anzahl Applikationen < Z

BA.M.2.4

Anzahl Matrixfelder Prozess/Sparte mit Anzahl Applikationen > Z

BA.M.2.5

Anteil Matrixfelder Prozess/Sparte mit Anzahl Applikationen > Z

BA.M.3.1

Anzahl Matrixfelder Prozess/Sparte, die nicht von IT unterstützt werden

BA.M.3.2

Anteil Matrixfelder Prozess/Sparte, die nicht von IT unterstützt werden

Summe aller Matrixfelder XY Prozess X und Sparten Y (Anzahl Applikationen je Prozess X und Sparte Y {BS.M.2}) / Anzahl Matrixfelder {BA.M.1} Summe aller Matrixfelder XY Prozess X und Sparten Y (Anzahl Applikationen je Prozess X und Sparte Y {BS.M.2} < Z) Anzahl Matrixfelder Prozess/Sparte mit Anzahl Applikationen < Z {BA.M.2.2} / Anzahl Matrixfelder {BA.M.1} Summe aller Matrixfelder XY Prozess X und Sparten Y (Anzahl Applikationen je Prozess X und Sparte Y {BS.M.2} > Z) Anzahl Matrixfelder Prozess/Sparte mit Anzahl Applikationen > Z {BA.M.2.4} / Anzahl Matrixfelder {BA.M.1} Summe aller Matrixfelder XY Prozess X und Sparte Y (Anzahl Applikationen je Prozess X und Sparte Y {BS.M.1} = 0) Anzahl Matrixfelder Prozess/Sparte, die nicht von IT unterstützt werden {BA.M.3.1} / Anzahl Matrixfelder {BA.M.1}

Tabelle 6-10

[0;’[

[%]

[0;’[

[%]

[0;’[

[%]

Allgemeine Kennzahlen des IT-Bebauungsplans (Teil 2)

Folgendes Beispiel erläutert die Kennzahl BA.A.4.2 Dstl. Anteil unterstützter Sparten je Applikation und Prozess. Die Prozesse 1.1, 1.2, 1.3, 2.1, 2.2, 3.1, 3.2 und 3.3 werden von den Applikationen A bis K unterstützt (vgl. Tabelle 6-11). BA.A.2.2 Anteil unterstützter Sparten je Applikation X und Prozess Y Prozess 1.1 1.2 1.3 2.1 2.2 3.1 3.2 Applikation 100% 100% 100% 100% 100% 100% 100% A 100% 67% B 100% 100% 100% 33% 33% C 33% 33% D 100% 100% 100% 67% 100% 100% 100% E 33% 33% F 67% 100% 67% G 100% 100% H 33% 67% 67% 67% 67% I 67% 33% 33% 67% 33% 67% 100% J K 87% 72% 71% 67% 73% 80% GP (BS.PR.2.2) 87%

Tabelle 6-11

3.3

App. (BS.A.2.2)

100%

100% 83% 73% 33% 96% 33% 78% 100% 56% 58% 33% 74% (BA.A.4.2)

33% 100%

33% 67% 33% 61%

Kennzahl BA.A.4.2 (Beispiel)

Die Prozentangabe in den Matrixfeldern gibt an, wie viele Sparten von einer Applikation in einem Prozess unterstützt werden (Kennzahl BA.A.2.2). Der Mittelwert über einen Prozess (Kennzahl BS.PR.2.2) gibt einen Hinweis auf einen möglichen Handlungsbedarf. Ist ein Wert im Vergleich zu den übrigen Werten niedrig (im Beispiel 61 % bei Prozess 3.3), empfiehlt sich eine Untersuchung der Unterstützung dieses Prozesses durch Applikationen. Der Mittelwert einer Applikation (Kennzahl BS.A.2.2) liefert ebenso einen Hinweis auf einen

140

Wertbeitrag von IT-Architekturen

möglichen Handlungsbedarf. Die Applikationen D, F und K fallen durch einen verhältnismäßig niedrigen Wert von 33 % auf. Das bedeutet, dass sie nicht spartenübergreifend genutzt werden. Im Beispiel stellt sich bei einer genauen Untersuchung heraus, dass Applikation D nur wenige Sparten unterstützt, da es sich um eine sehr spezielle Applikation handelt (z. B. ein GIS). Die Applikationen F und K dagegen können durch Applikation A ersetzt werden und werden nach dieser Analyse mittelfristig abgelöst. Eine solche Veränderung erhöht den Wert der Kennzahl BA.A.4.2. Diese ist somit ein Indikator für die Qualität der Durchgängigkeit der IT-Unterstützung von Sparten und Geschäftsprozessen im Unternehmen. 6.7.4.6 Kennzahlengruppen Bezüglich der Gestaltungsziele werden die Kennzahlen der IT-Architektur in Kennzahlengruppen strukturiert, die jeweils eine bestimmte Qualitätsausprägung der IT-Architektur abdecken. Da Einzelkennzahlen nur eine begrenzte Aussagekraft haben und vieldeutig interpretierbar sind, werden pro Gestaltungsziel mehrere Kennzahlen in einer Kennzahlengruppe zusammengeführt. Die vorhandenen Informationen verdichten sich dadurch und eventuelle Fehleinschätzungen bzw. -messungen einzelner Kennzahlen können erkannt und korrigiert werden. Tabelle 6-12 zeigt die Kennzahlengruppen der IT-Infrastruktur, Tabelle 6-13 die des IT-Bebauungsplans.

Wertbeitrag von IT-Architekturen

141

IT-Infrastruktur: Kennzahlengruppen

Standardisierung der Technologien

KennzahlenGruppe

Kürzel IA.T.1.1 IA.T.1.3 IA.T.2 IA.T.3.1

IA.P.4.1 IA.P.4.2 IA.C.1

Anzahl Technologien Anteil Technologien Applikationen Anzahl Lieferanten über alle Technologien Anzahl der potenziell redundanten Technologien über alle Cluster Anteil der potenziell redundanten Technologien über alle Cluster Anzahl Applikationen, von denen ein Technologie der Infrastruktur dstl. genutzt wird Anzahl Technologien der Infrastruktur, die mehr als Z-mal von Applikationen genutzt werden Anteil Technologien der Infrastruktur, die mehr als Z-mal von Applikationen genutzt werden Dstl. Anzahl Technologien je Cluster Anzahl Cluster mit Anzahl Technologien > Z Anteil Cluster mit Anzahl Technologien > Z Anzahl Plattformen Anzahl Technologien der Infrastrukur, die von Plattformen genutzt werden Anteil Technologien der Infrastrukur, die von Plattformen genutzt werden Anzahl Applikationen, von denen eine Plattform dstl. genutzt wird Anteil Applikationen, von denen eine Plattform dstl. genutzt wird Anzahl Applikationen, die Plattformen nutzen Anteil Applikationen, die Plattformen nutzen Dstl. Anzahl genutzter Plattformen je Applikation Anzahl Applikationen, von denen ein Technologie der Infrastruktur dstl. genutzt wird Anzahl Technologien der Infrastruktur, die mehr als Z-mal von Applikationen genutzt werden Anteil Technologien der Infrastruktur, die mehr als Z-mal von Applikationen genutzt werden Anzahl potenziell redundanter Plattformen Anteil potenziell redundanter Plattformen Anzahl Cluster

IA.L.2.1

Dstl. Anzahl Cluster pro Layer

IA.T.3.2 IA.T.4.1 IA.A.3.1 IA.A.3.2 IA.C.2 IA.C.3.1 IA.C.3.2 IA.P.1 IA.P.2.1 IA.P.2.2

Service-Orientierung

IA.P.3.1 IA.P.3.2 IA.A.4.1 IA.A.4.2 IS.A.4.3 IA.T.4.1 IA.A.3.1

Vollständigkeit der Technologien

IA.A.3.2

Tabelle 6-12

Bezeichnung

Kennzahlengruppen der IT-Infrastruktur

Ausprägung [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [%] [0;’[ [%] [0;’[ [0;’[ [0;’[ [%] [0;’[ [%] [0;’[ [0;’[

142

Wertbeitrag von IT-Architekturen

IT-Bebauungsplan: Kennzahlengruppen

Prozessbezoge Integration

Redundanz

Funktionale Vollständigkeit

KennzahlenGruppe

Tabelle 6-13

Kürzel

Bezeichnung

BA.A.1 Anzahl Applikationen BA.M.3.1 Anzahl Matrixfelder Prozess/Sparte, die nicht von der IT unterstützt werden BA.M.3.2 Anteil Matrixfelder Prozess/Sparte, die nicht von der IT unterstützt werden BA.P.2.1 Dstl. Anzahl Applikationen je Prozess BA.P.2.4 Anzahl Prozesse mit Anzahl Applikationen je Prozess < Z BA.P.2.5 Anteil Prozesse mit Anzahl Applikationen < Z BA.M.2.1 Dstl. Anzahl Applikationen je Matrixfeld Prozess/Sparte BA.M.2.2 Anzahl Matrixfelder Prozess/Sparte mit Anzahl Applikationen < Z BA.M.2.3 Anteil Matrixfelder Prozess/Sparte mit Anzahl Applikationen < Z BA.P.3.1 Dstl. Streuungsgrad über die Sparten je Prozess BA.P.3.2 Anzahl Prozesse mit Streuungsgrad über die Sparten > Z BA.P.3.3 Anteil Prozesse mit Streuungsgrad über die Sparten > Z BA.A.4.1 Dstl. Anzahl unterstützter Sparten je Applikation und Prozess BA.A.4.2 Dstl. Anteil unterstützter Sparten je Applikation und Prozess BA.A.4.3 Anzahl Applikationen mit dstl. Spartenunterstützung < Z % BA.A.4.4 Anteil Applikationen mit dstl. Spartenunterstützung < Z % BA.P.4.1 Anzahl Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z% BA.P.4.2 Anteil Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z % BA.A.1 Anzahl Applikationen BA.P.2.1 Dstl. Anzahl Applikationen je Prozess BA.P.2.2 Anzahl Prozesse mit Anzahl Applikationen je Prozess > Z BA.P.2.3 Anteil Prozesse mit Anzahl Applikationen je Prozess > Z BA.M.2.1 Dstl. Anzahl Applikationen je Matrixfeld Prozess/Sparte BA.M.2.4 Anzahl Matrixfelder Prozess/Sparte mit Anzahl Applikationen > Z BA.M.2.5 Anteil Matrixfelder Prozess/Sparte mit Anzahl Applikationen > Z BA.P.3.1 Dstl. Streuungsgrad über die Sparten je Prozess BA.P.3.2 Anzahl Prozesse mit Streuungsgrad über die Sparten > Z BA.P.3.3 Anteil Prozesse mit Streuungsgrad über die Sparten > Z BA.A.4.1 Dstl. Anzahl unterstützter Sparten je Applikation und Prozess BA.A.4.2 Dstl. Anteil unterstützter Sparten je Applikation und Prozess BA.A.4.3 Anzahl Applikationen mit dstl. Spartenunterstützung < Z % BA.A.4.4 Anteil Applikationen mit dstl. Spartenunterstützung < Z % BA.P.4.1 Anzahl Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z% BA.P.4.2 Anteil Prozesse mit Applikationen mit dstl. Spartenunterstützung < Z % BA.A.2 Anzahl nicht zugeordnete Applikationen BA.A.3.1 Dstl. Anzahl unterstützter Prozesse je Applikation BA.A.3.2 Dstl. Anteil unterstützter Prozesse je Applikation BA.A.5.1 Dstl. Vollständigkeit der Unterstützung der Prozessgruppen je Applikation BA.A.5.2 Dstl. Vollständigkeit der Unterstützung der Prozessübersichten je Applikation BA.A.6.1 Dstl. Anzahl zusammenhängender Prozessübergänge je Applikation BA.A.6.2 Dstl. Anteil zusammenhängender Prozessübergänge je Applikation

Kennzahlengruppen des IT-Bebauungsplans

Ausprägung [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [%] [0;’[ [%] [0;’[ [%] [0;’[ [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [0;’[ [%] [0;’[ [%] [0;’[ [%] [0;’[ [%] [0;’[ [0;’[ [%] [%] [%] [0;’[ [%]

Wertbeitrag von IT-Architekturen

143

Folgende Zusammenhänge werden für die Zuordnung angenommen:

x

Der Standardisierungsgrad hängt von der Anzahl der Technologien in der ITInfrastruktur, der Wiederverwendung von Technologien in Applikationen und der Anzahl der Technologien pro Cluster ab.

x

Der Grad der Service-Orientierung kann über die Anzahl Plattformen, die Anzahl der in Plattformen eingesetzten Technologien, die generelle Wiederverwendung von Technologien und die Nutzung von Plattformen gemessen werden.

x

Die Vollständigkeit der Technologien wird über die Anzahl der Cluster gemessen.

x

Beim Grad der funktionalen Vollständigkeit und dem Redundanzgrad wird die Anzahl der Applikationen und deren Verteilung in der IT-Bebauung je nach Gestaltungsziel positiv oder negativ interpretiert. Es wird davon ausgegangen, dass verschiedene Sparten beim gleichen Geschäftsprozess möglichst homogen mit Applikationen zu unterstützen sind. Entsprechend wird die Streuung und Verteilung in der IT-Unterstützung über die Sparten bei beiden Gestaltungszielen als Indikator für Heterogenität verwendet.

x

Der Grad der funktionalen Vollständigkeit wird über das Auftreten nicht durch Applikationen bzw. mit sehr wenig Applikationen unterstützter Prozesse und Sparten verfolgt.

x

Für den Redundanzgrad wird die Anzahl von Prozessen und Sparten mit sehr viel Applikationen und die Anzahl der nicht zugeordneten Applikationen herangezogen.

x

Der prozessbezogene Integrationsgrad hängt von der Durchgängigkeit der IT-Unterstützung gemessen über die Anzahl der von Applikationen unterstützen Prozesse ab.

Die Zusammenstellung der Kennzahlengruppen erfolgt unternehmensspezifisch und ist abhängig von den verfolgten Gestaltungszielen und den verfügbaren IT-Architektur-Kennzahlen im Unternehmen. 6.7.5

Spezifikation der Ist- und Soll-IT-Architektur

Zur Bewertung des Nutzens einer IT-Architektur werden die Auswirkungen von Unterschieden zwischen der Ist- und Soll-IT-Architektur bewertet. Den Ist-Zustand beschreiben die ITArchitektur-Kennzahlen anhand der Modelle der IT-Architektur. Die IT-Architektur-Ziele werden abstrakt festgelegt, ohne dass eine konkrete Ausgestaltung der Soll-IT-Architektur vorliegen muss. Die Kennzahlen werden dazu mit Zielwerten belegt. 6.7.5.1 Festlegen von Zielen mittels IT-Architektur-Kennzahlen Anhand der Kennzahlen wird der Ist-Zustand der IT-Architektur verdichtet beschrieben und kommuniziert. So sind Aussagen über den Zustand der IT-Architektur auf Ebene des GeVDPWPRGHOOV ]% Ä'LH $Q]DKO GHU 7HFKQRORJLHQ LQ GHU ,7$UFKLWHNWXU EHWUlJW ³ RGHU Ä-H 3UR]HVVHOHPHQW QXW]W GDV 8QWHUQHKPHQ  $SSOLNDWLRQHQ³ XQG HEHQVR IU HLQ]HOQH %HVWDQGWHLOH]%Ä$SSOLNDWLRQ;ZLUGLQ3UR]HVVJUXSSHQHLQJHVHW]W³P|JOLFK

144

Wertbeitrag von IT-Architekturen

Die Zielwerte werden z. B. vom CIO oder vom Leiter der IT-Architektur-Abteilung als Planungsgrundlage festgelegt. Die Ziele können durch Experten mit Erfahrungswerten und/ oder Benchmarking unterstützt werden. Benchmarking ist der Vergleich der eigenen Leistung mit der anderer, erfolgreicher Unternehmen aus der gleichen Branche [VaZe02, 142 - 169], um z. B. zu beurteilen, welche Applikationen für einen bestimmten Geschäftsprozess effektiv sind [Karg03, 380 f.]. Zu beachten ist: Ä9HUJOHLFKHQ NDQQ PDQ DEHU QXU ZDV >«@ YHUJOHLFKEDU LVW 8P >«@ GLH 9HU JOHLFKEDUNHLW YRQ ]ZHL 2EMHNWHQ KHU]XVWHOOHQ SURML]LHUHQ ZLU VLH DXI JHHLJQHWH /LVWHQYRQ0HVVJU|‰HQ:HQQGLHVH>«@.HQQ]DKOHQV\VWHPH>«@ÃJOHLFK¶VLQG GDQQLVWHLQ9HUJOHLFKGHU2EMHNWHDOVR%HQFKPDUNLQJP|JOLFK³>.W]I@ Ein2EMHNW ist z. B. die IT-Architektur. Die IT-Architektur-Kennzahlen bilden die Basis für einen Vergleich der IT-Architekturen von zwei oder mehr Unternehmen. Der Belegung der IT-Architektur-Kennzahlen im Ist-Zustand werden Benchmarkingwerte gegenübergestellt. Diese erlauben Rückschlüsse auf die Qualität der eigenen IT-Architektur und das Ableiten von Verbesserungsvorschlägen im Sinne einer Best Practice [Karg03, 381]. Abbildung 6-32 in Kapitel 6.7.6.3 zeigt dies unter der Bezeichnung ,7$UFKLWHNWXU=LHOHIHVWOHJHQ. Beispiele für IT-Architektur-Benchmarks auf Basis von 3.300 Unternehmen [Butt05] liefert die HACKETT GROUP: Ä+DFNHWW IRXQG WKDW ZLWKLQ ,7 LQIUDVWUXFWXUH FRPSOH[LW\ LV KLJKO\ FRUUHODWHG ZLWK FRVW 7KH PHGLDQ WRWDO ,7 FRVW SHU HQGXVHU ULVHV ZLWK WKH QXPEHU RI GDWDEDVH SODWIRUPV LQ XVH SHU  HQGXVHUV DQG ZRUOGFODVV ,7 RUJDQL]DWLRQV UHO\ RQ SHUFHQWIHZHUFXVWRPHUGDWDEDVHVSHUHQGXVHUVDQGSHUFHQWIHZHU VXSSOLHUGDWDEDVHVWKDQW\SLFDOFRPSDQLHV7KH\DOVRUHO\RQSHUFHQWIHZHU VRIWZDUHVXSSOLHUVDQGSHUFHQWIHZHUKDUGZDUHVXSSOLHUV>«@ZRUOGFODVV,7 RUJDQL]DWLRQV XVH SHUFHQW IHZHU SURJUDPPLQJ ODQJXDJHV SHU  HQG XVHUVWKDQW\SLFDOFRPSDQLHV´>+DFN@ Je höher die Übereinstimmung in der Struktur der IT-Architektur-Modelle ist, umso detailliertere Aussagen sind beim Benchmarking möglich. Die IT-Infrastruktur bringt eine vom Unternehmen weitgehend unabhängige Strukturierung in Layer und Cluster mit. So können sich Benchmarks auf konkrete Objekte, z. B. den Cluster '%06, beziehen. Für den ITBebauungsplan gibt es unternehmensübergreifende Referenzprozessmodelle, z. B. für eine Branche. Benchmarking ist dann auch für übereinstimmende Prozesse zwischen Unternehmen möglich. Es ist jedoch darauf zu achten, dass nur IT-Bebauungspläne der gleichen Granularitätsstufe verglichen werden können. 6.7.5.2 Bestimmung der Zielerfüllung Zum einen kann je Kennzahl der Soll-IT-Architektur die Zielerfüllung bestimmt werden, zum anderen die Zielerfüllung der Kennzahlengruppen. Tabelle 6-14 zeigt die Berechnung der

Wertbeitrag von IT-Architekturen

145

Zielerfüllung für die Kennzahlengruppe Standardisierung der Technologien (1) für ein Beispielszenario.

Standardisierung der Technologien

Tabelle 6-14

IA.C.2 IA.C.3.1

Anzahl der potenziell redundanten Technologien über alle Cluster Anteil der potenziell redundanten Technologien über alle Cluster Anzahl Applikationen, von denen eine Technologie der Infrastruktur dstl. genutzt wird Anzahl Technologien der Infrastruktur, die mehr als 10 mal von Applikationen genutzt werden Anteil Technologien der Infrastruktur, die mehr als 10 mal von Applikationen genutzt werden Dstl. Anzahl Technologien je Cluster Anzahl Cluster mit Anzahl Technologien > 6

IA.C.3.2

Anteil Cluster mit Anzahl Technologien > 6

IA.T.3.2 IA.T.4.1

IA.A.3.1

IA.A.3.2

8 14 22

380 3,1 80

Orientierung

IA.T.3.1

[0;’[ [0;’[ [0;’[

(8)

Zielwert

Anzahl Technologien Anteil Technologien Applikationen Anzahl Lieferanten über alle Technologien

(3) Einstufung

Gewichtung Kennzahl

IA.T.1.1 IA.T.1.3 IA.T.2

(4)

O/UGrenze

Bezeichnung

(5)

Belegung Kennzahl

Kürzel

(6) Szenario

Zielerfüllung Kennzahlengruppe [%]

ITInfrastruktur

(7) Ausprägung

Zielbereich Kennzahl

(2) Kennzahlen

Zielerfüllung Kennzahl [%]

(1) Kennzahlengruppe

2 2 2

400 2 100

150 10 10

1 2 1

[%]

38

35

1

50

10

1

[0;’[

29

40

2

50

15

1

20

2

2

0

10

2

[%]

33

10

1

0

30

2

[%]

48

12

2

0

25

2

[0;’[ [0;’[

51 26

3,2 15

2 1

5 20

1,5 1

1 1

[%]

11,76

20

1

22

5

1

[%]

27,4

Bestimmung der Zielerfüllung für eine Kennzahlengruppe (Beispiel) 120

Für jede IT-Architektur-Kennzahl (2), die in der Kennzahlengruppe zur Anwendung kommt, wird ein Zielbereich (3) festgelegt. Dieser besteht aus einem Zielwert und einer Ober- bzw. Untergrenze, je nachdem ob eine Verringerung oder Erhöhung des Kennzahlenwerts erreicht werden soll. Der Abstand der Ausprägung der Kennzahl (5) von der Unter- bzw. Obergrenze (0 Prozent) im Verhältnis zum Zielwert (100 Prozent) gibt die Zielerfüllung der Kennzahl (6) an 121. Die Berechnung der Zielerfüllung einer Kennzahl lautet (O/UGrenze - Zielerfüllung Kennzahl) / (O/U-Grenze - Zielwert). Die Kennzahlen werden absolut oder relativ gewichtet (4). Die Summe aller relativen Gewichte der Kennzahlen eines Kennzahlenclusters beträgt 100 Prozent. Die Gewichtung im Beispiel erfolgt absolut. Die Belegung der Kennzahlen im Szenario (5) wird anhand des Zielbereichs als Zielerfüllung prozentual bewertet (6), indem die Nähe des Kennzahlenwerts

120 121

O/U-Grenze steht für Ober-/ Untergrenze. Im Beispiel werden je nach Ausrichtung Werte kleiner als die Untergrenze mit 0 Prozent sowie Werte größer als der Zielwert mit 100 Prozent bzw. größer als die Obergrenze mit 0 Prozent sowie kleiner als der Zielwert mit 100 Prozent Zielerfüllung bewertet. Für die Berechnung wird in der Spalte Orientierung (8) angegeben, ob es sich um eine Unter- (Wert = 2) oder eine Obergrenze (Wert = 1) handelt.

146

Wertbeitrag von IT-Architekturen

zum Zielwert im Zielbereichsintervall bestimmt wird. Die Bewertungen der Kennzahlen einer Kennzahlengruppe werden über die vergebenen Gewichte zusammengefasst und somit die Zielerreichung pro Kennzahlengruppe in Prozent (7) angegeben. Im Beispiel ist für die Kennzahl IA.T.2 Anzahl Lieferanten über alle Technologien der Zielwert 10, die Obergrenze beträgt 100, d. h. sind in der IT-Infrastruktur mehr als 100 verschiedene Lieferanten für Technologien hinterlegt, ist diese Kennzahl mit 0 Prozent Zielerreichung zu bewerten. Der tatsächliche Wert im Basisszenario beträgt 80, was einer Zielerfüllung im Zielintervall von 22 Prozent entspricht: (100 - 80) / (100 - 10) = 0,22 (gerundet). Jede Kennzahlengruppe kann durch diese Art der Berechnung als eigenständige Kennzahl verstanden werden. Diese gibt die Zielerfüllung bezogen auf das Gestaltungsziel (im Beispiel Standardisierung der Technologien) an. Im Beispiel beträgt der Standardisierungsgrad der Technologien 27,4 Prozent. Der vom CIO vorgegebene Zielwert könnte 90 Prozent lauten, die deutliche Verfehlung bedeutet im konkreten Fall, dass die Kennzahlen der Kennzahlengruppe beginnend mit der niedrigsten (also der größten Abweichung vom Zielwert) genauer untersucht werden, um Maßnahmen in der IT-Architektur abzuleiten (vgl. Abschnitt 6.7.5.3). 6.7.5.3 Identifikation von Handlungsbedarfen Die Absicht des IT-Architektur-Managements ist es, eine Soll-IT-Architektur aufzustellen, die einen höheren Wert für das Unternehmen bietet als die bestehende Ist-Architektur. Dazu werden Verbesserungspotenziale innerhalb der Ist-IT-Architektur identifiziert und darauf aufbauend diese Potenziale über konkrete IT-Architektur-Maßnahmen realisiert. Der Ist-Zustand und die Soll-IT-Architektur lassen sich mittels der IT-ArchitekturKennzahlen charakterisieren. Darüber hinaus ermöglichen die Kennzahlen eine Analyse des Ist-Zustands hinsichtlich der Gestaltungsziele (vgl. Abschnitt 6.7.2) und das Priorisieren von Handlungsfeldern. Ausgehend von der Zielerfüllung einer Kennzahlengruppe wird, vergleichbar einem Drill-down, auf die Ebene der zugrunde liegenden Bestandteile und deren spezifische Kennzahlen zurückgegriffen, um gezielt auffällige Bestandteile und damit potenzielle Handlungsbedarfe zu identifizieren. Die Durchführung einzelner Maßnahmen zur Verbesserung der IT-Architektur wird nach einer Detailanalyse beschlossen, in der der konkrete Nutzen der jeweiligen IT-Architektur-Maßnahme bestimmt wird. Analysemöglichkeiten durch die Kombination der IT-Architektur-Kennzahlen sind sehr umfangreich. Folgende Absätze zeigen einige relevante Beispiele. IT-Infrastruktur: Standardisierung der Technologien Zur Erhöhung der Standardisierung der Technologien werden in der IT-Infrastruktur zunächst Cluster mit Standardisierungspotenzialen identifiziert. Abbildung 6-28 zeigt eine mögliche Verknüpfung der IT-Architektur-Kennzahlen.

Wertbeitrag von IT-Architekturen

Allgemeine Kennzahl IA.T.1.1 IA.T.3.2

IA.C.3.2

Anzahl Technologien Anteil der potenziell redundanten Technologien über alle Cluster Anteil Cluster mit Anzahl Technologien > 6

147

Clusterbezogene Analyse

Technologiebezogene Analyse je Cluster

Cluster

IS.C.3 Anzahl der potenziell redundanten Technologien je Cluster X

Technologien im Cluster '%06

IS.T.1.1 Anzahl Applikationen, die Technologie X nutzen

DBMS

8

Orcale 10g

4

OLAP

6

Oracle 9g

23

DB-Client

6

Oracle 8i

18

MySQL 4.2

4

IBM DB2 Express 9

8

IBM DB2 8.2

4

Microsoft SQL Server 2000

19

Microsoft SQL Server 2005

3

Abbildung 6-28 Analyse zum Handlungsbedarf Standardisierung der Technologien (Beispiel)

Ausgehend von den allgemeinen Kennzahlen wird für jedes Cluster die Anzahl der potenziell redundanten Technologien bestimmt. Cluster mit einem hohen Kennzahlenwert bieten mit einer großen Wahrscheinlichkeit Optimierungspotenzial. Für Cluster mit vielen Technologien (im Beispiel mehr als sechs) werden die Technologien analysiert, um herauszufinden, ob und wie deren Anzahl für diesen Cluster reduziert werden kann. In Abbildung 6-28 gibt die Kennzahl VS.E.1.1 Auskunft darüber, wie viele Applikationen eine Technologie im ausgewählten Cluster nutzen. Damit liegen erste Anhaltspunkte für den notwendigen Migrationsaufwand vor: Falls das Ziel für die Kennzahl IA.C.2 Dstl. Anzahl Technologien je Cluster wie im Beispiel 1,5 ist, müssen zur Zielereichung die Technologien im Cluster DBMS stark reduziert werden. Falls eine Vorgabe in der IT-Architektur-Strategie für den Cluster existiert (z. B. Microsoft SQL Server 2005 wie im Beispiel aus Abschnitt 5.3.1), sind alle Applikationen, die statt der Vorgabe eine andere Technologie aus dem Cluster verwenden, zu migrieren. Falls keine explizite Vorgabe existiert, empfiehlt sich eine Migration auf eine der häufig verwendeten und modernen, zukunftsfähigen Technologien (vgl. Abschnitt 5.4). Je mehr Applikationen eine zu migrierende Technologie einsetzen, umso aufwendiger ist die Migration dieser Technologie. Für die Analyse lassen sich mehrere IT-Architektur-Kennzahlen parallel untersuchen. Z. B. kann neben der Anzahl Applikationen, in denen eine Technologie eingesetzt wird, der Lieferant jeder einzelnen Technologie angegeben werden. Eine Option ist es dann, Technologien von nicht bevorzugten Lieferanten in Abhängigkeit von deren Verwendung in Applikationen eher zu migrieren als andere. IT-Infrastruktur: Service-Orientierung Ausgehend von IA.A.4.2 Anteil Applikationen, die Plattformen nutzen bzw. IA.A.4.3 Dstl. Anzahl genutzter Plattformen je Applikation werden über die Kennzahl IS.A.1.2 Anzahl Plattformen, die von Applikation X genutzt werden diejenigen Applikationen identifiziert, die

148

Wertbeitrag von IT-Architekturen

keine oder wenige Plattformen nutzen. Diese können dann gezielt auf einen möglichen Plattformeinsatz untersucht werden. Ausgehend von der Kennzahl IA.P.3.1 Anzahl Applikationen, von denen eine Plattform dstl. genutzt wird kann für jede Plattform die Anzahl Applikationen, die diese verwenden, aufgezeigt werden (IS.P.2.1 Anzahl Applikationen, die Plattform X nutzen). Für Plattformen mit einer geringen Verwendung sind zusätzliche Einsatzbereiche zu identifizieren oder diese sind, z. B. wegen zu hoher Spezifizität bezüglich einzelner Applikationen, in Frage zu stellen und gegebenenfalls aus dem IT-Portfolio zu entfernen. Betrachtet man ausgehend von der Kennzahl IA.P.4.2 Anteil potenziell redundanter Plattformen, die Kennzahl IS.P.3 Anzahl um Z % ähnlicher Plattformen für Plattform X können redundante Plattformen gefunden werden. IT-Infrastruktur: Vollständigkeit der Technologien Ausgehend von IA.C.1 Anzahl Cluster bzw. IA.L.2.1 Dstl. Anzahl Cluster pro Layer wird die spezifische Kennzahl IS.L.2 Anzahl Cluster im Layer X für jeden Layer untersucht, um bei einem auffällig niedrigen Wert in der Detailanalyse technologische Lücken aufdecken zu können. Insbesondere ermöglicht die Einteilung in Cluster einen Vergleich mit anderen Unternehmen, um nicht vorhandene, aber sinnvolle Technologien zu identifizieren. IT-Bebauungsplan: Funktionale Vollständigkeit Anhand der Kennzahlen können in der IT-Bebauung Lücken in der IT-Unterstützung aufgedeckt werden. Bei einem zu hohen Anteil Matrixfelder Prozess/Sparte, die nicht von IT unterstützt werden (BA.M.3.2) sind die Felder im IT-Bebauungsplan ohne Applikationen auf einen möglichen IT-Einsatz zu untersuchen. Ebenso werden Felder mit auffällig wenigen Applikationen identifiziert (BS.M.1 Anzahl Applikationen je Prozess X und Sparte Y). Für jeden Prozess kann die Kennzahl BS.PR.3 Streuungsgrad über Sparten je Prozess X erhoben werden. Je höher die Streuung, umso eher ist der Prozess genauer zu untersuchen, da entweder in manchen Sparten zu viele oder in anderen zu wenige Applikationen eingesetzt werden. Eine niedrigere Streuung sagt allerdings nichts über die Qualität der ITArchitektur aus: Diese Kennzahl ist deshalb mit der Anzahl der Applikationen je Prozess (BS.PR.1) zu kombinieren, um bei zufällig gleicher Anzahl an Applikationen in verschiedenen Sparten diesen Prozess aufgrund einer hohen Anzahl an Applikationen weiter zu untersuchen (vgl. Abbildung 6-29).

Wertbeitrag von IT-Architekturen

Kennzahl BS.PR.3

Streuungsgrad über die Sparten je Prozess X

149

Prozessbezogene Analyse Prozess

BS.PR.3 Streuungsgrad über Sparten je Prozess X

BS.PR.1 Anzahl Applikationen je Prozess X

Produktentwicklung (PE)

2,65

9

Vertrieb

0,00

9

Antrag

1,53

4

Matrixfeldbezogene Analyse Matrixfeld 3UR]HVVÄ3(³ XQG6SDUWH
3H\U@ Zahlreiche Softwarehersteller haben diesen Bedarf erkannt und bieten kommerzielle Standardsoftware für das IT-Architektur-Management an. Sowohl die Kosten in Anschaffung und Betrieb als auch der Leistungsumfang der einzelnen Softwarewerkzeuge unterscheiden sich erheblich. DURST und SCHÖNLEIN haben 15 EA Tools in einer Studie untersucht und bewertet [DuSc05], GARTNER und FORRESTER haben ebenfalls Untersuchungen vorgelegt [Jame04; Peyr04]. Der Markt für EA Tools ist sehr volatil, kein allgemeiner Standard oder Best Practice konnte sich bis dato durchsetzen [Jame04, 6]. Allen EA Tools gemein sind hohe Kosten und die aufwendige Implementierung [DuSc05, 30]. Das in diesem Kapitel vorgestellte ,7$UFKLWHNWXU0DQDJHPHQW3RUWDO verwendet grafische Darstellungen der Modelle IT-Bebauungsplan und IT-Infrastruktur, basiert auf Open Source-Technologien und liefert die in Abschnitt 6.7 vorgestellten Kennzahlen. Das Kürzel ,70$3 wird als Bezeichnung für das Portal verwendet. Dieses Akronym gibt durch die Komponenten ,7 und 0$3 einen Hinweis auf die grafische, kartenartige Darstellung der ITArchitektur.

7.3

Anforderungen

SCHEKKERMAN [Sche06, 2 - 5] benennt folgende grundlegende Anforderungen an ein ITArchitektur-Portal 128:

x

Ein konsistentes Modell soll die Basis des IT-Architektur-Portals bilden.

x

Die Benutzerumgebung für die Anzeige und Verwaltung des Modells soll intuitiv gestaltet sein. Diese soll den zur Verfügung stehenden Raum am Bildschirm effizient ausnutzen. Außerdem sollte sie die allgemeinen Standards des Betriebssystems bezüglich der Benutzerschnittstellen (wie z. B. Formulare oder Reaktionen auf Benutzereingaben) einhalten.

x

Der Anwender soll durch die teilweise Übernahme trivialer Bestandteile der Modellierung mittels Automatisierung oder selektiver Vorauswahl unterstützt werden.

128

Schekkerman definiert ein Enterprise Architecture Tools review framework [Sche06, 1], das über die Anforderungen an ein IT-Architektur Portal hinausgeht. Daher sind hier nur die Anforderungen aufgeführt, die für eine Software zur Verwaltung von IT-Architekturen relevant sind.

IT-Architektur-Management-Portal

x

169

Das Portal soll Funktionalitäten zur Analyse und Verwaltung von Modellbestandteilen anbieten.

x

Die Beschränkung der Anzeige mittels selektiver Auswahlfunktionen soll möglich sein. Das IT-Architektur-Portal gibt Hinweise auf Redundanzen und fehlende Bestandteile im Modell.

x

Ein Repository129 soll die Ablage und Wiederverwendung der Modelldaten ermöglichen. Idealerweise sollte das Portal hierbei Funktionen zur Versionierung bereitstellen, sowie eine Beschränkung des Lese- und Schreibzugriffs auf bestimmte Teile des Modells erlauben.

GARTNER nennt folgende, teils mit SCHEKKERMANN übereinstimmende Anforderungen [Jame03]:

x

Technologielisten sollen einen Überblick über die im Unternehmen vorhandenen Technologien ermöglichen.

x x

Ein konsistentes Informationsmodell bildet die Grundlage der Modellierung. Die Darstellung aller Applikationen als Liste soll einen Überblick über alle Applikationen im Unternehmen ermöglichen.

x

Verweise zwischen Applikationen und Technologien stellen ein Verständnis für den Zusammenhang zwischen Technologien und Applikationen her.

x

Das Portal soll die Modellierung eines Architekturframeworks unterstützen. Dieses Framework kann dabei unternehmensindividuell gestaltet sein oder auf einen Standard zurückgreifen.

x

Die Komponenten der IT-Architektur und die IT-Architektur als Ganzes sollen versionierbar sein.

x

Verknüpfungen zu anderen Modellierungsapplikationen (z. B. Microsoft Visio oder ARIS von IDS Scheer) sollen den schnittstellenfreien Austausch von Modellen ermöglichen.

x

Der Zugriff soll rollen- und rechtebasiert erfolgen (eine nichtfunktionale Anforderung, die unten weiter erläutert wird).

x

Die Informationen aus dem Portal sollen im gesamten Unternehmen verfügbar sein, wenn möglich durch einen Internetbrowser. Die Ausgabe der grafischen Darstellungen als Ausdruck soll möglich sein.

129

Ein Repository ist eine Verzeichnisstruktur oder Datenbank, die Datenobjekte und deren Methoden zur Datentransformation enthält.

170

x

IT-Architektur-Management-Portal

Die Applikationen und Technologien sollen mit den Geschäftsprozessen und weiteren Attributen (z. B. Sparten) verknüpfbar sein.

x

Eine hohe Verfügbarkeit im Unternehmen muss gewährleistet sein (eine nichtfunktionale Anforderung, die unten weiter erläutert wird).

x

Das IT-Architektur-Management-Portal soll verschiedene Sichten auf die ITArchitektur ermöglichen und flexibel erweiterbar sein.

Nichtfunktionale Anforderungen sind 130:

x

Ein beliebiger Browser auf Basis einer Thin-Client-Architektur soll als Benutzerschnittstelle dienen. Die Softwaredistribution und -pflege kann damit erfolgen, ohne am PC des Anwenders Komponenten installieren zu müssen. Alle Applikationslogik wird vom Server zur Verfügung gestellt. Die Verfügbarkeit im Intranet und je nach Konfiguration auch im Extranet eines Unternehmens ist damit sichergestellt.

x

Alle eingesetzten Technologien sollen unter Open Source-Lizenzen verfügbar sein. Kosten für Softwarelizenzen werden so vermieden und vielfältige Erweiterungsoptionen ermöglicht.

x

Die Anwenderzugriffe auf das Portal sollen durch ein konfigurierbares Rollen- und Rechtemodell organisiert werden können. Anwender von ITMAP sollen je nach Aufgabe verschiedene Zugriffsberechtigungen auf ITMAP haben.

x

Das Portal soll in mehreren Sprachen zur Verfügung stehen. Alle Benutzeroberflächen in ITMAP sollen so programmiert sein, dass die Sprache geändert werden kann. Deutsch und Englisch sollen von jedem Anwender je nach Präferenz selbst ausgewählt, weitere Sprachen sollen nach Bedarf hinzugefügt werden können.

x

ITMAP soll über einen Anmeldevorgang verfügen, der über den Benutzernamen und ein individuelles Passwort den Benutzer und seine Rechte im Portal erkennt und nur die Oberflächen und Funktionen (z. B. Betrachten, Verändern, Speichern, Löschen) zur Verfügung stellt, die der jeweilige Anwender verwenden darf.

x

Die Performanz des Portals soll mehrere parallele Zugriffe erlauben. ITMAP soll so gestaltet sein, dass die Performanz an hohe Zugriffszahlen angepasst werden kann 131.

130 131

Nichtfunktionale Anforderungen an Softwarewerkzeuge sind z. B. in Abschnitt 5.4 aufgeführt. Die Performanz von ITMAP spielt eine untergeordnete Rolle, da es sich in der vorgestellten Implementierung um einen einsatzfähigen Prototyp handelt, der nicht auf hohe Zugriffszahlen konfiguriert ist.

IT-Architektur-Management-Portal

7.4

171

Softwarearchitektur

Ausgehend von den Anforderungen aus Abschnitt 7.3 basiert ITMAP auf einer dreischichtigen Softwarearchitektur bestehend aus Benutzerschnittstelle, Applikations- und Datenbankserver. Als Technologien dienen Linux als Betriebssystem, Apache als Web- und Applikationsserver, MySQL als Datenbankserver und PHP als Programmiersprache. Diese Kombination hat sich in der Open Source-Programmierung unter dem Kürzel LAMP weitgehend durchgesetzt und wird in einem Großteil der so genannten Webapplikationen verwendet. Java als Programmiersprache kommt in einem Bestandteil (dem hyperbolischen Browser) von ITMAP zum Einsatz, um eine komplexe Visualisierung zu realisieren. 7.4.1

Framework

ITMAP basiert auf einem Programmierframework auf Basis von PHP 5, das ausschließlich für diese Implementierung entwickelt wurde. Das Framework hat den Zweck, einige Schwächen von PHP 5 zu korrigieren und die Implementierung, spätere Erweiterungen und Einbettungen in bestehende Applikationslandschaften 132, zu erleichtern. Das ITMAP-Framework erfüllt vier fundamentale Aufgaben. Zum einen stellt es einen methodischen Rahmen für die Unterstützung der eigentlichen Portalentwicklung dar. Des Weiteren schafft es eine technische Integrationsplattform für zukünftige Applikationsmodule und sieht die Einbindung von Services vor, die einzelnen Applikationsmodulen zur Verfügung stehen. Weiterhin definiert das Framework Schnittstellen für das Zusammenwirken von einzelnen Komponenten des Portals. Die fachlichen Anforderungen an das Framework lauten:

x

ITMAP soll durch eine hohe Modularität des Frameworks einfach erweiterbar sein.

x

Das Framework soll eine Rollen- und Rechteverwaltung sowie die Möglichkeiten zum Zugriff auf einen Verzeichnisdienst unterstützen.

x

Durch die Unterstützung von Templates 133 soll das Framework eine flexible Modifikation der Präsentationsschicht des Portals ermöglichen (z. B. zur optischen Integration in ein Unternehmensportal).

x

Das Framework soll die Ausgabe von verschiedenen Darstellungsformen und -formaten unterstützen (z. B. PDF, SVG, HTML, RSS oder WAP).

x

132

133

Eine schriftliche Dokumentation soll die Wiederverwendbarkeit sicherstellen.

Genannt sei hier z. B. die Anbindung des Anmeldevorgangs in ITMAP an einen unternehmensweiten Rechte- und Rollenverwaltungsdienst. Bekannte Vertreter dieser so genannten Verzeichnisdienste oder Directory Services sind Active Directory von Microsoft, eDirectory von Novell oder Dir.X von Siemens. Templates (Vorlagen) ermöglichen die Trennung von Layout, Inhalt und Struktur. Das Design der Benutzerschnittstelle kann damit unabhängig von der Programmlogik verändert werden.

172

x

IT-Architektur-Management-Portal

Durch die Einhaltung von Programmierstandards soll die schnelle Einarbeitung ermöglicht werden.

x

Die Integration in ein Single Sign-On Verfahren eines Unternehmensportals soll möglich sein.

Die technischen Anforderungen lauten:

x

Geringer Mehraufwand durch das Framework 134

x

Trennung von Applikations- und Präsentationslogik

x

Debugging-Funktionalitäten 135 bei der Applikationsentwicklung

x

Einheitliche und verständliche Dokumentation im Programmcode

Um die genannten Anforderungen in einem Programmierframework abzubilden, eignet sich eine Kombination aus einer dreischichtigen und einer Model-View-Controler (MVC) 136 Softwarearchitektur. Die dreischichtige Softwarearchitektur besteht aus Präsentations-, Anwendungs- und Datenschicht. Nahezu alle Webapplikationen sind prinzipiell auf diesem Konzept aufgebaut. MVC trennt die Programmlogik einer Applikation von der Präsentationsschicht. Der Controller bestimmt, wie die Applikation auf Benutzereingaben reagiert. [Swea03a, 10] Auch wenn die dreischichtige Softwarearchitektur und MVC die Zusammenfassung von Applikationsbestandteilen zur Datenausgabe in einer Präsentationsschicht vorsehen und sich von der Konzeption stark ähneln, gibt es einige Unterschiede. Die dreischichtige Softwarearchitektur nimmt eine Trennung zwischen dem Datenzugriff und der Anwendungsschicht vor. Demgegenüber trennt MVC innerhalb der Anwendungsschicht zwar die Darstellung der Daten und deren Verarbeitung, lässt jedoch den Ursprung der Daten und den Zugriff auf diese außer Acht. Um die Vorteile sowohl der dreischichtigen Softwarearchitektur als auch von MVC zu nutzen, wird das ITMAP-Framework mit den Ebenen Datenabstraktion, Applikationsobjekte, Applikationslogik und Präsentationsschicht realisiert. Das so genannte DMAV-Framework (Data, Model, Action, View) bildet die programmiertechnische Grundlage der Implementierung von ITMAP. Abbildung 7-2 zeigt das zu Grunde liegende Schichtenmodell.

134

135

136

Mehraufwand durch ein Framework im Vergleich zur Programmierung ohne ein Framework entsteht für den Programmierer durch die Einarbeitung in die Funktionsweise und die Standards, die das Framework vorgibt. Das Debugging (Fehlerbereinigung) soll bereits während der Programmierung und nicht erst zu einem späten Zeitpunkt im Lebenszyklus beim Testen von Applikationsmodulen möglich sein. Model View Controller (MVC) bezeichnet ein Architekturmuster zur Aufteilung von Applikationen in die drei Schichten Datenmodell (Model), Präsentation (View) und Programmsteuerung (Controller). Das Ziel ist ein flexibles Programmdesign, um u. a. eine spätere Änderung oder Erweiterung einfach zu halten und die Wiederverwendbarkeit der einzelnen Programmbestandteile zu ermöglichen.

IT-Architektur-Management-Portal

173

ITMAP-Framework

Benutzereingabe Controller

View Action Model

Datenabstraktion

Datenbank Abbildung 7-2

Funktionsweise des ITMAP-Frameworks

Nachdem der Anwender eine Anfrage an ITMAP gesendet hat 137, entscheidet der Controller, welcher Teil der in Actions gekapselten Applikationslogik auszuführen ist. Eine Action fordert gegebenenfalls von der Datenabstraktionsschicht ein Model an, das durch Zugriff auf eine Datenbank erstellt wird. Abschließend sendet die Action das Ergebnis über die in Views gekapselte Präsentationslogik an den Anwender zurück. 7.4.2

Benutzerschnittstelle

$OV7HFKQRORJLHIUGLH%HQXW]HULQWHUDNWLRQGLHQWDXVVFKOLH‰OLFKGHU%URZVHU±VRZRKO]XU Anwendung als auch zur Administration von ITMAP. Damit ist ein betriebssystemunabhängiger und installationsfreier Zugang zu ITMAP gewährleistet. Die Einschränkungen eines Webbrowsers stehen teilweise in Konkurrenz zu den Anforderungen der Visualisierung von komplexen Zusammenhängen in IT-Architekturen. Einschränkungen sind unter anderem:

x

Limitierungen in der Dynamik der Darstellung, z. B. bei Größenanpassungen von grafischen Bildschirmausgaben

137 138

x

Limitierungen bei grafischen Darstellungen

x

Limitierungen in der Interaktion, z. B. bei Drag and Drop 138

x

Limitierungen in der möglichen Ausdehnung von grafischen Darstellungen

(LQHVROFKH$QIUDJHN|QQWH]%Ä]HLJHHLQH/LVWHDOOHU$SSOLNDWLRQHQDQ³ODXWHQ Drag and Drop (Ziehen und Fallenlassen) ist eine Methode zum Bewegen grafischer Elemente in einer Bildschirmschnittstelle mit der Maus. Ein Element der grafischen Benutzeroberfläche kann damit gezogen und über dem gewünschten Ziel losgelassen werden. Dieses kann z. B. markierter Text oder das Symbol einer Datei sein.

174

IT-Architektur-Management-Portal

x

Limitierungen bei der Zwischenspeicherung von Formularen (Formulardaten werden im Browser erst durch eine Eingabe des Anwenders gespeichert und nicht bereits beim Verlassen des Formularfeldes)

Folgende Anforderungen an die Benutzerschnittstelle sind von den Beschränkungen eines Browsers besonders betroffen:

x

Dynamische Generierung von Grafiken, die sich überlagern und bei Kontakt mit dem Mauszeiger die Position wechseln können (von einer Hintergrund- in eine Vordergrundposition)

x

Darstellung von Netzstrukturen in Form eines Fisheye View 139

x

Dynamische visuelle Effekte zur Unterstützung der Benutzerführung. Der Anwender soll z. B. in Tabellen intuitiv erkennen können, welche Einträge durch Klicken weitere Informationen bieten und welche nicht

x

Darstellung komplexer Strukturen innerhalb eines Bildschirmfensters. Horizontales Scrolling in einem Webbrowser ist nie über einen experimentellen Stand heraus von Benutzern akzeptiert worden 140 und ist daher gänzlich zu vermeiden. Vertikales Scrolling soll nur Anwendung finden, wenn die Benutzerfreundlichkeit durch die Klicktiefe in Einzelfenstern stärker beeinträchtigt wird als durch vertikales Scrollen in einem Fenster

Weiterhin sind die unterschiedlichen Ausprägungen von verschiedenen Browservarianten (z. B. Mozilla Firefox, Microsoft Internet Explorer oder Apple Safari) ebenso zu beachten wie das dem Browser zu Grunde liegende Betriebssystem. ITMAP ist als unternehmensinterne Applikation konzipiert, daher können seltene Browsertypen ebenso wie seltene Betriebssysteme ausgeschlossen werden 141. Der Fokus liegt somit bei den ClientBetriebssystemen auf der Windows-Familie ab der Version 2000 und auf Apple OS X 142 und bei den Browsermodellen auf Internet Explorer (ab Versionsnummer 5), der MozillaFamilie 143 und Safari (ab Versionsnummer 2). 7.4.3

Applikationsserver

Der Applikationsserver beinhaltet die Programmlogik von ITMAP. PHP-basierte Applikationen benötigen einen Apache-Webserver zum Parsen des Quellcodes. Apache wurde ur139

Fisheye Views sind Übersichten von komplexen Strukturen, bei denen jeweils nur die interessantesten Knoten angezeigt werden. Als interessant gelten diejenigen Knoten, die entweder in der Nähe des aktuellen Standortes liegen oder die ganz allgemein als wichtig definiert sind. 140 NIELSEN VWHOOW GD]X IHVW Ä:H NQRZ IURP XVHU WHsting that users hate horizontal scrolling and DOZD\VFRPPHQWQHJDWLYHO\ZKHQWKH\HQFRXQWHULW³>1LHO@ 141 >%XUQ@ JLEW IU GLH %URZVHU Internet Explorer, Mozilla und Firefox einen Marktanteil von über 3UR]HQW LP $SULO  DQ :HLWHUH 0DUNWGDWHQ PLW lKQOLFKHQ (UJHEQLVVHQ OLHIHUQ >2QH6@ >7KH&@XQG>1HW$D@ 142 >1HW$E@ JLEW IU GLe Client-Betriebssysteme Windows 2000, Windows XP und Mac OS einen Marktanteil von über 93 Prozent an. 143 %HLVSLHOHVLQG)LUHIR[0R]LOOD$SSOLFDWLRQ6XLWHXQG1HWVFDSHDE9HUVLRQVQXPPHU

IT-Architektur-Management-Portal

175

sprünglich für Unix-Betriebssysteme und deren Derivate entwickelt. Als Applikationsserver dient hier ein Linux-Server. Dieser kann jedoch durch ein nahezu beliebiges UNIX-Derivat ersetzt werden. Linux wurde aufgrund der hohen Verbreitung 144 und des Open SourceQuellcodes ausgewählt. 7.4.4

Datenbankserver

Aufgrund der hohen Verbreitung kommt als Open Source-Datenbankserver ein MySQL in der Version 4 zum Einsatz. Dieser wird ebenfalls auf Linux betrieben und in der vorliegenden Implementierung auf der gleichen Serverhardware, den auch der Applikationsserver nutzt, installiert. Abbildung 7-3 zeigt eine Übersicht über die Softwarearchitektur von ITMAP.

ITMAP-Framework

Benutzerschnittstelle

Webbrowser

Controller

View Action Model

Datenabstraktion

Datenbank Abbildung 7-3

7.5

PHP, Apache und Linux

MySQL und Linux

Technologien im ITMAP-Framework

Modellierung

Das Datenmodell als Grundlage der Modellierung umfasst alle Komponenten einer ITArchitektur und abstrahiert diese in Form eines relationalen Modells. Die auf dem Datenmodell aufbauenden Applikationsbestandteile werden in Administration, Reporting und Controlling gegliedert. 7.5.1

Datenmodell

Ausgehend von den Modellen der IT-Infrastruktur und des Bebauungsplans ergeben sich die Entitätstypen für das Datenmodell. Ein Entitätstyp ist nach CHEN definiert als

144

Nach einer Studie von IDC und GARTNER hatte Linux bei Serverbetriebssystemen im Jahr 2005 einen Marktanteil von zwölf Prozent und war damit das am weitesten verbreitete Open SourceServerbetriebssystem hinter den kommerziellen Betriebssystemen Windows und UNIX (kommerzielle Derivate wie Solaris oder AIX) [Heis05].

176

IT-Architektur-Management-Portal

Ä=XVDPPHQIDVVXQJ DOOHU JOHLFKDUWLJHQ (QWLWlWHQ GK 5HSUlVHQWDWLRQHQ HLQHV NRQNUHWHQRGHUDEVWUDNWHQ *HJHQVWDQGVGHUIUHLQJHJHEHQHV$QZHQGXQJV V\VWHPYRQ%HGHXWXQJLVWXQWHUHLQHPJHPHLQVDPHQ2EHUEHJULII³>&KHQ@ Neben den in Abbildung 3-18 vorgestellten Entitäten der IT-Architektur sind drei abstrakte Entitätstypen notwendig (in der Tabelle kursiv gekennzeichnet), um das umfassende Datenmodell für das IT-Architektur Portal zu komplettieren (vgl. Tabelle 7-1). Modell

Bebauungsplan

Bebauungsplan

Bebauungsplan

Bebauungsplan

Bebauungsplan

145

Entitätstyp

Prozess

Sparte

Applikation

'RNXPHQWDWLRQHLQHU $SSOLNDWLRQ 

Person

Attribute x

Name

x

Zugehörigkeit zu einem übergeordneten Prozess (optional)

x

Status

x

Name

x

Zugehörigkeit zu einer übergeordneten Sparte (optional)

x

Status

x

Name

x

Zugehörigkeit zu einer übergeordneten Applikation (optional)

x

Lebenszyklus (optional)

x

Funktionale Abhängigkeit von einer anderen Applikation (optional)

145

x

Status

x

Zuordnung zu einer Applikation

x

Name

x

Beschreibung

x

URL (optional)

x

Pfad zu einer Datei (optional)

x

Dateigröße (optional)

x

Dateiformat (optional)

x

Status

x

Name

x

Kontaktdaten

x

Verantwortlichkeiten

x

Rolle

x

Status

Mögliche Status dieses wie auch der folgenden Entitätstypen sind: 3ODQXQJ, (QWZLFNOXQJ, (LQVDW], ,Q$EO|VXQJ und (LQVDW]EHHQGHW.

IT-Architektur-Management-Portal

Modell

Entitätstyp

IT-Infrastruktur

Basistechnologie

IT-Infrastruktur

IT-Infrastruktur

IT-Infrastruktur

IT-Infrastruktur

IT-Infrastruktur

Tabelle 7-1

Technologie

177

Attribute x

Name

x

Hersteller

x

Version

x

Beschreibung

x

Status

x

Verwendete Basistechnologie

x

Beschreibung der Verwendung

x

Lebenszyklus

x

Funktionale Abhängigkeit von einer anderen Technologie (optional)

x

Status

Dokumentation (einer

x

Zuordnung zu einer Technologie

Technologie)

x

Name

x

Beschreibung

x

URL (optional)

x

Pfad zu einer Datei (optional)

x

Dateigröße (optional)

x

Dateiformat (optional)

x

Status

x

Name

x

Beschreibung

x

Auswahl an Technologien

x

Status

x

Name

x

Enthaltene Technologien

x

Status

x

Name

x

Enthaltene Cluster

x

Status

Plattform

Cluster

Layer

Entitätstypen im Datenmodell von ITMAP

178

IT-Architektur-Management-Portal

Abbildung 7-4 visualisiert die Beziehungen der einzelnen Entitätstypen untereinander. n

Sparte

1

gehört zu n

m Prozess

unterstützt

1

Applikation

n

unterstützt

n

n

Dokumentation

verwendet

verwendet

n

m

m

beschreibt

1

n

Technologie

n

gehört zu

m

n

beschreibt

1

n

gehört zu

m

Plattform

n

gehört zu

1

Cluster

ist Instanz von

1

Basistechnologie

n

gehört zu

Abbildung 7-4

1

Layer

Entity-Relationship-Diagramm für ITMAP

Das schematische ERM aus Abbildung 3-18 wird erweitert um Dokumentation und Basistechnologie. Der Entitätstyp Dokumentation ermöglicht den Verweis auf Dateien, die weitere Informationen zu einer Technologie oder Applikation enthalten. Basistechnologie ist ein Datenspeicher für alle Technologien, die im Unternehmen vorhanden sind oder waren oder zukünftig zum Einsatz kommen sollen. Der Entitätstyp Technologie bedient sich aus diesem Datenspeicher und beinhaltet nur Technologien, die einem Cluster zugeordnet sind. Prozesse und Sparten können hierarchisch gegliedert werden.

IT-Architektur-Management-Portal

7.5.2

179

Administration

Die Administration des Datenmodells von ITMAP besteht aus dem Erstellen und Anzeigen von Technologien, Applikationen, Plattformen, Layern, Clustern, Sparten, Prozessen und Basistechnologien. Um eine einfache Bedienung zu gewährleisten, bietet ITMAP folgende unterstützende Funktionen an:

x

Eine Suchfunktion über alle Attribute der Entitätstypen

x

Ein Kalendermodul, das die Eingabe der Lebenszyklusdaten unterstützt

x

Ein Sprachenmodul, das den dynamischen Wechsel der Sprache in der Benutzeroberfläche ermöglicht

x

Eine Funktionalität zur Sicherstellung konsistenter Benutzereingaben. So kann z. B. ein Layer nicht gelöscht werden, wenn sich noch Cluster in diesem befinden

7.5.3

Reporting

Der Bereich Reporting in ITMAP umfasst alle Funktionalitäten zur Dokumentation, Visualisierung und Kommunikation der IT-Architektur. Der Fokus liegt dabei auf der Darstellung des Bebauungsplans und der IT-Infrastruktur, der Beziehungen und Abhängigkeiten der Entitäten untereinander und der Lebenszyklen der Technologien und Applikationen. 7.5.3.1 Listen ITMAP stellt Listenfunktionen zur alfabetisch sortierten Ansicht von Basistechnologien, Technologien, Applikationen, Prozessen, Sparten, Clustern, Layern und Plattformen zur Verfügung. Abbildung 7-5 zeigt einen Ausschnitt aus der Liste der Technologien.

IT-Architektur-Management-Portal

181

sich eine Applikation befindet. Weiterhin werden Verletzungen der Architekturkonformität von Applikationen durch eine rote Umrandung hervorgehoben (vgl. Abbildung 7-6).

Abbildung 7-6

Bebauungsplan in ITMAP

Die Farben sind folgendermaßen den Lebenszyklen der Applikationen zugeordnet:

x

Lebenszyklus nicht gesetzt: Helles Orange

x

Planung: Hellgrün

x

Entwicklung: Dunkelgrün

x

Einsatz: Blau

x

In Ablösung: Dunkles Orange

x

Einsatz beendet: Rot

Im IT-Bebauungsplan in ITMAP werden mögliche Detaillierungen gekennzeichnet, indem der Prozess, zu dem Unterprozesse existieren oder die Sparte, die weiter in Untersparten oder Produkte aufgegliedert ist, unterstrichen sind. Der Anwender kann auf diesen Link klicken und erhält einen Detailbebauungsplan. Die Ebenen der Detaillierung sind softwareseitig nicht begrenzt. 7.5.3.3 IT-Infrastruktur Die aus Abbildung 3-11 bekannte Abbildung der Technologien, Cluster und Layer wird in ITMAP als Ausschnittsdarstellung mit Fokus auf jeweils einen Layer realisiert. Falls alle

182

IT-Architektur-Management-Portal

Layer, Cluster und Technologien in einer Bildschirmmaske angezeigt werden würden, würde sich die Darstellung über mehrere Bildschirmlängen ausdehnen, ein langes Scrollen wäre unvermeidlich. Mit dem Fokus auf jeweils einen Layer wird dies vermieden (vgl. Abbildung 7-7).

Abbildung 7-7

IT-Infrastruktur in ITMAP

Die Technologien werden als Link dargestellt, der Linktext zeigt den Namen und die Version der Technologie an. Weitere Informationen (vgl. Tabelle 7-1) erhält der Anwender beim Klicken auf eine Technologie. In Abbildung 7-7 wird der Layer Clientspezifikation angezeigt. Um den Fokus auf einen anderen Layer zu wechseln, klickt der Anwender auf einen der Links auf der linken Bildschirmseite. Hier werden alle inaktiven Layer mit einem grauen Hintergrund angezeigt, der aktive Layer ist weiß hinterlegt und der Name des aktiven Layers wird fett und nicht unterstrichen dargestellt. Die Bezeichnungen der Cluster sind blau hinterlegt und können ebenfalls angeklickt werden, um weitere Informationen zum Cluster zu erhalten oder um das Cluster zu bearbeiten.

IT-Architektur-Management-Portal

183

7.5.3.4 Hyperbolischer Browser Die in ITMAP verwendeten Listendarstellungen können je nach Unternehmen sehr umfangreich sein. Die Geschäftsprozesse eines Versicherungsunternehmens umfassen z. B. bereits bei drei Modellierungsebenen über 70 Einzelprozessschritte. Die Listenansicht wird bei weiterer Detaillierung sehr unübersichtlich, ein intuitives Gesamtbild über die Geschäftsprozesse und Sparten ist für den Betrachter nur mühsam erschließbar (vgl. Abbildung 7-8).

Abbildung 7-8

Liste der Prozesse in ITMAP

Als alternative Darstellung von langen Listen oder Baumstrukturen eignet sich ein hyperbolischer Browser. Dieser stellt im Webbrowser eine Netzstruktur dar, die ausgehend von einem Knoten alle Verzweigungen zu anderen Knoten anzeigt, die Größe der Knoten jedoch je nach Entfernung immer kleiner werden lässt. Eine intuitive Navigation wird so möglich (vgl. Abbildung 7-9) 146.

146

Eine ausführliche Diskussion der Vor- und Nachteile von hyperbolischen Browsern bieten LAMPING und RAO [LaRa98, 382 - 404].

184

IT-Architektur-Management-Portal

Abbildung 7-9

Hyperbolischer Browser

Beim Einsatz des hyperbolischen Browsers zeigt sich, dass die Darstellung von n:mBeziehungen (z. B. der Zusammenhang Applikationen zu Technologien) des Datenmodells nicht möglich ist. Der Grund ist die dem Browser zu Grunde liegende mathematische Theorie, die von einem Baum (Verkettung von 1:n-Beziehungen) und nicht von einem Netz (Verkettung von n:m-Beziehungen) ausgeht [LaRa94, 2]. In der Praxis führt die Darstellung eines Netzes mit mehr als sechs Elementen zu Überschneidungen der Kanten und damit zu einer starken Abnahme der ursprünglich beabsichtigen Übersichtlichkeit. Aus diesem Grund wird der hyperbolische Browser in ITMAP nur zur Visualisierung der hierarchischen Strukturen innerhalb von Sparten, Prozessen und Applikationen eingesetzt. 7.5.3.5 Lebenszyklen KRCMAR definiert den Lebenszyklus von Applikationen folgendermaßen: Ä'HU/HEHQV]\NOXVYRQ,6$QZHQGXQJHQLVWGLH]HLWOLFKH(QWZLFNOXQJYRQGHUXU VSUQJOLFKHQ ,GHH XQG GHU (QWVFKHLGXQJ HLQH $QZHQGXQJ ]X NUHLHUHQ RGHU ]X

IT-Architektur-Management-Portal

185

EH]LHKHQEHUGLH(QWZLFNOXQJXQG(LQIKUXQJ>«@ELV]XUDEVFKOLH‰HQGHQ$E VFKDIIXQJ³>.UFP@ Im hier vorgestellten Modell erstreckt sich der Lebenszyklus einer Applikation oder Technologie über die Phasen 3ODQXQJ, Entwicklung, (LQVDW], ,Q $EO|VXQJ und (LQVDW] beendet (vgl. Abschnitt 7.5.3.2). Zur Darstellung der Soll-IT-Architektur in ITMAP ist es möglich, für jede dieser Phasen einen Zielkorridor (bestehend aus einem Anfangs- und einem Enddatum) vorzugeben, wobei einzelne Phasen (z. B. Entwicklung beim Einsatz von Standardsoftware) übersprungen werden können. Jeder Technologie und Applikation wird parallel dazu der tatsächliche Zustand zugewiesen, der vom geplanten Stadium abweichen kann. ITMAP verwendet Gantt-Diagramme, um Lebenszyklen darzustellen und die Identifikation von Abweichungen zu erleichtern (vgl. Abbildung 7-10).

Abbildung 7-10 Soll-Lebenszyklus einer Technologie

Ein Gantt-Diagramm ist ein Balkendiagramm, das die zeitliche Abfolge von Aktivitäten und Zuständen grafisch in Form von Balken auf der horizontalen Achse darstellt. Das in ITMAP realisierte Diagramm verwendet die gleichen Farbcodierungen wie der Bebauungsplan (vgl. Abschnitt 7.5.3.2). Das Beispiel zeigt die Lebenszyklen der Technologien Internet Explorer 6 und Internet Explorer 7. ITMAP ermöglicht die Definition von Nachfolgetechnologien. Falls eine Technologie sich in der Phase ,Q $EO|VXQJ befindet, identifiziert der IT-Architekt mit ITMAP alle Applikationen, die diese Technologie verwenden und stellt einen Plan zur Ablösung der Technologie durch die Nachfolgetechnologie auf. Ein rot schraffierter vertikaler Balken zeigt das Abfragedatum an. Im Beispiel aus Abbildung 7-10 löst die Technologie ,QWHUQHW([SOR rer 7 die Technologie Internet Explorer 6 ab. Letztere Technologie befindet sich aktuell in der Phase ,Q$EO|VXQJ, erstere ist seit dem 01.01.2007 im (LQVDW]. 7.5.4

Controlling

Der Bereich Controlling in ITMAP beinhaltet Funktionalitäten zur Überwachung und Steuerung der IT-Architektur. ITMAP stellt dazu einige der aus Abschnitt 6.7.4 bekannten Kennzahlen bereit (vgl. Tabelle 7-2).

186

Kürzel IS.T.1.1 IS.T.2.1 IS.T.3 IS.C.1 IS.C.3 IS.L.1 IS.L.2 IS.A.1.1 IS.A.1.2 IS.P.1 IS.P.2.1 IS.P.3 IA.T.1.1 IA.T.1.2 IA.T.2 IA.T.4.1 IA.C.1 IA.C.3.1 IA.L.1 IA.L.2.1 IA.P.1 IA.P.2.1 IA.P.2.2 IA.P.3.1 IA.P.4.1 IA.A.1 IA.A.2 IA.A.3.1 IA.A.3.2 IA.A.4.1 IA.A.4.2 IA.A.4.3 BS.A.1.1 BS.PR.1 BS.S.1 BA.S.1 BA.A.1 BA.A.3.1 BA.A.3.2 BA.PR.1 BA.PR.2.2 BA.PR.2.4

Tabelle 7-2

IT-Architektur-Management-Portal

Bezeichnung Anzahl Applikationen, die Technologie X nutzen Anzahl Plattformen, die Technologie X nutzen Lieferant Technologie X Anzahl Technologien im Cluster X Anzahl der potenziell redundanten Technologien je Cluster X Anzahl Technologien im Layer X Anzahl Cluster im Layer X Anzahl Technologien die von Applikation X genutzt werden Anzahl Plattformen, die von Applikation X genutzt werden Anzahl Technologien, die von Plattform X genutzt werden Anzahl Applikationen, die Plattform X nutzen Anzahl um Z % ähnlicher Plattformen für Plattform X Anzahl Technologien Anzahl Applikationen Anzahl Lieferanten über alle Technologien Anzahl Applikationen, von denen eine Technologie der Infrastruktur dstl. genutzt wird Anzahl Cluster Anzahl Cluster mit Anzahl Technologien > Z Anzahl Layer Dstl. Anzahl Cluster pro Layer Anzahl Plattformen Anzahl Technologien der Infrastruktur, die von Plattformen genutzt werden Anteil Technologien der Infrastruktur, die von Plattformen genutzt Anzahl Applikationen, von denen eine Plattform dstl. genutzt wird Anzahl potenziell redundanter Plattformen Anzahl Applikationen Dstl. Anzahl Technologien je Applikation Anzahl Technologien der Infrastruktur, die mehr als Z-mal von Applikationen genutzt werden Anteil Technologien der Infrastruktur, die mehr als Z-mal von Applikationen genutzt werden Anzahl Applikationen, die Plattformen nutzen Anteil Applikationen, die Plattformen nutzen Dstl. Anzahl genutzter Plattformen je Applikation Anzahl unterstützter Prozesse je Applikation X Anzahl Applikationen je Prozess X Anzahl Applikationen je Sparte X Anzahl Sparten Anzahl Applikationen Dstl. Anzahl unterstützter Prozesse je Applikation Dstl. Anteil unterstützter Prozesse je Applikation Anzahl Prozesse Anzahl Prozesse mit Anzahl Applikationen je Prozess > Z Anzahl Prozesse mit Anzahl Applikationen je Prozess < Z

Kennzahlen in ITMAP

Die Variable Z wird vom Anwender definiert, Abbildung 7-11 zeigt ein Beispiel der Realisierung in ITMAP.

IT-Architektur-Management-Portal

187

Abbildung 7-11 Variablenbelegung durch den Anwender in ITMAP

Der Anwender kann im Freitextfeld die gewünschte Anzahl der Applikationen einstellen und im Dropdown-Menü die Werte größer gleich oder kleiner als auswählen. Zusätzlich zu den aufgeführten Kennzahlen ermöglicht ITMAP den Vergleich von Plattformen nach deren Grad der Ähnlichkeit. Hierzu vergleicht ITMAP alle anderen Plattformen mit der aktuell fokussierten und bildet die Summe aller Plattformen, die in mindestens Z Prozent der Technologien mit der aktuellen Plattform übereinstimmen. Z kann vom Anwender frei gewählt werden. Auf Basis dieser Kennzahl kann ITMAP die Anzahl und den Anteil potenziell redundanter Plattformen ausgeben. Die Kennzahl Anzahl von Plattformen mit einer größeren Ähnlichkeit als Z Prozent weist den Anwender auf eine mögliche Überversorgung mit Plattformen hin (vgl. Abbildung 7-16).

7.6

Implementierung

Die Implementierung des in Kapitel 7.5.1 gezeigten Entity-Relationship-Modells erfolgt über die Transformation in ein Relationenmodell und die Umsetzung der modellspezifischen Datenabstraktionsschicht. 7.6.1

Datenmodell

Entsprechend der Nomenklatur des DMAV-Frameworks sind die Namen der Datenbanktabellen aus zwei Großbuchstaben zusammengesetzt. Weiterhin erfolgt die Dokumentation des Programmcodes in Englisch. Tabelle 7-3 zeigt die Nomenklatur des Datenmodells in der Implementierung. Entitätstyp

Applikation

Name in der Implementierung

Application

Kürzel

AP

Lebenszyklus einer Applikation

ApplicationLifecycle

AL

Abhängigkeiten einer Applikation

ApplicationDependency

AD

Technologie

Technology

TE

Lebenszyklus einer Technologie

TechnologyLifecycle

AL

Abhängigkeiten einer Technologie

TechnologyDependency

AD

Basistechnologie

BaseTechnology

BT

Prozess

Process

PO

Sparte

Division

PR

Person

Person

PE

Rolle

Role

RO

Layer

Layer

LA

188

IT-Architektur-Management-Portal

Entitätstyp

Cluster

Name in der Implementierung

Cluster

Kürzel

CL

Plattform

Platform

PL

Dokumentation

Documentation

DC

Tabelle 7-3

Nomenklatur des Datenmodells in der Implementierung

Abbildung 7-12 zeigt das Relationenmodell von ITMAP. Ein gerichteter Pfeil bezeichnet die Verwendung des Primärschlüssels des ausgehenden Entitätstyps als Fremdschlüssel im eingehenden Entitätstyp.

Relationenmodell

189

Abbildung 7-12

IT-Architektur-Management-Portal

190

IT-Architektur-Management-Portal

Das DMAV-Framework beinhaltet ein Verfahren zur Datenabstraktion mittels Datenabstraktionsobjekten (vgl. Abbildung 7-13). (1)

(2) DatasourceManager

Mysql4 1

0..*

1 0..*

(3)

(5) Mysql4DaoClusters

Cluster 1

0..*

(4) DAO

Abbildung 7-13 Klassendiagramm der Datenabstraktion 147

Eine Action fordert für den Zugriff auf einen bestimmten Entitätstyp (z. B. Cluster) vom DatasourceManager (1) ein Datenabstraktionsobjekt an. Für die Action ist nicht ersichtlich, welche Datenquelle Verwendung findet. Der DatasourceManager stellt aus den Konfigurationsoptionen des DMAV die benötigten Basismethoden zum Datenzugriff fest und lädt die entsprechende Datenquellen-Klasse (2), im Beispiel Mysql4. Danach lädt der DatasourceManager das konkrete Datenabstraktionsobjekt (3), z. B. Mysql4DaoClusters und gibt es an die Action zurück. Das Datenabstraktionsobjekt ist von der Oberklasse DAO (4) abgeleitet, die allgemeine Methoden und Attribute aller Datenabstraktionsobjekte enthält. Falls die Action im Folgenden eine Such- oder Manipulationsoperation auf der Datenquelle ausführt, nutzt sie hierzu die generischen Methoden des Datenabstraktionsobjekts, welches eine Modelinstanz (5), im Beispiel Cluster, zurückliefert. Die Abbildung der hierarchisch strukturierten Entitätstypen Applikation, Sparte und Prozess in einer relationalen Datenbank ist problematisch: Die klassische Vorgehensweise zur Abbildung von Bäumen in Datenbanken beschränkt sich auf die Verwendung eines Attributs Elternelement, welches den Primärschlüssel der übergeordneten Entität enthält. Dies erlaubt allerdings keine Darstellung der Ordnung von Elementen derselben Hierarchiestufe.

147

Das vollständige Klassendiagramm des DMAV-Frameworks zeigt Abbildung A-1 im Anhang.

IT-Architektur-Management-Portal

191

Um eine solche Ordnung zu ermöglichen, implementiert ITMAP im Service Mysql die Klasse Mysql4DaoTree nach dem Nested Set Model [Wong94, 31 - 33] 148. 7.6.2

Administration

Die Darstellung von Elementen aus dem Datenmodell wird im Menüpunkt Administration von ITMAP von den Services Listing (für die Entitätstypen Technologie, Layer, Cluster, Plattform und Basistechnologie) und Tree (für die Entitätstypen Applikation, Sparte und Prozess) übernommen (vgl. Abbildung 7-14).

Abbildung 7-14 Listengenerierung

Zur Manipulation einzelner Entitäten dient der Service Form, der die Metadaten eines Eingabeformulars in einem Model bündelt. Eine Action definiert die Bestandteile des Formulars (z. B. Textfeld, Radiobutton oder Auswahlmenü) und weist diesen Elementen Attribute (z. B. Standardwert oder mögliche Auswahloptionen) zu. Zur Realisierung der Mehrsprachigkeit dient der Service LocalLang. Dieser nach dem Strategy Pattern [GHJV95, 315 f.] aufgebaute Service dient als Filter zwischen Applikationslogik und sprachlichen Termen. Je nach der vom Anwender gewählten Sprache wird hierbei 148

Der Begriff Nested Sets bezeichnet ein Modell zur Abbildung eines Baumes mit Hilfe von Mengen, die ineinander verschachtelt sind. Dabei wird die ist-Kind-von-Beziehung auf eine istTeilmenge-von-Beziehung abgebildet.

192

IT-Architektur-Management-Portal

auf die englische oder deutsche Sprachbibliothek zurückgegriffen. Weitere Sprachbibliotheken können modular hinzugefügt werden. 7.6.3

Reporting

Die Bildschirmausgabe von Modelldaten als Gantt- oder Kuchendiagramm erfolgt als dynamisch von ITMAP generierte Grafik im PNG-Format (vgl. Abbildung 7-15).

Abbildung 7-15 Dynamisch generiertes Diagramm in ITMAP

Hierzu dient der Service Graph, eine Portierung der Open Source-Software JpGraph 149, im DMAV-Framework. Ähnlich wie beim Service Form erzeugt die Action eine Instanz einer Model Klasse (GraphPie) und legt deren Attribute fest. Das entsprechende Plugin der Präsentationsschicht (PluginGraphImage) erzeugt aus den Daten des Models eine Grafik sowie den darauf verweisenden XHTML-Code. Komplexer gestaltet sich die Generierung des Bebauungsplans (vgl. Abbildung 7-6). Die folgende Auflistung nennt die hierzu von ITMAP durchgeführten Schritte. 1. ITMAP lädt aus dem Datenmodell die angeforderten Sparten und Prozesse zur Achsenbelegung. 2. Die Applikationen werden identifiziert und geladen. Bei der Beschränkung auf einen Unterprozess oder eine Untersparte sind auch solche Applikationen relevant, die ein übergeordnetes Vaterelement (Prozess oder Sparte) unterstützen. In diesem Schritt liegt ein zweidimensionales Feld (Array) mit den Schlüsselattributen Prozess (erste

149

³-S*UDSK LV D OLJKWZHLJKW $3, WKDW DOORZV \ou to quickly generate professional looking graphs. &RXSOLQJ-S*UDSKZLWK3+3¶VGDWDEDVHDFFHVVFDSabilities provides you with a powerful toolset IRUWKHJHQHUDWLRQRIG\QDPLFJUDSKVRQWKHZHE´>6ZHDE@

IT-Architektur-Management-Portal

193

Dimension) und Sparte (zweite Dimension) vor, das als Werte die dieses Matrixfeld unterstützenden Applikationen enthält. 3. Nun werden vier mögliche Ausprägungen von Applikationen unterschieden: a. Applikationen, die nur ein Matrixfeld belegen, werden als horizontaler Balken im entsprechenden Matrixfeld dargestellt. b. Applikationen, die mehrere Sparten, aber nur einen Prozess unterstützen, werden als vertikaler Balken über den betreffenden Prozess dargestellt. Hierbei sind Aussparungen bei nicht unterstützten Sparten vorzunehmen, die auf der Vertikalachse von unterstützten Sparten eingeschlossen werden. c. Applikationen, die nur eine Sparte, aber mehrere Prozesse unterstützen, werden als horizontaler Balken über die betreffende Sparte aufgespannt. Hierbei sind Aussparungen bei nicht unterstützten Prozessen vorzunehmen, die auf der Horizontalachse von unterstützten Prozessen eingeschlossen werden. d. Bei Applikationen, die mehrere Sparten und Prozesse unterstützen erfolgt für jeden unterstützten Prozess die wiederholte Anwendung von Schritt (b), falls mehr Sparten als Prozesse betroffen sind. Andernfalls wird für jede unterstützte Sparte Schritt (c) wiederholt. 4. Die Transformation der bis jetzt nur in Rohdaten vorliegenden Ergebnisse der bisherigen Operationen in eine XHTML-Darstellung nimmt das im Service LayoutPlan implementierte ViewPlugin PluginLayoutPlanXhtml vor. Zur Berechnung der Position der horizontalen und vertikalen Balken innerhalb der Matrix sind zwei Durchläufe des Algorithmus erforderlich. Das ist notwendig, da zur Ermittlung der für jede Sparte variablen Zeilenhöhe und der für jeden Prozess variablen Spaltenbreite erst die Dimensionen der Applikationsbalken innerhalb der einzelnen Sektoren ermittelt werden müssen (vgl. Abbildung 7-6). 7.6.4

Controlling

Die Controllingfunktionen von ITMAP sind in der Applikationslogik in Form von Actions implementiert. Die Actions greifen über DAOs auf die durch Models repräsentierten Entitäten des Datenmodells zu und berechnen die Kennzahlen, die dann in der Präsentationsschicht für den Anwender grafisch aufbereitet werden. Diese Aggregation ist für die meisten Kennzahlen algorithmisch trivial (vgl. Tabelle 7-2). Die Berechnung der Anzahl potenziell redundanter Plattformen bei einem Ähnlichkeitsprozentsatz Z ist dagegen komplex (vgl. Abbildung 7-16).

194

IT-Architektur-Management-Portal

Abbildung 7-16 Ähnliche Plattformen

Der Anwender kann den Ähnlichkeitsgrad zwischen 0 und 100 Prozent frei bestimmen. Im Beispiel hat der Anwender eine Ähnlichkeit größer gleich 40 % ausgewählt. ITMAP hat drei Plattformen identifiziert, für die Plattformen mit einer Ähnlichkeit von 40 Prozent oder höher vorliegen. Erforderlich für diese Berechnung ist der paarweise Vergleich aller Plattformen auf einen gemeinsamen Anteil an zugehörigen Technologien. Hierzu dient die Klasse MathCombinatory im Service Math. Diese erlaubt, in verschiedenen Variationen N Technologien aus einer Menge mit M Technologien zu kombinieren. Im Beispiel erfährt der Anwender z. B., dass die Plattformen Streaming und Web Application zu mindestens 40 Prozent gleiche Technologien enthalten wie die Plattform Prozessportale. 7.6.5

Benutzeroberfläche

Die Benutzeroberfläche gliedert sich grundsätzlich in die Bereiche Navigation, Pfad, Inhalt und Fußzeile (vgl. Abbildung 7-17).

IT-Architektur-Management-Portal

195

Pfad

Inhalt Navigation

Fußzeile

Abbildung 7-17 Bereiche der Benutzeroberfläche

Die Navigation bietet neben den übergreifenden Kategorien Administration, Reporting und Controlling die Menübereiche Bebauungsplan, IT-Infrastruktur und Einstellungen an. Der Pfad dient zur Orientierung des Anwenders in der Struktur von ITMAP. Die Fläche des ,QKDOWVEHUHLFKVNDQQGXUFKGDV$XVEOHQGHQGHU1DYLJDWLRQVOHLVWHHUZHLWHUWZHUGHQ±GD]X klickt der Anwender auf den Bereich des Logos oder den Balken darüber (vgl. Abbildung 7-6, in der die Navigation ausgeblendet ist). Die Fußzeile schließt die einzelnen Seiten optisch ab und beinhaltet in dieser Implementierung Informationen zur Systemumgebung 150 der Applikation. Die Fußzeile kann je nach Implementierungsumgebung (z. B. in einem Intranet oder Unternehmensportal) beliebig angepasst werden. Ebenso in globalen Variablen anpassbar sind die Farbgebungen in der Oberfläche. 7.6.5.1 Symbole Um den intuitiven Einsatz von ITMAP zu erleichtern, kommen diverse Symbole zum Einsatz. Der Rollover-Effekt in der Navigation und in Listendarstellungen dient dazu, dem Anwender anhand des Farbwechsels beim Überfahren mit der Maus die dahinter liegende Funktionalität zu verdeutlichen: Bei einem Farbwechsel von Weiß zu Blau bewirkt ein Dop150

In der prototypischen Implementierung gibt ITMAP in der Fußzeile z. B. die PHP-Version, die für die momentane Bildschirmanzeige verwendeten Transaktionen, Actions und Module und die Zeit für das Rendering der aktuellen Bildschirmmaske in Millisekunden aus. Die Renderingzeit gibt Auskunft über die Performanz der Benutzeroberfläche. Je kürzer das Rendering dauert, umso schneller kann der Anwender die Oberfläche verwenden.

IT-Architektur-Management-Portal

x

R

Layer

R

Cluster

R

Plattformen

R

Basistechnologien

197

Einstellungen R

Sprache ändern

R

ausloggen

Die Menüeinträge Bebauungsplan, IT-Infrastruktur und Einstellungen dienen der Strukturierung und können nicht angeklickt werden. Home führt den Anwender auf die Startseite (vgl. Abbildung 7-17). Administration zeigt eine Übersicht aller Bestandteile der IT-Architektur, mit der Möglichkeit, eine Liste aller Einträge eines Bestandteils (z. B. Technologie) anzeigen zu lassen oder einen Bestandteil hinzuzufügen (vgl. Abbildung 7-14). Reporting verweist auf eine Liste, von der aus der Bebauungsplan, die IT-Infrastruktur, alle Technologiehersteller und alle ungenutzten Applikationen und Technologien aufgerufen werden können (vgl. Abbildung 7-19)

Abbildung 7-19 Reporting-Übersicht in ITMAP

Ungenutzte Technologien sind solche, die keiner Applikation zugeordnet sind. Ungenutzte Applikationen sind keiner Sparte und keinem Prozess zugeordnet. Der Link Controlling verweist auf eine Übersicht, in der die Anzahl der Applikationen, Technologien, Plattformen, Sparten und Prozesse angezeigt werden (vgl. Abbildung 7-20).

IT-Architektur-Management-Portal

199

Im Beispiel enthalten die Cluster Software Development und Server OS jeweils fünf Technologien. Ein Klick auf die Bezeichnung eines Clusters ruft die Maske mit den Clusterdetails auf, in der die einzelnen Technologien aufgeführt sind. Die Einträge Anzahl Applikationen, Anzahl Technologien und Anzahl Plattformen in der Controlling-Übersicht öffnen nach einem Doppelklick eine Detaillierungsansicht auf weitere Kennzahlen. Die in Tabelle 7-2 aufgelisteten Kennzahlen werden in übersichtlichen Darstellungen Angeboten und teilweise weiter untergliedert (vgl. Abbildung 7-22).

Abbildung 7-22 Maske Ä.HQQ]DKOHQ3ODWWIRUPHQ³

Unterstreichungen in den Kennzahlenbeschreibungen können für weitere Informationen DQJHNOLFNW ZHUGHQ .OLFNW GHU $QZHQGHU DXI GHQ /LQN Ä7HFKQRORJLHQ GLH YRQ 3ODWWIRUPHQ YHUZHQGHW ZHUGHQ³ DXV GHP %HLVSLHO HUVFKHLQW HLQH /LVWH PLW GHQ 7HFKQRORJLHQ GLH YRQ Plattformen verwendet werden. Diese Technologien wiederum sind den Plattformen zugeordnet (vgl. Abbildung 7-23).

200

IT-Architektur-Management-Portal

$EELOGXQJ 0DVNHÄ7echnologien die von Plattformen verwendetZHUGHQ³

,Q GHU 0DVNH Ä7HFKQRORJLHQ GLH YRQ 3ODWWIRUPHQ YHUZHQGHW ZHUGHQ³ N|QQHQ VRZRKO GLH einzelnen Technologien als auch die Plattformen angeklickt werden, um weitere Details (z. B. Lebenszyklusdaten, Hersteller der Technologie, Verwendung in Applikationen) angezeigt zu bekommen. Die Menüeinträge Applikationen, Prozesse und Sparten führen den Anwender zu einer hierarchisch strukturierten Liste, die alle Objekte des ausgewählten Typs anzeigt (vgl. Abbildung 7-8). Jede dieser Listen kann auch als hyperbolische Ansicht dargestellt werden (vgl. Abbildung 7-9). Der Link Personen|IIQHW]XQlFKVWHLQH/LVWHDOOHU%HQXW]HU]XJlQJHLQ ITMAP (vgl. Abbildung 7-24).

Abbildung 7-24 Anwenderliste

Neben dem Namen und der E-Mail-Adresse wird auch die Rolle angezeigt. Das RollenmoGHOOZLUGMHQDFK8QWHUQHKPHQLQGLYLGXHOOIHVWJHOHJW-HGHU5ROOHN|QQHQ=XJULIIHDXI%HUHL che in ITMAP zugewiesen werden. ITMAP unterscheidet bei den Rechten zwischen view, edit, new und delete. Ein Doppelklick auf einen Tabelleneintrag führt den Anwender zur Bearbeitungsmaske, in der die Daten der einzelnen Benutzerzugänge bearbeitet werden

IT-Architektur-Management-Portal

201

N|QQHQ 'LH JOHLFKH 0DVNH HUVFKHLQW EHL HLQHP .OLFN DXI Ä$QZHQGHU HUVWHOOHQ³ DOOHUGLQJV leer. Die Menüpunkte Technologien Layer Cluster PlattformenXQGBasistechnologien fühUHQ DOOH ]X HLQHU QLFKWKLHUDUFKLVFKHQ /LVWHQGDUVWHOOXQJ YJO $EELOGXQJ   -HZHLOV DP REHUHQ5DQGGHU$QVLFKWHUP|JOLFKWHLQ/LQNHLQQHXHV2EMHNWDQ]XOHJHQ Bei einem Klick auf Sprache ändernHUVFKHLQWHLQHLQIDFKHV'URSGRZQ0HQLQGHPDO OH]XU9HUIJXQJVWHKHQGHQ6SUDFKHQDQJH]HLJWZHUGHQ1DFKGHU$XVZDKOHLQHU6SUDFKH NOLFNW GHU $QZHQGHU DXI Sprache festlegen XQG ,70$3 HUVFKHLQW YRQ QXQ DQ LQ GHU JH ZQVFKWHQ 6SUDFKH 'LH 6SUDFKHLQVWHOOXQJ HUIROJW IU MHGHQ $QZHQGHU LQGLYLGXHOO ,70$3 VSHLFKHUWGLHMHZHLOVJHZQVFKWH6SUDFKH]XVDPPHQPLWGHQ'DWHQGHV$QZHQGHUV Der Menüpunkt ausloggen IKUW ]XUFN ]XU 6WDUWVHLWH PLW GHU $XIIRUGHUXQJ HLQHQ $Q ZHQGHUQDPHQXQGHLQ3DVVZRUWHLQ]XJHEHQ

7.7

Anwendungsfälle

'LH IROJHQGHQ $EVFKQLWWH GRNXPHQWLHUHQ GDV $QOHJHQ YRQ $SSOLNDWLRQHQ 7HFKQRORJLHQ 3ODWWIRUPHQ&OXVWHUQ/D\HUQ3UR]HVVHQXQG3ODWWIRUPHQLQ,70$3 7.7.1

Hinzufügen einer neuen Applikation

)DOOVHLQ,73URMHNWDXVUHLFKHQGVWUDWHJLHNRQIRUPLVWYJO.DSLWHO ]XU(UK|KXQJGHV$), EHLWUlJW YJO .DSLWHO   XQG HLQHQ :HUWEHLWUDJ LQ GHU ,7$UFKLWHNWXU OLHIHUW YJO .DSLWHO   NDQQ HV IUHLJHJHEHQ ZHUGHQ XQG GLH $SSOLNDWLRQVHQWZLFNOXQJ EHJLQQW 'LH $SSOLNDWLRQ LVW GDQQLP/HEHQV]\NOXVVWDWXVPlanungXQGZLUGLQ,70$3HUIDVVWYJO$EELOGXQJ 

202

$EELOGXQJ 3UR]HVVÄ$SSOLNDWLRQDQOHJHQ³

IT-Architektur-Management-Portal

IT-Architektur-Management-Portal

203

Die neu hinzugefügte Applikation erscheint von nun an in der Applikationsliste. In der MasNHÄ$SSOLNDWLRQEHDUEHLWHQ³ZHUGHQGHU$SSOLNDWLRQLPQlFKVWHQ6FKULWWSparten, Prozesse, Plattformen und Technologien]XJHZLHVHQYJO$EELOGXQJ 

$EELOGXQJ 0DVNHÄ$SSOLNDWLRQEHDUEHLWHQ³

204

IT-Architektur-Management-Portal

,P%HLVSLHOLVWGHU$SSOLNDWLRQÄ6FKDGHQ02QOLQH³ 151 eine Plattform (Web Application), drei Technologien (Apache 2, PHP 5 und Suse Linux 8) und ein Prozess (Rechnungswesen/ Verwaltung) zugeordnet. Der Anwender kann als Dokumentation entweder auf eine URL YHUZHLVHQRGHUHLQ'RNXPHQWDXIGHQ,70$36HUYHUKRFKODGHQYJOAbbildung 7-27).

$EELOGXQJ 0DVNHÄ'RNXPHQWDWLRQHUVWHOOHQ³

Mit der Funktion Nachfolgeapplikation definieren kann der Anwender die diese Applikation ablösende Applikation anlegen. ITMAP gibt zu einer Applikation folgende Warnmeldungen aus:

x 'HU,VW/HEHQV]\NOXVVWDWXVXQWHUVFKHLGHWVLFKYRP6ROO x

Die Applikation verwendet eine Technologie, deren Lebenszyklus nicht auf Einsatz gesetzt ist

x 7.7.2

Der Applikation ist kein Ist-Lebenszyklus zugewiesen Hinzufügen einer neuen Technologie

'LH 6RIWZDUHDUFKLWHNWXU HLQHU $SSOLNDWLRQ ZLUG in ITMAP modelliert, indem der Applikation Technologien zugewiesen werden (vgl. Abbildung 7-28).

151

Ä6FKDGHQ02QOLQH³VWHKWIUSchadensmeldung online und ist eine fiktive Applikation zur Eigenerfassung von Versicherungsfällen durch den Versicherungsnehmer auf der Webseite der Versicherungsgesellschaft.

IT-Architektur-Management-Portal

205

V

XOR

Softwarearchitektur einer neuen Applikation soll in ITMAP beschrieben werden

Technologie auswählen

Technologie ist zugewiesen, Softwarearchitektur ist noch nicht vollständig

Gewünschte Technologie ist bereits in ITMAP angelegt

XOR

Gewünschte Technologie ist noch nicht in ITMAP angelegt

Technologie der Applikation zuweisen

XOR

V

In Basistechnologien nach gewünschter Technologie recherchieren

XOR

XOR

Technologie ist zugewiesen, Softwarearchitektur ist vollständig

Gewünschte Basistechnologie ist noch nicht in ITMAP angelegt

Gewünschte Basistechnologie ist bereits in ITMAP angelegt

V

XOR Basistechnologie neu anlegen

Neue Basistechnologie ist angelegt

Gewünschte Basistechnologie zu den Technologien hinzufügen

$EELOGXQJ 3UR]HVVÄ7HFKQRORJLH]X$SSOLNDWLRQ]XZHLVHQ³

$XVGHU0DVNHÄ$SSOLNDWLRQEHDUEHLWHQ³UXIWGHU$QZHQGHUGLH0DVNHÄ7HFKQRORJLH]XRUG QHQ³ DXI ,Q GLHVHU ZHUGHQ DOOH LQ ,70$3 GHILQLHUWHQ 7HFKQRORJLHQ DQJH]HLJW )DOOV GLH JHZQVFKWH7HFKQRORJLHQLFKWYRUKDQGHQLVWZlKOWGHU$QZHQGHUGLH)XQNWLRQ Basistechnologie hinzufügen,QGLHVHU0DVNHZHUGHQDOOH%DVLVWHFKQRORJLHQDQJH]HLJWGLHLQ,70$3 YRUOLHJHQ'LH7UHQQXQJ]ZLVFKHQTechnologie und Basistechnologie soll den Prozess der $QODJH YRQ 7HFKQRORJLHQ HUOHLFKWHUQ ,Q GHU KLHU EHVFKULHEHQHQ ,PSOHPHQWLHUXQJ OLHJHQ EHU  %DVLVWHFKQRORJLHQ YHUVFKLHGHQHU +HUVWHOOHU YRU (LQH %DVLVWHFKQRORJLH YHUIJW über die Attribute Name, Hersteller, Version (Text) 152 und Version (Zahl) wohingegen eine

152

0DQFKH 6RIWZDUHKHUVWHOOHU YHUJHEHQ QLFKWQXPHULVFKH 9HUVLRQVEH]HLFKQXQJHQ ]% Microsoft Office Professional Edition 2003 Professional Edition ist dabei die textuelle Versionsbeschreibung, 2003GLHQXPHULVFKH

206

IT-Architektur-Management-Portal

Technologie um einen Ist-Lebenszyklusstatus, einen Soll-Lebenszyklus, eine Zuordnung zu Layern, Clustern, Applikationen und Plattformen, Dokumentationen und Vorgänger- und Nachfolgertechnologie(n) (im Lebenszyklus) erweitert wird. Der Vorgang des Hinzufügens von Technologien zu einer Applikation wird so lange wiederholt, bis die Softwarearchitektur vollständig in ITMAP erfasst ist. Schon während des Erfassens stellt ITMAP Funktionalitäten zur Sicherstellung der Architekturkonformität bereit: Falls der Anwender einer Applikation eine Technologie zuweist, deren Lebenszyklus nicht auf Einsatz steht, gibt ITMAP eine Warnmeldung aus. 7.7.3

Hinzufügen von Plattformen

Zunächst wählt der Anwender im Menü Plattformen aus und klickt dann im Inhaltsbereich auf Plattform erstellen. In der nun erscheinenden Maske vergibt er eine Bezeichnung und eine optionale Beschreibung der Plattform. Nach dem Speichern ist die Plattform in ITMAP angelegt. Nun kann der Anwender der Plattform Technologien zuweisen. Dieser Vorgang funktioniert analog zu dem in Abschnitt 7.7.2 beschriebenen Vorgehen. 7.7.4

Hinzufügen von Clustern

In der Listendarstellung aller Cluster wählt der Anwender den Menüpunkt Cluster erstellen aus. Neben der Bezeichnung wird dem neuen Cluster nun ein Layer aus einer DropdownListe zugewiesen (vgl. Abbildung 7-29).

$EELOGXQJ 0DVNHÄ&OXVWHUHUVWHOOHQ³

Nach dem Speichern ist der Cluster in ITMAP vorhanden und wird in der IT-Infrastruktur angezeigt. Jetzt können dem Cluster die entsprechenden Technologien zugewiesen werden. 7.7.5

Hinzufügen von Layern

,QGHU0DVNHÄ/D\HUKLQ]XIJHQ³GLHEHUGLH0DVNHÄ/D\HU³HUUHLFKWZLUGJLEWGHU$QZHQ der den Namen des neuen Layers ein. Nach dem Speichern steht der neue Layer in ITMAP zur Verfügung und kann mit Clustern verknüpft werden.

IT-Architektur-Management-Portal

7.7.6

207

Hinzufügen von Prozessen und Sparten

Das Vorgehen zum Anlegen von Prozessen und Sparten ist ähnlich. Nach Eingabe des JHZQVFKWHQ 1DPHQV LQ GHU 0DVNH Ä^3UR]HVV_6SDUWH` DQOHJHQ³ HUIROJW HLQH KLHUDULVFKH Zuordnung zu den bisher existierenden Prozessen oder Sparten (vgl. Abbildung 7-30).

$EELOGXQJ 0DVNHÄ3UR]HVVHUVWHOOHQ³

$XI GLHVH $UW XQG :HLVH NDQQ HLQH EHOLHELJ WLHIH +LHUDUFKLVLHUXQJ HUIROJHQ 6REDOG HLQ Prozess oder eine Sparte neu angelegt ist, können Applikationen zugeordnet werden.

7.8

Evaluation

ITMAP wird anhand der in Abschnitt  EHVFKULHEHQHQ $QIRUGHUXQJHQ HYDOXLHUW YJO Tabelle 7-4).

208

IT-Architektur-Management-Portal

Anforderung

ITMAP

Konsistentes Modell Intuitive Benutzeroberfläche Einhaltung von Standards des Betriebssystems Automatisierung von trivilalen Funktionen in der Benutzeroberfläche Funktionalitäten zur Analyse und Verwaltung von Modellbestandteilen

X X X X X

Hinweise auf Redundanzen und fehlende Bestandteile im Modell Repositoryfunktionalität Funktionen zur Versionierung Beschränkung des Lese- und Schreibzugriffs auf bestimmte Teile des Modells Technologielisten Applikationensliste Verweise zwischen Applikationen und Technologien Unterstützung der Modellierung eines Architekturframeworks Versionierbarkeit von Bestandteilen Versionierbarkeit der IT-Architektur Verknüpfungen zu anderen Modellierungsapplikationen Rollen- und rechtebasierter Zugriff Verfügbarkeit der Informationen im gesamten Unternehmen Grafische Darstellungen Verknüpfung von Applikationen, Technologien, Geschäftsprozessen und weiteren Attributen Hohe Verfügbarkeit Verschiedene Sichten auf die IT-Architektur Erweiterbarkeit Thin-Client Architektur Open Source-Komponenten Erweiterbares Sprachmodul

teilweise X

Tabelle 7-4

X X X teilweise X teilweise X X X X X X X X X X

Anforderungserfüllung von ITMAP 153

Die Anforderung Hinweise auf Redundanzen und fehlende Bestandteile im Modell erfüllt ITMAP insofern, als dass der Anwender in den grafischen Ansichten des Bebauungsplans und der IT-Architektur Redundanzen und Lücken in der IT-Versorgung intuitiv identifizieren kann. Eine algorithmische Lösung zur automatischen Identifikation von Redundanzen und Lücken liegt nicht vor. Die ITMAP zugrunde liegende Datenbank kann nicht als Repository verstanden werden, da Import- und Exportfunktionalitäten für Modelldaten nicht vorliegen. Die Versionierung von IT-Architekturen ist in der vorliegenden Implementierung nicht integriert. Nur über einen Datenbankabzug ist eine manuelle Versionierung der IT-Architektur möglich. Einzelne Technologien können über die Versionsbezeichnung versioniert werden. Die Anforderung Unterstützung der Modellierung eines Architekturframeworks wird insoweit erfüllt, als das die Modelle Bebauungsplan und IT-Infrastruktur abgebildet sind. Frameworks wie Zachman oder TOGAF werden nur teilweise unterstützt. Die Verknüpfungen zu anderen Modellierungsapplikationen ist in Ansätzen möglich, so können die dynamisch generierten

153

Ein XVWHKWIUÄ$QIRUGHUXQJHUIOOW³HLQMinuszeichenIUÄ$QIRUGHUXQJQLFKWHUIOOW³

IT-Architektur-Management-Portal

209

Grafiken aus ITMAP in Textverarbeitungsprogrammen oder Präsentationssystemen Verwendung finden. Die Datenbestände können mit Tabellenkalkulationssystemen weiter ausgewertet werden. Eine Importfunktionalität zur Übertragung von Daten aus Modellierungssystemen wie ARIS oder Visio ist nicht implementiert.

7.9

Anwendung

Im Folgenden wird zunächst dargelegt, wie typischerweise eine Applikation im Unternehmen eingeführt (vgl. Abbildung 7-31) und wie die IT-Architektur mit Hilfe von ITMAP abgebildet wird.

210

IT-Architektur-Management-Portal

V

XOR

Geschäftsbereich stellt Antrag auf neue Applikation

Strategiekonformität prüfen

XOR

SFI ist zu niedrig

Applikation ist neu gestaltet

SFI ist hoch genug

Softwarearchitektur ist neu gestaltet

Umgestaltung der Applikation

V

XOR

AAF und Beitrag zum AFI berechnen

XOR

AAF und AFI sind zu niedrig

Umgestaltung der Softwarearchitektur

Technologie zu Applikation zuweisen (Abb. 7-28)

Applikation anlegen (Abb. 725)

$EELOGXQJ 3UR]HVVÄ,73URMHNWIUHLJHEHQ³

AAF und AFI sind hoch genug

Freigabe des IT-Projekts

Projekt ist freigegeben, Implementierung beginnt

IT-Architektur-Management-Portal

211

Nach der Prüfung auf Strategiekonformität (vgl. Kapitel 4) und der Bestimmung des Beitrags zum AFI und eventueller Strafzahlungen für nicht konforme Bestandteile der Softwarearchitektur (vgl. Kapitel 5) wird das IT-Projekt freigegeben und in ITMAP angelegt. Mit den in ITMAP vorliegenden Datenbeständen kann der leitende IT-Architekt des Unternehmens nun Lücken in der Bebauung oder der IT-Infrastruktur identifizieren oder Redundanzen feststellen. Dazu dienen einerseits die aus Abschnitt 6.7.4 bekannten Kennzahlen und andererseits die grafischen Aufbereitungen des Bebauungsplans und der IT-Architektur. Redundante Plattformen stellt der IT-Architekt mit dem aus Abschnitt 7.6.4 gezeigten Verfahren fest. Die Bewertung und Steuerung der IT-Architektur nach dem in Abbildung 6-40 gezeigten Verfahren wird von ITMAP als zentrale Datenbasis für die ITArchitektur im Unternehmen unterstützt. Aus ITMAP heraus können die notwendigen Kennzahlen generiert werden. Das IT-Architektur-Management-Portal unterstützt damit ganzheitlich die Arbeit des IT-Architekten.

Kapitel 8 Schlussbemerkungen 8 Schlussbemerkungen 8.1

Zusammenfassung

Die zu Beginn dieser Arbeit formulierte Frage nach dem Beitrag der IT-Architektur zur Effizienz und Effektivität der IT wird mit einem konsistenten Modell, bestehend aus Kennzahlen und Prozessen, beantwortet. Der in Kapitel 2 diskutierten hohen Komplexität in der IT als Auslöser für immer geringere Investitionen in IT-getriebene Innovationen wird mit einem Modell zur strukturierten Dokumentation der Bestandteile einer unternehmensweiten ITArchitektur begegnet. Das aus Bebauungsplan und IT-Infrastruktur bestehende Modell ermöglicht zunächst einen transparenten Überblick über die Applikationen und Technologien im Unternehmen. Die im Rahmen des so genannten Business/ IT-Alignment geforderte Übereinstimmung der IT-Strategie mit der IT-Architektur [FiWi07, 163] wird durch ein Verfahren zur Gewährleistung der Strategiekonformität von IT-Projekten unterstützt. IT-Projekte werden vor dem Beginn der Implementierung anhand der Ziele der IT-Strategie auf den Beitrag zur Zielerreichung überprüft. Dabei wird sichergestellt, dass neue Applikationen in einem Unternehmen nur bei Konformität zur IT-Strategie eingeführt werden können. Die Komplexität in der IT-Architektur entsteht durch eine stetig zunehmende Anzahl an Applikationen und Technologien im Unternehmen. Fortlaufend werden neue Applikationen und Technologien im Rahmen von IT-Projekten entwickelt und in den Betrieb überführt, ohne in gleicher Anzahl alte Applikationen zu entfernen. Zur Reduzierung der Komplexität stellt diese Arbeit ein Verfahren vor, das ein IT-Projekt nach Prüfung auf Strategiekonformität auf die Konformität zur Soll-IT-Architektur untersucht. Zweck der Prüfung auf Architekturkonformität

ist

die

ausschließliche

Verwendung

der

in

der

Soll-IT-Architektur

vorgegebenen Technologien zur Realisierung neuer Applikationen (vgl. Abbildung 8-1).

214

Schlussbemerkungen

Anzahl Technologien und Applikationen

t Situation ohne IT-Architekturmanagement

Abbildung 8-1

Nur konforme ITProjekte erhalten Freigabe

Maßnahmen innerhalb der ITArchitektur

Soll-Zustand der IT-Architektur

Veränderung der IT-Architektur durch IT-Architektur-Management

Beide Prüfungen von IT-Projekten münden in Kennzahlen zur Steuerung und Durchsetzung der Soll-IT-Architektur. Mit der Gewährleistung der Architekturkonformität von IT-Projekten wird der unkontrollierte Zuwachs an Technologien im Unternehmen eingedämmt. Die Gesamtzahl der Technologien nimmt jedoch erst ab, wenn Maßnahmen innerhalb der IT-Architektur zur Ablösung von Technologien führen. Zur Identifikation dieser Maßnahmen dienen Kennzahlen, die den Wertbeitrag der IT-Architektur bemessen. Die Kennzahlen unterstützen den IT-Architekten bei der Priorisierung von Projekten zur Konsolidierung von Technologien und Applikationen. Die Umsetzung der in dieser Arbeit vorgestellten Methoden und Prozesse zum Management von IT-Architekturen im Unternehmen führt dazu, dass nur strategiekonforme Applikationen zu den bestehenden hinzukommen und ein unkontrolliertes Wachstum der Applikationslandschaft unterbleibt. Ebenso wird das Wachstum der Anzahl der Technologien mit der Prüfung auf Architekturkonformität beschränkt. IT-Projekte zur Reduzierung von nicht wertschöpfender Vielfalt in der IT-Architektur dienen der Reduktion der Komplexität der IT auf ein notwendiges Maß. Das auf Open Source-Technologien basierende IT-Architektur-Management-Portal unterstützt die Umsetzung des IT-Architektur-Managements im Unternehmen. Im Portal enthalten sind die Modelle Bebauungsplan und IT-Infrastruktur, Kennzahlen zur Bewertung der Qualität der IT-Architektur und Visualisierungen zur Kommunikation und Durchsetzung der Soll-IT-Architektur im Unternehmen.

8.2

Ausblick

Das vorgestellte Modell zur Strukturierung der IT-Architektur fokussiert auf Technologien und Applikationen im Kontext der Geschäftsprozesse eines Unternehmens. Die Datenarchitektur wird ebenso vernachlässigt wie die Schnittstellen zwischen Applikationen. Zwar wird aus dem Bebauungsplan ersichtlich, welche Applikationen im Prozessverlauf miteinander kommunizieren, die konkrete technische Ausprägung von Schnittstellen wird jedoch nicht

Schlussbemerkungen

215

dokumentiert. Hier bietet sich Raum für weitere Untersuchungen zur Visualisierung von komplexen IT-Architekturen, die auch Datenstrukturen und Schnittstellen mit einbeziehen. Die Software ITMAP ist in den hier vorgestellten Funktionalitäten voll funktionsfähig, benötigt jedoch für einen professionellen Einsatz im Rahmen eines Unternehmensportals noch folgende Erweiterungen:

x

Flexible Anbindung an gängige Verzeichnisdienste

x

Flexibel gestaltbares Rechte- und Rollenkonzept

x

Schnittstellen für den Import von bestehenden Datensammlungen zur ITArchitektur wie etwa Technologie- oder Applikationslisten

Des Weiteren ist ein ausführlicher Belastungstest notwendig, um die Stabilität bei hohen parallelen Zugriffszahlen zu gewährleisten.

Literaturverzeichnis Adam97

Adam, D.: Produktions-Management. Gabler, Wiesbaden 1997.

Adam98

Adam, D. (Hrsg.): Komplexitätsmanagement. Gabler, Wiesbaden 1998.

AdJo98

Adam, D.; Johannville, U.: Die Komplexitätsfalle. In: Adam, D. (Hrsg.): Komplexitätsmanagement. Gabler, Wiesbaden 1998, S. 5 - 28.

AdRo95

Adam, D.; Rollberg, R.: Komplexitätskosten. In: Die Betriebswirtschaft 55 (1995) 5, S. 667 - 670.

AiDo05

Aier, S.; Dogan, T.: Indikatoren zur Bewertung der Nachhaltigkeit von Unternehmensarchitekturen. In: Ferstl, O. K. (Hrsg.): Wirtschaftsinformatik 2005 eEconomy, eGovernment, eSociety. Physica-Verlag, Heidelberg 2005, S. 607 - 626.

Ambe99

Amberg, M.: Prozeßorientierte betriebliche Informationssysteme - Methoden, Vorgehen und Werkzeuge zur ihrer effizienten Entwicklung. Springer, Berlin 1999.

Andr06 ArKL99

Andres, M.: Die optimale Varianz. In: brand eins 8 (2006) 1, S. 65 - 69. Armour, F. J.; Kaisler, S. H.; Liu, S. Y.: Building Enterprise Architecture Step by Step. In: IT Professtional 1 (1999) 4, S. 31 - 39.

Ashb56 AuPr04

Ashby, R.: An Introduction to Cybernetics. Chapman & Hall, London 1956. Automobil-Produktion: Schafft VW den Spagat? In: Automobil-Produktion 18 (2004) 12, S. 13.

218

Baum06

Literaturverzeichnis

Baumöl, U.: Methodenkonstruktion für das Business-IT-Alignment. In: Wirtschaftsinformatik 48 (2006) 5, S. 314 - 322.

BeNS03

Bernus, P.; Nemes, L.; Schmidt, G.; Shaw, M.: Handbook on Enterprise Architecture. Springer, Berlin 2003.

BlBe03

Blomer, R.; Bernhard, M. G.: Was gehört zu einer IT-Strategie? In: Bernhard M. G; Blomer, R.; Bonn, J. (Hrsg.): Strategisches IT-Management Band 1 Organisation - Prozesse - Referenzmodelle. Symposion Publishing, Düsseldorf 2003, S. 93 - 111.

BiVa03

Birkhölzer, T.; Vaupel, J.: IT-Architekturen - Planung, Integration, Wartung. VDE Verlag, Berlin 2003.

Blis00

Bliss, C.: Management von Komplexität - ein integrierter systemtheoretischer Ansatz zur Komplexitätsreduktion. Gabler, Wiesbaden 2000.

Boar99

Boar, B. H.: Constructing Blueprints for Enterprise IT Architectures. Wiley, New York 1999.

Boar01

Boar, B. H.: The Art of Strategic Planning for Information Technology. Wiley, New York 2001.

Bode99

Bodendorf, F.: Wirtschaftsinformatik im Dienstleistungsbereich. Springer, Berlin 1999.

BoDu06

Bodendorf, F.; Durst, M.: Umsetzung von IT-Strategien bei IT-Projekten. In: Das Wirtschaftsstudium (WISU) 35 (2006) 11, S. 1415 - 1423.

BöKr05

Böhmann, T.; Krcmar, H.: Einfach besser? Zur Anwendbarkeit des industriellen Komplexitätsmanagements auf variantenreiche IT-Dienstleistungen. In: Ferstl, O. K.; Sinz, E. J.; Eckert, S.; Isselhorst, T. (Hrsg.): Wirtschaftsinformatik 2005 - eEconomy, eGovernment, eSociety. Physica, Heidelberg 2005, S. 449-468.

%ROO

%ROOHV * $ 7KLV 2OG ,QIUDVWUXFWXUH ± (QWHUSULVH $UFKLWHFWXUH http:/www.cioinsight.com/print_article/0,3668,a=117215,00.asp, 2004-01-01, Abruf am 2005-07-07.

Literaturverzeichnis

BoLT00

219

Boster, M.; Liu, S.; Thomas, R.: Getting the Most from Your Enterprise Architecture. In: IT Professional 2 (2000) 4, S. 43-50.

BrBr93

Brancheau, J. C.; Brown, C. V.: The Management of End-User Computing: Status and Directions. In: ACM Computing Surveys 25 (1993) 4, S. 437 428.

BrHa03

Brown, J. S.; Hagel III, J.: Flexible IT, Better Strategy. In: The McKinsey Quarterly (2003) 4, S. 50 - 59.

Broa05

Broadbent, M.: IT Architecture Matters. http://www.cio.com.au/index.php/ id;1699283945;fp;4;fpid;10, 2002-10-09, Abruf am 2007-01-15.

Brog96

Brogli, M.: Ein Performance Measurement System für die Informatik. Dissertation, Universität St. Gallen, St. Gallen 1996.

BuES04

Buchta, D.; Eul, M.; Schulte-Croonenberg, H.: Strategisches IT-Management - Wert steigern, Leistung steuern, Kosten senken. Gabler, Wiesbaden 2004.

Burn05

Burns, E.: Firefox Market Share Gains Continue. http://www.clickz.com/ showPage.html?page=3500691, 2005-04-16, Abruf am 2007-02-17.

Butt05

Butters, I.: IT-Standardisierung senkt die Kosten im gesamten Unternehmen. http://www.cio.de/strategien/811624/index.html, 2005-07-25, Abruf am 200702-05.

Buxm96

Buxmann, P.: Standardisierung betrieblicher Informationssysteme. Gabler, Wiesbaden 1996.

BYDH03

Boh, W. F.; Yelling, D.; Dill, B.; Herbsleb, J. D.: Effectively Managing InforPDWLRQ6\VWHPV$UFKLWHFWXUH6WDQGDUGV±$Q,QWUD2UJDQL]DWLRQ3HUVSHFWLYH http://www.si.umich.edu/misq-stds/proceedings/140_171-187.PDF, 2003-1214, Abruf am 2006-05-01.

ByTu01

Byrd, T. A.; Turner, D. E.: An Exploratory Examination of the Relationship Between Flexible IT Infrastructure and Competitive Advantage. In: Information & Management 39 (2001) 1, S. 41 - 52.

220

CaMe05

Literaturverzeichnis

Carnegie

Mellon

Software

Engineering

Institute:

What

is

CMMI?

http://www.sei.cmu.edu/cmmi/general/general.html, 2005-07-28, Abruf am 2006-08-16. &DUU

&DUU1*,7'RHVQ¶W0DWWHU,Q+DUYDUG%XVLQHVV5HYLHZ 6 41 - 49.

&%%*

&OHPHQWV3%DFKPDQQ)%DVV/*DUODQ',YHUV-/LWWOH51RUG 5 6WDIIRUG - 'RFXPHQWLQJ 6RIWZDUH $UFKLWHFWXUHV  9LHZV DQG %H\RQG $GGLVRQ:HVOH\/RQJPDQ$PVWHUGDP

&(%

&RUSRUDWH ([HFXWLYH %RDUG 9LVXDOL]LQJ ,7 9DOXH &UHDWLRQ  7DFWLFV IRU &RPPXQLFDWLQJ,7&RQWULEXWLRQVWR&RUSRUDWH6WUDWHJ\:RUNLQJ&RXQFLOIRU Chief Information Officers, 2001.

&H/H

&HFHUH 0 /HJDQ]D * 0HWKRGV RI )XQGLQJ (QWHUSULVH $UFKLWHFWXUH (I IRUWV)RUUHVWHU&DPEULGJH

&KHQ

&KHQ 3 7KH HQWLW\UHODWLRQVKLS PRGHO 7RZDUG D XQLILHG YLHZ RI GDWD ,Q $&07UDQVDFWLRQVRQ'DWDEDVH6\VWHPV 6

&KUL

&KULVW 3 2UJDQLVDWLRQ GHU 9HUDQWZRUWXQJ GHU 2UJDQLVDWLRQ +DXSW 9HUODJ %HUQ

&,2&

&,2 &RXQFLO)HGHUDO $JHQFLHV $UFKLWHFWXUH :RUNLQJ *URXS $ 3UDFWLFDO *XLGH WR )HGHUDO (QWHUSULVH $UFKLWHFWXUH KWWSZZZJDRJRYEHVWSUDFWLFHV bpeaguide.pdf, 2001, Abruf am 2007-01-11.

&1