Translates as:

The Event Processing Technical Society (a diverse community - vendors, analysts, academics and end-users - interested in event processing) and

Object Management Group (an international, open membership, not-for-profit computer industry standards consortium)

Event Processing Community of Practice (a new advocacy group for event processing under the OMG umbrella) have announced an

Innovative Event Processing Application (one showing significant and innovative use of event processing, developed in the past 5 years, with some innovative use and a potential or realized value)

contest!

So which of the use cases we’ve mentioned here should enter, I wonder?

This year DEBS is in Europe, and in Kings College Cambridge, England - surely a model for the Harry Potter Hogwarts School of Architecture, with a quite amazing internal maze of staircases that entirely obviates any need for an on-site gym, while maybe requiring some kind of RFID-enabled roomkeys so event organisors can detect and rescue guests from obscure parts of the college.

Fellow Event Processing Technical Society colleagues Adrian Paschke (Freie Universitat Berlin) and Catherine Moxey (IBM CICS) and I presented a tutorial on the EPTS Event Processing Reference Architecture journey and development, with additional contributions from Alex Alves (Oracle) and Themis Palanos (University of Trento), on Monday this week. The presentation is now posted up on Slideshare (see below or here, or if in a Flash-free environment, check out the PDF).

One of the interesting audience questions was, if I recall correctly, why the EPTS Reference Architecture team did not differentiate their architecture more from that of, say, the BPM community? This was a little surprising as nowhere had we mentioned the words “business process” or “process orchestration”; neither had these really come up in the Reference Architecture discussions (other than as consumers of events). However, we did refer to the Fast Flower Delivery use case discussed in Opher Etzion and Peter Niblett’s forthcoming book on Event Processing, and Opher assured the audience that the event-driven processes therein were valid event processing requirements as opposed to BPM. An interesting point of reference here was the TIBCO user presentation at TUCON earlier this year that also found out the difference in BPM and CEP for their particular problem.

A related comment - from an end-user organisation - was that the sales teams of companies selling CEP solutions were often too quick to offer their BPM offerings rather than their CEP solutions. For an end-user to complain to vendors that “you are trying to sell me the wrong stuff” is pretty interesting! Wonder which vendors they were?

Reading a paper from last year’s Knowledge Capture (K-CAP 2009) academic conference, I came across some references to various “event standards”. All of these were very domain specific, but 2 seemed they might have more generic uses.

One was Events-ML G2 from the International Press Telecommunications Council for registering “events as in conferences, meetings etc” (rather than the sorts of events the CEP world is mainly interested in). The event schema therefore includes properties such as phone and contact details, implicitly recording the observer’s data on the event (as opposed to some observer identifier from which that and other data could be gleaned, presumably). On the other hand they did have a nice test form!).

Event in Event Ontology

There was also an “Event Ontology” defined as part of a Music Ontology (!) project. Things started well when the authors stated:

This ontology is centered around the notion of event, seen here as the way by which cognitive agents classify arbitrary time/space regions, which is essentially the view expressed by Allen and Fergusson [or its HTML version via Google].

The next quote was less impressive though, seemingly going beyond abstraction and on into the realm of philosophy…

[..] events are primarily linguistic or cognitive in nature. That is, the world does not really contain events. Rather, events are the way by which agents classify certain useful and relevant patterns of change.

Reviewing their definition of event we see relationships between event and:

• place and time
• factors and products
• agents (acting on the events)

Presumably from the musician’s point of view, a set of notes (as events) may combine into a musical chord (an event product) - or in other words, agents combine events and context (”factors”) to define complex events (”products”). So not a million miles away from the EPTS’ labors on the EPTS Glossary, newly refreshed in a draft version 2…

Draft Reference Architecture

Some folks may have seen earlier updates on the EPTS Reference Architecture work. Well, the latest (Architect role Functional view) draft seems to be getting some approval (so far) among Reference Architecture Working Group members. Some of the terminology may change slightly to conform to (or influence) the EPTS Glossary; other roles and views are still in progress.

EPTS hasn’t set up a public review mechanism yet, so participants’ blogs will have to do: feedback posted here will be posted back to the working group wiki. Once the Working Group is satisfied with this, the Steering Committee and membership of EPTS will vote on it, and then it can be made “official”.

Opher Etzion recorded some action items for the Event Processing Technical Society at the EPTS5 symposium last week. One of these was “promotion of EPTS” as the go-to resource for event processing information (hence the irony that these action items are duly  listed on Opher’s blog and not anywhere on the EPTS web site).

One of these was the idea of an ROI Working Group to share and propagate ROI stories (this being a safe activity for vendors to share as customers seeing ROI will not likely be poachable by other vendors!). But how should ROI be measured and reported?

Coincidentally a colleague just mentioned an airline customer who just went live with a new track-and-trace CEP application -  an application with an estimated €2M per year payback.

Some observations here:

• This was an IT project completed during a big downswing in the airline industry, whilst many other conventional IT projects were being cancelled or postponed - but the ROI was compelling enough for this project to survive.
• The application used a distributed rule engine architecture, exploiting TIBCO BusinessEvents‘ agent-based architecture.

Another coincidence: I was just listening to Paul Coby, CIO of BA, talking about the need for lean and agile approaches in the airline industry, at IRMUK’s BPM2009. His message was ‘there are no IT projects, only business projects’ - all with business goals and KPIs to be measured. Model-driven CEP applications like the airline use case above certainly qualify as lean and agile… I wonder if BA is exploiting CEP like its competitors are?