Steve,
It's extremely refreshing to hear and read your comments below. I think
you've provided an in depth analysis of why neither EDI nor XML is the
silver bullet.
Futhermore, you also touched on the real issue: the competitive nature of
the global marketplace. My personal opinion is that companies today and in
the future will use "business processes" for competitive differentiation and
competitive advantage. Thus, rules for structuring data won't solve the
problem of interoperatability and neither will "standard formats" in
industries. These standard industry formats will be the lowest common
denominator - the vanilla approach. The world class companies will still get
highly integrated with their "selected" key trading partners using highly
specific and appropriate business processes.
I have to ask....if differentiated business processes do not offer a
competitive advantage, then why on earth are companies patenting business
methods?
So again....the real challenge is aligning the business meaning of named
(tagged!!) data between business partners....there ain't no automated tool
yet that will do this without a huge investment of human knowledge and human
capital.
Now...where can XML (and standardized DTD's, vocabularies, etc.) play a real
role and offer real benefit? Small business to small business. I would love
to be able to receive my attorney's invoice electronically directly into
Quicken from his Timeslips system...ditto for my AMX bill, etc. However, I
do not want to have to go to some web site....and with much time and effort
display my AMX statement and then download the data. I want these statements
all "pushed" to me via email. I want to be able to easily and simply collect
all of my financial data into one system (Quicken) regardless of whether
it's a multi-billion dollar company or another small business that I do
business with. I also want to be able to exchange draft legal documents with
my attorney or other companies even though we're both not using Micosoft
(gasp! are there still companies that have succumbed to MS yet?! Also, what
about presentation files (neither PowerPoint nor Freelance nor Corel
interoperate)...ditto for other office productivity tools.
This is where vanilla standard formats could offer benefit to both the big
companies and the little guys.
Rachel
>
>
> Hear, hear! very well said Rachel! You hit the nail on the
> head! Regardless of EDI or XML the content must still be
> programmed and integrated.
>
> The real problem with Richard's statement was not what he
> said about XSL. The real problem in the generality: "it is
> far easier using a common language XSL" is the "far easier"
> part of the phrase. It still must be programmed by a
> programming staff and that takes work whether in EDI or XML.
>
> Yes XML is about content, but the X in XML (extensibility)
> means you can have so many variations (just like EDI). Each
> variation must be programmed to integrate this into the
> ERP/CRM, etc. That takes resources. Resources leaves out
> the little players. This is the major problem in EDI also.
>
> This brings us to the REAL problem of EDI. It has nothing to
> do with the EDI format vs. XML format. It is the fact that
> there is such diversity in format definition among EDI
> Trading Partnerships. XML does nothing to change this fact.
> Where XML may be helpful (remains to be seen) is if some
> infrastructure can be built that will allow very small "rip &
> tear EDI" type partners to use their browser with no other
> cost involved. This could definitely be a benefit of XML
> over EDI. Speed of XML may also be a plus (again remains
> unproven to me).
>
> However for those partners automating the messages into/out
> of their ERP or other system the benefits/disadvantages of
> EDI vs. XML are far less clear and more nebulous.
> Generalities of "far easier" and "much better" are just so
> much hype. I take a "Show me" "Prove it" attitude.
>
> Lest someone think I am part of some EDI conspiracy (as was
> suggested recently in this thread), I have done EDI for 12
> years for about a dozen different clients, some large: Cisco,
> Sun, Qualcomm. I am now on a Java/XML project to replace
> some EDI. I very much dislike the problems of EDI and would
> love to scrap the whole thing with the next generation of XML
> or whatever that would solve the problems of EDI. Believe me
> I have no prejudice in favor of EDI nor desire to keep doing
> EDI !!! What I do wish to see however is REAL benefits, not
> just hype. I am not married to any technology and want what
> really works. I would love to see us evolve to the next
> generation of exchanging business transactions.
>
> Here is the REAL problem for both EDI & XML as I see it:
> There is much variation in Trading Partnerships requiring
> differing formats. Here at Cisco we had 17 variations on the
> X12 214 all programmed. We have trimmed this number down
> some but still have variations. If a big company like Cisco
> has these differences, imagine what it is like in the smaller
> trading partner!
>
> It works like this. General rule: Customers define the
> formats for vendors. Someone in the partnership must do
> this. It is often the customer. Sometimes it is the large
> company over the small company becoming the "hub". Yes, X12
> and EDIFACT have "standards" of transaction sets, but there
> are many optional element and ways of implementing them.
> There needs to be an agreement as to the meaning and use of
> some of these "optional" features that end up being required
> of the trading partnership.
>
> Example: Say a large company like Cisco tells all it's
> vendor trading partners "here is our published standard for
> the PO we will send you. To do EDI business with us you must
> follow this". Many vendors accept this and trading begins.
> Information flows are speeded-up and this is good.
>
> Now some of these smaller vendors also supply parts to HP and
> Sun. HP and Sun have their own PO formats and hand these out
> to their vendors. Now the little partner is burdened with
> maintaining three different formats. This takes programming
> resources not just to program but also to maintain. This is
> costly regardless of whether it is programmed in C, Java,
> COBOL, XSL, XSLT, whatever. It doesn't matter. It is not the
> format that is the problem. It is the differing types of
> information which companies decide to exchange. THAT is the
> problem. Get it?
>
> I hear too much argument of technologies, whereas the far
> bigger problem is the nature of the beast: TRADING
> PARTNERSHIP ARE DIFFERENT. XML does nothing to solve this!
>
> RosettaNet is working on this in defining set standards that
> all will use. They seem to be the farthest along in doing
> this in XML. Whether they can really pull this off or not
> remains to be seen, but I certainly applaud their efforts in
> this regard. Their intention is to have the formats so
> standard that adding new partnerships will be plug and play.
>
> Partly they do this by defining more mandandory fields and
> less optional. The problem with this is that in those
> mandandory fields that you have no reasonable data to supply,
> then zeros in numeric fields and "XXXXXX" or other hard coded
> values go into these fields. This renders them optional
> anyway in practice.
>
> REASON: I believe the reason for such diversity in
> partnership comes from doing business in a free market where
> there is much competition. To get the competitive advantage,
> addition data is required by this company but not by that company.
>
> I don't profess to know the answers here. I do know that to
> REALLY make XML the next generation over EDI we have to get a
> bit smarter in our arguments about how to really make
> business transactions become plug-n-play. I don't see this
> happening by arguing the benefits of XSLT. I am hopeful that
> XML/XSLT will help us. However, I think the REAL issue we
> need to argue is the way in which to re-engineer the type of
> information that businesses exchange. It is only through
> standardizing THAT, that we will leap into the next generation.
>
> Anyhow, what I have taken many paragraphs to say, was
> communicated very accurately and succinctly by Rachel in a
> single paragraph. I recommend you re-read what she said
> included below.
>
> Thanks for listening,
> Steve Bollinger
> Cisco Systems GPS-IT XML/EDI Logistics & Maintenance Project
>
>
> At 12:29 PM 7/3/00 -0500, you wrote:
> >There are even more who don't get the fact the XML/XSL or
> any of the other
> >components in a full suite of XML tools will NOT provide
> automatic alignment
> >of the business meaning of data....what I term semantic
> alignment. This task
> >is where the rubber hits the road, regardless of what set of
> rules (EDI,
> >XML, proprietary) one is using to structure data. This is
> also where human
> >effort must be applied. Thus, while XML has some usefulness
> neither it nor
> >EDI nor any other data structuring rules will align the
> business mean of
> >data between disparate applications even if both
> applications can parse an
> >XML data stream.
> >
> >Rachel
>
> Steve Bollinger 408-853-8478
> Cisco Systems GPS-IT XML/EDI Logistics & Maintenance Project
>
>
>
>
------ 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
