So - what can we learn from all these? I am not sure that we can learn anything new that was not already discussed, actually such discussions return in cycles from time to time. When we complete the document that we started to generate in the Dagstuhl seminar (it will probably take 2 months or so), we'll articulate some of this.
There are three basic issues: Does event processing has vitality as a technology? Is it define a stand-alone market? and how do we go about the 2.0 generation?
If we look at the considerations for the use of event processing as a technology, alternatively to hack in other technologies or just hard code the functionality ad-hoc for applications, one of the consideration that was mentioned is the ability to deal with high throughput of events, which is not a trivial task to achieve with hard-coding or regular technologies. However, it seems that experience got us to realize that the more noticeable benefit is the TCO.
Dan Galorath produced the TCO chart seen above related to software, there are also evidences that the software development in event-driven application achieved substantial reduction (sometimes in ratio of 1:4) relative to conventional solutions. In the last DEBS conference somebody remarked about the Fast Flower Delivery use case that is discussed as a pivot example in the EPIA book that this is a BPM example, since the event processing network looks to this person as a workflow (it has totally different semantics!), so my challenge is -- go ahead and implement in with a BPM system and then we'll compare the development time.
As seen from the chart, the software maintenance contributes much more to the TCO than software development, and here the use of higher level abstractions that leads to ease of change intensifies the difference. Rainer quotes somebody who says that there are charlatans in this area, true - there are charlatans in every area, when relational databases emerge, all of a sudden, implementations of relational databases were provided by people who did not understand what a relational database is (not just flat files!) and did not understand that they did not understand what a relational database is -- nothing is new. Investment in development in various solutions is something that can be measured.
As for the other question - whether event processing is a business as a stand-alone, I have already referred to it in the previous post, the answer is -- yes, for certain types of customers and applications, and embedded technology both in other technologies and applications. My guess is that the embedded mode represents higher portion of the market that will be still growing.
As for CEP 2.0 --- here I agree with Marco that the next generation should not be incremental. In the EPIA book we have introduced some abstractions that are independent of the implementations of the first generation, we are exploring them now as a basis for the second generation. I guess that this is also a challenge for the research community. More -later