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.

Die IT der der ÖGK entwickelt seit vielen Jahren eine der zentralen Anwendungen der ÖGK. LGK, Leistungswesen der Gesundheitskasse. Die Wurzeln reichen bis in die frühen 2000er Jahre zurück. Damals war die ÖGK noch neun Gebietskrankenkassen, die Anwendung lief für jeden Sozialversicherungsträger getrennt unter CICS oder Tuxedo, zentrale Webapplikationen steckten in den Kinderschuhen. Zu dieser Zeit wurde eLGK entwickelt. Als eine J2EE Anwendung auf Weblogic steckte es inmitten von Tuxedo- CICS- und anderer J2EE-Systeme, um sie zu verbinden, Nachrichten in Queues zwischenzuspeichern und einen zentralen Einstiegspunkt für externe Anwendungen bereitzustellen.

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.