Die Mitte September veröffentlichte Ankündigung der kalifornischen Unify Corp., den Klassiker unter den Datenbank- und Tools-Spezialisten Gupta zu kaufen, dürfte unter Anwendern und Partnern für einige Unruhe gesorgt haben. Nach wie vor sollen allein in Deutschland mehrere 100 unternehmenskritische Anwendungen und Branchenlösungen auf dem "Team Developer" von Gupta aufsetzen. Als problematisch sieht Eberhard Fecher, Inhaber des in Rodgau ansässigen langjährigen Gupta-Partners Fecher, insbesondere die unterschiedliche Ausrichtung der beiden Hersteller an. Die Produkte beider Häuser seien in einigen Bereichen zwar durchaus komplementär, doch die Unify-Strategie ziele mehr in Richtung Enterprise-Java und Linux, während eingefleischte Team-Developer-Anwender in der Regel Microsoft-Fans sind und eine stärkere Ausrichtung auf .NET und Visual Studio fordern. Insofern sei die von Gupta geplante Neuentwicklung des Team Developers in Frage gestellt.
Hinzu kommt noch ein anderer Umstand: Das Update 2006 sollte vor allem durch eine native Unterstützung von Linux, Unicode-Zeichensatz, Web-Services und neue GUI-Komponenten glänzen, doch viele dieser Erweiterungen werden bereits vom Unify-eigenen Produkt "NXj" abgedeckt, weshalb der neue Besitzer seine angestammte Lösung als die zukunftsträchtigere positioniert. Einen Freigabetermin für Team Developer 2006 gibt es also erwartungsgemäß noch nicht, und viele der von Fecher betreuten Entwickler rechnen nicht mehr damit, dass es diese Version geben wird.
Wechsel der Plattform
"Team-Developer-Anwender mit einer klaren Microsoft-Strategie kann Unify nicht bedienen", so das Resümee von Fecher. Sei- ne Empfehlung lautet, die Gelegenheit zu nutzen, um die Auswahl der Entwicklungsplattform grundsätzlich zu überdenken. Hier liegt der Wechsel auf .NET nahe, zumal die Ice Tea Group, die in Deutschland durch Fecher vertreten wird, eine automatisierte Migration anbietet, bei der SAL-Quellcode in die Programmiersprache C# übersetzt wird.
An Erfahrung fehlt es Fecher nicht. Die Firma erhielt von der Hildesheimer nGroup den Auftrag, die von Microsoft übernommene ERP-Anwendung "Apertum" auf die Zielplattform .NET Framework 2.0 in Kombination mit Visual Studio 2005 zu migrieren. Die nun unter "eEvolution" vertriebene betriebswirtschaftliche Lösung hat eine lange Geschichte.
Ursprünglich wurde sie in Guptas 4GL-Sprache "SQLWindows" erstellt, die seit fast 20 Jahren die Grundlage für viele Geschäftsanwendungen in den unterschiedlichsten Branchen war. Das Werkzeug bot seinerzeit durch eingebettetes SQL erhebliche Vorteile im Zugriff auf Datenbanken gegenüber anderen Tools, wurde aber in den letzten Jahren durch mächtigere Sprachen wie Java und C# zurückgedrängt.
Ice Porter übersetzt
Inzwischen ist bei der Ice Tea Group unter dem Sammelnamen "Porting Project" das Werkzeug "Ice Porter" entstanden, das auch bei der Apertum-Migration eingesetzt wurde und auf Basis eines Portierungs-Frameworks SQLWindows-Code vollautomatisch in C# übersetzt. So einfach dies klingen mag: Man darf nicht übersehen, dass es sich letztlich im wahrsten Sinn des Wortes um ein Porting Project handelt, das aus mehreren Phasen besteht. Wichtige Meilensteine dort sind zum Beispiel die kostenfreie Grobanalyse, die den Umfang der Anwendungen und etwaige Besonderheiten erfasst und mit einer groben Aufwandsabschätzung schließt. Auf Basis eines "Inventory"-Tools erfolgt eine Feinanalyse, die mögliche Problembereiche und Abhängigkeiten erfasst, so dass ein verbindlicher Preis und Zeitrahmen für das Projekt erstellt werden kann.
Manuell nacharbeiten
Erst dann kommt Ice Porter zum Einsatz, um die einzelnen Module und Reports einer Anwendung zu übersetzen und daraus Visual-Studio-Projekte zu erzeugen. Dieser Vorgang wird eventuell mehrmals wiederholt, um eine möglichst hohe Übersetzungsrate und bestmögliche Codequalität zu erhalten. Unter Umständen sind Eingriffe des Portierungspartners nötig, seien es kleinere Änderungen am SAL-Code oder am Übersetzer selbst. Das Ergebnis sind kompilierbarer C#- oder VB.NET-Quellcode sowie nach Crystal Reports konvertierte Berichte, die in den entsprechenden Visual-Studio-Projekten vorliegen. Schließlich muss noch der Code implementiert werden, der sich nicht automatisch portieren ließ. Das Projekt schließt mit der Testphase und einem optionalen Training bezüglich der Architektur des Porting Project Frameworks. (ue)