Hinweise zu den Phasen B,C und D: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
| Zeile 6: | Zeile 6: | ||
[[File:BerabeitungshinweiseBCD.png|thumb|right|300px|TOGAF ADM-Phasen mit 9 identischen Schritten]] | [[File:BerabeitungshinweiseBCD.png|thumb|right|300px|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 ADM-Phasen B - Geschäftsarchitektur, C - Informationssystemarchitektur und D - Technologiearchitektur besteht eine Besonderheit darin, dass sie aus | + | 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 | #Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur | ||
| Zeile 16: | Zeile 16: | ||
#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 === | ||
| Zeile 24: | Zeile 24: | ||
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. | **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. | **Im Anschluss werden die Bestandteile der Roadmap einem Peer-Review durch externe Experten (Stakeholder) unterzogen. | ||
| − | **Abschließend werden die Bestandteile der Architektur überarbeitet und | + | **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 == | == Übertragung des TOGAF-Schrittmodells auf die Ebenen von IVS-Architektur == | ||
| Zeile 40: | Zeile 39: | ||
=== Vorbemerkung === | === 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- | + | 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 | *1.Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur | ||
| Zeile 52: | Zeile 51: | ||
*9.Dokumentation der Ergebnisse im Dokument "Architekturdefinition" | *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: | 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: | ||
| Zeile 66: | Zeile 65: | ||
*9.Dokumentation der Ergebnisse im Dokument "Architekturdefinition" | *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: | 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 | *1.Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur | ||
| − | *2.Beschreibung der Ausgangssituation der Architektur (nur soweit | + | *2.Beschreibung der Ausgangssituation der Architektur (nur soweit erforderlich) |
*3.Beschreibung der Ziel-Architektur | *3.Beschreibung der Ziel-Architektur | ||
*4.Durchführung einer Gap-Analyse | *4.Durchführung einer Gap-Analyse | ||
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"
