TOGAF-Phase B: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 9: Zeile 9:
  
 
{| class="wikitable"
 
{| class="wikitable"
! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Umsetzung IVS-Rahmenarchitektur
+
! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Anleitung !! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
 +
 
 
|-
 
|-
 
| 1 || Auswahl von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_01 Referenzmodellen, Perspektiven und Werkzeugen]  
 
| 1 || Auswahl von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_01 Referenzmodellen, Perspektiven und Werkzeugen]  

Version vom 19. Mai 2016, 14:50 Uhr

Phase B – Geschäftsarchitektur

TOGAF
In Phase B erfolgt die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten Architekturvision.
IVS-Rahmenarchitektur
In der Phase B wird die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten IVS-Architekturprojekte geschaffen.
Schritt TOGAF Tailoring IVS-Rahmenarchitektur Anleitung Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
1 Auswahl von Referenzmodellen, Perspektiven und Werkzeugen
2 Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur
3 Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur
4 Durchführung einer Gap-Analyse


5 Definition von Roadmap-Komponenten
6 Klärung der Auswirkungen auf die gesamte Architekturlandschaft
7 Durchführung eines formalen Stakeholder-Reviews
8 Finalisierung der Geschäftsarchitektur


9 Erstellung der Dokumentation für die Architekturdefinition






Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.