On cost-effective EP when high performance is not required

Brian Connell has asked me to provide an example in which Complex Event Processing can be used when low latency is not required and it is still be better than other solutions.

I have already referred to this issue in the past. There are several concrete examples that come to mind - here is one (real system):

An enterprise has internal regulations to handle suppliers, these requirements relate to the interaction with suppliers, that may be represented as events, and involve actions that must be done, or should not be done, within certain amount of time, or until some event happens. The application is to monitor the compliance with these internal regulation in audit mode, meaning the results are alerts (which are also treated as events, since there are time-outs from alert sending) and not direct interference in the business processes.

The throughput is far below what is considered as "high throughput" and it is several thousands events per day. The latency is also not required to be extremely low -- if the alert will be issued within a minute or two, it is still very fast auditing. It also does not require any analytics of intelligent procedures, since the regulations are given and deterministic

What are the benefits for the customer to use EP software and not any other solution?

First - some of the regulations are fairly complex - writing them in hard-code can be time and resource consuming, putting everything on databases and using SQL was also considered - but some of the regulations are not easy to express in SQL.

Second - Regulations tend to change frequently, the users wish to control these changes, and getting them through the slow IT development cycle will delay the introduction of the change.

So in this case the customer's motivation are - agility and de-complexity; more later

On Event Proessing Platforms and Engines

Here are pictures of some engine and some platform, and they don't seem to be compatible, however if a car will replace the horse in the 2nd picture, all of a sudden, the engine (of the car) will have a role in the platform. In event processing we hear more and more about platforms, and even about event-based middleware that will be a basis for XTP and other stuff. The platform is providing some services for agents to run, like a road system that can enable to get from place to place and provide services such as: signs, traffic lights etc... The way to go there can be by foot, riding an hoarse, and driving a car, among other options. Taking this analogy further -- in the event processing world, every agent can be implemented in ad-hoc fashion (going by foot), use C/Java code with some tools to help create EP applications, or use engines, which are COTS tools that do event processing. Implementation of heterogenous agents on the same platform requires interoperability standards, if we also wish to implement it in a seamless applications we'll need language standards. There are some starts of event processing platform, quite basic at that point, but the direction seems promising, and may, at some point in time we may see event processing platforms as a basis for the new generation of enterprise application servers.

On Complexity and use of COTS

My daughter has returned yesterday from a trip abroad, and brought me a present - since she knows that I have a collection of teas, she brought me another tea, unfortunately she does not really understand much in teas, so what I got as a present is a laxative tea. Well - I thanked her, and wish that I'll not have the need to use it ever.

Catching up in blog-land, I found an interesting posting by Mark Tsimelzon from Coral8,

entitled "complexity scorecard", the direction of defining indications for complexity is useful, however, this can be taken a step further, since the different indications belong to various topics, some of them about the complexity of functionality, and some on different measurements of scale, high availability and interface type, which are orthogonal issues. The assumption in Mark's scorecard is that if one has enough indications that it is cost-effective to use COTS for event processing instead of hand-code it, however, in some cases it is not the aggregation, since some of these indications can justify COTS even if most others don't exist (e.g. complex functionality), and sometimes the boundaries are not that clear, thus, there is a need to further refine the question "when is it cost-effective to use COTS" ? - thus, while the thinking is in the right direction, a scorecard like this looks somewhat simplistic. Do I have a better one ? -- not really, but will join the chase after it... more - later.

On Event Processing and Now.

After some more technical postings, back to macro-level issue. David Luckham has written recently in his website about the history of CEP (I'll refer to the content of this article in another posting). All indications are the event processing is not a new thing, however, as some people indicate, there are a lot of interest, events, maybe hype around it NOW - the question is what is new ?



The first observation is that unlike the past, today there are commercial "on the shelf" products whose main purpose is to provide event processing capabilities, while in the past there were event processing capabilities in other types of products (simulation, databases, network and system management, middleware, real-time systems etc..), there is also a start of event processing as a discipline. What are the reasons for the interest now - some of what happened in the last few years that supported the shift from hard-coded event processing functionality to COTS are (based on discussions with people in multiple industries):

• Some contemporary applications which are event-driven by nature - such as: compliance with regulations, the need to detect frauds as two examples - have become pervasive in multiple industries
• The increasing complexity of inter-process integration that is simplified with event-driven interaction
• The need for flexibility and agility to gain market advantage in different areas - thus, move away from hard-coded solutions.
• The substantial growth in the number of available events - e.g. since RFID technology became pervasive.
• Some industry trends like - BAM, RTE, "on demand" - that are also based on responding to events.
• The drive to save expenses in back offices by automating exception handling - trends like STP.

I am sure that there are more of these.

Thus, while event processing functionality is not new - "event processing" as a first class citizen in the computing world - with its own dedicated products, community and emerging discipline is new. More - Later

"The only motivation to use EP COTS is to cope with high performance requirements" - true or false ?

Somehow, I find myself using my collection of analysts' presentations to help me make some points, this time, I am showing a slide from Roy Schulte's presentation in the Gartner EPS summit - I'll return to the content of this slide shortly, but will start with some discussion I had yesterday about the reasons that enterprises are using COTS for event processing. I have heard (and not in the first time) the assertion - the only reason that one will want to use EP software and not hard-coded solution is the ability to cope with high throughput / low latency - in short, to deal with high performance requirements. If there are no high performance requirements there are other solutions, e.g. the database guys think that in this case one can insert all events to a database and use simple SQL queries for CEP patterns, or just using the good old C/Java programming for this purpose. This is somewhat inconsistent with my own experience, where customers that did not have "high performance" requirements were eager to use CEP technologies. Indeed, high performance is a reason to use CEP COTS, however, as indicated in Roy Schulte's slide above - it is actually a minor reason. According to Gartner, the high end is somewhere between 5-10 percent of the candidate applications, while looking at the prediction for 2012 - the use in the high end will be 8% - out of the 27% total use; note also that Roy Schulte defines the high end as 250 events per second, which is really far from the definition of "high performance", so the numbers are even lower. It seems that the market for "non high performance CEP" is much larger, and will grow faster. If that's so - where does the misconception that EP equals high performance always ? I think there are two sources - the first, the early adopters were from the capital markets industry, where some (not all !) of the candidate applications has indeed high performance characteristics. However, with the growth of the market, and use of EP software in other applications and other industries, these type of applications, while continue to grow, will not match the higher growth of non high performance applications. The other reason is that some vendors make the high performance as their main message, and trying to get the market believe that this is indeed the most important property.

So - if high performance is not the only reason to use EP COTS what are the other reasons to use EP COTS ? this is a matter for investigation, but IMHO the main one is the "high level programming" and agility - in short - the ability to reduce the Total Cost of Ownership.

I'll provide more insights about the TCO issue in a future post.