Nutzung von TOGAF für die Entwicklung der IVS-Architekturen

Architekturentwicklung (ADM) sowie Richtlinien und Techniken

Einführung

TOGAF (TOGAF-Webseite) ist ursprünglich für den Einsatz in einem Unternehmen entwickelt worden. Die Tastsache, dass es nun für die Entwicklung einer Rahmenarchitektur eingesetzt wird, macht eine Anpassung des TOGAF-Vorgehensmodells nötig. In diesem Arbeitspaket wird geklärt, wie dieses vor sich geht. Es ist Teil der Vorarbeit für die Anwendung von TOGAF. Im Folgenden werden erste Ansätze zur Anpassung von TOGAF beschrieben, die im Rahmen des Vorhabens weiter konkretisiert und umgesetzt werden müssen. Generell werden gemäß TOGAF im ersten Projekt-Schritt Szenarien definiert, die umgesetzt werden können. Aus diesen Szenarien ergeben sich einerseits Capabilities, die zur Umsetzung notwendig sind, und andererseits Anforderungen (Requirements), die erfüllt werden müssen. Basierend auf den definierten High-Level Capabilities werden dann sogenannte Capability Architectures entworfen. Capabilities sind grundsätzliche Fähigkeiten bestehend aus Prozessen, Personen und IT, die langfristig nötig sind, um den Informationsaustausch zwischen den beteiligten Stakeholdern zu ermöglichen und somit zu intelligenten Verkehrssystemen zu gelangen. Zwischen den Fähigkeiten können Abhängigkeiten bestehen, gleichzeitig strukturieren sie aber die weitere Entwicklung der Rahmenarchitektur. Für jede High-Level-Capability wird die TOGAF ADM durchlaufen.

Zunächst wird die ADM von den Los 1 - Projektpartnern intern angewendet, um die Version 0.9 der IVS-Rahmenarchitektur zu erstellen. Auch währenddessen wird bereits erstes Feedback von den Bearbeitern der IVS-Referenzarchitekten eingeholt. Für die Version 1.0 werden die Ergebnisse aus den Workshops mit einbezogen und die IVS-Rahmenarchitektur wird entsprechend angepasst. Im Rahmen der TOGAF ADM werden zur Entwicklung der Rahmenarchitektur 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

Vorarbeiten

In der Phase der Vorarbeiten werden für eine spezifische High-Level-Capability die betroffenen Organisationstypen mit ihren Interessen und Zielen identifiziert (z.B. Reisende, öffentliche und private Mobilitätsanbieter, Service-Provider, u.a.). Zur Findung und Generierung von High-Level-Capabilities können beispielsweise die Lose 2-4 herangezogen werden. Bestehende Frameworks und Vorgaben für diesen Bereich werden recherchiert und eingebracht, das Wiki wird mit den Arbeitsergebnissen befüllt und damit werden die Ergebnisse den anderen Losen zur Verfügung gestellt.

Phase A – Architekturvision

In Phase A – Architekturvision werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.

Phase B – Geschäftsarchitektur

In Phase B – Geschäftsarchitektur werden relevante Prozesse, aber auch Rollen, Ziele, und Organisationen identifiziert. Die Rahmenarchitektur macht hier bewusst Soll-Vorgaben für eine Implementierung zur Sicherstellung der Interoperabilität. Dabei entstehenden zum einen Vorgaben, zum anderen aber auch Muster (ABBs), die von den Referenzarchitekturen später aufgegriffen und konkretisiert werden können. Solche Muster können z.B. Prozessmodelle oder Stakeholder-Definitionen sein. Die Anforderungen an die Interoperabilität werden detailliert.

Phase C – Informationssystem-Architektur

In Phase C – Informationssystem-Architektur werden die notwendigen Daten und Anwendungen spezifiziert.

• Dabei kommen Datenmodelle zum Einsatz, wobei auf bestehende Vorarbeiten zurückgegriffen werden kann (siehe Kapitel 2). Der Verfügbarkeit und dem Austausch von Daten wird hier voraussichtlich eine Schlüsselrolle zukommen: Mithilfe von TOGAF können an dieser Stelle Lücken in der Datenversorgung aufgedeckt werden.
• Im Bereich der Anwendungen werden Anforderungen erhoben, denen die Anwendungssysteme entsprechen sollten, bspw. Technische oder Interoperabilitäts-Anforderungen.

Phase D – Technologie-Architektur

In Phase D – Technologie-Architektur werden Technologien ausgewählt und vorgeschlagen, die zur späteren Umsetzung im Rahmen der Referenz- und echten Architekturen herangezogen werden können, z.B. Web-Services, XML oder Service-Orientierte-Architekturen. Hinweis: Fragen der Architektur von Datensicherheit und Datenschutz können im Projekt allenfalls identifiziert, aber nicht bearbeitet werden. Wie die Erfahrungen im C-ITS-Eurokorridor zeigen, ist das mit erheblichen Aufwänden verbunden, die das vorliegende Budget sprengen würde.

Phase E –Möglichkeiten und Lösungen

Phase E –Möglichkeiten und Lösungen können alternative Lösungsansätze und Architekturbausteine diskutiert und bewertet werden, um im Anschluss möglichst wenige, dafür aber konkrete Empfehlungen zu geben.

Phase F – Migrationsplanung

Die Phase F – Migrationsplanung kommt auf Ebene der Rahmenarchitektur voraussichtlich nicht zum Tragen, da die erarbeiteten Architekturbausteine nicht realisiert werden.

G – Governance

Phase G – Governance beinhaltet das Erfassen von Feedback durch Reviews und Workshops mit den Losen 2-4, die Referenzarchitekturen entwerfen. Das Feedback wird analysiert und bei Bedarf werden die Vorgaben der Rahmenarchitektur auf Basis des Feedbacks angepasst.

Phase H – Change Management

Durch Phase H – Change Management werden Vorschläge erarbeitet, die der langfristigen Pflege und Weiterentwicklung der Rahmen- und Referenzarchitekturen dienen.

Requirements Management

Das Requirements Management nimmt alle Anforderungen auf, die sich zum einen aus den Szenarien, aber auch aus den anderen Ebenen ergeben. Diese Anforderungen werden im Wiki dokumentiert und so auch den anderen Losen zur Verfügung gestellt, damit diese sie bei der Entwicklung der Referenzarchitekturen beachten können. Zu den Anforderungen gehören auch Sicherheits-, Datenschutzbezogene- sowie weitere gesetzliche Anforderungen. Diese werden soweit wie möglich erfasst und dokumentiert und bei der Entwicklung der Referenzarchitektur beachtet. Anforderungen an die Interoperabilität können nach TOGAF in Form von Matrizen auf Ebene der Stakeholder und der Systeme definiert werden.

Weitere relevante Bestandteile von TOGAF

TOGAF bietet neben der Architecture Development Method - ADM weitere für das Vorhaben relevante Modelle und Inhalte. Zu Beginn des Projekts muss geklärt werden, welches dieser Modelle und Inhalte für die IVS-Architekturen Relevanz haben.

Capability-based Planning

TOGAF schlägt ein Vorgehen basierend auf Capabilites vor. Dies ermöglicht es, den Mehrwert der Lösung im Fokus zu halten und sich auf das Wesentliche zu konzentrieren. Capabilities bestehen dabei aus Mensch, Prozess und IKT und finden sich über die verschiedenen Phasen und Ebenen der Architektur durchgehend wieder.

Architecture Repository

Die Ergebnisse der ADM (z.B: ABBs) werden in einem Repository abgelegt und so den Losen 2-4 zugänglich gemacht. Als Architecture Repository wird ein Wiki dienen.

Werkzeuge-Unterstützung

Am Markt sind verschiedene TOGAF-Werkzeuge verfügbar. Im Fall, dass Modelle erstellt werden, kann das Tool "Enterprise Architect" eingesetzt werden. Die damit generierten Modelle können anschließend in anderen Formaten (xmi, pdf, jpeg) an die Lose 2-4 weitergereicht werden. Die Weitergabe erfolgt über das Wiki.

Enterprise Continuum

Das Enterprise Continuum wird als Inhaltsverzeichnis zum Architecture Repository erstellt. Es besteht aus Einträgen und Querverweisen im Wiki.

Content Metamodel (Inhaltsmodell)

Das vorgegebene Content Metamodell aus TOGAF wird beachtet und bei Bedarf erweitert.

Architecture Building Blocks (ABBs)

Soweit möglich, wird die Rahmenarchitektur entweder Vorgaben für die Gestaltung von ABBs auf allen Ebenen machen oder bereits ABBs erstellen. Zur Definition von ABBs gehören folgende Aspekte:

Funktionen und Attribute

Schnittstellen

Kompatibilität und Beziehungen mit/zu anderen Bausteinen (ABBs)

Abhängige Bausteine mit notwendigen Funktionalitäten und benannten Schnittstellen

Verbindung zum Business/ zu den organisatorischen Einheiten und Richtlinien

Beispiele auf der Ebene der Geschäftsarchitektur sind

Architekturbausteine: Organisation/Akteur, Leitbild/Zweck/Ziel, Rolle, Service/Funktion, Ort, Prozess/Ereignis/Steuerung/Produkt, Vertrag/Messung

Matrizen: Interaktionsmatrix, Akteur/Rollen-Matrix

Diagramme: Steckbrief, Business Service, Funktionale Dekomposition, Zweck/Ziel/Service, Use-Case, Organisationelle Dekomposition, Prozesse, Ereignisse

Beispiele auf Ebene der Informationssystemarchitektur sind

Datenmodelle und -beschreibungen

Modelle zur Interaktion und Abhängigkeit (Datenaustausch) zwischen Anwendungssystemen

SBBs (Solution Building Blocks)

konkretisieren die ABBs in Lösungen und werden auf Ebene der Referenz- und der konkreten Architekturen verwendet werden.