Re: [ebxml-dev] Re: Addendum to Automating execution of Biz Processes(& BPSS)....

[Todd Boyle <tboyle@rosehill.net>]

At 08:25 PM 6/25/02, Klaus-Dieter Naujok wrote a brilliant piece ... thus
stimulating mental midgets like me to challenge him!  :-)

>Conclusion
>
>The question is will the current supplies of shrink-wrap solutions integrate
>ebXML into their offerings? For now these application vendors don't see the
>need for such an interface, or don't have the know-how to develop it. This
>opens the door for someone who knows the data interchange business to create
>the front end to those applications and to import a particular model in
>order to engage in the exchange with other partners that are ebXML
>compliant.

The 1000 largest Enterprises won't genuinely support global standardisation.
Oh, they get up early in the morning and work all day long, to make their
*own* software more efficient, even if that means driving adoption of
software in their whole supply chain.   BUT!  They must ensure that
whatever they design, build, support etc. does not make their competitor
more efficient to an equal degree.  If the whole industry becomes more
efficient only consumers win.  Producers just work harder.

ERP vendors knowing this, have bagged the Global 1000 firms with
applications they can endlessly configure and play with, and EAI
industry creates more. Now we're seeing the CRM industry and BI
etc.  From SME's viewpoint this is a disgusting spectacle that
translates into nothing but an advantage of the large over the small,
as only the largest corps can afford software and their systems
become entirely incompatible with SME and midrange platforms
(which have not improved substantially since the early 1990s
when we got GUIs, 32bit applications, and microsoft killed all
the other multitasking and networking choices.)

The SMEs having different behaviors, are captured by their own
vendors with plain old file and data lock-in.   This has long ago
run its course and collapsed into near monopoly among a few
packages owned by Intuit, CA, and Sage (including Peachtree,
business works etc.).

>There are many opportunities for such software front-ends. In addition to
>being able to execute more than one (if not all) business model(s), the
>application could use agents to query on-line repositories to identify
>potential trading partners for a specific requirement (order). In addition
>to just being the front end to a popular business application, one could add
>the capability for the system to be configured to in-house applications that
>were custom developed. Further, the in-house business process could also be
>stored in a business process model allowing agents to not only identify
>potential customers based on a static in-house process, but possibly
>extending the number of potential partners by modifying (adopting) the
>internal processes based on the knowledge of both models. The technology is
>there, we have the know-how; all it takes is for us to harness it.
>
>In closing, the success of any new way to exchange data among businesses
>depends not only on the adoption by the Fortune 1000 companies of standard
>agreements, but as well as on the utilization of the other 25,000,000 SMEs
>in the world. Without an economic incentive for the SMEs, any new method of
>accomplishing e-Business is just another pointless effort. ebXML is
>currently the global solution that uses business process and information
>modeling and object oriented technology to allow the software vendors to
>create the "volks data interchange" solution. The time is right for someone
>to do it, now.

No, there's not much business opportunity building addons to Intuit
Quickbooks, Sage Peachtree etc.  They're just waiting, to play that game.
Right now they're making millions from fees, from starry-eyed developers
and VAR wannabes.

Isn't it mysterious to you that the oligopolistic SME software vendors,
who could have long ago implemented "state alignment" among a whole
lot of obvious exchanges such as list data, purchases, sales, have not
done so?  They could have done it back in the days of DOS and
modems and BBS's.

The reason is that without data capture and lock-in, there is no
above-normal return in SME software.   All these vendors have
some ASCII interfaces, some APIs.  But these interfaces are *crooked
as a thumb.*  You cannot build applications that rely on those interfaces
because there is invariably something missing, something that corrupts,
or something that has a runtime royalty, platform churn etc. Many of
them still use btrieve database layer. e.g. Peachtree.  You know the
history of btrieve-- the database can't get a decent grip on the disk,
constantly undercut by changes in the hardware layers under DOS or
Windows.  It's a miracle Quickbooks' proprietary database still runs,
on Microsoft's ever changing platform.  The likelihood that anybody's
Addon software to these platforms will find a dependable API, that
reliably commit transactions over the amortization period of the addon
software, is not high.  The maintenance and support will kill you.
You'll be up there at $3000 or $5000.  A startup could deliver a
whole new SME package for less than that--or buy/partner with
one of the dozens of 2nd tier products.   Klaus- you said, somebody
who knows the data interface business should build addons to
Quickbooks. I say, no, they should buy or partner with a 2nd tier
product or build from scratch. You need something you can walk
away from and it keeps running a couple of years.

SMEs will continue with Quickbooks basically forever, until there is
a damned good reason to buy a entirely different software packages
from an entirely new generation of software vendors.   Existing
dominant vendors would have to be crazy to start opening up an
honest API anyway, with well defined semantics.  Sheesh. never
happen.  The applications would have to be changed anyway.
All of the terms on the user interface are intentionally general
and vague.  They are not core componentish. The whole mode
of operation is basically manual.

Again think of what you know about Enterprise vendors.  They
have no freedom really.  They can only sell what Enterprise is
ready to buy and what maximizes their revenue. That in turn
must maximize Enterprise' lock on their customers and suppliers,
and that often means, being a bad actor and not sharing data.

SMEs today have no reason to change. OK, there might be a
few good reasons in future.

1) access to substantially better markets or new customers
or stronger prices for what they sell.  and, access to lower cost
suppliers, better terms of trade, etc.   This is the siren song of
B2B isn't it?  But they're mutually contradictory.   How can
everybody on ebXML get higher revenue, while everybody has
lower costs?  heh heh!

But even so, SMEs are supposed to get better customers and
suppliers, by deeper process integration with Enterprise..  Well
maybe.  SMEs will have to observe, who turns out to be the winner.
Suppliers apparently have been the lusers. (That's SMEs.)

(Remember I'm talking about the smaller, millions of SMEs not
the real demand-signal types of companies.  ebxML or EDI
for that matter, is great, for them.)

2) Another d'good reason: major convenience for some significant fraction
of their business dealings.  Only Microsoft can provide this today,
without requiring a mass adoption as precondition.  They can make
whole categories of transactions almost secure enough for daily
use, because they are the only people who have sufficient control
over the security of Windows itself.

In other words, Microsoft can put a new gizmo on the desktop
that sends and receives a particular document within a particular
choreography and just the existence of that, would cause
some broad adoption. What if it was a signing Icon where you could
drag and drop any arbitrary XML document and signed and encrypted
the document and sent it to the address inside?  Mickey can
do anything like that.  But nobody else can do it.  Odds are,
Mickey will win.

Time is on their side.  They can keep hiring thousands and
thousands of guys like Jim Clark who then go silent.  My whole
neighborhood here is full of Indian, Chinese, Brits, Japanese, Koreans
as well as Compaqians, Dellians, Ciscoeans, and now GreatPlainsians.
Lots of others have already been ploughed under, you know,
the DEC people, 3+Open people before that, etc.  In fact there
is tall grass in front of my neighbor, the Compaquian who
must have been reloc.d back to Houston.

I read somewhere, they have 500 million desktops.  That is a lot
of desktops, where you cannot install eCommerce because
they are too insecure.  Isn't that an odd circumstance?

3) another possible driver for ebXML never mentioned here in ebXML is the
escape from regulation and taxation long recognized as a possibility
with digital cash and ebusiness exchanges.  The explosion of
wholesale looting of music by 50 million people the last couple years
shows, there can be very very rapid adoption of things that give a
sudden economic windfall, and that people are disgusting and lawless.

If you have the stomach for the consequences, then, build ebXML
business choreography into a headless P2P application with
its own mini-RegRep. Skip the CPPAs and build in something
like Webfunds client for digital cash.  That has been out there
for years and works fine. There are already numerous mints for
that, and there are other competing mints and clients, and a
lot of brokerages between them all.

However, sad to say there are break-ins and theft of digital
cash, and other disasters on a weekly basis on the digital gold
lists.  Why?  Because users are too clueless and Windows
is insecure.  If this is happening among technically savvy,
early adopters of digital gold, then what will happen when
ebXML is widespread, on Windows?  No doubt, crooks will
come in and fsck with your numbers in order to steal inventory
or tweak their payable/receivable balances in your system.
Or just to nuke your system.  OK, these risks are mitigated if
there's no digital cash and there is an orthodox bank-based
settlement, B2B intermediaries, audit trail, etc.!  That's fine,
but then, there is less of a payoff for I/SMEs to adopt it.  We
already know what SMEs think of B2B portals: they ignore
them, with prejudice!  :-)

Any serious ebXML needs to happen on Linux or BSD and
the accounting or business software on those platforms is
quite primitive and unsuitable for modification for ebXML.
Green fields.  Truly, green fields.  That's where ebXML will
happen for SMEs and probably outside the United States.
Not from the mature Windows vendors.

>===============
>
>BTW, the full article is available on my web site.
>
>Regards,
>Klaus

I agreed with just about everything in your article! Well said.

In particular -- SMEs need content, at this point.  They need
a library of Core Components elements and aggregates,
the sooner the better, and they need basic set of Business
Processes.  Neither of these needs to be rocket science
because no vendors are going to adopt the technical specifications
anyway.  They will pluck some of the semantic content and
smurf it all up within some kind of a strategic game, to
allow some partners to integrate a few selected things
just like they are doing with "web services".  They're just
trying to immobilize customers and churn everything.
ebXML is the "end of history" for all the basic business
choreography and severely constrains the differentiation
possible in whatever specialization remains.

LAMP (LinuxApacheMySQL/PHP) developers will have a
field day, with these globally standard data dictionaries.

Give them the content!

Todd