--- 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." > 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). > > 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? -Rob
