[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
You must be a developer right? JMS ain’t ebXML and as you probably missed it: guaranteed message delivery at the transport level has nothing to do with guaranteed processing of your messaging by the receiving application (essential for synchronization of the business state), and “business transaction” means that we both agree that we succeeded or failed in synchronizing our state. Could you do business in an environment where someone could claim that you made this commitment while the other one refuses to accept it and no-one has any ways to prove it? Those are not big words, they are real business concepts that every business person understand on a snap. I even argue that a developer could not care less, for him/her a call is a call, it should succeed otherwise it is a bug, or maybe you try the call until it succeeds.
JJ-
-----Original Message-----
I agree, pronouncing big words is a great way to get business people to agree with you - mostly because they don't know what they mean but are afraid to admit it ;-) Once you leave the room, though, they won't even bother to file it away (I believe the cliché "In one ear and out the other" is appropriate here.) In the end, whether the project goes or not will have very little to do with these words.
I tried to sell a JMS project a few months ago and was very surprised at how little weight words like "guaranteed messaging," and "transaction" carried with that audience. In the end, the solution they chose ignored these principles entirely, not because the business didn't need them, but because I did an inadequate job of selling them.
That is my experience, and, of course, yours may vary.
Regards, Adam
-----Original
Message-----
I can assure you that it takes no more than 50 seconds to explain the differences between ebXML and web services at any business people from CEO to business analysts. You just have to pronounce a few words: non-repudiation, guaranteed message processing by the receiving application, in addition to guaranteed message delivery, transactional protocol, …
I would argue that it takes much more than an hour to explain developers why web services are not enough.
My 2 cents and real life experience.
JJ-
-----Original
Message-----
I agree with Scott's assessment below, but with one caveat: I don't think that web services are that much easier to define or to describe to a non-technical person than ebXML is. Rather, I think that web services have been sold very well by some very influential salesmen. I have used the term "web services" to sell projects within my own organization, because it has become one of those buzzwords that causes the ears to perk up on pointed haired bosses with titles that start with "C." However, in those same conversations it has become apparent to me that if I asked for a definition of "web services" from each of them the answers would all be different and none would be right. In order for ebXML to have the same momentum that web services have it would have to be sold by the right people, articles would have to appear in all the boring business magazines that pointy haired bosses like to read, and pointless metaphors would have to be created such that they could be abused in boardrooms everywhere. I don't know that that will ever happen. It is unfortunate, too, because ebXML would certainly do a lot more for most organizations than web services would. Don't get me wrong, web services are great, but in terms of the real value they add to a business I don't think they're all they're cracked up to be. I have attempted to sell ebXML to business folks, on occasion, and the best explanation that I was able to get across was something like: "It's like EDI, but with XML and web services." Obviously this is a description that anyone on this list (Myself included) could tear apart in a second, but it makes sense to the audience, and is close enough to the truth to keep me from feeling dirty ;-) The problem with this explanation is that it is hard to see where the added value comes from. That, IMO, is why ebXML is hard to sell, because in order to understand what makes it great you have to get under the hood, and the moment you do the pointy haired bosses start snoring. Thanks, -----Original
Message----- The crux of
the issue... IT managers "think" they understand the concept of ebXML simply
lacks an "elevator speech" that is compelling to IT executives. -----Original
Message-----
Duane, Interesting
choice of title for a news posting. Please give me a chance Anyway, I
think we misunderstand each other. I see web services vs ebXML Does a person
who wants to set up a b2b exchange think about a web But before
you get annoyed at this statement please consider how we both Generally
since ebXML uses standards above the core three, I see them as From what I
see there seems to be a general split in the industry So, the
wrongs and rights of a poll that uses these terms is a Or are we saying
that on no basis can there ever be any competition Finally,
please understand webservices.org is my own private website, I work hard
on my site, and ask that you only take a few moments to Regards >
-----Original Message-----
---------------------------------------------------------------- ---------------------------------------------------------------- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC