Complex Event Processing RSS News

Tim Bass
Sun, 20 Jan 2008 06:30:30 +0000

Dear friend Opher Etzion responds to my post Betting on the SOA*Horse*with a*discussion on how SOA, EDA and CEP are technically orthogonal, concluding:

“Event Processing can have different interactions with SOA, and when IBM’s announcements in this area will be available you’ll realize that there are different entry points. Event processing can also work in legacy and non-SOA environment.”

Richard Veryard, who also kindly reads*my*blog*(and Opher’s blog) replies with Technological Perfecta*where he*opines,

*”I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies.”

Opher, Richard, you guys are technically right, but you are blogging orthogonally to the message in Betting on the SOA*Horse.
First of all, my post was not a technical discussion, it was a discussion about business, marketing, timing positioning*and the software industry in general.** Therefore, it is a bit humorously orthogonal to reply to a marketing metaphor about investments, competition, software postioning and horse racing with architectual posts about technology and how they are related or interdependent.
In a nutshell, here is why….
Candidly speaking, despite what*many analysts want you to believe, end users rarely*build “SOAs” “EDAs” or CEPs”.*** End users have IT budgets to*solve business problems with the most cost effective technology they can find; and they do not care*(if they have a clue)*what cute three letter acronyms*have been*created by analysts*to describe momentum in the software market.** Sorry, it is true really.
For example, I remember when I was in Tokyo where the very capable and conservatively risk adverse Japanese executives told me time and time again, “We don’t care about SOA we simply want to integrate our systems.”** They were quick to remind me, “You guys in*America must realize we don’t care what the western analysts, supported by software companies, say.* They have a conflict-of-interest anyway and they are not end users.* What we care about are mature technologies with solid reference clients and proven implementations.”
By the way, this is one reason I admire Japanese business so much.** They are not impressed with handwaving hyperbole.** They just want to see results.* In other words,** “Prove it, don’t just say it.”** The devil is in the details, as they say.* The Japanese are highly skillful at cutting through the smoke-and-mirrors.** I think this is one reason the Japanese are among the leaders in so many industry sectors, but that is a blog story for another day.
To this point, if you are in front of customers and you are pushing SOA because your software company has “bet the farm” on positioning themselves as an SOA company, you are making a mistake.* Three letter acronyms* and technology jargon do not solve business problems.* In fact, for the most part, they are a red-herring.* The same is true of EDA and CEP.* This was the main message in my post Betting on the SOA*Horse.
How*do I make such a statement?
Because for over 20 years I*have worked*as a*consultant working on the opposite side of the table*of hungry*software vendors who come into our house (organization) tossing out buzzwords, acronyms, and jargon.** My job was solving real*business problems, not selling software. * We*used to wonder*when*all the scrabble and babble*the software companies were tossing at us*was going to turn into a business language that solves a real business problems easily, rapidly and economically.** That day never came.
Then, I made a conscious decision to take a break from a long career of consulting to get an insiders perspective on, and perhaps even transform,*the software industry.** This experience, working for a software company, was an eye-opener, and one I am most likely not to repeat.** I*have never been interested in selling softare.** I am interested in real business solutions.**
Candidly speaking again, many software companies*tend to live in “La*La Land”.**
They create go-to-market strategies based on jargon, buzzwords and three letter acronyms that have very little to do with understanding*their customer’s*business problems, risks,*and culture.***** They spin and position and reposition*in a land of*smoke-and-mirrors happy to sell you a gold disk of “the-answers-to-all-your-problems.”** They leave you the gold disk, and your*business problem,*as they drive*away, looking at you in the rear view mirror as they count the revenue from their victorious*campaign.**
These same companies bet on jargon like SOA, EDA, CEP, BAM* and they hedge their bets with different combinations of the above, the theme of my post*Betting on the SOA*Horse, which was not a technology* nor architectural discussion, in any way.
Is it any real wonder why SOA has become, for the most part,*complex, vendor-driven jargon barely making a dent in the real-world, whereas social-networking and other grass-roots user-driven technologies, most without trendy three letter acronyms, has left SOA in the dust for the past few years?



Source...