API-Upgrade für eLGK

Die Österreichische Gesundheitskasse (ÖGK) ist die größte soziale Krankenversicherung Österreichs: Sie bietet 7,6 Millionen Versicherten in Österreich Schutz – unabhängig von Alter oder Einkommen.

Seit über zwei Jahrzehnten sorgt eLGK im Hintergrund für den reibungslosen Datenaustausch innerhalb der ÖGK – tief integriert in eine historisch gewachsene Systemlandschaft. Mit Unterstützung von Gepardec wird die zentrale Anwendung schrittweise modernisiert: Altschnittstellen werden durch zeitgemäße APIs ersetzt, Funktionen entkoppelt und die Basis für eine zukunftsfähige Weiterentwicklung gelegt.

Zwanzig Jahre später hat sich die Welt verändert. Statt 9 Gebietskrankenkassen gibt es eine ÖGK, LGK wurde von einer auf CICS und TUXEDO laufenden COBOL-Anwendung in eine JEE Applikation transformiert, zentrale Kundenportale dominieren die Systemlandschaft. eLGK aber steckt immer noch inmitten der Systeme, konzeptionell weitgehend unverändert, jedoch mit zusätzlichen Aufgaben versehen und auf JBoss EAP umgestellt. Zeit für einen Modernisierungsschub.

Modernisierungsvorhaben haben mehrere Gegner. Überlastete Strukturen (Monolithen), überholte Designs (Legacy), zwingende Änderungen (Vorgaben) und nur wenige Entwickler:innen mit Wissen über die lange vergangenen Architekturentscheidungen und deren Gründe. Schon gar nicht mit freier Zeit (Ressourcen).

Geplant ist eLGK in mehreren Schritten einem Facelift unterziehen, so dass wir die zwingenden Änderungen bald produktiv setzen können und Schritt für Schritt einer der Zeit angemessenen Architektur näher kommen. Unterstützt werden wir dabei von Gepardec.

Strukturell wollen wir die Applikation in drei Teile trennen und Funktionalität, die nicht mehr passend ist, in andere Applikationen auslagern. Damit ermöglichen wir höhere Geschwindigkeit in der Weiterentwicklung von Web-Funktionalitäten bei Erhalt der Stabilität von Business-Schnittstellen. Das größte Designproblem ist eine Binärschnittstelle aus der COBOL-Zeit, die sich durch alle Kommunikationsstrukturen, wie Serviceaufrufe und Message-Queues zieht. Dieses basiert auf einer proprietären Bibliothek, die nicht mehr unterstützt wird. Dieses Binärformat wird durch ein Webservice-Format umgestellt.

Zwingend ist der EAP 8 Upgrade der Anwendung von JEE7 auf Jakarta 10. 

Die Reihenfolge ergibt sich recht natürlich aus den Gegebenheiten. Da die Bibliotheken der Binärschnittstelle nicht mehr unterstützt werden, starten wir mit der Umstellung auf die Webservice-Schnittstelle, um dann auf EAP8 umstellen zu können. Danach können wir Anwendungen aus dem Monolithen herauslösen.