Buying Middleware, Without the Burn

• 07/19/1999

Special Report: Middleware

The decision is final. You need to integrate business applications, and middleware looks like the appropriate strategy. With lean staffing, your organization decides to buy connectivity solutions rather than develop them in-house.

Where do you begin? And how do you keep from getting burned by a wrong middleware purchase?

The most important step is to carefully architect a long-term middleware plan that reflects your business goals. In too many cases IT managers are influenced by marketing hype or high pressure when making technical selections, forgetting the real business drivers in the process. Or they make snap decisions based on immediate tactical requirements: The quickest fix may not be the most effective.

These problems can be avoided by asking the right questions about middleware products.

Middleware is designed to arbitrate differences between disparate platforms and protocols and to allow connectivity between applications. In most heterogeneous environments, middleware is a necessity for translating the languages spoken by different applications.

In homogeneous environments, for companies with a small user base or with applications that are not transactional in nature, middleware can be overkill. Posting legacy data to a Web site, for example, can be accomplished with simple screen scrapers, says Anish Dhanda, president of systems integrator NetNumina Solutions (www.netnumina.com). Only when Web-based data is more transactional -- when users can make changes to forms or request a change to data, for example -- is middleware required.

The key to creating an effective middleware solution is clearly defining the endpoints. "It may sound obvious, but you can’t have a middle without having two ends," says Peter J. Weyman, vice president at Rogue Wave Software Inc. (www.roguewave.com), a middleware vendor.

Systems connecting Unix to NT or allowing an inventory application to talk to distribution clearly require a discrete middle to their ends. Some buyers, caught up in the need to deliver a modern solution, implement elaborate middleware products that are unnecessary when similar systems are used, Weyman says.

Once certain that middleware is the answer, then you have to choose from the dozens of products available. Low-level "plumbing" tools provide pipes that connect systems. Higher-level products add sophisticated functionality, such as queuing, guaranteed delivery and connectors between applications.

All but the most rudimentary of middleware products offer messaging, a key function that enables distribution of the communication information. Messaging can be performed on a one-to-many scale -- called publish-and-subscribe -- which is appropriate for distribution of information that requires no response on the part of recipients, such as stock quotes.

When messaging is needed on a one-to-one basis, the primary question is whether to use synchronous or asynchronous transmission. "Our advice is to choose sync only if you have a good reason," such as a need for real-time, mission-critical transmission or the need for an order of precedence, says Jeff Held, service line leader for technology for the Americas at Ernst and Young.

Some IT professionals make the mistake of thinking asynchronous is akin to e-mail, a transmission that is slow and unreliable. But with the proper tools, you can have subsecond transmission, logic that enables verification of delivery and timeout, and resends when confirmation is not received.

Even if synchronous transmission is necessary for some applications, it should not be used across the board. Using all-synchronous can easily create a "deadly embrace, where everything stops waiting for everything else," Held adds.

Never use a synchronous solution if communications throughout the system are Internet-based. Because the availability of cyberspace users is uncontrollable, applications that rely on synchronous communications can be backlogged by undeliverable messages.

Choose a middleware solution that is open and standards-based. Focusing on standards such as COM and CORBA not only ensures interoperability between the middleware and other products you may eventually integrate with, but they also buy you the critical mass that comes with using an industry standard.

Buying open solutions helps preserve your middleware investment. "Proprietary tools and interfaces get customers in trouble eventually," predicts Ivan Casanova, product manager for middleware vendor Level 8 Systems Inc. (www.level8.com). "When technologies embrace open standards, they lend themselves to being long-term solutions."

Although the Internet is a work in progress, it is wise to choose products that are Internet friendly. Business rules need to be delivered over many transports in a Web -centric environment, so products should write and store rules in XML rather than a proprietary technology, Casanova suggests.

As with other IT technologies, middleware products need to be monitored and managed. But because the market is still developing, many products do not offer management functionality of their own or interoperability with third-party management products.

NT managers should consider and plan for management they will implement, even if they opt to bypass operational management for middleware now, says Mark Kusionowicz, director of EAI at Candle Corp. (www.candle.com).

ProTeam.com, a 4-year-old direct marketing and catalog sales company in Secaucus, N.J., created its $7.5 million IT infrastructure based on an enterprise application integration middleware product. Seven systems handle as many as 30,000 orders per day, each processing transactions through multiple interfaces to other systems.

"Over time, as you connect more systems, the monitoring of interfaces becomes critical," says Dominic DiMascia, CIO of ProTeam.com. "The more interfacing you do, the more monitoring you need."

ProTeam.com developed its own interface monitoring system after finding the management features in its middleware product were not robust enough to handle its mission-critical transactions. DiMascia considers it a lesson learned that the integrated monitoring system should have been in place earlier, but it is a lesson that could have been even more painful if the product dealt in proprietary technologies that resisted integration.

Another equally critical element in the middleware selection process is security. While most IT managers focus on simple security issues, such as external viruses, they should search for middleware products with fine-grained access controls that can protect networks from internal breaches, says Len Halio, president and CEO of Gradient Technologies Inc. (www.gradient.com).

The majority of security breaches -- and the most expensive breaches -- are committed by internal users, he says. To counter this threat, IT managers should select middleware that can incorporate a variety of authentication technologies.

The selected product should be able to incorporate developing authentication technologies, such as biometric mechanisms, and should be open-ended and extensible to meet changing security needs, Halio adds. Security built on proven technologies are another good bet.

Choosing a scalable middleware solution can be the most challenging part of the process for NT managers. "In middleware, scalability is the hardest issue," says Tom Laffey, cofounder and chief technical officer of middleware vendor Talarian Corp. (www.talarian.com). "There are hundreds of processes and so many things that can bite [you]."

The most important step is to build a prototype, develop a testing plan and test, test, test. Anything less will result in wasted efforts and potential failure. "If you don’t have a sound testing plan in the beginning, you will have more problems in the end," NetNumina's Dhanda says.

Furthermore, testing should be done slowly and deliberately. It is not a step to be rushed, Dhanda adds. Unfortunately, the distributed nature of most applications being used with middleware makes it difficult to test an implementation from beginning to end.

"Every middleware vendor says its products are scalable. In reality, none of it is," Talarian's Laffey says. When a site grows from 10 servers to 100, the complexity doesn’t rise in a linear fashion, but geometrically. When testing for the scalability of a middleware product, NT managers should not be satisfied to see a product move from one machine to two. "You hit the scalability issues when you get into the hundreds of machines," he says.

Moreover, the organization should be testing scalability of the number of processes, not just the number of machines. Laffey says scalability-minded vendors can help test products by passing messages at some tunable interval, increasing the volume until the middleware breaks. The failure provides an opportunity to better understand the product’s strengths and weaknesses, Laffey says.

Some products are better suited than others to grow. "Pick a middleware product that allows you to grow to additional server nodes, such as a server farm," says Joe Menard, vice president of marketing at BEA Systems Inc. (www.beasys.com). This can be especially important if your business is or may someday be operating on the Internet, where demand is impossible to predict.

Even with these precautions, some scalability requirements are difficult to anticipate. For this reason, it can be beneficial to purchase middleware technology with built-in scalability functionality. Some products offer rollover and load balancing features to help NT sites better manage middleware scalability.

Whichever middleware product is chosen, be careful that it matches the skill sets of your development team. Some choices are obvious: COM-based tools for NT-centric development teams, MQSeries for predominantly IBM shops.

Other selections can be trickier. You may have a significant volume of mainframe data to integrate, but if the majority of your development team is fluent in more sophisticated tools such as Visual Basic, your best middleware choice may be products that emphasize VB-related skills. On the other hand, a tactical middleware implementation that is not expected to grow may be a good application for legacy-style middleware tools, BEA's Menard explains.

In general, low-level plumbing tools are best-suited for performance-critical middleware that you cannot create in any other way. "We suggest that end user organizations focus on high-level products whenever possible," says Held of Ernst and Young. "Higher level tools are less dangerous and you don’t have to be a high priest to write good code."

If middleware is part of the enterprise’s long-term plan for systemwide integration, a limited engagement of consulting can help bring developers up to speed on an unfamiliar technology. Many NT managers worry that engaging a consultant team can be costly, but it can be an effective strategy.

One possibility is to hire a vendor who can provide customized code and consulting experience, but who also understands how to map business requirements to technology. Insist that members of your staff assume the role of co-developers and that knowledge transfer is executed during the implementation process.

Buyers should also test out vendor support before making a commitment to any middleware product. Will the support be available when you need it? Did you get answers right away or was there a wait? Did support staff provide knowledgeable information or merely recite from the manual? "Middleware is complicated," Laffey says. "You’re going to need that support."

Once you have a well-devised business plan and an understanding of the developers’ skill set, selecting the appropriate middleware product is simple. "Technology should be your last thing," NetNumina's Dhanda says.