2008/12/23 Rob Eamon <[email protected]>: > --- In [email protected], "Steve Jones" > <jones.ste...@...> wrote: >> >> >> I'd go for the products and their marketing. The reality is that a >> lot (maybe all) of the old EAI products have just been rebadged as >> SOA without any actual though as to "services" except of course in >> the marketing which is all about services. > > Undoubtedly there are companies and sales folk that don't quite > understand. > >> I remember in about 2004 when a CIO said to a colleague "why would >> I buy these old EAI tools to do SOA, they just don't get it" but >> from 2004+ they've focused their marketing in a way that pretends >> that they do. > > Why would the CIO be worried about "old EAI" when SOA is something > you do, not something you buy? By the time one is looking at tools, > one should have a very good grasp of what the tools need to do. > Dismissing a toolset as "old EAI" seems to belie a leaning towards "I > can buy SOA."
Nope, it was leaning towards "This crap didn't help before and it won't help now" which was backed by a series of failed EAI programmes that the company had done. In 2007 I was working within an IT estate where the 1999 EAI product was the biggest integration challenge. > >> I used a lot of the integration products back when I used to "think" >> SOA but have to deliver EAI and it was a pain, they were just doc >> shifting with the most convoluted and painful process/transformation >> parts which regularly failed to work as advertised. > > Certainly, some tools didn't do the trick. I remember working with an > early version of ActiveWorks that much like what you experienced-- > painful process/transformation efforts. > > A couple years later, Active was bought by wM--and that toolset was > much better (and still quite useful/popular today). I'll take the fifth on individual vendors ;) Some tools have improved, but how many are actually service to service integration (i.e. consumer to provider) rather than queue to queue or single end-point to single end-point? How often can I model a service interface and then attach to the service the various different integration pipelines? In a standards based world (something that has come along with SOA) then you should do transformation at the edge (which the license agreements prevent you from doing) then do mediation in the network (which the licensing again prevents you from federating). You should also have a LIMITED set of facilities in the mesh to prevent people doing dumb things, instead of which the EAI tools remain as application platforms in their own right and business logic bleeds into them. > >> >> EAI was conceptually (IMO) one of the worst considered movements >> that IT has ever had. > > I think EAI in and of itself was fine (and still is, though I eschew > its use just as I eschew the use of the SOA term--too much baggage). > But it suffered greatly from overhype, the notion of "buying an > architecture", and too much being done in the middle. It was those > experiences that lead us to SOA, no? How to do EAI right? EAI was worse than hype it was a fundamentally dunderheaded technology only approach. Steve > > -Rob > >
