Be prepared to learn some of the finer points of middleware and XML if you're plotting an architecture to help your company participate in one or more of the business-to-business marketplaces that industry watchers predict will flourish in 2001.
Once you've built an on-ramp to a marketplace, one of the key challenges will be integrating data into the back-end applications that need to use it. That's where middleware can provide a crucial assist in translating, routing and securely delivering data and where XML-based messaging can make it easier to cope with data in widely varying formats.
But technology is only part of the equation, analysts warn. Before you start to think about software, your company will need to examine its business processes and trading-partner relationships to figure out which ones will be affected and improved by the marketplace. Then you'll need to identify all of the applications and databases involved, because that information will affect the architecture decisions that have to be made.
While all that may sound straightforward, the work can get complicated, particularly at big firms. Several departments may have their own systems. The situation can become even more complex if there have been mergers.
Simon Yates, an analyst at Forrester Research Inc. in Cambridge, Mass., says he recalls one large company that had several competing integration projects going on in different business units, "and it was essentially a race to see who could get their project done first." The strategy was to "force-feed" the winner's solution onto the others.
"It's extremely difficult to get everybody on the same page. But it will save lots of companies time and wasted manpower if they build a general-purpose infrastructure across the company and pick vendors whose software is adaptable to future needs, regardless of business unit," Yates says, cautioning, "It's easier said than done."
| |  |
| Office Depot's Mike Kirschner says inconsistent e-commerce standards are "what causes us the most pain" |
Form a Multidisciplined Team
You can better organize that effort by forming a full-time central team with enterprisewide and cross-enterprise scope to develop, deploy and maintain the integration infrastructure, advises Roy Schulte, an analyst at Gartner Group Inc. in Stamford, Conn.
The team will have to carefully assess the current infrastructure and plan for any additional software that may be needed. It'll get a head start if there's already a flexible, multitier architecture in place, with presentation, business-logic and database layers.
United Parcel Service of America Inc., for instance, unknowingly laid the foundation for future Web endeavors seven years ago when it built custom middleware, running on an IBM AS/400 server farm, for a new client/server customer service initiative. IT staffers identified all the legacy applications and databases that would be needed and created a standard interface specification and message format for those applications, says Mark Hilbush, an Internet systems manager at UPS.
Atlanta-based UPS later adapted that infrastructure, adding Web and application server tiers, to launch the Web site customers now use to track their packages. That infrastructure could be modified further to connect to other presentation layers, including business-to-business marketplaces, Hilbush says.
Assess Existing Infrastructure
The messier and tougher job is back-end integration. Rick Hebert, a senior architect at NerveWire Inc., a consultancy in Newton, Mass., says clients have typically approached application integration in the following ways:
• By building and designing a point-to-point integration system to "hard-wire" applications to talk with one another. "It's a very complex environment to manage," Hebert says.
• By enlisting message-oriented middleware such as IBM's MQSeries or Palo Alto, Calif.-based Tibco Software Inc.'s Rendezvous. An application is connected to a message bus that manages communication between programs, which may be running on different operating systems. The downside is that data translation between applications, as well as transaction management, still must be done, Hebert notes.
• By using enterprise application integration (EAI) tools, many of which have been improved to handle a wide range of functions, including guaranteed delivery of messages between applications, transaction management, data translation and security.
Such middleware helps with external business-to-business integration and internal application-to-application integration. With this approach, each application and its integration characteristics are defined once in a metadata repository, Hebert says. "Using these EAI tools, we basically design the system once, and then we can tie into a number of marketplaces with very little custom work for each one," he says.
Companies, in turn, can check their trading partners' preferred means of e-commerce on the evolving Universal Description, Discovery and Integration Business Registry.
Vendors of integration middleware include Tibco, Extricity Inc., Neon Systems Inc., Vitria Technology Inc. and webMethods Inc. Microsoft Corp. aims to compete with its BizTalk Server, and IBM offers MQSeries Integrator.
While those products remove a good portion of the design and build work that developers used to do from scratch, Hebert says, "they're not silver bullets." Be prepared for a lot of analysis and design work, he cautions.
Some companies may decide not to use all of an EAI product's capabilities and may instead opt to use adapter code to connect to middleware they already have in place.
Eastman Chemical Co. in Kingsport, Tenn., has been processing more than 65,000 electronic data interchange (EDI) transactions per month with more than 400 trading partners. Now that it needs to deal with some partners using XML, Eastman has enlisted middleware from Fairfax, Va.-based webMethods to translate messages to XML and deliver them securely and reliably, says Bill Graham, head of Eastman's Integrated Direct effort.
Graham acknowledges that webMethods, through its acquisition of Active Software Inc., can provide the internal EAI engine that his company needs, in addition to the external capabilities it's using. But, he says, Eastman Chemical was "already down the path" internally with MQSeries and plans to stick with IBM's product for sending messages to the SAP R/3 system it's installing to replace R/2.
Neither the webMethods nor the MQSeries middleware eliminated all the work. IT staffers chose to build adapter code to link MQSeries to R/3 because they deemed that the prebuilt adapters on the market were too expensive for the functionality they needed.
One way to off-load part of the overall work is to join a marketplace. Sears, Roebuck and Co. in Hoffman Estates, Ill., has 30 to 35 mainframe applications that use EDI-formatted files. IBM, which hosts and maintains the Sears system, translates the transaction files and transmits and loads them in batch mode into the mainframe applications, explains IT resource manager Pamela Cox.
That back-end system didn't change when Sears joined San Francisco-based GlobalNetXchange LLC's (GNX) marketplace. IBM simply routed the EDI transactions to a middleware server from Cyclone Commerce Inc. in Scottsdale, Ariz., that Sears installed for security. The messages then go from the Cyclone server to GNX, which translates them into the format in which Sears' trading partners need to receive them and then delivers them.
Over time, says Cox, Sears will write new applications that will generate and accept the more neutral and flexible XML format. But "it will take a long time before the EDI files will be gone," Cox predicts. "Some are very old legacy applications that are working fine."
GNX won't push them. Gerry Palmer, chief technical officer at GNX, says the exchange is "very agnostic about EDI vs. XML." Palmer says he sees the benefits of XML for handling rich message content. But he says he also recognizes members' huge investment in EDI, not to mention the increased processing power and bandwidth needed for XML files, which can be five to 10 times larger than EDI files.
Evaluate XML Standards
Some analysts say those concerns are unfounded because bandwidth and disk space are plentiful. But that's not the only potential hurdle with XML. In the absence of XML standards, vendors and vertical industry groups have tried to define purchase orders, invoices and other important business documents. That has forced many companies to support many different XML document types.
Office Depot Inc. in Delray Beach, Fla., for instance, supports Ariba Inc.'s Commerce XML (CXML), Commerce One Inc.'s Common Business Language (CBL), Datastream Systems Inc.'s iProcure network, standards from the Open Buying on the Internet Consortium, and XML interfaces developed in-house.
Problems surface when firms implement the same CXML or CBL document differently. One customer might put a shipping or department field in a different place than another customer would, says Mike Kirschner, vice president of e-commerce development at Office Depot.
"We have to support inconsistent standards, and that's what causes us the most pain," says Kirschner. "If you look at EDI, the reason it's successful, they figured all that stuff out."
 | 
| |
 |