Wiederverwendung von Legacy-Systemen durch einen Bottom-up – Ansatz bei der Entwicklung einer SOA
Sandra Englet Abteilung IT Bayerischer GUVV/LUK
Ungererstraße 71 80805 München sandra.englet@bayerguvv.de
Abstract: Wird in einem Unternehmen die Entwicklung einer SOA geplant, so stellt sich schnell die Frage der richtigen Einführungsstrategie. Ist es sinnvoll, eine übergreifende Strategie zu fahren und ein allumfassendes Servicemodell als Ausgangspunkt festzulegen, um in einem Top-down-Ansatz die eigenen Produkte SOA-fähig zu machen? Oder sollen Investitionen in Legacy-Systeme geschützt werden, indem bestehende Anwendungen optimiert und durch den Einsatz von Services modernisiert werden, um Systeme wieder verwenden zu können? Bei der
Einführung einer SOA beim Bayer. Gemeindeunfall-
versicherungsverband/Landesunfallkasse (Bayer. GUVV/LUK) war die Grundidee, bestehende Systeme wieder zu verwenden und an einen integrierenden Information Switch anzubinden. In einem Pilotprojekt konnten erste Erfahrungen sowohl bei der Integration zweier Legacy-Anwendungen, als auch bei der Entwicklung von Web Services gesammelt werden.
1 Wiederverwendung von Legacy-Systemen
Beim Bayer. GUVV/LUK ist derzeit die Entwicklung einer Serviceorientierten Architektur (SOA) geplant, um zum einen Legacy-Systeme auf einer höheren Abstraktionsebene miteinander zu verbinden, sowie zum anderen einen Grundstein für eine Anbindung an externe Systeme zu setzen, um den geplanten Umstrukturierungsmaßnahmen im Bereich der gesetzlichen Unfallversicherungsträger Rechnung tragen zu können. Nur durch den Einsatz einer zusätzlichen Serviceschicht und durch die Umgestaltung der Organisation zu einer serviceorientierten Organisation kann ein gewisses Maß an Agilität erreicht werden.
Die zentrale Frage bei der Umsetzung dieser Entwicklung ist dabei, wie ein SOA-Projekt konkret angegangen werden soll. Ist es sinnvoll, die oft propagierte übergreifende Strategie zu fahren und ein allumfassendes Servicemodell als Ausgangspunkt festzulegen, um in einem Top-down-Ansatz die eigenen Produkte SOA-fähig zu machen? Oder sollen Investitionen in Legacy-Systeme geschützt werden, indem bestehende Anwendungen optimiert und durch den Einsatz von Services modernisiert werden, um Systeme wieder verwenden zu können?
In einem Unternehmen neben den Legacy-Systemen eine SOA neu aufzubauen und zunächst zwei Architekturen parallel zu betreiben, birgt gewisse Risiken. Nicht nur die hohen Einführungskosten, sondern vor allem das Risiko, dass eine SOA-Einführung scheitert, wenn es nicht gelingt, die Legacy-Systeme zügig in die neue IT-Architektur überzuführen, lassen diesen Ansatz nicht praktikabel erscheinen. Da Legacy-Systeme zu mächtig sind, um umgestellt zu werden, würde das Projekt aufgrund zu hohem Aufwand und zu hoher Komplexität scheitern. Die strategischen Entscheidungen und Zielsetzungen allerdings müssen zunächst Top-down erfolgen, um ein allgemeines Governance-Konzept und eine Roadmap vorzugeben. Für die konkrete Umsetzung ist es allerdings sinnvoll, bestehende IT-Architekturen zu analysieren, um Systeme weiter zu verwenden. Ein sinnvoller Alternativansatz ist somit das Bottom-up-Verfahren. Die Geschäftsprozesse werden nicht neu hinterfragt, sondern bestehende Technologien werden dazu verwendet, etablierte Prozesse zu erhalten und mit weiteren, alten oder neuen Prozessen zu kombinieren. Die Geschäftsprozesse werden dabei dahingehend hinterfragt, ob den Anforderungen aus Fach- oder Unternehmenssicht genüge getan werden kann. Etablierte Prozesse werden somit nicht neu definiert, sondern gekapselt und in einer SOA mit Hilfe eines Information-Switch mit anderen Prozessen kombiniert.
Das Unternehmen kann auf diese Weise in eine SOA „hineinwachsen“.
Bei der Einführung einer SOA beim Bayer. GUVV/LUK war die Grundidee ebenfalls, bestehende Systeme punktuell durch zusätzliche Serviceschnittstellen an einen zentralen Information-Switch zu integrieren. Bestehende Funktionalitäten werden nach und nach als Web Services angeboten. Dieser iterative und inkrementelle Ansatz zur Entwicklung einer SOA ist sinnvoll, da mit der Zeit immer mehr Funktionalitäten als Services angeboten und existierende Konzepte überarbeitet werden können. Somit werden sukzessiv mehr und mehr Prozesse serviceorientiert, wieder verwendbare Dienste bereitgestellt und vorhanden Systeme integriert. Auch die richtige Granularität der Services kann durch den Bottom-up-Ansatz einfacher gefunden werden.
Neue Applikationen sollen künftig die bereits realisierten Services nutzen und die neue Funktionalität wird bereits als Service implementiert. Der Vorteil dieser Vorgehensweise zeichnet sich sowohl aus ökonomischer Sicht aus, da Services wieder verwendet werden können, als auch durch die Tatsache, dass durch eine Verbreitung des Einsatzbereiches von Services Synergien innerhalb des Unternehmens genutzt werden können. Die bestehende IT – Architektur wird somit Schritt für Schritt in Richtung SOA
Somit werden einerseits bestehende Systeme um eine Serviceschnittstelle erweitert und mit Hilfe eines Information-Switch in eine Gesamtlösung integriert und andererseits wird die Grundlage für geplante Zusammenschlüsse zwischen Unfallversicherungsträgern und daraus resultierende Anbindung externer Systeme geschaffen.
Abbildung 1: SOA-Modell für den Verband
Abbildung 1 zeigt das SOA-Modell für den Verband. Die Back-End Systeme sollen künftig an einen Information-Switch angebunden sein, um die unterschiedlichen Schnittstellen zwischen diesen Systemen abzulösen. Ein Teil der Anwendungen wird in Form von Services bereitgestellt. Um komplette Geschäftsprozesse abzubilden, werden in einer weiteren Schicht die Services orchestriert und schließlich an das Front-End angebunden. Durch den zentralen Information-Switch ist ein einheitliches Management möglich. Allerdings stellt diese zentrale Middleware-Komponente auch ein Risiko in Form eines Single Point of Failures dar. Soweit sich der Ansatz bewährt hat und auf weitere Legacy-Systeme ausgeweitet wird, ist aus diesem Grund ein Redundanzkonzept notwendig.
Insgesamt werden die bestehenden Architekturen nicht abgelöst, sondern die zahlreichen Verknüpfungen reduziert und durch den Information-Switch und der zusätzlichen Service-Schicht weitere Vorteile realisiert. Nicht alle bestehende Systeme und Anwendungen werden zukünftig an den Information-Switch integriert werden, so dass auch weiterhin einige Client-Server-Systeme oder die Host-Terminal-Anwendung bestehen bleiben. Zudem soll durch dieses Architekturkonzept eine Anbindung an externe Programmsysteme ermöglicht werden.
In einem Pilotprojekt im Rahmen der Diplomarbeit wurde die Anbindung zweier Legacy-Systemen an einen Information-Switch zur Datenübernahme durchgeführt.
Dadurch kann eine manuelle Doppelerfassung vermieden werden. Dieses Projekt diente als Einstieg in die Entwicklung einer SOA, um erste Erfahrungen in der Integration von Legacy-Systemen und Entwicklung von Web Services zu sammeln. Durch das Pilotprojekt konnte ein erster Schritt in Richtung einer Serviceorientierten Architektur erfolgen.
2 Pilotprojekt im Rahmen der Diplomarbeit
Der Bayer. GUVV/LUK als Unfallversicherungsträger der öffentlichen Hand erhält täglich zwischen 3000 und 4000 neue Unfallanzeigen, Arztberichte oder Rechnungen.
Diese Dokumente werden von der Eingangsbearbeitung in der fachlichen Kernanwendung erfasst. Liegt für einen Versicherungsfall eine Krankenhausrechnung vor, so übernimmt ein DRG-Rechnungsprüfer die spezielle Prüfung dieses Dokumentes nach der Erfassung.
Zur Prüfung der Krankenhausrechnungen steht dem Sachbearbeiter eine spezielle Anwendung (KF-B.NET) zur Verfügung. Diese Anwendung wurde bislang völlig isoliert zum zentralen Schadensabwicklungssystem eingesetzt. Somit war eine Zweiterfassung der Versichertendaten in KF-B.NET notwendig.
Der Geschäftsprozess zur Krankenhausfallbearbeitung soll durch den Einsatz von Web Services optimiert werden. Die Daten sollen künftig nicht mehr doppelt erfasst werden müssen, sondern über einen Web Service aus der DB2 Datenbank der fachlichen Kernanwendung ausgelesen und der Anwendung zur Krankenhausfallprüfung bereitgestellt werden. Dadurch kann eine Zeitersparnis bei der Erfassung, sowie eine Qualitätssteigerung der Daten durch die Vermeidung von Tippfehlern realisiert werden.
Entsprechend dem eingegebenen Aktenzeichen werden die Daten aus der Datenbank ausgelesen und bereitgestellt. Da eine direkte Anbindung an die Oberfläche der Fremdsoftware aufgrund fehlender Schnittstellen nicht möglich war, wurde ein neuer Record mit den ausgelesenen Daten in der Oracle Datenbank von KF-B.NET angelegt.
Somit stehen die Daten nun bei einer erneuten Suche des Aktenzeichens in KF-B.NET zur Verfügung.
Abbildung 2: Gesamtprozess zur Anbindung der Services
Problematisch bei der Übertragung von Daten zwischen zwei heterogenen Systemen ist oftmals die semantische Interpretation der einzelnen Datenfelder. Die Datentypdefinition der einzelnen Felder ist in der DB2 Datenbank teilweise unterschiedlich zu der Oracle Datenbank. So erwartet die Oracle Datenbank bspw. eine Variable vom Typ „DATE“ für das Geburtsdatum des Versicherten, wohingegen das Datum auf der DB2 Datenbank in drei separaten Variablen (Geburtstag, -monat und –jahr) gespeichert wird. Somit mussten weitere Web Services zur Datenaufbereitung implementiert werden, um eine Übernahme zu ermöglichen.
Die Orchestrierung der einzelnen Services erfolgte über einen übergeordneten Prozess, der nacheinander die entsprechenden Dienste aufruft. Dieser Gesamtprozess (vgl.
Abbildung 2) wurde schließlich an die Anwendung angebunden.
