In-Depth

Q&A: Straight Talk on Mainframe Futures

Seagull Software’s Andre Den Haan isn’t a knee-jerk contrarian—but he also isn’t afraid to call it as he sees it

• By Stephen Swoyer
• March 28, 2006

When it comes to Big Iron futures, Andre den Haan, CIO of mainframe ISV Seagull Software Systems Inc., is a straight shooter. He’s encouraged by the mainframe renaissance, says service-enablement taps into something his company has been doing for quite some time now, but doesn’t necessarily foresee a future of pervasive service-enablement for mainframe customers.

Den Haan also weighs in on IBM’s next-generation workload push; on the longevity of CICS, MVS, and other bread-and-butter mainframe workloads; on partnering and competing with IBM’s Software Group; on and Big Blue’s bullish MIPS growth. He isn’t in any sense a knee-jerk contrarian, but he also isn’t afraid to call it as he sees it. Read on and see for yourself.

You started out as a UI enhancement vendor, mostly putting a graphical interface on top of mainframe and iSeries. You’ve since started to focus more on application integration, though. Can you talk a bit about this evolution?

Yes. In the late 1990’s, we moved on to integration solutions. We still provide the GUI-enablement solutions, but we added on to that integration solutions. The idea was that customers could wrap their existing applications and expose them to the outside world as Java objects, XML, and Web services. The new acronym is SOA, but this is something our customers have been doing [by another name] for a while now. We’re highly successful in that [respect].

You made a pretty prominent SOA-related acquisition last year—a company called SofTouch [Systems Inc.]. Could you say a bit about the SofTouch technology and about what the impetus for the acquisition was?

Up until last year, all of our software ran primarily in distributed mode, and that’s why we acquired SofTouch, out of Oklahoma, and they had a product called CrossPlex, which is a 100 percent Assembler solution that resides on the mainframe in the CICS region. We added that to our [LegaSuite] product portfolio, mainly for our integration solutions, so we can now offer customers deployments where they can [have] Web service enablement on the mainframe itself, or if they choose in a hybrid environment—[they can] offload some of the XML to a distributed environment.

The mainframe could be the ideal candidate for service-enablement—especially in a vision like Liquid from BEA [Systems Inc.], where they’re proposing to kind of freeze those “legacy” assets and expose them via Web services, so [these assets] can still be involved [in next-gen application architectures], but don’t necessarily have to evolve—don’t have to be updated, supported—going forward. With this in mind, what kind of service-enablement strategies are Seagull’s mainframe customers pursuing? Are they aggressively exposing mainframe assets via Web services? Are they approaching service enablement in a piecemeal fashion?

I would say the majority of our customers do not take an approach where they say they want to wrap everything in Web services. [On a] project-by-project basis, [they] let the services that they require be prescribed by the type of solution they need to create. In other words, if you want to completely modernize or redo your call center, obviously, you can specify a number of services … that need to be used in this call center application and they just wrapper those.

The same example goes for a few of our banking customers. They have a strong need to get state-of-the-art banking solutions, and so in the case of Bank of America, for instance, they had a financial fusion [initiative where they] created some 40 Web services on the mainframe, to get the necessary interaction.

Let’s switch gears and talk about IBM. You’re obviously a member of the mainframe product ecosystem, and in that sense, you’re dependent on them and them on you. But they’re also become more competitive in a lot of partner markets, so much so that—in the case of a BMC or a CA—they’re actually marketing management products that compete with them. Has this affected Seagull at all? And how would you describe your relationship with them [IBM]?

IBM is an interesting beast. I think the software group from IBM with some of their products, they have definite functionality overlap, and they would most certainly view Seagull as their prime competition. However, when you talk to the right levels, even in the software group, most of their revenues come from CICS and base WebSphere licenses. It’s mostly the base CICS that they get most of their money out of. They don’t view us as an evil or a bad thing.

Speaking of IBM and the mainframe market, the folks at Big Blue have talked a lot about new mainframe workloads, about how a sizeable percentage of the new mainframe capacity they ship goes to support new workloads. This is something I want to return to in a bit, but I wonder if you could give me a sense—from your own experience—of how much of this new mainframe capacity is destined for non-traditional customers? IBM says they exist, and that there’s an encouraging number of them, but they haven’t yet produced any who will speak on the record about their experiences. Are they out there?

I have seen very few new customers. Almost all of our customers have been longtime IBM mainframe shops. All of the bigger companies, utility companies, banks, they’ve had their mainframe for a long time. Quite frankly, I couldn’t come up with an example [of a new, non-traditional customer].

Getting back to new workloads—these seem to present an opportunity for ISVs like Seagull. Have you introduced any products, or otherwise enhanced existing products, to support these new workloads on zSeries?

We don’t have any products [explicitly] for this [new workload] market, but we do support them in our existing [products]. One of our deployment scenarios allows customers to run our integration server on a Linux partition, with or without WebSphere as an application server, so we fully support that environment, and we leave it really to the customer to make the best judgment call there.

I think it’s very much appreciated, [because] the whole dynamics, the price point of TCO can change in a heartbeat. Once you start thinking about outsourcing your mainframe processing, the whole dynamics change, IBM introduces new models with new types of pricing structures, [and] that changes the dynamics. One of our big advantages is that we allow our customers to move the processing to the environment that makes [the most sense].

IBM has priced J2EE and Linux workloads such that they’re an almost no-brainer proposition for a lot of customers. It hasn’t really budged on traditional, COBOL pricing, though. Do you see any justification for this? In other words, do you think IBM should move to make traditional, z/OS or COBOL workload pricing more in line with how it prices J2EE or Linux workloads?

I do understand why IBM prices the new workload-type things more attractively, and I do understand why IBM still charges a lot of money for their traditional workloads. At the end of the day, I think what counts is the value of the software itself. To give you an example, I have yet to see one situation where a large-scale application with 40,000 workstations is running on either a WebSphere or a Linux backend. They just do not exist, I think.

There’s a market for both. Obviously, the new workloads, Linux, WebSphere, they sort of fill the smaller-scale application deployments, and they will probably grow a little bit over time, but it will take a lot of time before they can come close to the large scale MVS CICS type of deployments.

But IBM claims it’s shipping more MIPS capacity than ever.

On the MIPS thing, I think the doubling of MIPS, the growth of the MIPS capacity of the machines, that is encouraging—but the software that consumes the new MIPS is typically in the WebSphere and the Linux workloads. To support 1,000 users, you have X [times] the number of MIPS that you require in a traditional workload environment. It is not unrealistic that you might need at least 20 times as many MIPS to support the same number of users in a Java environment.

These [new workloads] make sense if the mainframes [they’re deployed on] are bigger [have more capacity] than ever. So, in the same realm, we talk to some smaller customers who are sort of tired of IBM. Their investment [in MIPS capacity] isn’t that large, and maybe they can afford to get off. Realistically, I think if you have less than 500 MIPS on your shop floor, you have a chance of accomplishing that; if you have more than 500 MIPs or even 1,000 MIPS, you will never be able to get rid of [your mainframe].