TOGAF-Phase C

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: Entity-Relationship-Diagramme oder Klassendiagramme 1.1: Festlegung 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 1.2: Benötigte Kataloge für Daten Bulding Blocks identifizieren The organization's data inventory is captured as a catalog within the Architecture Repository. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., logical data component -> physical data component ->] data entity). Catalogs form the raw material for development of matrices and diagrams and also act as a key re-source for portfolio managing business and IT capability. During the Business Architecture phase, a Business Service/Information diagram was created showing the key data entities required by the main business services. This is a prerequisite to successful Data Architecture activities. Using the traceability from application to business function to data entity inherent in the content framework, it is possible to create an inventory of the data needed to be in place to support the Architecture Vision. Once the data requirements are consolidated in a single location, it is possible to refine the data inventory to achieve semantic consistency and to remove gaps and overlaps. The following catalogs should be considered for development within a Data Architecture: Data Entity/Data Component catalog 1.3: Matritzen definieren Matrices show the core relationships between related model entities. Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment. At this stage, an entity to applications matrix could be produced to validate this mapping. How data is created, maintained, transformed, and passed to other applications, or used by other applications, will now start to be understood. Obvious gaps such as entities that never seem to be created by an application or data created but never used, need to be noted for later gap analysis. The rationalized data inventory can be used to update and refine the architectural diagrams of how data relates to other aspects of the architecture. Once these updates have been made, it may be appropriate to drop into a short iteration of Application Architecture to resolve the changes identified. The following matrices should be considered for development within a Data Architecture: Data Entity/Business Function (showing which data supports which functions and which business function owns which data) Business Service/Information (developed during the Business Architecture phase) Application/Data (developed across the Application Architecture and Data Architecture phases) 1.4: Benötigte Diagramme definieren Diagrams present the Data Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders. Once the data entities have been refined, a diagram of the relationships between entities and their attributes can be produced. It is important to note at this stage that information may be a mixture of enterprise-level data (from system service providers and package vendor information) and local-level data held in personal data-bases and spreadsheets. The level of detail modeled needs to be carefully assessed. Some physical system data models will exist down to a very detailed level; others will only have core entities modeled. Not all data models will have been kept up-to-date as applications were modified and extended over time. It is important to achieve a balance in the level of detail provided (e.g., reproducing existing detailed system physical data schemas or presenting high-level process maps and data requirements, highlight the two extre-me views). The following diagrams should be considered for development within a Data Architecture: Conceptual Data diagram Logical Data diagram Data Dissemination diagram Data Lifecycle diagram Data Security diagram Data Migration diagram 1.5: Arten von Anforderungen identifizieren Once the Data Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the data-focused requirements for implementing the Target Architecture. These requirements may: Relate to the data domain Provide requirements input into the Application, and Technology Architectures Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements	Auswahl von IVS-Referenzmodellen und Werkzeugen | IVS-Referenzmodelle und Werkzeuge |
2	Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur Entwicklung einer Ausgangsbeschreibung der bestehenden Datenarchitektur im erforderlichen Umfang, um auf Basis dieser, die Ziel-Datenarchitektur zu erstellen. Der Umfang und die Detailebene sind abhängig vom Umfang der vorhandenen Datenelemente, die in die Ziel-Datenarchitektur übertragen werden und abhängig von bereits existierenden architektonischen Beschreibungen. So weit wie möglich sollten die relevanten Bausteine der Datenarchitektur identifiziert werden (s.g. Buildingblocks), durch Inanspruchnahme des Architektur-Repositories. Falls neue Architekturmodelle entwickelt werden müssen, um Stakeholder-Anliegen gerecht zu werden, sollten die in Schritt 1 definierten Modelle als Leitfaden für die Erstellung neuer Architektur-Inhalte herangezogen werden.
3	Entwicklung einer Beschreibung der Ziel-Datenarchitektur Entwicklung einer Zielbeschreibung für die Datenarchitektur in dem erforderlichen Umfang, um die Architektur Vision (Output Phase A) und die Ziel-Geschäftsarchitektur (Output Phase B) zu unterstützen. Der Umfang und die Detailebene werden auf Basis der Relevanz der Datenelemente zur Erreichung der Zielarchitektur bestimmt und ob, oder ob keine architektonischen Beschreibungen existieren. So weit wie möglich sollten die relevanten Bausteine der Datenarchitektur identifiziert werden (s.g. Buildingblocks), durch Inanspruchnahme des Architektur-Repositories. Falls neue Architekturmodelle entwickelt werden müssen, um Stakeholder-Anliegen gerecht zu werden, sollten die in Schritt 1 definierten Modelle als Leitfaden für die Erstellung neuer Architektur-Inhalte herangezogen werden.
4	Durchführung einer Gap-Analyse Überprüfung der Architekturmodelle auf Konsistenz und Genauigkeit: Durchführung von trade-off Analysen zur Lösung von Konflikten (falls vorhanden). Überprüfung, ob die Modelle die Prinzipien, Ziele und Anliegen unterstützen. Änderungen, in den ausgewählten Modellen aus dem Architektur-Repository, zu den jeweiligen Perspektiven notieren und dokumentieren. Architekturmodelle auf Vollständigkeit gegeben den Anforderungen überprüfen. Identifizierung von Lücken zwischen der Ausgangssituation der Datenarchitektur und der Ziel-Datenarchitektur. Zusatz: Durchführung der Gap-Analyse - Schritte Schritt 1: Zeichnen Sie eine Matrix mit allen Architektur-Bausteinen der Ausgangsarchitektur auf der vertikalen Achse, und allen Architekturbausteinen der Zielarchitektur auf der horizonta-len Achse. Schritt 2: Addieren Sie in der Ausgangsarchitektur-Achse eine Zeile "Neu", und bei der Zielarchitektur-Achse eine Spalte mit der Bezeichnung "Ausgeschieden". Schritt 3: Ist ein Architekturbausein sowohl in der Ausgangs- als auch in der Zielarchitektur verfügbar, notieren Sie bei der Kreuzung von Spalte und Zeile "inbegriffen". Schritt 4: Wenn ein Baustein der Ausgangsarchitektur in der Zielarchitektur fehlt, muss jeder überprüft werden. Wenn der Baustein gerechtfertig beseitigt wurde, markieren Sie diesen in der entsprechenden "Ausgeschieden" Zelle. Wenn es nicht gerechtfertigt ist, handelt es sich um eine zufällige Aufdeckung eines Fehlers, dieser muss in der nächsten Iteration des Architektur-Design behoben werden. Der Baustein muss also als solcher gekennzeichnet werden in der entsprechenden "Ausgeschieden" Zelle. Schritt 5: Wenn ein Architekturbaustein der Zielarchitektur nicht in der Ausgangsarchitektur zu finden ist, dann muss dies an der Kreuzung in der "Neuen" Zeile als Lücke markiert wer-den, die gefüllt werden muss, entweder durch die Entwicklung oder Beschaffung eines solchen Bausteins. Schritt 6: Ist die Analyse beendet, zeigt alles unter "Ausgeschieden" oder "Neu" eine Lücke auf, die entweder als richtig eliminiert erklärt werden kann oder markiert werden muss zur Wiederherstellung oder Entwicklung / Beschaffung.
5	Definition von Roadmap-Komponenten Nach Erstellung der Ausgangssituation der Datenarchitektur, Ziel-Datenarchitektur und Gap-Analyse ist eine Daten-Roadmap erforderlich, die die auszuführenden Aktivitäten in den kommenden Phasen priorisiert. Diese erste Datenarchitektur-Roadmap wird als Grundlage für eine detailliertere Definition einer konsolidierten, disziplinübergreifenden Roadmap innerhalb der Opportunities & Solutions Phase (Phase E) verwendet.
6	Klärung der Auswirkungen auf die gesamte Architekturlandschaft Sobald die Datenarchitecktur festgelegt ist, ist es notwendig, alle weiteren Folgen und Auswir-kungen zu verstehen. An diesem Punkt sollten andere Architektur Artefakte in der Architektur Landschaft untersucht werden, um zu identifizieren: Hat die Datenarchitektur Auswirkungen auf bereits existierende Architekturen? Wurden jüngst Änderungen ausgeführt, die Auswirkungen auf die Datenarchitektur haben? Gibt es Möglichkeiten, Arbeiten die innerhalb der Datenarchitektur verrichtet wurden in anderen Bereichen der Organisation zu nutzen? Hat die Datenarchitektur Auswirkungen auf andere Projekte (einschließlich der Ge-planten sowie diejenigen, die derzeit im Gange sind)? Wird die Datenarchitektur von anderen Projekten beeinflusst (einschließlich der Ge-planten sowie diejenigen, die derzeit im Gange sind)?
7	Durchführung eines formalen Stakeholder-Reviews Überprüfen, ob die ursprüngliche Motivation für das Architektur-Projekt und das Statement der Architektur-Arbeit der vorgeschlagenen Datenarchitektur entsprechen. Durchführung einer Analyse, um Auswirkungen auf alle Bereiche zu identifizieren, in denen die Geschäfts-und Anwendungsarchitektur möglicherweise geändert werden muss, um Änderungen der Datenarchitektur (z.B. Verfahren, Anwendungen oder Datenbanksysteme) gerecht zu werden. Bei signifikantem Einfluss, rechtfertigt das die nochmalige Betrachtung der Geschäfts- und Anwendungsarchitektur. Identifizierung von allen Bereichen, in denen die Anwendungsarchitektur geändert werden muss, um für Änderungen in der Datenarchitektur zu sorgen (oder Einschränkungen für die Anwendungsarchitektur definieren). Wenn die Auswirkungen signifikant sind ist es sinnvoll eine Iteration der Anwendungsarchitektur durchzuführen. Festlegung aller Einschränkungen für die Technologie-Architektur. Falls nötig, die vorgeschlagene Datenarchitektur verfeinern.
8	Finalisierung der Datenarchitektur 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 Alles im Architektur-Repository veröffentlichen Finalisierung aller Arbeitsprodukte, bspw. Gap-Analyse
9	Erstellung der Dokumentation für die Architekturdefinition Begründung für Entscheidungen über Bausteine in einem Architektur-Definition-Dokument festhalten. Vorbereitung von Datenarchitektur-Abschnitten in dem Architektur-Definition-Dokument, be-stehend aus einigen oder allen der folgenden Punkte: Geschäftsdatenmodell Logisches Datenmodell Datenmanagement -Prozessmodell Daten Entity / Geschäfts-Funktion-Matrix Dateninteroperabilitätsanforderungen (z.B. XML-Schema, Sicherheitsrichtlinien) Gegebenenfalls Verwendung von Berichten und / oder Grafiken erzeugt von Modellierungs-Tools; Dokument zur Überprüfung an relevante Stakeholders leiten und ggf. Feedbak integrieren.

Anwendungsarchitektur

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Umsetzung IVS-Rahmenarchitektur
1	Auswahl von Referenzmodellen, Perspektiven und Werkzeugen Überprüfung und Validierung (oder ggf. Generierung) einer Menge an Anwendungsprinzipien (application principles). Diese bilden in der Regel einen Teil eines umfassenden Satzes von Architekturprinzipien. Wahl der entsprechenden Anwendungsarchitektur-Ressourcen (Referenzmodelle, Muster, etc.) auf Basis der Business-Treiber, Stakeholders, deren Anliegen und der Geschäftsarchitektur. Wahl der relevanten Anwendungsarchitektur-Perspektiven (z.B. Stakeholder der Applikationen – relevante Perspektiven aus der Sicht der funktionalen Nutzer und aus Sicht der individuellen Nutzer der Applikationen, etc.); das heißt, diejenigen, die es den Architekten ermöglichen zu zeigen, wie die Stakeholder-Anliegen in der Anwendungsarchitektur adressiert werden. Identifizierung geeigneter Werkzeuge und Techniken, die für die Erfassung, Modellierung und Analyse der Anwendungen, in Verbindung mit den ausgewählten Perspektiven, verwendet werden können. 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. Erwägen Sie die Verwendung von plattformunabhängige Beschreibungen von der Geschäfts-Logik. Zum Beispiel bietet die OMG's Model Driven Architecture (MDA) einen Ansatz zur Modellierung von Anwendungsarchitekturen, die die Geschäfts-Logik von Änderungen durch die zugrundeliegende Plattform und Implementierungstechnologie bewahrt. 1.1: Festlegung 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 (see above). The recommended process for developing an Application Architecture is as follows: Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the business architecture scope Simplify complicated applications by decomposing them into two or more applications Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one Identify logical applications and the most appropriate physical applications Develop matrices across the architecture by relating applications to business service, business function, data, process, etc. Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the enterprise architecture effort to determine the level of decomposition. The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages. 1.2: Benötigte Kataloge für Daten Building Blocks identifizieren The organization's Application Portfolio is captured as a catalog within the Architecture Repository. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., logical application component -> physical application component ->] information system service). Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability. The following catalogs should be considered for development within an Application Architecture: Application Portfolio catalog Interface catalog 1.3: Matrizen definieren Matrices show the core relationships between related model entities. Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment. Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business. The initial mapping should focus on business services within the Business Architecture, as this is the level of granularity where architecturally significant decisions are most likely to be needed. Once applications are mapped to business services, it will also be possible to make associations from applications to data, through the business-information diagrams developed during Business Architecture. If readily available, baseline application data models may be used to validate the Business Architecture and also to identify which data is held locally and which is accessed remotely. The Data Architecture phase will focus on these issues, so at this point it may be appropriate to drop into a short iteration of Data Architecture if it is deemed to be valuable to scope of the architecture engagement. Using existing information in the baseline application catalog, the Application Architecture should identify user and organizational dependencies on applications. This activity will support future state planning by determining impacted user communities and also facilitating the grouping of application by user type or user location. A key user community to be specifically considered is the operational support organization. This activity should examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed. Specifically considering the needs of the operational community may identify requirements for new or extended governance capabilities and applications. The following matrices should be considered for development within an Application Architecture: Application/Organization matrix Role/Application matrix Application Interaction matrix Application/Function matrix 1.4: Benötigte Diagramme definieren Diagrams present the Application Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders. Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements. In the case of packaged applications, it is likely to be the case that the application supports a number of configuration options, add-on modules, or application services that may be applied to the solution. For custom developed applications, it is necessary to identify the high-level structure of the application in terms of modules or sub-systems as a foundation to organize design activity. The following diagrams should be considered for development within an Application Architecture: Application Communication diagram Application and User Location diagram Enterprise Manageability diagram Process/Application Realization diagram Application Migration diagram Software Distribution diagram Software Engineering diagram Application Use-Case diagram 1.5: Arten von Anforderungen identifizieren Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the application-focused requirements for implementing the Target Architecture. These requirements may: Relate to the application domain Provide requirements input into the Data and Technology Architectures Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements
2	Entwicklung einer Beschreibung der Ausgangssituation für die Anwendungsarchitektur Entwicklung einer Ausgangsbeschreibung der bestehenden Anwendungsarchitektur im erforderlichen Umfang, um auf Basis dieser, die Ziel-Anwendungsarchitektur zu erstellen. Der Umfang und die Detailebene sind abhängig vom Umfang der vorhandenen Anwendungen, die in die Ziel-Anwendungsarchitektur übertragen werden und ist zusätzlich abhängig von bereits existierenden architektonischen Beschreibungen. So weit wie möglich sollten die relevanten Bausteine der Anwendungsarchitektur identifiziert werden (s.g. Building Blocks), durch Inanspruchnahme des Architektur-Repositories. Falls Anwendungen (Building Blocks) noch nicht im Architektur-Repository vorhanden sind, muss jede Anwendung im Einklang mit dem Anwendungs-Portfolio-Katalog definiert werden. Falls neue Architekturmodelle entwickelt werden müssen, um Stakeholder-Anliegen gerecht zu werden, sollten die in Schritt 1 definierten Modelle als Leitfaden für die Erstellung neuer Architektur-Inhalte herangezogen werden.
3	Entwicklung einer Beschreibung der Ziel-Anwendungsarchitektur Entwicklung einer Zielbeschreibung für die Anwendungsarchitektur in dem erforderlichen Umfang, um die Architektur Vision (Output Phase A), die Ziel-Geschäftsarchitektur (Output Phase B) und die Ziel-Datenarchitektur (Output Teil 1 Phase C) zu unterstützen. Der Umfang und die Detailebene werden auf Basis der Relevanz der Applikationen zur Erreichung der Zielarchitektur bestimmt und ob, oder ob keine architektonischen Beschreibungen existieren. So weit wie möglich sollten die relevanten Bausteine der Anwendungsarchitektur identifiziert werden (s.g. Building Blocks), durch Inanspruchnahme des Architektur-Repositories. Falls neue Architekturmodelle entwickelt werden müssen, um Stakeholder-Anliegen gerecht zu werden, sollten die in Schritt 1 definierten Modelle als Leitfaden für die Erstellung neuer Architektur-Inhalte herangezogen werden.
4	Durchführung einer Gap-Analyse Überprüfung der Architekturmodelle auf Konsistenz und Genauigkeit: - Durchführung von trade-off Analysen zur Lösung von Konflikten (falls vorhanden). - Überprüfung, ob die Modelle die Prinzipien, Ziele und Anliegen unterstützen. - Änderungen, in den ausgewählten Modellen aus dem Architektur-Repository, zu den jeweiligen Perspektiven notieren und dokumentieren. - Architekturmodelle auf Vollständigkeit gegeben den Anforderungen überprüfen. Identifizierung von Lücken zwischen der Ausganssituation der Anwendungsarchitektur und der Ziel-Anwendungsarchitektur. Zusatz: Durchführung der Gap-Analyse - Schritte Schritt 1: Zeichnen Sie eine Matrix mit allen Architektur-Bausteinen der Ausgangsarchitektur auf der vertikalen Achse, und allen Architekturbausteinen der Zielarchitektur auf der horizonta-len Achse. Schritt 2: Addieren Sie in der Ausgangsarchitektur-Achse eine Zeile "Neu", und bei der Zielarchitektur-Achse eine Spalte mit der Bezeichnung "Ausgeschieden". Schritt 3: Ist ein Architekturbausein sowohl in der Ausgangs- als auch in der Zielarchitektur verfügbar, notieren Sie bei der Kreuzung von Spalte und Zeile "inbegriffen". Schritt 4: Wenn ein Baustein der Ausgangsarchitektur in der Zielarchitektur fehlt, muss jeder überprüft werden. Wenn der Baustein gerechtfertig beseitigt wurde, markieren Sie diesen in der entsprechenden "Ausgeschieden" Zelle. Wenn es nicht gerechtfertigt ist, handelt es sich um eine zufällige Aufdeckung eines Fehlers, dieser muss in der nächsten Iteration des Architektur-Design behoben werden. Der Baustein muss also als solcher gekennzeichnet werden in der entsprechenden "Ausgeschieden" Zelle. Schritt 5: Wenn ein Architekturbaustein der Zielarchitektur nicht in der Ausgangsarchitektur zu finden ist, dann muss dies an der Kreuzung in der "Neuen" Zeile als Lücke markiert wer-den, die gefüllt werden muss, entweder durch die Entwicklung oder Beschaffung eines solchen Bausteins. Schritt 6: Ist die Analyse beendet, zeigt alles unter "Ausgeschieden" oder "Neu" eine Lücke auf, die entweder als richtig eliminiert erklärt werden kann oder markiert werden muss zur Wiederherstellung oder Entwicklung / Beschaffung.
5	Definition von Roadmap-Komponenten Nach Erstellung der Ausgangssituation der Anwendungsarchitektur, der Ziel-Anwendungsarchitektur und der Gap-Analyse ist eine Applikations-Roadmap erforderlich, die die auszuführenden Aktivitäten in den kommenden Phasen priorisiert. Diese erste Anwendungsarchitektur-Roadmap wird als Grundlage für eine detailliertere Definition einer konsolidierten, disziplinübergreifenden Roadmap innerhalb der Opportunities & Solutions Phase (Phase E) verwendet.
6	Klärung der Auswirkungen auf die gesamte Architekturlandschaft Sobald die Anwendungsarchitektur festgelegt ist, ist es notwendig, alle weiteren Folgen und Auswirkungen zu verstehen. An diesem Punkt sollten andere Architektur Artefakte in der Architektur Landschaft untersucht werden, um zu identifizieren: Hat die Anwendungsarchitektur Auswirkungen auf bereits existierende Architekturen? Wurden jüngst Änderungen ausgeführt, die Auswirkungen auf die Anwendungsarchitektur haben? Gibt es Möglichkeiten, Arbeiten die innerhalb der Anwendungsarchitektur verrichtet wurden in anderen Bereichen der Organisation zu nutzen? Hat die Anwendungsarchitektur Auswirkungen auf andere Projekte (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)? Wird die Anwendungsarchitektur von anderen Projekten beeinflusst (einschließlich der Geplanten sowie diejenigen, die derzeit im Gange sind)?
7	Durchführung eines formalen Stakeholder-Reviews Überprüfen, ob die ursprüngliche Motivation für das Architektur-Projekt und das Statement der Architektur-Arbeit der vorgeschlagenen Anwendungsarchitektur entsprechen. Durchführung einer Einfluss-Analyse, um Auswirkungen auf alle Bereiche zu identifizieren, in denen die Geschäfts-und Datenarchitektur möglicherweise geändert werden muss, um Änderungen der Anwendungsarchitektur (z.B. Verfahren, Anwendungen oder Datenbanksysteme) gerecht zu werden. Bei signifikantem Einfluss, rechtfertigt das die nochmalige Betrachtung der Geschäfts- und Datenarchitektur. Identifizierung möglicher Einschränkungen für die Technologie-Architektur (insbesondere die Infrastruktur) die noch gestaltet werden muss.
8	Finalisierung der Anwendungsarchitektur 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 der Gesamtarchitektur mit Anforderungen der Organisation Dokumentation für Rückverfolgbarkeit durchführen. Dokumentation der endgültigen Zuordnung der Architektur in dem Architektur-Repository; von den ausgewählten Bausteinen, über diejenigen, die wiederverwendet werden und alles im Architektur-Repository veröffentlichen Finalisierung aller Arbeitsprodukte, bspw. Gap-Analyse
9	Erstellung der Dokumentation für die Architekturdefinition Begründung für Entscheidungen über Bausteine in einem Architektur-Definition-Dokument festhalten. Vorbereitung von Anwendungsarchitektur-Abschnitten in dem Architektur-Definition-Dokument. Gegebenenfalls auf Berichte und / oder Grafiken, die durch Modellierungs-Tools erzeugt wurden, zurückgreifen; Dokument zur Überprüfung an relevante Stakeholders leiten und ggf. Feedback integrieren.

---

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.