Fachmodellierung für Service-Orientierte Architekturen
Wolfgang Glock1, Harald Störrle1,2
1)mgm technology partners GmbH Frankfurter Ring 105a
80807 München wolfgang.glock@mgm-tp.com
2)Universität München Oettingerstr. 68 80538 München Harald.Stoerrle@pst.ifi.lmu.de
Abstract: Dieser Praxisbericht stellt ein Fachmodell-getriebenes Vorgehen zur Innovation großer Anwendungslandschaften in der öffentlichen Verwaltung vor.
Innovation ist dabei die stufenweise Ablösung bestehender, meist host-basierter Anwendungen durch eine moderne Lösung auf Basis einer Service-orientierte Architektur, wobei Alt- und Neusystem über Zeiträume von Jahren parallel betrieben werden.
1 Einleitung
Föderale Organisationen haben häufig einen umfangreichen, organisch gewachsenen Bestand an Anwendungen und komplexe, heterogenen Anwendungslandschaften. Unter diesen Rahmenbedingungen sind Wartung und Erneuerung extrem schwierig und aufwändig. Die föderale, oft von Fusionen bzw. Übernahmen geprägte Struktur der Organisation macht eine Vereinheitlichung der Plattformen und Applikationen noch dringlicher, und noch schwieriger. Aktuelle Projektvorhaben Organisationen dieser Art haben daher oft das Ziel, im Rahmen einer SOA-Strategie die vorhandene, Host-basierte Anwendungslandschaft zu innovieren und damit vereinheitlichte Geschäftprozesse auf Basis dezentral gefertigter Services und Prozesse bereitzustellen. Vorhandene System- funktionalität sollen dabei durch Service-Schnittstellen genutzt und dadurch getätigte Investitionen der Vergangenheit gesichert werden. In diesem Paper berichten wir über unsere Erfahrungen unter den genannten Randbedingungen.
2 Ansatz
In einem sogenannten Referenzprojekt werden dazu am Beispiel eines Mustergeschäfts- prozesses der Nachweis erbracht, dass eine SOA aus Sicht der Fachseite, IT- Entwicklung und auch des Betriebs geeignet ist, die organisatorischen und geschäfts- relevanten Rahmenbedingungen erfolgreich zu unterstützen.
Diese Vorarbeiten sind für die Planung eines Großvorhabens essentiell. Sie erlauben dem Projekt und der Organisation, Erfahrungen mit dem Projektvorgehen, den Methoden, Techniken und Werkzeugen in einer SOA zu sammeln, aber gleichzeitig das mit diesem Lerneffekt verbundene Risiko zu kontrollieren.
92
3 Projektvorgehen
Dem Gesamtvorhaben liegt ein iteratives, evolutionäres Vorgehen zugrunde. In einem ersten Schritt wird eine initiale Strukturierung des Gesamtvorhabens vorgenommen, um die identifizierten Themenbereiche nach einem einheitlichen Schema bearbeiten zu können. Die Ergebnisse dieses wichtigen Schritts fließen dabei in einen zentralen Modellbestand ein und beeinflussen dabei auch bereits erarbeitete Ergebnisse (Feedback-Zyklen). Somit entstehen erste Bausteine einer neuen Anwendungslandschaft sukzessive und werden in Koexistenz mit bestehenden Anwendungen betrieben.
Die folgende Grafik stellt die grundsätzlichen Elemente unserer Vorgehens zur Umsetz- ung eines SOA-Vorhabens dar.
Umsetzungs- einheiten (Afo)
Abbildung fachliches Design auf tech- nisches Servicemodell
Integration und Test Betrieb
Modellbestand
Fachliches Design
Umsetzungs- einheiten (F)
Technisches Design und Realisierung
Anforderungs- analyse Initiale
Strukturierung
Umsetzungs- einheiten (T)
Anwendungs- komponente Anwendungs-
system
Abbildung 1: Vorgehen in SOA-Projekten
Basierend auf einem werkzeuggestützten Anforderungsmanagement mit der Beschreib- ung funktionaler und nicht-funktionaler Eigenschaften der zukünftigen Anwendungs- landschaft, erfolgt die Fachmodellierung, also die Beschreibung von Facharchitektur, Geschäftsprozessen und fachlichen Diensten. Hierzu verwenden wir einen vereinfachten Auszug der UML, die um domänenspezifische Elemente erweitert wurde. Diese Sprache ist in einem UML-Profil zusammengefasst. Um den bei der Fachmodellierung beteiligten Experten ein angemessenes, nicht überzogenes Instrument zur Darstellung der fachlichen Inhalte zu geben, beschränken wir uns auf ausgewählte Notationen der UML, insbesondere vereinfachte Aktivitätsdiagramme, Montagediagramme, Anwendungsfalldiagramme und einfache Klassendiagramme. Betrachtet werden sowohl statische Strukturen der Anwendungen, die fachlichen Domänen, Schnittstellen und Informationen, als auch die dynamischen Aspekte in Form von Geschäftsprozessen und Service-Modellen. Diese Notationen werden durch Methoden zur Modellierung der Benutzeroberfläche u.ä. ergänzt.
93
Folgende Grundprinzipien zur Arbeitsweise haben sich dabei bewährt und gelten auch unabhängig von einer SOA-Strategie.
• Eine intensive Vorbereitungsphase mit der Durchführung eines Referenz- projekts und der Strukturierung des Gesamtvorhabens als Programm
• Eine offene Kommunikation und Informationsaustausch zwischen Fachseite und IT-Umsetzung
• Qualitätssicherungsmaßnahmen und Feedback-Zyklen zum Beispiel durch den Einsatz fachlicher Prototypen
• Ein Projekt-begleitendes, kritisches Prüfen der Arbeitsweisen und Justierung der Methoden
4 Sichtweisen auf eine SOA
In vielen Projekten fehlt eine gemeinsame Sichtweise von Fachseite, Entwicklung und Betrieb (letztere beide werden manchmal als „Technik“ zusammengefasst).
Erfahrungsgemäß unterscheiden sich aber die grundsätzlichen Herangehensweisen dieser Stakeholder, was sich oft in uneinheitliche Sichtweise ausdrückt oder durch häufige Missverständnisse noch verschlimmert wird. So ist der vielbeschworene „Gap“ zwischen Fachseite und Technik vorprogrammiert. Die zentralen Begriff „Geschäftprozess“ und
„Dienst“ in einer SOA verbessern diese Situation erheblich. Wichtig ist es, einen Dienst als gemeinsame Metapher und damit als Kommunikationsbasis zu begreifen, die aus Sicht der Geschäftsprozesse, der Realisierung und der Bereitstellung der Anwendungssysteme den Dreh- und Angelpunkt einer SOA-Strategie bildet.
Abbildung 2: Dienst („Service“) als Metapher
94
Dieser gemeinsame Begriff kann einerseits für die durchgängige und integrative Steuer- ung von Entwicklungsprozessen genutzt werden (Service als Inkrement und Deliver- able). Andererseits können Services zur nachvollziehbaren und handhabbaren Struktur- ierung einzelner Applikationen dienen (Service als Einheit der Versionierung und Inte- gration). Diesen Zusammenhang stellt obige Grafik anschaulich dar.
5 Einsatzkontext
Seit Oktober 2005 treten alle deutschen Rentenversicherungsträger unter dem gemein- samen Dach „Deutsche Rentenversicherung“ (DRV) auf. Damit ist die Deutsche Renten- versicherung europaweit der größte gesetzliche Rentenversicherer. Nach der Organi- sationsreform der Deutschen Rentenversicherung sollen die existierenden, unter- schiedlichen Verwaltungsverfahren bundesweit in eine einheitliche Anwendungsland- schaft überführt werden.
Als technische Umsetzungsstrategie für die Umstrukturierung der fachlichen Abläufe entschied sich die DRV für eine Service-orientierte Architektur (SOA). Anhand dieses Praxisbeispieles werden Aspekte der hier skizzierten Methoden mit Schwerpunkt auf Fachmodellierung gezeigt.
Literaturverzeichnis
[Arsa2004] Arsanjani, A.: Service-Oriented Modeling and Architecture, verfügbar unter http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/
November 2004 siehe auch
http://www.ibm.com/developerworks/rational/downloads/06/rmc_soma/.
[BMRS1998] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern- Orientierte Software-Architektur. Addison-Wesley, 1998.
[Gimn2006] Gimnich, R.: SOA-Migration – Approaches and Experience. In: Kaiser, U., Kroha, P., Winter, A. (Hrsg.): Proc. Ws. Reengineering Prozesse (RePro’06), Softwaretechnik- Trends 1(27)2006.
[GlSt2006] Glock, W.; Störrle, H.: Ein Erfahrungsbericht über die agile Steuerung eines Großprojektes durch fachliche Anforderungen. In: Softwaretechnik-Trends, 1 (2007), Fachgruppentreffen der GI-FG 2.1.6 Requirements Engineering 2006, Gesellschaft für Informatik.
[Stör1999] Störrle, H.: A different notion of components, In: Schürr, A., Hofmann, P. (Hrsg.):
Proc. Ws. Object-Oriented Modeling of Embedded and Realtime Systems (OMER’99), Universität der Bundeswehr (München), Fakultät für Informatik, Bericht Nr. 1999-01.
[Stör2001] Störrle, H.: Models of Software Architecture. Book on Demand, 2001.
[Stör2005] Störrle, H.: UML 2 erfolgreich einsetzen. Addison-Wesley Deutschland, 2005.
[Stör2006] Störrle, H.: A Comparison of (e)EPCs and UML 2 Activity Diagrams. In: Mendling, J., Nüttgens, J., Rump, F.J.. (Hrsg.): Proc. 5. Intl. Ws. Event Process Chains (EPK’06), CEUR Workshop Proceedings Volume 224, Dezember 2006, Ges. für Informatik, Bonn.
[ZiMe2005] Ziemann, J., Mendling, J.: EPC-Based Modeling of BPEL Processes: A Pragmatic Transformation Approach. In: Proc. 7th Intl. Conf. Modern Information Technology in the Innovation Processes of the Industrial Enterprises (MITIP’05), Genua, 2005.
95
