In-Depth

My meeting with a legacy transformation architect

• By Deborah Melewski
• October 30, 2003

We speak with Jim Rhyne (below), a distinguished engineer and legacy modernization architect, based at the IBM Silicon Valley Lab.

Q: Why is mainframe integration with Web services so important?

A: Specific to the mainframe, what we’re seeing is that enterprises are beginning to use Web services to integrate and automate within the enterprise. There are some very good reasons why they’re doing that as opposed to just going out on the Web. The reasons have to do with security configurations that customers have. Because the mainframe tends to be a very business-critical piece of the technology, they’re extremely well insulated from the general Internet. You don’t often find people that connect their servers directly with the Internet. So customers are looking at how they can do Web services within the enterprise first, because in that domain security is a little bit less of a concern. For the first time, people will have a way to get applications talking to each other without requiring a lot of expensive customization or elaborate hardware configurations.

A: This is a critical piece of Web services technology. Historically, most of the security around the mainframe was physical security. That’s because if you logged into a CICS application using a 3270 terminal emulator, things like passwords and user IDs actually flowed on the network unencrypted.

That kind of physical security is incompatible with new ways of doing business. Enterprises are spread out all over the globe. There are things like virtual private networks, but security experts can’t audit and verify that the installation is physically secure. For that reason there is increased focus on software-based security, typically involving things like encryption.

Q: What percentage of IBM customers is applying Web services today?

A: We have some customers employing our XML technology, and [there are] others I probably don’t know about because there’s no real way of monitoring. I would estimate that probably out of our 500 largest enterprise customers, some 10% to 15% have homegrown XML solutions. Most of this is still in the “kick the tires mode.” Many companies are still evaluating this technology, but with a few exceptions they haven’t made a strategic commitment to it. But we see that they’re beginning to be very interested in doing it.

Q: What is the benefit to the organization today of keeping the mainframe around as opposed to taking the route of Web services without mainframe integration?

A: In most cases, there is no effective replacement. There is not much you can put together that offers the same scale as we do with the mainframe. Second, customers have an enormous investment in their mainframes. One calculation I like to do, and this pertains just to Cobol, is that if you look at the world’s supply of currently active Cobol it’s somewhere in the neighborhood of 200 million lines of code. If you figure about $35 per line of code as the replacement cost for rewriting all of this, it’s just not economically feasible to throw away all you’ve invested in for between 15 and 30 years.

Management control is another value point. It’s almost impossible to manage a distributed computing environment at the same level of cost that you can manage one that is more centralized.

Q: With both Cobol programmers and Web service programmers, are there issues in making tools easy enough for either group to work with?

A: It is hard; on the other hand, I have to say that mainframe programmers are tough. Over the years they haven’t had a lot of the nice language support or tools that distributed and Java programmers have had. As a general rule they’re not phased by the intrinsic difficulties of doing this. But matching Web services to a CICS application is much less challenging technically than matching CICS to a Java J2EE application. The simple reason is that Java or J2EE are object-oriented technologies and Web services is not; it actually matches better to how transactional applications behave today than J2EE does. We typically find that mainframe programmers can get up to speed on Web services patterns much more quickly than they can get up to speed on some Java-Cobol integrations. That latter one tends to cause a lot more head scratching.

Q: When a customer comes to you for Web services integration, do you find that they are extremely concerned with ROI at this point?

A: I think they’re less concerned with ROI. Their primary concerns have to do with technology and schedule risks. The customer can appreciate a couple of value points. If you can do application integration middleware or business process automation middleware on a commodity technology like TCP/IP and XML, then it’s bound to be several orders of magnitude cheaper than a proprietary solution.

For customers who have a particularly large investment in Microsoft and Intel and, on the other hand, a large investment in IBM mainframes or P-series distributed offerings, they’re looking at Web services and saying, “At last, I have a solution that will allow me to wire everything together without having to hire a rocket scientist, or build thousands upon thousands of special-purpose adapters to convert things to get applications talking to each other.” The value is transparent to people. Everybody is ready to do this, but there’s the usual thing. Only a few people want to be first; the rest want to wait until the technology has proven itself and then they’re going to jump on the bandwagon.

Q: What is IBM offering to help its customers integrate the mainframe with Web services?

A: This integration is part of our strategy. We’re moving in a direction that would have any mainframe application you write be accessible to Web services. It will take us a while to do this because the same thing that’s causing customers to move slowly with these applications, namely substantial investment and huge cost in applications, is also causing us to move slowly. The first thing you’ll see is a SOAP implementation for CICS applications. We’re doing this in a way that initially does not require changing the application. We have a small number of customers piloting this technology.

Our strategy is to provide Web services enablement for all the transaction processing systems on the mainframe -- WebSphere, IMS, DB2 and batch applications as well. WebSphere on the 390 is doing extremely well, and there is a lot of customer interest. A lot of customers have deployed J2EE applications in WebSphere on the 390.

Q: Do you find particular business segments within your customer base moving toward Web services more so than others?

A: At the forefront is financials; almost every customer we have that’s trying to do serious things with XML Web services is in the financial sector. One thing driving them is that they tend to operate in an environment where the cost of a transaction to a customer is critical. The more they can reduce the cost of doing their interactions and at the same time improve customer satisfaction, the better their bottom line will look.

Q: What controls or administrative mechanisms do you provide for Web services/mainframe integration?

A: The most common way of doing this is to use IBM WebSphere as a front end to an existing application. WebSphere comes with a system management console that allows you to manage the Web services you offer. You can configure workload management and make the best use of the computer resources you have.

Q: Do you have any advice for application developers?

A: Web services is an area where they need to start acquiring skills. This is increasingly important not just for the Java developer, but for the folks writing C, C++, Cobol and PL/1 applications. This will become very important, so people need to learn about it.

There are tools to help people with these kinds of applications and there are published best practices to help the developer in Web services avoid all the obvious mistakes. I urge them to take a look at the tooling we have, and to look at our alphaWorks and developerWorks Web sites because there is a great amount of information about Web services there.

Q: What is in the future for Cobol and PL/1 programmers? Will they be out of a job?

A: Their future, and the future of the mainframe, looks extremely good. Our annual compound growth in sales of mainframes is very healthy. We’re not worried about mainframes disappearing, or their programmers losing work anytime soon, either. Customers have a huge investment in their mainframes, so it’s way cheaper for them to modernize things and continue to use it than to rewrite it in Java, or whatever the language du jour happens to be.

In 1997, IDC estimated the worldwide supply of Cobol programmers at about 1.2 million, but they saw that declining so that by 2003 there would be less than 400,000 left. As it turned out, they were wildly wrong because there are still somewhere between 900,000 and 1 million Cobol programmers out there today.

Please see the related story "It’s the mainframe’s turn to get the services treatment" by Deborah Melewski, or click here to go to special Web-only material on mainframes.