April 29, 2003, 12:00 AM — 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.
