Los1: UAP1.2 TOGAF basiertes Rahmenwerk
Inhaltsverzeichnis
UAP 1.2 Aufgabenstellung
Da TOGAF ursprünglich für den Einsatz in einem Unternehmen entwickelt worden ist, macht die Tatsache, dass es im vorliegenden Projekt für die Entwicklung einer Rahmenarchitektur eingesetzt wird, eine Anpassung des TOGAF-Vorgehensmodells nötig. So waren vorrangige Ziele von Unterarbeitspaket 1.2
- Die Entwicklung eines generellen Modells zur Anpassung des TOGAF-Vorgehensmodells an die Aufgaben zur Erstellung einer IVS-Rahmenarchitektur und von IVS-Referenzarchitekturen
- Erarbeitung eines TOGAF basierten Rahmenwerks für die verschiedenen Phasen der IVS –Rahmenarchitekturentwicklung und Darstellung in einem Los-übergreifenden Wiki
- Die Entwicklung eines IVS-Architektur-Glossars und Metamodells
UAP 1.2 Anpassung des TOGAF-Vorgehensmodells
Das TOGAF ADM-Phasenmodell als Ausgangslage für IVS-Architektur
Die TOGAFTM Architecture Development Method (ADM; siehe nebenstehendes Bild) ist als eine Methode zur Entwicklung von Geschäftsarchitekturen eines einzelnen Unternehmens definiert und entwickelt worden. Im vorliegenden Projekt soll sie für die Entwicklung der IVS-Rahmenarchitektur und von IVS-Referenzarchitekturen verwendet werden und muss somit an die Anforderungen der Entwicklung von IVS-Architekturen angepasst werden.
Im Einzelnen werden mit der TOGAF-ADM folgende Phasen durchlaufen:
- Vorarbeiten
- A – Architekturvision
- B – Geschäftsarchitektur
- C – Informationssystem-Architektur
- D – Technologiearchitektur
- E – Möglichkeiten und Lösungen
- F – Migrationsplanung
- G – Governance
- H – Change Management
- Requirements Management
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 |
Das Vorgehen in Schritten mündet in sog. Architecture Deliverables als Ergebnis 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. Wie folgende Abbildung zeigt,ordnet TOGAF selbst die Bausteine in verschiedene Ebenen ein.
TOGAF Architecture Deliverables als Ergebnisse der Archtekturarbeit
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.
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.
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 and die Anforderung der Entwicklung einer IVS-Archtektur anpassen zu können, wurde ein Tailoringmodell enwtwickelt, das die Schritt-Tabellen der Phasen um drei Spalten wie folgt erweitert:
| Schritt | TOGAF-Vorgabe | Tailoring IVS-Rahmenarchitektur | Anleitung | Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables |
|---|
Im Ergebnis ensteht durch die Erweiterung das Modell einer TOGAF-Schritt-Tabelle, die an die Anforderungen der IVS-Architekturentwicklung angepasst werden kann. Debei haben die einzelnen Spaltenüberschriften der Tabelle folgende Bedeutung:
- Schritt: fortlaufende Nummer des Schrittes in der Phase
- TOGAF: Titel des Schrittes (gleichzeitig Link zum TOGAF-Erläuterungstext)
- Tailoring IVS-Rahmenarchitektur : Titel des Schrittes, interpretiert für die Aufagbenstellung der Entwicklung einer IVS-Architektur
- Anleitung: Links zu Seiten, mit denen der Schritt für die Entwicklung einer IVS-Architektur inhaltlich interpretiert und erläutert wird, evtl. ergänzt umd Tempaltes für Bausteine, aus denen die unter "Artefakte" genannten "Delverables" bestehen.
- Artefakte: Deliverables, die im Rahmen des Schrittes erstellt werden und auf der Hauptseite des WIKI unter Architecture Deliverables abgelegt werden müssen. Gemäß TOGAF kann es sich dabei um Artefakte (Kataloge, Matritzen, Diagramme) oder Other Deliverables handeln (siehe auch Präsentation Vorab-Workshop).
Das Ergebnis einer an die IVS-Architekturentwicklung angepassten Tabelle zeigt folgendes Beispiel:
| Schritt | TOGAF | Tailoring IVS-Rahmenarchitektur | Anleitung | Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables |
|---|---|---|---|---|
| 1 | Bestimmung des Wirkungsbereichs | Bestimmung der IVS-Dömäne, in denen spezifisches Architekturwissen zum Betrachtungsgegenstand IVS angewendet wird | IVS-Dömänen-Konzept | O:IVS-Domäne |
| 2 | Betroffene Organisationseinheiten | Bestimmung der Organisation, die für IVS-Domäne relevant sind | IVS-Wertschöpfungs- und Rollenkonzept | M:IVS-Rollen Matrix |
| 3 | Sicherstellung von Steuerungs- und Unterstützungsframeworks | Keine Vorgaben | Projektspezifische Anleitung | Projektspezifische Lösung |
| 4 | Definition und Aufbau eines Unternehmensarchitektur-Teams und einer Organisation | Definition und Aufbau eines IVS-Architektur-Teams und einer Organisation |
Modell für ein IVS-Architekturteam und für eine Organisation Grundlagen der Zusammenarbeit |
Projektspezifische Lösung |
| 5 | Identifizierung und Festlegung von Architekturprinzipien | Identifizierung und Festlegung von IVS-Architekturprinzipien | K: IVS-Architekturprinzipien | |
| 6 | Auswahl und organisationsspezifische Anpassung von Architekturframeworks | Auswahl und organisationsspezifische Anpassung von IVS-Architekturframeworks | Entscheidung und Anleitung erfolgen am Ende des Projekts!! | |
| 7 | Implementierung von Architekturwerkzeugen | Implementierung von IVS-Architekturwerkzeugen | Vorschläge IVS-Architekturwerkzeuge | Projektspezifische Lösung |
UAP 1.2 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
- der TOGAF ADM-Tayloringmethode für IVS-Architektur sowie der nach den TOGAF ADM-Phasen strukturierten Ablage der getaylorten Steps im Wiki-Navigationsbaum
- der nach den TOGAF ADM-Phasen strukturierten Ablage für Templates für IVS-Architekturbausteine auf der Wiki-Hauptseite rechts
- der nach den TOGAF ADM-Phasen strukturierten Ablage für Deliverables eines Architekturprojekts auf der Wiki-Hauptseite links
UAP 1.2 IVS-Architektur-Glossar und Metamodell
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 folgende Abbildung zeigt ein Beispiel für die Modellierungsebenen anhand 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.
