OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


Let me add a few comments from my perspective as a system integrator for

On Fri, 27 Apr 2001, David Lyon wrote:

> 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 more an issue of integration. As I understand it, the ebXML
project will/should result in a concrete standard for e-commerce. However,
the integration of this standard into already existing systems is not
within the scope of ebXML, I think.

> 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.

I don't think so, again - if you consider the scope of ebXML.
> >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.

> 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.

But it will (hopefully) enable them to integrate whatever they already
have with just one general e-commerce framework, instead of 10

Besides, for the off-the-shelf accounting packages this would be a task
for the software vendor, not for an SME. At least in the common case...
there are still many legacy systems out there which are not likely to be
replaced in the next couple of years, no matter what kinds of new
standards will show up.

The common case with which I have to deal in my job is that the accounting
package used by an SME doesn't follow any standards for the data exchange
(in some extreme cases there is no possibility to exchange data at
all...), and the business process definitions they follow are different.
Some of these packages can produce/consume CSV files. But so what? These
are just files with some digits in them, as long as you don't know the
business process that leads to their creation.

I believe firmly in the top-down approach. You have to understand
how the business process works for that particular company in order to
properly understand the semantics of each and every message, file and
piece of data exchanged.

Once you've understood this, the next step is the integration of this
model with some standard framework (let's say, ebXML). The existance of
such global framework then means for you that you have to implement just
one integration module instead of 10.

FYI: there is a project within CEN/ISSS Workshop for E-Commerce
to address exactly this problem of the integration between the different
ways of doing e-commerce. I attached the draft documentation. If you find
it interesting, please feel free to participate - the project is open.

So, back to the subject: I wouldn't support your suggestion, because IMHO
it comes from misunderstanding of the ebXML scope. However, I fully agree
that this issue has to be addressed in a systematic way by some standards
body. Maybe the project I mentioned would be a better forum for that kind
of work...


// ----------------------------------------------------------------
// Andrzej Bialecki <abial@webgiro.com>, Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// ----------------------------------------------------------------
// <abial@freebsd.org> FreeBSD developer (http://www.freebsd.org)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC