Four Quick Ways to Improve Your Legacy System

Mired in reams of excess paper and postal costs, the State of Washington's Social Service Payment System realized that it was time to streamline their payment operations. By adding Web-based mainframe access, electronic report distribution, interactive voice response and electronic deposit, it wasn't long before Washington State lifted themselves out of their rut and onto the path of company and customer satisfaction.

• 09/01/1999

Maybe the legacy system you just made Y2K-compliant really isn’t as ugly as a pig (although you might not want to ask your users that question directly!), but almost any legacy system can use some quick improvements that let your users know you are thinking of their needs.

Y2K work usually meant that the system was in a solid freeze against changes, or at least limited to only absolutely necessary fixes. Your users have gotten no new functionality for all the millions that have been spent in the last two years and, deep in their hearts, keeping the old system going next year really does not mean anything to them. Their world has been changing in the meantime, and they either lost staff or have not been able to add enough new people to cover the growth of a booming economy. They want help from you – now!

That pent-up user demand could be a problem as you try to plan a rational future. Big changes that have been planned for years would deliver what they want at the cost of several more years of delay. But if you can roll out several quick improvements in four months to a year, you might buy enough good will so that substantive changes that are going to take longer have a decent chance. At the very least, the information technology staff will get some much-needed, positive notice. The key to success is to focus on incremental improvements that reduce cost, risk and time to delivery. You could look at one or more projects like Web-based mainframe access, electronic report distribution, interactive voice response (IVR) to capture critical data and electronic deposits of funds.

This article covers the post-Y2K experiences of the State of Washington’s Social Service Payment System, or SSPS, and how it made its small improvements.

The SSPS improvements only make sense within SSPS’s business context. SSPS allows 3,500 social worker users in five divisions of the Washington Department of Social and Health Services to authorize social services for 125,000 clients. These services include childcare for parents coming off of welfare, emergency shelter for battered kids, chore services for homebound senior citizens and monthly, extended care for the developmentally disabled. It runs on a Unisys 2200 Clearpath mainframe using COBOL nightly batch programs against a DMS 2200 database and flat files with online data collection from TIP programs.

Then each month, SSPS mails to the provider an "invoice" listing the maximum quantity of all types of services to be delivered by that provider during that month. The provider fills in the actual amount of services delivered, up to the maximum, signs a return sheet and mails it back to SSPS for data entry. Once the information is entered into the system, a paper warrant (a check issued by the state) is mailed to the provider. Finally, a huge amount of paper and microfiche reports are printed and distributed to every office across the state.

User divisions wanted immediate help with input to SSPS. It was clear to everyone that SSPS’s old green screen system used to input service authorizations was clunky. At the end of Y2K, it had required a very complex simultaneous installation of 3,500 copies of a new DOS program that provided local editing at a PC. Maintenance of this program and tracking down all the ways in which it can fail in emulation, dialup and input errors created constant problems that ate up precious staff positions across the state. Worse, it required doing double work. If a social worker did his or her work on paper or in a divisional case management system, SSPS still forced them to sit down at a mainframe terminal session and reenter the data.

The longer-term answer was to remote the entire front end processing for SSPS to new Visual Basic (VB) 7 components and a SQL Server 7 relational database running on a Windows NT 4.0 server. That worked well for fixing the authorization piece, because it was the logic that was complex, not the data. The logic was encapsulated into COM (Microsoft’s component object model) components. Copies of the mainframe data were sent each night to the NT server by file transfer protocol (FTP). These files took only minutes to send and then 20 minutes to replace the relational database. Updated records return to the mainframe each evening, also by FTP batch.

One of the largest user divisions had been building its own childcare case management system, so their system was designed to send SSPS just the authorization data it needed using the distributed COM protocol, known as DCOM. This method has turned out to be very quick to build (six months from the start of coding to live implementation), very flexible and very robust. Response times are excellent. It takes less than two seconds after a childcare worker in eastern Washington pushes the send button until both systems have spoken, edited the authorization, recorded it and sent back a confirmation number.

Even better, using COM makes Web-enabling this new process very simple. Microsoft encourages Web developers to use its Visual Interdev tool to create screens and scripting. At the server, the screens hook to active server pages, or ASPs. On the other side, the ASPs hook neatly to the Visual Basic COM modules. Thus, the code written for the peer to peer interchange via DCOM works just as nicely for direct delivery to Web browsers across the state for divisions without case management systems. As users connect with their browser, a little Java scripting is downloaded to give them local editing, like numeric versus text and so on. It is possible to write Web screens for both Internet Explorer (IE) and Netscape browser users, but independent consultants were clear about how much extra work the Netscape version would require, so SSPS chose to use IE only.

Moving the actual issuance of authorizations to the new front end sets up many possibilities for the future. The time needed to respond to new user needs will be greatly reduced in the future because of the flexibility of the tools chosen and the rate at which they can be deployed over an intranet. Properly designed, new functionality can be placed on the Web with Web-enabled training and documentation, so implementation could consist only of sending a broadcast e-mail to all users.

But that utopia is unavailable until all SSPS functions are Web enabled. The more difficult part of the new front end deals with SSPS’s DMS billing database, which is extremely complex. When copied to a relational design, it will take seven main tables to duplicate the DMS logic. But the bigger issue is its size, because a database unload will take more hours than there are in a night. Catching the incremental updates and synchronizing the old and new databases is the way to go, but there are many, many sources in the COBOL batch programs for the incremental updates that would have to be intercepted, with all the coding and testing each one would require.

Because of user pressures to replace all green screens with Web-enabled SSPS programs, an interim solution was investigated. The billing queries could be handled for some time via a mainframe to Web connectivity tool. Unisys makes such a tool in WebTX. This method is in use at many sites and is working well. But it does require modern levels of TIP communications; a problem for SSPS because it still is written in COMPOOL TIP, abandoned by Unisys more than a decade ago. Second, WebTX requires modification of the TIP code on the mainframe, something SSPS would prefer not to do in any case.

Fortunately, a less invasive approach was at hand. Washington State’s IBM systems often use OpenConnect for mainframe connectivity. NT servers run a 3270 to HTML translation program that uses Java and Java script to make the emulated green screens look and act much better than before. OpenConnect has enlisted Core Technologies of San Francisco to make a similar approach available in the Unisys 2200 world. The user is responsible for the Java or Java script coding, but that skill is readily available if your own staff does not yet have the capability.

SSPS is now investigating using the Core Technology tools on the same NT server that is running the VB COM modules. The advantage is that the user only has a single SSPS icon on their browser. On activating it, the user receives an SSPS security logon screen, independent of NT security, followed by a menu of functions. If the function they request is in VB, then the ASP logic directs their input there and gives the right NT security. If, however, the request were for a function not yet implemented in VB, it would be routed internally to the Core interface to the mainframe. One advantage of this approach is that the independent security program on the NT server can validate based on the user’s own LAN ID, but then automatically translate it into their mainframe ID and submit it without further effort. This gets very close to the old Holy Grail of a single logon ID for everything.

Legacy systems produce a lot of paper reports. SSPS itself is approaching 600,000 pages per month and this is puny compared to many private print runs. Then there is the need to save all the reports for years to come, a job that has been the province of microfiche and microfiche readers. Data marts or warehouses would make everything electronic and far more flexible to boot, but they take lots of time and money to set up. Worse, the risk factor is high, with something over half of all such efforts failing to reach a successful implementation.

Enter COLD systems. COLD stands for computer output to laser disk, but in today’s world, that can be RAID disk arrays and/or optical disks (CD-ROMS are too small). These systems store the ASCII text of a report, not its scanned image, so with compression a page of green bar printout can be smashed down to only 1 kilobyte of storage. When you consider that an optical disk can store 5.2 gigabytes of printouts for a century or more, and that some large disk towers now can have from 16 to 500 disks, the possibilities become staggering.

The software that processes the printouts, which can come from any kind of mainframe, UNIX server or NT system, receives the reports, cleans and parses them according to stored instructions, and then archives them to both hard disk and optical storage. A hierarchical storage manager (HSM) monitors the hard disk reports and erases them after a preset waiting period, usually 60 to 90 days, when a report has become stale. After that, the HSM waits for a user to request an old report, finds it in the optical jukebox and mounts the optical disk in less than 15 seconds. While the first reply is going to the user, the HSM copies the report back to temporary storage on the hard disk for fast subsequent accesses.

Another part of the COLD system is the retrieval engine, which receives Web-based queries from users, finds the report, checks it against security restrictions on a per-user basis and sends it out. It is possible to get inexpensive modules that will find all of the reports of any type in a user’s security profile according to query-by-example search criteria. (For example, a user could ask for all reports for account 103522 in this fiscal year where the district 5 total was less than $1,500,000.)

One of the real long-term advantages of a properly architected COLD system is that it is really a document management system. Document management systems don’t care if the documents they manage are compressed mainframe reports, scanned images, faxes, MS Office or Lotus documents, or any combination thereof. Thus, you can start with a COLD system and get immediate benefits, but have the beginnings of a robust imaging system or complete document archive.

The cost to set up a COLD system for an organization of a thousand-plus users would be about $150,000 for hardware and software to start out and $25-50,000 for training and startup assistance. SSPS is using software provided by Optical Image Technology (State College, Pa.), but also strongly considered Mobius Systems.

IVR systems are in use all over for banks and credit cards, so why is it listed as something to consider for a quick, high-payback project? The reason is that few of these systems capture data in a way that can replace more traditional and more costly data entry systems, like key to disk and scanning.

SSPS has been mailing out more than 45,000 paper invoices each month to private providers of social services. This is an extraordinarily slow process that is costly even if it works right, about 50 cents for each of the three steps: mail out, mail back and data entry. Opportunities for lost or delayed invoices are everywhere, leading to a huge backend cost in tracking down lost documents and dealing with legitimate provider complaints about late payments.

Early thoughts about using IVR were stopped because of the worry that the maintenance of the IVR security system might cost more than the old paper method. SSPS was fortunate to discover an easy way to handle the security that might be useful to many. It turns out that the combination of the invoice number and the provider’s ID number is unique each month. Thus, if that combination is used as the IVR database key, only the provider who receives the paper invoice with the invoice number could know which invoice to access.

Most of the large firms providing "800" number services have existing relationships with IVR service bureaus, who can both code IVR logic and provide the necessary services on their own UNIX or NT, server located in the telephone provider’s switch room. Clearpath mainframes can use encrypted virtual private networks (VPNs) through specialized NT or UNIX servers to FTP data files to the IVR system each night and receive the IVR’s captured data the same way.

SSPS discovered huge differences in the programming costs charged by different vendors, so check all sources, not just the communications provider’s partner. A medium size application can be coded for $50,000-60,000, and in just several months. You will be charged each month for the callers’ time on the 800-number and about $3,500 per group of 24 inbound telephone lines. These can handle a lot of callers per day at 3 minutes per call.

The savings you get from IVR’s cheaper data gathering may more than pay back its cost. But the increase in user satisfaction is an even greater benefit. SSPS’s Invoice Express IVR system is generating a lot of interest for that reason.

You probably already pay your staff via direct deposit (sometimes also called electronic funds transfer, or EFT) of their paychecks. The convenience and reliability are of great value to both parties. The same could be true if you keep sending out many checks to a large group.

The State of Washington has found that fully allocated costs to create, mail, reconcile or cancel a warrant (state check) may be more than $10 each because of all the manual handling. As an efficiency move, the state strongly encourages its agencies to pay as many warrants as possible with direct deposit. That may apply in your organization.

The same internal process or external service bureau that directly deposits your organization’s paychecks can very likely also handle direct deposit of other types of checks as well. The work on your part would be to set up a "crosswalk file" that knows which of the entities you must pay have already signed up for EFT. If your payment process finds a match with a crosswalk file entry, then you would send that payment to the EFT process and adjust your accounts accordingly. There will also be some automated or semi-automated process to correct any errors, although those tend to be very few, mostly because of closed bank accounts.

At least one of the four projects listed above probably applies in your situation. They can be done in four to eight months for a small amount of cash outlay, and they can pay off handsomely.

About the Author: Stephen Anderson is the technical architect for the State of Washington’s Social Service Payment System in Olympia, Wash. He can be reached at andersm@dshs.wa.gov.