A legacy system is like any other corporate asset. You invest in it, maintain it, and maximise returns from it. With the money you spent remediating legacy systems, you'd better get extra leverage from them. One way to do this is with Web-to-host integration - making functionality from legacy systems available via a browser. Like so many subjects in IT, however, the obvious solutions are often shortsighted.
Go back to the basics: the need for IS to manage technical architecture. Technical architecture management is a core discipline for IS these days. Architecture consists of three layers: application, information, and platform.
Business value comes from the application layer. Applications use information (including databases and unstructured data), and run on the platform layer (including hardware, networks, software, and database management systems). Web-to-host integration from an architectural perspective begins by describing the application-layer functionality needed and then traces a path for its implementation maintaining as much simplicity and design elegance as possible in lower layers of the architecture.
What functionality are you looking for? You may be looking for a less costly way to deliver 3270 screens to end users by simplifying the platform layer and leveraging an intranet. If so, congratulations; you're taking an architectural view.
On the other hand, you may be trying to export legacy functionality to the company's Web site to encourage customer self-service or supply-chain optimisation.
If so, you're about to make a big mess. You want to export mainframe functionality via the Web. However, you'll need to export that functionality via other channels too - through the Web, IVR (interactive voice response), a call centre, and possibly through tools customised for your direct sales force.
Once you start thinking you need Web-to-host integration, you'll start thinking you need separate host integration for every category of application. That's bad enough. What happens next is worse. Because your Web site, call centre, and IVR system will have separate host connections; they will need separate, possibly inconsistent host integration logic.
Host integration logic belongs in the middle tier, where all applications can use it. That's what EAI (enterprise application integration) systems are for. The case for EAI is compelling: The alternative is to create a spider web of separate interfaces between each legacy system and every front-end application.
Do this, and managing the impact of legacy system maintenance is a polynomial nightmare. EAI is difficult to implement well. First-class EAI implementations know how to use host wrappers and integration tools to map legacy systems into well-designed object class hierarchy - to present them and to "persist" any updates.
A good EAI implementation is very hard. The alternative, however, is completely unworkable.