TOGAF-Phase C

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen

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


Auswahl von IVS-Referenzmodellen und Werkzeugen IVS-Referenzmodelle und Werkzeuge
2 Entwicklung einer Beschreibung der Ausgangssituation für die Datenarchitektur Auflistung der Standards zum Datenaustausch Ausgangssituation der IVS-Datenarchitektur
3 Entwicklung einer Beschreibung der Ziel-Datenarchitektur


Harmonsierung von Datenmodellen Zielsituation der IVS-Datenarchitektur
4 Durchführung einer Gap-Analyse


Gap-Analyse der Datenarchitektur 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 Durchführung einer Gap-Analyse
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.