For years, enterprises have relied on traditional electronic data interchange (EDI) to simplify and speed up their transactions with customers, suppliers and other partners. Now, along comes the document-tagging language XML, with the potential to reach new markets, simplify access, populate Web pages and serve as an Esperanto format for transactions of all kinds. Should companies stay with EDI? Should they move to XML? Should they try to get EDI and XML to interoperate? Many are finding that they can do all of the above - if they use the right tools in the right ways.
 | | | The Outsourcing Option Third-party services can handle EDI/XML interoperability for you. For some enterprises, bringing EDI/XML interoperability in-house may not make sense. Smaller companies may not want to bother with the effort necessary to support EDI, even with the EDI/XML tools available. Luckily, there are services that can handle your transactions for you, delivering the connectivity and integration you need. CommerceQuest Inc. in Tampa, Fla., provides one such service. Clients can have a variety of reasons for using this service. They may not have EDI capabilities, but want to do business with a company that mandates EDI. In such a case, CommerceQuest receives the transactions from the client company in whatever format, translates them to EDI and forwards them to the client's partner. The partner sends EDI to CommerceQuest, which translates the EDI into the client's preferred format and forwards it to the client. Another scenario is where a pure EDI client wants to branch out to non-EDI companies without implementing interoperability in-house. The client sends and receives EDI to CommerceQuest, which does the translation for the non-EDI company. "Either way, this saves companies a lot of effort," says Colin Osborne, chairman of CommerceQuest. CommerceQuest clients include Global 2,000 companies as well as e-business companies looking to link with business partners. Services like CommerceQuest make it less likely that companies will implement their own EDI capabilities, since that interoperability can be outsourced. At the same time, such services typically use XML exclusively internally and communicate with XML users. Ironically, this EDI/XML interoperability option will probably serve to further reduce the need for EDI in the future. |
| |||
Many enterprises embracing both EDI and XML started out in the EDI arena years or decades ago. For instance, St. Louis-based Transentric, which began life as the technology arm of the Union Pacific Corp. rail conglomerate, has been using EDI for more than 20 years. It currently handles more than a million transactions per day with some 8,000 partners on its value-added network (VAN).
Aircast Inc. in Summit, N.J., is another example. The maker of orthopedic braces and other medical products began establishing EDI connections with very large distributors of its products when it was unusual for small businesses to get involved with EDI. Aircast's motivation was simple: To expand the market for its products, it had to adopt the preferred connection method of the larger companies, namely EDI. That investment paid off: Approximately 40% of Aircast's business moves over EDI.
Why XML?
Enterprises have a variety of motivations for wanting to get involved with XML. Many are desperate to get involved in e-commerce but have no idea how to get started, given their current technology. In industries that already have online marketplaces and portals springing into existence, XML is often the required admission ticket. Many firms view the advent of XML as the golden opportunity to automate processes from beginning to end, with the XML format as the central touchstone.
"We have a goal to eliminate manual processes entirely," says Susan McKay, vice president of customer and information systems at Aircast.
For EDI companies, the motivations emerge from some of the drawbacks to EDI itself. Most EDI traffic flows over VANs, which can be expensive. The open and free Internet beckons, and while EDI over the Internet is possible, it's not fun. In contrast, XML is a child of the Internet and seems a more natural format to use. EDI is also primarily a one-to-one technology, while Web-based marketplaces allow many-to-one connectivity. "One goal for exploring XML is to broaden our group of trading partners to include those who - for whatever reason - don't use EDI," says Ken Olsen, assistant vice president of marketing at Transentric. In addition, Transentric aims to use its combined EDI and XML prowess to give such increased access to partners as part of its value-added message-management offering.
As with the original adoption of EDI, one draw of XML is the fact that your potential business partners may be using it. "Many of our large clients - including automotive and chemical vertical industries - are moving into the growing XML user community," says Randy Morin, director of e-business solutions at Transentric.
Another reason to master EDI/XML interoperability is so you can offer that connection as a service to others. For example, SupplySolution Inc. in Santa Barbara, Calif., aims to calm supply chain nightmares for clients with its i-Supply service. Many of these clients are struggling with EDI's limitations due to such things as a lack of real-time information and EDI's point-to-point nature. SupplySolution says it doesn't see either EDI or XML as complete answers, but as parts of a package it can offer clients.
What to Look For
If your industry already has a recognized online marketplace to partner with, it's a good idea to follow its lead on tools and technologies. Platform considerations are paramount because you don't want to make massive hardware purchases to support EDI/XML interoperability. Your goal should be to leverage your existing infrastructure investment.
"We're a Windows shop, so Microsoft's BizTalk server technology seemed the ideal solution for our XML needs," says McKay. The low cost of ownership and ease of use were also important to Aircast.
One alleged advantage of XML is its utility in any-to-any connectivity; it can ensure that a given product will enable you to connect with everyone you need to - or anticipate needing to. There are also different dialects of EDI, and you want to make sure your chosen technology handles them all.
"You don't want 20 different products," says Vicente Manalo, a senior analyst at Aircast. "You want a single product that will talk to everyone."
That said, different products may satisfy different requirements. For example, you might use one component to do EDI mapping and another to translate between XML and EDI. Another consideration here may be integration with existing systems. Investigate whether your current EDI vendor has a tool that simplifies certain tasks with its system before trying to whittle a third-party tool to fit.
It's also advantageous to have data in XML format for supporting e-commerce and portal sites. Pure translation products may be wonderful, but if they can't take it to the Web, they may fall short of your aspirations. If you're looking to do e-commerce, especially delivering content to Web browsers, make sure that your XML tool can go that extra mile for you.
You clearly need to try before you buy. You can set up some trial projects to get an idea of how - or whether - the product can help you. You can also get an idea of how much integration effort will be necessary if you proceed. For example, Aircast used a beta release of BizTalk for six months.
Fastenal Co. in Winona, Minn., had several hoops that any XML technology would have to jump through. A decade-long EDI user - thanks to the demands of its largest customer - the industrial and construction supplier knew that its existing system couldn't handle XML. Still, Fastenal needed to accept XML transactions to deal with portals and dot-coms. In addition, it wanted to unite its more than 600 branch locations with a common look and feel. And there was that pesky back-end connection. "Seamless integration was of prime importance," says Eric Falls, e-business integration manager at Fastenal.
Luckily, Sterling Commerce Inc. in Dublin, Ohio, had the necessary back-end connectivity and XML capability. Sterling Commerce is mostly known for its traditional Gentran EDI products, but it also offers XML connectivity through some key partners.
This illustrates an important point. Fastenal could have chosen an EDI/XML product and done the heavy lifting of integration from scratch. But by researching its needs more fully, the company was able to frame a better system for its situation. And by carefully investigating vendors, Fastenal discovered a technology set that would meet its needs far better and more simply than a homegrown solution.
Similarly, SupplySolution had a number of priorities for any XML technology. "We operate as a pure [application service provider], so we needed a technology that would support that commitment," says Stephen Bell, chairman and founder of SupplySolution. In addition, since the company tries to smooth transactions for a variety of clients, it needed technology with a variety of maps ready for use. Peregrine Systems Inc. in San Diego filled the bill on these and other counts.
Seek Outside Help
One of the most important points is that it may be necessary to look to outside help when implementing EDI/XML interoperability. "Initially, we tried to build the XML part ourselves," says Bell. "Then we realized that XML is not our business, so we looked to experts for the technology we needed." The same is true for many companies. Sure, you can roll up your sleeves and write it all from scratch. But odds are that you would do better to consult XML experts who do this routinely.
EDI veterans say they often view the addition of XML as dejý vu all over again. Way back when, they had to integrate EDI and its connectivity demands into their existing sales and procurement infrastructure. Now they face a similar challenge with XML.
It's also important to remember that XML is a data format, not a protocol or an application. "You could use XML tags in Cobol if you wanted to," says Fred Domke, chief technology officer at Transentric. The argument is that XML, as a data format, isn't going to buy you much by itself. What matters is the system - including transport, storage and transformation - that you build around it.
For instance, Transentric is using a tool kit from XMLSolutions Corp. in McLean, Va., as part of its EDI/XML and any-to-any processing. But this is only one component. For example, an application may receive a message for processing. That processing may include various stages such as validation and sequencing. One of these stages may involve translation between EDI and XML. Thus, the overall process is a much bigger picture that this translation must fit into.
This is especially true when using EDI/XML transformation as part of an enterprise-class application. Can the tool handle the load? What if the enterprise is offering this connectivity as part of a service? Can the tool scale to manage unpredictable volume? How does the tool behave as part of a system where security, reliability and fail-over require special technologies and strategies?
When building EDI/XML connectivity into an application, you clearly want the component to be portable across any platforms you'll be using. Careful attention must be given to the application programming interface or other hooks for linking with the rest of the system. For instance, Java-based tools have a special appeal for Web-based applications.
One trap that developers might fall into is to think that Web experience will prepare them for EDI-style business-to-business demands. "Web capabilities are far less demanding than enterprise-level B2B," notes Domke. The rock-solid security and reliability of standard EDI connections may prove a more elusive goal in the Web world than many people say.
XML's dark secret is that it's slower than EDI. The messages must be larger - as much as 10 times larger - requiring greater bandwidth and more cycles to move and process. For those merely seeking any-to-any connectivity, this isn't a major barrier. But when you start thinking about handling enterprise-level volumes of transactions, you clearly have to explore the ramifications of moving to XML.
Big Picture
It's important not to limit the scope of what you can accomplish with XML. For instance, Fastenal had a lengthy wish list for its XML connectivity needs, mostly in dealing with its customers. However, "another possible use of XML is for the procurement end of the business," says Falls. Users who can parlay their XML use in one area to solve another set of problems are clearly going to realize an otherwise unexpected return-on-investment windfall.
If you're even contemplating that you may someday want to add XML to existing EDI capabilities, don't wait. In many cases, you can gain a distinct competitive advantage by being first to offer XML connectivity. For example, Aircast was the first medical products provider to do an XML order over the Internet, and it hasn't looked back. Company executives estimate that they have a lead time of at least six months on competitors that may only now be implementing XML technology.
XML Futures