The OpenEdge Hive

If the goal of the transformation is dominated by the desire for a new UI, this is less readily achieved by a stepwise approach since converting individual functions tends to result in users require a mix of old and new UI required to complete their work, which can be confusing and awkward. At a minimum, one tends to have to select whole modules for conversion at each step. Since most legacy applications are monolithic in architecture, with UI, BL, and data access all mixed together, such a transformation can closely resemble a complete re-write, at least of the selected modules.

In terms of moving toward compliance with the layered structure of the OpenEdge® Reference Architecture, it is likely that one can replace direct access to the database with calls to new data access objects in a stepwise fashion, but separating the UI from the business logic has the same difficulties as it does in a transformation motivated by the UI alone.

Thus, we have two quite different strategies for moving from a legacy application to one of a more modern technology and architecture. Traversing the upper two legs of the triangle we begin with the extremely difficult task of extracting abstract model information from the concrete legacy application, which is currently not susceptible to much automation. However, once we arrive at the same kind of starting model which might have arisen from standard OOAD processes, then we can take advantage of MDA to help write the new application and the revised application can be as modern in technology and architecture as we like. Alternatively, traversing the lower leg of the triangle, we can have good success with gradual stepwise transformation if our primary goal is moving to a service-oriented architecture, but we are less likely to find an easy stepwise path to replacing the user interface.

There are some transformation projects which can be thought of as taking something of a middle ground. These are typified by projects in which one of the primary goals is replacing the user interface and the goal is to implement this change across the entire application. Some of these projects make some use of MDA to generate at least parts of the new application, but many are almost entirely manual. It is often the case that those following this path are disappointed by the amount of code which can be harvested, but if one considers the discussion about intrinsic framework above and the dramatic change in the fundamental architecture which is being undertaken, it should perhaps not be surprising that the amount of harvestable code is modest at best.

The productivity gains possible through the use of generator technologies such as MDA are dramatic. There is an up-front, one-time investment required to develop the framework and transforms, but once developed these can be applied to multiple projects with only small incremental investments to accommodate new requirements. The big obstacle to the efficient use of such technologies for transforming legacy applications is the limited toolset available for the automated extraction of abstract model information from the legacy code. If improvements can be made in that area, then it is almost certain that a full re-invention of the application can be accomplished by this process less expensively and more rapidly than through the sort of mass re-write process typical of UI replacement projects today. As an alternative, one can achieve significant restructuring of an application by the stepwise conversion to SOA approach as long as one is cautious or patient about replacing the user interface.