MQ and the management aftermath -- ADTmag

MQ and the management aftermath

By Elizabeth U. Harding
June 27, 2001

IBM more than any other company -- can benefit from successfully connecting the diverse application platforms that have emerged over time. In recent years, IBM met the challenge to connect multiple platforms as it redefined messaging middleware with its MQSeries software program. While much attention has centered on the advantages that asynchronous, message-oriented MQSeries middleware brings to transactional systems, IBM's first goal was more simple -- to provide a way of connecting legacy systems in heterogeneous environments.

Today, that is how many application development managers use MQ. In operations, managing this advanced technology can be a challenge, and an assortment of familiar and new management software vendors are ready to meet this growing need.

After the pioneers

Messaging technology has been around for at least a decade. Among the vendors that pioneered messaging technology are many that remained small, got bought or went out of business. "Pioneering vendors had good technology, but they tried to appeal as technology," said Ed Acly, director of middleware research, International Data Corp. (IDC), Framingham, Mass. "But the way you sell middleware is to sell solutions, [you need] medicine for business problems, not elegant technology."

Application integration has been an issue since the dawn of computing, and IBM's MQSeries message-queuing engine is aimed squarely at solving this problem. Industry watchers estimate that application integration costs can be nine to 10 times as much as the original purchase cost of software. Often for corporate development managers, it is a case that their company just acquired another company and they now have

to integrate one information systems (I/S) system into another and another. That's a huge cost. Or, they have to integrate a system like SAP, Baan or PeopleSoft with hundreds of applications already around the company. Another huge cost. Companies have often dealt with integration themselves rather than looking to a middleware product to solve the problem for them.

"Developing a home-grown system is very complex, and you'll be spending a great deal of effort on developing infrastructure glue," said Colin Osborne, IBM worldwide business unit manager for MQSeries stationed at the IBM U.K. Hursley Lab. "That requires a very high degree of accuracy, and essentially, you'll be using your application developers to write infrastructure rather than business code." A favorable alternative, from Osborne's point of view, is to let IBM help via MQ.

The drive up into enterprise application integration will be a major push of computing over the next few years. "With every company you talk to on the business level, the key issue they are struggling with is integrating these functions to get greater efficiency," said Osborne. "And once you start talking about cross-enterprise multiapplication integration, you're talking about the most complex computing environment known to mankind."

That said, the middleware market today is relatively small. IDC projects this market in 1997 to be around $289 million, but Acly said he wouldn't be surprised to see "a rapid growth in 1998 as people figure out how to develop and deploy message-queuing technology." Although IBM began commercializing its product several years ago, MQSeries is still relatively little known within much of the development community. MQSeries is currently installed in about 4000 customer sites worldwide, according to Osborne.

One of the major strengths of MQSeries is that it runs on most major platforms and network protocols. MQSeries will take you from Sun to Tandem, from DEC to NCR or from any one of these to IBM. It runs on 25 platforms and supports most of the key network protocols. "In the new world of the Internet, companies face a challenge -- they understand TCP/IP, but they don't know how to get from the TCP/IP world to the back office SNA world where most of their corporate data is stored. MQSeries does that," Osborne said.

When IBM began to conceive MQ -- at the request of customers -- it decided -- again, at the behest of customers -- to connect MQ to non-IBM platforms. According to Rob Levy, CEO of MQTech, a small consulting firm based in Glendale, Calif., MQ has a major advantage by covering so many platforms. "A great number of MQSeries licensees do not have IBM equipment," said Levy. "This is the first time that IBM has been able to successfully sell IBM products to non-IBM sites."

IBM did not develop MQSeries from scratch. SSI (Systems Strategies International, a company that at one point became part of Baby Bell Nynex) originally built a messaging engine called ezBridge in the late 1980s. SSI was acquired in 1993 by Apertus. Building upon the ezBridge engine, IBM developed MQSeries Version.

Today's use of message-queuing technology falls in the following three areas according to Roy Schulte, vice president of Research Advisory Services for Stamford, Conn.-based Gartner Group: one, for plain distributed application support; two, for asynchronous applications that use a store and forward mechanism like E-mail; and three, for connecting dissimilar applications.

Synchronous versus asynchronous

Figuring out how to develop and deploy MQSeries is not easy. In fact, messaging technology may impact the way applications are being built. "Application developers should really be thinking of building applications in an asynchronous way from design on up," said Osborne. Continuous synchronous links do not scale. "You need to go asynchronous in terms of pure performance." Moreover, Osborne said that a synchronous link cannot guarantee delivery.

As companies go across their organizations to other organizations, they are less able to guarantee availability of physical devices. MQSeries is guaranteed to deliver even when there is an interruption in the network.

"Database connectivity works extremely well in high-volume, locally assembled systems running on the same CPU or cluster," said Osborne. "Once you move beyond that to a company in the Far East, for example, you can't manage it because you may not know what system they are running, when they are up and when they are working." I/S cannot manage this type of business situation with a continuous connection as in a synchronous link, said Osborne. "You need a disconnected connection which is independent of the applications or the systems being available. When you used messaging in the old days, you had one operating system and database synchronization was all straightforward. The system took care of it. In the distributed world, if you try to do a database update in realtime synchronously, you can run into serious problems."

"Asynchronous message queuing is the only way that guarantees that, at the end of a transaction, all the databases will be synchronized," said Les Yeamans, president, NASG, a consulting firm headquartered in Scarsdale, N.Y. "The database companies tried to make us believe that we needed client/server, and that all the applications had to be synchronous. Ninety-eight percent of applications could be handled more practically by using asynchronous message queuing." NASG provides information on this technology, and lets people know what users are doing and what problems they are encountering at the Web site: http://www.messageQ.com

Managing MQSeries

MQSeries can be pervasive, but it can become a management headache. "MQSeries is truly peer-to-peer," said Yeamans. "It's almost like a headless monster. There's no one place where you can get it all. That's why third-party management products are so important."

To meet the need to manage, according to Osborne, IBM has currently struck partnerships with 85 vendors whose products add value to MQSeries. "Because our customer sites are so different and many already have a systems management tool in-house, we won't build [into MQSeries] a one-size, one-does-it-all systems management system," said Osborne. "There is no one system that can do it all. [The solution] may be too big for some, too small for others."

Still, IBM has moved toward supplying at least one bundled management option. Addressing manageability needs of MQSeries in the field, IBM and Candle Corp., Santa Monica, Calif., have announced the bundling of Candle's tools with every shipment of MQSeries. (In 1997, Candle acquired the MQView product line from Apertus Technologies Inc.) Available in Q3/'98, the Candle Command Center Admin Pac for MQSeries is a limited-version tool suite for message development, configuration and availability management. Joining Candle among the ranks of large vendors offering enterprisewide systems management for the MQSeries environment are IBM's Tivoli subsidiary, Boole & Babbage, Computer Associates, BMC, Landmark and others.

Boole & Babbage, San Jose, Calif. launched its Command MQ product suite for monitoring the whole MQSeries topology in the latter half of 1996. "We manage MQSeries and also the entire enterprise," said Mike Bunyard, B&B senior director of product management. "If a management product focuses only on MQSeries and not on the hardware and network devices, MQSeries often becomes a victim of a surrounding infrastructure problem."

According to Bunyard, customers want to manage the middleware piece just as they manage their transaction servers. Companies with a mainframe-centric view (who use MQSeries to take information from the mainframe and put it out into other environments) typically want to use 3270 terminals or PCs emulating a 3270 terminal whereas people responsible for managing MQSeries in a more distributed environment want the ability to manage from a graphical user interface (GUI). Bunyard said that Command MQ supports both 3270 terminal and GUI interfaces.

MQ on track

When Burlington Northern Inc. and Santa Fe Pacific Corp. merged their rail lines, they brought in MQSeries to get their separate MVS mainframe systems to communicate and chose Command MQ to manage their systems.

"When we first implemented MQSeries about three years ago, we had to write our own tools, our own utilities," said Terry Meyer, senior systems engineer, Burlington Northern Santa Fe Railroad, Fort Worth, Texas. "With Command MQ, Boole is providing the tools, and they also provide scripts for monitoring. We don't have to maintain our own tools anymore."

Landmark Systems Corp., Vienna, Va., is offering tools focused on performance management not only from a production but also from a life-cycle point of view. "Customers tell us that they don't want to deal with performance during production," said Mark Knecht, Landmark vice president of marketing and business development. "They want to plan for it during the development time frame. The Monitor is not a smokestack solution. It addresses performance management from a life-cycle perspective." Landmark began shipping its PerformanceWorks' Monitor (TMON) for MQ Series last December.

ABM/AMRO, a financial services company based in Chicago, needed a tool to be able "to get further under the covers of MQSeries and see what's happening," said Gregory Korbecki, ABM/AMRO systems officer. Since ABM/AMRO has been using Landmark products on the mainframe for MVS, CICS and VSE, Korbecki said the Monitor's look and feel is comfortable and similar to Landmark's other products. According to Korbecki, ABM/AMRO is using MQSeries for some smaller financial transfer applications and is in the process of developing a large call-center application that will run on MQSeries.

Small is beautiful

The message management market is not only made up of large systems management vendors. Small startups like NasTel Technologies Inc., Level 8 and others are ready to try their fortune as well. Among these startups are developers that had an early hand in the formation of message queuing middleware. Some, such as NasTel, suggest that full-fledged MQSeries implementations can be overkill in some cases, and that too many overly encompassing approaches to MQ will cause "analysis paralysis" in I/S and slow the market.

NasTel, based in New York City, has become one of IBM's premier certified MQSeries service providers. "In order to manage MQSeries, you need a certain amount of expertise of its internals," said Krish Shetty, NasTel president. "Our people came from SSI and have a strong knowledge of MQSeries and middleware in general. Companies generally underestimate the amount of expertise and time needed to take full advantage of MQSeries. There's quite a bit of work to be done after you get MQSeries in house."

NasTel's product MQControl is a point solution compatible with other network management frameworks but does not require an existing product set to operate. As such, MQControl can hook into any SNMP-based management platform, such as HP OpenView, NetView, Tivoli or CA's Unicenter or work as a standalone non-SNMP tool. MQControl is said to work well with other performance and systems management products. NasTel has relationships with vendors, such as Boole & Babbage, which has licensed NasTel technology, and Landmark, which resells MQControl as a complementary solution to TMON MQ product. "There's no question that MQSeries is the right solution for connecting various systems and applications in today's distributed environment," said Shetty. "The challenge is starting out with a system that does not cause future problems. If you want a support tool while developing which can grow into a systems management tool, our tool is very effective."