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