Subject: RE: Comments on TA version 0.9
sorry Mike, but I don't plan to respond to this today. I was informed that in the TA/QRT meeting there was no consensus, except that continuing this debate would risk delivering the "basic" infrastructure of ebXML. This will have to be continued in phase 2. The requirements to pick "a single modeling technique and methodology, and adopting existing specifications" will not be met for this phase. Scott -----Original Message----- From: Mike Rawlins To: 'ebxml-architecture@lists.ebxml.org ' Sent: 11/6/00 9:39 AM Subject: Re: Comments on TA version 0.9 Comments and questions below: "Nieman, Scott" wrote: > I find it terrifying to hear that some people do not know the real > problems....especially at this stage of this initiative. > > Have you ever heard of a "plug-in" or maybe an "adapter"? Have you ever > been prompted by your browser that you need to install one of these "things" > to view the most updated version of Shockwave? > > PERHAPS this is the architecture? > > Why? because of the REAL problems!! > > 1) the REAL SME does not give a hoot about technology and it should be > ABSOLUTELY transparent to them. Looking at XML versus looking at CODE is > still LOOKING at technology...make it invisible to them or we fail. > 2) there WILL BE YAP (yet another protocol) in a few more years...5, 10, > 15...whatever...it WILL happen. (or should I say YAHP (yet another "hype" > protocol...EDI -->ASN.1--->XML????) I may be mistaken, but I think most of us feel that this is a fairly obvious, non-controversersial point. > > > SOOOOOO....the solution scenario...for those who don't get it... > > trading partner A uses QuickBooks and wants to buy something...looks into a > registry and finds trading partner B has a suitable product. trading > partner A and trading partner B have the ebXML messaging service installed. > however, based on trading partner A's profile and trading partner B's > profile, trading partner A is prompted with a dialog box(message) because > the tpp / tpa process states that for the specific collaborative business > process trading partner A needs to install an adapter to talk to trading > partner B. download the adapter from a ebxml reg-rep with software > components in it and wa-la! trading partner b gets a PO. Scott, thanks for spelling out how you think this is going to work. Now my questions: Even if we can normalize the data requirements through better modeling than we have with traditional EDI, there may still be *many* variations due to real differences in business processes. Do you agree with this assessment? What is your order of magnitude estimate of the number of different business process variations, and hence, the number of different plug-ins that might be needed for QuickBooks? Who is going to provide these adapters that A needs to make QuickBooks talk to B? Do you expect Intuit to supply them? Or, do you expect someone else to? -- Michael C. Rawlins, Rawlins EC Consulting http://www.metronet.com/~rawlins/
Powered by
eList eXpress LLC