IBM Targets Potential Customers with Revamped MQ Release

Big Blue hopes the latest release will entice fence-sitters

IBM Corp.'s announcement last week of a new version 6.0 release of WebSphere MQ boasted what Big Blue claims are more than 150 enhancements, including improved support for building and using an enterprise service bus (ESB).

But IBM’s revamped WebSphere MQ is as much a testament to the company's aggressive ambition as it is a message-brokering Swiss Army knife.

For while IBM says as many as 12,000 shops are today using WebSphere MQ, officials believe that’s just the tip of the iceberg. More to the point, they argue, many of the new version 6.0-specific WebSphere MQ enhancements will address this untapped Silent Majority.

“One of the key things that we’re trying to address with this announcement is to really try and identify—and make special enhancements for—the large set of customers out there that don’t use WebSphere MQ or any other similar solution,” says Leif Davidsen, an IBM WebSphere product manager who works specifically with WebSphere MQ.

Just how many should-be WebSphere MQ customers aren’t using that product?, and how are they servicing their message-queuing requirements? Davidsen says a lot of companies are still doing things the old-fashioned way. “There’s sort of one large chunk of the non-middleware market. We believe there’s a truly large percentage, probably around 70 to 80 percent of all data moving throughout the enterprise, [that] is using a mixture of custom code or predominantly, as a matter of fact, FTP.”

For a variety of reasons, Davidsen says, this approach isn’t cutting it anymore for customers. In fact, specific drivers such as regulatory compliance, supply chain integration, and the increasing primacy of service-oriented architectures require companies to make changes to even the most stable of long-functioning status quos.

“As businesses look to make sure that they can validate that they are in compliance with certain regulations, that they can take advantage of some of the capabilities that MQ provides, to make sure that they don’t have to directly implement some of those steps, that’s certainly one of the most important drivers,” he says. “Another segment we’re also seeing, and this, to be honest, took us slightly by surprise, is a sort of outside-in driver of supply-chain integration. A number of businesses have recognized that they actually need to integrate their own internal data to make sure that they can provide that data in real-time to their supply chain suppliers.”

For that reason, IBM plans to pitch WebSphere MQ to these customers as an auditable, manageable, and reliable message-queuing and data-integration framework. “We’ve tried to address some of the key aspects of the technology, particularly for new users. We’ve added in a lot of key technology both to make sure that it’s easy to pick up, and we’ve got a quick tutorial built into the product,” Davidsen notes.

Of course, many customers—particularly those in mainframe shops—live and die by an if-it-ain’t-broke-don’t-fix-it motto. These customers might not be quite so willing to give up the custom scripts that have served them well. For such shops, Davidsen says, IBM has developed a new utility that lets them incorporate these scripts into WebSphere MQ itself.

“We’ve actually included in the product a file transfer application that allows businesses to keep running their data exchange using [FTP-style] approaches. So to make sure that their skills are sufficient to move data over the enterprise -- but by running the file transfer over MQ—you can get the advantage of the assured delivery, you can take advantage of the logging, and also you can take advantage of all of the configuration and monitoring tools that you get as standard with MQ.”

How does this utility work? Davidsen says it supports a scripting language that should enable customers to move the lion’s share of their custom scripts over to WebSphere MQ—as well as continue to develop new, MQ-ready scripts. “It is very much a language so customers can replace some of their scripting environments to take advantage of some MQ functions."

Of course, the new WebSphere MQ facility doesn’t feature script discovery or canned migration capabilities, Davidsen concedes. “I would say we don’t have a discovery or migration tool for those scripts. We do have a partnership with CommerceQuest, and they have a product that works with MQ for file system data, and that works to further extend our capabilities in this space.”

The revamped WebSphere MQ features a new Explorer console that’s based on the open-source Eclipse IDE framework: “In a large set of functions, you can now configure your entire MQ infrastructure on an Eclipse console running on Windows or Linux, and that includes [configuring WebSphere MQ on] iSeries as well as z/OS.”

Other WebSphere MQ 6.0 highlights include integrated support for .NET classes, which lets .NET applications natively invoke MQ as a connectivity environment; integrated SOAP support; and—when used in tandem with WebSphere Application Server and WebSphere Business Integration—ESB capability.

“Customers using the [WebSphere] Application Server, WebSphere MQ, and also the … WBI message broker, can all take advantage of the same Eclipse framework to launch and configure sort of their entire connectivity infrastructure,” Davidsen explains. “This enables sort of their own implementation of what we would call the ESB framework, and we believe the flexibility that surrounds it would allow them to implement and configure from a single tooling environment this type of universal connectivity.”

But will all of these new features be enough to entice fence-sitting users to take the WebSphere MQ plunge? More to the point, why should an organization that has a perfectly functional ad hoc (script-based) solution pony up the cash for WebSphere MQ—especially on the (comparatively more expensive) mainframe?

Davidsen cites the aforementioned market drivers as one factor, but claims that there’s also an ROI case to be made for WebSphere MQ. For this reason, he doesn’t think IBM will be cutting first-time adopters any breaks on MQ pricing.

“What we’ve been looking at is the level of expenditure that we’re seeing customers spending on sort of application connectivity and creating and maintaining these [scripts], different analysts have come up with a 35 to 40 percent figure for IT budget that is actually being consumed by these [scripts],” he says. “And based on these costs, customers could save a tremendous amount of their IT budget over a quite short period of time by starting to move some of this connectivity over to MQ.”

About the Author

Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.