TIBCO finished its financial year at the end of November. The TIBCO BusinessEvents CEP product saw a 65% year-on-year growth in license revenue. Not bad, and validates the utility of CEP via rules-based pattern matching, standards-based model-driven engineering, and distributed processing for markets such as telco, logistics, insurance and government (as well as the traditional investment-based financial services).

As luck would have it, the end of TIBCO’s internal sales and training event in Las Vegas coincided with the best downtown snowfall in 30 years, with the inevitable result that McCarran airport shutdown, flights were delayed and cancelled, roads shut, and the TIBCO teams had an unscheduled extra night in casino-land.

It was interesting to see how the FAA, airport and airlines responded to the “complex events” resulting from incoming storms, snowfall, reduced visibility, etc [*1]. Local news reported that the airport claimed it was the visibility, not the snow, that was the problem (somewhat amusing to any fog-prone Europeans present). Somewhat ominously, they also admited to having no equipment for dealing with snow and ice - obviously the disruption of such weather every few years is not worth the expense of such equipment (to the airport, anyway).

First one airline, then others cancelled flights as the afternoon wore on into evening; some were optimistically stubborn in delaying cancellations, causing some of their customers the pain of travelling to the airport just to return later. Then, a few hours after the departure boards showed carnage, the airport put out a notice of the problems on their web site (woo hoo!). Which at least was better than the FAA, whose site seemed to be down (either that or McLarren posted a bad link). Clearly, some of these guys are not yet into the business of real-time customer information (or keeping customers happy).

By Thursday morning, the snow had stopped falling, the sun started shining, and the airlines started shifting passengers on their way again.

We’ll cover some of the “lessons learned” from the TIBCO BusinessEvents CEP sessions in Vegas in future posts; meanwhile, some interesting stats given were:

• one customer is deriving up to $500K revenue per day from the use of CEP in their CRM
• one customer is managing 1 Billion events at any one time
• one customer is running a credit scoring decision table more than 200K rows in size, with more such tables in development.

Notes:

[1] Interestingly, one of the airlines involved is operational with a TIBCO CEP system to help provide information to respond to “unforeseen schedule disruptions”.

Ashwin used this great slide at our TIBCO BusinessEvents QLGroup best-practices session this week, courtesy of James Gosling’s blog and credited to Peter Deutsch.

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

Arnon Rotem-Gal-Oz did a follow-up white paper that goes into more details.

Opher (as chair of the Event Processing Technical Society) just sent out an email to EPTS members, reminding us of the progress on EPTS working groups. EPTS is a lightweight, low-cost industry body of Event Processing vendors, users, analysts and researchers: in some ways EPTS is following the role played by BPMI, remembered for kick-starting the (now prevalent) BPM industry.

Current workgroups up for discussion and approval by members include:

• Glossary (continuing work from the current EPTS Glossary version 1.1) - standardized terminology
• Use Cases (continuing work) - standardized format for describing use cases
• Interoperability Analysis - how EP tools can interoperate
• Languages Analysis - potential metalanguages for describing EP constructs, possibly aiding interoperability in the longer term
• Metamodelling - support for existing and future EP-related model standardization efforts in the official standards bodies like OASIS, W3C and OMG
• Reference Architectures - continuing some of the earlier work on common architectures for describing EP systems

EPTS members will be discussing and voting on these over the next few weeks.

[Disclosure: TIBCO is a member of the EPTS Steering Committee, and is co-chairing the Metamodel and Reference Architecture workgroup proposals.]

Michelle Cantara at Gartner just blogged about someone in the financial services industry building a “trade exceptions” system. OK, so just another BPM case study, you might think. But there were some interesting phrases that deserved closer attention:

“I patiently explained than exception handling tends to involve a great many process paths, many of which are undocumented, are handed down by oral tradition. The business users can’t possibly “grok” the solution implications of all these permutations.”

This does not sound like a conventional business process flow or workflow for assigning exceptions to staff. If there are a great many undocumented process paths, then that implies some sort of dynamic process (such as event- and/or rule-driven process activities). And if this was modeled in a convention process flow, it could easily end up being “large and fragile” as opposed to simple and maintainable.

“More importantly is lack of process context. The in-house trade control group gets these exception trades back from the outsourcer. They are accompanied by lots of data, but there is no way to tell what process steps that exception has already been through, and what the data means as a result.”

So maybe they are processing events (trade exceptions)? And they probably need to either maintain the state of the transactions in (and for) the exception process, or do some (typically rule-based) analysis of the exception and data to deduce its status in the underlying (trades) process. Quite possibly there are important interrelationships between these exceptions, too.

“After hearing all of this, I launched into my BPM pitch – since I had a captive audience, stuck in the car with me. My friend insisted that neither IT or the trade control group will go for a model-driven approach.”

Hoorah for BPM - the obvious solution!

Maybe, maybe not: Business Process Management [*1] invariably involves process modeling as a prerequisite to process execution and runtime management, but today is mostly concerned with (simple) process orchestrations or flows… for which the above process might not be a good fit [*2].

Presumably the relevant IT department is savvy enough to realize that “business processes” are not exclusively orchestrations / activity diagrams; that “model-driven processes” can be done by, but not exclusively, “BPM”; and that there are other model-driven technologies (like CEP) better suited to some event-driven rule-based automated business processes.

Presumably.

Notes:

[1] Assuming Michelle is using BPM in its most analyst-friendly form, “Business Process Management”, not the rarer more technical term “Business Process Modeling”. Regardless, the latter is often just a synonym for BPMN process flows.

[2]  TIBCO has an example best-of-breed BPM tool that includes the traditional orchestration of process flows in BPMN via  BusinessStudio, but also can handle goal-driven dynamic process models via iProcess Conductor, and event- and rule- driven “BPM+” via TIBCO CEP / BusinessEvents.