Diskussion:IVS-Architektur-Vorgehensmodell

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen

Entwicklung eines TOGAF-basierten IVS-Architektur Vorgensmodells

Problemstellung

Da TOGAF ursprünglich für den Einsatz in einem Unternehmen (bzw. Wertschöpfungsketten/-netzwerken eines Unternehmens) entwickelt worden ist, macht die Tatsache, dass es im vorliegenden Projekt für die Entwicklung einer IVS-Architektur (bzw. von IVS-Wertschöpfungsketten/-netzwerken) eingesetzt wird, eine Anpassung des TOGAF-Vorgehensmodells nötig. Dabei waren vorrangige Ziele:

  • Die 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 Los-übergreifenden Wiki
  • Die Entwicklung eines IVS-Architektur-Glossars und -Metamodells

Anpassung des TOGAF-Vorgehensmodells zur Nutzung für IVS-Architektur

Das TOGAF ADM-Phasenmodell als Ausgangslage für IVS-Architektur

TOGAF ADM

TOGAF definiert mit der TOGAFTM Architecture Development Method (ADM; siehe nebenstehendes Bild) einen Prozess zur Entwicklung von Geschäftsarchitekturen eines Unternehmens. Im Einzelnen werden mit der TOGAF-ADM folgende Phasen durchlaufen (siehe [1]):

Preliminary Phase (Vorarbeiten)
Hier wird die Einbindung zugrundezulegender Modelle geklärt, Modell-Anpassungen definiert sowie wichtige Prinzipien für die Architekturentwicklung festgelegt.
Phase A - Architekture Vision (Architekturvision)
Hier werden die Ziele der Architekturentwicklung und die daran Beteiligten festgelegt.
Phasen 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 Geschäftsprozessmodelle, Use-Case- und Klassendiagramme verwendet.
Phasen 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.
Phasen 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 konkreten Hardwaresysteme 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 Implementation 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 und steht deshalb im Zentrum des Prozesses.

Mit der Entwicklung der IVS-Rahmenarchitektur wird TOGAF-ADM zur Grundlage für das Vorgehensmodell zur Entwicklung einer IVS-Architektur, wird allerdings an die Anforderungen der Entwicklung von IVS-Architekturen angepasst.

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 Architektur 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 Besonderrheit 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 (Bulding blocks). Dass sind die Elemente, aus denen am Ende die eigentliche Architektur aufgebaut ist. TOGAF ordnet Bausteine in verschiedene Ebenen ein.

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. Z.B. werden in der Phase A relevante Stakeholder mit dem IVS-Rollenkonzept identifiziert und in der Phase B werden basierend auf diesen Rollen dann Prozesse beschrieben.


Unterschied zwischen Artefakten und Deliverables

Es wird in TOGAF unterschieden zwischen Artefakten und anderen Devlierables. Die Unterscheidung kommt daher, dass Artefakte stets die Architektur an sich beschreiben bzw. die einzelnen Bestandteile der Architektur. Andere Deliverables beschreiben z.B. die Umgebung der Architektur oder die Projektstruktur des Architekturprojekts.

Mögliche Artefakte zur Beschreibung einer Architektur nach TOGAF

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 Typ Baustein; Matrizen bestehen typischerweise aus zwei verschiedenen Bausteintypen und Diagramme aus mehreren.

TOGAF sieht eine Vielzahl an Artefakten vor, siehe nebenstehende Abbildung.

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.


Tayloring des TOGAF ADM-Phasenmodells als Grundlage für IVS-Architekturarbeit

Um das TOGAF-Modell für jede Phase und jeden einzelnen Schritt an die Anforderung der iEntwicklung 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-Refenzarchitekturen Empfehlung für IVS-Architekturen realer IVS-Dienste
1 Bestimmung des Wirkungsbereichs Bestimmung des Wirkungsbereichs von IVS-Architektur Wirkungsbereich von IVS-Architektur
Hintergrundinformationen und Techniken
Beispiel IVS-Rahmenarchitektur
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

Hintergrundinformationen und Techniken
Modell, Grundlage für Nachvollziehbarkeit
Glossar, Grundlage für gemeinsames Verstehen
Projektspezifische Lösung Projektspezifische Lösung Projektspezifische Lösung
5 Identifizierung und Festlegung von Architekturprinzipien Identifizierung und Festlegung von IVS-Architekturprinzipien

IVS-Architektur-Prinzipien

Hintergrundinformationen und Techniken
Beispiele für Architekturprinzipien aus dem IKT-Bereich
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 für IVS-Architektur und seine Darstellung im Wiki

Ergebnis des Taylorings des TOGAF ADM-Phasenmodells ist am Ende das TOGAF-basierte Rahmenwerk für IVS-Architektur. Es besteht im Einzelnen aus

IVS-Architektur-Glossar und Metamodell

Motivation und methodische Grundlagen

Um im Projekt zwischen den Bearbeitern von Los 1 bis 4 von Anfang an babylonischen Sprachverhältnissen begegnen zu können, muss der Sprache bzw. der Begriffsbildung und Begriffsverwendung ein hoher Stellenwert eingeräumt werden. Dazu wird ein Glossar aufgebaut, in dem die wesentlichen Begriffen der IVS beschrieben werden.

Um die Begriffe auf Ebene der IVS-Rahmenarchitektur adäquat beschreiben zu können, muss ein passendes Metamodell ausgewählt werden, in dem eine solche Beschreibung möglich ist. Die Meta Object Facility (MOF) ist eine Spezifikation der Object Management Group (OMG), die zur abstrakten Beschreibung beliebiger Modelle, also auch für das Glossar-Metamodell geeignet wäre. Unter anderem ist die Unified Modeling Language (UML) in MOF modelliert.

Die MOF unterscheidet vier Ebenen der Modellierung M0 - M3. Die nebenstehende Abbildung zeigt ein Beispiel für die Modellierungsebenen anhand eines Datenüberlassungsvertrags:

Meta-Modelle am Beispiel eines Datenüberlassungsvertrags

Die vier verschiedenen Ebenen haben die folgende Bedeutung:

M0 – Realität
Auf dieser Ebene ist die Realität angesiedelt. Im Beispiel ist dies der eigentliche Datenüberlassungsvertrag.
M1 – Modell
Auf dieser Ebene ist in einem Benutzermodell eine Beschreibung der Realität dargestellt. Dies können z.B. physikalische oder logische Daten- und Prozessmodelle sein. Im Beispiel ist diese eine Klasse, in der Datenüberlassungsverträge modelliert werden und eine Objektinstanz, in der ein bestimmter Datenüberlassungsvertrag beschrieben wird.
M2 – Meta-Modell
Auf der Meta-Modell-Ebene wird festgelegt, wie Modelle aufgebaut sind. Das können z.B. Festlegungen sein, welche Attribute in welcher Klasse vorhanden sein müssen. Im Beispiel ist dies eine Festlegung, dass die Klasse „Vertrag“ als Klasse, die Attribute der Klasse „Vertrag“ als Attribut und die Objektinstanz „detektorDatenNRW“ als Instanz modelliert werden.
M3 – Meta-Meta-Modell
Die Meta-Meta-Modelle sind auf einer abstrakten Ebene, in der beschrieben wird, wie Meta-Modelle definiert werden. Die Definition der M3-Ebene erfolgt mit den Mitteln der M3-Ebene selbst, dies stellt den Abschluss einer sonst unendlichen Metaisierung dar.

Die vier Ebenen der MOF eignen sich, um in gewisser Weise die Architekturebenen zu beschreiben. Auf der Ebene M0 sind dabei die realen Systeme angesiedelt, die Ebene M1 enthält die Systemarchitekturen, die Ebene M2 enthält die Referenzarchitekturen als Meta-Ebene zu den Systemarchitekturen und die Ebene M3 ist dabei die IVS-Rahmenarchitektur, die wiederum beschreibt, wie Referenzarchitekturen aufzubauen sind.

Für die IVS-Rahmenarchitektur bedeutet das, dass die Beschreibung auf den Meta-Ebenen M1 - M3 stattfinden wird. Die Sprache UML ist geeignet, um die Ebenen M1 - M3 zu beschreiben. Aus diesem Grund wird vorgeschlagen, zusätzlich zu den natürlichsprachlichen Beschreibungen, ausgewählte Beschreibungen im Glossar in UML vorzunehmen. Bei dieser Beschreibung werden die zu definierenden Begriffe als UML-Klassen, Eigenschaften dieser Begriffe als Attribute der Klassen, Beziehungen zwischen den Begriffen als Konnektoren und Verallgemeinerungen von Begriffen als Generalisierung modelliert. Der Vorteil einer Beschreibung in UML gegenüber einer formlosen, natürlichsprachlichen Beschreibung liegt vor allem darin, dass Eigenschaften, Beziehungen, Verallgemeinerung bzw. Spezialisierungen einheitlich und in grafischer Form gut lesbar beschrieben werden können. Dabei muss nicht auf eine natürlichsprachliche Beschreibung verzichtet werden. Zu allen oben genannten UML-Elementen (Klassen, Attribute, Konnektoren, Generalisierungen) können Dokumentationen hinterlegt werden.

Aufbau des IVS-Glossars

Das Glossar der IVS-Rahmenarchitektur besteht insgesamt aus drei seperaten Bestandteilen:

Das Glossar für allgemeine Begriffe aus Verkehr, Transport und Mobilität wird parallel in deutsch und englisch in einer Wiki-Tabelle gepflegt und ist wie folgt aufgebaut:

Begriff Referenz Beschreibung Term Reference Definition

Die Spalten der Tabelle haben die folgende Bedeutung:

  • Begriff: Begriff, der im Glossar beschrieben wird
  • Referenz: Verweis auf die Quelle, aus der die deutsche Beschreibung des Begriffs entnommen wurde
  • Beschreibung: Beschreibung des Begriffs in deutsch
  • Term: Englische Übersetzung des Begriffs
  • Reference: Verweis auf die Quelle, aus der die englische Beschreibung des Begriffs entnommen wurde
  • Definition: Beschreibung des Begriffs in englisch

Das IVS-Glossar für die IVS-Rahmenarchitektur enthält Begriffe, die für die Rahmenarchitektur und für alle Referenzarchitekturen relevant sind. Die Referenzarchitekturen sollen eigene Glossare mit der oben beschriebenen Struktur anlegen, in denen Begriffe, die speziell für die jeweilige Referenzarchitektur relevant sind, aufgenommen und beschrieben werden.

Phasen und Schritte der IVS-Rahmenarchitektur 1.0

Vorbemerkung

Die TOGAFTM Architecture Development Method (ADM; siehe Bild) ist als eine Methode zur Entwicklung von Geschäftsarchitekturen eines einzelnen Unternehmens definiert und entwickelt worden.

Für die Entwicklung einer IVS-Architektur ist sie an die entsprechenden Anforderungen angepasst worden (Tayloring). Unter Zugrundelegung des TOGAF-basierten Rahmenwerks für IVS-Architektur wurde mit der IVS-Rahmenarchitektur 0.9 der Schwerpunkt auf die Geschäfts- und Informationssystemarchitektur gelegt (TOGAF Phasen A bis C).

Abgrenzung IVS-Rahmenarchitektur Version 0.9 gegen Version 1.0

Von der IVS-Rahmenarchitektur 0.9 nicht abgedeckte Phasen sind somit:

  • D – Technologiearchitektur
  • E – Möglichkeiten und Lösungen
  • F – Migrationsplanung
  • G – Governance
  • H – Change Management

Diese sind der Gegenstand der IVS-Rahmenarchitektur 1.0.

Tayloring der TOGAF-ADM Phasen für IVS-Architektur

Einen Überblick über das Tayloring der Phasen Vorbereitung und Phasen A, B und C (C1. und C.2) liefern die folgenden Grafiken:


<< Zurück zur Hauptseite



<< Zurück zur Hauptseite