[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-mktg] [user friendly write-ups] (was) fwd: gorilla hair vs.beach balls
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 <email@example.com> > >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:firstname.lastname@example.org] >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:email@example.com] >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: firstname.lastname@example.org >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 <email@example.com> > > 06/18/2002 12:21 AM > > To: "'Adam Sroka'" <AdamS@rewardsplus.com>, firstname.lastname@example.org, > <email@example.com> > > > > 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:firstname.lastname@example.org]* >>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'; 'email@example.com' >>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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC