The OpenEdge Hive

In any transformation effort there may be selected parts of the application that are appropriate for this kind of complete re-invention. This might be, for example, a module which was known to need substantial redesign anyway, so that taking the approach of doing a fresh implementation from core principles can be less time-consuming than doing an in-place redesign. Such selective re-invention tends to work only when there is a well-identified and well-separated module that is appropriate for more intensive upgrade.

While such re-invention is obviously desirable, since the resulting application is fully modernized, many companies cannot afford the massive effort required. The alternative is to perform some kind of stepwise transformation, making incremental improvements over a period of time. It should be noted that applying a stepwise approach is likely to require more total effort and a greater length of time than direct re-invention, if one carries it through to the same end point, but most companies utilizing a stepwise approach only make partial transformations, thus moderating the cost and effort.

One of the forms of stepwise transformation which has become popular in recent years is a progressive migration to a service-oriented architecture (SOA). In this approach, one typically begins by implementing an Enterprise Service Bus (ESB) to serve as the messaging backbone and then focuses on a small series of key projects to convert them from the legacy form to a service. One classic example of this kind of re-engineering might be an application which had some complex body of code which was more or less replicated in multiple modules or systems, each differing slightly in functionality. Since changes in one version need to be manually replicated in the other systems, such situations are error prone and labor intensive. By centralizing all versions of this code in a common service, which is then called by all of the consumers, future changes can be implemented with consistency and lack of disruption. The loose coupling characteristic of SOAs means that the system is more resilient to change, typically allowing individual services to be upgraded as needed without changes to other services.

In such progressive SOA re-engineering, there is often a very high level of harvesting of code since the approach tends to be more one of putting a wrapper on existing code than it is one of creating entirely new code. At some point, the “insides” of a service may get rewritten if this is indicated, but in many cases one simply proceeds with the old code wrapped in a new interface and the architectural shift is in the move from a tightly coupled monolithic system to a loosely coupled collection of services. This is very different from the architectural shift which results from re-invention. While re-invention might include a shift to SOA, it also produces changes to all the details of the application as well. E.g., in the ABL world, it would not be surprising to find the code inside a service developed by the progressive approach continuing to use shared variables, while these would never appear in a re-invented application.

The two most common goals of transformation are a move to SOA and separation of user interface (UI) from business logic (BL), usually accompanied by a shift in the technology for the UI, e.g., to a web or other non-ABL client. A stepwise approach is easily applied to a move to SOA since all unmodified parts of the application continue to work as they did before and the changes are primarily “behind the scenes”. When all functions in a given area have been converted to services, it becomes quite easy to provide a new UI for those functions because the desired separation of UI and BL has been achieved by moving the BL into services. But, this tends to defer the UI shift for a significant period while the conversion to services takes place and tends to only allow the conversion of specific clusters of functions rather than an application wide shift. This can meet the needs of some businesses, e.g., where the interest in a new UI is concentrated on a limited number of functions such as web access for customers for creating orders. But, it does not provide for an overall shift in the UI for an application.