Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]

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

You have some good points however I have a few points of my own.
Remember in college when you would have what's called a departmental exam
lets say for Calculus or something. That meant that every single student in
that semester taking Calculus was going to take the same final to pass even
though they may be Math majors, engineering majors, Comp. Sci majors or
whatever. Department made a standard exam for all and did not give
Engineering professors choice of questions for their students or Math majors
harder questions and so on. You get the idea. That is what a standard exam
is.
Standard is not there to make every group happy but to make every group to
be able to inter-operate with each other and across many other verticals.
Standard organizations should not wimp out under pressure because GE
Exchange wants something in there or Airline industry just wants to keep
some things in there that just make their life easier. That is not a
standard, that is a copout. When you say I have this method in Java or this
function in C, then everyone knows what a method exactly is. there is no
ambiguity there. I guess I am thinking more like an engineer and less like a
businessman. Business people have a nagging habit of sticking their nose
where they only complicate things. Many times all arguments do is make a
body over engineer a solution where the return of over engineering and
flexibility is not really worth it. It gains you much less and it
complicates things. Keeping it simple always produces the best designs for
anything. Providing flexibility to the vertical markets gives them the
opportunity to make things so complicated that when they want to do business
across multiple verticals they just get annoyed and their heads start
shrinking.
If we don't do this with ebXML we will still have this problem. There is a
common goal here and that is inter-operability and automation and
efficiency. All of these are best served with more stringent standards not
with flexibility. What flexibility provides you can be achieved in other
ways it does not need to belong to the core business automation. This is
just my opinion but of course I will also follow what the standard says
because when it is out, it is meant to be followed no matter what it is. Now
if airline people + the RosettaNet people could think like me :).
Abid Farooqui

----- Original Message -----
From: "Tim McGrath" <tmcgrath@tedis.com.au>
To: "Abid Farooqui" <farooqui@tampabay.rr.com>
Cc: <ebxml-dev@lists.ebxml.org>
Sent: Monday, June 04, 2001 8:30 PM
Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]


> Maybe another way to consider this situation is that, every vertical,
region,
> business-type, business size, at any moment in time, each operate across
various
> mixes of these 'contexts'.   businesses are dynamic and fluid structures.
this
> i why current EDI standards have these increasing numbers of message
> implementation guidelines, and all the inherent non-standard features,you
> describe.  I too, once thought that if my trading partner supported X12
855 then
> I can just send my version of an 855 to him.  Makes you wonder what a
standard
> is, doesn't it?
>
> There is not, and i suspect never will be, the universal Invoice or
Purchase
> Order - in whatever syntax you wish to name.  This is not simply because
the
> Airline EDI standards people think and operate differently from everyone
else.
> In some contexts, they really are different.  Traditionally, EDI standards
> bodies have proudly stood by their vertical 'business focus' groups.
There has
> been less attention to an 'information systems focus' - that is, the
analysis of
> the common data models and processes.  I believe, this is one of the major
> achievements of ebXML - it gave voice to those who have been struggling
with
> this problem.
>
> For example, in such a situation, rather than establish and enforce a
fixed
> structure, an alternative strategy is to define the framework for defining
data
> to be exchanged.  If this is consistent and unambiguous, then this
information
> can drive the automated exchnage of whatever data the parties involved
require.
> Remember, the names "Purchase Order", "Invoice" are arbitrary titles to
bunches
> of data that support business processes.
>
> As you say, ebXML has not achieved this state yet, but at least it isn't
> avoiding the real problem.
>
> What is more, it is an open forum that has enticed people such as yourself
, to
> comment and participate in developing this new paradigm.
>
>
> Abid Farooqui wrote:
>
> > Thanks for the answers Chris. I am not directly into the EDI world much,
I
> > am a Java developer but I do work with a lot of people using EDI tools
like
> > DI for doing Maps and so on.
> > One problem that nagged me about EDIFACT was that even though it is a
> > standard what was quite annoying and what made it much more complex than
it
> > ever needed to be is the fact that each of the vertical markets can
> > basically come up with their own version of an 855 and so on. So many
fields
> > are optional making it even more complex. I am not sure, may be it is my
> > strict upbringing or something (hope my mom never reads this:)) but
giving
> > so much leeway really gets away from the point of being a standard. With
> > such complexity you give rise to complex programming tasks making EDI or
> > ebXML platforms rise way higher in price than they otherwise would be
and
> > make so many people so specialized in one area that their whole career
is
> > based on it. For instance there are EDI people who are just experts in
the
> > Airline industry and so on.
> > If the standard was more like a standard (more stringent) then there
could
> > be say just one and only one version of a PO and it would be easy to
parse
> > it, reducing cost and complexity a hundread fold. It seems like ebXML
has
> > not achieved that state yet either. May be we are just making jobs and
> > careers for ourselves in the industry and not really solving business
> > problems. In my opinion there is no reason that if enough thought is put
> > into a standard that anything should be left up to the vertical markets
to
> > decide.
> > Sincerely,
> > Abid Farooqui
> >
> > ----- Original Message -----
> > From: "christopher ferris" <chris.ferris@east.sun.com>
> > To: "Abid Farooqui" <farooqui@tampabay.rr.com>
> > Cc: <ebxml-dev@lists.ebxml.org>
> > Sent: Monday, June 04, 2001 4:46 PM
> > Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]
> >
> > > Abid,
> > >
> > > Please see below.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > Abid Farooqui wrote:
> > > >
> > > > Dear James,
> > > > So let me understand this correctly.
> > > > As far as I can make out from your kind answers below what seems to
be
> > the case is
> > > > that :
> > > > 1) ebXML can be used as a messaging mechanism to deliver traditional
EDI
> > to
> > > > traditional EDI engines
> > >
> > > Yes, it can.
> > >
> > > > 2) Now you mention 2 problems:
> > > > "First, it must correctly interpret the element that identifies the
> > schema
> > > > (such as X12) in which the payload documents are encoded, so it can
send
> > > > that data stream to something that can interpret it.  (Like your EDI
> > engine.)"
> > > > My question to that is : Doesn't ebXML messaging has in it some
> > indicator that
> > > > describes what kind of data it is and if not ... why?
> > >
> > > Yes, it does. This is the purpose of the Manifest. Of course, there
are
> > other
> > > elements of the ebXML SOAP extension headers that the message service
can
> > > use for purposes of internal dispatching of messages to the
appropriate
> > handler
> > > application. These include the CPAId, Service and Action elements. The
> > CPAId
> > > can be used to identify a CPA (whether a true CPA document or an
implied
> > or
> > > logical "agreement" between the parties that specifies what messages
will
> > > be exchanged, etc.). The Service and Action elements can be used for
> > internal
> > > dispatching as well. Again, ebXML MSH places no specific constraints
on
> > > how these elements are (or are not) used in any given implementation.
> > >
> > > >
> > > > "Second, it must correctly apply the ebXML business signals so that
it
> > can
> > > > read and process the simple business-rule context of that payload --
Is
> > > > this a response?  A request?  To what?  Is it logically dependent on
or
> > > > conditioned on another message already received, or to come?  Is
this
> > > > binding?  Does it conform to whatever rules for acknowledgement,
> > encryption
> > > > or signature are invoked?"
> > >
> > > The business signals referred to here are those that are defined in
terms
> > > of an ebXML business process. The business signals are low-level
messages
> > > that parties exchange to signify things such as:
> > > - I've received your message
> > > - I've pre-processed your message and it passed the preliminary
> > > edits
> > > - ...
> > >
> > > The ebXML Business Process Specification Schema specification
describes
> > these
> > > in more detail. Business signals may, or may not be necessary. This is
> > clearly
> > > the realm of the "owner" of a business process to determine.
Typically,
> > this
> > > would be the purview of a vertical standards body such as OTA,
RosettaNet,
> > OAG, etc
> > > or a horizontal standards body such as X12 or EDIFACT, etc.
> > >
> > > > Isn't this what an ebXML server would do anyway? I think these are
> > basically
> > > > requirements for an ebXML platform, regardless of EDI payload or any
> > other payload.
> > > > Am I correct?
> > >
> > > Basically, yes.
> > >
> > > >
> > > > Thanks
> > > > Sincerely,
> > > > Abid Farooqui
> > > >
> > > > James Bryce Clark wrote:
> > > >
> > > > > At 11:17 AM 6/4/01, you wrote:
> > > > >
> > > > > >Date: Mon, 04 Jun 2001 14:16:14 -0400
> > > > > >From: Abid Farooqui <farooqui@tampabay.rr.com>
> > > > > >Subject: Re: Example Scenarios Used Within the Aerospace Industry
> > > > > >
> > > > > >Isn't it true that ebXML messaging can be used to deliver
traditional
> > EDI
> > > > > >payloads as well.
> > > > >
> > > > > Yes indeed.
> > > > >
> > > > > >Probably there has to be ways of delivering that payload to
> > > > > >the EDI mapping engine like DI or GenTran but ebXML messaging
could
> > be used as
> > > > > >the transport correct?
> > > > >
> > > > > Once past transport, the receiver's business service interface
has,
> > broadly
> > > > > speaking, two problems.
> > > > >
> > > > > First, it must correctly interpret the element that identifies the
> > schema
> > > > > (such as X12) in which the payload documents are encoded, so it
can
> > send
> > > > > that data stream to something that can interpret it.  (Like your
EDI
> > engine.)
> > > > >
> > > > > Second, it must correctly apply the ebXML business signals so that
it
> > can
> > > > > read and process the simple business-rule context of that
payload --
> > Is
> > > > > this a response?  A request?  To what?  Is it logically dependent
on
> > or
> > > > > conditioned on another message already received, or to come?  Is
this
> > > > > binding?  Does it conform to whatever rules for acknowledgement,
> > encryption
> > > > > or signature are invoked?
> > > > >
> > > > > >I am new to ebXML so feel free to correct me.
> > > > > >I believe that changes from large EDI users to adapt ebXML will
be
> > slow
> > > > > >but they
> > > > > >have to be made because there is a very good business case to do
> > that.
> > > > >
> > > > > The ebXML business process group spent a lot of time working
closely
> > with
> > > > > the X12, EDIFACT and RosettaNet communities precisely to preserve
the
> > > > > upgrade path you describe.
> > > > >
> > > > > Best regards
> > > > >
> > > > > James Bryce Clark
> > > > > McLure Moynihan Inc.
> > > > > 818 597 9475     jamie.clark@mmiec.com
>
> --
> regards
> tim mcgrath
> TEDIS   fremantle  western australia 6160
> phone: +618 93352228  fax: +618 93352142
>
>