TOGAF (The Open Group Architecture Framework) ist ein offenes organisatorisches Framework. Das Framework selbst ist eine gut dokumentierte Wissenssammlung, einschließlich detaillierter Methoden und einer Reihe unterstützender Tools für die Entwicklung von Unternehmensarchitekturen. TOGAF 9.2 ist die neueste Version des Frameworks.
- TOGAF wird von Mitgliedern der Open Group entwickelt und gepflegt und arbeitet in einem Team namens Architecture Forum. Die erste Entwicklung von TOGAF Version 1 wurde 1995 produziert, und nachfolgende Versionen von TOGAF erweiterten und verbesserten dieses Wissenssystem.
- TOGAF wurde durch die gemeinsamen Bemühungen von mehr als 300 Mitgliedern des Architekturforums entwickelt, die einige der weltweit führenden Unternehmen und Organisationen vertreten, und ist daher eine gute Zusammenfassung der allgemeinen Praktiken der Unternehmensarchitektur.
- Die Entwicklung und Wartung einer Unternehmensarchitektur ist ein komplexer Prozess, an dem viele Interessengruppen und Entscheidungsprozesse beteiligt sind. TOGAF hilft durch die Dokumentation von Spezifikationen, Prozessen und Arbeitsergebnissen der Unternehmensarchitektur.
- Durch den Einsatz von TOGAF können Unternehmen eine konsistente Unternehmensarchitektur entwickeln, die die Bedürfnisse der Stakeholder widerspiegelt, Best Practices anwendet und aktuelle Bedürfnisse und wahrgenommene Geschäftsanforderungen in der Zukunft angemessen berücksichtigt.
Woher kommt TOGAF?
TOGAF entstand aus dem Information Management Technology Architecture Framework (TAFIM) des US-Verteidigungsministeriums. TOGAF 1.0 wurde schließlich 1995 nach Jahren der Erforschung mit Genehmigung des US-Verteidigungsministeriums und der Hilfe einer großen Investition der US-Regierung veröffentlicht. TOGAF hat seine bisher neunte Version veröffentlicht, TOGAF 9 (die neueste Version ist TOGAF 9.2)
Warum TOGAF?
Die IT-Architektur muss die Geschäftsziele der Organisation genau widerspiegeln. Tatsächlich sollten spezifische Techniken (Geschäftsszenarien) verwendet werden, um sicherzustellen, dass die Geschäftsziele vom IT-Architekten richtig verstanden und in der mit TOGAF entwickelten IT-Architektur widergespiegelt werden.
Hier sind die Gründe, warum wir TOGAF ADM für die Architekturentwicklung einsetzen sollten:
- Eine umfassende allgemeine Methode
- Ergänzend, nicht konkurrierend mit anderen Frameworks
- Weit verbreitet auf dem Markt
- Maßgeschneidert, um die Anforderungen einer Organisation und Branche zu erfüllen
- Verfügbar unter einer kostenlosen unbefristeten Lizenz
- Hersteller-, tool- und technologieneutraler offener Standard
- Vermeidet es, das Rad neu zu erfinden
- Business-IT-Ausrichtung
- Basierend auf Best Practices
- Teilnahme an der Weiterentwicklung des Frameworks möglich
Was ist ADM?
Die Architekturentwicklungsmethode (ADM) wird angewendet, um eine Unternehmensarchitektur zu entwickeln, die die Geschäfts- und Informationstechnologieanforderungen einer Organisation erfüllt. Das TOGAF ADM ist das Ergebnis kontinuierlicher Beiträge einer großen Anzahl von Architekturpraktikern, die den folgenden Zwecken dienen:
- Es beschreibt eine Methode zur Entwicklung und Verwaltung des Lebenszyklus einer Unternehmensarchitektur und bildet den Kern von TOGAF.
- Es kann auf die Bedürfnisse der Organisation zugeschnitten werden und wird dann verwendet, um die Ausführung von Architekturplanungsaktivitäten zu verwalten.
Die Architekturentwicklungsmethode – oft als Abkürzung für ADM bezeichnet – ist ein detaillierter Schritt-für-Schritt-Prozess, der verwendet wird, um die Architektur eines Unternehmens zu entwickeln oder zu ändern.
ADM beschreibt 10 Phasen, die den Architekturentwicklungszyklus abdecken.
Diese Phasen sind:
- Vorstufe
- Phase A : Architektonische Vision
- Phase B : Geschäftsarchitektur
- Phase C : Architektur des Informationssystems
- Phase D : Technische Architektur
- Phase E : Chancen und Lösungen
- Phase F : Migrationsplanung
- Stufe G : Implementieren Sie Governance
- Phase H : Architekturänderungsmanagement
- Anforderungsmanagement
ADM-Eingang und -Ausgang
TOGAF bietet eine Reihe von Input- und Output-Ergebnissen aus jeder Phase:
- Dies sind Vorschläge und müssen nicht genau befolgt werden
- Jede produzierte Leistung sollte versioniert werden, um anzuzeigen, wenn eine Änderung aufgetreten ist
- Die angezeigte Versionsnummerierung ist ebenfalls ein Vorschlag und muss nicht befolgt werden
Leistungen
Ein Arbeitsprodukt, das vertraglich spezifiziert und wiederum von den Stakeholdern formal überprüft, vereinbart und abgezeichnet wird. Es wird normalerweise nach Abschluss eines Projekts archiviert oder als Referenzmodell in ein Architektur-Repository überführt
Erstphase:
Das Hauptziel der Anfangsphase besteht darin, die erforderlichen architektonischen Fähigkeiten der Organisation zu bestimmen und zu etablieren.
Einer der wichtigsten Teile ist, zu bestimmen, was getan werden muss und wie es umgesetzt werden soll. Das Hauptergebnis ist beispielsweise eine architektonische Arbeitsanforderung , die die Anforderungen umreißt und entscheidet, welcher Umfang, welche Struktur, welche Tools oder welcher architektonische Rahmen zur Unterstützung dieser Arbeit erforderlich sind.
In dieser Phase ist TOGAF speziell auf die Anforderungen der bevorstehenden ADM-Iteration zugeschnitten. Wir definieren Grundprinzipien, bewerten die Fähigkeit der Unternehmensstruktur und des Geschäfts, erforderliche Änderungen vorzunehmen, und integrieren TOGAF in andere Management-Frameworks. In dieser Phase gibt es Schritte, um die von den vorgeschlagenen Änderungen betroffene Unternehmensorganisation einzuschränken, das korrekte Governance- und Support-Framework zu bestätigen, ein EA-Team und eine EA-Organisation zu definieren und einzurichten, Architekturprinzipien zu identifizieren und festzulegen, TOGAF und alle anderen Frameworks anzupassen und Tools zu implementieren . Am Ende dieser Phase sollte das EA-Team bereit sein, die Iterationen des ADM-Zyklus zu verfolgen. Dies liegt zum Teil daran, dass die Vorstufe oben im ADM-Diagramm und außerhalb der Hauptschleife der Stufen A bis H dargestellt ist.
Phase A: Architekturvision:
Phase A bietet eine klare architektonische Arbeitserklärung, die in der Iteration von ADM bereitgestellt wird. Es bietet auch eine Vision für die vorgeschlagene Unternehmensarchitektur. Dieser Orientierungssinn ist wesentlich, um die Arbeit von ADM während des gesamten Iterationsprozesses zu leiten. Die Erklärung der architektonischen Arbeit definiert die Verfahren zum Entwickeln und Bereitstellen der in der Architekturvision skizzierten Architektur. Es ist die Vision, die den hochrangigen Wunsch nach der Funktionalität und dem Geschäftswert vermittelt, die die vorgeschlagene Unternehmensarchitektur bieten wird. Beginnend mit der Bewerbung für eine Stelle im Bauwesen bietet Phase A ein Werkzeug (diese Vision), um die Vorteile der vorgeschlagenen Fähigkeiten an Stakeholder und Entscheidungsträger im Unternehmen zu verkaufen. Geschäftsszenarien werden verwendet, um die Geschäftsanforderungen zu verstehen und die durch die erforderlichen Funktionen implizierten architektonischen Anforderungen zu verdeutlichen. Dies ist in der Architektur-Arbeitserklärung dokumentiert und wird verwendet, um einen Konsens zur Unterstützung der endgültigen Architektur zu erzielen. Wenn die Trägerorganisation das Dokument unterzeichnet, wird ein Konsens entstehen.
Die Schritte in Phase A bestehen darin, die Bauanfrage in eine klare architektonische Leistungserklärung umzuwandeln und sicherzustellen, dass das Unternehmen in der Lage, bereit, willens und engagiert ist, die notwendigen architektonischen Änderungen vorzunehmen. Dies beinhaltet die Etablierung eines Architekturprojekts, einschließlich der Definition seines Umfangs, sowie die Bestätigung und Ausarbeitung der Architektur und der Geschäftsprinzipien. Phase A identifiziert Stakeholder und ihre Bedenken und Anforderungen und bestätigt die Geschäftsziele, treibenden Faktoren und Einschränkungen der Vorphase. Um den Erfolg sicherzustellen, bewertet es auch die Geschäftsfähigkeiten, bewertet die Bereitschaft zur Geschäftstransformation und löst alle Transformationsrisiken.
Phase B: Geschäftsarchitektur:
TOGAF betrachtet die Unternehmensarchitektur als eine Möglichkeit, die Geschäftsfähigkeiten zu verbessern – deshalb befasst sich die erste Phase der Architekturentwicklung mit der Geschäftsarchitektur .
ADM aus geschäftlicher Sicht – in den Vorstufen der Infrastrukturarbeitsanforderungen , um die starke Geschäftsnachfrage zu ermitteln, und weiter verfeinert für Phase A in der Infrastrukturarbeit und Architekturvision .
Ein Hauptziel der Geschäftsarchitekturphase ist die Entwicklung der Zielgeschäftsarchitektur, die zeigt, wie das Unternehmen die Architekturvision verwirklicht und die Architekturarbeitsanforderung löst. Das zweite Ziel besteht darin, zunächst Komponenten der Kandidatenarchitektur-Roadmap zu identifizieren, um die Lücke zwischen der Baseline und der angestrebten Geschäftsarchitektur zu schließen. TOGAF betrachtet Geschäftsarchitekturwissen als Voraussetzung für Architekturarbeit in anderen Bereichen (z. B. Daten, Anwendungen und Technologie). Die Geschäftsarchitektur demonstriert den wichtigsten Stakeholdern auch den kommerziellen Wert und die Rentabilität der Architekturarbeit. Geschäftsmodelle wie Aktivitäts- oder Prozessmodelle, Anwendungsfälle und Klassenmodelle oder Knotenverbindungsdiagramme,
Alle drei Architekturentwicklungsphasen (B, C und D) folgen ähnlichen Schritten. Es ist wichtig, jedes verfügbare Referenzmodell wiederzuverwenden und alle Ergebnisse anzupassen, um den Standpunkt der Interessengruppen zu berücksichtigen. Anschließend entwickelt der Architekt eine Ausgangs- und Zielbeschreibung der Geschäftsarchitektur und führt eine Gap-Analyse durch, um zu bestimmen, wie von einer Architektur zur anderen übergegangen werden kann.
Phase C: Architektur des Informationssystems:
TOGAF unterteilt Phase C – Informationssystemarchitektur – in zwei Teile, die die Entwicklung der Daten- und Anwendungsarchitektur abdecken . Das TOGAF-Dokument enthält ein kurzes Einführungskapitel, das zwei Bereiche abdeckt, gefolgt von separaten Kapiteln zu Daten und Anwendungen. Wie bei anderen Architekturentwicklungsphasen (B&D) besteht das Ziel darin, die Zielarchitektur des Informationssystems für Daten und Anwendungen zu entwickeln und Kandidatenarchitektur-Roadmap-Komponenten basierend auf der Lücke zwischen der Baseline und der Zielarchitektur zu bestimmen.
In Phase C geht es immer um die Kombination von Daten- und Anwendungsarchitektur. Vorausgesetzt, beide sind enthalten, und es spielt keine Rolle, in welcher Reihenfolge, gibt es Befürworter für beide Methoden. Die Schritte für Daten und Anwendungen sind sehr ähnlich – wählen Sie Referenzmodelle, Standpunkte und Werkzeuge aus; Baselines entwickeln und dann Architekturbeschreibungen lokalisieren, Gap-Analysen durchführen und Kandidaten-Roadmap-Komponenten definieren; und alle Auswirkungen in der gesamten Architekturumgebung beheben. Nach einem formellen Stakeholder-Review wurde die Architektur endgültig festgelegt und ein Architekturdefinitionsdokument erstellt.
Der Hauptunterschied zwischen Daten und Anwendungen liegt in der Thematik, die sich in der Verwendung unterschiedlicher Referenzmodelle, Technologien und Architekturdarstellungen widerspiegelt. Beispielsweise kann die Datenarchitektur Entitätsbeziehungen oder Klassendiagramme verwenden, während die Anwendungsarchitektur Anwendungskommunikationsdiagramme oder Softwareentwicklungsdiagramme verwenden kann.
Phase D: Technische Architektur:
Phase D ist die Phase von TOGAF, die die technische Architektur für das Architekturprojekt entwickelt. Die Technologiearchitektur beschreibt die Struktur und das Zusammenspiel von Plattformdiensten und logischen und physikalischen Technologiekomponenten. Phase D entwickelt die Zieltechnologiearchitektur, die Daten- und Anwendungskomponenten (entwickelt in Phase C) unterstützt, um Geschäftskomponenten zu realisieren.
Die in den Phasen B, C und D entwickelten Architekturen werden kombiniert, um die Architekturvision zu verwirklichen, die die Anliegen der Interessengruppen und die Anforderungen der Bauarbeiten löst. Wie bei anderen Architekturentwicklungsphasen werden in Phase D mögliche Architektur-Roadmap-Komponenten identifiziert, um den Übergang von Baseline zu Target zu erreichen. Die Schritte in Phase D sind fast dieselben wie in Phase B und Phase C – der Hauptunterschied besteht darin, dass der Fokus jetzt auf der Technologie liegt. Dazu gehören daher technische Referenzmodelle und technische Standards oder Messungen – wie Leistung, Wartbarkeit, Standort und Latenz oder Verfügbarkeit.
Die Bestimmung des Outputs und der Liefergegenstände ist sehr wichtig, um beim Aufbau der technischen Architektur zu helfen, die das Informationssystem und die Geschäftsarchitektur wirklich unterstützt. Das Ermitteln des richtigen Umfangs kann die Rendite beschleunigen, während ein zu großer Umfang eine erfolgreiche Implementierung behindert. Dabei geht es nicht um die Bereitstellungstechnologie selbst, sondern um die Entwicklung einer technischen Architektur, die die architektonische Vision und die Arbeitsanforderungen wirklich anspricht.
Phase E: Chancen und Lösungen:
Phase E bekommt ihren Namen – es geht darum, Möglichkeiten zu finden, die Zielarchitektur bereitzustellen, indem spezifische Lösungen implementiert werden. Phase E generiert die erste vollständige Version der Architektur-Roadmap, indem die Empfehlungen der Analyse- und Gebäudeentwicklungsphasen B, C und D kombiniert werden.
In dieser Phase liegt das Hauptaugenmerk auf der Bereitstellung der Architektur. Daher konzentriert es sich auf die Erstellung einer Architektur-Roadmap, die Arbeitspakete in einem Zeitplan auflistet, um die Zielarchitektur zu erreichen. Wenn die Änderung so groß ist, dass es unmöglich ist, direkt von der Baseline zur Zielarchitektur zu gehen, wird Stufe E einen inkrementellen Ansatz hervorbringen, der aus Zwischen- oder Übergangsarchitekturen besteht. Phase E bildet die erforderlichen architektonischen Änderungen auf Investitionsverfahren und Projekte ab, die über die Mittel und Ressourcen verfügen, um das Arbeitspaket auszuführen, und stellt Übergangs- und Zielarchitekturen bereit. Der Input in dieser Phase ist fast alles, was in der frühen Phase ausgegeben wurde. Diese Schritte nehmen diese Ausgaben; konsolidieren, Abhängigkeiten analysieren und Differenzen ausgleichen; und erneut bestätigen, dass die Organisation Änderungen vornehmen kann. Phase E verbessert und aktualisiert Anforderungen, Architekturdokumente und Architektur-Roadmaps. Das wichtigste Ergebnis ist der erste Schritt im Implementierungs- und Migrationsplan.
Phase F: Migrationsplanung:
In den frühen Stadien von ADM wurde der Bedarf an Architekturänderungen identifiziert und dann die Geschäfts-, Daten-, Anwendungs- und technischen Architekturen entwickelt, um diesen Bedarf zu unterstützen. Dann wird in der zweiten Phase ein Implementierungs- und Migrationsplan auf hoher Ebene entwickelt, um Investitionsmöglichkeiten zu nutzen und spezifische Lösungen zu identifizieren. Zielarchitektur: Phase F stellt den detaillierten Implementierungs- und Migrationsplan sowie die endgültige Architektur-Roadmap fertig.
Es stellt auch sicher, dass der Plan mit den im Unternehmen verwendeten Change-Management-Methoden und anderen Plänen im gesamten Change-Portfolio abgestimmt ist. Schließlich stellt Phase F sicher, dass die wichtigsten Stakeholder den Geschäftswert, die Kosten des Arbeitspakets sowie den Übergang und die zukünftige Architektur vollständig verstehen. Obwohl die frühen Phasen von ADM stark vom Unternehmensarchitekturteam geleitet werden, erfordert die Phase von E nach H die Zusammenarbeit mit anderen Change Agents.
Phase F erfordert insbesondere eine enge Zusammenarbeit zwischen den vier Managementrahmen, um den Umsetzungs- und Umsiedlungsplan zum Erfolg zu führen.
Die vier Bereiche sind:
- Geschäftsplan
- Unternehmensstruktur
- Portfolio-Management
- Projektmanagement
Durch die Zusammenarbeit müssen diese vier Bereiche die Arbeit priorisieren, indem sie Kriterien wie Leistungsbewertung, Kapitalrendite, Geschäftswert, Schlüsselerfolgsfaktoren, Effektivitätsmessung und strategische Eignung verwenden.
Stufe G: Governance implementieren:
Die eigentliche Entwicklung und Implementierung findet parallel zu Phase G statt. Phase G stellt sicher, dass das Implementierungsprojekt und andere laufende Projekte der definierten Architektur entsprechen.
Typischerweise wird die Zielarchitektur als eine Reihe von Transformationen entwickelt, um so schnell wie möglich geschäftlichen Nutzen und Nutzen zu erzielen und die Risiken im Transformationsplan zu mindern. Jede Transformation ist ein Schritt hin zum Zielunternehmen, um die eigenen Geschäftsinteressen zu verwirklichen.
Bis wir Phase G erreichen, ist die Architektur entwickelt (in Phase A bis D), Möglichkeiten und Lösungen zur Bereitstellung der Architektur sind identifiziert (in Phase E) und detaillierte Implementierungs- und Migrationspläne sind abgeschlossen (in Phase F ). Daher besteht die Rolle des Phase-G-Architekturteams darin, die Architekturimplementierung zu beaufsichtigen. Dies geschieht durch die Validierung des Umfangs und der Prioritäten der Bereitstellung, die Steuerung der Entwicklung und Lösungsbereitstellung und die Durchführung von Compliance-Prüfungen.
Architekturvertragsdokumente werden verwendet, um Architekturänderungen voranzutreiben. Es wird zu Beginn von Phase G generiert und von der Architekturfunktionalität und den für die Implementierung Verantwortlichen genehmigt und ist ein Mechanismus zur Bewertung der Governance-Compliance der Architektur.
Phase H: Strukturänderungsmanagement:
Nichts lief nach Plan – es wird immer wieder neue Anforderungen und Änderungen an der Architektur geben. Phase H beschreibt den Change-Management-Prozess zur kohärenten und strukturierten Verwaltung von Änderungen an der Architektur. Normalerweise erfordert dies eine kontinuierliche Überwachung von Governance-Anforderungen, neuen Technologien oder Änderungen im Geschäftsumfeld.
Der Prozess soll die realisierte Unternehmensarchitektur als dynamische Umgebung unterstützen, die flexibel auf diese Veränderungen reagieren und sich schnell weiterentwickeln kann. In Phase H ist es wichtig, dass das Leitungsgremium Standards festlegt, um zu bestimmen, ob eine Änderungsanforderung eine einfache Architekturaktualisierung erfordert oder ob ein neuer Zyklus der Architekturentwicklungsmethode (ADM) eingeleitet werden muss. Änderungen müssen in direktem Zusammenhang mit dem Geschäftswert stehen. Die Verwendung der Unternehmensarchitektur ist der wichtigste Teil des Architekturentwicklungszyklus, daher ist es entscheidend, das Wachstum und den Niedergang des Unternehmens in Phase H zu überwachen.
Am Ende unterstützt die Unternehmensarchitektur, die gestern für die Organisation funktioniert hat, aktuelle oder zukünftige Funktionen nicht mehr. Die Ausgabe einer Änderungsanforderung in Phase H kann als Vereinfachung klassifiziert werden – normalerweise angetrieben durch die Anforderung, Investitionen zu reduzieren; inkrementelle Änderung – erfordert zusätzlichen Wert aus bestehenden Investitionen; oder Neugestaltung des Wandels, der eine Voraussetzung ist, um Investitionen zu steigern und neue Werte zu schaffen.
Architekturanforderungsmanagement:
In jeder Phase von ADM sind Anforderungen für die Generierung, Analyse und Überprüfung erforderlich. Die Phase des Anforderungsmanagements beschreibt den Prozess der Verwaltung dieser Architekturanforderungen im gesamten ADM. Die Phase des Anforderungsmanagements ist das Herzstück von ADM – deshalb wird sie in der Mitte des ADM-Kornkreises dargestellt. Diese Phase beschreibt den Anforderungsmanagementprozess und wie der Prozess mit anderen Phasen von ADM verknüpft ist. Anforderungen sind nicht statisch – sie entwickeln sich dynamisch zwischen jeder Phase unseres Abschlusses von ADM und dem ADM-Zyklus.
Die Anforderungen an die Unternehmensarchitektur und spätere Änderungen dieser Anforderungen werden identifiziert, gespeichert und in Bezug auf die ADM-Phasen sowie zwischen den ADM-Zyklen ein- und ausgegeben. Der Umgang mit Nachfrageänderungen ist entscheidend. Architektur befasst sich mit Ungewissheit und Veränderung – der „Grauzone“ zwischen den Erwartungen und Möglichkeiten der Interessengruppen! Daher werden sich die architektonischen Anforderungen immer wieder ändern.
Darüber hinaus beinhaltet die Architektur viele treibende Faktoren und Einschränkungen, die außerhalb der Kontrolle des Unternehmens liegen – wie z. B. sich ändernde Marktbedingungen oder neue Gesetze –, die auf unvorhergesehene Weise zu Änderungen der Anforderungen führen.
TOGAF betont, dass der Anforderungsmanagementprozess selbst keine Anforderungen behandeln, lösen oder priorisieren wird, da dies in der entsprechenden Phase von ADM erfolgt. Die Anforderungsmanagementphase ist nur der Prozess der Verwaltung der Anforderungen im gesamten ADM.
ADM-Vorphase
Die Vorbereitungs- und Initiierungsaktivitäten, die zum Erstellen einer Architekturfähigkeit erforderlich sind, einschließlich der Anpassung von TOGAF und der Definition der Architektur
Output-Leistungen:
- Prinzipien der Architektur
- Architektur-Repository
- Geschäftsprinzipien, Geschäftsziele und Geschäftstreiber
- Organisationsmodell für Unternehmensarchitektur
- Anfrage für Architekturarbeiten
- Maßgeschneidertes Architektur-Framework
ADM Phase A: Architekturvision
Die Anfangsphase eines Architekturentwicklungszyklus. Es enthält Informationen zum Definieren des Umfangs der Architekturentwicklungsinitiative, zum Identifizieren der Beteiligten, zum Erstellen der Architekturvision und zum Einholen der Genehmigung zum Fortfahren mit der Architekturentwicklung
Output-Leistungen:
- Prinzipien der Architektur
- Architekturfahrplan
- Architekturvision
- Geschäftsprinzipien, Geschäftsziele und Geschäftstreiber
- Fähigkeitsbewertung
- Kommunikationsplan
- Erklärung der Architekturarbeit
- Maßgeschneidertes Architektur-Framework
ADM Phase B: Geschäftsarchitektur
Geschäftsarchitektur: Die Entwicklung einer Geschäftsarchitektur zur Unterstützung der vereinbarten Architekturvision
Output-Leistungen:
- Dokument zur Architekturdefinition
- Prinzipien der Architektur
- Spezifikation der Architekturanforderungen
- Architekturfahrplan
- Geschäftsprinzipien, Geschäftsziele und Geschäftstreiber
- Erklärung der Architekturarbeit
ADM Phase C: Informationssystemarchitektur
Informationssystemarchitekturen: die Entwicklung von Informationssystemarchitekturen zur Unterstützung der vereinbarten Architekturvision
- Dokument zur Architekturdefinition
- Prinzipien der Architektur
- Spezifikation der Architekturanforderungen
- Architekturfahrplan
- Erklärung der Architekturarbeit
ADM Phase D: Technologiearchitektur
Technologiearchitektur: Die Entwicklung der Technologiearchitektur zur Unterstützung der vereinbarten Architekturvision
Output-Leistungen:
- Dokument zur Architekturdefinition
- Prinzipien der Architektur
- Spezifikation der Architekturanforderungen
- Architekturfahrplan
- Erklärung der Architekturarbeit
ADM-Phase E: Chancen und Lösungen
Opportunities & Solutions führt die anfängliche Implementierungsplanung und die Identifizierung von Liefervehikeln für die in den vorherigen Phasen definierte Architektur durch
Output-Leistungen:
- Dokument zur Architekturdefinition
- Spezifikation der Architekturanforderungen
- Architekturfahrplan
- Architekturvision
- Fähigkeitsbewertung
- Implementierungs- und Migrationsplan
- Erklärung der Architekturarbeit
ADM-Phase F: Migrationsplanung
Die Migrationsplanung befasst sich mit dem Übergang von der Baseline zu den Zielarchitekturen durch die Fertigstellung eines detaillierten Implementierungs- und Migrationsplans
- Bausteine der Architektur
- Dokument zur Architekturdefinition
- Spezifikation der Architekturanforderungen
- Architekturfahrplan
- Change Request Implementierungs- und Migrationsplan
- Implementierungs-Governance-Plan
- Anfrage für Architekturarbeiten
- Erklärung der Architekturarbeit
ADM-Phase G: Implementierungs-Governance
Implementierungs-Governance bietet eine architektonische Aufsicht über die Implementierung
Output-Leistungen:
- Änderungsanforderung
- Compliance-Bewertung
- Lösungsbausteine
- Erklärung der Architekturarbeit
ADM-Phase H: Architekturänderungsmanagement
Das Architekturänderungsmanagement legt Verfahren zur Verwaltung von Änderungen an der neuen Architektur fest. Das Anforderungsmanagement untersucht den Prozess der Verwaltung von Architekturanforderungen im gesamten ADM
Zusammenfassung
Das ADM ist eine umfassende allgemeine Methode
- Es empfiehlt eine Reihenfolge für verschiedene Phasen und Schritte bei der Entwicklung einer Architektur
- Es ist ein iteratives Verfahren
- Es stützt sich auf die anderen Teile von TOGAF für Assets und Prozesse
- Es kann mit anderen Liefergegenständen aus anderen Frameworks verwendet werden
Hier ist die Übersicht des TOGAF ADM für jede Entwicklungsphase, wie in der folgenden Abbildung dargestellt:
- Mehr über TOGAF ADM Guide-through
- Mehr über Just-in-Time-TOGAF-Vorlagen
- Mehr über ArchiMate-Tools
- Probieren Sie Visual Paradigm KOSTENLOS aus
TOGAF-Einführungsreferenzen
- Was ist TOGAF?
- TOGAF ADM-Lernprogramm
- TOGAF 9.1 Framework – Ein umfassender Leitfaden
- TOGAF-Software für Unternehmensarchitektur
- Die beste TOGAF-Software
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский