… was the title of the Business Rules Forum session presented earlier this month, targeting the Business Analysts attending the BBC2011 conference. This includes a quick overview of (some) of the various ways to model events (in business models), including using the EPTS Reference Architecture as a guide to event operations required or events desired. Sandy Kemsley did a great overview on her blog, by the way (and Sandy also covers event modelling in her tutorials and training).

Feedback welcome, and of course I’ll be adding things like VPEC-T to version 2 of this.

I was going to blog on the presentations at the Decision Modeling Information Day at OMG, but suffice to say that James Taylor has already done a great job of this so I will just add a few comments from the CEP perspective…

1. CEP can be viewed just as “complex event” detection… but increasingly businesses want “complex  event” *processing*, where processing is not just event detection but also decision and reaction. Of course, the reaction can be a traditional orchestrated business process, as in a pattern like:

(a) detect fraud event (b) decide appropriate action (c) react with the Fraud Handling business process

2. Business modeling of decisions, as well as complex events, is an area that none of the traditional business modeling tools seem to be taking seriously. Yet both decision automation and CEP provide huge values to business operations.

3. Methodologists on the decision modeling side are finding receptive audiences in business. These include the KPI Decision Model, which was endorsed by Mark Pettit from Freddie Mac at the info day, the new BRS Question-Charts, and Alan Fish’s DRA. Adapting these for real-time, event-based decisions should be possible, as Larry Goldberg from KPI discussed in the meeting: the main difference with top-down analysis of decisions is that you may or may not be able to detect some of the desired business events!

4. There were some good questions on the role of analytics in, for example, driving CEP-based decisions, or in risk management for trading systems. For example, TIBCO Spotfire Data Miner can be used to generate rules for classification decisions inside a TIBCO BusinessEvents CEP system dealing with high volumes of trading events in a stateful manner.

5. The proposed DMN standard discussed at the end of the Information Day should of course equally apply to decisions in CEP as well as BPM.

Analytics Magazine on OODA

While discussing the proposed OMG Decision Modelling standard with business rules specialist Ron Ross recently, Ron reminded me of the list of “roles” that “decisions” can provide:

Classification, Evaluation, Selection, Approval, Assessment, Assignment, Allocation, Diagnosis, Prediction

Curious as to what sources might refer to this list, I “googled” for these terms and one of the first relevant results was…

Threat evaluation and weapon assignment decision support: A review of the state of the art (2006-2007)

This is a fascinating paper that targets the military domain but nonetheless is very relevant to CEP (and indeed business) methodology:

1. “Threat evaluation” is also a business task: business threats are things like poor customer satisfaction, poorly managed product marketing, changing business conditions (locally or across the business), inability to predict business changes, regulatory compliance risks, and so on.
2. “Command and control” (a.k.a. business management) methodologies are also of interest: the paper refers to Boyd’s Orient-Observe-Decide-Act (OODA) cycle, Lawson’s Sense-Process-Compare-Decide-Act cycle, and a Monitor-Assess-Plan-Execute cycle.
   • Orient means setting up measurements, or event sources
   • Observe, Sense-Process-Compare, and Monitor means event (including “complex event”) detection, and all the associated processes for complex event processing.
   • Decide means making some decision based on our observed events.
   • Act and Plan-Execute mean behaviors that in turn will likely affect the environment and future events.
3. The paper refers to the JDL Data Fusion model which may well be familiar to some CEP folk: this model describes (with a minor translation from the table in the paper) the use of and relationships between:
   • event assessment
   • complex event or entity assessment
   • situation or state assessment
   • impact or cost-benefit assessment
   • performance or goal assessment.

I would therefore claim that the relationship between events and decisions seems not only very clear, but also well recognised.

This week the OMG held its technical meeting and as usual there were some very interesting sessions - particularly the Tuesday meeting by the Business Architecture folks on “Value and Innovation” hosted by William Ulrich. This covered:

- Value Chain Modelling: where the actors or agents in an organisation have their inputs and outputs analysed to see what value is being added to a business and where - information which can then be used to prioritise investments, process improvements, etc. There is an effort to standardised a metamodel for Value Chain modelling - the VDM or Value Driven Metamodel. A good adjunct to BPM and Enterprise Architecture levels of business modelling, in my opinion,and related to metrics and BAM (Business Activity Monitoring) to identify the state of your “value chain” and your business operations’ net-current and potential values.

- REA or Resources, Events, Agents - provides a slightly more detailed view of the same value perspective. Agents, or actors, add value to  Resources, via Events. Simple, really. CSC’s Klaus Loehnert and Pavel Hruby presented this, with an excellent decomposition of REA diagrams to business events (what they called the IT implementable layer) as well as abstraction up to a value chain model.

To differentiate REA events (which are accounting abstractions of real events) from other events, the term “economic event” is used (and indeed economic resources and economic agents).

The REA concept was first published in 1982 by William McCarthy and is now an ISO standard - see ISO 15944-4. So now you can answer any pub quiz (or inane RFP) question on “what is the ISO standard for business events” …

In both the above, REA and value chain models could probably be emulated in TIBCO BusinessEvents by using a state model and scorecard, with results displayed in a TIBCO BE Views dashboard.

One of the drivers of success in the BPM world has been BPMN - the Business Process Modelling Notation - developed under BPMI before it got absorbed into OMG, and probably a bigger success than any other modelling standard - and now as BPMN 2.o (beta, at this time) slightly reconfigured in name as the Business Process Model And Notation. BPMN is used to provide a “process” perspective (versus, say, a data or an event perspective) of a system and shows the flow or orchestration of process tasks and activities. It is made up of (per the excellent bpme.de BPMN2 summary poster):

• 2 flow subtypes: sequence is the normal flow, with default and conditional conditional subtypes
• 7 task types: send, receive, user, manual, “business rule” (really decision), service, and script
• 6 activity markers: sub-process, loop, parallel, sequential, ad-hoc and compensation
• 7 gateways: exclusive, event-based, parallel, inclusive, exclusive event-based, parallel event-based, and complex
• 6 types of data: input, output, object, collection, store, and message
  and
• 63 types of event…

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate

… across 8 situations classified by location in a process:

• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving 58 63 event types defined [*1].

Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

So let us analyse these event types from an event processing perspective:

• Message and timer events: these are probably most familiar with to those with an event processing perspective, with a message relating to what we consider either a source or a derived event.
• Escalation: this is really a deferal to a different process (e.g. a supervisory process), and can be handled by some internal message in event processing.
• Conditional: this is “reacting to conditions becoming true” - in other words equivalent to a rule-firing (or event query) success. In a rule system this might be handled just by setting some fact or data, which in an inferencing rule system will use some internal event to signal to the rule engine that other rules may “fire” - however there is no need to explicitly model this behavior. I may also of course create an event (or in a query system, insert / update some event), which is again is not explicitly modelled as “conditional” per se…
• Link: some means of connecting models: this is more a “page break” than a business event!
• Error: I prefer the term “exception” here, which of course is a local context - an error event in one process is a normal event in an error-handling process, etc.
• Cancel: this is more a transaction-specific event: if dealing with transactions then some events may indeed be “cancel transaction X” requests, which may or may not be satisfiable, etc.
• Compensation: this is where some process route may require some compensatory process - for example in relation to a “cancel” event.
• Signal: signalling information across processes: this is might be used as a control event, such as in controlling a choreography.
• Multiple: one of a set of events is “caught” or provides the cue to continue the process.
• Parallel Multiple: all of a set of events is “caught” to continue the process.
• Untyped events are used for start and state changes. Typically, though, a state change is the main event we are interested in (in event processing)!
• Terminate event - process complete! From an event perspective this (process end) might never happen of course…

The extra detail might be explained by the fact that in BPMN you are detailing *how* to implement a process, and the “event symbol” is providing you with some specific context for that event. In event processing languages, you usually describing “what* is to be processed, and where all events contribute to some situation or context. It will be interesting to see how these 58 symbols work out in practice, as a hindrance or a help for process designers…

Note:

*1: the table of events above, from the BPMN2 poster from bpmb.de, has 63 event symbols, and is slightly re-organised from the equivalent table in the BPMN2 beta specification (Table 10.93 pp 269-270, in 10-06-04.pdf). Interestingly the specification document also includes a table to detail the event symbols (Table 12.23 ppp 405-411, in 10-06-04.pdf) but this shows only 58 symbols! Let’s just say “lots of event types” in BPMN2 then…