Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03373.jsonl.gz/1630

Das TOGAF®-Framework ist eine Methode zur Entwicklung einer Unternehmensarchitektur mit Hilfe einer Reihe von Werkzeugen und steht Organisationen, die eine Unternehmensarchitektur einführen wollen, kostenlos auf der Website der Open Group zur Verfügung. Die erste Version, die 1995 veröffentlicht wurde, basierte auf dem Technical Architecture Framework for Information Management (TAFIM), das vom US-Verteidigungsministerium entwickelt wurde. Der TOGAF-Standard besteht aus dem ADM-Zyklus
Die TOGAF-Zielsetzung
Das TOGAF®-Framework ist ein Ansatz für eine „schnelle“ Architekturentwicklung und eine effektive Governance. Es schreibt nicht die Modelle vor, die zur Darstellung der Architektur zu verwenden sind, sondern leitet den Prozess während der Erstellung der Architektur. Dank seiner Skalierbarkeit kann es für Regierungsorganisationen, Großunternehmen und sogar für kleine und mittlere Unternehmen eingesetzt werden. Betrachtet man die verschiedenen Architekturebenen, die ein Rahmenwerk unterstützen kann, so versucht TOGAF®, alle Ebenen zu unterstützen, von der Unternehmens-, Daten- und Anwendungsarchitektur bis hin zur Technologiearchitektur.
TOGAF Vorteile
Der TOGAF-Standard bietet die folgenden Vorteile:
A method tested and applied by thousands of digital architects;
A common dictionary, so that everyone can understand the information provided by the resulting architecture.
TOGAF Framework
- Das TOGAF®-Framework besteht aus den folgenden Hauptbestandteilen:
- Das Capability Framework: Who? Wer sollte beteiligt sein? der Zyklus der Architekturentwicklungsmethode (ADM): What? Was sollte getan werden?
- ADM-Leitlinien und -Techniken: How? Wie sollte es gemacht werden?
- Der Inhaltsrahmen: Which? Welche Dokumentation sollte erstellt werden?
- Unternehmenskontinuum und Werkzeuge: Where? Where to store documentation?
9 Phasen von TOGAF ADM
Der TOGAF-Standard als Architekturentwicklungsmethode ist ein detaillierter, in Phasen unterteilter Ansatz, der erklärt, wie man den gesamten Lebenszyklus einer Architektur bewältigt.Die Phasen sind wie folgt:
Vorläufige Phase – Rahmen und Prinzipien
In dieser TOGAF-Phase werden das Enterprise Architecture Team, die Architekturprinzipien und das zu verwendende Framework definiert.
Phase A: Defining Architecture Visions
Diese TOGAF-Phase identifiziert :
- The list of stakeholders, their roles and implications
- Ein Konsens über die Ziele, Anforderungen, Beschränkungen und Architekturregeln
- Der betroffene Anwendungsbereich
- Der Entwicklungsplan für den ADM-Zyklus und die erforderlichen personellen, technischen und finanziellen Ressourcen
- Großräumiges Mapping der ursprünglichen Architektur und der Zielarchitektur
- Identifizierung von Risiken und Plan zu deren Verringerung
Phase B: Entwicklung der Geschäftsarchitektur
Das Geschäft mit seinen Anforderungen, Prozessen und Entitäten bestimmt die Unternehmensarchitektur. Die TOGAF-Phase Business B dient dazu, die Zielarchitektur zu definieren und ihre Auswirkungen zu messen. Die Ergebnisse dieser Phase können z.B. mit UML oder IDEF-0 definiert werden. Die Wahl der Modellierungsmethode richtet sich nach den erforderlichen Sichten, deren Gesichtspunkte in dieser Phase ermittelt werden.
Phase C: Entwicklung von Informationssystem-Architekturen
Das Ziel dieser TOGAF-Phase ist die Beschreibung der Daten- und Anwendungsarchitektur. The views created in this phase are again modelled in the chosen model. For databases, for example, this may be relational data modelling.
Phase D: Developing Technical Architecture
Ziel dieser TOGAF-Phase ist die Beschreibung der technischen Architektur, die die Grundlage für die anschließende Implementierung bildet.
Das Geschäft mit seinen Anforderungen, Prozessen und Entitäten bestimmt die Unternehmensarchitektur. Die TOGAF-Phase Business B dient dazu, die Zielarchitektur zu definieren und ihre Auswirkungen zu messen. Die Ergebnisse dieser Phase können z.B. mit UML oder IDEF-0 definiert werden. Die Wahl der Modellierungsmethode richtet sich nach den erforderlichen Sichten, deren Gesichtspunkte in dieser Phase ermittelt werden.
Phase D: Entwicklung von Informationssystem-Architekturen
Ziel dieser TOGAF-Phase ist es, die technologische Architektur zu beschreiben, die die Grundlage für die nachfolgenden Implementierungsarbeiten bildet.
Phase E: Entwicklung von Lösungen und Möglichkeiten
In dieser TOGAF-Phase werden die Merkmale der Änderung identifiziert, die Implementierungseinschränkungen bestimmt, die Abhängigkeiten validiert und eine Übergangsarchitektur identifiziert. Die Ergebnisse dieser Phase bilden die Grundlage für den Implementierungsplan, der für den Übergang zur Zielarchitektur erforderlich ist.
Phase F: Migrationsplanung
In dieser TOGAF-Phase liegt der Schwerpunkt auf der Priorisierung der Projekte und der Schätzung der Migrationskosten für die verschiedenen Projekte. Das Endergebnis ist eine detaillierte Architektur-Roadmap, einschließlich des Implementierungs- und Migrationsplans.
Phase G: Implementierung der Governance
Für jedes Implementierungsprojekt wird eine entsprechende Organisation benannt, die die Umsetzung sicherstellt. Gleichzeitig werden Compliance-Prüfungen durchgeführt, um sicherzustellen, dass das System am Ende dieser TOGAF-Phase vollständig fertiggestellt und gemäß den Spezifikationen implementiert ist.
Phase H: Architecture Change Management
Der Lebenszyklus der Architektur des TOGAF®-Frameworks endet nicht, wenn das System implementiert worden ist. Das Ziel dieser Phase ist es, Änderungen an der Architektur auf konsistente Weise zu verwalten. Damit die Architektur flexibel und dynamisch bleibt, müssen alle technologischen oder umweltbedingten Änderungen schnell in die Architektur eingearbeitet werden. In dieser Phase wird entschieden, ob für jede Änderungsanforderung formell ein neuer Architekturentwicklungszyklus eingeleitet werden soll. Diese Entscheidung muss auf der Grundlage vordefinierter Kriterien getroffen werden, die bestimmen, ob eine Änderungsanforderung nur eine Aktualisierung der aktuellen Architektur oder einen Neustart des Zyklus erfordert. Diese Kriterien sind im TOGAF®-Framework nicht vordefiniert, da die Risikoakzeptanz von Unternehmen zu Unternehmen zu unterschiedlich ist.
Requirement Management
Der zentrale Kreis des ADM-Zyklus zeigt uns, dass die verschiedenen Phasen des ADM durch Anforderungen gesteuert werden. Das TOGAF®-Rahmenwerk schreibt keine bestimmte Art und Weise der Erfassung und Verwaltung dieser Anforderungen vor, sondern legt nur fest, wie ein effektiver Anforderungsmanagementprozess aussehen sollte.
Die verschiedenen Phasen des ADM-Zyklus liefern den Input für den Anforderungsmanagementprozess.
Endgültiges Ergebnis
Bei der Anwendung des TOGAF®-Frameworks zur Erstellung einer Architektur erzielen viele Unternehmen nicht immer den erwarteten Nutzen. Dies liegt in der Regel daran, dass eine Architektur oft von unten nach oben implementiert wird, wobei sich das Management nicht ausreichend dafür einsetzt, dass die Geschäftsziele mit den Architekturzielen übereinstimmen, so dass es unmöglich ist, das beabsichtigte Geschäftsziel durch den Einsatz der Architektur zu erreichen. Dieses Problem tritt bei jedem Rahmenwerk auf, das zur Erstellung einer Architektur verwendet wird. Es ist daher wichtig, dass der in Phase A verwendete strategische Plan von der gesamten Organisation geteilt und genehmigt wird.
QRP International bietet TOGAF-Kurse in TOGAF Foundation, TOGAF Practitioner und TOGAF Combi an. Schreiben Sie uns für weitere Informationen!