An article recently published in the Guardian [1] puts forth evidence
that brand names effect our brain in a different way than other words
and phrases. Brands appeal to out emotions apparently. Ah! So that is
why I cry when I read advertisements for the Ferrari Testarossa.
As much as I hate to admit it, I'm as prone to conditioning via brands
and marketing tactics as the next guy. Perhaps more so because I'm a
computer geek. Computer geeks are exposed to a lot of brands. Many of
the geek brands are subtle. They do not appear on prime time TV. They
may not actually seem like brands at first sight. Here is an example:
.doc
Large swathes of the personal computers on the planet contribute, on a
daily basis, to the maintenance of this brand -- Microsoft Word. Over
the years, the term ".doc" has become synonymous with Microsoft Word.
Other word processors have no option but to try to establish other
brands around less memorable file extension codes such as ".wp" or
".sxw".
Now of course there are those that argue that this is just a hangover
from the bad old days of DOS, which limited file extensions to three
letters. I think this risks missing the point. The point is that the
".doc" extension has conquered the word processing world. Microsoft Word
now owns that brand. It could have been ".wp", ".let", or any number of
others still within the historical three-letter extension restriction,
but one brand emerged victorious -- for now at any rate.
On the Web, file extensions are not so important. Sure we have ".html",
".css", and so on, but the file's MIME type [2] dictates how the file is
interpreted, not its extension. Well, that is the theory anyway. In
practice, three letter acronym wars break out on the Web from
time-to-time. For example, the W3C's XML schema language recommendation
is variously abbreviated to ".xsd", ".xs", and ".wxs". This fight is on
going right now with various parties going to great pains to point out
that it does not matter. Again, I think this risks missing the point.
Words matter. Three letter filename extensions really do matter. It is
part of the brand. One of these filename extensions will win out and a
brand will be established for W3C XML Schema.
Like it or not, the little acronyms and catch phrases we use really do
matter. Take SOAP for example. It is still a moving technological
target, much has changed since SOAP was first mooted -- indeed the "S"
no longer officially stands for "Simple". So much has changed underfoot,
yet SOAP is SOAP is SOAP. The brand remains unblemished. "Just use
SOAP", say the geeks -- a marketing persons dream!
Here is another brand in the making:
Web Services
Hmmmm. The phrase sure trips off the tongue. Google produces over 2
million hits. But is it a brand?
Not yet. It is a brand in waiting, hence the mindshare wars going on
right now out there. The phrase "Web Services" is probably the most
valuable potential brand since ".doc" (Imagine owning the thought
processes that went into the utterance "Just use Web Services"). This
could be the most valuable technology brand ever. A prize worth fighting
for....
Where there is a prize worth fighting for, the fighting will get dirty.
One useful tactic incumbents can utilize while figuring out a strategy
for claiming the prize is to spread confusion. I believe this is a
reasonable assessment of what is going on right now in the Web Services
arena. Confusion, spread thickly and wantonly by a bunch of Titans
gaining time for the back room strategists to work out what is going on.
Confusion reigns. So too does the malaise I call PME -- Premature
Mereological Exactitute. Anybody who is watching this space with any
degree of interest knows that there is a lot going on in the Web
Services world. A lot more than the component acronyms -- SOAP, WSDL,
and UDDI -- would lead you to believe. Yet, because the Web Services
brand is so embryonic at the moment, because confusion and hype is rife,
PME has set it. The result is that these three acronyms are repeated in
chorus over and over again. As if they collectively define the space. As
if they form some cohesive, meaningful whole.
Faced with a confusing vista of acronyms, whispers of an impending
"fundamental shift in computing" and a feeling that the whole thing is
rather undercooked, what do bewildered geeks do?
They stick with what they know best -- another brand:
objects
Ah, objects! I understand objects! Objects and I go waaaay back. An
object is the result of thirty or so years of development in which the
Object Oriented approach to software has risen to a position of
dominance. A brand. A sort of ".doc" for programmers.
Whilst struggling to wrap their heads around Web Services, developers
interpret the emerging brand in terms of one they already know: objects.
The unfortunate result of this understandable maneuver is the
positioning of Web Services as an object technology. Or, to put it
bluntly, a really bad implementation of CORBA. A technology for creating
distributed, Object Oriented, systems.
Right now, all over the world, there are developers treating Web
Services technology as a distributed object technology. The result
(apart from a scandalous waste of processing power and bandwidth) is an
XML based, damp squib. Ask these developers for examples of what they
can envisage doing with Web Services and you risk getting back clichéd
examples of stock quote and weather forecasting applications. Is that
really what Web Services is all about?
That is the bad news. Now the good news. I firmly believe that Web
Services will be the brand name associated with the next generation of
distributed application development. Furthermore, I believe it
represents one of those fundamental shifts in computing that comes along
every decade or so.
But -- and this is the important point -- Web Services will *not* be
about distributed objects in my opinion. It will not entail publishing
detailed information about how my objects can talk to your objects -
interfaces. We have been there and done that and many of us bought the
expensive tee shirts. It was called CORBA. Furthermore, CORBA was a
darned sight better at doing distributed objects that what we currently
have in the Web Services arena (namely the anaemic, PME-induced
triumvirate of SOAP, WSDL and UDDI).
The critical shift in Web Services, I believe, is towards a loosely
coupled, document-centric approach to distributed application
development. A model based on flowing real data - not function calls
through nodes of functionality. These nodes change the data from one
state to another. XML (naturally) goes in, XML comes out. The difference
between the structure and content of the XML fed in, and the XML fed
out, constitutes the functionality of the Web Service.
The key choreographing paradigm will be how data changes shape with
respect to *time* - not how one object calls another. Somebody once said
that a data structure is a business process slowed down. Whoever it was
got it spot on.
The irony behind the emergence of this trend (if I'm right of course)
will not be lost on those old enough to remember that before "objects"
became the brand on everyone's lips, we had something called "dataflow"
and a powerful three-letter acronym to go with it:
.dfd [3]
Data Flow Diagramming -- a paradigm for software development based on
how data changes state with respect to time. A paradigm from the
Seventies no less. Well, XML's daddy, SGML, came from a similar era and
look what happened to it!
"Just use DFD (a web service dataflow model)." - another brand in the
making?
NOTES
[1]
http://media.guardian.co.uk/marketingandpr/story/0,7494,773943,00.html
[2] http://www.ufaq.org/navcom/mime_tutorial.html
[3] http://roger.babson.edu/osborn/doit/readings/dfddiag.htm
