Es gibt noch eine Menge guter und ausgereifter Applikationen, die beispielsweise in Gupta Team Developer oder VB6 geschrieben sind – allein im deutschsprachigen Raum gehen wir von weit über tausend kommerziellen Anwendungen aus. In Anbetracht der über viele Jahre investierten Arbeitszeit unzähliger Entwickler mag man es kaum aussprechen, aber diese Anwendungen – beziehungsweise ihre technische Basis – sind schlicht und einfach am Ende ihrer Lebenszeit angekommen. Jedem muss klar sein, dass die Wartung einer solchen Applikation die Pflege eines Oldtimers bedeutet. Diese Pflege wird immer teurer und unzuverlässiger; moderne Infrastrukturen und Ressourcen lassen sich nicht nutzen. Analysiert man die Situation ganz sachlich, wird einem schnell bewusst, dass man sich hier schon seit einiger Zeit in einer Sackgasse befindet.
Der erste Plan sieht in der Tat meistens so aus. Eine Neuentwicklung erscheint als einzig sinnvoller Weg, die technische Plattform ist .NET, VB.NET der alten Programmiersprache am nächsten. Die Entwicklungsabteilung soll geschult und verstärkt werden. Parallel zur Wartung der alten Applikation wird dann neu in VB.NET implementiert. Das erklärte Ziel lautet, endlich alle Altlasten zu beseitigen und „richtig“ neu zu implementieren. Vielleicht ist sogar vorgesehen, sich für Engpässe oder als Starthilfe externe Unterstützung einzukaufen. Trotzdem klappt dieser Plan in der Praxis nur in den seltensten Fällen. Und auch dort, wo es funktioniert, werden Zeit- und Kostenrahmen meist um ein Vielfaches überschritten.
Einer der häufigsten Gründe ist, dass das Team erst Know-how auf der neuen Plattform aufbauen muss. Werden externe Spezialisten für die Neuentwicklung mit ins Boot geholt, besteht wiederum fast immer das Problem, dass sie nicht von Anfang effizient unterstützen können, da das anwendungsspezifische Wissen nicht ausreichend dokumentiert wurde. Um dieses Fachwissen zu vermitteln, müssen Kräfte aus dem eigenen Team gebunden werden.
Oft unterschätzt wird auch die Erwartungshaltung der Benutzer, welche die Altanwendung schließlich über Jahre nutzen. Eine neu entwickelte Applikation bedeutet für die Anwender hohen Lernaufwand. Auch wenn aus Entwicklersicht alles neu, besser und schöner ist, bleibt die Akzeptanz oft hinter den Erwartungen der Entwickler zurück. Zudem ist eine Neuentwicklung so gut wie nie fehlerfrei. Die Endanwender sind mit eingebunden, testen und entdecken Fehler. Das kostet Zeit und Nerven.
In jedem Fall bedeutet eine Neuimplementierung enorme Aufwände. Das damit verbundene Risiko ist schwer kalkulierbar und wird oft verkannt. Die Herausforderung beginnt ja schon bei der Auswahl der unüberschaubaren Menge an Technologien, die zum Einsatz kommen könnte. Ohne ein sehr tiefes fachliches Wissen über diese Technologien und die Anwendung selbst, können solche Entscheidungen nicht optimal getroffen werden.
Ob Gupta, VB6 oder Access – im alten Projekt sind bereits alle Informationen und Definitionen enthalten, die wir für eine erfolgreiche Portierung brauchen. Die einzige Basis, die wir für eine automatisierte Migration benötigen, ist also der Quellcode. Allerdings geht es nicht primär darum, jede einzelne Zeile der Altanwendung auf die neue Plattform zu übertragen; vielmehr müssen die Definitionen, die das Gesamtbild der Anwendung ausmachen, portiert werden. Dazu hat fecher das passende Regelwerk – ein regelbasiertes Tool, das den entsprechenden .NET-Code erzeugt. Fast alle bisher verwendeten Basis-Controls gibt es genauso oder ähnlich in .NET. Ist das einmal nicht der Fall oder handelt es sich um Fremd-Controls, nutzen wir definierte Regeln für eine identische Darstellung in .NET. So lässt sich das Funktionsgerüst erstellen und die Oberfläche eins-zu-eins abbilden.
Als Ergebnis liefert fecher die altbekannte Applikation, umgesetzt in C# oder VB.NET auf der .NET-Plattform. Sie funktioniert zu hundert Prozent wie die Ursprungsapplikation, aber auf einer neuen Plattform, welche unter anderem die effiziente Nutzung von 64-Bit-Technologie, Multicore-Prozessoren und Servicemodels zulässt. Durch Modifikationen des Migrationsprozesses kann auch eine Web-Oberfläche als Präsentationsschicht generiert werden.
Die streng strukturierte Arbeitsweise und der hohe Automatisierungsgrad garantieren ein Ergebnis von außerordentlich guter Qualität. Aufgabenstellungen werden schlüssig und gleichförmig projektübergreifend gelöst. Die Inline-Dokumentation bleibt komplett erhalten und wird sogar um Standards ergänzt. Der Code ist so gut strukturiert und geformt wie im Referenzprojekt.
Das ist eine Frage, die mir häufiger gestellt wird; auf den ersten Blick scheint die Eins-zu-eins-Migration keinen fachlichen Mehrwert zu bringen. Prinzipiell ist es ja auch naheliegend, die Anwendungs-Portierung dafür zu nutzen, gleichzeitig auch Altlasten zu entfernen oder neue Funktionen hinzuzufügen. Allerdings ist die Gefahr hoch sich dabei zu verzetteln.
Unserer Erfahrung nach ist es ideal, zunächst mit der fertigen, funktionierenden Lösung auf neuer Plattform zu starten. Nach Abschluss der Anwendungsmigration durch fecher kann diese dann weiterentwickelt und einzelne Komponenten ausgetauscht werden. Die Anwendung kann wachsen und trotzdem funktioniert sie einfach weiter.
Bei unserem Standard-Migrationsverfahren wird maßgeblich der Quellcode modernisiert. Neben der Übersetzung in eine .NET Programmiersprache werden veraltete Strukturen erneuert und eine objektorientierte Syntax eingeführt. Die Oberfläche macht einen moderneren Eindruck, enthält aber nur minimale optische Änderungen. Benutzererfahrung und Menüführung bleiben identisch. Das ist oft das beste Verfahren aus Sicht des Benutzers: Dieser findet sich in der portierten Anwendung direkt wieder – in Bezug auf Lernaufwand und Akzeptanz ein entscheidender Faktor. Doch auf Wunsch kann die Benutzeroberfläche während des Projekts auch angepasst werden. Für solch eine Migration mit Redesign erarbeiten wir gemeinsam mit dem Kunden das passende Konzept. Letzteres haben wir zum Beispiel bei unserem Kunden Amtech Software durchgeführt.
Während sich bei einer Neuentwicklung unter Umständen die schwierige Einführungsphase wiederholt, die schon bei der Implementierung der alten Anwendung eine Belastung war, ist dies bei einer Anwendungsmigration, wie fecher sie durchführt, nicht der Fall: die Anwender benötigen keine Schulungsmaßnahmen und erleben einen weichen Übergang, die Entwickler können in Ruhe Erfahrungen mit .NET sammeln und sich auf neue Möglichkeiten konzentrieren, ohne dass die Gefahr des Scheiterns im Raum steht. Dadurch, dass das Datenbackend transparent bleiben kann, ist in der Einführungsphase oft sogar ein Parallelbetrieb der alten und neuen Anwendung möglich.
Bei realistischer Kalkulation liegt der Migrationsprozess von fecher bei etwa 15 bis 20 Prozent der Kosten einer Neuimplementierung. Die Projektlaufzeit liegt sogar noch weit darunter. Die Dauer kann man nicht pauschal nennen, denn sie ist unter anderem abhängig von der Anzahl der Lines of Code. Als grober Richtwert: Die meisten Projekte, die wir betreuen, benötigen zwischen zwei und sechs Monaten.
In einem ersten Schritt ermitteln wir bei einer kostenlosen Grobanalyse mithilfe eines Tools den Kosten- und Zeitrahmen bereits mit einer 80-prozentigen Genauigkeit. Hier werden auch schon Besonderheiten und mögliche Hürden erkannt, wie zum Beispiel Drittanbieterkomponenten, die die Migration aufwendiger machen.
Passen die Parameter der Grobanalyse, folgt im nächsten Schritt die Feinanalyse. Eine gegenseitige Verschwiegenheitserklärung schafft den notwendigen rechtlichen Rahmen. Nach Sichtung des Source-Codes erarbeiten wir ein detailliertes Konzept und erstellen einen Prototyp, welcher die individuellen Anforderungen fokussiert und die Hauptmaske mit repräsentativen Funktionen enthält. Damit kann man sich ein gutes Bild von der zu erwartenden Performance und Qualität machen.
Wählt der Kunde unseren Projekttyp ‚All Inclusive‘, erstellen wir außerdem ein Festpreis-Angebot für das Projekt, mit einem Jahr Garantie nach erfolgter Abnahme. Ein Projektplan und ein ausführliches Analysedokument runden das Angebot ab. Sie sehen: Niemand muss die Katze im Sack kaufen. Bevor der Kunde den Auftrag erteilt, hat er bereits einen Prototypen seiner migrierten Anwendung evaluiert, kennt die exakten Kosten und hat einen verbindlichen Zeitplan vorliegen. Und fecher übernimmt das komplette Risiko. Wir finden, fairer geht es nicht!
