Re-Engineering
Immer mehr Anwendungen kommen in die Jahre. Nicht, dass sie nicht mehr ihre Funktion erfüllen, aber die Technologie hat sich weiter entwickelt und immer weniger passt noch zusammen mit der alten Software. Die eingesetzten Produkte sind schon lange abgekündigt, es gibt keinen Support mehr und auch die Ersatzbeschaffung von Hardware bereitet immer mehr Schwierigkeiten. Etwas Neues muss her.
Doch was wird aus dem ganzen Know-How, das man mühsam all die Jahre in die Software hat einfließen lassen? Kann man das nicht irgendwie in die aktuelle Technologie retten?
Man kann!
Den Schatz heben
Wenn man ein Re-Engineering-Projekt beginnt, weiß man sehr genau, was man will. Schließlich liefert die bestehende Software eine perfekte Vorlage. Doch wenn das Projekt dann endlich abgeschlossen ist, stellt man erstaunt fest, dass die neue Software eigentlich nicht mehr viel mit der alten gemeinsam hat.
Was ist da bloß falsch gelaufen?
Keine Sorge, besser konnte es gar nicht laufen!
Die Kunst beim Re-Engineering besteht darin, das Know-How der Altanwendung wie einen Schatz aus tiefer See zu heben. Dabei interessieren wir uns nur für den Schatz und nicht für das Schiff, das mit dem Schatz untergegangen ist.
Klingt einfach? Ist es aber nicht.
Lösungen unterliegen immer der Beeinflussung durch die jeweils nutzbare Technologie. Eine Kaffemühle aus dem 19. Jahrhundert unterscheidet sich grundlegend von den Geräten, die wir heute zum Kaffeekochen verwenden. Die eine kann den Kaffee nur mahlen. Die heutigen servieren ihn auf Knopfdruck duftend in der Tasse. Hätten wir beim Re-Engineering der Kaffeemühle nur die Technologie ersetzt, hätte sie zwar statt der Handkurbel einen Elektromotor bekommen, aber sie könnte immer noch keinen Kaffee brühen.
Alte Software ist voll von solchen Kaffeemühlen. Um den Schatz zu heben, muss man die Kaffeemühlen nicht nur finden, man muss auch verstehen, was das eigentliche Ziel war, das der Entwickler von damals hatte, aber nur teilweise oder nur sehr umständlich realisieren konnte, weil ihm die passende Technologie fehlte.
Um das zu erkennen, muss man wissen, wie die Dinge sich entwickelt haben. Ohne die entsprechende Erfahrung weiss man das aber nicht.
Von 4GL zu OOP
Was sich anhört wie zwei Fachabteilungen eines Krankenhauses, ist der Klassiker bei Re-Engineering-Projekten. In den 80ern entstanden die sogegannten 4GL-Sprachen, die gegenüber den bisherigen Sprachen der dritten Generation, den 3GL-Sprachen,
für bestimmte Anwendungsarten erhebliche Zeit- und damit Kostenvorteile brachten, weil sie durch ihre Spezialisierung weniger Codezeilen benötigten. Besonders beliebt sind diese Sprachen als Erweiterung von Datenbanken, wo sie vor allem auf die Erstellung
von Benutzerschnittstellen sowie von Druck- und Auswertungsprogrammen spezialisiert sind. Dieser Typus kommerzieller Anwendungen ist weit verbreitet und wird nach und nach durch aktuelle Technologie ersetzt, i.d.R. mit Mitteln der sogegannten Objektorientierten Programmierung, der OOP.
Als wir selbst auf OOP umstellten, zu einer Zeit als woanders noch viele neue Projekte mit 4GL gestartet wurden, stellten wir fest, dass in der schönen neuen OO-Welt auch nicht alles Gold ist, was glänzt. Bis heute machen viele Programmierer bei der Umstellung ihrer Altanwendung auf OOP Erfahrungen, die am ehesten mit einem Zehnkämpfer zu vergleichen sind, dem man Arme und Beine auf den Rücken gebunden hat.
Weil wir nicht einsahen, warum man in bestimmten Anwendungsbereichen Rückschritte hinnehmen soll, haben wir beschlossen, das Beste aus alt und neu zu verbinden. Dieses Wissen haben wir in unser Java-Framework Tentackle einfließen lassen. Damit können wir wieder unsere Arme und Beine benutzen. Nur Kaffeekochen kann Tentackle noch nicht.