IVS-Architektur-Vorgehensmodell: Unterschied zwischen den Versionen
| (2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 11: | Zeile 11: | ||
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert. | Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert. | ||
| − | |||
== TOGAF - ein Überblick == | == TOGAF - ein Überblick == | ||
| Zeile 84: | Zeile 83: | ||
Artefakte beschreiben Bausteine ('''Building blocks'''). Das sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. <span style="font-size:small"><span style="font-family: arial, helvetica, sans-serif"><span style="line-height: 107%">TOGAF stellt ein Metamodell bereit, welches die Zuordnung der Bausteine zu verschiedenen Bereichen der Unternehmensarchitektur ermöglicht.</span></span></span> | Artefakte beschreiben Bausteine ('''Building blocks'''). Das sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. <span style="font-size:small"><span style="font-family: arial, helvetica, sans-serif"><span style="line-height: 107%">TOGAF stellt ein Metamodell bereit, welches die Zuordnung der Bausteine zu verschiedenen Bereichen der Unternehmensarchitektur ermöglicht.</span></span></span> | ||
| − | Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, | + | Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, es werden z. B. in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B dann basierend auf den IVS-Rollen Prozesse beschrieben. |
[[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]] | [[File:TOGAFBausteine.png|thumb|center|300px|TOGAF Bausteine]] | ||
| Zeile 191: | Zeile 190: | ||
| style="width: 89.55px" | Projektspezifische Lösung | | style="width: 89.55px" | Projektspezifische Lösung | ||
|} | |} | ||
| + | |||
Aktuelle Version vom 13. Februar 2018, 15:14 Uhr
Inhaltsverzeichnis
Problemstellung
"Das The Open Group Architecture Framework (TOGAF) bietet einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen. Als operationelles Framework der Gruppe Government and Agency Frameworks bietet TOGAF mit der Architecture Development Method (ADM) unter anderem auch ein Vorgehensmodell zur Entwicklung von [Unternehmensarchitekturen]" (siehe hier TOGAF).
Aufgrund der weltweiten Verbreitung und Anerkennung als "das Modell" für die Entwicklung von Unternehmensarchitekturen eignen sich TOGAF und die ADM sehr gut als konzeptioneller Hintergrund auch für die Entwicklung von IVS-Architekturen. Allerdings ist TOGAF einerseits mehr auf die Entwicklung der Architektur eines einzelnen Unternehmens ausgerichtet und stellt andererseits viele Konzepte für Architekturaspekte bereit, die für IVS und IVS-Dienste keine Bedeutung haben. Für die Entwicklung einer IVS-Architektur, das heißt die Architektur von IVS-Diensten, an denen in der Regel mehrere Institutionen und Unternehmen beteiligt sind, erfolgte deshalb eine Anpassung (Tailoring) des TOGAF-Vorgehensmodells unter drei Gesichtspunkten:
- Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Architektur, um dieses für die Entwicklung von IVS-Architekturen nutzen zu können
- Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS-Architekturentwicklung und Darstellung in einem Wiki
- Entwicklung eines IVS-Architektur-Glossars und -Metamodells
Zum besseren Verständnis des für IVS-Architektur vorgenommenen Tailorings der ADM wird diese im Folgenden kurz erläutert.
TOGAF - ein Überblick
Das TOGAF ADM-Phasenmodell
TOGAF definiert mit der ADM (siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Unternehmensarchitekturen. Im Einzelnen werden mit der ADM folgende Phasen durchlaufen[1]:
- Preliminary Phase (Vorarbeiten)
- Hier werden die Einbindung zugrundeliegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt.
- Phase A - Architecture Vision (Architekturvision)
- Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt.
- Phase B - Business Architecture (Geschäftsarchitektur)
- Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden u.a. Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet.
- Phase C - Information and Systems Architectures (Informations- und System-Architektur)
- Hier werden für die Informations-/Datenarchitektur und für die Anwendungsarchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die konkreten Datenmodelle und Anwendungen verwendet.
- Phase D - Technology Architecture (Technologiearchitektur)
- Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden die benötigten Technologien für die Ausführung der Anwendungen und der darüberliegenden Prozesse beschrieben.
- In Phase E - Opportunities and Solutions (Möglichkeiten und Lösungen)
- Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation zum Soll-Zustand durchführen.
- Phase F - Migration Planning (Migrationsplanung)
- Hier wird die Überführung von Ist-Zustand in den Soll-Zustand geplant.
- Phase G - Implementation Governance (Steuerung und Überwachung der Implementierung)
- Hier wird die Implementierung in den Soll-Zustand überwacht.
- Phase H - Architecture Change Management (Änderungsmanagement)
- Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als Grundlage für einen evtl. nächsten Durchlauf des Prozesses dienen.
- Requirements Management (Anforderungsmanagement)
- Das Anforderungsmanagement treibt den ADM Prozess kontinuierlich an und steht deshalb im Zentrum des Prozesses.
Das TOGAF-ADM Schrittmodell
Gemäß TOGAF Version 9.1 ist jede Phase nochmals in einzelne Schritte (Steps) unterteilt, die im TOGAF-Handbuch genau erklärt sind. Damit wird generell ein methodisches und umfassendes Vorgehen bei der Entwicklung einer Unternehmensarchitektur sichergestellt. Ein Beispiel für die Vorbereitungsphase zeigt folgende Tabelle:
| Schritt | TOGAF-Vorgabe |
|---|---|
| 1 | Bestimmung des Wirkungsbereichs |
| 2 | Betroffene Organisationseinheiten |
| 3 | Sicherstellung von Steuerungs- und Unterstützungsframeworks |
| 4 | Definition und Aufbau eines Unternehmensarchitektur-Teams und einer Organisation |
| 5 | Identifizierung und Festlegung von Architekturprinzipien |
| 6 | Auswahl und organisationsspezifische Anpassung von Architekturframeworks |
| 7 | Implementierung von Architekturwerkzeugen |
Eine Besonderheit ist mit dem Schrittmodell der Phasen B, C und D verbunden (siehe auch Hinweise zum TOGAF Schrittmodell der Phasen B, C und D).
TOGAF Architecture Deliverables als Ergebnisse (Liefergegenstände) der Architekturarbeit
Das Vorgehen in Schritten mündet in sog. Architecture Deliverables als Ergebnis (Liefergegenstände) der Architekturarbeit. Dabei unterscheidet TOGAF folgende "Architecture Deliverables":
- Artefakte (im möglichen Format von Katalogen, Matrizen und Diagrammen) und
- Other Deliverables
Artefakte beschreiben Bausteine (Building blocks). Das sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. TOGAF stellt ein Metamodell bereit, welches die Zuordnung der Bausteine zu verschiedenen Bereichen der Unternehmensarchitektur ermöglicht.
Ein Architecture Deliverable ist das Ergebnis der Architekturarbeit. Bei der Durchführung der Arbeiten nach der ADM werden Deliverables als Output erzeugt. Diese Deliverables werden häufig in folgenden Schritten als Input verwendet und weiter konkretisiert, es werden z. B. in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B dann basierend auf den IVS-Rollen Prozesse beschrieben.
Unterschied zwischen Artefakten und Deliverables
In TOGAF wird zwischen Artefakten und anderen Deliverables unterscheiden. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich bzw. die einzelnen Bestandteile der Architektur beschreiben. Andere Deliverables beschreiben z. B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.
Artefakte sind entweder Kataloge, Matrizen oder Diagramme und bestehen aus den einzelnen Bausteinen.
- Ein Baustein ist z. B. eine einzelne Rolle. Der Rollenkatalog, der alle Rollen auflistet, ist ein mögliches Artefakt. Ein Prozessdiagramm mit Rollen als Swimlanes wäre ein weiteres mögliches Artefakt, das die Bausteine Prozess und Rolle kombiniert.
- Ein Katalog besteht immer nur aus einem Bausteintyp; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren.
TOGAF sieht eine Vielzahl an Artefakten vor (siehe Abbildung (schwarz-weiß)).
Im Los 1 IVS-Rahmenarchitektur werden sowohl Templates zur Beschreibung einzelner Bausteine als auch Templates für Artefakte entwickelt und für die IVS-Referenzarchitekturen bereitgestellt.
Das TOGAF-basierte Rahmenwerk für IVS-Architektur
Tailoring des TOGAF Phasen- und Schrittmodells
Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der Entwicklung einer IVS-Architektur anpassen zu können, wurde ein Tailoring-Modell entwickelt, das die Schritt-Tabellen der Phasen um Spalten wie folgt erweitert:
| Schritt | TOGAF | Tailoring IVS-Architektur | Anleitung | Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables | Empfehlung für IVS-Referenzarchitekturen | Empfehlung für IVS-Architekturen realer IVS-Dienste |
|---|---|---|---|---|---|---|
| 1 | Bestimmung des Wirkungsbereichs | Bestimmung des Wirkungsbereichs von IVS-Architektur | Wirkungsbereich von IVS-Architektur
|
Projektspezifische Lösung | Projektspezifische Lösung | Projektspezifische Lösung |
| 2 | Identifizierung der betroffenen Organisationseinheiten | Identifizierung von IVS-Architektur betroffener Institutionen/Unternehmen | Von IVS-Architektur betroffene Institutionen/Unternehmen und Rahmenbedingungen | Projektspezifische Lösung | Projektspezifische Lösung | Projektspezifische Lösung |
| 3 | Sicherstellung von Steuerungs- und Unterstützungsframeworks | Sicherstellung von Steuerungs- und Unterstützungsframeworks für IVS-Architektur | Steuerungs- und Unterstützungsframeworks für IVS-Architektur | Projektspezifische Lösung | Projektspezifische Lösung | Projektspezifische Lösung |
| 4 | Definition und Aufbau eines Unternehmensarchitektur-Teams und einer Organisation | Definition und Aufbau eines IVS-Architektur-Teams und einer Organisation |
Hinweise zur Bildung eines IVS-Architekturteams
|
Projektspezifische Lösung | Projektspezifische Lösung | Projektspezifische Lösung |
| 5 | Identifizierung und Festlegung von Architekturprinzipien | Identifizierung und Festlegung von IVS-Architekturprinzipien |
|
K: IVS-Architekturprinzipien | K: IVS-Architekturprinzipien für die IVS-Dienstekategorie (geerbt von der IVS-Rahmenarchitektur, erweitert für die IVS-Dienstekategorie) | K: IVS-Architekturprinzipien für den spezifischen IVS-Dienst (geerbt von der IVS-Dienstekategorie, erweitert für den spezifischen IVS-Dienst) |
| 6 | Auswahl und organisationsspezifische Anpassung von Architekturframeworks | Auswahl und Anpassung von IVS-Architekturframeworks | Nationale und internationale IVS-Architekturframworks | Projektspezifische Anpassung und Erweiterung | Projektspezifische Anpassung und Erweiterung | Projektspezifische Anpassung und Erweiterung |
| 7 | Implementierung von Architekturwerkzeugen | Implementierung von IVS-Architekturwerkzeugen | Vorschläge für IVS-Architekturwerkzeuge | Projektspezifische Lösung | Projektspezifische Lösung | Projektspezifische Lösung |
Das TOGAF-basierte Rahmenwerk als Ergebnis des Tailorings
Ergebnis des Tailorings des TOGAF ADM-Phasenmodells ist am Ende das TOGAF-basierte Rahmenwerk für IVS-Architektur. Es besteht aus der TOGAF ADM-Tailoringmethode für IVS-Architektur sowie gemäß der TOGAF ADM strukturierten Phasen und Schritten zur Entwicklung einer IVS-Architektur (siehe im Wiki-Navigationsbaum Menüpunkt "Phasen und Schritte zur Entwicklung einer IVS-Architektur").
Phasen und Schritte der IVS-Rahmenarchitektur 1.0
Für die Entwicklung der IVS-Rahmenarchitektur 1.0 wurde der Schwerpunkt auf die Architekturvision, die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).
TOGAF - ADM
Fokus IVS-Rahmenarchitektur 1.0
In der TOGAF Phase D erfolgt die Dokumentation des grundlegenden Aufbaus der IT-Systeme aus Hardware, Software und Kommunikationstechnologie. Diese Phase ist eine wichtige Phase für eine IVS-Architektur eines realen IVS-Dienstes. Jeder Akteur, der an einer IVS-Architektur eines realen IVS-Dienstes beteiligt ist, muss sich die Fragen nach der bestmöglichen technologischen Einbettung in die Unternehmensarchitektur seines Wirkungsbereichs stellen. Diese Entscheidungen können und sollen weder von der IVS-Rahmenarchitektur noch von einer IVS-Referenzarchitektur getroffen werden.
Für die TOGAF Phasen A bis C enthält die IVS-Rahmenarchitektur Vorgaben für die Entwicklung der entsprechenden Phasen der IVS-Referenzarchitekturen. Die IVS-Referenzarchitekturen enthalten wiederum die Beschreibung der Architekturphasen A bis C für die jeweiligen Domänen. Dort werden Vorgaben und Vorschläge für IVS-Architekturen realer IVS-Dienste entwickelt und beschrieben. Von dieser Vorgehensweise wird für die TOGAF Phasen E bis H abgewichen. Für die IVS-Referenzarchitekturen entfallen diese Phasen vollständig, da keine einheitlichen Vorgaben für IVS-Architekturen realer IVS-Dienste entwickelt werden können. Stattdessen müssen in jedem Projekt, in dem eine IVS-Architektur eines IVS-Dienstes erarbeitet wird, diese Phasen individuell ausgearbeitet werden. Für die IVS-Rahmenarchitektur ändert sich für die Phasen E bis H der Blickwinkel: Anstatt Vorgaben für die IVS-Referenzarchitekturen zu entwickeln, werden diese Phasen zusammengefasst und es wird die Vorgehensweise zur Umsetzung der IVS-Architekturen beschrieben.
Einen Überblick über das Tailoring der Phasen Vorbereitung sowie Phasen A, B und C (C1. und C.2) liefern die folgenden Grafiken:
Vorbereitungsphase
Phase A - IVS-Architekturvision
Phase B - IVS-Geschäftsarchitektur
Phase C.1 - IVS-Datenarchitektur
Phase C.2 - IVS-Anwendungsarchitektur
Literaturverzeichnis
- ↑ Schmid, Daniel (2013): ARCHITEKTURMANAGEMENT MIT TOGAF. Online verfügbar unter http://blog.itil.org/2013/01/allgemein/architekturmanagement-mit-togaf/, zuletzt geprüft am 14.11.2017.
