Re: [ebxml-mktg] ebXML name

[Stephen McConnell <mcconnell@osm.net>]

I am seeing good recognition of the ebXML brand amongst the investment and
technical communities - no need to change names. I agree strongly with the
suggestion below concerning profile branding - something that facilitate
presentation and perception of the value proposition. My option is that ebXML
is suffering in terms or organizational identity - the ownership of ebXML
is not what it was - or more correctly the perception of what ebXML is in
terms of a organization entity, structure and political backing has lost
substantial ground over the past nine months - that is damaging and that
should be the topic - how to rebuild the confidence in the analyst, investment
and customer communities in the organization integrity and its ability to
deliver.

Cheers, Steve.


ARIJIT.SENGUPTA wrote:

This is really interesting. Daniel, were you there at Barcelona? The ebXML JCC discussed this exact issue and came up with the following:

1. The ebXML spec names should not change as that would be confusing and lose quite a bit of brand value

2. The versions of the combination of specs and necessary infrastructure should be published as a profile. For example Profile 1 could be CPPA 2.0, Messaging 2.0, BPSS a, RegRep b, SOAP c, WSDL d, etc. This combination of interoperable specs could be used to create mission critical, industrial strength WebServices.

3. This profile could be branded as something along the lines of Business WS, Collaborative WS, ebWS, or anything else the marketing team come up with.

I think this would address your concerns adequately. I too have faced the perception problem of "ebXML must be yet another XML payload like cXML because it has XML!" This is stupid, but it is rampant.

Please let me know what you think. And please feel free to suggest names for this profile. I really like ebMS best at this point. What do others think? I would like to resolve this branding issue before we start doing outbound communications through Analyst briefings, journal articles, etc. Regards,

Apu

---

I believe ebXML's public perception problems begin with its name. Those
wishing ebXML well need to realize that it is never too late to change it.
I would suggest something along the lines of WS-Business - that would be the
name of the framework. WS-Commerce can be used to refer to some subset of
ebXML specs. The individual ebXML deliverables would then be called
something like WS-Business Repository, WS-Business Processes, WS-Business
Communications, WS-Business Agreements, WS-Business Language, etc.

My particular choice of WS-Business vs ebXML stems from the thinking -
whether appropriate or not - that e-business (at the core of ebXML) is an
irrelevant concept, since there is nothing special from a business
perspective about business processes that rely on computers and network
transport rather than on people and fax machines. The WS prefix indicates
affinity to Web services technologies, which, following W3C's definition,
implies only a reliance on XML, which is also the logic behind ebXML's
current name. "WS-" makes more obvious the complementary nature of ebXML to
Web services and everything else represented by the "WS-" moniker. From an
even more purely marketing-technical standpoint, whenever another
WS-Something spec comes out or whenever WS-I makes noise again, that might
translate into some publicity for ebXML. Finally the more popular Microsoft
makes its "WS-" efforts (7 at last count, so there is much potential there),
the more receptive Microsoft's audience is going to be to ebXML.

In terms of making the transition go smoothly, perhaps the new name could be
applied to the suite of approved 2.0 specs. That would reflect the growing
maturity of the framework, minimize the negative impact of the name change,
and justify any required incompatibilities with previous spec versions.

Daniel

---

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net