IT-Unternehmensarchitektur - Von der Geschäftsstrategie zur optimalen IT-Unterstützung

von: Wolfgang Keller

dpunkt, 2012

ISBN: 9783864910876

Sprache: Deutsch

433 Seiten, Download: 12132 KB

Format: EPUB, PDF, auch als Online-Lesen

geeignet für:

Apple iPod touch, iPhone und Android Smartphones

eBook anfordern

▸

Mehr zum Inhalt

IT-Unternehmensarchitektur - Von der Geschäftsstrategie zur optimalen IT-Unterstützung

	Vorwort zur 2. Auflage	8
	Vorwort zur 1. Auflage	12
	Danksagung	14
	Inhaltsübersicht	16
	Inhaltsverzeichnis	18
	1 Einleitung und Überblick	26
	Abb. 1-1 Agenda eines IT-Vorstands nach [Broadbent+05]	26
	1.1 Motivation des Buches	28
	Abb. 1-2 Aufgabengebiete des IT-Managements - dargestellt anhand der Gliederungen des IT Governance Institute (ITGI, links) [ITGI11] und nach Weill (rechts) [Weill+04]	28
	1.2 Struktur des Buches	30
	Abb. 1-3 Kapitelstruktur des Buches	30
	Abb. 1-4 Zusammenhang der Teile des Buches	33
	1.3 Wer sollte dieses Buch lesen und warum?	35
	1.3.1 IT-Unternehmensarchitekten	35
	1.3.2 Verantwortliche für Business Development	37
	1.3.3 IT-Vorstände	37
	1.3.4 Softwarearchitekten	38
	1.3.5 Alle anderen IT-Mitarbeiter	39
	1.3.6 Studierende	39
	1.3.7 Ist dieses Buch auch für den Mittelstand oder für Behörden interessant?	39
	1.4 Wie können Sie dieses Buch lesen?	40
	1.5 Einige Besonderheiten	41
	1.5.1 Sprache: Deutsch	41
	1.5.2 Verwendung von Wikipedia-Definitionen	41
	1.6 Was sich seit der ersten Auflage geändert hat	41
	2 Was ist IT-Unternehmensarchitektur?	44
	2.1 Das Substantiv: Unternehmensarchitektur als Struktur	45
	Definition: Enterprise Architecture	45
	Abb. 2-1 Unternehmensarchitektur - Sicht aus [Engels+08], [Kappes+09] - leicht angepasst	46
	2.1.1 Geschäftsarchitektur	46
	Abb. 2-2 Bestandteile einer Geschäftsarchitektur nach [Reynolds10]	47
	Abb. 2-3 Beispiel für die Kategorien eines Geschäftsmodells (aus dem Englischen übersetzt auf Basis von [Doblaski03])	48
	2.1.2 IT-Unternehmensarchitektur	49
	Abb. 2-4 Beziehung von Unternehmensarchitektur und IT-Unternehmens- architektur (analog zu [Engels+08] - leicht angepasst)	49
	Abb. 2-5 Architektur- Modellpyramide nach Dern [Dern03]	50
	Abb. 2-6 TOGAF Content Metamodel Overview [TOGAF9]	51
	2.2 Die Tätigkeit: Unternehmensarchitektur als Management	51
	Abb. 2-7 Prozesslandkarte IT- Unternehmensarchitektur	52
	Trennung Business/IT ist auf Dauer wenig sinnvoll	52
	2.3 Musterbasierter Ansatz für IT-Unternehmensarchitektur	53
	EAM-Patternkatalog der Technischen Universität München	53
	Abb. 2-8 Viewpoint-Pattern »V-6 Architectural Standard Clustering« (Quelle: http://wwwmatthes. in.tum.de/wikis/ eam-pattern-catalog/v-6, aufgerufen am 12.8.2011)	55
	Abb. 2-9 Information-Model- Pattern »I-6 Usage of Architectural Solutions« (Quelle: http:// wwwmatthes.in.tum.de/ wikis/eam-pattern- catalog/i-6, aufgerufen am 12.8.2011)	56
	Konfiguration mit den Patterns des TUM-EAM-Patternkatalogs	56
	Anwendung der Pattern-Idee in diesem Buch	56
	3 Zielmuster	58
	Abb. 3-1 Beziehungen gebräuchlicher Zielmuster in IT-Unternehmens- architektur (IT-Management)	58
	Tab. 3-1 Prioritätenliste von CIOs (Quelle: Jährliche Umfrage der Society for Information Management, 2010)	60
	3.1 Business-IT-Alignment	61
	3.1.1 Bedeutung	61
	Abb. 3-2 Prioritäten von CIOs über mehrere Jahre (Quelle: CIO Panels der Society for Information Management 2008 - 2010)	62
	3.1.2 Dimensionen	63
	3.1.3 Zwischenbilanz	65
	3.2 Verbesserung der Ertragskraft und Kostenmanagement	66
	3.2.1 Verbesserung der Ertragskraft des Business	66
	3.2.2 Reduktion von IT-Kosten	69
	Abb. 3-3 IT-Fitnessprogramm. Bei allen dunkelgrau hinterlegten Feldern spielt IT-Unternehmens- architektur eine wesentliche Rolle.	69
	3.3 Optimierung mit Sourcing-Strategien	74
	3.4 Verbesserung Time-to-Market	74
	3.5 Verbesserung Kundenzufriedenheit	77
	3.6 Reduktion von Heterogenität	78
	3.7 Bewältigung von Fusionen	78
	3.8 Compliance, Sicherheit und Risikomanagement	79
	4 Managementprozessmuster	80
	Abb. 4-1 Prozesslandkarte IT-Unternehmensarchi- tektur nach [Dern+08] (redundant zu Abb. 2-7 - um Ihnen als Leser mühsames Blättern zu ersparen)	80
	Tab. 4-1 Zusammenhang zwischen Zielmustern und unter- stützenden Manage- mentprozessmustern	83
	4.1 IT-Strategieentwicklung	84
	4.1.1 Was ist eine Strategie?	84
	Definition: Strategie	85
	Definition: Strategie (Clausewitz)	85
	4.1.2 Ein kurzer Blick auf den Strategieprozess	85
	4.1.3 Wozu sollte eine IT-Strategie Aussagen machen?	86
	Abb. 4-2 Einordnung des Maxime-Prozesses in den IT-Strategieprozess. Die Erarbeitung von Business- und IT-Maximen ermög- licht die sinnvolle Defini- tion der IT-Governance- Strukturen und die Erar- beitung und Ausformulie- rung einer IT-Strategie.	86
	Abb. 4-3 Strategieraster der Gartner Group (aus [Gartner03b], [Gartner03c] ins Deutsche übersetzt). Die Matrix zeigt exemplarisc...	86
	Abb. 4-4 Bausteine für IT-Strategie [Gartner03b]	88
	4.1.4 Herausforderungen bei der Umsetzung in der Praxis	89
	Geschäftsstrategie ist nicht dokumentiert	89
	Geschäftsstrategie ist nicht fokussiert	90
	Geschäftsstrategie ist in sich widersprüchlich	90
	Das Management kümmert sich nicht ausreichend um das Thema	90
	Infrastruktur-Betriebsstrategie spielt eine Nebenrolle	90
	4.1.5 Der Maxime-Prozess	91
	Beispiel für eine Geschäftsmaxime und die daraus abgeleitete IT-Maxime	91
	4.2 Business-IT-Alignment herstellen mit Capabilities	92
	4.2.1 Was sind Capabilities	92
	Definition: Capabilities	92
	Definition: Capability	93
	Definition: Capability	93
	Abb. 4-5 Capabilities können mit IT implementiert werden, sie lassen sich aber auch rein manuell implementieren.	93
	4.2.2 Investitionssteuerung mit Capabilities	94
	Abb. 4-6 Thermografie als Beispiel für Heat Maps	94
	Abb. 4-7 Beispiel für eine Heat Map in einem Unternehmen [HeatMap06]: Hier interessiert zunächst nur der »oberflächliche optisch...	95
	4.2.3 Wie kommt man zu einem sinnvollen Katalog von Capabilities?	95
	Abb. 4-8 Capability-Landkarte (oberste Ebene) [Merrifield+06]	96
	Abb. 4-9 Oberste Ebene des Capability-Modells eines stark vertriebsorientierten Finanzdienstleisters3	97
	Abb. 4-10 Beispiel für elementare Geschäftsfähigkeiten in Ausschnitten aus zwei verschiedenen Modellen (links bzw. rechts)	97
	4.2.4 Wie kommt man zu den Bewertungen der Capabilities?	98
	Abb. 4-11 Festlegen der Bewertungsfunktionen für Heat Maps	98
	4.2.5 Zwischenbilanz: Warum helfen Capabilities bei der strategischen Ausrichtung einer Anwendungslandschaft?	99
	4.2.6 Optimierung des Sourcings einer Anwendungslandschaft mit Capabilities	99
	Abb. 4-12 Zerlegen einer Anwen- dung in strategische und nicht strategische Teile mithilfe einer Analyse von Capabilities	100
	4.2.7 Vergleich von Anwendungen mit Footprints	101
	Abb. 4-13 Bewertungen von Anwendungen mithilfe von Capabilities	101
	4.3 Management des Anwendungsportfolios	102
	4.3.1 Grundlegende Begriffe zum Management des Anwendungsportfolios	103
	Definition: Portfolio	103
	Definition: Anwendung (Application)	104
	Unterschiede zu Finanzanlagen	104
	4.3.2 Management des Anwendungsportfolios als zyklischer Prozess	106
	Abb. 4-14 Management des Anwendungsportfolios als zyklischer Prozess	106
	4.4 Erfassung der Ist-Anwendungslandschaft	108
	4.4.1 Umfang	108
	4.4.2 Typische Attribute für eine minimale Befüllung	109
	4.4.3 Erfassung von Schnittstellen: Ja oder Nein?	110
	Abb. 4-15 Architekturmodelle in der IT-Unternehmensarchi- tektur werden meist breit (Mile Wide), aber flach (Inch Deep) angelegt...	110
	4.4.4 Key Visual für die Anwendungslandschaft	111
	Abb. 4-16 Beispiel für eine komplette Bank-Anwendungslandschaft. Sie werden dieses Bild in vielen Vorträgen der Credit Suisse im...	112
	4.4.5 Tipps und Tricks	112
	4.5 Auswertungen des Anwendungsportfolios	113
	Grundmodell Marktwachstum-Marktanteil-Portfolio der BCG	114
	Abb. 4-17 Beispiel für eine Markt- wachstum-Marktanteil- Matrix. Die Fläche der Kreise symbolisiert den Umsatz eines Geschäfts- felds. In einer solchen Matrix kann das kom- plette Produktportfolio einer Firma eingetragen werden.	115
	Anwendungsportfoliomanagement nach Ward/Griffiths/Peppard	116
	Abb. 4-18 Boston-Square- Produktportfoliomatrix übertragen auf ein Anwendungsportfolio [Ward+02, S. 299 ff.]	116
	Bezug zum Management des Softwareentwicklungsprozesses	117
	4.6 Anwendungslandschaft, Metriken und Dashboards	118
	Abb. 4-19 Beispiel für ein einfaches Dashboard (Quelle: Vorlesung »Software Engineering für betriebliche Anwen- dungen«	120
	4.7 Strategische Bebauungsplanung	121
	Definition: Strategische IT-Planung	121
	4.7.1 Grundsätzliches Vorgehen	122
	Abb. 4-20 Workflow für die Erstellung einer strategischen Anwendungsplanung	122
	4.7.2 Erfassen der Anforderungen (Scoping)	123
	4.7.3 Analyse und Bewertung (Analysis)	125
	4.7.4 Erarbeiten der Zielbebauung	125
	4.7.5 Abstimmung (Design)	126
	4.7.6 Maßnahmenplanung (Plan Implementation)	127
	4.7.7 Zusammenfassung der strategischen Bebauungsplanung	127
	4.8 Management eines Serviceportfolios	128
	Abb. 4-21 Anwendungssicht mutiert zu SOA-Sicht [Slama+11]	128
	Definition Service Portfolio Management	129
	Abb. 4-22 Capabilities benötigen Prozesse. Die IT-unterstützten Prozesse benötigen IT-Support in Form von Services.	129
	Abb. 4-23 SOA bildet u. a. Geschäftsprozesse auf Services ab, es besteht eine Beziehung zu Capabilities.	130
	Abb. 4-24 Von der Capability über Geschäftsprozesse zum Service	131
	Abb. 4-25 Service Portfolio Management benötigt u. a. auch Capability- basierte Planung, Business Process Management und SOA-Governance für ein sinnvolles Funktionieren.	132
	4.9 Managed Evolution	133
	Abb. 4-26 Schrittweise Verschlechterung eines »sehr großen Software- systems« durch opportunistische Projekte [Murer+11, S. 16]	134
	Abb. 4-27 Vorgehen bei Managed Evolution. Projekte werden so gesteuert, dass das Gesamtsystem in einem festgelegten Ziel- korridor aus Agilität und Geschäftswert bleibt. Verschlechterung wird verhindert [Murer+11, S. 24].	135
	4.10 Etablieren eines IT-Governance-Systems	137
	Definition: Governance	137
	4.10.1 Was ist IT-Governance?	138
	Definition: IT-Governance (ITGI)	138
	Abb. 4-28 IT-Regelkreise der Meta Group [Meta02]	138
	4.10.2 Hierarchie von Governance-Systemen	139
	Abb. 4-29 Hierarchie von Governance-Systemen	139
	4.10.3 Stile von IT-Governance	140
	Abb. 4-30 Governance-Archetypen nach Weill [Weill04]	141
	Abb. 4-31 Häufigste Verteilungen der Entscheidungs- und Mitwirkungsrechte je Entscheidungsfeld eines IT-Governance-Systems [Weill04]. Stark umrandete graue Felder sind die am häufigsten genannten Verteilungen der Entscheidungsrechte je Entscheidungsfeld.	141
	4.10.4 Hinzunahme des Unternehmenstyps	143
	Reife von Industrien, Grad an Föderalismus	143
	Werttreiber	144
	Generische Wettbewerbsstrategien nach Porter	145
	Einfluss der Situation Ihres Unternehmens auf die Strategie	146
	Abb. 4-32 Generische Wettbewerbsstrategien nach Porter [Porter89]	146
	Typisiert und dann? Anwendung der Merkmalsraster	147
	4.11 Architektur-Governance	148
	Definition: Architektur-Governance (Architecture Governance)	148
	4.11.1 Aufbauorganisation der IT-Governance und Architektur- Governance	149
	Einbettung in die Organisation des Gesamtunternehmens	149
	Abb. 4-33 Exemplarische Dar- stellung - Einbettung einer zentralen IT in ein Unternehmen mit mehreren Geschäftseinheiten	150
	Gremien	150
	Abb. 4-34 Typische Berichtswege für IT-Komitee und IT-Architekturboard	151
	Typische Entscheidungs- und Vorschlagsrechte	152
	Abb. 4-35 Typische Verteilung von Vorschlags- und Entscheidungsrechten in einem großen IT- Anwenderunternehmen	152
	Mehr zu Architekturboard und IT-Unternehmensarchitekturgruppe	153
	Abb. 4-36 Typische Aufgaben- verteilung für die Prozesse der IT-Unternehmens- architektur	153
	Beispielhafte Aufgaben eines Architekturboards	154
	4.11.2 Entwicklung und Durchsetzung von Richtlinien	155
	Abb. 4-37 Schritte bei der Entwicklung und Durchsetzung von Richtlinien	155
	Regelungsbedarf erkennen	156
	Richtlinien entwerfen	157
	Das perfekte »Design Manual«, mit dem man aus dem Stand aus Berufsanfängern erfahrene Softwaredesigner machen kann, gibt es nicht.	157
	Richtlinien abstimmen	159
	Richtlinien kommunizieren und durchsetzen	159
	Richtlinien aktualisieren	160
	4.11.3 Monitoring des Projektportfolios	161
	Ziel des Monitorings	161
	Durchführung des Monitorings	163
	4.11.4 Projektbegleitung	164
	Kontinuierliche Begleitung	164
	Abb. 4-38 Phasen der Projektbegleitung	164
	Initiales Gespräch	165
	Als Beispiel dafür, wie man Vertrauen nicht aufbauen kann, möge folgende Geschichte dienen:	165
	Periodische Gespräche	166
	Retrospektive	167
	4.11.5 Über Reviews im Rahmen der Projektbegleitung	167
	Wie man in den Wald hineinruft, so schallt es hinaus.	167
	Ziel von Reviews, Vorgehen bei Reviews:	168
	Der Fall des vorgeblichen »Vollidioten«:	168
	Der Fall des vorgeblichen »Vollidioten« (Fortsetzung):	169
	Noch zwei Tricks	170
	Für Fortgeschrittene: Fly on the Wall und Writers’ Workshops	171
	Keine Rückdelegation zulassen	171
	4.12 SOA-Governance	172
	4.12.1 Schichten	172
	Abb. 4-39 Klassifikation von SOA-Initiativen	173
	Definition: SOA-Governance	173
	4.12.2 Operationale und technische SOA-Governance	174
	4.12.3 Business-Motivation für SOA	175
	4.13 Management von Fusionen	176
	Fangen Sie überhaupt an, die Situation zu bereinigen?	176
	4.13.1 Die Leiter der Integration	177
	Abb. 4-40 Die Leiter der Integration: Je weiter Sie auf dem Weg der Integration fortschreiten, desto höher werden die Stufen und desto geringer wird der relative Ertrag. Gleich- zeitig steigen auch die Projektrisiken an.	177
	4.13.2 Grundmuster von Anwendungskonsolidierungen	178
	Kompletter Neubau	178
	Cherry Picking	179
	Dampfwalze	180
	Auch Zukauf kann Dampfwalze sein	181
	4.14 Reduktion von Heterogenität	181
	5 Sichten und Informationsmodelle	184
	Abb. 5-1 Auf den ersten Blick erscheint die Menge verschiedener Diagramme zur Beschreibung von Anwendungslandschaften [Wittenburg07] schier unüberschaubar.	184
	5.1 Softwarekartografie als Grundlage der Systematisierung	186
	Abb. 5-2 Ebenen von Karten und Softwarekarten	186
	5.2 Typen von Softwarekarten	187
	5.2.1 Clusterkarten	188
	Abb. 5-3 Beispiel für eine Softwarekarte vom Typ Clusterkarte	188
	5.2.2 Prozessunterstützungskarten	189
	Abb. 5-4 Beispiel für eine Softwarekarte vom Typ Prozessunter- stützungskarte	190
	5.2.3 Intervallkarten	191
	Abb. 5-5 Beispiel für eine Softwarekarte vom Typ Intervallkarte	191
	5.2.4 Karten ohne Kartengrund	192
	Abb. 5-6 Beispiel für eine Softwarekarte ohne Kartengrund zur Verortung	192
	5.3 Viewpoints und Viewpoint-Patterns	192
	5.3.1 Viewpoints in IEEE 1471 und TOGAF	192
	Abb. 5-7 Konzeptuelles Modell des IEEE 1471 [IEEE00]	193
	5.3.2 Viewpoint-Patterns	194
	Abb. 5-8 Beispiel für die Anwendung des Viewpoint-Patterns V-76, Technology Usage Viewpoint (Quelle: http://wwwmatthes.in.tum.de...	195
	Abb. 5-9 Information-Pattern I-76 »Infrastructure Usage« (Quelle http://wwwmatthes. in.tum.de/wikis/ eam-pattern-catalog/i-76, aufgerufen am 28.1.2011)	195
	5.3.3 Diskussion der Pattern-Qualität	196
	5.4 Informationsmodelle	196
	5.4.1 Das TOGAF Content Metamodel	198
	Abb. 5-10 Überblick über das TOGAF Content Model (Informationsmodell): vereinfachte Form von Abbildung 2-6	198
	5.4.2 Hybride Wikis als Repository für IT-Unternehmensarchitektur	199
	Abb. 5-11 Ausschnitt aus dem TOGAF Content Metamodel - Teil: Core Content Metamodel [TOGAF9]	199
	Weiterentwicklung: semantische Wikis	201
	Hybride Wikis	201
	Abb. 5-12 Bearbeiten eines einzelnen Attributs einer Seite in einem hybriden Wiki	202
	Abb. 5-13 Tabelle aller Attribute der Wiki-Seiten mit dem Typ-Tag »applicationsystem«	204
	Abb. 5-14 Bearbeiten der Konsistenzbedingungen für das Attribut »intendedBlueprint« für Seiten mit dem Typ-Tag »applicationsystem« im Wiki »SyCaStore«	205
	Kommunikation und Zusammenarbeit über hybride Wikis	205
	Einsatzpotenziale für hybride Wikis im Enterprise Architecture Management	206
	6 Compliance	208
	Haftungsausschluss	208
	6.1 Was ist »Compliance«?	208
	Definition: Compliance	209
	6.2 IT-Compliance im Kontext von Enterprise Compliance	210
	Abb. 6-1 Aufteilung von Corporate Compliance in einzelne Arbeitsgebiete [Behringer10]	211
	Abb. 6-2 Compliance-Würfel für IT-Compliance [Behringer10, S. 201]	211
	6.3 Exemplarische Compliance-Themen für die IT	212
	6.3.1 Basel II und III	212
	Wo und wann gilt Basel II?	214
	Was heißt das für IT-Unternehmensarchitekten von Banken?	215
	Was heißt Basel II für IT-Manager von Kundenunternehmen?	216
	6.3.2 Solvency II	216
	Wo und wann gilt Solvency II?	217
	Was heißt Solvency II für IT-Unternehmensarchitekten von Versicherungen?	217
	6.3.3 Der Sarbanes-Oxley Act (SOX)	217
	Gültigkeitsbereich	218
	Wesentliche Stellen für den IT-Verantwortlichen	218
	Aus Section 302	218
	Aus Section 404	219
	Konsequenzen der Nichtbefolgung von SOX	219
	Konsequenzen für den IT-Bereich	220
	SOX kann man also nicht nur als Last empfinden, sondern auch als Chance, vom Management Unterstützung dafür zu bekommen, ordentliche Arbeit machen zu dürfen.	221
	Was tun kleine Firmen?	221
	6.4 KonTraG	222
	6.5 Aufbewahrungsfristen	223
	6.5.1 E-Mails sind archivierungspflichtig	223
	6.5.2 Stilllegung von DV-Systemen	224
	6.6 COBIT und Compliance	225
	6.6.1 Beispiel aus Version 4.1: PO1 Define a Strategic IT Plan	226
	Tab. 6-1 Output-Matrix des COBIT-4.1-Prozesses PO1 - Define a Strategic IT Plan [COBIT07, S. 31]	226
	Tab. 6-2 Matrix der Verantwortlichkeiten für die strategische IT-Planung [COBIT07, S. 31]	226
	Tab. 6-3 Auszüge aus einigen COBIT-Kontrollzielen, die Architekturthemen betreffen [COBIT07, S. 34]	227
	6.6.2 Beispiel aus Version 5.0: AP02 - Define Strategy	227
	Abb. 6-3 RACI-Chart für den COBIT-Prozess »AP02 Define Strategy« [COBIT11b, S. 52]	228
	Rolle von COBIT	229
	6.7 Der Clinger-Cohen Act	229
	7 IT-Sicherheit	230
	Abb. 7-1 Entwicklung von Sicherheitsrisiken (Quelle: http://www.corporate- trust.de/pdf/Gefahren- barometer2010.pdf)	231
	7.1 Bedarfsgerechte Sicherheit	231
	7.2 Organisation zur IT-Sicherheit	232
	7.2.1 Sicherheit als Prozess	232
	7.2.2 Ebenen der IT-Sicherheit	232
	7.2.3 Andere Akteure der IT-Sicherheit	233
	Abb. 7-2 Bedrohungen in der IT-Sicherheit - Herkunft von Attacken	233
	7.2.4 Aufgaben der Unternehmensarchitektur	235
	7.3 Architekturgrundsätze IT-Sicherheit	236
	7.4 Anforderungsanalyse IT-Sicherheit	236
	7.5 Schutzbedarfsfeststellung	237
	7.6 Sicherheitsbebauung	239
	7.7 Typische funktionale Sicherheitsmaßnahmen	240
	7.7.1 Rollen und Rechte	240
	Single Sign-on (SSO)	241
	Rollenbasierter Zugriffsschutz	241
	7.7.2 Logging	242
	7.8 Typische nicht funktionale Sicherheitsmaßnahmen	243
	7.8.1 Modellierung von Schutzzonen	243
	7.8.2 Risikobewusste Einbindung von Anwendungen in die Netzwerkinfrastruktur	244
	7.8.3 Verschlüsselung auf Netzwerkebene	245
	7.8.4 Einbindung in Infrastruktur- und Betriebssicherheit	246
	7.8.5 Sicherheitsbewusstes Codedesign	246
	7.8.6 Verschlüsselung auf Applikationsebene	248
	7.9 Dokumentation, Test und Verifikation	248
	Abb. 7-3 Klassifizierung von Penetrationstests nach BSI	250
	8 IT-Risikomanagement	252
	Abb. 8-1 IT-Governance, IT-Risikomanagement, Compliance und IT-Sicherheit greifen eng ineinander.	252
	Abb. 8-2 IT-Risiko tritt heute querschnittsmäßig in allen Disziplinen des Risikomanagements auf (nach [RiskIT09]).	254
	8.1 Was ist Risikomanagement?	255
	Definition: Risiko	255
	Abb. 8-3 Risikowürfel [COSO04]	255
	8.2 Management von Risiken mit Total Risk Profiling	257
	Abb. 8-4 Vorgehen TRP-Methode [TRP10]	257
	Abb. 8-5 TRP-Matrix zum Management einer Menge von Risiken (nach [TRP10])	258
	8.3 Risikoregister für Anwendungen	259
	8.4 IT-Risikomanagement-Framework Risk IT	260
	Abb. 8-6 Überblick Risk IT [RiskIT09]	260
	9 Makro-Architekturmuster	262
	9.1 Blueprints und Architekturrichtlinien	263
	Abb. 9-1 Blueprint aus dem 19. Jahrhundert - technischer Plan aus dem Schiffbau (Quelle: http://en. wikipedia.org/wiki/ File:LaBelle_Blueprint.jpg)	263
	Definition: Blueprint	263
	9.1.1 Abstützen auf Standards	264
	9.1.2 Beschreibungsmittel	264
	9.1.3 Marchitecture: der Marketingaspekt	265
	Abb. 9-2 SAP NetWeaver: Darstellung der obersten Ebene als Beispiel für eine gut eingeführte »Marchitecture«	265
	9.2 Beispiel: Facharchitektur für Versicherungen	266
	9.2.1 Beispiel zur Beschreibungstiefe einer Facharchitektur	267
	Abb. 9-3 Beispiel für die Darstellung der obersten Ebene der Facharchitektur einer Versicherung. Das Bild wurde anonymisiert. Ähnliche Abbildungen in verschiedenen Versicherungen unterscheiden sich nur marginal.	267
	9.2.2 Einsatz und Nutzen einer Facharchitektur	268
	9.2.3 Abgrenzung zu Informationsarchitekturen	269
	9.2.4 Verwendung der Facharchitektur für die Bebauungsplanung	269
	Abb. 9-4 Intervallkarte zu den Mandanten des Obstia- Versicherungskonzerns mit der Abdeckung des Geschäftsobjekts (Geschäftssystems) Partner durch verschie- dene Standardprodukte und deren Versionen	270
	9.3 Beispiele für technische Architekturmuster	270
	9.3.1 Beispiel: SOA	271
	Abb. 9-5 Vier Schichten von SOA [Slama+11]	271
	SOA-Schichten	272
	SOA-Komponenten	273
	Abb. 9-6 Aufbau einer SOA-Service- Komponente [Slama+11]	273
	Abb. 9-7 Elemente einer SOA [Slama11+]	275
	9.3.2 Beispiel: Blueprint für Internetanwendungen	276
	Abb. 9-8 Blueprint für Internetan- wendungen [Generali02] (Abkürzungen siehe Fußnote)3	278
	10 Pragmatische Vorgehensweisen	280
	10.1 Angemessenes Budget für IT-Unternehmensarchitektur	280
	10.1.1 Zahlt sich IT-Unternehmensarchitektur aus?	281
	Architecture is Free!	281
	Architecture Is Free	282
	Architecture is Free	282
	Die Betreiber der ERP-Systeme verwenden selbst keine	282
	Leerkapazitäten	283
	Business Continuity Management	283
	Langfristige Einsparungen durch Portfoliomanagement	284
	Geht es nicht schneller?	284
	Professionalisierung ist zu erwarten	286
	10.1.2 Wie groß sollte eine Architekturgruppe sein?	286
	Einfluss der Fertigungstiefe	287
	Anzahl der Projektarchitekten	287
	10.2 Wie viel Ordnung muss sein?	287
	10.2.1 Wie sorgt man für die Reduktion von Komplexität?	287
	10.2.2 Wie viel Ordnung ist gut? Gibt es zu viel Ordnung?	288
	Städte, die leblos wirken	289
	Abb. 10-1 Modell von Germania, der geplanten Hauptstadt des Dritten Reiches, die zum Glück nie gebaut wurde, als Beispiel für eine »von oben nach unten« geplante Architektur mit dem klar formulierten Ziel, Macht auszudrücken.	289
	Abb. 10-2 München-Westkreuz als Beispiel für ein totes Stadtviertel, das am Reißbrett geplant wurde. Trotz Modernität und besserer Infrastruktur als in manchem gewachsenen Kiez wirkt das Viertel tot.	290
	Abb. 10-3 Ein »lebendiges« Stadtviertel - Berlin- Charlottenburg, Dankelmannstraße. Ein gewachsenes Stadtviertel, das nicht am Reißbrett geplant wurde, sondern über mehrere Jahrzehnte entstanden ist.	290
	Christopher Alexander und die rekursive Nutzung von Mustern	291
	Abb. 10-4 Kaukasischer Teppich (Quelle: wikimedia - public domain). Der Raum wird durch Zentren in Unterräume geteilt.	292
	Abb. 10-5 Muster dafür, wie Alexan- der Stadtarchitektur beschreibt. Hier wird z. B. das Konzept einer von Fußgängern zu benutze...	292
	Entwicklungsplanung	293
	Abb. 10-6 Beispiel für einen Bau- leitplan der Stadt Wien (Quelle: Internetauftritt der Stadt Wien vor 2006. Nicht mehr im Web erreichbar)	294
	10.3 Gefahren für Unternehmensarchitekten	295
	10.3.1 Exkurs: Organisationsmuster für die IT-Funktion	296
	Klassische Organisation	296
	Abb. 10-7 Klassische Organisation großer IT-Abteilungen, wie man sie heute noch finden kann. Dieses Muster für Organisationscharts befindet sich allerdings auf dem Rückzug.	297
	Moderne Organisationsform	298
	Abb. 10-8 Aufteilung der IT-Funktion in Manage/Change/Run	299
	10.3.2 Auf die Beschaffungsseite fixierter IT-Vorstand	300
	10.3.3 Organigramm alten Stils	300
	10.3.4 Hierarchiedenken	300
	10.3.5 Chicken Race	301
	10.3.6 Mangelnde Offenheit	302
	10.3.7 Verzetteln: keine klare Strategie	303
	10.3.8 Inkonsequenz	304
	10.4 Zusammenarbeit mit Lösungsarchitekten	304
	10.4.1 Warum macht der IT-Unternehmensarchitekt nicht meine Projektarchitektur?	305
	Ihre eigentlichen Aufgaben bleiben liegen	306
	Sie fördern Rückdelegation von Verantwortung	306
	Nicht abheben	306
	Abgrenzungsregeln, die sich bewährt haben	307
	10.4.2 Das Kostendilemma der Wiederverwendung	308
	10.5 Tipps und Tricks	309
	10.5.1 Architekturtickets	309
	10.5.2 Radar-Chart-Methode	310
	Abb. 10-9 Beispiel für eine qualitative Skala	311
	Abb. 10-10 Beispiel für ein Radar Chart für die Größen, die in einem Architekturmanagement als diejenigen erkannt werden, die ge...	312
	10.5.3 Chefmanagement	312
	Abb. 10-11 Matrix zur Klassifikation unangenehmer Situationen im Chefmanagement - adaptiert nach [Welch+05, S. 329]	313
	11 Frameworks für IT-Unternehmensarchitektur	316
	Definition: Framework	316
	Definition: Architecture Framework	317
	11.1 Ordnungsrahmen für EAM- und IT-Management-Frameworks	317
	Abb. 11-1 Genealogie von EAM- Frameworks [Buckl10]	318
	Abb. 11-2 Klassifizierungsraster für EAM-Frameworks nach [Rozemeijer07]	319
	Abb. 11-3 Alternatives Klassifikationsschema für IT-Management- Frameworks [Schönherr 04]	319
	Marktanteile von EAM-Frameworks	320
	Abb. 11-4 Marktanteile von EA-Frameworks - Stand 2003 [Schekkerman03]	320
	11.2 TOGAF 9	322
	11.2.1 Die Sicht von TOGAF 9 auf IT-Unternehmensarchitektur	323
	TOGAF as an EAM Framework (TOGAF 8.1 - Enterprise Edition)	323
	Abb. 11-5 Entwicklung von TOGAF von Version 7 bis Version 9	324
	11.2.2 Der Kern von TOGAF: die »Architecture Development Method« (ADM)	326
	TOGAF Teil II - Überblick über die ADM	326
	Abb. 11-6 Der zyklische ADM- Prozess (eine analoge Abbildung finden Sie in TOGAF, Abb. 5-1, http://www.opengroup. org/architecture/ togaf9-doc/arch/Figures/ adm.png)	327
	TOGAF Teil III - ADM Guidelines und Techniques	327
	Weiteres Material, das Sie neben TOGAF lesen sollten	328
	11.2.3 Abgleich von TOGAF mit Prozessclustern der IT-Unternehmensarchitektur	328
	TOGAF und IT-Strategie	328
	TOGAF und Anwendungsportfoliomanagement	329
	TOGAF und Management des Infrastrukturportfolios	329
	Abb. 11-7 Oberste Ebene des technischen TOGAF- Referenzmodells. Dazu sind tiefere Ebenen und Taxonomien abgebildet (eine analoge Abbildung ist in TOGAF 9, Abb. 43-1 zu finden).	331
	TOGAF und Architektur-Governance	331
	Abb. 11-8 Überblick über Architektur-Governance- Anteile der Prozess- landkarte für IT-Unter- nehmensarchitektur	331
	11.2.4 Abdeckung weiterer Aufgabenbereiche durch TOGAF	332
	TOGAF und Informationsmodelle für die IT-Unternehmensarchitektur	332
	Abb. 11-9 Oberste Ebene des TOGAF Content Metamodel (detailliertere Darstellungen finden Sie in TOGAF 9, Abb. 33-3, http://www.opengroup. org/architecture/ togaf9-doc/arch/Figures/ 34_contentfwk5.png)	333
	TOGAF und Toolunterstützung für IT-Unternehmensarchitektur	333
	TOGAF und Einführungspfade für IT-Unternehmensarchitektur	334
	11.2.5 Sonstige nützliche Aspekte von TOGAF	335
	Foundation Architecture/Technical Reference Model (TRM)	335
	Das Integrated Information Infrastructure Reference Model (III-RM)	336
	Abb. 11-10 Vereinfachte Sicht auf TOGAF TRM (eine analoge Abbildung ist in TOGAF, Abb. 43-2 zu finden unter http://www.opengroup. org/architecture/ togaf9-doc/arch/Figures/ 43_trm_detail.png)	336
	11.2.6 Künftige Versionen von TOGAF	336
	11.3 Zachman-Framework	337
	Tab. 11-1 Zachman-Framework (ins Deutsche übersetzt, das Original ist z. B. unter http://www.intervista- institute.com/resources/ zachman-poster.pdf erhältlich)	338
	Tab. 11-2 Abgleich Zachman- Framework mit Architektur- Modellpyramide (Abb. 2-5)	339
	12 IT-Management-Frameworks	340
	12.1 COBIT	341
	Definition: COBIT	341
	12.1.1 Grobstruktur von COBIT	342
	Tab. 12-1 Abgleich COBIT mit dem IT-Referenzorganisations- modell (siehe Abb. 10-8)	342
	Abb. 12-1 COBIT-Prozesslandkarte [COBIT11b]	343
	Tab. 12-2 Abgleich der Prozessmodelle von COBIT 4.1 und COBIT 5.0	345
	12.1.2 Nutzen von COBIT für IT-Unternehmensarchitekten	346
	12.2 ITIL	346
	Definition: ITIL	347
	Abb. 12-2 Aufbau der ITIL-Dokumen- tation. Dieses Bild der obersten Ebene von ITIL ist in fast jeder Publikation der ITIL-Version 3 enthalten, z. B. [ITIL07].	348
	13 Werkzeuge für Enterprise Architecture Management	350
	A fool with a tool is still a fool.	350
	Die Kinder des Schusters haben die zerrissensten Schuhe.	350
	Weiterführendes Material	352
	13.1 Abwägungen beim Werkzeugeinsatz	352
	Abb. 13-1 Typische Schnittstellen eines IPIT	352
	Systeme, die zentrale Stellen zum Funktionieren erfordern, skalieren nicht.	353
	Abb. 13-2 Notwendige Schnittstellen für ein IPIT, das einen weniger integrierten Funktionsumfang hat als dasjenige, das der Darstellung in Abbildung 13-1 zugrunde lag (nach [Reese10])	354
	Das Wunschbild und die derzeitige Realität	354
	13.2 Umfang eines integrierten IT-Planungswerkzeugs	355
	Abb. 13-3 Prozess- und Funktionsblöcke eines IPIT-Repräsentanten (alfabet), zugeordnet zu den IT-Governance- Regelkreisen der Meta Group (rechte Seite der Abbildung © alfabet AG 2005 - 2010)	355
	Abb. 13-4 Funktionsblöcke der aktuellen Version (Januar 2011) des IPIT planningIT von alfabet	356
	13.2.1 Zu unterstützende Prozesse der IT-Unternehmensarchitektur	357
	Abb. 13-5 Prozessmodell	357
	Unterstützung: Strategie ableiten und verfolgen	358
	Unterstützung: IT-Anwendungsportfoliomanagement	358
	Wo werden technologische Blueprints abgelegt?	359
	Unterstützung: Modellierung	360
	Unterstützung: Entwicklung und Durchsetzung von Richtlinien	360
	Unterstützung: Monitoring des Projektportfolios	360
	Unterstützung: Projektbegleitung	360
	13.2.2 Sonstige Prozesse des IT-Managements	361
	Unterstützung: Anforderungsmanagement	361
	Unterstützung: Projektportfoliomanagement	361
	Unterstützung: IT-Asset-Management (CMDB)	362
	13.2.3 Schnittstellen eines IPIT zu anderen Arten von Werkzeugen	362
	Schnittstelle zum ERP-System des Gesamtunternehmens	362
	Schnittstellen zum IT-Asset-Management und zur Configuration Management Database	363
	Schnittstelle ITIL-Unterstützungssysteme (Incident, Problem)	363
	13.2.4 Weitere funktionale Anforderungen an IPITs	364
	Unterstützung: Synchronisationsmanagement	364
	Unterstützung: Management von Softwareservices (SOA)	364
	13.2.5 Nicht funktionale Anforderungen an IPITs	365
	Anforderung: Prozessunterstützung	365
	Anforderung: Konfigurierbarkeit des Metamodells	365
	Anforderung: Abdeckung bekannter Frameworks durch das ausgelieferte Metamodell	366
	Anforderung: Reichhaltigkeit unterstützter Visualisierungsarten, Flexibilität der Visualisierung	366
	Anforderung: Flexibilität der Reporting-Funktionen	366
	Anforderung: Unterstützung für die Zusammenarbeit mehrerer Benutzer (Usability)	366
	Anforderung: Unterstützung für Import und Export von Daten	367
	13.3 Möglicher Umfang von Planungswerkzeugen	367
	13.3.1 Werkzeuge mit maximalem Umfang: das umfassende Informationssystem für die IT-Funktion?	367
	13.3.2 Werkzeuge mit realistischem Funktionsumfang: IPIT	367
	13.3.3 Werkzeuge mit mittlerem Funktionsumfang: Aufsätze auf bestehenden Lösungen	368
	Ergänzungen zu BPM-Werkzeugen	368
	Ergänzungen zu UML-Werkzeugen	368
	13.3.4 Werkzeuge mit geringem Funktionsumfang: Ad-hoc-Werkzeuge nur für Bebauungsplanung	369
	13.4 Richtungen, aus denen Werkzeuge entstanden sind	370
	Werkzeuge für Balanced Scorecards	370
	Metaeditor-Werkzeuge	370
	BPM-Werkzeuge	371
	Hersteller von Systemverwaltungssoftware	371
	Hybride Wikis	371
	13.5 Marktsituation	371
	14 Einführungspfade für IT-Unternehmensarchitektur	374
	14.1 Einführungspfade für IT-Unternehmensarchitektur mit und ohne Topmanagement-Unterstützung	375
	Abb. 14-1 In Anlehnung an bekannte und eher leicht witzig gemeinte »Problem-Charts« zeigt diese Abbildung, worauf es bei der Maßnahmenplanung für IT-Unternehmensarchitektur ankommt.	376
	Weg 1: Von oben nach unten	379
	Abb. 14-2 Einführungsstrategie »von unten nach oben«	379
	Weg 2: Von unten nach oben	380
	Abb. 14-3 Einführungsstrategie »von oben nach unten«	380
	14.2 Wege in Konzernen mit dezentralen IT-Einheiten	381
	Abb. 14-4 Unternehmensgruppe mit mehreren Geschäftseinheiten und jeweils dezentralen IT-Funktionen. Über die Stärke der Zentralfunk- tionen ist hier noch keine Aussage getroffen.	381
	Weg 1: Von oben nach unten	382
	Abb. 14-5 Einführung von oben nach unten über die Zentrale	382
	Weg 2 - Pilotanwendungen	382
	Abb. 14-6 Einführung über ein Pilotprojekt	382
	Abb. 14-7 Erfolgsaussichten verschiedener Einführungswege von IT-Unter- nehmensarchitektur - gilt auch für unterstützende Werkzeuge.	383
	15 Ausblick	386
	IT-Unternehmensarchitektur hat sich ausgebreitet und wird zur reifen Disziplin	386
	Bezüglich Business-IT-Alignment gibt es nach wie vor Verbesserungspotenzial	386
	Abb. 15-1 Steigender Nutzen verschiedener Heran- gehensweisen an das Thema IT-Unternehmens- architektur	387
	IT-Unternehmensarchitektur und Business-Architektur werden weiter zusammenwachsen	387
	IT-Unternehmensarchitektur rechnet sich schon bei geringerem Anspruch	388
	Modellierung ist nicht die Hauptsache	388
	Compliance, IT-Sicherheit, IT-Risikomanagement und IT-Governance werden weiter als Themen »wachsen«	388
	Ausreichendes Rüstzeug ist vorhanden	389
	Zu »Architektur« gibt es keine wirklichen Alternativen mehr	390
	Architecture is free!	390
	Für sehr große Systeme ist architekturgetriebene, kontrollierte Weiterentwicklung (Managed Evolution) der einzig sinnvolle Weg, um die Kontrolle über die IT zu behalten und als Unternehmen handlungsfähig zu bleiben.	390
	Anhang	392
	A Checkliste für Richtlinien, Vorstudien und Architekturdokumente	394
	A.1 Wer kann diese Checkliste verwenden und warum?	394
	A.2 Zu Beginn	395
	A.2.1 Reviewen ist eine Dienstleistung für den Autor	395
	A.2.2 Schreiben ist eine Dienstleistung für den Leser	396
	A.3 Kontrollfragen	396
	A.3.1 Kontrollfragen zur Geschichte, die das Dokument wiedergibt	396
	A.3.2 Formalia	399
	B Textauszüge	400
	B.1 Auszug SOX Sections 302 und 404	400
	SEC. 302. CORPORATE RESPONSIBILITY FOR FINANCIAL REPORTS.	400
	SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS.	401
	B.2 Auszug aus COBIT-4.1-Kontrollzielen	402
	B.2.1 PO1 Define a Strategic IT Plan	402
	B.2.2 PO2 Define the Information Architecture	403
	B.3 Auszug AO (Abgabenordnung)	404
	AO 1977 § 147 Ordnungsvorschriften für die Aufbewahrung von Unterlagen	404
	C Abkürzungsverzeichnis	406
	D Glossar	410
	E Literatur	416
	[Alexander79a]	416
	[Alexander79b]	416
	[Alexander02a]	416
	[Alexander02b]	416
	[Andersen09]	416
	[Balzert98]	416
	[Beck93]	416
	[Behringer10]	416
	[Bernhard+03]	416
	[Bieberstein+05]	416
	[Bieberstein+08]	416
	[BIZ04]	416
	[Broadbent03]	417
	[Broadbent+05]	417
	[Buchta+04]	417
	[Buckl+07]	417
	[Buckl10]	417
	[Cameron+09]	417
	[Carr04]	417
	[Clausewitz98]	417
	[COBIT07]	417
	[COBIT11a]	417
	[COBIT11b]	417
	[Coplien96]	417
	[COSO04]	417
	[Cunningham+01]	417
	[Denert+92]	418
	[Dern03]	418
	[Dern+08]	418
	[Dietrich+06]	418
	[Doblaski03]	418
	[Engels+08]	418
	[Ernst09]	418
	[eTOM10]	418
	[Fink00]	418
	[Gamma+95]	418
	[Gartner03a]	418
	[Gartner03b]	418
	[Gartner03c]	418
	[Gaulke10]	418
	[Generali02]	418
	[Hake+02]	419
	[Hammer+93]	419
	[Hanschke10]	419
	[HeatMap06]	419
	[Hirzel+09]	419
	[Holley+06]	419
	[IBM11]	419
	[IEEE00]	419
	[Infosys09]	419
	[ITGI11]	419
	[ITIL07]	419
	[Johannsen+10]	419
	[Johnson+88]	419
	[Kagermann+06]	419
	[Kaplan+97]	419
	[Kappes+09]	419
	[Keller+08]	420
	[Kerth03]	420
	[Keuntje+10]	420
	[Keuper+10]	420
	[Krafzig+04]	420
	[Kumar06]	420
	[Lahti+05]	420
	[Lankes+05a]	420
	[Lankes+05b]	420
	[Lutchen05]	420
	[Malik95]	420
	[Malinverno06a]	420
	[Malinverno06b]	420
	[Masak05]	420
	[Masak06]	420
	[Matthes+04]	420
	[Matthes11]	421
	[Merrifield+06]	421
	[Meszaros+98]	421
	[Meta02]	421
	[Mitra05]	421
	[Murer+11]	421
	[OMG04]	421
	[Osterwalder10]	421
	[Philip96]	421
	[Porter89]	421
	[Quibeldey-Cirkel99]	421
	[Reese10]	421
	[Reynolds10]	421
	[Rising00]	421
	[RiskIT09]	421
	[Ritzenhöfer08]	421
	[Robinson+95]	422
	[Roebuck11]	422
	[Rozemeijer07]	422
	[Rüping03]	422
	[Schekkerman03]	422
	[Schekkerman04]	422
	[Schönherr04]	422
	[sebis08]	422
	[Slama+11]	422
	[Solvency06]	422
	[Sowa+92]	422
	[SOX02]	422
	[Sterling10]	422
	[Sweeney10]	422
	[TOGAF8.1]	422
	[TOGAF8.1.1]	423
	[TOGAF9]	423
	[Treacy+97]	423
	[TRP10]	423
	[Ward+97]	423
	[Ward+02]	423
	[Weill04]	423
	[Weill+04]	423
	[Welch+05]	423
	[Windley06]	423
	[Winter+06]	423
	[Wittenburg07]	423
	[Zachman87]	423
	[Zachman97]	423
	Stichwortverzeichnis	424

IT-Unternehmensarchitektur - Von der Geschäftsstrategie zur optimalen IT-Unterstützung

von: Wolfgang Keller

IT-Unternehmensarchitektur - Von der Geschäftsstrategie zur optimalen IT-Unterstützung

Kategorien

eBooks