SOA als Werkzeug der Organisationsreform IT-Architektur erfolgreich gewandelt

Redakteur: Gerald Viola

Die Deutsche Rentenversicherung setzt zurzeit eines der größten SOA-Projekte in der deutschen Verwaltungslandschaft um. Bislang arbeiten die Regional- und Bundesträger mit zwei unterschiedlichen IT-Verfahren, um die Rentenansprüche von rund 51 Millionen Versicherten zu verwalten und zu berechnen. Die bisherigen Kernverfahren rvGlobal und GRVS werden jetzt auf der Basis einer SOA-Infrastruktur durch ein gemeinsames Programmsystem ersetzt.

Firma zum Thema

Entwicklungszyklen. Das SOA-Rollenkonzept und das Vorgehensmodell der DRV-IT ermöglichen eine klare Aufteilung
Entwicklungszyklen. Das SOA-Rollenkonzept und das Vorgehensmodell der DRV-IT ermöglichen eine klare Aufteilung
( Archiv: Vogel Business Media )

Dabei wird deutlich, dass die SOA den organisatorischen und inhaltlichen Umbau, der durch die Organisationsreform der gesetzlichen Rentenversicherung ausgelöst wurde, ideal unterstützt. Im Rückblick zeigt sich auch, welche Kriterien bei der erfolgreichen Umsetzung eines SOA-Rahmenkonzepts eine entscheidende Rolle spielen.

Zur Umsetzung der Organisationsreform in der Deutschen Rentenversicherung (DRV) haben die Rentenversicherungsträger unter anderem die Migration der beiden bestehenden IT-Systeme zu einem gemeinsamen System beschlossen. Den IT-Infrastrukturrahmen haben Projektgruppen in Form eines IT-Architekturplanes für die DRV erarbeitet, in dem Funktionalitäten über offene, standardisierte Schnittstellen zur Verfügung gestellt werden. Die Projektgruppen legten die SOA und die Java Enterprise Edition (Java EE) als technologische Plattform fest. Außerdem wurde festschrieben, dass die zukünftige IT-Architektur eine weitestgehende Nutzung der existierenden Systeme unterstützt.

Schrittweises Vorgehen

Die verabschiedete Architekturvariante sieht die Realisierung einer SOA-basierenden IT-Infrastruktur mit neuer einheitlicher Benutzeroberfläche vor, in der Infrastrukturdienste und gegebenenfalls ein Teil der fachlichen Dienste zur gemeinsamen Nutzung bereitgestellt werden. Die Geschäftslogik der beiden Bestandssysteme soll dabei zunächst gekapselt und über eine Integrationsschicht zur Verfügung gestellt werden. Anschließend soll die Funktionalität Schritt für Schritt aus den beiden Kernverfahren herausgelöst und in „neuer“ Technologie (Java EE) als Service angeboten werden. Dann erst ist die angestrebte Zielarchitektur erreicht.

Die DRV stellt hohe Erwartungen an die neue Architektur. Durch die Verwendung standardisierter Schnittstellen ermöglicht die SOA die lose Kopplung der Dienste und bietet dadurch mehrere Vorteile:

  • Eine flexible Orchestrierung und Nutzung von Diensten in Geschäftsprozessen,
  • die Wiederverwendung, das heißt, die Verwendbarkeit eines Dienstes in unterschiedlichen Geschäftsprozessen,
  • ein technologieunabhängiges Angebot von Diensten sowie
  • die Interoperabilität, also auch die Integration der bereits existierenden Systeme.

Koexistenz der Systeme

Durch ihr SOA-Konzept ist die DRV-IT in der Lage, die fachlichen Anforderungen ihrer Kunden oder Auftraggeber und deren Kompetenz als Fachexperten adäquat mit einzubeziehen. Das neue Programmsystem wird iterativ und inkrementell entwickelt – leistungsfähige Bestandsverfahren werden weiterverwendet, wo dies möglich und sinnvoll ist (Investitionsschutz). Dies garantiert bei übergangsweiser Koexistenz von „alter“ und „neuer Welt“ eine Migration zu einem modernen, zukunftsfähigen IT-System im laufenden Betrieb auf der Basis der existierenden Systeme. Die Ziele der Organisationsreform lassen sich so adäquat und kostengünstig mit einer SOA erreichen, wie beispielsweise die Konsolidierung der Organisation nach Fusionen und Kooperationen einzelner Träger sowie die notwendige Arbeitsaufteilung in den neu entstandenen föderalen Strukturen der DRV-IT.

Der Weg der DRV

Auf der Basis der Ergebnisse aus den Projektgruppen wurde ein Programm zur Einführung einer SOA in der DRV-IT konzipiert und verabschiedet. Es legt die wesentlichen Konzepte und Methoden, die Architektur, einen Meilensteinplan und ein SOA-Rollenkonzept sowie ein auf diesen Rollen basierendes Ausbildungskonzept fest. Darüber hinaus wurde zur Unterstützung und Koordination ein SOA-Programmmanagement aufgebaut, in dem folgende Expertengruppen mitarbeiten:

  • Architekturmanagement (Referenz-, System- und Softwarearchitektur),
  • Facharchitektur (Geschäftsprozessmodellierung und Service-Identifikation),
  • Standards und Richtlinien,
  • Anforderungsmanagement,
  • Softwareentwicklungsprozess,
  • Betriebskonzepte,
  • Sicherheitskonzepte und
  • Kommunikation.

Diese Expertengruppen werden durch das Programmmanagement koordiniert. Dadurch stellt die DRV eine geeignete Governance sicher (konsequente Unterstützung und Koordination). Perspektivisch sollen alle Aufgaben weitgehend ohne externe Unterstützung erledigt werden.

Parallel dazu hat die DRV in den Jahren 2006 und 2007 ein erstes Pilotprojekt ins Leben gerufen, um die Realisation einer SOA-basierenden IT-Infrastruktur im Detail zu prüfen. Dazu wurde die bereits bestehende, moderne IT-Infrastruktur um eine Workflow-Engine, eine Integrationsplattform und einen Benutzerinteraktionsdienst erweitert. Dies gewährleistet die flexible Definition und Umsetzung von Geschäftsprozessen (GP), in denen Infrastruktur- und fachliche Dienste orchestriert und Aufgaben zur weiteren manuellen Bearbeitung ausgesteuert werden können.

Entscheidende Bestandteile wie das Identity- und Access-Management wurden zwar konzeptionell mit betrachtet, blieben aber bei der prototypischen Umsetzung zunächst außen vor. Auf der Grundlage dieser minimalen IT-Infrastruktur wurde ein repräsentativer GP umgesetzt und die Machbarkeit der Integration von Geschäftslogik aus den beiden bestehenden Kernverfahren nachgewiesen. Vorhandene Infrastrukturdienste wie Archivierung und Dokumentenmanagement wurden mit einbezogen.

Ziel des Prototyps war auch, die trägerübergreifende Zusammenarbeit von Fach- und IT-Bereichen im Rahmen eines gemeinsamen Entwicklungsprozesses auf der Basis einer Facharchitektur zu erproben und durch eine geeignete Infrastruktur zu unterstützen.

Derzeit bereitet die DRV-IT die zweite und die folgenden Iterationen zur Entwicklung eines neuen gemeinsamen Programmsystems für alle Träger in der DRV im Rahmen einer SOA-basierenden Infrastruktur vor. Dazu werden die beschriebenen Aufgaben des Programmmanagements angegangen: vor allem die Meilenstein- und Ressourcenplanung, die Wirtschaftlichkeitsbetrachtung, die SOA-Referenzarchitektur einschließlich der Facharchitektur, der Softwareentwicklungsprozess sowie die Werkzeugauswahl.

Vier neue Schichten

Das Architekturmodell der DRV basiert auf dem verbreiteten Schichtenmodell, das um vier Schichten erweitert wurde: um die Integrations- und die Geschäftsprozessschicht (GP-Schicht), einer Schicht zur Integration von Bestandssystemen sowie der Batch-Verarbeitung.

Die Infrastruktur- und fachlichen Dienste, der Benutzerinteraktionsdienst (BID), die GP-Steuerung, die Bestandssysteme sowie die Batch-Verarbeitung können dabei sowohl als Dienstanbieter als auch als -nutzer auftreten. Alle Dienste werden über standardisierte Schnittstellen an die Integrationsplattform (IP) angeschlossen und so miteinander verbunden.

Die aus den Schichtenarchitekturen bekannten Schichten finden sich hier innerhalb der einzelnen Dienste wieder. Beispielsweise beinhaltet der BID eine Client-, Präsentations- und Geschäftslogikschicht. Fachliche Dienste können aus einer Geschäftslogik- und Datenhaltungsschicht bestehen. Sie sind jeweils in der Geschäftslogikschicht (GL) über einen passenden Adapter mit der IP verbunden.

An den BID ist auch die grafische Benutzerschnittstelle (GUI) angebunden. In der Geschäftslogikschicht des BID ist darauf zu achten, dass dort keine anwendungsspezifische Logik realisiert wird. Dies wird dadurch erreicht, dass die Anwendungsfälle und die damit verbundenen Maskenfolgen regelbasierend ausgeführt werden. Formale Prüfungen von Eingabefeldern (Datum, Zeit, Ziffern, Text usw.) erfolgen im BID, während fachliche Plausibilitätsprüfungen durch Service-Aufrufe über die IP realisiert werden.

Die GP-Schicht besteht aus den GP-Beschreibungen und einer Workflow-Engine, welche die GP ausführt. In der DRV wird hier die Business Process Execution Language (BPEL) verwendet. Während der Ausführung eines GP können über die IP alle verfügbaren Dienste genutzt werden. Umgekehrt kann die Workflow-Engine in der GP-Schicht auch als komplexer Dienst, der einen bestimmten GP ausführt, genutzt werden. GP laufen – soweit möglich – vollautomatisch ab. Falls während der Ausführung eines GP eine Benutzerinteraktion erforderlich ist, werden die manuell zu erledigenden Aufgaben an den BID ausgesteuert und der GP angehalten. Nach Erledigung wird der GP wieder aufgenommen.

Die hostbasierenden Bestandssysteme der DRV werden über die Transaktionsmonitore UTM und CICS mit der IP verbunden. Für UTM wird eine eigene Anpassung des BeanConnect-Adapters eingesetzt. Bei anderen, externen Systemen ist die Transaktionssicherheit der Verbindung jeweils spezifisch zu berücksichtigen.

Die IP kümmert sich um die Lokalisierung der Dienste sowie um das Routing und die Transformation von Daten. Zur Realisierung werden derzeit drei Alternativen betrachtet:

  • ein Enterprise Service Bus (ESB) auf der Basis der Spezifikation Java Business Integration (JBI) des Java Community Process (JSR 208),
  • eine Integrationslösung nach der Spezifikation der Service Component Architecture (SCA) der Open Service Oriented Architecture (OSOA) Collaboration und?
  • ine Eigenimplementierung.?

Es kommen auch Kombinationen der drei Alternativen in Betracht. Im Rahmen des Prototyps wurde die grundlegende Funktionalität durch eine Eigenimplementierung realisiert.

Klare Strukturen

Die Anbindung von Diensten an die IP als Web-Service (SOAP) ist zwar ein häufig genutzter und zitierter Weg der Anbindung an die IP, aber nicht der einzige. Grundsätzlich kommen auch andere Protokolle wie JMS, RMI oder HTTP in Frage. Zur Anbindung von Web Services (WS) werden die Spezifikationen von OASIS und die Profile des WS-I berücksichtigt sowie das Web Service Invocation Framework (WSIF) von Apache verwendet. Eine zentrale Anforderung ist in der DRV die dienstübergreifende Transaktionssicherheit. Da für die WS-Transaction-Spezifikation von OASIS bisher noch keine praktikable Lösung angeboten wird, muss darauf geachtet werden, dass hier transaktionssichere Verbindungen über die IP hergestellt werden können. In der DRV werden dazu RMI und die Transaktionsmonitore UTM und CICS eingesetzt.

Das SOA-Rollenkonzept und das Vorgehensmodell der DRV-IT ermöglichen eine klare Aufteilung der Arbeiten im Entwicklungsprozess zwischen Fach- und Entwicklungsbereich sowie dem Betrieb. Die erhöhte Bedeutung des Fachbereichs zeigt sich in dem neuen Zyklus zur Fachanalyse und -modellierung (Entwicklung der Facharchitektur). Neu ist der Zyklus zur Entwicklung der Betriebsinfrastruktur, die aus Hardware, Betriebssystemen, Datenbanken, Application-Servern usw. besteht.

Am Anfang des Entwicklungsprozesses erfolgt – ausgehend von einer fachlichen Anforderungsdefinition – in der Facharchitektur eine detaillierte Beschreibung der Geschäftsprozesse und der Services aus fachlicher Sicht. Auf dieser Basis werden in der Anwendungsentwicklung die technischen Anforderungen an die IT-Infrastruktur ermittelt, die durch eine Software- und Betriebsinfrastruktur umgesetzt werden. Bei der Entwicklung der Software-Infrastruktur werden die technischen Anforderungen analysiert und daraus Anforderungen an die Betriebsinfrastruktur abgeleitet.

Fazit: Große Chancen, wenn die Risiken erkannt werden

Aus Sicht der DRV ist eine breite Akzeptanz, die sich durch sämtliche Organisationseinheiten und Hierarchiestufen zieht, entscheidend für die erfolgreiche Einführung einer SOA. Die konsequente Unterstützung und Koordination durch die Unternehmensleitung und andere Leitungsinstanzen spielt eine zentrale Rolle. Eine SOA bietet einen hohen Nutzen für Kunden, Auftraggeber und die IT. Die IT kann schnell und flexibel auf Kundenwünsche reagieren und dabei die Kompetenz der Fachexperten auf Kundenseite einbeziehen. Deshalb sind konkrete Absprachen und eine intensive Zu-sammenarbeit sehr wichtig.

Weitere Erfolgsfaktoren sind ein methodisches Vorgehen und ein gemeinsames Verständnis aller Beteiligten über die Terminologie und Konzepte. Dies erfordert eine intensive Kommunikation und eine Ausbildung aller Beteiligten. In der DRV wurde ein rollenbasierendes Ausbildungskonzept definiert, auf dessen Basis eine breite, trägerübergreifend einheitliche Grundausbildung sowohl in der Technologie (Java EE) als auch zu SOA durchgeführt wurde. Dabei ist darauf zu achten, dass die Ausbildung zeit- und praxisnah an den aktuellen Aufgaben ausgerichtet wird.

Um die Komplexität der Einführung und späterer Weiterentwicklungen einer SOA zu reduzieren, ist ein iteratives und inkrementelles Vorgehen notwendig. Eine gute Orientierung bietet der Rational Unified Process (RUP), aber auch traditionelle Modelle wie das Spiralmodell.

Beim Vorgehen gilt es, klein einzusteigen und in kleinen und überschaubaren Schritten voranzugehen. So bleibt sichergestellt, dass jederzeit eine konsolidierte IT-Infrastruktur zur Verfügung steht. Außerdem ist vor jedem Schritt die „Reife“ des Unternehmens zu berücksichtigen: Einerseits müssen sämtliche Mitarbeiter inhaltlich und organisatorisch dort abgeholt werden, wo sie stehen, und andererseits muss die bestehende IT-Infrastruktur die Ausgangsbasis für Erweiterungen, Anpassungen oder Umbauten bilden.

In der DRV wird deutlich, dass die SOA den organisatorischen und inhaltlichen Umbau (Organisationsreform der gesetzlichen Rentenversicherung) ideal unterstützt. Das gilt nicht nur für die Integration und schrittweise Migration der Bestandssysteme, sondern auch für die Entwicklung eines Beteiligungsmodells für alle Rentenversicherungsträger einschließlich der Rechenzentren, in dem eine adäquate Aufgabenaufteilung definiert werden kann.

Artikelfiles und Artikellinks

(ID:2013380)