Inside Technique : Legacy Data and the Web: Steps to a Successful Marriage
By P.C. McGrew, EDPP and W.D. McDaniel, EDPP

"We need to be on the web!" It's the battle cry heard in every industry from banking to agricultural engineering, and it means something different to everyone who utters the phrase. For a large number of companies it means getting legacy data available beyond its typical paper delivery system, and that is not a challenge for the faint of heart. Over the next series of articles we want to address the steps to a successful marriage of legacy data and web delivery, whether you are starting out with proprietary data streams or line print applications. We'll take questions, too! Address them to siteexpert@mcgrewmcdaniel.com.

So what does it mean to move legacy data to the web? Engineering the solution may be different for every company, but the mechanics and tools will be remarkably the same. The hundred-thousand foot overview is that you'll need to uncover the deep dark secrets of the applications that have been designated to go to the web, and then try to locate the best solutions for getting the data to the web. All the while you'll be battling the "look and feel" issues, such as how close the web version has to be to the paper version of any document that moves to the web. Security issues and access issues will raise their heads at every turn. And when you think you've encountered every problem, testing will uncover even more of those deep dark secrets, like graphics that were created with proprietary fonts and data that was re-mapped in COBOL, PL/I or FORTRAN routines.

This sounds like a big job, and it is. But, it's not an impossible job. Many companies have successfully moved applications originally designed for Xerox, IBM, and many other printers to the web. They have taken many paths and many innovations have been forged along the way. We are going to start at the beginning and walk through each critical phase to give you an idea of what it really takes. The starting point is the identification of the application.

Can just any application move to the web? Almost, but some will be easier than others. The only real requirements are that at some point you need data and a way to describe it and  format it for web delivery. As you look through your business applications you should find at least two basic types of information to work with: customer-deliverables and internal deliverables. In many businesses you may have also have business-to-business applications that generate paper that might be candidates for the web as well. A good place to start identifying applications is at the output end of your system printers. Anything printed on green bar paper or its equivalent, as well as anything printed on a form (electronic or preprinted) is a candidate.

Start by drawing up a list of applications and identify what output arrives on either system or local printers, and who gets the paper once it's printed.

This  can be one of the hardest tasks. It is not uncommon to discover applications that run nightly, weekly or monthly that produce reports that are never delivered to anyone. You may also find reports that are printed to be filed and never reviewed by anyone. You'll want to check with department heads and customer liaison personnel to determine what they print regularly, and what they would like to be able to see online instead of printing. For many folks it might be possible to give them large amounts of square footage back in their offices and cubicles if they had online viewing of archives instead of paper under their feet.

When you have your list it should look something like the table shown below:

This is not a comprehensive list, but you can see where we are heading.  There is a lot of paper!

The table gets a bit more complicated in some organizations because there are many different types of printers in use. Some are attached to mainframe systems controlled by the IT department, while others are personal or departmental printers found in every department. You will usually find that the printers each speak different languages and have different characteristics, which is part of the challenge of taking all of this data to the web. The data is usually specifically conditioned for the target printer.

Let's look at the table again with an eye toward the printers used in typical applications.  Remember that this is just a sample and you should see a different picture at your shop.

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.