I recently suggested that David Luckham add latency as a measure of “power” in his strawman for features that CEP users are interested in. This generated some discussion, and the question as to whether I was asserting that all CEP applications require low latency, so I thought I’d share some observations.

When people look at the performance, in terms of speed and capacity, of a CEP platform, they are generally concerned with one or both of two dimensions: throughput and latency. Throughput is typically measured in messages per second, i.e.  how many incoming messages (events) per second can be processed without getting overloaded. Latency is the elapsed time between an event and a response. You could also call it the response time or reaction time.

Different applications have very different needs. Most care about throughput at some level, because they need to ensure that their application can keep up with the expected message rate. This can vary widely. One application might expect a few events a day, another might expect a few hundred thousand a second (the most extreme I’ve run across was a firm that was designing a system for a capacity of 15 million messages per second! yikes). So you care about throughput in so far as you need to have enough for your intended application. Beyond that, excess capacity is irrelevant other than to give you head room for growth.

The same is true for latency in that most applications will care about latency at some level, but expectations may vary widely. We see trading applications that are latency-sensitive to the level where every millisecond counts. We also see many BAM-type applications where the results are being displayed on a dashboard for consumption by a human user. In this case, the requirements might be for latency in the range of 150ms to a few seconds. Demanding latency of less than 150 ms in this context is pointless, since that’s below the range of human perception. In still other cases, a reaction time within the hour might be perfectly acceptable to the application - and yet it still might be an application that can benefit from CEP. At some level, however, you probably don’t need CEP. If you truly don’t care about latency - if it’s ok that your reponse comes hours, days or weeks after the fact, then you can probably accomplish what you want through conventional data analysis tools that run periodicall against historical event data. Sure, you could still use CEP, but if you aren’t trying to analyze  events in real-time, as they occur, there are other tools available. And the only reason to go to the trouble to analyze them as soon as they occur, is because you care about latency, even if your idea of acceptable latency differs from someone else by seconds or minutes.

Bottom line, I think the fact that some CEP technology can be used for those very demanding high performance applications that require very high throughput or very low latency sometimes distorts the discussion. The big numbers (or extremely little numbers in the case of ultra-low latency) get peoples attention, but they shouldn’t cause people to think that they only need CEP if they are building a high speed application. If there is a need to analyze and act on event data in real-time, then CEP can help, regardless of how fast the events arrive or how quickly you need to respond.

Finally, lest I create the wrong impression, performance is merely ONE feature of CEP that users care about. It is by no means the only one. In fact a lot of the time I think too much attenion gets focused on performance at the expense of other critical factors - the most fundamental one being: can it address the use case in question - at any speed? But that’s for another day.

There’s an interesting blog post by James Tayler over at eBizQ on Business Rules, Decisions and Events that talks about the role of CEP in decision management. I share James’ view that trying to compare and differentiate BPM from CEP is tricky and not worth the effort. So much of the problems and solutions end up being along a continuum with overlapping domains, that trying to draw black and white distinctions ends up being arbitrary. Can CEP technology be used in BPM applications? It often can. Do all BPM applications need CEP? Certainly not.

I think James gets to the essence of how we (and others) are applying CEP, which is to either enable or make better decisions. I like the smart order routing example for a couple of reasons - for one because it’s an example of how CEP is being used for things beyond situation detection - the type of use case that gets the most attention when it comes to CEP. Also because it draws from a lot of the different capabilities of CEP: analyzing events in the context of other events; watching for patterns of events (eg patterns that suggest hidden liquidity); correlation of events (comparing trade activity to order activity in the market); and doing all of this in real-time.

Traditional order routing in the securities market followed relatively simple rules. In fact it could be as simple as “if the order is an equity order for less than n shares, send it to x”. In today’s markets, orders are routed more intelligently, and there is a lot of interest in “smart order routing” which takes into account the state of the markets to make a decision on where to send the order. Now even here, there is a range of complexity that can be factored in. At the simplest level, a “smart” order routing application might simply look at the best bid and offer from multiple market venues, and pick the one with the best price. While some call this smart order routing, it really doesn’t take much in the way of smarts. Where it starts to get more interesting is when you factor in market depth - not just who has the best price, but where is the liquidity and where can you get the best overall price for the quantity you need to move? In fact Aleri’s Market Liquidity Analysis framework, which in implemented on the Aleri CEP platform, uses CEP to consolidate and analyze market liquidity in a fragmented market - where a common use case for the analysis is to intellegently route orders.  Then you can further ratchet up the complexity of the routing decision when you factor in dark liquidity, and use algorithms that look at things like refresh rates to estimate where there may be hidden liquidity and factor this into the routing decision. CEP is well suited to this since it’s all about analyzing events (in this case the order) in the context of other events (activity in the market) to make a decision (where  - and sometimes when - to send the order). It’s this type of real-time decision making where CEP can help, and thus smart order routing is just one of the applications in the capital markets where firms are turning to CEP. Is this a BPM application? I guess it is - though probably not in the conventional sense. But it’s certainly a case where CEP can deliver value in automating - and more importantly optimizing - a business process, where there is a level of complexity in the decision making that is required - in this case the need to take into account numerous external factors that are independent of the event requiring a response. Here CEP is deciding the appropriate response to a single incoming event (rather than a pattern of events) but the nature of the response will vary depending on the external conditions as discerned through previous events.

Just read an interesting article over at Intelligent Enterprise, titled: “Report Warns Of Data Warehouse ‘Bottleneck’ In Real-Time Analytics“. It certainly reflects what we have been seeing, where people are looking to Event Processing technology (whether you call it Complex Event Processing or Event Stream Processing) to overcome the limitations of more traditional data collection, analysis and reporting technologies - such as operational data stores and data warehouses - when it comes to real-time analysis and monitoring.

A couple of observations:

“Real-time” means different things to different people.  While the CS purists are quick to point out that real-time really just refers to predictably response time, in general usage people use it to mean “right now” or “as soon as something happens”. But as the article points out, for some users, a few seconds or even a few minutes can be “right now”. For someone who goes from an overnight report to data that’s a few minutes old, it certainly feels light “right now”. But for other users, and other applications, “right now” can mean milliseconds. Placing a trade in the markets before the opportunity is lost, requires sub-second response. Shutting down that nuclear reactor that just sprung a leak…I hope they don’t consider a few minutes to be “right now”. 

This is where event processing can help. Data can be streamed into an event processor - as soon and as fast as it appears, and the event processor can apply complex rules and operations to combine it with other data, filter, summarize, compute new values, look for patterns, etc - producing a stream of new “events” as a result. The lag time between the input and the output - for a high performance complex event processing (CEP) engine - will be sub-second (or even sub-millisecond in some cases).

One thing I think the article didn’t mention is the case that we see most often: using an event processor to complement a data warehouse. The article talks about how event stream processing is an alternative to a data warehouse. But frankly I have yet to see a customer use Aleri’s CEP engine as an alternative to a data warehouse. What I do see, however, is CEP being deployed to complement a data warehouse.  The data warehouse still serves as the ultimate data repository, and the event processor takes on one (or both) of two functions:

1) as a real-time monitoring application, the event processor sits along side the data warehouse, monitoring and analyzing the same data that is flowing into the data warehouse. But while the data warehouse holds it to make it available for querying, the event processor analyzes it as soon as it arrives in order to generate alerts, initiate an immediate response, or to make low-latency information available to a user to support real-time decision making.

2) as a front-end pre-processor for data flowing into the data warehouse. This is the case that I think gets overlooked a lot. You can almost think of this as “STL” in the sense that it’s an alternative to ETL that is event-driven. Here, data streams into the event processor in real-time. The event processor performs real-time data correlation, transformation, etc and collects the data to be loaded into the data warehouse in micro-batches. This micro-batch loading overcomes the speed limitations with which the data warehouse can absorb data, and at the same time avoids large batches that introduce unnecessary latency.  Because of the event processor’s ability to combine data from different sources and transform the data in real-time, the data gets loaded into the data warehouse in a format that is optimal for reporting. This can significantly improve the speed of applications that use the data in the warehouse, since the data is already in the form they need, rather than being stored in the warehouse in a raw form, and then being combined and transformed at query time.

Bottom line, at Aleri we see event processing (or CEP) as a powerful ally of the data warehouse rather than as an alternative to the data warehouse.

When Wall Street Systems (Wallstreet) acquired Aleri Global Banking back in April this year, it gave us both a good opportunity to learn about each other’s companies, and in doing so, we discovered some interesting parallels. Firstly, we both count some of the largest banks among our client bases and secondly, we both strive to constantly deliver best of breed solutions to our clients. As a result, we believe there are strong joint business opportunities for us. Wall Street Systems currently offers a Global Cash Utility as part of its back office suite of functionality. This is a substantial offering for cash management but is weak in regards to liquidity management, collateral management and payment release control. After considerable due diligence we felt that LMS offered the best possible route for us to close these gaps and give our clients the fastest ROI. In parallel, we are continuing to review Aleri’s CEP platform for use in other parts of our solution sets. - Tony White, managing director of product and research & development, Wall Street Systems

As a former Sybase employee myself, I was pleased for Aleri to receive an innovation award from Sybase for our work integrating Sybase RAP and Aleri, and specifically for our joint efforts at Mitsubishi. I have always considered Sybase to be a true leader in database technology, and their recent efforts with Sybase RAP - The Trading Edition, are no exception. Furthermore, this technology is a great complement to Aleri’s CEP offering, the Aleri Streaming Platform, as well as for use cases like Aleri Market Liquidity Analysis which we will be demonstrating in our booth at Techwave this week. I see this award as a leading indicator of more good things to come between Aleri and Sybase, and certainly appreciate Sybase for the recognition.