145 67 4MB
German Pages 260 Year 2008
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'DWHQXQGJURHU'\QDPLNQHLJHQ2UJDQLVDWLRQHQ]XDOVHIIL]LHQWHUNDQQWHQGH]HQWUD OHQ (QWVFKHLGXQJVNRPSHWHQ]HQ 'XUFK 'H]HQWUDOLVLHUXQJ XQG 6HOEVWVWHXHUXQJ ZHUGHQ 0RWLYDWLRQVNUlIWHIUHLJHVHW]WVRGDGLH4XDOLWlWGHU3UREOHPO|VXQJHQSULQ]LSLHOOVWHLJWXQG GLH/|VXQJHQVFKQHOOHUJHQHULHUWZHUGHQN|QQHQ0LWGHU=HUOHJXQJYRQ(QWVFKHLGXQJVIHO GHUQJHKHQDEHUGLH%H]LHKXQJHQ]ZLVFKHQGHQ(QWVFKHLGXQJHQGHU7HLOEHUHLFKHYHUORUHQ XQG HV JHOLQJW KlXILJ QXU XQ]XUHLFKHQG IU 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]XEHUWUDJHQ³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 KHLW 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 9HUNQSIXQJ 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 .XQGHQZQVFKHQ NDQQ GDEHL LQ GLH VR JHQDQQWH .RPSOH[LWlWVIDOOH IKUHQ >$G-R@ ,PPHU PHKU 3URGXNWYDULDQWHQ EHL QDKH]X JOHLFK EOHLEHQGHP 0DUNWYROXPHQ IKUHQ ]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 6WFN]DKOHQ 'LVSRVLWLRQVDXIZDQGIU PHKU3RVLWLRQHQ =XQDKPHGHU Verhandlungsgespräche mit Lieferanten +|KHUHU$XIZDQGIU Qualitätssicherung von ]XJHOLHIHUWHQ Komponenten +|KHUHU$XIZDQGGHU 5HFKQXQJVSUIXQJ
11
Fertigung / Montage *HULQJHUH/RVJU|HQ +|KHUH5VWNRVWHQ 6LQNHQGHU Auslastungsgrad der Fertigungsanlagen *HULQJHUH6WFN]DKOHQMH Auftrag *HULQJHUH3URGXNWLYLWlW durch geringere Lerneffekte /HHUNDSD]LWlWHQEHL 1DFKIUDJHUFNJDQJ +|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 IU 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.XQGHQZQVFKHQQRWZHQGLJLVW 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 0DQDKPHQ 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 LQVWUXPHQWHPVVHQGLH$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 IU 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*UXQGOLHJWLQHLQHP0LYHUVWlQGQLV]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 8QWHUVWW]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 PVVHQ *OHLFK]HLWLJ ZHUGHQODXIHQGQHXH$SSOLNDWLRQHQLQGDV,73RUWIROLRPLWDXIJHQRPPHQGDHLQHUVHLWVGLH *HVFKlIWVEHUHLFKH QHXH ,7/|VXQJHQ ]XU 5HDOLVLHUXQJ LQQRYDWLYHU 3URGXNWH XQG *H VFKlIWVPRGHOOHIRUGHUQXQGDQGHUHUVHLWV7HFKQRORJLHVSUQJHLQGHU,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]WXQGDXHUKDOEGHUELVKHULJHQ6WDGWJUHQ ]HQZHUGHQPRGHUQH6WDGWYLHUWHOZLH/D'pIHQVHDXIGHUJUQHQ:LHVHHUULFKWHW'LH,QIUD VWUXNWXU LQ )RUP YRQ 6WUDHQ %UFNHQ 6FKLHQHQ :DVVHU XQG 6WURPYHUVRUJXQJ XVZ YHUNQSIWDOOH*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 EHUPlLJH .RPSOH[LWlW QHJDWLYH (IIHNWH ZLH 9HUNHKUVVWDXV EHUIOOWH 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 IKUW >:LOG@ 'DV YRP ,7 16
=XU %HDUEHLWXQJ GHV -DKU 3UREOHPV ZXUGHQVR JHQDQQWH Ä'95HQWQHU³ UHDNWLYLHUW XQG GLH 6WXQGHQVlW]HIU&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 IU 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|IIQHQXQGVFKOLHHQ³ 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 GUIWH 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 IU Ä.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 PVVWHGHU,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 ÄDXVVFKOLHOLFK GXUFK GHQ ,7%HUHLFK RKQH (LQEH]LHKXQJ GHU *HVFKlIWVEHUHLFKH³ ELV ÄDXVVFKOLHOLFK 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 IU 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, ÄGDVULFKWLJH0DDQ3URGXNWIXQNWLRQDOLWlWNRPSOH[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 GDIU 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
9HUHLQIDFKWEHUQRPPHQDXV>(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 JURDUWLJH 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 0DQDKPHQ 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]LHKHQ8QWHUVWW 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]HLWXQG0DQDJHPHQWXPJHEXQJIU(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]XQJHQIUGLHVWlG 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 IU (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]HVVXQWHUVWW]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 0DQDKPHQSODQXQJ 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 ÄGLH5DKPHQDXVVDJHQIUGDV,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$XVNXQIWEHU die Zielerreichung ('AFI = AFIIst - AFISoll). Ein negatives '$),VWHKWIUHLQH=LHOYHUIHKOXQJ HLQSRVLWLYHVIUHLQH=LHOEHU HUIOOXQJ(LQSRVLWLYHV'AFI als Bestandteil des Mitarbeiter]LHOV\VWHPVIKUW]X%RQXV]DKOXQJHQIU,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 folgenGHUPDHQ(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,78QWHUVWW]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 WieGHU8QWHUVWW]XQJGHU*HVFKlIWVSUR]HVVHEH]HLFKQHQXQGGLHVHUGLH,7.RVWHQXQGGLH 4XDOLWlWGHU,73URMHNWH]XRUGQHQ>.5$%@'LH,7(IIHNWLYLWlWEHVFKUHLEWLQZLHZHLWGLH (UZDUWXQJHQ GHU *HVFKlIWVEHUHLFKH DQ GLH ,7 HUIOOW 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
9HUlQGHUWEHUQRPPHQDXV>+LSS3RWW@ ($ VWHKW IU (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 YHUIJEDU XQG LQ ZHOFKHP 0DH VLH WDW VlFKOLFKJHQXW]WZHUGHQ³ [KRAB98, 17], also das :RIU 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 ,78QWHUVWW]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 ÄXQWHUVWW]HQGLH$QDO\VHXQG *HVWDOWXQJ NRPSOH[HU EHWULHEOLFKHU 6\VWHPH $OV %HVFKUHLEXQJVPRGHOOH HUIDVVHQ VLH GLH ,VW6LWXDWLRQHLQHV8QWHUQHKPHQVDOV*HVWDOWXQJVPRGHOOHGLHQHQVLHQRUPDWLYDOV9RUODJH IU 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 ÄLVWGDIUYHUDQWZRUWOLFKGDVVEHUHLWJHVWHOOWH,6 105MHGHU]HLWYHU IJEDU VLQG XP GLH *HVFKlIWVSUR]HVVH ]X XQWHUVWW]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 IU 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
$OV7HFKQRORJLHIUGLH%HQXW]HULQWHUDNWLRQGLHQWDXVVFKOLHOLFKGHU%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 IU 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 IU 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 *HJHQVWDQGVGHUIUHLQJHJHEHQHV$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 VSUQJOLFKHQ ,GHH XQG GHU (QWVFKHLGXQJ HLQH $QZHQGXQJ ]X NUHLHUHQ RGHU ]X
IT-Architektur-Management-Portal
185
EH]LHKHQEHUGLH(QWZLFNOXQJXQG(LQIKUXQJ>«@ELV]XUDEVFKOLHHQGHQ$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'URSGRZQ0HQLQGHPDO OH]XU9HUIJXQJVWHKHQGHQ6SUDFKHQDQJH]HLJWZHUGHQ1DFKGHU$XVZDKOHLQHU6SUDFKH NOLFNW GHU $QZHQGHU DXI Sprache festlegen XQG ,70$3 HUVFKHLQW YRQ QXQ DQ LQ GHU JH ZQVFKWHQ 6SUDFKH 'LH 6SUDFKHLQVWHOOXQJ HUIROJW IU MHGHQ $QZHQGHU LQGLYLGXHOO ,70$3 VSHLFKHUWGLHMHZHLOVJHZQVFKWH6SUDFKH]XVDPPHQPLWGHQ'DWHQGHV$QZHQGHUV Der Menüpunkt ausloggen IKUW ]XUFN ]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³VWHKWIUSchadensmeldung 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 JHZQVFKWH7HFKQRORJLHQLFKWYRUKDQGHQLVWZlKOWGHU$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 YHUIJW ü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]XIJHQ³GLHEHUGLH0DVNHÄ/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 JHZQVFKWHQ 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 XVWHKWIUÄ$QIRUGHUXQJHUIOOW³HLQMinuszeichenIUÄ$QIRUGHUXQJQLFKWHUIOOW³
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