Re: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

[David Lyon <david.lyon@globaltradedesk.com>]

Mike,

I stand by my words.

"The fact is that nobody has (yet) released a reliable business messaging
product that is suitable for Small Business use. That is the main problem."

There are reliable messaging systems for big business, but not too many for
small business.

> I doubt we will ever have many ebxml accounting appliances.
> This will not happen because accounting is too complex for the
> PDA equivalents we will soon have. It will not happen because
> accounting will soon be too simple for them.

We are about to start selling an ebXML accounting appliance. It is being
released next month. It's a CDR business card that can send orders, receive
invoices and make credit card payments.

> End user accounting only got simple enough for non-accountants
> when Intuit began to revolutionize the way individuals and small
> businesses manage our finances. It involved masking most of the
> accounting technical details behind easily understood business
> forms and menus.

That's right.

> The more accounting is a business transaction byproduct, the more
> of us can use it. This can only happen if future PDAs are network
> appliances, calenders, credit cards, TVs, video recorder/players
> and business, medical and family interchange and history devices.

That's what we say.

> You think this impossible?

Not at all. I'm sure you can find some skeptics somewhere though.

> It is likely there will always be a need for accountants to verify
> accuracy and provide insight. However, even such functions may
> well be largely taken over by programs like those that let computers
> often better analyze ECG reports than the doctors who program
> them.

I totally agree. Approve payments and expense allowances also.

Some very good points. Take care.

David Lyon
Product Manager
Global TradeDesk Exchange

----- Original Message -----
From: "Mike Block - Tax Cut C.P.A." <blocktax@mindspring.com>
To: "David Lyon" <david.lyon@globaltradedesk.com>; "Todd Boyle"
<tboyle@rosehill.net>
Cc: <ebxml-dev@lists.ebxml.org>; ""Rachel Foerster ""
<rachelf@ix.netcom.com>; ""'Frank. Christopher'"" <C.Frank@seeburger.de>;
""'Christopher Harvey'"" <ckharvey@zaratechnology.com.sg>;
<mike@rawlinsecconsulting.com>; ""Doug Sleeter"" <doug@sleeter.com>
Sent: Wednesday, April 24, 2002 5:42 PM
Subject: B Re: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...


> David said, "The fact is that nobody has (yet) released a reliable
> business messaging product that is suitable for Small Business use.
> That is the main problem."
>
> I am a nonentity in the small business messaging and ebxml area,
> but let us see. It probably took billions of years before there were
> people and around a further million years before the printing press.
> The press surely let many small businesses send messages. Within
> about the next 200 years the telegraph and the telephone sent many
> small business messages.
>
> We began getting computers only about 60 years ago and quantities
> of small business computers around 20 years ago. It was not until
> around 4 years ago that cheap Internet connections got common.
> Until then few small businesses could use a releiable small business
> messaging system. Now we send millions more small business emails
> each year. My email is pretty reliable, though email is not what David
> meant.
>
> Some say we should have a universal small business messaging
> system for accounting data by now. Heck, I recently heard we
> still have around 800 different spoken languages. Some how
> many of the users of each of the languages use good produced
> by small buinesses speaking other languages. To me that says
> we have long had a pretty reliable small business messaging
> system for accounting data, though users of many languages try
> to perpetuate their native tongue. Be a bit patient with ebxml. It
> is far younger than most of those babies that only their mothers
> can understand.
>
> I doubt we will ever have many ebxml accounting appliances.
> This will not happen because accounting is too complex for the
> PDA equivalents we will soon have. It will not happen because
> accounting will soon be too simple for them.
>
> End user accounting only got simple enough for non-accountants
> when Intuit began to revolutionize the way individuals and small
> businesses manage our finances. It involved masking most of the
> accounting technical details behind easily understood business
> forms and menus.
>
> The more accounting is a business transaction byproduct, the more
> of us can use it. This can only happen if future PDAs are network
> appliances, calenders, credit cards, TVs, video recorder/players
> and business, medical and family interchange and history devices.
> They also must have a GPS and be a word processor, game player,
> teacher, phone, speach processor & language translators. Of course,
> I am probably leaving out more functions than I am including. That is,
> they must be so useful that we rarely try to interact without them.
>
> You think this impossible?
>
> How can you say that when we learned to fly, invented computers
> and went to the moon in less than 70 years, after barely walking
> for a million?
>
> How can you expect me to agree if I use programs that integrate
> and share local and remote accounting, billing, calendars, contact
> management, database, email, fax, filing, hand writing, scanning/
> OCR, spreadsheets, speech recognition, taxes, to do lists, web
> access, word processing and other functions I cannot even recall
> now?
>
> It is likely there will always be a need for accountants to verify
> accuracy and provide insight. However, even such functions may
> well be largely taken over by programs like those that let computers
> often better analyze ECG reports than the doctors who program
> them.
>
> A recent TV program discussed super accurate smart bombs.
> Solid state GPS guidance now costs only a few dollars, compared
> to thousands for innacurate mechanical gyro systems. Moore's Law
> is still doubling computer speed every 18 - 24 months, at much less
> cost. Metcalf's Law shows network value increases exponentially
> with added users. This constantly makes more of us more creative
> and better off financially and physically every year, so we keep
> getting new super PDAs, new programming and programmer-less
> languages, new drugs and countless other once impossible things.
>
> This power also insures that we will soon be increasingly far better
> connected. Business at the speed of light is more than a Bill Gates
> slogan. Gates could not buy Intuit. There will now be a critical fight
> between Microsoft Money & GreatPlains, Oracles Business Suite
> (NetLedger) and Intuit's Quicken, QuickBooks and QuickBooks
> for the Enterprise. Despite this, don't worry about Bill. I think the
> most important part of XP is .Net. It may make most programs talk
> to each other, not just accounting programs. Bill also has a second
> generation Biztalk server to translate data between programs. A year
> ago the CEO of one of these companies said Biztalk would resolve
> differences between different ebxml versions. It obviously will take
> a little more time, but I do not know any reason why someone may
> not be able to do this.
>
> Intuit may lead the way with ebxml. Of course, it is not yet 20 years
> old and QuickBooks is only around 10 years old. Therefore, it is
> unlikely anyone wanted a small business accounting data conversion
> program from Intuit 10 years ago. Today they have around 70% of
> the home checkbook program market (Quicken) and 80% of the
> small business accounting program market (QuickBooks).
>
> A QB add-on developer said Intuit was "actively hostile" to his efforts
> 4 years ago. As far as I know it was only in the 1998 QB beta tests
> that there was obvious strong support for a QB developer version.
> That is when I started building my QuickBooks Add-ons web site.
> I still have many more such QB add-ons now than Intuit does at
> http://blocktax.com/quickbooks-addons/quickbooks-add-ons.htm
>
> QBxml is only 10 month old for developers & 4 months old for end
> users. It applies only to QuickBase, QB for the Web and QB Pro
> and above.  However, with Microsoft extending .Net to M$ Money
> and Access, Intuit should quickly extend QBxml to QB Basic and
> Quicken. Quicken has around 7 times the users of QB & only it
> has investment accounting and planning.
>
> Microsoft dominates operating systems, programming languages and
> office suites more than Intuit dominates accounting. I think, our future
> accounting programs will be embedded in universal linked programs.
> This means Microsoft's operating system to office suite experience
> may be more important than Intuit accounting dominance. However,
> both companies may be more limitd by anti-trust action than IBM,
> Oracle, Sun, HP/Compaq and others who are all working hard on
> ebxml. Should all companies agree an ebxml standard instead of
> fighting for their own versions?
>
> Not if you believe in democracy and our free enterprise capitalism! It
> is only by their competing that the vast majority of us will get the best
> selection and lowest prices. Need you ask the Russians or Japanese
> how they made out with planned economies in the long run?
>
> The current ebxml mess and delay are only the latest example of our
> terribly inefficient system, which somehow accomplishes far more
> (for far more of us) than any other system.
>
> ----- Original Message -----
> From: "David Lyon" <david.lyon@globaltradedesk.com>
> To: "Todd Boyle" <tboyle@rosehill.net>
> Cc: <ebxml-dev@lists.ebxml.org>; <mblock@blocktax.com>; <doug@sleeter.com>
> Sent: Tuesday, April 23, 2002 9:20 PM
> Subject: Re: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
> ...
>
>
> > Todd,
> >
> > It isn't as simple as you might think and I don't believe that there is
a
> > conspiracy as you would have us believe.
> >
> > The fact is that nobody has (yet) released a reliable business messaging
> > product that is suitable for Small Business use. That is the main
problem.
> >
> > The Accounting Software providers know this. They can't write one either
> > so they just stick with what they are good at, writing accounting
systems
> > that don't talk to each other.
> >
> > Millions/Billions was spent on developing EDI. It's not that people
> haven't
> > tried.
> >
> > The Europeans spent big on X.25/X.400/X.500 technology in an effort to
> > get that to work.
> >
> > The Web was probably the first big jolt as the cost of networking
> equipment
> > became affordable.
> >
> > Don't be fooled, the world can only move so fast. There are *real*
> technical
> > challenges involved.
> >
> > One point that I would like to make is that with SBCs (Single board
> > computers) it is quite feasible to put an accounting system on one of
> those.
> >
> > With a Flash Disk RAM chip, you get 64MB which is plenty enough for a
> Small
> > businesses transactions for the year.
> >
> > See http://www.embeddedx86.com/epc/ts3300-spec.php for quite a good one
> > and go to the local camera shop to see where they sell the Flash Memory
> that
> > you can plug in.
> >
> > Consider the practical implications: A Plumber can have his ebXML server
> > implanted on the dash of his van. When people make a reservation, it
comes
> > up on the screen.
> >
> > Other possibilities: Video Shops, Pizza places, Small Hotels that could
> > never afford a "server solution" can all use tiny SBC based connectable
> > accounting systems that all talk to each other.
> >
> > This is the Small Enterprise vision. It's the same computer firepower
that
> > the big companies have, only it's running from a whole set of mobile
> > locations.
> >
> > What I would suggest is to start making something for this market.
That's
> > how Intuit and the others started. Now it's grown from nothing to being
a
> > very huge market indeed.
> >
> > Best Wishes
> >
> > David Lyon
> > Product Manager
> > www.globaltradedesk.com
> >
> > ----- Original Message -----
> > From: "Todd Boyle" <tboyle@rosehill.net>
> > To: <rachelf@ix.netcom.com>; "'Frank. Christopher'"
> <C.Frank@seeburger.de>;
> > "'Christopher Harvey'" <ckharvey@zaratechnology.com.sg>;
> > <mike@rawlinsecconsulting.com>
> > Cc: <ebxml-dev@lists.ebxml.org>; <mblock@blocktax.com>;
<doug@sleeter.com>
> > Sent: Wednesday, April 24, 2002 10:37 AM
> > Subject: RE: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core
Components
> > ...
> >
> > > At 03:17 PM 4/23/02, Rachel Foerster wrote:
> > > >Todd,
> > > >
> > > >Way to go. But, and this is my beef....if QuickBooks enjoys 80%
market
> > > >share, and I believe it does, then why on earth can't one user of
> > QuickBooks
> > > >interoperate with another user of QuickBooks for the electronic
> exchange
> > of
> > > >purchase orders and invoices. Gads, this should be a walk in the part
> for
> > > >the developers at Intuit! And furthermore, Quicken and QuickBooks
> should
> > > >interoperate as well!!! Child's play!!!!
> > >
> > > That is the $64,000 question we have been asking for ten years,
> > > on the accounting newsgroups and the inescapable conclusion
> > > is that, whatever else a vendor might include in an accounting
> > > system they must NEVER provide functionality that allows users
> > > to easily migrate to other platforms.  Vendors who had open interfaces
> > > went the way of the dinosaur.  Lock-in works.  That's that.
> > >
> > > Ask yourself, why hasn't there ever been a lingua franca for data
> > > files between accounting systems?  Whenever somebody starts
> > > designing one, the vendors head the other direction, on purpose.
> > >
> > > Many in alt.accounting and the quickbooks groups also conclude,
> > > that Intuit does want to capture some type of portal role between
> > > their users and the rest of the global economy.  You can see
> > > that clearly in the design of Quickbooks.com website and the number
> > > and variety of network communications launched by Quickbooks directly
> > > to Intuit or to the Quickbooks portal, with or without the consent of
> > > users.   Clearly Intuit will not put open interfaces on the product,
> > > if their users are so passive that they will allow Intuit to operate
> > > as a portal, collecting percentages and limiting their access to
> > > competitive products and services.
> > >
> > > Another factor:  it is widely agreed by now, that software vendors
> > > should prevent any excessive accumulation of add-on or 3rd party
> > > markets from accumulating because that can severely limit their
> > > flexibility to deploy new generations of software (the legacy user-
> > > base problem).
> > >
> > > For example, there were so many applications on
> > > btrieve databases, or the novell network stack, etc. in the 1980s
> > > and early 1990s it was a major hassle for Microsoft until they
> > > gradually destroyed all those applications one by one.   Ditto
> > > for the browser.  If the MSIE browser were W3C standard or
> > > if it stood still for very long it would be imitated, and everybody
> > > would start writing software against the clone instead of Win32,
> > > or the new DotNet cr*p.
> > >
> > > Microsoft succeeds in putting together a single platform, year
> > > after year by skillfully dispersing any bloc of users whenever it
> > > gets too large, having dependencies on any API.   Intuit will have
> > > to do the same thing.
> > >
> > > When Intuit follows through with its promised "QBXML"
> > > interface and its new Intuit Developers' Network it will be setting
> > > the clock ticking towards one of two paths:  either a very large
> > > and rather rigid market with thousands of interoperating users
> > > depending on the 2002 versions of APIs, or, a devastating and
> > > wrenching changes in the APIs in 2004, 2006 etc. similar to
> > > what Microsoft does,
> > >
> > > Another factor against a big ISV community: whenever you have
> > > that pattern, competitors start cloning behavior patterns. For
> > > example, Intuit has something like 3000 developers @ $1000 apiece,
> > > registered in its developer network.  If they produce 3000 really
> > > great applications that use QBXML (or whatever API) then surely,
> > > clones of Quickbooks that cost less money, will start appearing
> > > to use those APIs.  In fact you will certainly be able to connect
> > > many of those Quickbooks addons directly to each other without
> > > any Quickbooks in the middle.
> > >
> > > Which brings us back to ebXML common semantics, common
> > > business process definitions, the RegRep etc.   I love this ebXML
> > > stuff, it is the best hope for all of us,
> > >
> > > Todd
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.ebxml.org/ob/adm.pl>
> > >
> >
> >
>