Die Verfechter der 4GL-Philosophie werden nicht müde, zu betonen, durch die von ihnen propagierten Produkte werde das vielzitierte Wartungsproblem obsolet. Andreas Bereczky hält dieser Argumentation entgegen, daß Neuschreiben keineswegs immer die wirtschaftlichere Lösung bedeute.
Zweijahrzehnte Software-Entwicklung haben ein riesiges Portofolio von Anwendungen geschaffen, die für viele Unternehmen lebenswichtige Wettbewerbsvorteile bedeuten. Es sollte daher niemanden überraschen, daß die fortlaufende Erweiterung und Pflege dieser Systeme höchste Priorität hat. Überraschend ist jedoch, daß der zeitraubende und fehleranfällige Prozeß der Anpassung und Erweiterung fast nichts vom technologischen Fortschritt der letzten zwanzig Jahre mitbekommen hat und neue Vorgehensweisen, etwa die Sprachen der Vierten Generation, diese Arbeit bislang kaum unterstützen können.
Eine Untersuchung der Gartner Group belegt, daß EDV-Abteilungen durchschnittlich 80 Prozent ihrer Zeit damit verbringen, das Leben existierender Systeme zu verlängern. Man erwartet, daß diese Zahl sich in den nächsten Jahren auf 90 Prozent erhöht.
Es gibt viele Ursachen dafür, daß es so schwierig ist, existierende Systeme weiter zu entwickeln. Die meisten Mainframe-Anwendungen sind in Cobol geschrieben, viele wuchsen sich mit der Zeit zu sehr großen und komplexen Systemen aus. Cobol ist die Standard-Programmiersprache auf Mainframes, man schätzt, daß heute weltweit etwa 80 Milliarden Zeilen Code "in Produktion" sind.
Die Sprache ist jedoch geschaffen, um der Neuentwicklung Kraft und Flexibilität zu geben, nicht für einfache Erweiterungen, Änderungen und Anpassungen. Viele der existierenden Systeme befinden sich jedoch seit Jahren im Einsatz und sind durch die Hände vieler verschiedener Software-Autoren gegangen. Manche Programme sind sicher älter als die Programmierer, die heute daran arbeiten.
Nur wenig Computerunterstützung steht dem Programmierer bei seiner Arbeit mit existierenden Systemen zur Verfügung - Sprachen der Vierten Generation greifen hier nicht; folglich muß man fast alles manuell durchführen.
Den Prozeß des Erweiterns existierender Systeme, die Beseitigung alter Fehler und das Hinzufügen neuer Funktionen wird mit Re-Engineering bezeichnet und umfaßt die Schritte: Feststellen des Bedarfs für Erweitern und Reparieren, Untersuchen des Systems, Codieren/Compilieren, Test/Debug und Dokumentation/Qualitätssicherung.
In der Realität läuft dieser Prozeß nie einfach und sequentiell ab. Während der Programmierer beim Durchlaufen des Zyklus mehr und mehr über die Programme erfährt, macht er zwischendurch Verbesserungen und Anpassungen. Ergebnisse von Tests erfordern häufig Änderungen im Programm, im Design oder gar in der Spezifikation. Nach diesen Eingriffen werden weitere Testläufe notwendig. Hier läuft also ein interaktiver Prozeß, bei dem Verzögerungen entstehen können. Man benötigt im Schnitt sieben bis zwölf Versuche, um ein Programm durch die Phase des Compilierens zu bringen.
Nach einer Studie der IBM über den Re-Engineeringzyklus verbringt der Programmierer mehr als die Hälfte seiner Zeit damit, das Programm zu verstehen, zu analysieren. Er "spielt Computer" und versucht, die komplexe Logik und den Datenfluß zu begreifen, indem er durch tausende von Code-Zeilen blätterte Farbstifte, Heftklammern und Post-it-Notes benutzt.
Trotz der Bedeutung des Re-Engineering und trotz dessen Einfluß auf die Ressourcen der EDV-Stäbe konzentriert sich die Software-Industrie darauf, Unterstützung für die Entwicklung neuer Systeme anzubieten. Die meisten Techniken, die als Re-Engineering beschrieben werden, setzen an der falschen Stelle an. Sie automatisieren die Schritte, die am wenigsten Zeit brauchen und sie umgehen oder eliminieren existierenden Code, statt ihn zu verbessern. Vor allem die Sprachen der Vierten Generation geben hier keine Hilfestellung: Sie unterstellen, daß die beste Lösung für das Re-Engineering immer ist, den Code neu schreiben. Aber man kann Kosten und Zeit für Neuschreiben nicht rechtfertigen, wenn das bereits existierende System seine Aufgaben im großen und ganzen erfüllt. Nach einer Schätzung der IBM müssen lediglich sieben Prozent der existierenden Anwendungen neu geschrieben werden.
Eine Alternative bietet sich in einer neuen Generation integrierter Werkzeuge an, die die zeitraubenden Aufgaben des Re-Engineering automatisieren. Diese neue Generation entspricht exakt den 4GL und CASE-Tools, aber eben für existierende Software: Beispielsweise funktioniert Re-Engineering interaktiv und betont die Analysephase - im Gegensatz zu alten Wartungskonzepten, die vor allem aus Test- und Debug-Instrumenten bestanden. Der Automatisierungsgrad reicht hinauf bis zu 75 Prozent, dies wird vor allem bei der Analyse bestehender Software erzielt. Auch kann man Re-Engineering-Konzepte in die CASE-Welt und in Sprachen der Vierten Generation integrieren. So wird beispielsweise auf der Basis eines fertigen Mainframe-Produktes für MVS-Anwendungen jetzt ein Re-Engineering vom PC bis zum Mainframe entwickelt - mit gleichem "Look and Feel". Dieses Konzept paßt genau zu den Vorstellungen der IBM und in AD/Cycle hinein.