Subject: Re: IBM and Microsoft high jinks with UDDI
Date: 09/09/2000         alt.accounting 
Author: Todd Boyle <tboyle@NoSMAProsehill.net>

post reply << previous in search  ·  next in search >>

 

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