Will IBM Marry Off WebFacing to HATS?
by Mary Lou Roberts
Dave Slater, IBM's iSeries application development product manager, scoffs at some of the rumors that have been published lately reporting that the company is poised to merge its two green-screen Web refacing tools, WebFacing and Host Access Transformation Services (HATS). "There's not much that is accurate in these reports," he says. "About the only thing that's correct is that we won't leave customers high and dry. We will protect our customers' investments."
Both part of WebSphere Development Studio Client for iSeries, WebFacing and HATS both convert 5250 interfaces to browser-based graphical user interfaces. But they work in different ways. HATS is a dynamic runtime conversion tool that converts 5250 data streams into a Web-based interface at program execution. WebFacing, on the other hand, creates a Web or portal interface to a 5250 application through a development time conversion using display file (DDS) source code. WebFacing requires conversion when the source code is modified. HATS requires conversion when source code modifications affect screen customization.
Slater certainly doesn't deny that a marriage may be in the offing. He acknowledges that IBM is investigating "a number of initiatives to make the Web more acceptable to the SMB marketplace. We are looking at creating a solution to leverage the strengths of both tools. Will it be a separate product? We don't know yet. We are still in the investigation phase, and going through the design alternatives now."
This is simply business as usual, Slater maintains, since IBM is always looking at ways to improve its products. But in this instance, someone let the cat out of the bag too early, long before IBM is ready to announce its intentions. "Typically, we do all this investigation under the covers and don't announce until the product is ready," he says--and clearly, it's not ready even in concept, let alone delivery. Consequently, Slater won't even hint at a delivery date for the new product strategy--whatever it will be.
There are significant differences between the two tools. "Having two solutions tends to create some confusion and lack of modernization initiatives," says Slater, "so combining both technologies in one product would have advantages. But it also has its challenges. HATS is source-based. WebFacing is emulation-based. With HATS, the tools are free, but you pay for the runtime. With WebFacing, the runtime is free, but you pay for the tools. They have completely different business models."
Slater maintains that 49 percent of the iSeries market that is using a Web-enabling solution is using HATS. "HATS is best tuned to a customer environment. You install it on a server and apply it to every application on that server. It's great customization for out-of-the box. WebFacing, however, is very good from an ISV perspective. It can run automation tooling to customize big applications with lots of screens very quickly. But they are both good tools. We shouldn't force the market to choose."
To be sure, the products are different. "WebFacing is geared toward development shops with WebSphere and Java skills that are looking for a cost-effective method for bringing their 5250 applications to the Web," points out LANSA President John Siniscal. "HATS is oriented to those customers who are looking for a rich Web interface with lesser programming effort, but who are willing to pay the cost in CPW cycles and license fees for this functionality. WebFacing uses the DDS source for display files to generate Java code, and subsequently runs natively in Java and WebSphere Application Server. There is no additional cost for the WebFacing tool and there is no 'Interactive CPW penalty,' as the WebFacing Server runs under batch. WebFacing, though, requires a good deal of Java experience and does not generate as rich a client as HATS. HATS requires no special development skills, has a built-in macro recorder, and can generate, with much easier manipulation, a very rich client interface that rivals many competing emulation products. In addition, HATS requires no DDS and will convert any 5250 data stream. However, HATS only runs interactively and, therefore, requires CPW cycles on the iSeries."
Other vendors--some with competing products--are watching as well, but don't seem overly concerned. Brian Pick, head of marketing for Linoma Software, says that his company's aXes product competes with both WebFacing and HATS, since it's another way to Web-enable applications. "We'll have to see how the new IBM strategy stacks up against aXes. Every Web-enablement solution has its unique benefits. aXes is good for those who want a true thin client for remote access and no conversion required to get Web-enabled because it does the converting dynamically. aXes can also run with no interactive, as can WebFacing, but not HATS," says Pick.
Alex Roytman, president of Profound Logic Software, also sees significant differences between HATS and WebFacing. "HATS is easier to implement, but is limited in capabilities. An iSeries shop that doesn't have a lot of resources can use HATS to have its iSeries applications run in a browser. A big plus for HATS is that it handles virtually any type of screen. But the downside is that your applications will look and act like green-screens in a browser, not Web applications. WebFacing has some more flexibility. It is harder to implement than HATS, and it hiccups on certain types of applications like interactive queries or menus. But it does offer some (still limited) capabilities for customizing the look of an application, and it does allow you to have better looking--and to some extent, customized--screens. If an iSeries shop has Web design resources, they can make WebFacing work for them."
Profound Logic Software offers an alternative to both WebFacing and HATS, so it's no surprise that Roytman does not consider either product to be a good strategic, long-term solution for iSeries customers. "Neither one creates true Web applications. Both WebFacing and HATS are quick-fix solutions rather than a real long-term solution. Until recently, this meant rewriting your code. Now, iSeries shops can use [Profound Logic's] Dream Architecture to instantly convert green-screens to true Web applications. Once you have a real Web application, you're no longer limited by the restrictions of the original green screen. Unlike a WebFaced or a HATS application, a true Web application has no ties to greed-screen display files, so you can customize, refine, and enhance the application in any way imaginable."
Fine and good, but it's not clear that the majority of iSeries shops (meaning end users--not ISVs) are not, in fact, looking for a quick fix solution. Slater acknowledges that the majority of iSeries shops are not Web-enabled, despite the fact that he says that "Web applications have fewer errors that phone, fax, and email. Being web-enabled reduces error rates and gives very significant payback in months, not years. This becomes very important when you cross geographic boundaries--especially international boundaries."
But a lot of iSeries shops are not feeling the heat or pushing hard to Web enable those legacy applications, and new development by end users has dropped off.
While Slater stops just short of saying that ISVs are the primary target for any strategy that IBM may put into place in repositioning its Web modernization tools, he notes that prior to Y2K, the percentage of customer-built applications was in the 30 to 35 percent range in the OS/400 base. "Then people became concerned about Y2K and the cost to upgrade those applications, so they replaced them with ISV-built applications. Now, the percentage of customer-built applications is down to about 15 percent."
Slater stresses that these percentages are somewhat unreliable because the demarcation between new application development and "maintenance" is a fuzzy one. Many companies purchase applications from ISVs and then invest in major customization projects. In a sense, the third party applications are nothing more than templates, and this has been the case in the IBM midrange for decades. It is a side effect and a benefit of the tradition of open source (but not free) applications on IBM's midrange machines.
Nevertheless, the trend on the iSeries is moving toward an increasing percentage of purchased applications, so it makes good sense that IBM's strategy would favor meeting the needs of the ISVs. Logic, then, would dictate that if the two products are, indeed, coupled, the business model of WebFacing would be predominant.
A spokesperson for one ISV, who declined to be named, believes that this non-announcement by IBM is even further confusing the market. "How integrated are these products anyway? WebFacing was just a band-aid approach. Is this happening because WebSphere is not getting much traction in the iSeries space?"
Perhaps. Maybe even probably. It's no secret that IBM has a huge stake in pushing everyone down the WebSphere path, and a better, faster, slicker Web-facing toolset could help. Remember that many shops have yet to start down this road at all. But IBM better do it right. And given the differences in the technological approaches and business models--including the pricing structures--of the two products, merging the two could well be a challenge. What might emerge (which Slater hints at but never says explicitly) is an entirely new solution.
Chris Wilson, director of programming tools for Advanced Systems Concepts, is concerned about the pricing structure for any new product that IBM might announce. "It's always good to give customers options, but WebFacing is essentially free, so the key question is whether or not the combined product would be free as well." In addition, Wilson notes that his company's RIO RPG-to-Java translation tool offers an option of converting display files into JSPs via WebFacing, "so this decision might have a small impact on ASC if IBM elected to begin charging for the combined tool."
"Integrating WebFacing and HATS should be a good thing for iSeries customers who choose this type of application modernization approach," says Profound Logic's Roytman. "It will join the capabilities of both products. However, if the integration is poor, it may instead create more confusion for developers and produce unintuitive interfaces for end users."
LANSA's Siniscal also sees the potential integration as a plus. "The complementary integration of the two technologies would enable IBM customers the opportunity not to have to choose one product or the other," he says. "WebSphere could implement both products as pieces of a whole and could use the most appropriate product for each application choice. This means that should no WebFacing code exist for a specific 5250 screen, WebSphere could automatically render the screen using HATS. This is very good for IBM and for WebSphere, but would still require the purchase of HATS licenses and have the overhead of WAS for both products, limiting adoption by smaller iSeries shops."
It seems clear that IBM has something planned for a new Web modernization solution on the iSeries. But Slater cautions against reading too much into the speculation that's been floating around in recent weeks. "Someone let the cat out of the bag, and we want to correct the misconceptions."
Bottom line: Stay tuned--or, as Slater says, "Watch this space."