Don't Replace -- Extend: Why Leveraging Your Legacy Systems Is the Way to Go

If you're feeling bored with your legacy system and want to try new, more fashionable technologies, wait. Extending legacy systems can provide a sleeker look and feel, without the high price tag.

• 06/01/2001

Oracle’s Larry Ellison once said every business should dump their legacy systems and replatform. (You can guess whose database software he recommended.) Ellison’s recommendation, though, is just one such piece of advice to come down the pike. In truth, any business that replatformed every time a new technology became popular probably would have gone bankrupt because of the astronomical costs and lengthy development time.

When a legacy system’s core processing is inadequate, that’s a compelling reason to adopt a new platform. But most legacy systems are sound, and going to a new system is invariably expensive, and often unwarranted. Moreover, when you rewrite proven applications for a new platform, there’s always a substantial risk they won’t work well, at least not for a long time.

Using specialized tools and methodologies, experts can extend and transform most legacy systems into fast, contemporary systems with all the features today’s users demand. You can often accomplish everything you could with new technology, but much more quickly and at a fraction of the cost. By leveraging and extending legacy systems, you can accommodate e-commerce and CRM functions and provide good response time. In short, you throw out the dirty bathwater – but not the baby.

Functioning legacy systems are enormously valuable information assets. They contain data access methods and core business logic that works, and they are centralized and easy to control. Having stood the test of time and evolved, they provide the most accurate statement of current business practices.

Typically, they fall short in three areas: user access, usability and navigation. Applications that cannot access the Web or local area networks that present cryptic green screens, forcing users to scroll through multiple screens are clearly inadequate. A legacy system is like a box full of beautiful pictures, but the poor user has only a pinhole to peek in. Instead of throwing out the box and the artwork, with legacy extension, you just replace the pinhole with a big, bright window.

Cost is also a compelling reason to extend rather than replace. Let’s say your company invested $500,000 in its legacy system in 1997. Today, it’s no longer meeting your needs, but replacing it might cost one million dollars. If you can extend its life by five years with an investment of $50,000 to $100,000, you’ve cut your annual cost of ownership almost in half.

For companies deploying e-commerce applications, integrating legacy systems is absolutely crucial. Companies invariably run into serious business problems when their new e-commerce applications only support the Web and fail to integrate smoothly with existing core systems. It’s like having your left and right hand each controlled by a separate brain. If there’s also an insufficiently integrated CRM system, it’s like having three hands and three brains. In contrast, if you can expose legacy business processes, such as order and customer-service processing, to the Web you can leverage your existing investment and avoid these problems.

Every legacy system offers unique technical challenges, and every organization has unique needs. The best legacy extension methods vary case by case.

Evaluation always begins with the users. What’s important to them? What business needs should the system support? What information and functions do your users need? Once you’re crystal clear on your users’ requirements, survey the IT staff for its input.

Perform a careful technical assessment on your legacy system. Is it technically sound and worth fixing? Can it be modernized? If source code is missing, or if for some other reason too much work would be needed, updating may not be feasible. This, though, is unusual: Most legacy systems can be updated.

Then, choose the right legacy extension method or combination of methods. In doing so, you’ll be considering three main approaches: Web emulation, screen-scraping and the invasive approach, also known as reengineering.

If your company has a first-rate mainframe application, and the only problem is Internet access, Web emulation can be the optimal solution. This involves setting up a Web server, installing software to Web-enable the legacy system and providing the URL to end users for access.

Quick and relatively inexpensive, "Webulation" does not produce dramatic improvements in usability. Its advantage is that it requires no rewriting of mainframe code and really, no development at all. Because the emulator is installed at the Web server, you don’t have to distribute software; your customers use their existing browsers. On the other hand, you’ve done nothing to make your host-based application any easier to use. To accomplish the latter, you need to turn to one of the two other categories – "screen-scraping" and reengineering – or a combination of both.

Let’s consider screen-scraping first. (Some people find this term pejorative. They may prefer to call it enterprise application integration (EAI), even though that term can also be interpreted as including reengineering.) Screen-scraping is non-invasive: No mainframe code is altered. And it’s become surprisingly powerful, provided its implementation is creative and carefully carried out.

In their most basic form, screen-scrapers do just that: "scrape" various screens and present the data in a more user-friendly way, via a standard Windows or Web interface, complete with widgets, lists, radio buttons, and so forth. Most screen-scrapers also enable you to reengineer how the application behaves for the user, while still maintaining the back-end host navigational flow. The transformation can be so complete that PC users have no idea they’re tapping into the mainframe. To them, it all looks and acts like any other up-to-date application.

Early screen-scrapers employed fairly simple technology, and as a result, complicated scripting was required to implement them. Today’s sophisticated tools drastically reduce such scripting, thus speeding development. These tools use rules and event-based screen recognition and learning host navigation as the developer actually navigates through the application. Essentially, the newer screen-scrapers act like 3270 or 5250 middleware. The screen-scraper resides on a server, and when the user makes a request, the scraper retrieves the data, much like other middleware. Some tools can even present a Graphical User Interface (GUI) based on what they detect on the mainframe.

Regardless of the tools you use, engineering a successful application using this technology requires experience. Screen-scraping applications have sometimes been viewed as slow or inflexible. This often results from the inexperience of application designers with screen-scraping technology: They are often overly influenced by the structure and navigation built into the existing legacy application, and fail to think "outside the box" in the design process. Managing the user experience is key and must be a central focus of the development effort.

There are dozens of software tools for legacy integration and extension. All provide benefits, but the best ones generate Java source code, making them more suitable for enabling Web applications. Of all the options available, Java source code provides the greatest flexibility and is easiest to change and modify in an open manner.

Screen-scraping can be the optimal solution in many environments, but there are limits on what can be accomplished with it. So if it can’t do the job for you, you’ll need to go further.

This third legacy extension technique – the invasive or "peer-to peer" reengineering approach – is more time-consuming and expensive than screen-scraping. But it also offers the greatest potential benefits. It involves enabling legacy applications to "speak" TCP/IP, the language of the Internet, using an Application Programming Interface (API).

The amount of reprogramming required to accomplish this will depend on how your legacy application has been written. In a best-case scenario, just one program manages screen-handling. In this case, you only need to modify this one program to work with TCP/IP and to recognize when an inquiry is from a terminal and when it’s arriving via TCP/IP. If an existing application’s architecture doesn’t exhibit this modularity, you may have to TCP/IP-enable all – or many – of the application programs you intend to use.

This full-blown approach to legacy extension offers several advantages over screen-scraping. Since TCP/IP-enabled modules can send all required data at once, without navigating amongst mainframe screens, they can deliver huge amounts of data to the client quickly. This dramatically reduces response time.

Additionally, if done properly, this method can produce reusable business objects. Say a bank’s legacy systems include a mortgage amortization module. The module, written in COBOL, retrieves information from an IMS database and performs complex calculations based on that data. It’s old technology, but it works. Using this methodology, the company can create a reusable component that is accessible to any application – internal or external – whether it’s legacy, client/server or Web-based.

If you apply this process broadly, you can significantly lower your costs of ownership by eliminating redundant code, simplifying maintenance and accelerating new application development. At the same time, you can make your IT systems far more responsive to changing business requirements.

Sometimes, the best solution calls for both screen-scraping and invasive techniques. For instance, suppose you need to update a legacy order-entry application. After analyzing your business requirements, you determine that many of the system’s new functions have a one-to-one relationship with existing legacy screens. Screen-scraping will be ideal here, assuming that it can meet your response time requirements.

In other cases, new functions cannot easily be mapped to existing screens. In still other cases, you may be totally redesigning your business processes: The processes embedded in your mainframe code are no longer relevant. Here, of course, the more invasive approach is clearly the best option.

The key point is this: You can make these decisions one function at a time, co-mingling screen-scraping and reengineered functions in the same application – thereby minimizing costs by rewriting code only where you must, or where doing so offers the greatest business value.

From the developer’s standpoint, the first part of the legacy extension process is to create a middleware layer that serves both business rules and data. In doing so, developers can leverage the mindset and skills they’ve already learned in creating middleware for database applications – as well as the back-end middleware code that may already be serving their client/server applications.

As they extend legacy applications, developers should be wary of application server approaches that deliver HTML-based user interfaces to clients via Active Server Pages, JavaServer Pages, servlets and similar approaches. In our experience, such applications compromise both performance and usability, are often inferior to the client/server applications they replace and waste the processing power and bandwidth that are increasingly available on the desktop. A better solution is to create user interfaces with Java.

Your instincts are correct: replacing the code that drives your business is high-risk behavior.

In certain cases, replatforming or replacing code is clearly necessary to move your business forward. A poorly designed database application or business process will work just as badly when it is accessed from a browser.

In far more cases, it is clearly not necessary. If your core processes work well, but must be Web-enabled, or if you need to improve the productivity of your application’s users, there’s no need to change the aspects of your system that are already working well.

You can leverage the Web and other new technologies, while reusing and adapting the IT infrastructure you’ve worked long and hard to build, thereby minimizing costs and risk, while maximizing business impact. You can even build next-generation applications that are intrinsically integrated with your legacy systems, so you won’t have to manage synchronization or write additional interfaces later.

Replatforming when it isn’t necessary is like building a new house just to install a new set of windows. Using today’s legacy extension techniques, you can avoid such costly missteps, putting in bright new windows where needed, without dynamiting the frame and foundation of your familiar, cozy house.