Prof Adrian Paschke invited me to present to his students this week on some of the real-world experiences of CEP versus the semantic technology space and the merger with the BPM space. Well, for the semantics study, we will be presenting some thoughts at the Semantic Technology conference next week.
On CEP and BPM, I should start first by pointing out TIBCO’s new ActiveMatrix BPM suite, that seems to have been very well received by the BPM world. BPM today is not the same thing as CEP, of course – they are complementary components in an enterprise IT stack. But having said that, they both conform to the event-decision-action model – where as CEP tools concentrate on the events (and defining complex events in terms of other events) and decisions thereon, the BPM world focuses on the actions (ie process activities or tasks), and predefines many event-decisions as control flow in a BPMN model. But the idea here is that both these cover “process” in a generic sense, with different “models” (and hence deployment architecture optimisations), and for different use cases.
One of the TUCON2010 user presentations that brought this out was the excellent and detailed OOCL shipping line presentation, where they did 3 different implementations of an event processing use case (managing the milestones and subsequent exceptions for shipping – where shipping is of course the overall business process). From the data presented, and being unduly pessimistic in my interpretation of said data for the CEP part, I noted and derived the following:
| detail | J2EE version | BPM version | CEP version |
|---|---|---|---|
| Implementation coverage* | 100% | ~3%** | 100% |
| Effort (person yrs) | 5.3 | 1.7 | 2.3*** |
| Development cost (person yrs per milestone) | 0.6 | 56.7 | 0.3 |
| Issues | Change costs**** |
Notes:
* Based on >100 milestones being defined
** 3 milestones were completed in the BPM project; however it may well have been that these were particularly difficult implementation-wise
*** TIBCO effort includes a POC (which probably shouldn’t be counted), and 4mths of “tuning” (which probably did not involve the full team) – without these the figure becomes 0.75 person years, and development cost per milestone a low 0.01 …
**** The reason for discontinuing the J2EE version was stated as being the cost of changes to business rules, new milestone implementations, etc.
One important fact here remains that the role of this application was to direct – or invoke – existing known business processes (implement in Oracle BPM). So while this particular application was clearly ideal for a CEP solution, it works very much alongside conventional BPM business processes…
