Hinweise zu den Phasen B,C und D: Unterschied zwischen den Versionen
Zeile 1: | Zeile 1: | ||
== Schrittmodell für die Architekturentwicklung in den TOGAF Phasen [[TOGAF-Phase_B|B]], [[TOGAF-Phase_C|C]] und [[TOGAF-Phase_D|D]] == | == Schrittmodell für die Architekturentwicklung in den TOGAF Phasen [[TOGAF-Phase_B|B]], [[TOGAF-Phase_C|C]] und [[TOGAF-Phase_D|D]] == | ||
+ | |||
=== Aufbau des TOGAF-Schrittmodells === | === Aufbau des TOGAF-Schrittmodells === | ||
− | |||
− | Die TOGAF - Architecture Develeopment Method, kurz ADM, sieht die Entwicklung einer Architektur in mehreren Phasen vor, wobei jede Phase aus bis zu 9 Schritten aufgebaut ist. | + | [[File:BerabeitungshinweiseBCD.png|thumb|right|200px|TOGAF ADM-Phasen mit 9 identischen Schritten]] |
+ | |||
+ | Die TOGAF - Architecture Develeopment Method, kurz ADM, sieht die Entwicklung einer Architektur in mehreren Phasen vor, wobei jede Phase aus bis zu 9 Schritten aufgebaut ist. | ||
+ | |||
+ | Für die, die eigentlichen TOGAF-Architekturdomänen betreffenden ADM-Phasen | ||
− | |||
*B - Geschäftsarchitektur, | *B - Geschäftsarchitektur, | ||
*C - Informationssystemarchitektur und | *C - Informationssystemarchitektur und | ||
*D - Technolgiearchitektur | *D - Technolgiearchitektur | ||
+ | |||
(siehe auch nebenstehendes Bild) besteht ein Besonderheit darin, dass sie aus insegsamt '''9 identisch Schritten''' aufgebaut sind. Diese Schritte werden wie folgt bezeichnet: | (siehe auch nebenstehendes Bild) besteht ein Besonderheit darin, dass sie aus insegsamt '''9 identisch Schritten''' aufgebaut sind. Diese Schritte werden wie folgt bezeichnet: | ||
− | #Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur | + | #Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur |
− | #Beschreibung der Ausgangssituation der Architektur | + | #Beschreibung der Ausgangssituation der Architektur |
− | #Beschreibung der Ziel-Architektur | + | #Beschreibung der Ziel-Architektur |
− | #Durchführung einer Gap-Analyse | + | #Durchführung einer Gap-Analyse |
− | #Festlegung von Kandidaten für die Architektur Roadmap | + | #Festlegung von Kandidaten für die Architektur Roadmap |
− | #Klärung der Auswirkungen auf die gesamte Architekturlandschaft | + | #Klärung der Auswirkungen auf die gesamte Architekturlandschaft |
− | #Durchführung eines formalen Stakeholder-Reviews | + | #Durchführung eines formalen Stakeholder-Reviews |
− | #Finalisierung der Architektur | + | #Finalisierung der Architektur |
#Dokumentation der Ergebnisse im Dokument "Architekturdefinition" | #Dokumentation der Ergebnisse im Dokument "Architekturdefinition" | ||
Version vom 14. November 2017, 13:29 Uhr
Inhaltsverzeichnis
Schrittmodell für die Architekturentwicklung in den TOGAF Phasen B, C und D
Aufbau des TOGAF-Schrittmodells
Die TOGAF - Architecture Develeopment Method, kurz ADM, sieht die Entwicklung einer Architektur in mehreren Phasen vor, wobei jede Phase aus bis zu 9 Schritten aufgebaut ist.
Für die, die eigentlichen TOGAF-Architekturdomänen betreffenden ADM-Phasen
- B - Geschäftsarchitektur,
- C - Informationssystemarchitektur und
- D - Technolgiearchitektur
(siehe auch nebenstehendes Bild) besteht ein Besonderheit darin, dass sie aus insegsamt 9 identisch Schritten aufgebaut sind. Diese Schritte werden wie folgt bezeichnet:
- Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur
- Beschreibung der Ausgangssituation der Architektur
- Beschreibung der Ziel-Architektur
- Durchführung einer Gap-Analyse
- Festlegung von Kandidaten für die Architektur Roadmap
- Klärung der Auswirkungen auf die gesamte Architekturlandschaft
- Durchführung eines formalen Stakeholder-Reviews
- Finalisierung der Architektur
- Dokumentation der Ergebnisse im Dokument "Architekturdefinition"
Ziel des TOGAF-Schrittmodells
Mit dem TOGAF-Schrittmodell werden zwei Ziele verfolgt:
- Das Ziel der Schritte 1 bis 5 ist der Entwurf der architekturdomänen-spezifischen Architektur und die Dokumentation des Enwurfs
- Dazu werden zunächst - auf der Grundlage der mit Schritt 1 jeweils festzulegenden Sichten auf die Architektur der jeweiligen Phase - die Ausgangssituation (Schritt 2 - Ist-Architektur) und anschließend die gewünschte Situation (Schritt 3 - Ziel-Architektur) beschrieben.
- Über eine Gap-Analyse werden anschließend die Unterschiede zwischen der bestehenden und der gewünschten Architektur-Situation herausgearbeitet, deren Ergebniss in einer Roadmap (Schritt 5) dokumentiert, mit Prioritäten versehen und zeitlich geplant wird.
- Das Ziel der Schritte 6 bis 9 ist die konsensuale Finalisierung des Architekturentwurfs
- dazu werden zunächst die Auswirkungen auf die gesamte Architekturlandschaft geklärt
- im Anschluss werden die Bestandteile der Roadmap einem Peer-Review durch externe Experten (Stakeholder) unterzogen
- abschließend werden die Bestandteile der Architektur überarbeitet und finalsiert, bevor sie in das phasenübergreifende Architekturdokument Eingang finden.
Diesen hier beschriebenen Ablauf zeigt nebenstehendes Bild.
Übertragung des TOGAF-Schrittmodells auf die Ebenen von IVS-Architektur
Vorbemerkung
Aufgrund der unterschiedlichen Natur der drei Ebenen von IVS-Architektur (siehe auch Ebenen von IVS-Architektur kann das TOGAF-Schrittmodell nicht in identischer Weise auf die Ebenen von IVS-Archtektur übertragen werden. Vielmehr müssen die Schritte für jede Ebene unterschiedlich interpretiert werden und gewinnen unterschiedlich an Bedeutung. Diese Unterschide werden im Folgenden dargelegt:
Interpretion für die IVS-Rahmenarchitektur
für die IVS-Rahmenarchitektur geht es darum, Architekturbausteine, aus denen IVS-Dienste im Kern aufgebaut sind, mit den zugehörigen Deliverables zu entwerfen und diese mit Semantik zu versehen. Vor diesem Hintergrund stehen für die IVS-Rahmenarchtektur die folgenden Schritte im Vordergrund:
- 1.Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur
- 3.Beschreibung der Ziel-Architektur
- 7.Durchführung eines formalen Stakeholder-Reviews
- 8.Finalisierung der Architektur
- 9.Dokumentation der Ergebnisse im Dokument "Architekturdefinition"
Interpretion für IVS-Referenzarchitekturen
Für die IVS-Referenzarchitekturen geht es darum, die von der IVS-Rahmenarchitektur vorgegebenen Architekturbausteine für den Gestaltungsraum einer spezifischen mit einem Bezeichner benannten IVS-Dienstekategorie zu verwenden und soweit zu konkretisieren, dass sie aus fachlicher Sicht den gemeinsamen Bedingungen der IVS-Dienstekategorie entsprechen. Vor diesem Hintergrund stehen für IVS-Referenzarchitekturen die folgenden Schritte im Vordergrund:
- 1.Auswahl von Referenzen, Sichten und Werkzeugen für die Architektur
- 2.Beschreibung der Ausgangssituation der Architektur (nur soweit vorhanden)
- 3.Beschreibung der Ziel-Architektur
- 4.Durchführung einer Gap-Analyse (soweit Ausgangsituation beschrieben)
- 5.Festlegung von Kandidaten für die Architektur Roadmap
- 6.Klärung der Auswirkung auf die gesamte Architekturlandschaft
- 7.Durchführung eines formalen Stakeholder-Reviews
- 8.Finalisierung der Architektur
- 9.Dokumentation der Ergebnisse im Dokument "Architekturdefinition"
=
Interpretion für IVS-Architektur eines realen IVS-Dienstes
Für die IVS-Architektur eines realen IVS-Dienstes geht es um die tatsächliche Umsetzung relevanter IVS-Referenzarchitekturen bis zur letzten Detaillierungsebene in einem konkreten Anwendungsfall. Vor diesem Hintergrund sind für die IVS-Architektur eines realen IVS-Dienstes alle Schritte des TOGAF-Schrittmodells von Relevanz:
- 1.Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur
- 2.Beschreibung der Ausgangssituation der Architektur (nur soweit erfoderlich)
- 3.Beschreibung der Ziel-Architektur
- 4.Durchführung einer Gap-Analyse
- 5.Festlegung von Kandidaten für die Architektur Roadmap
- 6.Klärung der Auswirkung auf die gesamte Architekturlandschaft
- 7.Durchführung eines formalen Stakeholder-Reviews
- 8.Finalisierung der Architektur
- 9.Dokumentation der Ergebnisse im Dokument "Architekturdefinition"