SV: Where to next? - It's not the traction, nor supporting two stacks, nor any of this!

["Mikkel Hippe Brun" <MHB@itst.dk>]

Dear David et al

This will be a short post since I have to get back to work on rolling out UBL
infrastructure. 

I think that we share the same goal: 

1. That it should be possible to exchange business messages with very low
barriers 
2. and that it should be possible to do this on an open standards based and
freely available platform.

We are establishing this freely available platform. I think of this as
putting up an ice cream machine with free ice cream. The ice cream comes in
two variations, but we have to pick one of them: 

We have the choice of an ebXML organic flavor and the WS-* synthetic flavor
with lots of GMO's. The kids says "Give us the WS-* flavor and we will eat
lots of ice cream. We will integrate the ice cream in the heart of our
applications and do all our home work." I don't mind serving synthetic ice
cream if it can motivate my kids to do their homework.

Once we get the ice cream flowing it will affect the ways we do business
immensely. Adoption rate is critical because the business case for
establishing an infrastructure is incredible. But we have to act fast! Public
sector institutions are building infrastructure from the ground up every day
based on WS-* standards and we have to stop the insane redundancy of efforts
and waste of tax payers money. We can save 300 million USD every year in the
public sector by establishing a shared infrastructure (We are only 5.5
million inhabitants in Denmark). It makes a world of a difference how fast we
can establish the infrastructure. We do not have the luxury to choice of the
organic road because it will affect adoption. We have support from very small
companies as well as big enterprises. The toolkit that we are developing will
make it very easy to use our infrastructure. I do not share the concern that
our approach will only be to the benefit of governments and large
enterprises. It's a business requirement that the baker on the corner should
be able to plug into our infrastructure with OSS components. We have
demonstrated that this can be done.

Well - I am getting back to work. I am so thrilled by what's happening to UBL
at the moment. NES has invited other EU member countries to a workshop in
Brussels on February 15th to get more support. The UBL TC has succeeded in
creating a viral technology and I congratulate all of the hard working TC
members for their contribution. You have given us the payload, which will
drive the establishment and roll out of infrastructure in Denmark and around
the world.

I hope that we can all agree that as long as UBL payload can flow from one
framework to another in a reliable and secure fashion, then we are all OK!

Best regards
Mikkel

> -----Oprindelig meddelelse-----
> Fra: David RR Webber (XML) [mailto:david@drrw.info]
> Sendt: 5. februar 2007 01:15
> Til: Mikkel Hippe Brun
> Cc: ubl-dev; fulton.wilcox@coltsnecksolutions.com; Roger Bass; Sacha
> Schlegel; Stephen Green
> Emne: Where to next? - It's not the traction, nor supporting 
> two stacks,
> nor any of this!
> 
> 
> Mikkel, 
> 
> It's much simpler than all of this.  We've been fighting this
> "self-fulfilling prophecy" stuff from Microsoft and IBM especially for
> the past five years - when they decided they wanted to step out from
> supporting ebXML  for whatever reasons and agendas they had (sure -
> they had plenty - but few they wanted to admit to - more on this
> below). 
> 
> For me this is exactly the same battle and arguments that 
> were thrown at
> UNIX/LINUX for exactly the same reasons. 
> 
> The double standard and hypocrisy are there for everyone to see.   
> 
> If the roles were reversed - do you think we'd be hearing any of these
> arguments?  No - it would sooo eassy to put WS-* alongside SOAP/ebXML,
> no problems.  Do you think we'd be hearing "traction" 
> mentioned if WS-*
> had 11% and ebXML 17% according to CDBI? 
> 
> And project costs - I've seen first hand that maintaining the 
> messaging
> stack takes less than 10% of the project resources - the other 90% is
> all on application support, XSD issues, java null pointers, database
> issues, and performance tuning.  Also we know from the EDI 
> world - once
> the messaging is running - its very stable.  And we know this 
> stuff just
> plain works - as Norway can see from their NIA solution.
> 
> You have to look at what is REALLY going on here.  It's all 
> about money,
> contracts and lock-in.  I've been doing this consulting all 
> now too long
> to not realize this was why IBM got "cold feet" over ebXML - when
> someone said "wait a minute, why are we doing this?  This undermines
> why customers need Websphere, AND worse means all our competitors know
> how to do all this - not just our engineering teams".   And Microsoft
> said - "this undermines BizTalk server and our developer re-sellers" -
> so they formed an unholy alliance - because they said they had "simple
> web services that in six months would replace complex ebXML". Do you
> remember that pitch?  Ironic is'nt it - five years later and 
> their WS-*
> stack is way more complex than ebXML.
> 
> Look if you want standards - anyone can BUY an ISO standard 
> these days -
> Microsoft just did it for OOXML... and now all the big guys have open
> source solutions.
> 
> So what is the TRUE MEASURE of open public standards and solutions?
> 
> Does one segment of the marketplace gain significant lock-out by
> imposing their standards on the remainder?  Open standards 
> only benefit
> customers when they create a broad marketplace - where costs over time
> are reduced and implementers can easily deploy the technology.
> 
> So using ebXML here is your insurance policy. What if there are no
> alternatives to WS-* ? Whatif WS-* v3+ is even more complex so that
> only the few trained consultants know how to make this all work
> together? I'm sure the sales organizations from the Big-6 are hoping
> for exactly that!!!
> 
> And notice that there has been a HUGE TREND ALREADY toward complexity
> with XML.  UBL is a case in point.
> 
> What happened to the whole vision that Tim and Jon had back in 1997 -
> that XML would be simple and human manageable and work with existing
> tools and editors?
> 
> You cannot even OPEN a UBL schema and understand it - without using a
> $200 tool now... 
> 
> (unless you are using a CAM template to guide you on your use 
> model...is
> this telling you something?)
> 
> Mikkel - please do not be blinded by this.  
> 
> I can give you 50 whitepapers that argue about the pro's and con's of
> ebXML, WS-* and more - but the reality is that one technology is
> designed from its foundation to be inclusive and accessible 
> and totally
> public and neutral.  The other - well only "professional drivers on
> closed courses can be driving those cars".
> 
> And since UBL is supposed to be the "Volks-Technology" 
> enabling everyone
> to do e-Invoicing - if I were you I'd be including that 
> little piece of
> ebXML "insurance policy" in your implementation mix.
> 
> But of course, when you do that, you will hear a chorus of wailing and
> dismay from the "Big-6" partners - and that should be telling you
> something also.
> 
> The irony is that Oracle has the most to gain and to offer here to its
> customers - and I beleive they sense that here.  This is simple
> value-add that any Oracle customer can get right away for a small
> effort and cost.  And Oracle is being very saavy these days in
> maintaining customer loyality by emphasizing inherent benefits from
> their solution suite.
> 
> You maybe just so surprised here - to discover as the Canadian
> Government did - that by including the use of ebXML - they suddenly
> found it makes total sense and dramatically lowers the costs for their
> partners...
> 
> Thanks, DW
> 
> "The way to be is to do" - Confucius (551-472 B.C.)
> 
> 
>