RE: MORE: [ebxml-mktg] FW: [ebxml-dev] Gartner and ebXML

["Yader, Mark (GXS)" <Mark.Yader@gxs.ge.com>]

Title: RE: MORE: [ebxml-mktg] FW: [ebxml-dev] Gartner and ebXML

After spending a week at the XML Web Services conference in Boston, I would concur: ALL of the WS presentations were given by vendors or consultants....no real end-users, per se.

Mark

-----Original Message-----
From: alankotok@cs.com [mailto:alankotok@cs.com]
Sent: Tuesday, September 10, 2002 2:57 PM
To: Gnosis_@compuserve.com; Yader, Mark (GXS)
Cc: ebxml-mktg@lists.ebxml.org
Subject: RE: MORE: [ebxml-mktg] FW: [ebxml-dev] Gartner and ebXML

David, Mark:

IDC released a study today on Web services plans and implementations, which showed (as you might expect) big plans but few implementations.  Our Daily Wire story notes ...

<excerpt>
IDC says for many respondents, the prospect of moving to a more flexible, interoperable systems environment is highly appealing, but the Web services phenomenon has been hyped prematurely; standards are still evolving and semantic concerns have yet to be addressed.  Similarly, the benefits of investing in an immature technology just aren't clear enough to justify the investment in the current environment. 

</excerpt>

The study suggests that customers for Web services may indeed want some of that over-engineering our less enlightened friends cite as a problem with ebXML.  From a marketing/public-affairs standpoint, we have an opportunity to position ebXML as Web services for grown-ups: solid infrastructure combined with real business processes and semantics, packaged in open, vendor-neutral standards.

But we need to do it soon, before Web services grows up.

For more info ...
Daily Wire story: http://65.201.162.121/dailywire/S20020910_05.html
IDC Web services page: http://www.idc.com/webservices

Alan Kotok
AlanKotok@cs.com
http://www.technewslit.com/
Editor, <E-Business*Standards*Today/>, http://www.disa.org/dailywire/
Co-author, ebXML: The New Global Standard (Sept 2001, New Riders), http://www.ebxmlbooks.com/

David RR Webber - XMLGlobal <Gnosis_@compuserve.com> wrote:

>Mark,
>
>I knew I'd get quality feedback.   Here's what I based my thoughts on.
>
>Last week I read a blurb on a web service implementation, where the virtues
>of
>all the interactive forms that had access to the backend systems
>were being expounded.  And I see a recurring theme here -
>simple access via Internet.  As I stopped to review this - then
>I saw this is exactly what realtime EDI systems do.
>
>Mostly this is availablity of transient resources - bookings systems,
>high volume purchasing, perishable goods, and in online ECommerce
>systems - "find me the best price of widget X".
>
>There was not one word about EAI in this.
>
>Now in regards to EAI - I would argue that ebXML brings much more
>to the table that pertains to those formal interchanges.  And vital is the
>Registry, Metadata and Assembly technologies of ebXML - a fact
>that large US Gov Departments with thousands of such interfaces
>have grasped readily.
>
>And then there is the access model - would you really open up
>your backend EAI systems to the risks that come with Realtime EDI?
>
>Exposing information is good - but you have to realize how quickly
>the fox can carry off the chickens once the hole in the fence is
>discovered.  I'd like to wager a beer that web service interfaces
>are being deployed today with all the same mistakes that were
>learned before - since the people building them never worked
>on those older systems.
>
>But as you rightly point out here - and I believe I personally
>have proven this over the last five years - our main focus
>is on bringing the right combination of technology to the table
>as solutions - to enable the ultimate end users to deliver
>better products and services to customers longterm with
>confidence in the approach and the architecture.
>
>The truth is that the ebXML is not broken, and that it has
>been skillfully architected combining the talents of the
>broadest range of engineers.  Web services up to now
>has been narrowly engineered by a few companies
>with a specific market focus.  And what I find bad is when
>perfectly good pieces of ebXML are being re-engineered
>in slightly different terms, instead of the original being
>embraced - when that effort would be better directed to
>providing feedback to the open ebXML process to
>refine and extend.
>
>This is a two way street.  While we are strenously working
>to show how WSDL and other components work in
>excellent combination with CPP / BPSS technologies,
>we are facing a situation where certain players in the
>WS-I camp would rather roll-over and die than
>embrace and extend.   And it is very clear that web
>services used in the role of realtime EDI dramatically
>need robust CPP / BPSS / Assembly controls to
>ensure information exchanges are not compromised.
>
>What this really comes down to is educating customers.
>
>People are buying into webservices in good faith.
>However, how much of this is a "Oh - don't worry we'll fix
>that in next years release!  Just don't use that right now".
>And in reality the "fix that" is re-engineering pieces that
>ebXML can provide today - proven and tested.
>
>So - we need customers to be asking these tough
>questions - and seeing the value that ebXML brings
>here - and how the combination of ebXML with Web services
>gives them a richer environment - just as batch EDI and
>realtime EDI are working in tandem, and how this
>model can be extended of course to EAI today.
>
>On the technical side - as we proved time and time
>again during the ebXML development process - if
>you can push the politics aside, and let the
>engineering teams work unimpeded - then the
>alignment and integration happens.
>
>OASIS is facing this same challenge today with
>the UDDI work and the ebXML Registry.  These are
>two different business models, and they are potentially
>complimentary - serving different but allied and
>ultimately collaborating communities and customers.
>
>The challenge is keeping the politics out - and having
>the techies simply work on "OK - how do we connect our
>two pieces together - so they become extensions of
>each other?".
>
>Our task here is to promote the benefits of ebXML, not
>to the exclusion of web services, but to show when
>and how you can select appropriate usage of each,
>and conversely - talk about where the "I have a hammer,
>everything looks like a nail", worldview is creeping in
>to the exclusion of common sense.
>
>I've never met a marketing or sales type who
>responds with "No, if that is what you want, then
>our stuff will work with this other guys stuff for that".
>
>It's always - "Major company X wants to do this - how
>long will it take engineering to patch this and have
>the demo up and running?".
>
>Thanks, DW.
>======================================================
>Message text written by "Yader, Mark (GXS)"
>>
>David,
>
>YOur enthusisasm is to be applauded, but it appears that the major thrust
>for Web Services is focused on a "standard for EAI", not EDI. More
>importantly, I believe that any attempt to continue the "us versus them" or
>"ebXML versus WS" is detrimental.
>
>Personally, I don't think the concept of "real-time EDI" is as important
>commercially as processes such as "Collaborative SCM". Does anyone really
>care what "real time" is (other than the folks looking for Earthquakes and
>weather-related disasters) ?
>
>Just some personal thoughts.......
>
>Mark<
>
>