TOGAF-Phase B

Phase B – Geschäftsarchitektur

TOGAF

In Phase B erfolgt die Entwicklung einer [| Geschäftsarchitektur] zur Unterstützung einer abgestimmten Architekturvision.

IVS-Rahmenarchitektur

In der Phase B wird die Entwicklung einer Geschäftsarchitektur zur Unterstützung einer abgestimmten IVS-Architekturprojekte geschaffen.

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Umsetzung IVS-Rahmenarchitektur
1	Auswahl von Referenzmodellen, Perspektiven und Werkzeugen Auswahl der entsprechenden Referenzmodelle, Perspektiven und Werkzeuge, auf der Grundlage der Business-Treiber und der Anliegen der Stakeholder. Die Auswahl der relevanten Perspektiven zeigt, wie die Anliegen Stakeholder in der Geschäftsarchitektur adressiert werden. Zusätzlich erfolgt die Identifizierung von geeigneten Werkzeugen und Techniken für die Erfassung der Geschäftsarchitektur, ihrer Modellierung und ihrer Analyse, in Verbindung mit den ausgewählten Perspektiven. Je nach Grad der gewollten Komplexität, kann die Modellierung in Form einfacher Dokumente oder Tabellen erfolgen, oder komplexere Modellierungstools und Techniken angewandt werden, wie Geschäftsprozessmodelle oder Use-Case-Modelle usw.
2	Entwicklung einer Beschreibung der Ausgangssituation der Geschäftsarchitektur Es sollte eine Beschreibung der bestehenden Geschäftsarchitektur auf der Basis der benötigten Anforderungen zur Unterstützung und Beschreibung der Ziel-Geschäftsarchitektur angefertigt werden. Der Umfang und die Detailebene der Beschreibung der bestehenden Geschäftsarchitektur hängt ab, von der Anzahl der zu übertragenden Elemente in die Ziel-Geschäftsarchitektur. Relevante Bausteine sollten vorher definiert werden.
3	Entwicklung einer Beschreibung der Ziel-Geschäftsarchitektur Die Beschreibung für die Ziel-Geschäftsarchitektur sollte in dem Umfang erfolgen, die zur Umsetzung der Architektur Vision benötig wird. Umfang und Wichtigkeit ergeben sich also auf Basis der Architektur Vision und vorhandener Architekturbeschreibung Zusatz Die Ziel-Geschäftsarchitektur gibt einen verbindlichen Orientierungs- und Gestaltungsrahmen für die Umsetzung vor. Dies sind in der Regel grobe, strategische Aussagen. Diese Aussagen werden durch Prinzipien und Richtlinien weiter ergänzt. Die bestehende Geschäftsarchitektur sowie der strategische und operative Handlungsbedarf sind neben den strategischen Vorga-ben (bspw. Architektur- und Geschäftsprinzipien) wesentlicher Input für die Festlegung der Ziel-Geschäftsarchitektur.
4	Durchführung einer Gap-Analyse Überprüfung der Architekturmodelle nach Konsistenz und Genauigkeit: Trade-Off-Analyse der verschiedenen Architekturmodelle durchführen um Konflikte zu vermeiden Sicherstellen, dass die Architekturmodelle, die Prinzipien unterstützen, Zielen und Restriktionen entsprechen Abweichungen dokumentieren Architekturmodelle auf Vollständigkeit gegeben der Anforderungen prüfen Zusatz Die GAP-Analyse wird verwendet, um Lücken zu identifizieren die zwischen Ist-Architektur und Soll-Architektur existieren. Die Lücken stellen das Delta zwischen Ist- und Soll-Zustand dar und helfen die für die Überbrückung notwendigen Maßnahmen abzuleiten.
5	Definition von Roadmap-Komponenten Nach der Beschreibung der bestehenden Geschäftsarchitektur, der Ziel-Geschäftsarchitektur und der Durchführung der Gap-Analyse, ist die Erstellung einer Roadmap erforderlichen, um Handlungsschritte und Aktivitäten in den kommenden Phasen zu priorisieren. Diese Erstversion der Geschäftsarchitektur-Roadmap wird als Grundstein zur detailliertere Definition einer konsolidierten, disziplinübergreifenden Roadmap innerhalb der Opportunities & Solution Phase (Phase E) verwendet.
6	Klärung der Auswirkungen auf die gesamte Architekturlandschaft Sobald die Erstellung der Geschäftsarchitektur durchgeführt ist, ist es notwendig, alle weiteren Folgen oder Auswirkungen zu verstehen. In dieser Phase sollten andere Architektur Artefakte in der Architektur Landschaft untersucht werden, um Folgendes zu klären: Hat diese Geschäftsarchitektur Auswirkungen auf bereits existierende Architekturen? Haben die jüngsten Änderungen Auswirkungen auf die Geschäftsarchitektur? Gibt es Möglichkeiten, Arbeiten die während der Erstellung der Geschäftsarchitektur durchgeführt worden sind, in anderen Bereichen der Organisation zu nutzen? Hat diese Geschäftsarchitektur Auswirkungen auf andere Projekte (einschließlich der geplanten sowie diejenigen, die derzeit im Gange sind)? Wird die Geschäftsarchitektur von anderen Projekten beeinflusst werden (die geplanten sowie diejenigen, die derzeit im Gange sind)?
7	Durchführung eines formalen Stakeholder-Reviews Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture, asking if it is fit for the purpose of support-ing subsequent work in the other architecture domains. Refine the proposed Business Archi-tecture only if necessary. || ||
8	Finalisierung der Geschäftsarchitektur 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 können (Aktivitäten, Rollen, Geschäftsbeziehungen, Stellenbeschreibungen, etc.), Alles im Architektur-Repository veröffentlichen Finalisierung aller Arbeitsprodukte, wie bspw. Ergebnisse der Gap-Analyse
9	Erstellung der Dokumentation für die Architekturdefinition Document rationale for building block decisions in the Architecture Definition Document Prepare the business sections of the Architecture Definition Document, comprising some or all of: A business footprint (a high-level description of the people and locations involved with key business functions) A detailed description of business functions and their information needs A management footprint (showing span of control and accountability) Standards, rules, and guidelines showing working practices, legislation, financial measures, etc. A skills matrix and set of job descriptions If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and in-corporate feedback.

---

Es werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.