TOGAF-Phase C: Unterschied zwischen den Versionen
Zeile 15: | Zeile 15: | ||
! 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 Referenzmodellen, Perspektiven und Werkzeugen ''' |
+ | Überprüfung und Validierung (oder ggf. Generierung) der Menge an Daten-Prinzipien (data principles). Diese bilden in der Regel einen Teil eines umfassenden Satzes von Architekturprinzipien. | ||
+ | Wahl der entsprechenden Datenarchitektur-Ressourcen (Referenzmodelle, Muster, etc.) auf Basis der Business-Treiber, Stakeholders, deren Anliegen und der Geschäftsarchitektur. | ||
+ | |||
+ | Wahl der entsprechenden Datenarchitektur-Perspektiven (z.B. Stakeholder der Daten – Aufsichtsbehörden (Kontrollorgane), Benutzer, Erzeuger, andere Personen, Wirtschaftsprüfer, etc.; verschiedene Zeitdimensionen – in Echtzeit, ereignisgesteuert, in einem festgelegten Berichtszeitraum etc.; Standorte; (Geschäfts-)Prozesse); das heißt, diejenigen, die es den Architekten ermöglichen zu zeigen, wie die Stakeholder-Anliegen in der Datenarchitektur adressiert werden. | ||
+ | |||
+ | Identifizierung geeigneter Werkzeuge und Techniken (einschließlich Formate), die für die Datenerfassung verwendet werden, Modellierung und Analyse, in Verbindung mit den ausgewählten Perspektiven. Je nach Grad der gewollten Komplexität können diese eine Form von einfachen Dokumenten oder Tabellen haben, oder in Form von komplexeren Modellierungstools und Techniken wie Datenmanagement-Modellen, Datenmodellen, etc. | ||
+ | Beispiele für Datenmodellierungs-Techniken sind: | ||
+ | * Entity-Relationship-Diagramme oder | ||
+ | * Klassendiagramme | ||
+ | |||
+ | '''1.1 Feslegung des allgemeinen Modellierungsprozesses ''' | ||
+ | For each viewpoint, select the models needed to support the specific view required, using the selected tool or method. Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models. | ||
+ | The recommended process for developing a Data Architecture is as follows: | ||
+ | * Collect data-related models from existing Business Architecture and Application Architecture materials | ||
+ | *Rationalize data requirements and align with any existing enterprise data catalogs and mo-dels; this allows the development of a data inventory and entity relationship | ||
+ | * Update and develop matrices across the architecture by relating data to business service, bu-siness function, access rights, and application | ||
+ | *Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived|| || | ||
|- | |- | ||
| 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur || || | | 2 || Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur || || |
Version vom 4. März 2016, 13:46 Uhr
Phase C – Informationssystem-Architektur
- TOGAF
- In Phase C erfolgt die Dokumentation der grundlegenden Struktur von unternehmenseigenen IT-Systemen, die die wichtigsten Informationsobjekte und Anwendungssysteme enthalten und diese verarbeiten. Diese Phase besteht aus zwei Schritten, die entweder nacheinander oder gleichzeitig entwickelt werden können:
- Datenarchitektur
- Anwendungsarchitektur.
- IVS-Rahmenarchitektur
- In der Phase C wird die Dokumentation der IVS-Architekturprojekte finalisiert und erstellt.
Datenarchitektur
Schritt | TOGAF | Tailoring IVS-Rahmenarchitektur | Umsetzung IVS-Rahmenarchitektur |
---|---|---|---|
1 | Auswahl von Referenzmodellen, Perspektiven und Werkzeugen
Überprüfung und Validierung (oder ggf. Generierung) der Menge an Daten-Prinzipien (data principles). Diese bilden in der Regel einen Teil eines umfassenden Satzes von Architekturprinzipien. Wahl der entsprechenden Datenarchitektur-Ressourcen (Referenzmodelle, Muster, etc.) auf Basis der Business-Treiber, Stakeholders, deren Anliegen und der Geschäftsarchitektur. Wahl der entsprechenden Datenarchitektur-Perspektiven (z.B. Stakeholder der Daten – Aufsichtsbehörden (Kontrollorgane), Benutzer, Erzeuger, andere Personen, Wirtschaftsprüfer, etc.; verschiedene Zeitdimensionen – in Echtzeit, ereignisgesteuert, in einem festgelegten Berichtszeitraum etc.; Standorte; (Geschäfts-)Prozesse); das heißt, diejenigen, die es den Architekten ermöglichen zu zeigen, wie die Stakeholder-Anliegen in der Datenarchitektur adressiert werden. Identifizierung geeigneter Werkzeuge und Techniken (einschließlich Formate), die für die Datenerfassung verwendet werden, Modellierung und Analyse, in Verbindung mit den ausgewählten Perspektiven. Je nach Grad der gewollten Komplexität können diese eine Form von einfachen Dokumenten oder Tabellen haben, oder in Form von komplexeren Modellierungstools und Techniken wie Datenmanagement-Modellen, Datenmodellen, etc. Beispiele für Datenmodellierungs-Techniken sind:
1.1 Feslegung des allgemeinen Modellierungsprozesses For each viewpoint, select the models needed to support the specific view required, using the selected tool or method. Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models. The recommended process for developing a Data Architecture is as follows:
| ||
2 | Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur | ||
3 | Entwicklung einer Beschreibung der Ziel-Datenarchitektur | ||
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 Datenarchitektur | ||
9 | Erstellung der Dokumentation für die Architekturdefinition |
Anwendungsarchitektur
Schritt | TOGAF | Tailoring IVS-Rahmenarchitektur | Umsetzung IVS-Rahmenarchitektur |
---|---|---|---|
1 | Auswahl von Referenzmodellen, Perspektiven und Werkzeugen | ||
2 | Entwicklung einer Beschreibung der Ausgangssituation für die Anwendungsarchitektur | ||
3 | Entwicklung einer Beschreibung der Ziel-Anwendungsarchitektur | ||
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 Anwendungsarchitektur | ||
9 | Erstellung der Dokumentation für die Architekturdefinition |
Es werden die notwendigen Daten und Anwendungen spezifiziert.
- Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
- Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.