|
Those
who have already invested in EDI technology are not going to be in a hurry to go
back to the drawing board just to leverage the latest and greatest technology.
If it works, don't fix it. Those who have not yet invested in such an
infrastructure, though, are far more likely to turn to XML-based technologies
because the barriers to entry are so much lower.
XML-based integration technologies have some catching
up to do with EDI. However, as you yourself mention, there's no reason that the
experience with EDI can't be leveraged. EDI's substantial investments in
business processes and vertical industry vocabularies can be directly mapped
into the XML world; none of this is intrinsically tied to EDI technical
infrastructures. XML enables these same things to be accomplished with much
cheaper technologies and infrastructures. That means the barriers to entry are
much lower, and more organizations will be able to invest in such technologies
than was the case with EDI. However, one should not underestimate the amount of
time and effort (and therefore cost) that must still go into such a solution.
With XML, you get parsers that are free commodities, you get cheap (or free)
transformation tools with XSLT, you can use your web server and simple Java
programs or scripts for transport. Mapping your own business processes into
standardized models and vocabularies, and working out the details of
interactions with a partner, remains a large burden of work, however. XML can't
improve on that.
That's
why these sort of vertical, industry standard models and vocabularies are not
taking off with the momentum that XML itself is. With EDI techologies, building
any kind of integration interface was a great deal of work. With XML lowering
the technical barriers, organizations are finding it relatively easy to design
and implement a proprietary point-to-point interface with specific partners
without worrying about mapping all of the specifics into some generic
industry-wide model. That is often considerably cheaper and more expedient than
trying to adopt some standard vocabulary.
Even
before XML came along, few companies found they could standardize on a specific
EDI format. The more sophisticated EDI tools included transformation engines
designed to enable IT staff to build transformations mapping any format to
something they can work with. These were typically very expensive tools using
proprietary technologies for transformation, typically relying upon a scripting
language like Tcl or Scheme for customization. The XML technologies have made
this more standardized, much cheaper, and easier to implement. This has not only
made XML-based standards such as ebXML more attractive than EDI (as these newer
standards mature and fill in the gaps), but has made proprietary point-to-point
interfaces built with these open technologies so much easier to accomplish that
the whole notion of standard industry vocabularies and business process models
is now less compelling.
Thus,
the "XML Tower of Babel" that some lament, while others point out that it's the
transformations that count (as Claude Bullard mentioned in a recent post
regarding an article: http://lists.xml.org/archives/xml-dev/200104/msg00758.html).
The truth is that even with EDI technologies, having the transformation tools
was critical. It's just that with those tools, the transformation technology was
proprietary, very expensive, and cumbersome to work with, so the role of
standardized vocabularies was of comparatively greater value. If you could get
everyone to agree to a standard format, you could go with a cheaper toolkit that
only supported that format and alleviate a great deal of
cost.
|