|
|
| Zeile 11: |
Zeile 11: |
| | ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Umsetzung IVS-Rahmenarchitektur | | ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Umsetzung IVS-Rahmenarchitektur |
| | |- | | |- |
| − | | 1 || ''' Auswahl von 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] |
| − | Auswahl der entsprechenden Referenzmodelle, Perspektiven und Werkzeuge, auf der Grundlage der Business-Treiber und der Anliegen der Stakeholder.
| + | |
| − | Die Auswahl der relevanten Perspektiven zeigt, wie die Anliegen Stakeholder in der Geschäftsarchitektur adressiert werden.
| |
| − | Zusätzlich erfolgt die Identifizierung von geeigneten Werkzeugen und Techniken für die Erfassung der Geschäftsarchitektur, ihrer Modellierung und ihrer Analyse, in Verbindung mit den ausgewählten Perspektiven.
| |
| − | Je nach Grad der gewollten Komplexität, kann die Modellierung in Form einfacher Dokumente oder Tabellen erfolgen, oder komplexere Modellierungstools und Techniken angewandt werden, wie Geschäftsprozessmodelle oder Use-Case-Modelle usw.
| |
| | || || | | || || |
| | |- | | |- |
| − | | 2 || '''Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur''' | + | | 2 || Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_02 Ausgangssituation der Geschäftsarchitektur] |
| − | Es sollte eine Beschreibung der bestehenden Geschäftsarchitektur auf der Basis der benötigten Anforderungen zur Unterstützung und Beschreibung der Ziel-Geschäftsarchitektur angefertigt werden. Der Umfang und die Detailebene der Beschreibung der bestehenden Geschäftsarchitektur hängt ab, von der Anzahl der zu übertragenden Elemente in die Ziel-Geschäftsarchitektur. Relevante Bausteine sollten vorher definiert werden.
| + | |
| | || || | | || || |
| | |- | | |- |
| − | | 3 || '''Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur''' | + | | 3 || Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_03 Ziel-Geschäftsarchitektur] |
| − | Die Beschreibung für die Ziel-Geschäftsarchitektur sollte in dem Umfang erfolgen, die zur Umsetzung der Architektur Vision benötig wird. Umfang und Wichtigkeit ergeben sich also auf Basis der Architektur Vision und vorhandener Architekturbeschreibung
| + | |
| − | ;Zusatz:
| + | || || |
| − | : Die Ziel-Geschäftsarchitektur gibt einen verbindlichen Orientierungs- und Gestaltungsrahmen für die Umsetzung vor. Dies sind in der Regel grobe, strategische Aussagen. Diese Aussagen werden durch Prinzipien und Richtlinien weiter ergänzt. Die bestehende Geschäftsarchitektur sowie der strategische und operative Handlungsbedarf sind neben den strategischen Vorga-ben (bspw. Architektur- und Geschäftsprinzipien) wesentlicher Input für die Festlegung der Ziel-Geschäftsarchitektur. | |
| − | || | |
| | |- | | |- |
| − | | 4 || ''' Durchführung einer Gap-Analyse ''' | + | | 4 || Durchführung einer [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_04 Gap-Analyse] |
| − | Überprüfung der Architekturmodelle nach Konsistenz und Genauigkeit:
| + | |
| − | *Trade-Off-Analyse der verschiedenen Architekturmodelle durchführen um Konflikte zu vermeiden
| |
| − | *Sicherstellen, dass die Architekturmodelle, die Prinzipien unterstützen, Zielen und Restriktionen entsprechen
| |
| − | *Abweichungen dokumentieren
| |
| − | *Architekturmodelle auf Vollständigkeit gegeben der Anforderungen prüfen
| |
| | | | |
| − | ;Zusatz:
| + | || || |
| − | : Die GAP-Analyse wird verwendet, um Lücken zu identifizieren die zwischen Ist-Architektur und Soll-Architektur existieren. Die Lücken stellen das Delta zwischen Ist- und Soll-Zustand dar und helfen die für die Überbrückung notwendigen Maßnahmen abzuleiten.
| |
| − | || || | |
| | |- | | |- |
| − | | 5 || ''' Definition von Roadmap-Komponenten ''' | + | | 5 || Definition von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_05 Roadmap-Komponenten] |
| − | Nach der Beschreibung der bestehenden Geschäftsarchitektur, der Ziel-Geschäftsarchitektur und der Durchführung der Gap-Analyse, ist die Erstellung einer Roadmap erforderlichen, um Handlungsschritte und Aktivitäten in den kommenden Phasen zu priorisieren.
| |
| − | Diese Erstversion der Geschäftsarchitektur-Roadmap wird als Grundstein zur detailliertere Definition einer konsolidierten, disziplinübergreifenden Roadmap innerhalb der Opportunities & Solution Phase (Phase E) verwendet.
| |
| − | || ||
| |
| | | | |
| | + | || || |
| | |- | | |- |
| − | | 6 || '''Klärung der Auswirkungen auf die gesamte Architekturlandschaft''' | + | | 6 ||Klärung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_06 Auswirkungen auf die gesamte Architekturlandschaft] |
| − | Sobald die Erstellung der Geschäftsarchitektur durchgeführt ist, ist es notwendig, alle weiteren Folgen oder Auswirkungen zu verstehen.
| |
| | | | |
| − | In dieser Phase sollten andere Architektur Artefakte in der Architektur Landschaft untersucht werden, um Folgendes zu klären:
| |
| − | *Hat diese Geschäftsarchitektur Auswirkungen auf bereits existierende Architekturen?
| |
| − | *Haben die jüngsten Änderungen Auswirkungen auf die Geschäftsarchitektur?
| |
| − | *Gibt es Möglichkeiten, Arbeiten die während der Erstellung der Geschäftsarchitektur durchgeführt worden sind, in anderen Bereichen der Organisation zu nutzen?
| |
| − | *Hat diese Geschäftsarchitektur Auswirkungen auf andere Projekte (einschließlich der geplanten sowie diejenigen, die derzeit im Gange sind)?
| |
| − | *Wird die Geschäftsarchitektur von anderen Projekten beeinflusst werden (die geplanten sowie diejenigen, die derzeit im Gange sind)?
| |
| | || || | | || || |
| | | | |
| | |- | | |- |
| − | | 7 || ''' Durchführung eines formalen Stakeholder-Reviews ''' | + | | 7 || Durchführung eines formalen [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_07 Stakeholder-Reviews] |
| − | Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture, asking if it is fit for the purpose of support-ing subsequent work in the other architecture domains. Refine the proposed Business Archi-tecture only if necessary. || ||
| + | || || |
| | |- | | |- |
| − | | 8 || ''' Finalisierung der Geschäftsarchitektur ''' | + | | 8 || Finalisierung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_08 Geschäftsarchitektur] |
| − | *Festlegung der Standards für jeden der Bausteine, wobei so viele wie möglich von den Referenzmodellen stammen sollten
| + | |
| − | *Jeden Baustein vollständig dokumentieren
| + | |
| − | *Ausführung eines letzten Gegenchecks Geschäftsarchitektur mit den Zielen
| |
| − | *Dokumentation durchführen für Rückverfolgbarkeit
| |
| − | *Dokumentation der endgültigen Zuordnung der Architektur in dem Architektur-Repository; von den ausgewählten Bausteinen, über diejenigen, die wiederverwendet werden können (Aktivitäten, Rollen, Geschäftsbeziehungen, Stellenbeschreibungen, etc.),
| |
| − | *Alles im Architektur-Repository veröffentlichen
| |
| − | *Finalisierung aller Arbeitsprodukte, wie bspw. Ergebnisse der Gap-Analyse
| |
| | || || | | || || |
| | |- | | |- |
| − | | 9 || '''Erstellung der Dokumentation für die Architekturdefinition''' | + | | 9 || Erstellung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_09 Dokumentation für die Architekturdefinition] |
| − | *Document rationale for building block decisions in the Architecture Definition Document
| |
| − | *Prepare the business sections of the Architecture Definition Document, comprising some or all of:
| |
| − | **A business footprint (a high-level description of the people and locations involved with key business functions)
| |
| − | **A detailed description of business functions and their information needs
| |
| − | **A management footprint (showing span of control and accountability)
| |
| − | **Standards, rules, and guidelines showing working practices, legislation, financial measures, etc.
| |
| − | **A skills matrix and set of job descriptions
| |
| | | | |
| − | If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and in-corporate feedback.
| |
| | || || | | || || |
| | |} | | |} |
