GEK-Kernanwendung nebenbei auf C# portiert

Erfolgreiches Migrationsprojekt für 2.000 User parallel zu Kassenfusion und Einführung des Gesundheitsfonds

"Gesundheit Erster Klasse" verspricht der Slogan der Gmünder Ersatzkasse. Dafür, dieses Versprechen gegenüber ihren rund 1,7 Mio. Versicherten einzuhalten, sorgt nicht zuletzt die hauseigene Softwarelösung GEK-Client. Fast 2.000 Anwender können sich zu jeder Zeit einen umfassenden Überblick über alle relevanten Informationen rund um ein Mitgliedsverhältnis verschaffen. Durch unaufschiebbare Projekte wie die Fusion mit der Hamburgischen Zimmererkasse und die Einführung des Gesundheitsfonds wäre die 2008 geplante und dringend notwendige Migration der SQL-Windows-Anwendung auf eine moderne .NET-Umgebung beinahe unter die Räder gekommen. Dass es am Ende doch noch geklappt hat, ist das Ergebnis einer mehrstufigen Vorgehensweise und der toolbasierten Dienstleistung "The Porting Project" des Software- und Consultinghauses fecher aus Rodgau.

"Schon 2007 war uns klar, dass SQL Windows auf Dauer keine zuverlässige Basis für eine unternehmenskritische Anwendung mehr sein konnte", sagt Karl Lang, verantwortlicher Projektleiter im Bereich Qualität und Verfahren der IT-Abteilung der GEK. "Das ursprünglich von Gupta stammende Werkzeug war bereits mehrfach an fremde Unternehmen verkauft worden. Der neue Eigentümer hatte freigegebene Versionen immer wieder zurückgezogen. Wir mussten permanent mit der Unsicherheit leben, ob es mit dem Produkt überhaupt weitergeht." Zudem entsprach die Softwareplattform nicht mehr dem Stand der Technik. Vor allem die fehlende Möglichkeit zur Modularisierung machte den GEK-Entwicklern zu schaffen. "Die ganze Anwendung bestand aus einer einzigen großen .EXE-Datei, und die befand sich ständig in Änderung", erinnert sich Lang.

So machte er sich mit dem vierköpfigen Team, das bei der GEK für die Auswahl von Werkzeugen und Verfahren verantwortlich ist, auf die Suche nach Alternativen. Dabei sollte sich im Grunde möglichst wenig ändern: Die Software, die in den 90er-Jahren als interaktives Front-End zu den verschiedenen Mainframe-Anwendungen im Haus entstanden war, tat ihren Dienst und die Anwender waren mit den Funktionen sehr zufrieden. Regelmäßige Totalabstürze der Anwendung, wie sie an verschiedenen Arbeitsplätzen zuletzt mehrmals täglich auftraten, unterstrichen allerdings die Dringlichkeit der Suche. Kommerzielle Alternativen zu der maßgeschneiderten Eigenentwicklung der GEK gab es keine. Daher kam also nur die Portierung der vorhandenen Lösung auf eine moderne Technologie wie Java oder .NET in Frage.

Unter Windows .NET bevorzugt

Pragmatische Überlegungen gaben den Ausschlag, dass es am Ende .NET werden sollte. "Wir wollten auf alle Fälle bei Windows-Clients bleiben", erläutert Lang. "Da ist das .NET-Framework von Microsoft einfach besser integriert." Da die Entwicklungssprache C# dem im Hause bereits verbreiteten Java obendrein sehr ähnelt, würden die Entwickler sich auch in der neuen Umgebung schnell zurechtfinden.

Die über Jahre gewachsene Anwendungssoftware selbst neu zu schreiben oder zu portieren kam allerdings aufgrund des damit verbundenen Entwicklungsaufwands nicht in Frage. Für die Migration auf die neue Plattform war also auf alle Fälle externe Unterstützung gefragt. Ende 2007 holte das GEK-Team Angebote bei zwei verschiedenen Anbietern ein, die sich auf die Portierung von Gupta-Anwendungen spezialisiert hatten. Zuvor ließ man von beiden auch gleich eine Testportierung eines überschaubaren Anwendungteils durchführen.

Über die Unterschiede staunt Lang noch heute: "Nach wenigen Tagen lieferte fecher den fertig portierten Code unter .NET ablauffähig zurück. Der andere Anbieter ließ uns mehrere Wochen warten. Und was dann endlich kam, funktionierte noch nicht einmal." Der entscheidende Unterschied lag darin, dass die Rodgauer mit "The Porting Project" eine toolbasierte Dienstleistung angeboten hatte, während der andere Anbieter größtenteils manuell neu codieren musste. Obendrein wäre sein Angebot auch fast dreimal so teuer gekommen, so dass die Entscheidung für fecher schnell getroffen war.

Grau ist alle Theorie

Im Frühjahr 2008 setzte sich das Projektteam erstmals zusammen und stellte den Projektplan für die Migration auf: Im Juli sollte der Code eingefroren und an fecher übergeben werden. Ab Oktober war der Test des zurückgelieferten Codes vorgesehen, parallel dazu die Finalisierungsarbeiten geplant, so dass der Routinebetrieb zum Jahreswechsel 2009 erfolgen könnte.

"Aber dann hat uns die Realität des deutschen Gesundheitswesens eingeholt", schmunzelt Lang. Die kurzfristig bekanntgewordenen Vorgaben des Gesetzgebers zur Einführung des Gesundheitsfonds erforderten alle vorhandenen Entwicklerkapazitäten. Zeitgleich fusionierte die GEK noch mit der HZK, so dass die Konsolidierung zweier IT-Landschaften zu bewältigen war. Für die ebenfalls dringend notwendige Plattformumstellung blieb einfach keine Kapazität. Mehr noch: Da der GEK-Client von den erforderlichen Softwareänderungen massiv betroffen war, musste auch der geplante Code-Freeze ausfallen.

So standen zum Projektbeginn am 1. Juli 2008 also weder Entwickler noch Tester aus der Fachabteilung zur Verfügung und fecher musste praktisch ohne Unterstützung durch die GEK mit dem nicht eingefrorenen Code arbeiten. "Natürlich hatten wir ein schlechtes Gefühl im Bauch, aber es ging einfach nicht anders", betont Lang.

Das Projekt nach dem Projekt

So entschloss sich der erfahrene Projektmanager, aus der Not eine Tugend zu machen, und überließ die erste Portierungsstufe komplett dem externen Dienstleister. Wie vereinbart, lag die Anwendung im Herbst 2008 fertig migriert als C#-Code vor, der sich in Visual Studio.NET einwandfrei kompilieren ließ. Statt nun mit der fachlichen Testphase und der Finalisierung zu beginnen, wartete das Team erst einmal das Ende der andauernden Programmierarbeiten ab. Zum Jahresbeginn 2009 fror man den weiterentwickelten SQL-Windows-Code dann ein und schickte ihn erneut zu fecher in die Porting Factory. Diesmal allerdings blieb den GEK-Entwicklern die Zeit für eine gründliche Schulung in der neuen Technologie. So waren sie in der Lage, alle in dieser zweiten Portierungsphase doch unvermeidlichen Codeänderungen parallel an der alten Gupta- und der neuen .NET-Codebase durchzuführen.

Die neuerliche Portierung war schnell erledigt: Nachdem alle Fallstricke bereits aus dem ersten Durchlauf bekannt und gelöst waren, stand der finale Code im März 2009 zur Verfügung. Anfang April startete eine Pilotphase mit 50 Anwendern, die sich als freiwillige Tester gemeldet hatten. "Dabei haben wir noch viele Fehler gefunden", fasst Lang zusammen. "Die weitaus überwiegende Zahl davon war allerdings mit kosmetischen Korrekturen schnell zu beheben." So konnten die Entwickler an Kleinigkeiten wie schlecht umbrochenen Maskentexten, zu großen Buttonbeschriftungen oder falsch eingefärbten Überschriften den Umgang mit dem neuen .NET-Framework üben. "Zu unserer großen Überraschung hatte die Portierung einen ausgesprochen übersichtlichen Code ergeben, in dem die Programmierer sich gleich zurechtfanden", so das Fazit.

Weitere Probleme blieben aus. Daher nutzte das Team die abschließende Finalisierungsphase, um die Benutzeroberfläche der Applikation aufzufrischen. Um den Anwendern den Umstieg von Anfang an schmackhaft zu machen, wurde eine fremde Icon-Bibliothek im neuen Windows-Office-Stil integriert und die Bedienungsschritte oft genutzter Masken optimiert. Aber auch die Verbesserungen "unter der Haube" waren deutlich spürbar: So lobten die Teilnehmer der Pilotphase vor allem die gute Performance und Stabilität der neuen Lösung. Systemabstürze, wie sie zuvor noch an der Tagesordnung waren, gab es überhaupt nicht mehr.

Auf los geht's los

Damit stand der nunmehr für Anfang Mai geplanten Aufnahme des Routinebetriebs nichts mehr im Weg. Zwar hatte das Projektteam einen wasserdichten Fallback-Plan für den Fall vorgesehen, dass beim unternehmensweiten Einsatz unerwartete Probleme auftauchen würden. Doch davon konnte am 4. Mai keine Rede mehr sein: "Selten haben wir eine reibungslosere Migration erlebt", freut sich Lang. "Nach dem schwierigen Projektstart war das 'Go Live' wirklich ein Spaziergang".

Unter dem Strich hat sich für ihn auch die unkonventionelle Vorgehensweise ausgezahlt. Der neuerliche Portierungslauf hat nur wenig zusätzliches Budget erfordert und erhebliche Zeitersparnis für das Entwicklerteam gebracht, das sich so voll und ganz auf sein Tagesgeschäft konzentrieren konnte. Mittlerweile allerdings steht die Weiterentwicklung der Lösung im Vordergrund, die zunächst einmal modularisiert werden soll. "Jetzt, da wir endlich in der .NET-Welt angekommen sind", so Lang, "wollen wir die neuen Möglichkeiten auch optimal nutzen." 

Keywords: .NET, C, Gupta, Migration, Portierung, SQL Windows