… 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.

One of the sessions at the EPTS VS was James Odell and Manfred Koethe presenting on the Event Metamodel and Profile RFP. I was surprised to see they already have some large vendors signed up for this. So why consider an “event standard”? What is wrong with say the TIBCO BusinessEvents idea that extends the idea of UML Class to build hierarchies of events, which in addition to properties and payloads have metadata like “TimeToLive” and datetimestamps?

1. There *is* a need for cross-enterprise understanding of events …  including derived, complex events, used across business and IT processes. So a common event spec should help here.

2. The requirement for such a standard is especially noticable when pushed up into the business domain (i.e. what are my business events?). Potentially this raises the bar for the vocabulary for event understanding to ontologies like OWL/ODM and SBVR, and associated modelling tools…

3. But what about the details of “complex events”? How can event relations etc be a part of this standard without treading on the toes of potential query versus rule language semantic issues? There is an easy answer to this (as I mentioned in the EPTS Virtual Symposium). We’ll see if the rest of the community agrees.

The “letter of intent” deadline to join the work on this specification is 20th May this year.

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.

Thanks to James Taylor for pointing out an interesting blog post by EPTS member Jeff Adkins on a topic he calls the 4Ds - Detect, Derive, Decide and Do. Clearly this is very similar to the event-decision-action pattern mentioned here a few times, where event is neatly extended to detect (source or simple events) and derive (complex events). Good separation of concerns!

I fully concur with Jeff:

” I don’t believe this is limited to simply CEP or expert systems. This is the nature of a reactive system, which all computer systems in truth are. Even “proactive” systems are reacting to an understand of the world around us and a potential threat or opportunity (also known as situational awareness).”

The interesting thing here (and probably the topic for another post) is how this can be used to classify event processing technologies. For example, event stream processing (or ESP) is usually event edge (”detect” and some local “derive” in Jeff’s parlance). Event cloud processing is doing more of the same (”detect” and wider context “derive”), and often nudging into decisions (”decide”). Simple SOA technology usually fixes the events and hard-wires the decisions (”detect” and “decide” and “do”) although business decision engines (a.k.a. BREs) will sometimes be used to provide some agility on the “decide”. BPM is all about what to “do” of course with some fixed (hence human oriented) events and orchestrated decisions. Analytics technologies can be used to determine some of the “derive” pieces, albeit usually from a past data rather than a current event context. Etc Etc.

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…