Mixed messages

Electronic data interchange, or EDI, is status quo for business messaging in the federal sector.

For a decade or more, some agencies have been using EDI, typically the X12 protocol, which is the primary North American standard for defining EDI transactions. It's steady, secure and gets the job done whether processing mortgage insurance claims or ordering supplies from contractors. EDI has become a familiar communication tool in numerous information technology shops.

Enter Extensible Markup Language. The specification provides a way to create Web documents that can be easily shared among organizations. In the business-messaging context, XML stands out for simplicity. Any organization with a Web server and an XML parser, which processes XML messages in much the same way a Web browser reads HTML documents, possesses the rudiments of business-to-business or business-to-government e-commerce.

Some observers once believed that Web-powered XML would sweep EDI out of the business-to-business picture. Yet the overthrow of EDI has yet to take place. Indeed, industry watchers believe EDI and XML will coexist for years to come.

"The sense is that X12 EDI is up and running and is working well," said David Barkley, chairman of the Accredited Standards Committee X12 and director of e-commerce relations at Freddie Mac's Services Development Division. "XML is seen as an additional tool."

Those who decide to juggle EDI and XML have a couple of choices. They can build and maintain separate EDI and XML messaging infrastructures, a rather expensive proposition. But, the better solution, observers suggest, is to pursue an integration strategy that allows EDI and XML messages to be transmitted over the same network. Technology solutions on the market are designed to do just that.

Advantages and Disadvantages

XML has some attractive features as a format for business messages. It is much more intuitive than EDI, experts say. EDI messages are highly compressed and based on codes. For example, an EDI message might say "ST," which stands for "ship to," followed by a numerical code representing a company's address. An XML message, in contrast, might include a tag followed by a company's address.

EDI's complexity — coupled with the expense of maintaining EDI expertise — has kept many businesses on the sidelines. Organizations adopting XML may be able to reach out to more trading partners. XML adherents can also readily embrace new transaction types as business opportunities arise. That's because XML manipulation tools make it easier to customize messages. In short, XML lets groups push e-commerce in new directions.

"Expansion is a major motivation for exploring XML," Barkley said.

XML's structure provides another edge. XML messages include embedded metadata, according to Jake Freivald, director of marketing at iWay Software, a business integration middleware vendor. The metadata provides business context, which cryptic EDI messages lack. Therefore, XML messages are less prone to errors in interpretation, he said.

The promise of XML has left its mark on the EDI crowd. A recent survey of X12 users reveals that 56 percent are deploying XML, while 34 percent are evaluating the technology.

Few of those exploring XML, however, intend to toss EDI. Organizations with "legacy EDI systems are not throwing them out the window," said Dan Heick, director of product marketing at webMethods Inc. "Some agencies have been doing EDI for a long time, and it might be more cost-effective to stay on EDI than migrate away from EDI. They may have trading partners who don't want to migrate away from EDI."

That's an issue for the Department of Housing and Urban Development, which uses X12 EDI and has no near-term plan to adopt XML, according to HUD spokesman Brian Sullivan.

"The migration to XML requires that HUD and all of our business partners convert to XML," Sullivan said.

EDI's ability to handle higher message volume is another reason to keep it around. EDI's compressed nature contributes to its complexity but is an asset in high- transaction environments. A messaging rule of thumb is that an XML message can be as much as 10 times larger than its EDI counterpart.

"For the very highest volumes, XML has the disadvantage of being much bigger than EDI and has requirements for more processing power," Freivald said.

"EDI is still the king" of business-to-business, Heick said. He said EDI accounts for more than 80 percent of the business transactions moving over networks, citing reports from AMR Research.

Against this backdrop, messaging experts expect many organizations to pursue a coexistence strategy. Jeff Eck, global product manager with Global Exchange Services, said customers would employ both XML and EDI, depending on what business problem needs to be solved.

Some organizations already are heading down that path. Freddie Mac uses a number of X12 EDI messages for loan servicing but is building XML messages for real estate finance. The XML messages will help automate loan-underwriting decisions.

Barkley said EDI makes sense for Freddie Mac's loan-servicing side, which collects data on 7 million loans each month in a three-day window. "EDI transactions are very powerful and effective in those conditions," he said.

Loan origination, on the other hand, is "more Web-oriented and more interactive," he said. "We see that as an XML application."

Once a decision is made to use both EDI and XML, the next issue is how to get them to cohabitate.

Ken Volmer, a research director with Giga Information Group Inc., believes organizations can employ "universal translator" software to mediate among different message formats. The translator receives messages in XML or EDI and translates them into whatever format is used internally. Conversely, such a translator can also process outbound messages to suit trading partners' requirements.

Volmer said software from enterprise application integration firms such as Vitria Technology Inc. and webMethods could serve as translators. In addition, value-added network providers, the traditional EDI conduit, may also deliver the translator functionality, he said.

Global Exchange Services, for example, provides data transformation software as part of its trading partner network and as a stand-alone product. The software, called an application integrator, supports both XML and EDI data formats. It works with value-added networks, but also supports protocols for direct buyer/seller connectivity via the Internet, Eck said.

Organizations with mature EDI programs and an interest in XML can use data transformation software to take advantage of existing resources, Eck said. Customers, however, don't always take advantage of this option.

Using an established value-added network for EDI and XML offers some advantages. First, there's the simplicity of adding a new messaging format to an existing network infrastructure. They also offer stability in terms of private-network security and time-tested reliability mechanisms, such as those confirming message receipt. Cost is another issue. Achieving EDI/XML coexistence via enterprise application integration software can cost from $300,000 to $500,000, according to Volmer.

But there's another side to the cost story. XML adherents argue that an organization can use the Internet for EDI and XML traffic, thus avoiding costs associated with value-added networks. Such providers charge per message and can assess fees for maintenance and connect time.

Of course, there's plenty of work to be done to make the Internet a secure and reliable vehicle for business messaging (see box, Page 40).

WebMethods software lets customers "support any payload through any transport mechanism," Heick said. Specifically, webMethods' EDI adapter lets customers support EDI or flat file messaging while pursuing Internet technology, according to the company.

XAware Inc., meanwhile, offers an XML data integration solution that can be deployed as a component within Sun Microsystems Inc.'s Java 2 Enterprise Edition and Microsoft Corp.'s .Net servers. The solution processes EDI messages via a Configurable Text Adaptor or a Java EDI Adaptor, according to XAware officials.

Anyway you slice it, EDI and XML are headed on the same course. Managing the convergence is up to the consumer.

Moore is a freelance writer based in Syracuse, N.Y.