Hinweise zu den Phasen B,C und D: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(43 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== Architekturentwicklung in den TOGAF Phasen [[TOGAF-Phase_B|B]], [[TOGAF-Phase_C|C]] und [[TOGAF-Phase_D|D]] ==
 
  
[[Datei: BerabeitungshinweiseBCD.png | thumb | 200px | right | TOGAF ADM-Phasen mit 9 identischen Schritten ]]  
+
== Schrittmodell für die Architekturentwicklung in den TOGAF Phasen [[TOGAF-Phase_B|B]], [[TOGAF-Phase_C|C]] und [[TOGAF-Phase_D|D]] ==
  
Die TOGAF - Architecture Develeopment Method, kurz ADM, sieht die Entwicklung einer Architektur in mehreren Phasen vor, wobei jede Phase aus bis zu 9 Schritten besteht.
+
=== Aufbau des TOGAF-Schrittmodells ===
  
=== Aufbau des Schrittmodells ===
+
[[File:BerabeitungshinweiseBCD.png|thumb|right|300px|TOGAF ADM-Phasen mit 9 identischen Schritten]]
  
Für die die eigentlichen TOGAF-Architekturdomänen betreffenden ADM-Phasen (siehe nebenstehndes Bild): 
+
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:
B - Geschäftsarchitektur,  
 
C - Inforamtionssystemarchitektur und  
 
D - Technolgiearchitektur
 
besteht ein Besonderheit darin, dass sie aus '''9 identisch Schritten''' aufgebaut sind. Diese Schritte heissen:
 
  
#Auswahl von Referenzen, Sichten und Werkzeugen für die Architektur
+
#Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur  
#Beschreibung der Ausgangssituation der Architektur
+
#Beschreibung der Ausgangssituation der Architektur  
#Entwicklung einer 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"  
  
=== Ziel des Schrittmodells ===
+
=== Ziel des TOGAF-Schrittmodells ===
  
Ziel des Schrittmodells der TOGAF-Phasen B, C und D ist es, ist es zunächst auf der Basis der mit Schritt 1 jeweils festzulegenden Sichten auf Architektur über die Beschreibung einerseits der Ausgangssituation (Schritt 2 - Ist-Architektur) und anderseits der gewünschten Situation (Schritt 3 - Ziel-Architektur) hin zu einer Gap-Analyse zu kommen und so die Unterschiede zwischen der bestehenden und der gewünschten Archtektur-Situation herauszuarbeiten.
+
[[File:TOGAFSchrittmodellBbisD 00-00-01.png|thumb|right|350px|TOGAF-Schrittmodell der ADM-Phasen von B bis D]]
  
Die Ergebniss der Gap-Analyse werden dann in einer Roadmap (Schritt 5) verankert, mit Prioritäten versehen und zeitlich geplant. Auf Basis der Kommentierung durch externme Exerten (Peer-Review) werden die Ergebnisse der Archtekturarbeit überarbeitet und fianlsiert, bevor sie in das phasenübergreifende Architekturdokument Eingang finden.
+
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.
 
Diesen hier beschriebenen Ablauf zeigt nebenstehendes Bild.
  
== Referenzarchitekturen in den TOGAF Phasen B, C und D ==
+
== Ü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:
  
Diese Vorgehensweise ist für die Entwicklung der Architektur eines realen IVS-Dienstes sicherlich sinnvoll. Bei der Entwicklung einer Referenzarchitektur ist dies jedoch nicht immer der Fall. Eine Referenzarchitektur abstrahiert die Architekturen realer IVS-Dienste einer bestimmten [[IVS-Dömänen|IVS-Domäne]]. Es ist daher oft gar nicht möglich, eine Ist-Architektur anzugeben, da die Ist-Architekturen der realen IVS-Dienste weit auseinander klaffen. Stattdessen können dann Lücken bzw. fehlende Architekturbausteine identifiziert und beschrieben werden. In anderen Fällen ist es möglich, bestehende Architekturbausteine, die eine sinnvolle Weiterentwicklung der Architektur erschweren, zu benennen. Die Beschreibung der Ist-Architektur sollte, wenn möglich, die bestehenden Architekturbausteine beschreiben. Insbesondere sollen dabei die Bausteine aufgelistet werden, die einer sinnvollen Weiterentwicklung der Architektur im Wege stehen. Wenn dies nicht
+
*1.Auswahl von Referenzen, Sichten und Werkzeugen für die Architektur  
möglich ist, sollten zumindest Lücken identifiziert werden. Dabei werden Architekturbausteine aufgelistet, die für eine Weiterentwicklung der Architektur fehlen.
+
*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"
  
Die Zielarchitektur muss jedoch auf jeden Fall beschrieben werden. Bei der Gap-Analyse werden die neuen, die zu verändernden und die zu entfernenden Architekturbausteine identifiziert und bei der Definition der Roadmap-Komponenten in einen Zeitplan eingeordnet.
+
=== Interpretation für IVS-Architektur eines realen IVS-Dienstes ===
  
Es wird folgende Vorgehensweise für die Entwicklung einer Referenzarchitektur vorgeschlagen:
+
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:
#Auswahl von Referenzmodellen, Perspektiven und Werkzeugen
 
#Beschreibung der vorhandenen Architekturbausteine, falls nicht möglich, Beschreibung der fehlenden Architekturbausteine
 
#Entwicklung einer Beschreibung der Ziel-Architektur
 
#Durchführung einer Gap-Analyse
 
#Definition von Roadmap-Komponenten
 
#Klärung der Auswirkungen auf die gesamte Architekturlandschaft
 
#Durchführung eines formalen Stakeholder-Reviews
 
#Finalisierung der Architektur
 
#Erstellung der Dokumentation für die Architekturdefinition
 
  
== Architekturen realer IVS-Dienste in den TOGAF Phasen B, C und D ==
+
*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"
  
Bei der Entwicklung von Architekturen realer IVS-Dienste sollen die Schritte 2-5 sowie 9 auf jeden Fall durchgeführt werden. Ob und wie die anderen Schritte bei der Entwicklung einer Architektur eines realen IVS-Dienste durchgeführt werden, wird jeweils projektspezifisch festgelegt. Damit ergibt sich die folgende Vorgehensweise bei der Entwicklung und Beschreibung einer Architektur eines realen IVS-Dienstes:
+
----
  
#Auswahl von Referenzmodellen, Perspektiven und Werkzeugen (projektspezifisch)
+
[[Hauptseite|<< Zurück zur Hauptseite]]
#Entwicklung einer Beschreibung der Ausgangssituation der Architektur
 
#Entwicklung einer Beschreibung der Ziel-Architektur
 
#Durchführung einer Gap-Analyse
 
#Definition von Roadmap-Komponenten
 
#Klärung der Auswirkungen auf die gesamte Architekturlandschaft (projektspezifisch)
 
#Durchführung eines formalen Stakeholder-Reviews (projektspezifisch)
 
#Finalisierung der Architektur (projektspezifisch)
 
#Erstellung der Dokumentation für die Architekturdefinition
 

Aktuelle Version vom 15. November 2017, 12:31 Uhr

Schrittmodell für die Architekturentwicklung in den TOGAF Phasen B, C und D

Aufbau des TOGAF-Schrittmodells

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 insgesamt 9 identischen Schritten aufgebaut sind. Diese Schritte werden wie folgt bezeichnet:

  1. Auswahl von Hilfsmitteln, Sichten und Werkzeugen für die Darstellung der Architektur
  2. Beschreibung der Ausgangssituation der Architektur
  3. Beschreibung der Ziel-Architektur
  4. Durchführung einer Gap-Analyse
  5. Festlegung von Kandidaten für die Architektur Roadmap
  6. Klärung der Auswirkungen auf die gesamte Architekturlandschaft
  7. Durchführung eines formalen Stakeholder-Reviews
  8. Finalisierung der Architektur
  9. Dokumentation der Ergebnisse im Dokument "Architekturdefinition"

Ziel des TOGAF-Schrittmodells

TOGAF-Schrittmodell der ADM-Phasen von B bis D

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"

<< Zurück zur Hauptseite