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

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

Well, I always have problems with people who are only pointing out problems
with no possible solutions and somehow on this thread I have turned into one
of them. So I will at least make an effort to point out a possible solution
or two.
Here goes
One obvious solution is of course to give verticals no leeway and define a
"universal PO" or a "universal Acknowledgement" and so on. Now realizing
that airline people and RosettaNet people can't even agree on what fields
and information should be in a Purchase Order (which is pathetic state of
affairs BTW) I will go on to my second possible solution.
Lets say airline industry as a vertical does come up with its "own PO" or
its "own acknowledgement" within ebXML framework. Lets say RosettaNet does
the same thing for technology vertical. All is fine and good except we are
starting to head in the direction of EDI again in some ways (not all but
some ways). Things are only going to get worse with time (I'll put that in
an envelope in writing to be opened at a future date). So what do we do now.
Now one possible idea is that every ebXML platform should be required to be
able to produce a version of the PO which is "Universal". Airline industry
can produce its "own PO" and that is fine but at the same time "a universal
PO" is also produced from the same information. This Universal PO is minimal
and sticks to only mandatory fields that should be in any PO. Without this
information PO simply will not be able to be processed successfully. Hence
the name Universal PO. Now when one vertical wants to do business with
another vertical, they really don't have to explain to each other what their
format of the PO is and what are they going to use among each other because
that will just produce a hotch potch. What they do is they send each other
the "universal" version and every ebXML platform if required to minimally
produce and accept this universal version of a PO, things go very smoothly
in a very simple uncomplicated way and people will not be pulling their hair
out.
Sincerely,
Abid

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


> 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
> >
> >
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org