[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Software abstraction layer to ebXML core component objects
> Big hint: Those who tie themselves to native implementation > of standard representation models of the information may > find it difficult to adjust to changes in the models as they > version over time. I'm on your side, but that does set off alarms. There has been a lot of needless version churn in small business applications, as a way to increase vendor revenue. I believe small business and individuals are primarily interested in making our payables and receivables and cash and inventory movements equal to our customers and suppliers and bank. In other words, once they have "done a deal" they want the bookkeeping to be automatic. SMEs are held back by lack of privacy, security, authentication, lack of global party codes and product codes, etc. While waiting for the real causes of the problem to be fixed, I hope the doctors don't kill the patient with increasingly exotic experimental drugs. Faithfully Todd > -----Original Message----- > From: Hayes, Brian [mailto:Brian.Hayes@Commerceone.com] > Sent: Monday, May 14, 2001 7:19 AM > To: tboyle@rosehill.net; ebXML-BP (E-mail); ebXML-Core (E-mail) > Subject: Re: Software abstraction layer to ebXML core component objects > > > > Todd wrote: > - Couldn't the software developer implement some kind of abstraction > - layer, that could point to *any* core component? This would > - let their > - software survive the changes in Core components. > [Brian] There is a great deal to be learned from EDI and > back-office integrations on how to handle this. Big hint: > documents are yet just another presentation of information just > as a UI is a presentation of information. Those who tie > themselves to native implementation of standard representation > models of the information may find it difficult to adjust to > changes in the models as they version over time. > > Todd wrote: > - That is as far as I go, with the business requirements. I'm > - waiting for ebXML to cough up some more core components and willing to > - lay odds that > - the SMEs will just pick them up and start using them natively. > [Brian] > 1. I always thought the Core Component's charter to be that of > providing a methodology for discovering core components NOT > delivering core compenents. This is a huge distinction. > 2. I'm not sure what you mean by "just pick them up and start > using the natively." As I mentioned above, "there is a great > deal to be learned from EDI and back-office integrations." > > Todd wrote: > - Meanwhile--small developers I suppose, should write an > - abstraction layer > - to interoperate with these diverse, new, ever-changing core component > - objects, to play in this fascinating new game. > It's good to state this and restate this (and is in line with my > "big hint" above). Of course, what we will see in many cases is > just the opposite of this as time-to-delivery schedules and poor > design result in implementations with a high meintenace cost. > > /Brian >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC