PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder

PowerBuilder: Article

Legacy Systems: To Extend or Not Extend

Legacy Systems: To Extend or Not Extend

In 1999 millions of dollars were spent preparing legacy systems for the dreaded Y2K meltdown. Thankfully, most of these core computer systems survived the 01/01/00 coding problem. However, businesses now face another issue regarding their legacy systems that in many ways will prove more challenging than simple Y2K code remediation.

IT managers today need to provide customers and employees with access to data stored in legacy systems via the Internet. Unfortunately legacy systems are not "Internet compatible." This leaves many IT organizations facing the question of whether to extend their legacy systems or scrap them in favor of a whole new system.

The good news is most companies probably won't have to destroy their legacy systems just to get on the Internet. There's this notion that because legacy systems are old, they need to be replaced. But if they survived Y2K, chances are they can be modified or "extended" to the Web. The difficult thing is figuring out the best way to get there.

Legacy systems aren't necessarily the big, black boxes we call mainframe systems. The technical definition is any core computer system that's integral to keeping a business running. A business could have a brand new core computer system, and it will still be a legacy system. For the purposes of this article we're talking about older technology, such as mainframes and newer client/ server systems.

The problem with the older legacy systems is that the Internet wasn't important when they were invented. So if companies want to integrate Web-based data retrieval and processing, they can't just hook up a T1 line. The process of providing Internet access to a legacy system is much more complex. That's why businesses think they need to scrap the old in favor of the new, which isn't always the case.

Companies are interested in Internet access to their legacy systems because customers are demanding 24/7 access to their information. For example, people are no longer satisfied with quarterly statements from their 401K plans. They want to be able to go online and get real-time information about their accounts. The same holds true for customers who want to know if a warehouse has a part in stock. They can look online and not worry about delays due to telephone tag or being placed on hold.

Today's world is more self-service. Businesses are running off the McDonald's model of "get your own straw and napkin" when it comes to data. If you're in the business of selling something, it's easier to let customers service themselves with Web access to your core business computer system.

Up until a few years ago, the only two solutions were to scrap the legacy system in favor of a new system or to rewrite all its coding. The word rewrite sends chills up most managers' spines because traditionally it takes lots of time and money. Another problem is many older legacy systems have "black box" logic, which is a big mystery to IT managers. The systems do their job but very few people know how their inner workings function. Huge costs were amassed in the 1990s as people tried to figure out how the old systems worked and struggled to rewrite the coding. These difficulties really left a bad taste in many a manager's mouth.

The good news is twofold. First, rewriting is less expensive now that procedures and precedents have been set over the past few years. Second, rewriting isn't the only solution that preserves a legacy system and makes it Web accessible. The other option is called extension. Instead of writing legacy code on new platforms, technology pros are integrating new platforms with the old legacy systems. This means having a new system running side-by-side with the old one with programs that allow the two systems to communicate.

The legacy system is preserved with little or no modification. Extending doesn't lead to a rewrite of the legacy system, rather it's reframed with phrase changes or new interfaces. When a legacy system is extended, a front end can be added so that customers have Web access to data and a back end, such as a data warehouse, or a business intelligence tool can be added. Either way, the core logic - the "black box" of the legacy system - is not modified.

There are drawbacks to extension. You'll create more complexity in your infrastructure because you're now work- ing with two platforms. In some cases the extension becomes so complex we actually recommend the company swallow the pill and rewrite the whole system. Also, if the IT manager isn't ready to manage a system with two platforms, it's time for a new system.

There are basically six options for a company with a legacy system that's looking to integrate new technologies into its core operations and get to the Web now.

Outside of Extending
1. Prepackaged Solutions
Prepackaged systems can be a great way to make the jump into a Web-based solution. What you do is buy the application, install it, get rid of your old system, and you're done. You have a front end on the Web, and you cut the ties to the old legacy system. These packages are very expensive; however, they aren't very customizable, and there could be a problem during transition. A company could be left helpless if a glitch develops along the way.

2. Automatic Rewriting
Tools exist that read your legacy code, such as COBOL, then rewrite it into Visual Basic or Java. This lets you completely rewrite your old system and move your core system into a Windows-based environment. The scary part comes into play when these types of programs encounter your legacy system's black box area. What happens if part of the black box coding is captured by the tool and rewritten incorrectly? Your system may be changed, and you won't even know until it's too late. This can lead to major problems for your business.

3. Screen Scraping or Enhanced Terminal Emulation
Screen scraping is the least expensive way to extend a system, plus it's fast and tactical. Basically you're using the protocols already in place and piggybacking a new operation on top. You'll have a dot.com component that lets you interface with the Web. However, you're stuck with whatever green screen you had in the first place. This means you can't modify the way you view or interface with the data. A screen scrape only allows you to hook the Web attachment onto the old system. It still looks the same, just Web-based. But if all you need is Web access and nothing fancy, screen scraping could work.

4. Wrapping
A wrap is what its name implies. The legacy system is wrapped by the new back and front ends. By doing this you ratchet up your complexity level. Typically, wrapping is a fine solution if you want to get data into or out of your mainframe via a new system. Wrapping is best suited for a batch-processing environment, such as taking customer orders. You can wrap a SQL system onto the front and back ends of the legacy system. Then create a Web application that takes that data and puts it into a SQL system that dumps into the mainframe several times a day.

The drawback of wrapping is that you can't get complex, real-time data. You can see if an order has been placed, but you can't check its details. Wrapping gives you a buffered legacy environment with new technologies that create a good Web connection. The information can be formed any way the company wants, unlike the limitations of screen scraping. The tradeoff is that the system is now more complicated.

Once legacy data has been restaged into a relational database environment, a variety of Internet development tools can be used to create new Web-based applications. The chosen development platform should be able to address as many back-end data sources as possible. For example, EAStudio from Sybase offers a back-end independent solution for Java development. While offering native drivers for Sybase and Oracle connections, it also provides broader database connectivity through JDBC and ODBC support. This is an attractive feature for managers considering a wrapping strategy to extend legacy data because it allows them to choose the best relational database for their organization. EAServer also provides connection pooling, which can dramatically increase application performance. Pooling of database connections is a must-have feature of any application server because establishing the initial connection is the single biggest drain on database-driven solutions.

Tool sets such as EAStudio also provide IDEs for Java development. Developers can visually create the inherently nonvisual server-side components they need to encapsulate business logic. Sybase has managed to use its mature PowerBuilder IDE for Java development as well. PowerBuilder really introduced the masses to the concept of encapsulating business-processing logic in software classes. Their IDE was one of the first to provide a visual metaphor for developing components. They've done a great job extending this into the Java development arena.

5. Middleware Solutions
Middleware provides direct programmatic access to legacy code and processes. To use middleware you typically introduce a server or middleware system that knows how to talk to the operating environment of the legacy system. Middleware solutions are more appropriate than screen scraping for most business applications.

However, they're technically more challenging and complex because you're brokering a new relationship between the new and old platforms. Middleware allows you to use Java or new languages to program new components to your legacy systems. It allows for real-time data access, which is important for transaction processes and things such as stock exchanges.

6. Enterprise Application Integration
EAI allows you to buy a package that does the entire extending process for you. For example, you have a legacy payroll system you'd like to get on the Web. You can buy an EAI that automatically does a front- and back-end extension for you. In theory, you can buy the package, put it in, and you're done. The drawback is you're stuck with whatever system the vendor likes. EAI may be quick, but it's certainly not easy to customize and is very costly.

Which solution is the best? It all depends upon your needs and how much money you have to fix the problem. But remember, if your legacy system is working, you may not have to change or replace it. If your core business hasn't changed and the access needs haven't changed, the answer is simple: don't touch it. If your customers or employees want to have Internet access to the data, you need to extend. Whatever choice you make, I recommend calling an outside consultant to look at your legacy set up and help determine the best way to apply the solution. Try to pick a solution that gives you as much flexibility and customization as possible.

The trick to extending legacy systems properly is to keep the business running while you modify the system to incorporate new applications, such as the Internet. Only when the traditionally inflexible core system has been made flexible can the process be declared a success. It can be done; the trick is finding the right solution for you.

More Stories By Stephen Laich

Stephen Laich is a senior solution developer at Pinnacle Decision Systems, a Microsoft Certified Solution Provider.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.