Congratulations to the OMG PRR team - the OMG have voted the Production Rule Representation 1.0 as a standard for UML modellers to represent production rules (including “sequential” if-then statements as well as Rete-type inference rules). Of course this is not the last version of PRR -  there may be a few bugs to work out and we have commissioned the Revision Task Force already - with a 1.1 release planned for next year. Maybe other CEP vendors will realize the importance of standards (and rules!) and join the effort?

Close behind is the W3C Rule Interchange Format - Production Rule Dialect - which is “imminent”. There was some overlap between the teams involved with these standards so, usefully, and as PRR Core defines “the” generic production rule metamodel, PRD is “compatible” with PRR - meaning conversion between the 2, from  modeling to interchange, should not mean too many hurdles. Indeed, current ideas are for a RIF PRD 2.0 that allows for object models (as opposed to “frames“) and a PRR 2.0 that utilizes the PRR-PRD syntax that uses the PRD expression language… we’ll see.

The Banker runs annual technology awards, and this year the Citibank CEP application supporting real-time marketing is one of the winners. The article quotes:

“The system deploys complex event processing technology to evaluate static and dynamic events against a customer profile and ‘propensity model’, to determine in real time the next best offer the bank can extend to the customer.”

“Because the system operates on a ‘rules basis’, it can be adapted by business users to design the rules that govern a particular campaign without the involvement of IT staff. “

“The bank is also using the intelligence in the system for fraud prevention and proactive customer service.”

This week OMG’s Technical Meeting has had most buzz around the BPMN 2.0 submission (and congratulations to that team, for which TIBCO is a supporter). Some of the other stuff going on includes:

• PRR or Production Rules Representation (which, for complex event processing like in TIBCO BusinessEvents, can include event-condition-action rules using standard forward-chaining semantics) starts the Revision Task Force process for PRR1.1. A few tweaks are due, but more interesting was to see 2 more vendors attend the PRR session this week. Also, note that UML tool NoMagic is presenting on PRR at ORF’09 later in the year…
• DMN or Decision Model and Notation started on its first stage of development, which is the identification of use cases and roles for defining UML-based decisions for a future RFP. We had some good discussions (which I’ll report in a future post once I have reported to the DMN community), and it is clear that this could be a very key standard for business modelers, end-users and tool vendors. Of course the relevance of this to event processing is that many CEP/EP systems’ role is to support decisions…

A somewhat hotter debate continues (/is) regarding the proposed Case Management RFP, which was developed from a Dynamic Business Activity Modeling RFI last year (which TIBCO responded to, and was also covered by our session at the recent Semantic BPM day in Berlin). Many BPM applications are also case management applications, but some case management requires more sophisticated event-handling, rule-driven processes, decision management, and case record management and recording (technologies that TIBCO mostly covers under BPM+). One school of thought is that the more sophisticated requirements for case management need to be rolled into the common BPM standards stack (including BPMN); another is that multiple different standards should be used flor flexibility (such as combining BPMN with BMM, PRR and DMN). From an event processing perspective, of course, case management (by one definition at least!) involves applying incoming events to the state of some case in order to determine whether processes need to be started, continued, halted or changed - in other words CEP technology can often be applied for case management areas in government, finance, healthcare, etc.

Some of the other case management discussions can be found from EBizQ, Bruce Silver, and Derek Miers.

Over the past few weeks I’ve been an “Acting Project Manager” alongside a talented TIBCO team who designed and implemented a telco services gateway using TIBCO event processing software. Of course, the importance of the Project Manager role decreases in direct relationship to the experience of the team - so my role here was somewhat redundant due to the experienced implementation team. The project required Rapid Application Development exploiting a “standard set” of TIBCO technologies:

• TIBCO BusinessWorks to host the service entry and exit points
• TIBCO BusinessEvents for the main processing rules covering routing, validation, service throttles, KPIs, logging etc
• TIBCO EMS as the main external event (/message) transmission mechanism
• TIBCO RV for internal communications within the distributed application, e.g. for log handling
• TIBCO HAWK for application monitoring
• TIBCO Administrator for managing the deployment and updates to the application.

Some observations on the Project Management aspects were:

1. Good design counts: there were several specification changes (including to the specification of the incoming events) that were to some extent mitigated by the tooling flexibility, and some by the use of good design patterns.
2. Project Management is sometimes Anti-Agile: some of the (event) specification changes we deferred to later in the application development process in order to provide controlled, manageable, validated releases. The PM’s main role is obviously to protect the development team and delivery schedule from scope creep, although inevitably some scope changes were requirements boundary cases…
3. Test-driven development: early effort was expended in an appropriate test framework and test cases, used to exercise the event processing application with particular event types and patterns. This paid dividends in allowing defects to be identified, and resolved, early.
4. Communication and control artifacts: the High Level and Detailed Designs were defined in docs and in prototype BW processes and BE rules; we first used MindManager for internal reporting of issues, and then progressed to an existing Bugzilla instance for co-operation on issue management. Although we had an MS Project plan, we deferred to Excel for internal and customer reporting. Code and docs were controlled using SVN.
5. Knowledgable customer contacts (and good customer relations) make the PM’s job so much easier…

Some specific project challenges relating to the “event processing” aspects:

- Event definitions are key. If the event model is changing lots as development is occuring then this can be problematic. One traditional and effective solution is to use your own internal abstract event model and map to / extend this as required.
- Testing timed sequences of events could be a challenge. This project was event processing, not complex event processing (there were a few abstract KPI events created, but for the most part the application was stateless). Obviously, live system events are ideal for testing.
- Application performance (throughput, latency) need to be monitored and managed thoughout (although not an issue for this particular application, so far).

So - not much Project Management is specific to the “event processing” aspect. But that is good news and to be expected when insulated by a good development team and good tools!

Someone asked what other TIBCO blogs were around, as the “Communities” tab on www.tibco.com currently only mentions this, the CEP blog…

Here is a quick guide to the other TIBCO blogs…

• Cloud computing - the TIBCO Silver blog - answering questions about TIBCO’s approach to cloud computing for businesses…
• Spotfire community - the Spotfire blog(s) - answering mostly technical stuff about visual BI and analytics with Spotfire, S+, Miner etc
• TIBCO developer community - the TIBCommunity blogs - covering a wide range of stuff  (divided by product, including for BusinessEvents).