Re: The initial ebXML business vocabulary - A call for a listofcandidates

[Abid Farooqui <farooqui@tampabay.rr.com>]

Dear John,
You are welcome to stay with the old and I'll take the new :).
I think you will find extending traditional EDI to work with smaller and
medium companies much harder than keeping the EDI investement where it works
(within VANs and within fortune 1000) and using new systems to work with
trading partners that are not going to be on EDI. I believe you will see
that in the next 4 to 5 years a lot of big EDI users are planning to
implement part or all their business automation over XML. I think I read
that in some report very recently. EDI will be around no doubt but so are
mainframes. They run and they are OK but they are not a solution for
everything and certainly not the solution for the internet.
Abid


----- Original Message -----
From: "John Evdemon" <jevdemon@vitria.com>
To: <ebxml-dev@lists.ebxml.org>
Sent: Thursday, June 21, 2001 7:54 PM
Subject: RE: The initial ebXML business vocabulary - A call for a list
ofcandidates


> On Abid Farooqui: Wednesday, June 20,  wrote:
> >
> > In my opinion these needs are tackled even today by systems like
> traditional
> > EDI but I think that traditional EDI's weakness is in its complexity,
lack
> > of similarity between document standards across verticals, its
non-tagged
> > nature and its price (both the purchase price and the maintenance price
> > because you literally need to employ and EDI person to keep the maps
> > up-to-date, keep the software up-to-date and deal with new partners that
> > come onboard etc.).
>
> Interesting statement - EDI is, indeed, implemented differently across
> verticals.  I believe you'll see the same thing happen with whatever
markup
> recommendation comes out of ebXML.
>
> > You need an EDI consultant basically and that is simply
> > not going to work in the 21st century.
>
> Somebody better tell this to the Global 1000 using EDI to conduct
e-business
> today.  Whatever happened to the concept of leveraging and extending
> existing investments in technology?    The best approach is usually to
> preserve what works and extend it to integrate with others.
>
> > Moving on to XML based standards ... XML is simple and it provides
> > flexibility. However, flexibility requires responsibility. What I mean
by
> > that is that if we over engineer the solution (business document
standards
> > etc.) even with XML then you end up just like with EDI after everything
is
> > said and done. Too complex, requires a consultant almost full-time and
so
> > on. That is no improvement, its just change of hands.
>
> This appears to be where we are headed.
>
> Many companies that have already adopted existing XML "standards" have had
> to replace or extend them because the "standards" didn't reflect their
> internal semantics.  A realistic example is a large EDI-enabled
corporation
> using XML to communicate with SMEs.  Most XML "standards" do not support
all
> of the fields in a typical EDI Purchase Order.  Further, most existing XML
> "standards" only support a few business transactions (e.g. Purchase Order,
> Invoice, Shipping Notice).  Other transactions (such as Freight Receipt
and
> Invoice or Materials Safety Data Sheet) are simply unavailable.
>
> Someone suggested that ebXML adopt XEDI to begin defining markup - XEDI
> supports every X12 and EDIFACT transaction from any version - including
the
> examples just mentioned.  See www.xedi.org for more info.
>
> > If we are really
> > serious about solving the business problem then the requirements are
> > simple,
> > make a solution that is not necessorily perfect but applies to 90% of
the
> > scenarios, make it simple to use, administor and add partners with and
> make
> > it work across industry verticals because business does not happen in a
> > vaccum. If we should ever learn something from recent history it should
be
> a
> > lesson from Microsoft. When they first came out with Windows, the
> operating
> > system was hardly even a contendor for even close to perfect (it isn't
now
> > even) but it was simple to use. It provided the end user an interface
that
> > is much more intuitive (visual, GUI) and it had software running on it
> that
> > solved most of the common problems. This provided a marked advantage
> > over
> > Unix like operating systems even though they were and perhaps even today
> > are
> > more robust than windows. Yet you can see that windows has taken off.
>
> Microsoft was building on top of an already established "standard" called
> DOS.  DOS wasn't pretty, but it worked (much like EDI itself).   Using
> XML-based representations of EDI transactions makes them easier for
non-EDI
> companies to create and consume.
>
> ebXML seems to be looking to adopt an XML standard that is already
prevalent
> in the business community.  I suggest that we should be looking at broader
> e-business standards - restricting ourselves to custom XML-based
initiatives
> will be much more difficult (since most XML-based initiatives are rather
> immature when compared to EDI).
>
> There are currently far more companies using EDI than XML (or, more
> correctly, XCBL) for e-business.  That said, ebXML should define its
markup
> using the dominant e-business standard (EDI) as a foundation.
>
> > In essense in this particular situation with ebxml, if we are to develop
a
> > solution, we need to develop it so that it solves most of the problems
not
> > all (the ROE ... Return Of Effort, in going from most incrementally to
all
> > is too large to justify even trying) and that it is asstandard across
> > verticals as possible to reduce complexity and is easy enough to use
that
> > any decent computer user can administor and maintain it.
>
> Agreed - again, EDI is already a standard across many different verticals.
> Defining markup for these verticals should leverage the metadata
associated
> with existing standards.  XEDI would seem to provide a great starting
point
> for markup development since it already represents over 3000 business
> transactions (all of which are derived from the X12 and EDIFACT metadata
> standards).
>
> > I still favor the concept of a universal PO, a universal FNACK and so
on.
>
> Its already available - its called an 850 Purchase Order and an 855
Purchase
> Order Acknowledgement (or, in the case of EDIFACT, Orders and OrdersP).
> Granted these are EDI standards, but a quick look at the associated
metadata
> helps you realize that these documents contain the fields that most
> companies use to conduct business.
>
> > Specific
> > extensions
> > to these universal document(s) can be applied by each industry group if
> they
> > are really really needed (I discourage these from the bottom of my
heart)
> > and as that happens software patches (perhaps even optional components)
> > can
> > be released by vendors to deal with these extensions. If things are kept
> > simple I don't think moving from today's systems to the new ones will be
> as
> > painful as you might think.
>
> Your description sounds suspiciously like EDI today.
>
> The real value that EDI can provide to ebXML is in the metadata - ignore
the
> cryptic syntax and associated VAN requirements.    Leverage EDI's
> comprehensive set of metadata to define the schemas for ebXML and avoid
> re-inventing the wheel.
>
> John Evdemon
> Regional CTO/Director of Engineering
> Vitria Technologies
> www.vitria.com
> www.xmls.com
>
> ------------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org