Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Five Ways To Modernize Your Mainframes: Page 8 of 8

ClientSoft Inc.'s ServiceBuilder software for Windows Server adopts an either/or approach, letting customers incrementally disuse middleware services as they see fit. "Solutions that utilize the application logic are typically the most valuable, because they take advantage of the 20 or 30 years' worth of business rules that have been encapsulated in many of these programs," says Brian Anderson, ClientSoft's director of product marketing.

The elimination of the middle tier is a new architectural trend, says Pete McCaffrey, IBM's director of product marketing for zSeries. "More and more, we're seeing customers move toward two tiers, with this middle tier getting squeezed out," he says. "So you may be seeing the beginning of a trend as a result of our embrace of open standards, but also the result of the technologies that are now being deployed that are going to drive us more toward at least a physical two-tier implementation."

But not everyone is so enamored by these claims that they're prepared to toss the middle tier entirely. Karen Larkowski, executive VP at analyst firm the Standish Group, is skeptical. "There are no benefits that I can think of and many costs to consider," she says. Without middleware outside the mainframe to perform the job of mediation, Larkowski says, companies are left to write infrastructure code by themselves or interpret the code produced by automated tools. "The biggest problem here is the cost of failure. We have found that applications which include homegrown middleware have a near 90% failure rate," Larkowski says.

Cutter Consortium analyst and author William Ulrich is more intrigued by the two-tier option but also warns of the dangers involved, such as creating new transactional logic that the underlying original logic does not, and cannot, expect. There's also the fact that simply wrapping Web-services documents around existing transactions bypasses what could be many companies' key problem: the spaghettilike behavior of the transactions themselves. "In reality," Ulrich says, "you're not really addressing the underlying segregated architecture."

There are benefits, such as improving workflow and eliminating the green-screen hassle, Ulrich says. But as far as improving the application itself is concerned, "you're putting icing on a half-baked cake," he says. "You still have a lot of starting and stopping, you don't have [proper] flow from system to system, a lot of the underlying systems use batch processes, and there's a lot of inelegant handshaking going on behind the scenes. You're not making that go away."