Thursday, October 26, 2006

Technologists to shoot...

Thanks to Gervas Douglas and the yahoo list I've got a cracking example of the sort of thing I mean....

According to Forrester, an ESB typically includes communication
infrastructure; request routing and version resolution (mediation);
transformation and mapping; service orchestration, aggregating and
process management; transformation management; security; quality of
service; service registry and metadata management; extensibility for
message enrichment; monitoring and management; and support for the
service life cycle.
Oh god, how complex do you want one product to be?

But by far the biggest change in the ESB market, he said, is "you find
more and more larger vendors adding either a standalone ESB, like IBM
and BEA, or including those features in basic integration suites, like
Tibco and WebMethods and Oracle. Over time, I believe standalone ESBs
will gradually be consumed by the larger vendors and become more basic
infrastructure technology," Vollmer said.
Genius, this doesn't actually make any sense at all. Standalone ESBs (as produced by IBM/BEA) will gradually be consumed by the larger vendors. What the hell does that mean, he has just said that the larger vendors actually are either choosing to a) consider ESB as a lightweight platform to link things or b) are lobbing stuff onto existing products. I have three issues with this

1) Oracle's ESB is miles more like IBM/BEA than it is Tibco/Webmethods... and I'd bet more on them going for that model in future
2) The consumed line makes no sense
3) How on earth can the ESB with its millions of features he described before ever become a "basic" infrastructure technology.

This is exactly the sort of thing I was ranting about in the last post. The whole article is purely about how technologies will "solve" problems and move you towards SOA, and there isn't even a consistent line about what the technology is.

Technologies won't solve those old problems. If SOA is just about building applications in the same old way using Unicode based transport mechanisms then we've regressed. If its about using EAI type tools, then we've regressed.

Not one of these people actually suggested that SOA was about altering the way you think about systems. It read exactly like a bunch of people arguing that C++, Java, Smalltalk, Eifflel, UML, BON, Schloer-Mellor et al were the "way to do OO" rather than OO actually being about a shift in the way people think about designing systems. SOA works a level above OO in that it is about the architecture of multiple as well as single systems, but still the line is pushed that buying this technology will solve the problems created by the one they sold you last year.

Technorati Tags: ,

5 comments:

Anonymous said...

I see people are still confused about what SOA is. My experience tells me that this is doomed, or doesn't belong in technology forums.

I have said this many times if its not technology related why is this not in the business transformation area?

Steve Jones said...

Its an interesting idea about SOA in business transformation. But I'd argue it still needs to be mainly in IT right now as IT doesn't look like the business. So IT can't really support transformation as its one of the problems and issues, not the driver for change.

Once IT looks and operates like the business its then time to ask whether SOA can be used more radically.

Anonymous said...

http://www.theregister.co.uk/2006/11/02/accenture_wins_olympic_contract/

Interesting to see how they try to apply SOA here?

Anonymous said...

Same way as they did with the NHS and Sainsbury.

How does that presentation go "So how did your last major goverment contract go?"... "Oh it was a complete disaster"...."No worries here is a new contract, we're sure you'll do better this time"

Anonymous said...

Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore