TOGAF-Phase E: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(15 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Phase E – Möglichkeiten und Lösungen == | == Phase E – Möglichkeiten und Lösungen == | ||
Zeile 21: | Zeile 4: | ||
:Phase E ist die erste Phase, die sich direkt mir der Implementierung befasst. Sie beschreibt den Prozess der Identifizierung von Instrumenten (Projekte, Programme oder Portfolios), zur Implementierung der Zielarchitektur, die in den vorherigen Phasen entworfen wurde. | :Phase E ist die erste Phase, die sich direkt mir der Implementierung befasst. Sie beschreibt den Prozess der Identifizierung von Instrumenten (Projekte, Programme oder Portfolios), zur Implementierung der Zielarchitektur, die in den vorherigen Phasen entworfen wurde. | ||
− | :Im Prinzip geht es in der Phase E darum, | + | :Im Prinzip geht es in der Phase E darum, wie die identifizierten Lücken in den Architekturen geschlossen werden können. In den Phasen B-D wird eine Gap-Analyse (Soll-Ist-Vgl.) durchgeführt. Wenn nun im Rahmen der Gap-Analyse z.B. festgetsellt wird, dass ein Geschäftsprozess zukünftig von einem IT-System unterstützt werden soll, dann geht es in der Phase E nun darum, wie man dieses IT-System bekommt und welches es sein soll - welche Systeme am Markt verfügbar sind, welche geeignet sind oder ob selbst etwas entwickelt werden muss. D.h. verschiedene Möglichkeiten und Lösungen zur Schließung der Lücke werden erwogen und anhand von Kriterien bewertet. Schließlich wird eine davon ausgewählt. |
+ | :Bei der Lücke in der Datenarchitektur (z.B. uns fehlen Baustellendaten), kann man als Lösungen in Betracht ziehen, die Baustellendaten vom MDM zu beziehen oder von den Städten einzeln. Nach dem Kriterium der Wirtschaftlichkeit könnte der MDM als bessere Lösung ausgewählt werden. | ||
+ | :Im Sinne des Capability-Ansatzes muss die Lücke aber nicht unbedingt eine fehlende IT-Lösung sein. Es kann auch sein, dass z.B. eine ganze Organisationseinheit fehlt oder ein neuer Geschäftsprozess entwickelt werden muss. | ||
;IVS-Rahmenarchitektur | ;IVS-Rahmenarchitektur | ||
Zeile 35: | Zeile 20: | ||
|- | |- | ||
| 1 | | 1 | ||
− | | style="text-align: left; vertical-align: top" | Bestimmung/Sicherstellung der wichtigsten [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_01 Attribute für Veränderungen im Unternehmen] | + | | style="text-align: left; vertical-align: top" | Bestimmung/Sicherstellung der wichtigsten [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_01 Attribute für Veränderungen im Unternehmen] |
− | | style="text-align: left; vertical-align: top" | Festlegung der besten Strategie und der wichtigsten Faktoren für die Implementierung der IVS-Architektur | + | | style="text-align: left; vertical-align: top" | Festlegung der besten Strategie und der wichtigsten Faktoren für die Implementierung der IVS-Architektur |
− | | style="text-align: left; vertical-align: top" | [[Festlegung_einer_Strategie_für_die_Implementierung_einer_IVS-Architektur|'''Festlegung einer Strategie für die Implementierung einer IVS-Architektur''']] | + | | style="text-align: left; vertical-align: top" | [[Festlegung_einer_Strategie_für_die_Implementierung_einer_IVS-Architektur|'''Festlegung einer Strategie für die Implementierung einer IVS-Architektur''']] |
*[[Implementation_Factor_Assessment_and_Deduction_Matrix|Template: IVS-Architektur Implementierungsmatrix]] | *[[Implementation_Factor_Assessment_and_Deduction_Matrix|Template: IVS-Architektur Implementierungsmatrix]] | ||
− | | style="text-align: left; vertical-align: top" | | + | | style="text-align: left; vertical-align: top" | |
|- | |- | ||
| 2 | | 2 | ||
Zeile 55: | Zeile 40: | ||
| 4 | | 4 | ||
| Review der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_04 Anforderungen in gegenüber den zugehörigen Business-Funktionen] | | Review der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_04 Anforderungen in gegenüber den zugehörigen Business-Funktionen] | ||
− | | | + | | Überprüfung der Anforderungen gegenüber den zugehörigen Business-Funktionen |
− | Überprüfung der | + | | [[Überprüfung_der_Anforderungen|Überprüfung der Anforderungen gegenüber den zugehörigen Business-Funktionen]] |
− | |||
− | |||
| | | | ||
|- | |- | ||
| 5 | | 5 | ||
| Konsolidierung und Abstimmung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_05 Anforderungen an die Interoperabilität] | | Konsolidierung und Abstimmung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_05 Anforderungen an die Interoperabilität] | ||
− | | | + | | Konsolidierung und Abgleich von Interoperabilitätsanforderungen |
− | | | + | | [[Konsolidierung_und_Abgleich_von_Interoperabilitätsanforderungen|Konsolidierung und Abgleich von Interoperabilitätsanforderungen]] |
| | | | ||
|- | |- | ||
| 6 | | 6 | ||
| Detailliertere [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_06 Bestimmung und Überprüfung von Abhängigkeiten] | | Detailliertere [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_06 Bestimmung und Überprüfung von Abhängigkeiten] | ||
− | | | + | | Definieren und Bestätigen von Abhängigkeiten |
− | | | + | | [[Definieren_und_Bestätigen_von_Abhängigkeiten|Definieren und Bestätigen von Abhängigkeiten]] |
| | | | ||
|- | |- | ||
| 7 | | 7 | ||
| Untersuchung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_07 Reife und des Risikos für Veränderungen aus geschäftlicher Sicht] | | Untersuchung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_07 Reife und des Risikos für Veränderungen aus geschäftlicher Sicht] | ||
− | | | + | | Bestätigung der Bereitschaft und des Risikos für die Geschäftsumwandlung |
− | | | + | | [[Bestätigung_der_Bereitschaft_und_des_Risikos_für_die_Geschäftsumwandlung|Bestätigung der Bereitschaft und des Risikos für die Geschäftsumwandlung]] |
| | | | ||
|- | |- | ||
| 8 | | 8 | ||
| Formulierung einer groben [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_08 Implementierungs- und Migrationsstrategie] | | Formulierung einer groben [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_08 Implementierungs- und Migrationsstrategie] | ||
− | | | + | | Formulierung der Implementierungs- und Migrationsstrategie |
− | | | + | | [[Formulierung_der_Implementierungs-_und_Migrationsstrategie|Formulierung der Implementierungs- und Migrationsstrategie]] |
| | | | ||
|- | |- | ||
| 9 | | 9 | ||
| Identifizierung und Gruppierung wichtigster [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_09 Arbeitspakete] | | Identifizierung und Gruppierung wichtigster [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_09 Arbeitspakete] | ||
− | | | + | | Identifizierung und Gruppierung wichtigster Arbeitspakete |
− | | | + | | [[Identifizierung_und_Gruppierung_wichtigster_Arbeitspakete|Identifizierung und Gruppierung wichtigster Arbeitspakete]] |
| | | | ||
|- | |- | ||
| 10 | | 10 | ||
| Identifizierung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_10 Transitionsarchitekturen] | | Identifizierung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_10 Transitionsarchitekturen] | ||
− | | | + | | Identifizierung von Transitionsarchitekturen |
− | | | + | | [[Identifizierung_von_Transitionsarchitekturen|Identifizierung von Transitionsarchitekturen]] |
| | | | ||
|- | |- | ||
| 11 | | 11 | ||
| Erstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_11 Portfolio- und Projektvereinbarungen und Aktualisierung der Architekturen] | | Erstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html#tag_13_04_11 Portfolio- und Projektvereinbarungen und Aktualisierung der Architekturen] | ||
− | | & | + | | Erstellung von Architektur Roadmap & Implementierung und Migration Plan |
− | | & | + | | [[Erstellung_von_Architektur_Roadmap_&_Implementierung_und_Migration_Plan|Erstellung von Architektur Roadmap & Implementierung und Migration Plan]] |
| | | | ||
|} | |} |
Aktuelle Version vom 6. September 2017, 09:31 Uhr
Phase E – Möglichkeiten und Lösungen
- TOGAF
- Phase E ist die erste Phase, die sich direkt mir der Implementierung befasst. Sie beschreibt den Prozess der Identifizierung von Instrumenten (Projekte, Programme oder Portfolios), zur Implementierung der Zielarchitektur, die in den vorherigen Phasen entworfen wurde.
- Im Prinzip geht es in der Phase E darum, wie die identifizierten Lücken in den Architekturen geschlossen werden können. In den Phasen B-D wird eine Gap-Analyse (Soll-Ist-Vgl.) durchgeführt. Wenn nun im Rahmen der Gap-Analyse z.B. festgetsellt wird, dass ein Geschäftsprozess zukünftig von einem IT-System unterstützt werden soll, dann geht es in der Phase E nun darum, wie man dieses IT-System bekommt und welches es sein soll - welche Systeme am Markt verfügbar sind, welche geeignet sind oder ob selbst etwas entwickelt werden muss. D.h. verschiedene Möglichkeiten und Lösungen zur Schließung der Lücke werden erwogen und anhand von Kriterien bewertet. Schließlich wird eine davon ausgewählt.
- Bei der Lücke in der Datenarchitektur (z.B. uns fehlen Baustellendaten), kann man als Lösungen in Betracht ziehen, die Baustellendaten vom MDM zu beziehen oder von den Städten einzeln. Nach dem Kriterium der Wirtschaftlichkeit könnte der MDM als bessere Lösung ausgewählt werden.
- Im Sinne des Capability-Ansatzes muss die Lücke aber nicht unbedingt eine fehlende IT-Lösung sein. Es kann auch sein, dass z.B. eine ganze Organisationseinheit fehlt oder ein neuer Geschäftsprozess entwickelt werden muss.
- IVS-Rahmenarchitektur
- Die Phase E beschreibt den Prozess der Identifizierung von Instrumenten, zur Implementierung der IVS-Architekturprojekte.
Es können alternative Lösungsansätze und Architekturbausteine diskutiert und bewertet werden, um im Anschluss möglichst wenige, dafür aber konkrete Empfehlungen zu geben.