Invasive Techniques

Invasive approaches, where the legacy application code is modified, are inherently much more powerful and flexible. Business functions can be separated from workflow and implemented as components that expose specific business services. However, modifying legacy applications by hand runs the risk of introducing errors into production systems, since it is extremely difficult to analyze existing code and extract all the business rules. A new class of powerful transformation tools for automated object-based transformation makes invasive techniques much more reliable, cost effective and attractive.

Non-invasive Techniques

Non-invasive techniques enable business functions embedded in existing code to be accessed through new interfaces, and are promoted by their vendors as being low risk and economic solutions. However, the front-ends required to handle the mapping of client requests to legacy functions are generally complex and fragile. Non-invasive methods offer only short term solutions to the problem of integration with new technologies, since they do nothing whatsoever modernize the structure of the underlying applications and access methods. They simply postpone the day when these fundamental changes must be made, and the investment in the front-end mapping discarded. Furthermore non-invasive solutions do not scale well, and cause major maintenance problems in the front-end mapping if revisions are made in the legacy code.
Non-invasive techniques are appropriate, however, when applied to object code acquired as a "packaged" solution, or where the source code has been lost.
Non-invasive techniques include:

Wrappering

Wrappering allows existing mainframe and UNIX applications to be made available to the network as components. By "wrapping" code round application subprograms they expose themselves, and behave like, Java or DCOM components. This technique enables the construction of new, component based applications without rewriting or changing existing code, making legacy applications accessible on the Web.
A wrapper can be resident on the host from where it is served as a Java Bean or accessed via DCOM from a client. This is called server-side wrapping and prerequisites a suitable environment on the host to support the wrapper (e.g. JVM, OS/390 Open Edition). Alternatively the wrapper can reside on an appropriate client platform (client-side wrapping), whereby subprograms on the server are accessed by Remote Procedure Calls (RPC).
Wrappers are generally delivered as features of a middleware product that also handles the network communication, message queuing, security, integrity etc. This requires additional, complex product knowledge, programming resources and on-going maintenance effort and costs at the host site. Further disadvantages are that changes to the source application require wrapper regeneration, leading to versioning problems and that the middleware introduces protocol conversions during message transfer, compromising the robustness of the solution.

Back to the list

Middleware

Middleware is a term used to describe messaging and transaction processing monitors that connect web and e-Business application servers with legacy systems at a low level using system-to-system mappings.
Most middleware products also include connectors to common application interfaces and database access methods. They can provide Enterprise Application Integration (EAI) - that is: system-to-system integration between legacy systems and web and e-Business applications based upon the underlying middleware.
This assumes that the legacy systems already provide suitable application programming interfaces (APIs). Some disadvantages of middleware solutions have been briefly described above.
There are many examples of middleware offerings, including:
ActiveWorks, Cross Worlds, MQSeries from IBM, AQ from Oracle, EntireX from Software AG, TIB/ActiveEnterprise from Tibco and Vitria’s Businessware.

Back to the list

Screen scraping

Screen scraping software allows a PC to intercept character-based data from a mainframe and present it, field for field, as an easier to understand graphical user interface
Screen scraping in its simplest form consists of a terminal emulator installed on a PC, together with presentation software. The PC communicates directly with a legacy application via the terminal emulator, which causes it to appear to the host application as a "green screen" device. The screen-scraping software then converts the block-mode communication into a GUI representation on the PC. Newer screen scrapers present the information in HTML, so that it can be accessed via a web-browser. This simply provides the host application with a colorful, graphical user interface (putting lipstick on a pig!). Such screen scrapers are quick to implement, but extremely fragile, since any unexpected message from the host can confuse the presentation software.
Examples of screen scrapers are Rumba from NetManage, Flashpoint, Mozart and Intelligent Environments.
More advanced screen scraping techniques are more robust, converting communications with the host into events that can be handled on the PC by VisualBasic or PowerBuilder applications. These provide sophisticated error-handling, but require much more effort to implement. Screen scrapers in this category include Mitem View.
All screen scrapers suffer from the disadvantage that they do nothing to improve the structure of the host application and generally degrade its performance. Any modification whatsoever to a host screen image requires modification to the screen image on all the PCs where it is resident. Screen scraping must be regarded as a short-term visual improvement to an application, with expensive maintenance implications.

Back to the list

Packaged applications

If the costs or risks associated with retaining and maintaining a legacy application are perceived as too high, then a corporation may decide against any of the above methods. An alternative to redevelopment of the application can be the replacement of the legacy system with an Enterprise Resource Package (ERP application), purchased from a vendor such as SAP, Baan or PeopleSoft. Such packages provide access to their features via APIs, and increasingly expose their features as components. This makes a hybrid transformation/ERP-acquisition project possible.

Back to the list

Back to the list