Umzugsservice: von Gupta nach .NET

Günter Hofmann ist Head of Software Services bei fecher e.Kfm

Datenbankapplikationen, die im öffentlichen Bereich eingesetzt werden - von Behörden oder Spitälern beispielsweise - müssen kontinuierlich an sich ändernde Rahmenbedingungen und Gesetze angepasst werden. Das Berner Software-Haus AG Büro 70 betreut zwei solche Lösungen: eine Pensionskassen-Software (Peka) und eine Spital-Software (Pabs). Die bislang für beide Anwendungen eingesetzte Gupta-Plattform war jedoch in die Jahre gekommen und machte flexible Änderungen zunehmend schwierig. Bereits seit dem Jahr 2002 wurde bei den Bernern deshalb intensiv über einen Technologiewechsel diskutiert. «Dem direkten Vergleich mit der Java-Technologie, mit der ich zuvor gearbeitet hatte, hielt Gupta schon zu diesem Zeitpunkt nicht mehr stand», meint Büro-70-Geschäftsführer Daniel Stucki. Zudem war es immer schwieriger geworden, auf dem Arbeitsmarkt Entwickler mit Gupta-Know-how zu finden.

Unlösbares Ressourcenproblem?

Als sich Stucki und sein Team die Systemumgebungen ihrer Kunden daraufhin genauer ansahen, stiessen sie vor allem auf Produkte von Microsoft. Da sich die Branchenpakete aber auf .NET wesentlich besser integrieren lassen würden als auf Java, entschied man sich für die Microsoft-Plattform. Die Ernüchterung folgte jedoch auf dem Fuss: Nach einer ersten Berechnung, was es an finanziellen und personellen Ressourcen kosten würde, Peka und Pabs von Grund auf neu zu entwickeln, war Stucki schnell klar: «Parallel zur notwendigen Wartung und Anpassung der Kundenanwendungen hätten wir eine Neuentwicklung einfach nicht stemmen können.» Die Lösung für ihr Dilemma fanden die Berner erst einige Jahre später: Eine toolbasierte Dienstleistung namens «The Porting Project». Im Herbst 2006 überzeugten eine Roadshow und Referenzprojekte die Software-Spezialisten davon, dass die automatisierte Portierung von Gupta-SAL-Code nach C# in der Praxis funktioniert. Im Januar 2007 liess man dann vom Anbieter, dem Beratungs- und Software-Haus fecher aus Deutschland, eine Analyse des Anwendungscodes vornehmen, die Aufschluss über die Projektdauer gab. Im März fiel die Entscheidung für die Portierung.

Die wichtigste Anforderung an das Projekt: Der Technologiewechsel muss möglichst schnell ablaufen und die Arbeitsbelastung für die eigenen Entwickler so klein wie möglich bleiben. Denn diese arbeiteten mit Hochdruck an neuen Vollversionen von Peka und Pabs, die im Frühjahr 2008 auf den Markt kommen sollten.

Parallel entwickeln geht schneller

Um diesen Termin halten und die Versionen bereits unter .NET ausliefern zu können, sollte auf der Gupta-Plattform weiterentwickelt werden, um danach die je 150 Module umfassenden Anwendungen Stück für Stück zu portieren. Zwischenzeitlich würde fecher in einem Pilotprojekt fünf Module pro Anwendung portieren, um Probleme früh zu erkennen und zu beheben. Im Mai begannen die Experten damit, den Code der ausgewählten Module zu übertragen.
Da während des Pilotprojekts ungewöhnlich viele Fehler im umgewandelten Code auftraten und durch die parallele Weiterentwicklung mehrere Male neue Codeschnipsel hinzukamen, die nachträglich noch eingefügt werden mussten, war der manuelle Aufwand für beide Seiten zunächst hoch. Trotzdem genügte es, auf Kundenseite drei bis vier Entwickler dafür abzustellen. «Selbst in dieser Phase war es beruhigend zu sehen, dass die automatisierte Codeumwandlung grundsätzlich funktionierte», erinnert sich Stucki. Drei Monate später war der Gupta-Code dann durchweg so aufgebaut, dass er
problemlos durch das auf Gupta-Code spezialisierte Portierungswerkzeug «Ice Porter» laufen würde. Dieses hatte fecher wegen der enormen Anzahl an Modulen extra mit einem Zusatzprogramm zur Batch-Ansteuerung versehen.

Portierung im Eilverfahren

Von Juli bis September 2007 portierte fecher erst Pabs und von September bis November 2007 Peka. Dabei mussten insgesamt rund eine Million Codezeilen und Tausende Fenster, Klassen, Funktionen und auch Reports übersetzt bzw. umgewandelt werden. Neben der Komplexität der beiden Anwendungen stellte die Unterstützung der unterschiedlichen Datenbanken Oracle, DB2 UDB und SQL Server eine Herausforderung bei der Portierung dar. Bei den anschliessenden Tests bezog AG Büro 70 neben den Entwicklern auch hausinterne Anwender mit ein, die jedoch nur wenig zu beanstanden hatten. «Der Aufwand des Pilotprojekts hat sich in der Testphase absolut ausgezahlt», resümiert Stucki. Lediglich kleinere Fehler mussten behoben werden.

Release-Planung eingehalten

Nach einer dreitägigen hausinternen Schulung durch fecher und einige .NET-erfahrene Kollegen konnte das Team um Stucki die verbleibende Zeit bis zum Release sogar noch ausnutzen, um die Benutzeroberflächen der beiden Anwendungen zu modernisieren. Unter Gupta fehlte eine konsistente Darstellung, die Anwender hatten es noch mit zahlreichen .exe-Dateien zu tun. Dagegen erscheint die Oberfläche in den neuen Versionen in bekannter Outlook-Optik: Sie zeigt eine Navigationsleiste und ein Übersichtsfenster mit allen Einzelanwendungen, für die eine Zugriffsberechtigung besteht.

Nachdem das Berner Software-Haus den C#-Code 2008 abgenommen und die Entwicklungsarbeiten unter .NET fertiggestellt hatte, konnte die Auslieferung der neuen Versionen beginnen. Zwölf Kunden haben in den vergangenen Monaten bereits darauf umgestellt. «Rückblickend sind wir den richtigen Weg gegangen», fasst Stucki zusammen. «Die Anwendungsstruktur unserer Branchenpakete ist einfacher geworden und unseren Entwicklern steht jetzt eine moderne Technologie zur Verfügung.» Nächstes Ziel: Für einen durchgehenden Workflow beim Kunden die Office-Produkte noch stärker als bisher in die Branchen-Software zu integrieren.

Laut Stucki hatte das Projekt übrigens noch einen netten Nebeneffekt: «Unsere Entwickler haben durch die Umstellung und den damit verbundenen Community-Gedanken einen grossen Motivationsschub erfahren.»

 

Die Projektdaten

Ursprungsplattform: Gupta Team
Developer
Zielplattform: Microsoft .NET / C#
Unterstützte Datenbanken: Oracle, DB2 UDB, SQL Server
Umfang:
-eine Million Codezeilen
- 1200 Fenster
- 3000 Klassen
- 30000 Funktionen
- 250 Reports
Projektdauer: 12 Monate