In-Depth

SOA: The Rewrite-vs.-Replace Dilemma

Legacy design approaches complicate things for would-be service-enablers and raise questions about the viability of some mainframe applications

• By Stephen Swoyer
• 10/11/2005

Web-enabling or exposing mainframe applications to new and different constituencies—including non-mainframe applications—is supposed to be easy provided organizations have first prepared by appropriately separating their application’s business logic from its presentation logic.

While still no piece of cake—far from it, mainframe pros say—such separation should make for much easier going than when the logic is integrated. Unfortunately, some industry watchers claim, that's not the case for many mainframe apps, forcing enterprise service-enablement initiatives to negotiate some fairly difficult roadblocks.

The situation isn't totally bleak, of course. “There are a lot of people doing that already. You look at client-server design techniques that came out of the 80’s—they effectively said that all CICS programs (or all CICS transactions) should be broken out into a couple of programs: one that would handle all of the screen-handling and prepare a message that would pass through to a [communications] area that would do all the work itself,” says Tyler Allman, a product manager with software tools vendor Compuware Corp.

Putting aside the vagaries of the service-oriented architecture (SOA), a design of this kind just makes good sense, says Mark Schettenhelm, QACenter mainframe product manager with Compuware. “It’s just a good design, regardless of [the architecture,” he says. At the same time, Schettenhelm acknowledges, separating an application’s business logic from its presentation logic also provides a starting point for organizations to expose—in native COBOL, if they want—mainframe application features and interfaces as part of an SOA.

The question, of course, is the extent to which organizations have actually done so. And the results seem to be a mixed bag. While most mainframe applications written in the late 80s and later have probably been segmented in such a fashion, Compuware’s Allman stresses that mainframe apps from the 70’s and mid-80’s have to be taken into account, too.

“I think [the application split is] pretty much half and half. It’s amazing how long applications live. When people write stuff and it works and it gets the business done, they keep it. It runs. It’s cheap. There’s a lot of stuff that was written in the 70’s and 80’s that is taking screen-based input—it’s all mixed up together and that’s the stuff that you have to screen-scrape,” he comments.

According to Schettenhelm, the result is that even with the (growing) uptake of SOA, many organizations have put off deciding what to do about these applications. “I think a lot of the [service-enablement] technology is there and being adopted, and I think the people realize that the service-oriented architecture really makes sense and is the way to go, but it’s now making those hard decisions about what to do with these older applications,” he comments.

As many mainframe pros discovered long ago, when organizations first started Web-enabling their mainframe applications, there are no easy answers, short of a substantial rewrite of the application itself. “When you consider the old command-level COBOL code in the CICS region, the presentation and the business logic were contained in the same program. The data to be displayed was retrieved from another source, be it VSAM, IMS, or DB2,” Poole says.

In theory, he acknowledges, this made the idea of Web-enablement an attractive option. “Web-enabling those programs could be done by changing the screen writes and reads to HTML writes and reads. Not that difficult, except for the idiosyncrasies of each browser that had to be considered,” he indicates.

The truth, Poole points out, was far more complex. For this reason, he says, the lessons of Web enablement also have something to teach us about the much more serious work of service-enablement.

“I think that Web-enabling is a distinct change in architecture of the program, and rewriting the application is necessary. After all, you're changing the presentation from a 3270-based screen that a skilled operator could decipher into a graphical display that almost anyone can handle,” he says. “For example, CICS didn't support pull-down boxes very well, but browsers do. Buying a package to ‘webify’ an old application is the wrong approach, especially if the intent is to show the output to the outside world, or even the co-workers for that matter. A legacy screen is 24 lines of 80 characters each, which doesn't translate well into a free form HTML display. You can do it, but you can do better with a re-design.”

Poole’s point isn’t so much concerned with the specificity of the technology challenges—i.e., legacy screen display modes of 24 lines by 80 lines are incompatible with modern free-form HTML displays—as with the difficulty of updating an application that was written in a totally different time period, and with totally different architectural expectations in mind, for a next-generation architecture such as SOA. In such cases, he argues, the best Rx is almost certainly the most uncomfortable Rx—a substantial rewrite.

It’s an Rx that’s uncomfortable, if not impossible, for many organizations to swallow. Consider the case of Jim Melin, a mainframe systems programmer with a Minnesota county government. His organization is buckling under the costly 3270 terminal-licensing fees it pays to infrequently expose one of its core mainframe applications to several thousand users. In desperation, Melin’s employer once tapped IBM Corp.’s now-defunct Host Publisher tool, the functionality of which Big Blue has subsequently folded into its Host Access Transformation Services (HATS) product.

“We had tried to use WebSphere Host Publisher to expose a TN3270 application for payroll to the staff via Web browser. [IT] currently needs a 3270 client—and with several thousand people that's a lot of TN3270 or Hummingbird licenses for an application that gets used once every two weeks,” he explains.

IBM positions Host Publisher as a tool that helps organizations rapidly expose mainframe applications by applying presentation rules to green screens as they are encountered in 3270 or 5250 data flows. Both Host Publisher (and now HATS) can skip through green screens programmatically, and both tools also let developers consolidate several application green screens into a single Web view.

Unfortunately, Melin says, neither Host Publisher nor several other third-party solutions were flexible enough to handle his organization’s requirements. “The product we used was not robust enough at the time to handle the hundreds of fields this application could present. I had built a test application that worked well presenting legacy data from two separate but related apps on one GUI screen, but we never could get the tool to work,” he comments. “Interest in other tools waned. Host on Demand was also tried, but development felt that it required too much business logic to be duplicated for this payroll app to be practical.”

In the end, Melin says, his employer found that the issues involved were intractable. A complete rewrite is out of the question, and—at this point, anyway—it looks as if his organization will transition away from COBOL apps running on z/OS. “Since we are looking at a retirement point from a cash recovery standpoint of 2009 for our z/OS applications, I think for us it's moot. Linux on z/Series may not be enough to keep the environment.”

All’s not lost, of course, Compuware’s Allman, for example, says that organizations are not plunging into SOAs with the same abandon that they embraced Web-enablement. “Now people have kind of taken a step back and they’ve gone up to a higher level, saying ‘Let’s make sure that what we do isn’t just going to get us through the next five years; let’s take a look at our whole enterprise requirements,’” he says. “Once they start making those decisions, then everything else starts falling back into place, then they can look at the build versus replace options that are available to them.”

Similar or Related Articles:

Swap Green Screens for a Web Interface in Under an Hour
http://www.esj.com/news/article.aspx?EditorialsID=923