[ebxml-mktg] [user friendly write-ups] (was) fwd: gorilla hair vs.beach balls

[James Bryce Clark <jamie.clark@mmiec.com>]

Forwarding to ebxml-mktg, where this may be a very useful discussion.
Thanks  JBC

>Date: Thu, 20 Jun 2002 09:30:52 +1000
>From: "Webb, Mark" <Mark.Webb@industry.gov.au>
>Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
>To: ebxml-dev <ebxml-dev@lists.ebxml.org>
>
>Just a (possibly horribly under-informed) vote along the same lines. I'm
>working with an Australian government team who are trying to build support
>for an Australia wide "electronic machine-to-machine services directory"
>based around the Australian Business Number (ABN - a unique business
>identifier that all businesses in Australia have) as the primary discovery
>key (no technology or particular standards have been selected at this time).
>
>Because the funding decision makers are not technically literate, there is a
>real need to articulate the issues around this whole area in business terms.
>Dieter's point about strategic issues is absolutely spot on - in my case,
>it's attempting to articulate the strategic advantage that such a directory
>could bring to the country as a whole.
>
>While investigating "prior art" in this area, I read a lot of "technical"
>documentation that convinced me that what we are proposing is a good idea,
>but I have yet to find an external document that I can point these
>non-technical decision makers to that will explain some of the issues that
>are going to come up as a result of wider adoption of electronic services
>(such as interoperability, discovery, trust etc) in business terminology. As
>important, there nothing I can point to that explains what's happening out
>there to try and prevent the problems in the first place (again in business
>terms).
>
>At the end of the day, no matter how much I believe in the work of
>initiatives like ebXML, I won't be able to do anything useful unless I can
>first convince people who would probably struggle to spell ebXML, let alone
>have any meaningful knowledge about it.
>
>I am now mentally preparing for an onslaught of email pointing out the 1001
>documents/articles that EVERYONE knows about but I've somehow managed to
>miss :-)
>
>Regards,
>Mark
>
>-----Original Message-----
>From: Adrian Robinson [mailto:adrian.robinson@genie.co.uk]
>Sent: Wednesday, June 19, 2002 6:32 PM
>To: ebxml-dev
>Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
>
>Me too!
>
>I have a growing number of clients that have all heard of ebXML but assume
>that it is a data structure standard and are more than happy to implement
>it - until I explain that this part of the project hasn't even got off the
>ground yet. The next question I get is "So what is it?".  If I had a paper
>that I could pass on to these business minds, the least it would do is
>sustain their interest.
>
>By the way, does anyone know when we will see something of the data
>structure standards - if at all?
>
>Thanks in advance,
>Adrian.
>
>-----Original Message-----
>From: Dieter E. Jenz [mailto:dejenz@jenzundpartner.de]
>Sent: 19 June 2002 08:59
>To: ebxml-dev
>Subject: Re: [ebxml-dev] gorilla hair vs. beach balls
>
>I wholeheartedly agree. In my view, there is a definitive need for a
>paper targeted at business people. A requirements document is just not
>enough, since, among other things, it doesn't speak business people's
>language. For example, I cannot see what a manager of a Chamber of
>Commerce & Trade or an industry consortium, who would be ideally suited
>to relay the message to numeous business people, could gain from a
>requirements document or a technical architecture document.
>
>Business collaboration is a strategic issue and has to do with aligning
>IT with business. Therefore, a paper needs to unfold how ebXML fits in
>with the business environment and talk about a clear-cut ROI proposition.
>
>To me, the biggest obstacle at this time seems to be that few business
>people seem to know about ebXML at all. This, at least, is my experience
>from talking to business people. While commercial software vendors are
>committed to spending two or three times more money for marketing &
>sales than for R&D, the ebXML marketing effort seems to be minimal.
>
>Regards,
>Dieter
>--
>Dieter E. Jenz
>Jenz & Partner GmbH
>Hainstr. 40a
>63526 Erlensee, Germany
>Phone: +49-6183-9100-11
>Email: dejenz@jenzundpartner.de
>http://www.jenzundpartner.de
>http://www.bpiresearch.com
>
>Martin W Sachs wrote:
>
>  > Jacques,
>  >
>  > I think that the point is that you need different words and especially
>  > different styles of presentation to business people and to developers.
>  > Right now, all we have in the way of overall descriptions of ebXML are
>  > the Requirements document and the ebXML Architecture document. Both of
>  > those speak to members of the ebXML teams but are good neither for
>  > business people nor for developers.
>  >
>  > Regards, Marty
>*********
>  > Martin W. Sachs
>  > IBM T. J. Watson Research Center
>  > P. O. B. 704
>  > Yorktown Hts, NY 10598
>  > 914-784-7287; IBM tie line 863-7287
>  > Notes address: Martin W Sachs/Watson/IBM
>  > Internet address: mwsachs @ us.ibm.com
>  >
>*********
>  > Jean-Jacques Dubray <jjd@eigner.com>
>  >  06/18/2002 12:21 AM
>  > To: "'Adam Sroka'" <AdamS@rewardsplus.com>, ebtwg-bcp@lists.ebtwg.org, 
> <ebxml-dev@lists.ebxml.org>
>  >
>  > 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-----*
>  > From:* Adam Sroka [mailto:AdamS@rewardsplus.com] *
>  > Sent:* Monday, June 17, 2002 3:59 PM*
>  > To:* ebXML-dev List (E-mail)*
>  > Subject:* RE: [ebxml-dev] gorilla hair vs. beach balls
>  >
>  > 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 cliche "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
>
>>From:* Jean-Jacques Dubray [mailto:jjd@eigner.com]*
>>Sent:* 17 June, 2002 15:44*
>>To:* 'Adam Sroka'; 'ebXML List (E-mail)'; 'ebXML-dev List (E-mail)'*
>>Subject:* RE: [ebxml-dev] gorilla hair vs. beach balls
>>
>>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-----*
>>From:* Adam Sroka [mailto:AdamS@rewardsplus.com] *
>>Sent:* Monday, June 17, 2002 3:23 PM*
>>To:* ebXML List (E-mail); ebXML-dev List (E-mail)*
>>Subject:* RE: [ebxml-dev] gorilla hair vs. beach balls
>>
>>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, Adam
>>
>>  -----Original Message-----
>>From: Beach, Scott [_mailto:Scott.Beach@goodrich.com_]
>>Sent: 14 June, 2002 13:25
>>To: 'colin adam'; 'Duane Nickull'; 'Jean-Jacques Dubray'
>>Cc: 'ebxml org'; 'ebtwg-bps@lists.ebtwg.org'
>>Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
>>The crux of the issue... IT managers "think" they understand the concept 
>>of web services (whether true or not). Major mainstream vendors are 
>>pushing web services(IBM,BEA,Microsoft, etc) as the future of web 
>>interactions, not ebXML (not that the two play exactly the same role 
>>anyway). I've yet to see anyone capable of explaining ebXML to an IT 
>>executive without taking an hour and taking the conversation to such a 
>>technical level that the executive becomes lost in the details and stops 
>>caring. Does ebXML "define" more than web services? Absolutely. Does this 
>>make it easier to sell as a concept? Absolutely not.
>>
>>ebXML simply lacks an "elevator speech" that is compelling to IT 
>>executives.  Web services doesn't suffer from this same marketing 
>>paralysis. Another case where better technologically doesn't correlate to 
>>more successful.