First of all, let’s ground the discussion a bit by translating “smart order routing” to “rule-based message routing” since in this application “smart”  translates to “using rules” and “order” translates to “message”.    Basically, Mark (and other “new on the routing scene” stream processing players) argue that rule-based message routing is CEP.  I will argue that routing is not even close to CEP.  Here is why,

Let’s take a look at a router on the backbone of the global Internet.   A backbone router has very sophisticated software developed over many decades.   These routers run sophisticated, mature algorithms to determine how to route messages (packets) and use these algorithms to build complex routing tables. 

In addition, these routers process messages (packets) from countless sources and route messages (packets) to countless destinations.  Using some of the terms in early posts (above), there is a great “confluence of events” processed by routers.    Futhermore, there are normally quite complex authentication, authorization and other security parameters managed in a router, all in real time.   Routers do much more, but I don’t want to get too deep into routing in this post.

My point is that, without any doubt, global Internet routers process very “cloudy” “confluence of events” with much more sophistication than order routing applications.    However, we do not call Internet routing “CEP”, regardless of how many connections are processed or how much sophisticated processing occurs.  The reason is because the “C” in “CEP” defines a complexity that is at a higher abstraction than messaging and routing.

If you study the literature on CEP, some of which I posted recently, CEP was envisioned to solve complex event processing problems “on top of the routing layer” because the routing layer is a mature technology layer.  We can route, pure and simple.  Of course, we are always seeking faster, more scaleable and more secure routing. 

I admire some of the startups in the CEP/ESP/EP space for working hard to make money and for aggressively positioning their products and attempting to build market share.   However, issues surface when these same companies seem to believe they are the first companies to work in the event processing or message routing space and that they can define whatever they want as “complex event processing” as long as it benefits their sales targets.

There is no doubt that a router does much more sophisticated event processing than the new rule-based stream processing systems running continuous queries across streaming data.  There is no doubt that a router processes a complex “confluence of events”.   However, we don’t call routers “CEP”. 

We do not call routers “CEP” because CEP is about a higher level of knowledge processing.  CEP was created to detect the “complex events” that happen above the mediation and routing layer.     The literature and original examples on CEP are quite clear on this.

I agree with Mark that SOR is important and very interesting; but in his reply he seems to be confusing CEP with “complex EAI” or a “complex messaging” application.  For example, Mark says,

“It’s not uncommon for a single SOR system to connect to 10 or more markets and multiple asset classes.  Not only is this a confluence of events, it’s a stunningly complicated environment in which to create a complex, real-time model in which to apply “simple” routing decisions. On this basis alone, SOR needs CEP.”

Connecting to many market feeds with multiple asset classes might be complicated, but “complicated connections” are an EAI  (adaptation layer) function, not a core CEP function.   In fact, TIBCO Software has been doing this type of low latency back-office order routing for many years, and TIBCO historically calls this “messaging.”  Adding some rules to high speed, low latency messaging does not make it a “CEP” application.

Mark goes on to set up a counter argument to ILOG’s Changhai Ke, comments with,

“SOR operates by analyzing the confluence of events from market data feeds, order flows from OMS systems, and executions, aggregating and analyzing those events in real time, and adjust routing decisions on the fly.”

This is the well travelled argument the “new stream processing vendors in capital markets” have been saying, still unconvincingly, for the last few years.  Basically their perspective is that if you have a lot of ”feeds” and a core requirement for “speed” - “feeds and speed” - you are doing “complex event processing.” 

Mark Palmer forcefully stated his opinon that the folks who do not agree with him do not “understand” modern day SOR.    However,  a strong counter argument can be made that the “newcomers” to capital markets like StreamBase do not understand that “feeds and speeds” with order routing is little more than moderan day EAI.   This is a basic message routing capability and it has been around for a long time.  After all, Wall Street operated quite well before the term CEP was coined!  TIBCO technology was providing Wall Street back office, low latency, smart order routing a decade ago, and they called this technology “messaging”.  

So, I remain unconvinced, at least by Mark’s passionate counter post, that SOR is CEP.   SOR, as Mark and other have described it, is a low latency messaging technology.  Message routing rules have exisited in this technology space for decades.

I agree with Mark completely that low latency EAI (like SOR has been described) can be quite complex, from a “feeds and speeds” perspective.   However,  I remain skeptical that “feeds and speeds” is much more than  modern day messaging and message routing.

In closing, in the network and security management world we have been dealing with “myriad feeds and speeds” for as long as I can remember, but admitted not like capital markets.    Taking myriad feeds, running rules against the feeds and then routing the messages/events for further processing, regardless of the complexity of the feeds and the data, is actually more of a messaging/ESB technology than a CEP technology. 

I remain completely open minded to any convincing counter arguments.

Jeff uses the example, “Smart Order Routing” as an example of taking an event and routing the resulting market order match based on some simple rules.    Routing a order kicked off by a simple order match against a deep liquidity pool (or other market factor) does not define complex event processing nor detecting a complex event - the core idea behind CEP.   Order routing based on simple rules is BPM, plain and simple.

Let’s take another example, fraud.  In this example, there is some complex neural network monitoring for credit card fraud and a potential fraud is detected - this is CEP, detecting a complex event based on some sophisticated analytics.   

After a possible fraud has been detected, a process looks into a database and the routes the incident to someone in the company who is a (1) specialist in credit card fraud, (2) working at the same time of the discovered threat, and (3) immediately available to act on this type of task.   Routing the incident is not CEP, it is BPM.

Jeff makes the argument that it is OK to call an event-driven BPM task CEP because “it fits the EPTS definition” in the CEP glossary.   He also avoids the discussion of detection accuracy, and instead insists that latency is a ”very important” factor in a CEP application.

If you read the various post by vendors in the blog-o-sphere, it is obvious that they are continually defining CEP as BAM, BPM, BRE, BRMS, SOA and just about every other related processing activity that is complimentary to the event correlation and analysis required to detect an opportunity or threat to your business.

I’m not picking on Aleri.  TIBCO has been doing the same thing recently in their CEP blog, continually attempting to redefine CEP as BRMS.    Detecting business opportunities and threats with high confidence requires sophisticated analytics, and their tools have not yet evolved to “real CEP” capabilities.  Instead, vendors are attempting to redefine BPM, BRMS, BRE, and even SOA to some degree, as CEP. 

CEP is Not BPM, BAM, BRE, BRMS or SOA.

At the moment, event correlation and event analysis is Gartner’s closest magic quadrant (MQ)  that relates directly to complex event processing (and event processing in general).    

A number of our friends and colleagues would like to position CEP as BRE, BRMS, BPM, SOA, algo trading and just about every other technology under the sun, except event correlation!

In a nutshell, the state-of-the-state of CEP/EP is that a number of firms in the software industry have found some “uncharted magic quadrant waters” and are positioning themselves to be “chart worthy”. Instead of competing head on with the experienced players (event correlation and analysis) that have been in the event processing field for many years.   

As I have mentioned a few times here on The CEP Blog, if the current generation self-described CEP engines were leading the industry in event correlation and analysis (CEP’s core technology domain) they would be either be on Gartner’s Magic Quadrant for IT Event Correlation and Analysis, or possibly acquired by a one of these large giants in event processing to solve complex event processing and event correlation problems that remain, for the most part, still unsolved!

I’ve heard the buzzwords but wasn’t exactly sure what they meant–luckily, when there’s media hype, there are definitions, too. According to this article, cloud computing is exemplified by Software as a Service — outsourced, hosted platforms and software that perform services for companies.

Another article puts it slightly differently:

OK, let us look at what form of computing in being provided via the cloud. In this model, all IT applications and facilities (i.e. compute, storage and network) are provided as a service rather than dedicated infrastructure. This is intended to allow any user, independent of client platform, to access IT services without knowledge or concern of their location or form. Sound familiar — it’s a service-oriented architecture (SOA)!

In addition, cloud computing incorporates almost every computing manifestation within the IT world: distributed, grid, utility, on-demand, open-source, Web services, P2P, Web 2.0 and, last but not least, software as a service.

It also accommodates thin, thick and mobile clients and allows integration of corporate, commercial and service provider cloud-accessed resources. As an example, in this model, storage is a service resource that is accessed via the cloud, not a dedicated user resource.

Honestly I read that last one first and found the definition a bit dense. It sounds like a summation of everything that makes up our Internet infrastructure already, so how is that different than the Internet itself? Well, cloud computing isn’t about what service or devices are being supported — it’s more about how it’s being provided– it is a location-independent style of computing. The first article calls it “platform as a service.”

Have you heard better definitions of what cloud computing is and does? Share them in the comments below. Thanks!