The Subprime Crisis and the Impact on the CEP Market

Last quarter TIBCO Software missed earnings after an earlier warning.  Among other things, the Q3 2007 earnings teleconference highlighted dissappointing sales in the financial services sector.

Experience has demonstrated,  time and time again, when a sector is underperforming and cutting costs, one of the first line items in the budget to dramatically decrease is information technology (IT) expenditures.   This is also true in financial services.

The subprime meltdown which caused E*Trade’s stock to drop nearly 60 percent this week is, and continues to, dramatically impact the financial services industry (FSI). 

In turn, this impact will almost certainly adversely effect IT expenditures and new technology investments, such as complex event processing solutions and similar projects, in FSI.

StreamBase has shown some business savvy by focusing on the on-line gaming industry this year.   

This is a good time for all software vendors, including CEP vendors, to diversify their sales strategy on a wide variety of markets.  I recommend looking at a variety of sectors,  not only FSI; for example, manufacturing, supply chain, retail (consumer services), and telecommunications. 

Event Processing Languages and the Nonsense about SQL

Louis Lovas, a distinguished Progress Fellow, and one of the event processing  implementation gurus at Apama has been doing a fine job discussing and debating why SQL is suboptimal for many classes of event processing problems.  

His latest contribution to the community, Taking Aim, does a great job responding to a earlier rebuttal to his post on SQL and its suitability as an EPL for CEP.  I agree with Louis and look forward to his views on the usability and scaleability on graphical models, tools and visual design studios for designing complex event processing applications.

One of the problems, as I see it, is the misconception that CEP is a technology that will be dominated by database programmers in the future.    CEP is not intrinsically a database application architecture.   CEP is a solution architecture for solving complex problems in real-time where databases and similar transactional processes are a part of the overall solution, not the whole.

There are certainly many classes of CEP solutions where SQL and extended SQL can be effective.  On the other hand, there are dramatically more CEP applications where a more expressive, functional and modern language is appropriate.  After all, John Bates did not conceive and design a better language for event processing because he had nothing better to do at Cambridge University! 

OBTW, TIBCO Software, also known for being very innovative and technologically savvy, did not select SQL as their EPL either.

Most of us would never dream of using SQL for writing all possible permutations of event processing applications no more than we would use SQL for writing an event handler for the wonderful mouse we use for browsing the Internet everyday.

Then again, there are always folks that might argue we don’t need calculus because we have math; and we can, in theory, do calculus with only add, subtract, multiply and divide.  No wait!  We really don’t need multiply and divide, because we can multiply with addition and divide with substraction, so let’s toss out multiply and divide as well!

Some might even argue that we don’t need C, C++, or Java because we can write it all in assembly language.   (Actually, I have heard this argument more than once in the past – believe-it-or-not!)

Let jump to the bottom line.  It is simply nonsense, in my opinion, for anyone to argue, no matter how technical, detailed or pedantic, that SQL is the only processing language for all event processing applications.