A common theme in Science Fiction writing is the idea that in the
future, goods will have obsolescence built-in. That is to say, they will
be designed to self-destruct after a period of time. Clothes, cars,
household goods, all will have perishability designed into them in the
interests of future sales.

This theme used to be part of my nightmare vision of the future which
involves a blend of Gattaca[1], Brave New World[2], 1984[3],
Neuromancer[4] and Ned Flanders[5].

Unfortunately, those of us knee deep in IT do not have to wait for the
future to come around to see built-in obsolescence in action. It is
rampant, all around us.

The machine I am writing this article on was top of the range when I got
it a year ago but is looking obsolete already. Mind you, I spend my life
in Emacs[6] so I'm largely immune to the charms of the
latest-and-greatest when it comes to 'go faster' stripes and colorful
gadgets. I'm unusual in this regard though.

Some systems I built last year are already showing signs of age in terms
of that old chestnut 'state of the art' hardware and software. Old
operating system versions, old JDKs, old DLLs, old interfaces, memory
measured in mere megabytes - you know the drill.

It could be argued, that the humming noise in the background here, is
just the relentless drone of technological progress. That would be a
charitable reading of the situation in my opinion. We live in a world
where software products are rushed out to the market half cooked, only
to be replaced again and again by upgrades. Are these upgrades the
result of technological progress or simply a commonly used commercial
tactic to get 'em early and churn 'em regularly? Is the noise you hear,
the noise of a churn constantly rotating? Built-in obsolescence anyone?

Speaking of churn, let's take a look at Web Services. A business-level
definition of a Web Service is hard to come by, what does that tell you?
Being a part-time grisly old cynic, I have an uncharitable
interpretation of that lack of definition. Yes, it does feature words
like 'churn' and phrases like 'half cooked'.

But wait! It's spring, the daffodils are blooming[7]. The ambient
temperature is rising and wild trout are jumping in the streams. There
is a non-churn interpretation of Web Services which is, in my opinion,
the real value proposition that lies before us.

The big leap required for Web Services to be worth it - to be a
worthwhile revolution rather than yet another IT churn - cannot be made
by technologists. If it happens at all, it will be made to happen by
business people.

Here is my reading of the situation. The current culture of application
design and integration leans heavily towards creating tightly integrated
information silos protected by garrisons of heavily fortified defenses
known as 'APIs'. As I've written before in this column, tight
integration sounds appealing but it is, from a business perspective, a
bad thing[8].

Now, what do Web Services have to offer here? What benefit does using a
Web Services 'API' have over an RMI interface or a CORBA interface or a
COM interface? Very little in my opinion. Do you hear a droning noise in
the background here?

I see signs however, that the culture of application design and
integration is changing. Changing towards an appreciation of the
negatives inherent in information-silo based architectures.

Which brings us to the real value proposition of Web Services according
to my reading of the situation. Properly applied, Web Services are the
vehicle through which the current silo-based approach to application
design and integration can be fundamentally revisited. It involves
focusing application design and integration on the data that flows
between processes - not on the processes themselves. It involves
modelling data in an application neutral fashion using XML technologies
and getting that data flowing around your systems. It involves
businesses taking control over their own data and using technology to
transform the data over time - but not allowing technology to *own* that
information.

Mind you, the part-time cynic in me feels compelled to point out that
what we are talking about here is essentially the data-flow based
approach to application design and integration advocated by many in the
Seventies. Less cynically, it can be argued that we did not have XML in
the Seventies to describe the data in dataflows. We also did not have
ubiquitous inter-connectivity. Now that we have both, I think it is time
for data flow to take its rightful place at the heart of how businesses
think about IT and think about systems. That is what Web Services are
all about. A new way of looking at things - not a coat of paint on an
existing model.

It is early days yet in the Web Services world and it could still go
either way. It could descend into a noisy IT churn fueled by hype and
irrational expectations. Or it could be the beginnings of something
really big.

On the negative side, we have SOAP RPC and UDDI both of which point to a
very strong API-think in Web Services. On the positive side, REST[9] and
and doc/literal style[10] Web Services point to a more temporally
decoupled, business-process-centric future.

I will leave you this week with a joke that illustrates the risks
inherent in treating a new technology (Web Services) as an old
technology revisited (RPC).

A lumberjack walks into a hardware shop and explains that his manual saw
method limits him to felling four trees a day. He expresses an interest
in one of those new chain-saws he has heard so much about and read about
in the trade magazines.

The shop sells a chain-saw to the delighted lumberjack and promises him
a five-fold increase in productivity. A week later, a very tired looking
lumberjack comes back into the shop looking for his money back. He
claims that with the chain-saw, he cannot fell more than six trees a
day.

The shop assistant takes the chain-saw and starts it up to examine it.

The lumberjack steps back in amazement and exclaims:
"What's that noise?"

Sometimes, the real value in a new technology lies in looking at things
differently. Bear this in mind the next time you hear a developer waxing
lyrical about the benefits of putting a web services wrapper on an
existing application or on an existing integration architecture.

[1] http://www.gattaca.com/
[2] http://www.huxley.net/
[3] http://www.online-literature.com/orwell/1984/
[4] http://www.williamgibsonbooks.com/books/neuromancer.asp
[5] http://www.snpp.com/guides/flanders.file.html
[6] http://www.linuxnetmag.com/share/issue8/avfs-emacs.jpg
[7]
http://seanmcgrath.blogspot.com/2003_03_23_seanmcgrath_archive.html#2000...
[8] http://www.itworld.com/nl/ebiz_ent/02042003/
[9] http://internet.conveyor.com/RESTwiki/moin.cgi/
[10] http://www.infoworld.com/article/02/06/07/020610feappdevtci_1.html

» posted by ITworld staff

ITworld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine