RE: VOTE REQUESTED - Suggest vote NO to Section 7 of the TechnicalArchitecture Specification

[Rebecca Reed <rreed@mercator.com>]

Hi Bob and David

I agree with Bob's comments but want to add a little bit more.  Tying into
accounting systems is tricky - even if we could agree on what business
components would make up the body of the messages that would retrieve from
and send to an accounting system then we would still have to come up with a
format that would be acceptable to the six or seven major accounting systems
that are out there for small businesses.  The second issue is how to
choreograph the scenarios (transactions, collaborations, signals, etc.) to
incorporate the additional steps required for interaction with the
accounting system at the appropriate point in the transaction.

To solve the second problem there is an organization that has choreographed
scenarios that can be integrated with accounting systems, the OAG -
furthermore OAG is making their scenarios compliant with BPSS. Additionally
RosettaNet PIPs could probably be used - PIPs are basically compliant with
ebXML BPSS. 

Now the tricky part is to take an OAG BOD (the message/document - Open
Applications Group Business Object Document) or a RosettaNet Message and
integrate it with the accounting systems that don't support OAG BODs or
RosettaNet messages (or EDI either) - probably none of them.   

Furthermore it isn't just a simple transformation problem - the document or
documents may need to be combined into (or separated into) the various
tables and elements of the data structures that support the various
accounting systems - so it isn't just a simple transformation problem but
rather an integration problem.  Mercator is one product (there may be
others) that supports a many-to-many integration and can easily accommodate
the integration and transformation requirements of these various accounting
systems - but it is a case-by-case scenario for each accounting application
that would have to be written for each of these systems.

WHY XML and ebXML??? - XML based messages so that you don't need an EDI
translator and ebXML so that you can safely send over the Internet using
ebXML transport and message handling services not an EDI VAN.  

Finally, both OAG and RosettaNet are subscription bodies with member fees
that are prohibitive to SMEs - a member of OAG would need to support the
small businesses for the use of the OAG scenarios and OAG BODs (or a member
of RosettaNet for the use of RosettaNet PIPs and messages as an
alternative).


Becky Reed
Senior Architect
Mercator Software

-----Original Message-----
From: Bob Haugen
To: 'David Lyon'; 'ebxml-core@lists.ebxml.org'
Sent: 4/27/01 7:58 AM
Subject: RE: VOTE REQUESTED - Suggest vote NO to Section 7 of the
TechnicalArchitecture Specification

David Lyon and all,

Integration with internal business systems has been another feature
that has been declared out-of-scope for ebXML from the beginning.

I agree with David that this is vitally important and like him wish it
had been in-scope, but ebXML had 18 months to get finished and
I understand why the scope decision was made.  There are a lot
of internal business systems out there, and a lot of ways to 
approach integration.  There have been proposals and ideas
put forward on the ebXML lists.  Personally I like some and
hate others.  It would have been yet another circular argument,
and required yet another work group, probably composed of
already-overworked people from this and other groups.

I don't think it does any good to become indignant at this late date
about scope decisions made a year and a half ago.

-Bob Haugen

-----Original Message-----
From:	David Lyon [SMTP:djlyon@one.net.au]
Sent:	Friday, April 27, 2001 1:57 AM
To:	ebxml-core@lists.ebxml.org
Subject:	VOTE REQUESTED - Suggest vote NO to Section 7 of the
TechnicalArchitecture Specification

All members,

I have been examining my copy of the technical Architecture
specification. I
would suggest that a vote of NO should apply to this section.

For the SME, this section is fundimentally flawed and will not work in
any
Small Business that I know of.

Line 434 says "The implementation phase deals specifically with the
procedures for creating an application of the ebXML infastructure"

There is extensive descriptions following of registries, scenarios,
runtime
phases etc... but there is nothing that I can find even showing how an
SME
connects it to their packaged accounting system.

This is in my opinion, an extremely major flaw!

I kindof understand the benefit of using a top down methodology, but in
this
case it has led to a very grave design flaw.

>From the ebXML homepage, I got the impression that what was being
designed
was sortof like a volkswagon. A car for the masses that businesses all
over
the world could use.

The problem is that the designers so far have been concentrating so much
on
a top down view of what they are designing, that they haven't bothered
to
have a look at the car from the side or underneeth.

What has therefore been designed, from an implemention perspective, is
much
like a car without wheels!

It just won't go!

Without connecting ebXML to the packaged accounting system so central to
the
movement of every SME, what hat has been described so far, won't
actually
work.

So it doesn't matter how much you rev the ebXML engine, it will never
translate into forward motion for business. It will just sit there
forever
looking like a car, sounding like a car but incapable of leaving the
driveway.

I know that it's just a minor detail - but connecting the ebXML to the
Accounting system is a fairly important one I would think.

The TA document described thus far, if implemented the way it is read,
would
not enable an SME to conduct business using ebXML. I just thought I'd
point
that out, just a comment from somebody looking from the side.

David Lyon




------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org