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 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 (What was I thinking?). This experience, working for a software company, was an eye-opener.
Candidly speaking again, some 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 little to do with understanding their customer’s business problems, risks, and culture. They spin, position and reposition in a market of smoke-and-mirrors happy to sell you a gold disk of “the-answers-to-all-your-problems.” Then, they leave you the gold disk, and your business problem, as they drive away, looking at your business 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, architectural nor implementation 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 practical real-world, whereas social-networking and other grass-roots user-driven technologies, most without trendy jargon, has left SOA in the dust for the past few years?