Re-Engineering
More and more applications are getting outdated. It’s not that they don’t work anymore, but the technology has constantly advanced and integrating the old software with new components becomes a more and more challenging task. Whether or not the products are discontinued, adequate service isn’t available anymore and getting spare parts is like finding a needle in a haystack, it’s time for a change!
However, what about the know-how that has worked its way into the old software over the years? Is there a way to save it and to run it with the latest technology?
There is!
Unburying the treasure
When starting a reengineering project, the requirements are known very precisely, because the old software yields a perfect template. However, when the project is finished, the new software usually will not have much in common with the old one anymore. What the heck went wrong?
Nothing went wrong. It couldn’t have gotten any better!
Reengineering is the art of salvaging the know-how like a treasure from the deep sea. By doing so, we only care for the treasure and not the ship that sank with the treasure.
Sounds simple? It isn’t!
Finding a solution is always influenced by the current technology available at the given time. A coffee mill from the 19th century is significantly different from the kind of devices we are using today. The old mill is only capable to grind the coffee. The modern machines serve the coffee ready to drink! If we just would have replaced the technology, the new mill probably would have gotten an electric motor instead of the crank handle, but it still won’t be able to cook the coffee.
Old software is full of such old coffee mills. In order to salvage the treasure, you have to understand what the developer’s original intention was, and what he probably wasn’t able to implement, because of the technological restrictions during his time. To realize that, you have to know how the things have developed. However, without this knowledge and experience, you won’t succeed.
From 4GL to OOP
In the 1980s the so-called 4GL-languages were introduced. These languages were designed for typical database oriented business applications, and provided some advanced features superior to the 3rd-Generation-Languages, resulting in fewer lines of code and, of course, cost. Nowadays, 4GL-applications are redesigned by means of the so-called OOP, the Object Oriented Programming.
When we began with OOP, at the time when others still started new projects in 4GL, we discovered that the grass isn’t always greener on the other side. And still today, developers switching to OOP-languages like Java, make experiences resembling a decathlete with his arms and legs fixed to his sides.
Because we didn’t want to step backwards, we decided to combine the best from the old and the new. This knowledge became the foundation of our Java framework Tentackle. Now we can use our arms and legs again.