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, Brave New World, 1984, Neuromancer and Ned Flanders.
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 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. 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.
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 and and doc/literal style 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.