Subject: Re: VOTE REQUESTED - Suggest vote NO to Section 7 of theTechnicalArchitecture Specification
Andrzej, I agree with the general direction of your comments, but not even to address the question of 'how does an SME make it work' in an implementation section in a technical architecture document pushes down the value of the entire document to a piece of abstract writing. Non technical people, (the SME Manager) will probably need to be told explicitly within the document that he/she needs to request ebXML module or something from his Accounting system provider. Also, software providers need to be brought on board, but they need to know that their services will be required. They need to be prepared for clients should they call. It's a high level document remember, and the people reading the implementation section want quick answers, especially in small enterprises. The way it is at the moment leaves more questions in the mind of a non-technical reader than it does answers. Ok, there are no answers right now, but people need to be given a sense of where to next. These small changes, maybe one or two lines, will help the non-technical reader enormously. Take care David Lyon ----- Original Message ----- From: Andrzej Bialecki <abial@webgiro.com> To: David Lyon <djlyon@one.net.au> Cc: <ebxml-core@lists.ebxml.org> Sent: Friday, April 27, 2001 10:07 PM Subject: Re: VOTE REQUESTED - Suggest vote NO to Section 7 of the TechnicalArchitecture Specification > Hello, > > Let me add a few comments from my perspective as a system integrator for > SMEs: > > 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 > different. > > 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 > > // ---------------------------------------------------------------- > // Andrzej Bialecki <abial@webgiro.com>, Chief System Architect > // WebGiro AB, Sweden (http://www.webgiro.com) > // ---------------------------------------------------------------- > // <abial@freebsd.org> FreeBSD developer (http://www.freebsd.org) > >
Powered by
eList eXpress LLC