Let’s see, how often are you actually able to make the call to go one way or the other? Based on my experience both in our own shop and in dealing with literally hundreds of trading partners over the years, here are a few examples of when you’ll need to make a decision on taking the EDI or XML path.

• You’re a hub and just starting to deal with your supplier partners electronically. You must make a decision on which documents you’ll trade and which format you want them in.
• You’ve developed a new buy-side marketplace application and you need to determine how best to communicate with the suppliers that will be using it.
• You’re already EDI-enabled with your major direct suppliers, but you are implementing a new stream for indirect purchasing.
• You’re implementing support for a 3^rd-party process to enable your small and medium size partners to use a series of web-based screens to create electronic business transactions. You need to determine the format to use in dealing with the 3^rd party.
• You have the capability to support anything and you’re given the option by individual buy-side partners to select your preferred format.
• You have an existing EDI program that you want to covert to XML.

I’m sure there are other scenarios, but you get the point: there are few situations where you actually have the opportunity to choose between XML and EDI. If given the chance, though, how do you make a good informed decision?

EDI has some advantages over XML, and XML has some advantages over EDI. I won’t try to catalogue them all here- just Google ‘EDI vs XML’ and you can see a large number of articles and comparisons on the subject. Some points may be relevant to you, most probably aren’t. However, matching functionality with your requirements has to be your top consideration. There are certainly other variables to take into account, but selecting the right language for communicating based on your business and technical requirements is critical.

One of the major advantages touted for XML, circa 1999, was that it was actually ‘human readable’. We thought that was pretty funny, since any experienced EDI person can read an ANSI X.12 document almost as easily as they can read a newspaper. There have been many improvements in XML functionality, though, since then that are significant enough to consider. For example, one decision point for us with individual customers was related to how XML-based data could be stored and queried in database structures. That proved very useful in addressing some issues we had with partner data and drove us to increase our usage of XML for certain partners.

The point is that you must know what you want to do with the data and be familiar with how EDI and XML processes would be able to meet your needs before you select a direction. If you have an uncomplicated process of sending orders and invoices, both EDI and XML are perfectly useful for that purpose and you may then need to make your decision based on other criteria. But if you want to bring data in, massage it, compare it to values in tables or otherwise do a little more than just translating it, you might take a look at what XML-based processes would buy you.

Other factors to integrate into your decision making are certainly out there. Your system capabilities would always enter in the equation. Although most high-end translation and messaging platforms support both EDI and XML processing, you may have an older translator that has limited or no support for XML, or maybe you’ve written your own XML parser and you don’t even have an EDI translator. This shouldn’t be an issue in most shops, but there are a lot of legacy systems still being used.

Yet another consideration we’ve used at the partner level is the skill set of available mapping analysts. From a project scope and resource standpoint, it’s one thing to make a global decision that affects, for example, your entire customer base or supply chain. It’s another when faced with a choice from an individual partner who has both capabilities and is on a tight schedule. In the latter case, you’d want to see who is available to do the work, what they’re capable of doing, and choose accordingly. Our approach was that due to the diverse nature of our partner base, our analysts had to learn to map everything, so we attempted to take the skill set issue entirely out of the conversation. However, as is always the case, people are at different stages of familiarity and competence with their work and sometimes we needed to pick a direction based on that fact. If there was a deadline, we had one analyst available who was only capable of doing EDI mapping, the transaction chain was straightforward, and the customer was able to do both EDI and XML, then we used good old X.12 EDI.

Lastly, don’t forget to take your partners’ capabilities into account. As a manufacturer or retailer who is just getting into the electronic transaction game, you can certainly call the shots with regard to the specs you’ll send your suppliers. However, it’d be a good idea to survey them early in the process to understand what their ability is to support what you want to exchange with them. You’re certainly welcome to mandate whatever you feel is best for your business, but keep in mind that your deadlines may be at risk if you expect full compliance from a group that doesn’t have the capabilities already there.

One last scenario I wanted to mention would be converting an existing EDI program into an XML-based one. Since you should always be in a process of continually improving your programs, there may come a time where functionality that needs to be added may be supported better by XML transactions. As with any other large project, defining requirements and developing solutions are important steps. Don’t forget, though, to identify all of the costs and associated change management issues that could result from a major change. In this case, existing partners would need to be surveyed, results analyzed, a communication strategy to partners planned and executed, training for your people and others who support your processes may be required, and systems and programs may need updating. The benefits may far outweigh these costs, but don’t forget to include them in your analysis.

The one thing to remember about the EDI vs. XML discussion is that it’s not a zero-sum game. There’s room for growth for both technologies, and it’s up to you to learn enough about the relative advantages and disadvantages of the formats and processes to enable you to make a good decision when you have the rare opportunity to do so.

It’s always fun, every once in awhile, to re-surface the old XML vs. EDI discussion, and I suspect we’ll continue to explore the topic for years to come.