Hinweise zu den Phasen B,C und D
Architekturentwicklung in den TOGAF Phasen B, C und D
TOGAF sieht den Entwurf von Architekturen auf verschiedenen Ebenen vor. Unter anderem werden Architekturen auf den Ebenen Geschäftsarchitektur, Informationsarchitektur und Technologiearchitektur beschrieben. Die Struktur der Beschreibung dieser Architekturen ist identisch aufgebaut und enthält die folgenden Schritte:
- Auswahl von Referenzmodellen, Perspektiven und Werkzeugen
- Entwicklung einer Beschreibung der Ausgangssituation der Architektur
- Entwicklung einer Beschreibung der Ziel-Architektur
- Durchführung einer Gap-Analyse
- Definition von Roadmap-Komponenten
- Klärung der Auswirkungen auf die gesamte Architekturlandschaft
- Durchführung eines formalen Stakeholder-Reviews
- Finalisierung der Architektur
- Erstellung der Dokumentation für die Architekturdefinition
Dabei ist vorgesehen, dass zuerst eine Ist-Architektur (Ausgangssituation der Architektur - Schritt 2) und danach eine Soll-Architektur (Ziel-Architektur - Schritt 3) beschrieben wird. Anschließend sollen in einer Gap-Analyse (Schritt 4) die Unterschiede zwischen der Ist- und der Soll-Architektur herausgearbeitet werden, die dann in einer Roadmap (Schritt 5) zeitlich geplant werden.
Referenzarchitekturen in den TOGAF Phasen B, C und D
Diese Vorgehensweise ist für die Entwicklung der Architektur eines realen IVS-Dienstes sicherlich sinnvoll. Bei der Entwicklung einer Referenzarchitektur ist dies jedoch nicht immer der Fall. Eine Referenzarchitektur abstrahiert die Architekturen realer IVS-Dienste einer bestimmten IVS-Domäne. Es ist daher oft gar nicht möglich, eine Ist-Architektur anzugeben, da die Ist-Architekturen der realen IVS-Dienste weit auseinander klaffen. Stattdessen können dann Lücken bzw. fehlende Architekturbausteine identifiziert und beschrieben werden. In anderen Fällen ist es möglich, bestehende Architekturbausteine, die eine sinnvolle Weiterentwicklung der Architektur erschweren, zu benennen. Die Beschreibung der Ist-Architektur sollte, wenn möglich, die bestehenden Architekturbausteine beschreiben. Insbesondere sollen dabei die Bausteine aufgelistet werden, die einer sinnvollen Weiterentwicklung der Architektur im Wege stehen. Wenn dies nicht möglich ist, sollten zumindest Lücken identifiziert werden. Dabei werden Architekturbausteine aufgelistet, die für eine Weiterentwicklung der Architektur fehlen.
Die Zielarchitektur muss jedoch auf jeden Fall beschrieben werden. Bei der Gap-Analyse werden die neuen, die zu verändernden und die zu entfernenden Architekturbausteine identifiziert und bei der Definition der Roadmap-Komponenten in einen Zeitplan eingeordnet.
Es wird folgende Vorgehensweise für die Entwicklung einer Referenzarchitektur vorgeschlagen:
- Auswahl von Referenzmodellen, Perspektiven und Werkzeugen
- Beschreibung der vorhandenen Architekturbausteine, falls nicht möglich, Beschreibung der fehlenden Architekturbausteine
- Entwicklung einer Beschreibung der Ziel-Architektur
- Durchführung einer Gap-Analyse
- Definition von Roadmap-Komponenten
- Klärung der Auswirkungen auf die gesamte Architekturlandschaft
- Durchführung eines formalen Stakeholder-Reviews
- Finalisierung der Architektur
- Erstellung der Dokumentation für die Architekturdefinition
Architekturen realer IVS-Dienste in den TOGAF Phasen B, C und D
Bei der Entwicklung von Architekturen realer IVS-Dienste sollen die Schritte 2-5 sowie 9 auf jeden Fall durchgeführt werden. Ob und wie die anderen Schritte bei der Entwicklung einer Architektur eines realen IVS-Dienste durchgeführt werden, wird jeweils projektspezifisch festgelegt. Damit ergibt sich die folgende Vorgehensweise bei der Entwicklung und Beschreibung einer Architektur eines realen IVS-Dienstes:
- Auswahl von Referenzmodellen, Perspektiven und Werkzeugen (projektspezifisch)
- Entwicklung einer Beschreibung der Ausgangssituation der Architektur
- Entwicklung einer Beschreibung der Ziel-Architektur
- Durchführung einer Gap-Analyse
- Definition von Roadmap-Komponenten
- Klärung der Auswirkungen auf die gesamte Architekturlandschaft (projektspezifisch)
- Durchführung eines formalen Stakeholder-Reviews (projektspezifisch)
- Finalisierung der Architektur (projektspezifisch)
- Erstellung der Dokumentation für die Architekturdefinition
