It seems we can't escape the notion that "legacy" means outdated and obsolete. For example, we often hear of the System i being referred to as a legacy system...and not in a complimentary sense. But for many enterprises, the significant investment in System i software and hardware infrastructure still holds tremendous value. Some software applications may be 10 or 20 years old, but they still prove reliable, both in functionality and use. They are still scaleable. And the IT staff is familiar enough with them to be able to keep them up-to-date. So how do you decide if "legacy" is a swear word or not? The answer lies in doing an organizational and technical analysis of each business system to see if it has potential new value that can be unlocked.

Performing an Organizational Analysis

The first step is to determine whether a legacy technology is a candidate for some kind of change. Once you've done that, you can begin to decide how it should change: scrap it and start again, salvage some remnants, or build upon its strengths. Let's consider step one. Ask yourself these questions:

Stakeholders

Who are the stakeholders in this technology? In other words, who uses it and who benefits from it? The answer to this question may involve more than one group in your organization. For example, a requisition system may be used by the purchasing department, but the beneficiary of the information coming from that system is the Chief Financial Officer. He or she may receive weekly reports tracking the progress of purchases in order to monitor capital expenditures.

Relevance

Is the technology meeting everyone's needs? Again, with the purchase order example, you may consider points such as these:

• Is it as easy as possible for users to enter information about items they wish to order?
• Would it be more helpful to have a direct link to vendors' databases to determine availability of supplies or to obtain current pricing?
• Can management predict with reasonable accuracy the availability of supplies? Or would a link to FedEx or UPS help with real-time tracking of shipments?
• Can the CFO get a quick overview of the status of procurements? Would it help to have a graphical presentation of key performance indicators (KPIs) such as actual-to-budget comparisons of acquisitions or time-to-delivery for key materials used in manufacturing?

Data Access

Is information readily accessible and meaningful? Many existing System i business applications provide information in two ways: green-screen, text-based inquiries and hard-copy, text-based reports, often with excessive amounts of detailed information. Much of this information may be both physically hard to get at and difficult to consume. For example, if you need a green-screen session every time you want to do a sales inquiry, you may need either specialized software (a 5250 emulator) or hardware (an actual green-screen terminal). For reports, you may need a high-volume printer that will generate stacks of paper to wade through. This is probably not so much the case these days, as inquiries take precedence over printed documents. However, if you neglect many of the reports because of their sheer size, you may be missing gems of information hidden within them.

Technology

Are there weaknesses in the technology that are constraining users' productivity? Sometimes very simple changes can be made to an application that can result in reducing workloads significantly. This seems to be especially true of reports. Often, the addition of a simple total or subtotal makes the data on the report much more useful and saves time for the report reader. Other cases include the need for improving efficiency for getting data into the application. Using a bar code reader to scan inventory for month-end counts is much more efficient than having to type in the data, for example.

Performance

Are there performance issues? Is the interactive response time too slow? Does it take too long to run batch processes?

The Value of the Process

This process is important to go through because it helps you to distinguish between opinions and fact. Business executives are as heavily influenced by media and advertising as any consumer, and the impression that the System i and its associated software technologies are old and outdated is probably largely the result of Microsoft's successful marketing campaigns.

By examining questions such as those listed above, you can begin to build a case based on fact rather than general impression. The result of such an exercise will most likely expose some weaknesses in your current system, but you will be better prepared to decide how you should deal with these deficiencies. You might choose one of the following methods to address your findings:

1. Do nothing.
2. Throw out the entire system (hardware and software) and purchase completely different technology.
3. Commit to a continual "Band-Aid" approach of patching up deficiencies as they become critical.
4. Leverage the strengths of your technology.

Performing a Technical Analysis

OK, so this article is really about the fourth option. Let's assume you have an open mind and are willing to put aside options 1–3 until you've given option 4 a fair chance. The next steps in the analysis are to determine what the technical strengths and weaknesses of your application are and then to consider what new technologies are available to you that will leverage the strengths and mitigate the weaknesses.

Here's a table of typical technology components, along with some possible strengths and opposing weaknesses for each one:

This table is by no means exhaustive, but it gives you a sense of the issues to consider when evaluating your existing technology and determining the actions you might take. For example, if your home-grown order-entry system's database has a five-digit customer number in some files and a six-character number in others, it may be a candidate for a complete redesign and conversion simply because the ongoing costs of maintenance may be prohibitive. Or, if you find you need to store BLOBs in your files, you may need to convert your database to use SQL definitions instead of DDS. Another consideration here is that IBM is no longer enhancing DDS, but it is enhancing SQL, so if you think this database is going to be subject to major upgrades in the future, it may be worthwhile re-engineering it.

Before you throw out all your source code, remember that it contains all the business rules of your application. These are generally very valuable assets. Often, it makes sense to rewrite some of the front-end user interfaces as Web pages to make them more accessible and productive for users while keeping the business rules and database logic. This may involve some repackaging of the code into discrete modules that can be easily encapsulated and referenced by new code. Also, most of that business logic is manifested in one way or another in the output produced by your system, whether via interactive inquiries or reports. There are ways you can make the most of your reports, for example, without having to rewrite everything. Various report distribution tools, from both IBM and third-party ISVs, exist for this very purpose.

These tools take advantage of the potential goldmine of information already available to you, without requiring any invasive programming. In other words, you don't have to modify any underlying source code to leverage the information. Instead, you can directly mine spool file reports for information. With this technology, you never actually print the spool files; they just sit on output queues once they are produced by the application. The report distribution software detects the arrival of new spool files, grabs them, and then refactors and/or transforms the report contents. You can summarize report data; split it; email it; create graphs, charts, Excel spreadsheets; etc.—all without having to change your legacy system. For example, if you have a billing system that produces paper bills, you can easily eliminate the need to print and mail them by having the report distribution software burst each bill at the correct start and end points on the report and then email each bill to the respective customer. Another option is to first transform the bill into a PDF, overlaying a form or images on the data, and then email the PDF. Some solutions also provide a way to create HTML documents from reports that can be indexed, archived, and retrieved via a browser.

Modernizing the User Interface

Generally, "modernizing" means creating some sort of browser-based interface to replace the green-screen. Again, your analysis of your existing systems may determine this is unnecessary, but generally speaking, if you want more immediate access to data from other sources (such as FedEx, UPS, or any one of your vendors), a browser application is the best option.

One way to accomplish this is by using a refacing tool. Again, both IBM and third-party ISVs provide these. While refacing tools can get you quick results, they often lack flexibility in how you can add enhanced functionality. Another approach is to use a tool for writing browser-based applications. Many such tools are available, ranging from open-source APIs for writing Web programs in RPG to full-blown rapid application development (RAD) tools that cover the complete software development lifecycle. Some of these tools let you leverage existing business rules that are embedded in the source code of your applications. Often these are very valuable assets, worth keeping in one form or another. You may find it makes sense to rewrite some of the front-end user interfaces as Web pages to make them more accessible and productive for users while keeping these business rules and database logic. This may involve some repackaging of existing code into discrete modules that you can encapsulate and reference with new Web application code. While this might take some work by your programming staff, it's probably still less effort than a complete rewrite and more cost-effective than purchasing new off-the-shelf software. A Web-based interface can provide your users with many benefits, including rich-text editors for typing notes associated with orders, email facilities for communicating directly with customers or vendors, images, Google maps, dynamic charts to provide graphical KPIs, access to other forms of data such as PDFs or Word docs, etc. All these technologies can leverage your existing database and business logic while providing more timely and meaningful information to users.

The Legacy Lives On

Once you've enhanced your application with a Web interface, you are ready to tackle direct integration of data from other servers using SOA or Web services technology. Using Web services opens up a whole new world of data accessibility to you; it enables you to directly share, either as a provider or a consumer, information with other organizations, using widely recognized protocols. For example, using Web services lets you easily integrate shipping information from FedEx into your own applications, seamlessly, without any user intervention or the need to open another page. Compare this to the old method of sitting on the phone waiting for a customer service rep to tell you where your package is, and you begin to see the benefits of building on the strengths of your legacy technologies.

Duncan Kenzie is President and CTO of BCD Technical Support, the development and support group for WebSmart, a popular iSeries Web development tool, and Nexus Portal, a portal product specifically designed for System i, iSeries, and AS/400 servers. Duncan has 30 years of experience on the midrange systems platform creating software for both green-screen and native Web environments.