First of all, let's get clear on something....EDI is electronic data
interchange. XML is electronic data interchange, thus XML is EDI. If what
you mean by EDI, Brian, is the use of the X12 and/or UN/EDIFACT syntax for
structuring data, then yes, of course, ultimately these standards will give
way to new and emerging technologies. Furthermore, major efforts are already
in process (and have been for years) in the major standards development
organizations to develop the standards tools for the future using, not only
XML, but OOT, UML, business process analysis, and so on and lay the
groundwork for migration and transition. So, it never was and never will be
an either-or issue. It will also be the strategic question of "What are the
strategies and array of technology tools and other capabilities that will
help my company achieve its business goals?" Thus, companies who would
succeed today and survive and succeed in the future must of necessary have a
blended strategy incorporating many different tools.
Now, to address your second statement...that startup companies should choose
XML over the current X12/EDIFACT standards. First of all, why just limit
your focus to startup companies? With whom do startup companies do business?
With companies already in existence, of course! Or, do they only do business
with each other and only other startup companies?
In order for any company to exchange information electronically with another
they have to have a willing partner, and reach agreeement on the method,
mode, what data, what actions, semantic alignment of the business
information, etc., etc. The use of XML is not that widely deployed in all of
the various applications systems that companies use today or could use in
the future. A tool is of no use if you are the only one with it....for
example, if you had the only phone in town, with whom would you speak? So,
it will take time for XML to become ubiquitous. In order for this to occur
XML has to mature into an industrial strength prime-time ready tool set.
Work is already underway to bring this about. Once those capabilities are
available then the solution providers (read application software developers)
will have to decide whether or not to incorporate this technology into their
commercially available, off-the-shelf product offerings. It will only be by
doing this that even the smallest of companies will be able to take
advantage of these new technologies and use them to do business not only
with their big-guy business partners, but with their small-guy business
partners as well. Then, the potential customers will have to make the
business decision to buy/license or whatever the new products and replace
their existing applications. These decisions will be made, hopefully, in the
cold hard light of asking and answering what's the business benefit to do
so? What's the cost to do it? How long will it take for the business benefit
to be realized? In other words, it is a dollars and cents decision for most
companies.
In the meantime, thousands of companies will continue to use and begin to
use software tools that support today's standards for electronic data
interchange...if it makes good business sense. If it doesn't, they won't.
Too many companies just blindly rush out and buy technology without having
any clear idea of how that technology is going to contribute to the
achievement of the fundamental business goals: increasing stakeholder value,
increasing revenue, increasing profit, and increaing market share. If the
use of technology tools is not linked to the enablement or achievement of
critical business goals, it's just another toy that gathers dust in the toy
box.
Rachel
|
|
|
|While I must agree that XML will be replaced (history of technolgy in
|general proves this theory), I wouldn't bet on it being
|anytime soon. As a
|general note, XML is (in my opinion) not going to replace EDI.
| However, it
|will replace EDI as the chosen format for startup companies.
|Unless someone
|can give vaild reason for why a company should choose EDI over
|XML (or any
|other format for that matter). Smart money says: go flexible, go XML.
|
|Brian
|
|-----Original Message-----
|From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
|Sent: Saturday, July 29, 2000 5:32 PM
|To: 'Kurt Cagle'; XML EDI Listserv (E-mail)
|Subject: RE: Is the Internet/XML Going to Kill EDI?
|
|
|Kurt,
|
|First of all, I don't know why you sent your comments just to
|me. However,
|I do think that this discussion deserves to be on the list, so I'm
|going to post my response back to the XML/EDI list as well.
|
|Just a couple of comments to yours below. I've inserted them at the
|appropriate spot.
|
|Rachel
|
||
||Rachel,
||
||First a disclaimer -- I'm not an EDI person, although I have
||worked with X12
||in a number of projects, but I have reached a point where I
||think I'm pretty
||much an expert on XML. While I do agree with you on a number
||of the points
||you bring up, I'd argue that your point about where we are with XML is
||pre-EDI. Consider this:
|
|RF: I didn't say that XML is pre-EDI....I just said that XML and the
|full suite of XML-related "standards" needs to mature in order
|to provide
|much of today's capabilities that companies currently have with the
|traditional
|X12 or UN/EDIFACT standards. When these standards were first being
|created they didn't explode out of the box as they are today. They were
|developed and modified by many, many business domain and subject matter
|experts to meet the business needs of the day. And, the beat
|goes on with
|many
|of these same people and others shaping and molding XML into
|what it must
|be to meet the needs of business (commerce).
|
|What I did say is that EDI is the electronic exchange of
|data....that we've
|been
|doing that for decades, even before the advent of the X12 or UN/EDIFACT
|standards....
|and that we'll being doing electronic data exchange long after X12,
|UN/EDIFACT and, yes,
|XML, have faded into the dim history of memory. It's just a
|new kid on the
|block that needs to continuing growing and reaching maturity.
|It's not the
|end-all, be-all of businesses exchanging information. It's
|just today's and
|tomorrow's (for a while) tool. It too will be replaced and/or
|subsumed by
|something else...bet on it!
|
|
||1) EDI had no notion of the concept of an encapsulatable
|transformation
||mechanism. XML has XSLT. While I think that the language
||itself still has
||some room for maturity, the ability to readily transform
||elements means that
||far from having immature dictionaries of tags, XML has largely
||transcended
||the need to have such a common dictionary in the first place.
||Thus, in many
||respects this is a HUGE advance.
|
|RF: Of course EDI didn't include a concept of "an encapsulatable
|transformation
|mechanism" since that concept didn't exist when the early X12 standards
|(let's not confuse EDI with the X12 and/or UN/EDIFACT standards) were
|being created since the problem being addressed was the
|application-to-application exchange of data. The basic concept
|of the X12
|standards
|is that since the X12 standard represents the common
|language transformation is done only once by the sender (into the X12
|standard)
|and only once by the receiver (from X12 to internal format. XSLT only
|provides a
|mechanism for transforming one XML-formatted document
|structure into another
|XML-formatted document structure.
|
|
||2) Up until recently EDI developers were only found in
|relatively large
||corporations because of the cost of access, and the tools for
||developing
||such applications were typically highly specialized and
||proprietary. XML is
||neither, meaning that the cost of entry of getting into B2B
|has dropped
||dramatically, the number of programmers specialized in those
||areas has risen
||accordingly, and there is far more synergy and evolution of
||B2B application
||theory as a consequence. When you have ten times the number of
||developers,
||the opportunities for developing better B2B solutions increase
||exponentially. Thus, I see the XML space as being far more
||evolved, dynamic,
||and flexible than EDI/X12 ever would be.
|
|RF: I don't disagree with the above. I never said that XML was
|bad and X12
|was good.
|It's important to remember the context within which X12 was
|developed and
|what
|was available at that time (30 years ago). XML will most
|likely become much
|more
|predominate due to the greater accessibility of
|lost-cost/no-cost tools.
|However, don't
|confuse the fact that X12 developers were most often located
|within large
|companies
|with a lack of adoption. I developed PC-based systems that
|were provided to
|over 5,000
|customers in the late 1980's that used the X12 standards for
|purchasing, all
|totally
|transparent to the end-user (customer) who didn't even know
|that X12 was the
|underlying data structuring rules employed. Furthermore, don't
|credit XML
|solely with
|your contention that "there is far more synergy and evolution of B2B
|application
|theory." This is due to a convergency of many technologies and
|capabilities,
|not the
|lease of which is the extention of the Internet to the masses with the
|creation of Mosaic,
|the World Wide Web, AND affordable and accessible telecommunications
|services in
|the U.S. XML is a johnny-come-lately to the tool-kit of electronic
|information exchange
|and complex computer networks. It's just the new kid on the
|block and he'll
|have to
|grow up just like every other technology.
|
|
||
||3) The VANs are faced with a fundamental problem --
||competition. With XML,
||the ability to create a competitive solution to the problem of
||EDI becomes
||more accessible to programmers, which means that the
||stranglehold that the
||VANs (such as EDS or related companies) have had has largely
||slipped away.
||Yes, the VANs provide value-added services, but so can any number of
||smaller, more nimble companies that have committed whole
||heartedly to the
||XML paradigm. As we move increasingly into a net services
||model, the only
||real advantage that the VANs have are longevity and relatively
||deep pockets
||-- both significant, but neither a guarantee in the more
||highly volatile
||markets of e-commerce.
|
|RF: Don't confuse the Value Added Network (VAN) model with XML. XML
|is ONLY a set of rules for tagging and structuring a document.
|It doesn't
|at all deal with the transport of that document once it's created. I
|developed systems and established X12 interfaces with thousands of
|trading partner WITHOUT using VANs. VANs just simplied connectivity
|for many large hub companies trying to connect with thousands of spoke
|trading partners. Today the old EDI VAN model is morphing into the
|Internet hub model, or marketplace, or exchange, or portal. VANs solved
|a need at the time. The marketplace and their customers will tell them
|when they need to transform themselves into something else.
|
|
||4) EDI is exclusively a commerce transaction format. However,
||one thing that
||people are beginning to recognize is that transactions involve
||more than
||just the exchance of commerce information. A medical XML
||infrastructure
||could handle everything from the storage of client care information to
||scheduling of procedures to data mining of traits for expert
|systems to
||billing, ordering and maintaining inventories of equipment and
||supplies.
||Thus its a more systemic solution, one that could in fact handle the
||complexities being applied to it. Moreover, the development of
||XML standards
||within the medical industry need to be developed by domain
||experts in the
||field, not by accountants working within the X12 paradigm.
||
|
|RF: X12 is NOT exclusively for commercial (whatever you mean
|by that) transaction format. There are X12 transactions that convey
|all kinds of data that could be construed as non-commercial, such as
|a First Report of Injury or Illness for workman's compensation
|reporting, Organizational Relationships which is used to exchange
|the structure, membership and relationship of organizations and/or
|databases, such as a large hotel holding corporation or a purchasing
|cooperative, or a database of entity identifiers. Also, lab
|test results
|reporting, EPA reporting, and so on. These are just a few. As for your
|assertion that XML will provide for the billing, ordering and
|maintaining
|of equipment inventories and supplies or other clinical medical data,
|you're off the mark. What will provide for those functions will be
|the intelligent, automated business systems that apply and enforce
|chosen business rules. Now, these system could and perhaps will in
|the future, label the data used by these systems following the XML
|rules, but systems like this are not dependent on XML to accomplish
|their business mission. Lastly, XML-based vocabularies do need to be
|developed and maintained by the business domain experts....but this
|is already taking place on a fairly large scale, with RosettaNet, HL7
|(for health care data), ACORD for insurance transactions, OTA for
|travel and leisure transactions. I don't know what you mean by
|"accountants working within the X12 paradigm." Have you
|participated in the X12 Committee work? If you have, you would
|know that the majority of participants are the business domain and
|subject matter experts from there respective organizations. One would
|only see the "accountants" for the work needed for some of the
|financial transactions.
|
|
||The reason that I feel that these points need to be raised is
||that the XML
||market IS a little less established than the EDI/VAN
||infrastructure, and
||that self-same infrastructure has made a concerted effort to
||insure that
||people don't understand where the benefits of XML solutions do
||arise in the
||EDI sphere. The principle benefit of XML is that it is a democratic
||solution -- you don't need a significant investment for access
||of data, you
||don't need specialized tools for working with the data, you don't need
||specialized networks for transporting the data. Up until now,
||the VANs have
||controlled all three, but with the rise of open data standards that
||advantage is now largely lost.
|
|RF: You're incorrect on all of your assertions above. The VANs have
|not tried to keep people in the dark....they have been moving to
|support XML for quite some time. However, remember, they have
|a huge customer base that STILL USES THE X12 STANDARDS which
|they still continue to support. Furthermore, the VANs have not
|controlled the EDI/X12 software....sure, VANs provided software
|solutions, but so do literally hundreds of other small to medium size
|companies that do not provide VAN services. Where do you think
|Mercator, NEON-PaperFree, DNS Worldwide, etc. to name a few,
|came from? There never were and are not now VANs. Furthermore,
|each of these, plus dozen's of other also support XML.
|
|Also, you DO need specialized tools for dealing with XML-based
|documents. What do you think the XML parsers are? Or the the
|whole array of tools that can handle not only a well-formed
|XML document
|but a valid document, plus use schemas, XSL, XSLT's etc. None of
|this is done at the operating system level, which by the way, is just
|another specialized piece of software, albeit an essential one.
|
|When forced to compete
||essentially at the
||same level as the new players in the industry, they end up
||doing so with no
||significant advantages of the benefits, and not surprisingly
|are waging
||campaigns of disinformation about not just a change in standards but a
||paradigm shift in the ways that those standards are being applied.
|
|RF: I don't know what "campaigns of disinformation" are being waged.
|I haven't seen them. But, I do see all of the VANs that provided
|traditional EDI/X12 services actively transforming themselves, offering
|new types of services, and even participating (gasp!) with many of us
|in the XML space to create the standard framework for XML so that
|we will have interoperability....not the tower of babel and chaos that
|exists today between all of the various domain-specific XML
|vocabularies
|and/or company-specific vocabularies.
|
||I will doubtless generate heat with this message, but I get
|tired about
||hearing how the VANs are still the best way of doing B2B, that the XML
||standard is badly fragmented, and that we're worse off now
|then before.
|
|RF: I don't know where you hear that VANs are still the best way for
|business-to-business exchange of information. What you've been hearing,
|at least on the XML/EDI and EDI-L lists, is that VANs are part of the
|picture, offer services that may or may not be important to a company,
|and that companies must determine for themselves what their
|requirements
|are for the exchange of electronic information with their
|business partners
|and to how best satisfy those requirements.
|
|I have a bit tired of the VAN bashing....EDI was conducted for
|many years
|without VANs. They came into existence to satisfy a customer/market
|need and will go away when that need no longer exists. Rather than
|getting so hung up about VANs why not start dealing with how you're
|going to automatically process an XML-based purchase order when your
|customer uses a tag like <PO#> and you use a tag like
|<purchase.order.number>
|and they use a tag like <Ship Date> and you use one like
|<Despatch Date>.
|Just because these are human readable doesn't make them semantically
|equivalent, and this is where the rubber hits the road.
|
|Furthermore, I wouldn't be so eager to bash commerce. Afterall, it is
|commerce (the buying and selling of stuff) that makes the
|world go around...
|this has been so since the dawn of human beings and continues to be so.
|Folks
|did, do, and will continue to need to get stuff and in order
|to get stuff
|they'll
|have to exchange something for it. This is called commerce! It
|ain't so bad!
|
|Rachel
|
||We're adapting to a new technology, one that will have an
||impact well beyond
||the domain of commerce, and as with any paradigm shift people
|are still
||learning how best to work with the new concepts. Many of the
||domain experts
||in EDI have made the shift to XML already, because they HAVE seen the
||advantages of the paradigm .... significantly, much of the
||shift of XML's
||focus from document to data has occured largely because of these
||individuals, who realized that the EDI standards simply had
||too high a price
||tag. Additionally, those same individuals understand that
||domain knowledge
||in the field of electronic commerce is more than simply
||knowing how to work
||with a specific program or set of field tags, and it is this
||expertise that
||gives them value in the new market. Does that mean that the
||EDI companies
||can survive with the model that they've been using for twenty
|years? Of
||course not.
||
||Okay, just my two cents worth.
||
||-- Kurt Cagle
|
|
|
|------ XML/edi Group Discussion List ------
|Homepage = http://www.XMLedi-Group.org
|
|Unsubscribe = send email to: [EMAIL PROTECTED]
|Leave the subject and body of the message blank
|
|Questions/requests: [EMAIL PROTECTED]
|
|To receive only one message per day (digest format)
|send the following message to [EMAIL PROTECTED],
|(leave the subject line blank)
|
|digest xmledi-group your-email-address
|
|To join the XML/edi Group complete the form located at:
|http://www.xmledi-group.org/xmledigroup/mail1.htm
|
|
|
|
|------ XML/edi Group Discussion List ------
|Homepage = http://www.XMLedi-Group.org
|
|Unsubscribe = send email to: [EMAIL PROTECTED]
|Leave the subject and body of the message blank
|
|Questions/requests: [EMAIL PROTECTED]
|
|To receive only one message per day (digest format)
|send the following message to [EMAIL PROTECTED],
|(leave the subject line blank)
|
|digest xmledi-group your-email-address
|
|To join the XML/edi Group complete the form located at:
|http://www.xmledi-group.org/xmledigroup/mail1.htm
|
|
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
