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: 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 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
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
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.