The technologies of ebXML are being torn away from the carcass
and carried away by the dingoes of the software industry. ebXML
is a very civilized group of course, or they would never have
formed a standards body in the first place. They think it's
fine to see software companies compete on fundamental platform
issues like registries and business process modeling. Frinstance,
Ed Julson said Thursday, September 07, 2000 ebxml-awareness list,
> First of all, I believe the UDDI spec
in its current incarnation
> provides a repository for business information that is
complementary
> [..]
> The ebXML Reg/Rep focus is to build a container for the XML
> vocabularies, core components, and business process that are
> needed for the programmatic support of a business transaction
> or document exchange.
> [..]
> It's conceivable that UDDI could evolve to a point of
overlap
ebXML workgroups, gird your loins, and prepare to embrace and extend the
work of commercial competitors. This means adopting everything
which is good and not proprietary, and willfully breaking whatever they
build which is proprietary.
It would be lunacy for the scale of effort that has gone into ebXML to
be cherrypicked by commercial competitors, without compensation. They
will inevitably differentiate their technologies, breaking key parts of
ebXML work.
I call on UDDI to contribute all of their work to ebXML, and
accommodate the requests of non-UDDI consortium participants in
ebXML. Especially ebXML participants from the software buyers
rather than vendors side, and small business segment rather than EDI
segment.... (if you can find any... )
Is that naive? Yes of course it is. If UDDI wanted to
participate in a standards process, they would be sitting at the ebXML
table, instead of their corp. HQs designing UDDI. It is
hard to escape the conclusion that ebXML is the same as a software
company. It must compete, with its strengths, and play good poker.
Software design is predominantly about securing niches and customers---
more than 50% of the budget or resources of ebXML needs to be devoted to
analysis of competing commercial registries, and competing commercial
middleware, competing commercial repositories and modelling standards.
More than 50% of commercial software developers' budget is certainly
devoted to structures necessary to secure and retain a grip on
customers, in ways that cannot be immediately commoditized.
BPMI somehow bothers me as well. They were formed what, August
2000? http://www.bpmi.org/faq.html
--innocently they say "BPMI.org and ebXML are addressing
complementary aspects of e-Business process integration. While ebXML
provides a standard way to manage Collaborative Business Processes (CBP),
BPMI.org focuses on the modeling, deployment, and management of
Enterprise Business Processes (EBP). " Yeah right.
Obviously, Business Processes extend across enterprise lines. Splitting
the internal BP modelling and development from inter-entity is an
unfortunate step that will setback the integration efforts by years,
harming both the internal and external parties.
BPML and UDDI are birds of a feather, if you ask me. Let's
get their authors integrated into ebXML, or impose consequences.
The individuals who are selling this to IT are not invincible.
Their story does not hang together and should be challenged. ebXML's
architecture must become a more dynamic thing, capable of willful and
measured changes, TO DEFEAT COMPETITORS. You have to move up the
food chain, and become the lion of the savannahs instead of the
antelope.
Todd
* Todd F. Boyle CPA http://www.GLDialtone.com/
* tboyle@rosehill.net
Kirkland WA (425) 827-3107
* XML accounting, web ledgers, BSPs, ASPs, whatever it takes
|