Hinweise zu den Phasen B,C und D: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (32 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
| 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 === | ||
| − | |||
| − | + | [[File:BerabeitungshinweiseBCD.png|thumb|right|300px|TOGAF ADM-Phasen mit 9 identischen Schritten]] | |
| − | Für die | + | 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 ADM-Phasen B - Geschäftsarchitektur, C - Informationssystemarchitektur und D - Technologiearchitektur besteht eine Besonderheit darin, dass sie aus insgesamt '''9 identischen Schritten''' aufgebaut sind. Diese Schritte werden wie folgt bezeichnet: |
| − | |||
| − | |||
| − | |||
| − | |||
| − | #Auswahl von | + | #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 |
| − | #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" |
=== Ziel des TOGAF-Schrittmodells === | === Ziel des TOGAF-Schrittmodells === | ||
| − | [[ | + | |
| + | [[File:TOGAFSchrittmodellBbisD 00-00-01.png|thumb|right|350px|TOGAF-Schrittmodell der ADM-Phasen von B bis D]] | ||
Mit dem TOGAF-Schrittmodell werden zwei Ziele verfolgt: | 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 | + | *Das Ziel der Schritte 1 bis 5 ist der '''Entwurf der architekturdomänen-spezifischen Architektur''' und die Dokumentation des Entwurfs |
**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. | **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 | + | **Über eine Gap-Analyse werden anschließend die Unterschiede zwischen der bestehenden und der gewünschten Architektur-Situation herausgearbeitet, deren Ergebnis 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''' | + | *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 finalisiert, bevor sie in das phasenübergreifende Architekturdokument Eingang finden. | ||
Diesen hier beschriebenen Ablauf zeigt nebenstehendes Bild. | 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 [[IVS-Architekturprinzipien#Ebenen_von_IVS-Architektur|Ebenen von IVS-Architektur ]]) kann das TOGAF-Schrittmodell nicht in identischer Weise auf die Ebenen von IVS-Architektur übertragen werden. Vielmehr müssen die Schritte für jede Ebene unterschiedlich interpretiert werden, wobei sie unterschiedlich an Bedeutung gewinnen. Diese Unterschiede werden im Folgenden dargelegt: | ||
| + | |||
| + | === Interpretation 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-Rahmenarchitektur 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" | ||
| − | + | === Interpretation 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" | ||
| − | + | === Interpretation 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 erforderlich) | ||
| + | *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" | ||
| − | + | ---- | |
| − | + | [[Hauptseite|<< Zurück zur Hauptseite]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Aktuelle Version vom 15. November 2017, 12:31 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 ADM-Phasen B - Geschäftsarchitektur, C - Informationssystemarchitektur und D - Technologiearchitektur besteht eine Besonderheit darin, dass sie aus insgesamt 9 identischen 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 Entwurfs
- 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 Ergebnis 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 finalisiert, 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-Architektur übertragen werden. Vielmehr müssen die Schritte für jede Ebene unterschiedlich interpretiert werden, wobei sie unterschiedlich an Bedeutung gewinnen. Diese Unterschiede werden im Folgenden dargelegt:
Interpretation 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-Rahmenarchitektur 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"
Interpretation 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"
Interpretation 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 erforderlich)
- 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"
