This week is RulesFest in San Jose California, at the Dolce Hayes Mansion on the South side of the city (which I think I last visited a decade ago during a dot-com-era company party that involved riding, er, “toilet buggies” around a car park - thats quite enough reminiscing I think).

One of the presentations planned this week is by Barbara von Halle and Larry Goldberg who wrote the “Decision Model” book, and who are one of the influences for the DMN Decision Modelling standard being worked on (as an OMG RFP) with IBM and Jan van Thienen (Mr Decision Table). One of the things I liked about the KPI model is how it can be viewed as a Goal Network model (albeit more an analytical logical tree in KPI’s view) for organising decision metaphors like decision tables. Such a Goal Network is of course ideal for modelling inference rulesets of the type used in rule engine programming and complex event detection: the goals define the intermediate states and the rule conclusions represent goals that are subgoals in other rules’ conditions.

The interesting thing about the Goal Network is that it applies equally to process design and decision design (where decisions can be decision tables or inference rulesets or anything else). The nice thing about a Goal Network for inference rule engines is that the goal network can be “executed” automatically during “inferencing” or rule engine processing; with decision tables you have to explicitly control the execution path (which of course could be preferable in some scenarios).

I’ve a strong feeling that “goal networks” and their multiple viewpoints are the next interface development area for those bridging the gap between business models and IT.

At the OMG technical meeting this week we had a review of the draft DMN RFP by the Business Modelling and Integration group experts, and a thought-provoking presentation by Barbara von Halle and Larry Goldberg of KPI on their KPI Decision Model which is proving very attractive to business analysts.

From an event processing perspective, “decisioning” is part of “event processing” in that it is the consumer of complex events: when you detect an event pattern you decide what to do with it. Of course, it is also extremely relevant to day-to-day business processes and operations…

Goals as related to processes (per Wikipedia)

Some of the conclusions the DMN RFP team came to this week:

• Decision modelling is more than just a complement to BPMN, and indeed the RFP will not over-emphasise the relationship between the two. Indeed, in some respects, the “goal-driven network” idea for business models is as applicable to process models as it is to decision models. Decision modelling could become the dominant analysis aspect in future years: consider a business process like “loan approval” and you don’t need a degree in computer science to work out that the business process is there just to support the business decision on whether to approve a loan!
• Barbara and Larry emphasised the need for metrics and business motivation in decision modelling. Monitoring decision events is of course yet another event processing task.
• The “business model” - “IT model” dichotomy can take many forms in a decision model, with the classic being the business analysis model being the logical decision structure or goal-driven network, using business terminology, with the underlying decision metaphors (such as decision tables - the first and obvious choice for the DMN RFP) being IT models. Transformations from things like SBVR to UML Class, and decision table to PRR, will be out of scope for DMN itself though - such transformations will either be subject to other standards or be vendor-specific. But they and the Model Driven Engineering ideal become much clearer using a DMN.
• The logical decision model or goal-driven network has ramifications for the inference rule engine business. I’ll blog on that separately!

So in summary: DMN is looking like it could be very useful. And I expect attendees at the RulesFest and BAForum conferences next month will enjoy the KPI show as much as I did. For those interested in decision metaphors, BRForum (alongside BAForum) also has the Decision Table World Congress…

This might seem an odd question, but there are 2 schools of thought here:

1. An event is a point in time.
   
2. An event is an activity that can take a period of time.

Taking the latter view, we can say things like:

• Earthquake MMM took place from date-time D1 to date-time D2
• Fraudulant act on account NNN took place from date-time D3 to date-time D4
• Flight QQ123 was delayed in the period date-time D3 to date-time D4, when it completed disembarkation time T1 late
• World War 2, an historical event, took place from 1 September 1939 to 2 September 1945.

The problem with this view is that activities, and therefore processes, can therefore be viewed as “events”, which in IT terms can lead to confusion and generalisation. And what about “historical events” like World War 2, which definitely have a duration. But in reality “world war” was a “state” the various nations affected found themselves entangled in - for sure it had a start event (invasion of Poland) and an end event (surrender of Japan), and many many events in between. And indeed many many “predictor events” (or even “causal events”) beforehand.

In event processing terms, we want to predict certain events - when will Earthquake MMM start, and with what strength? - as well as states - Flight QQ123 is now in a “delayed” state. In effect, in the real world, we are concerned not just with event patterns, but also state management and processing. Passengers might not care about the events that lead to their flight being delayed, but they may certainly care about being delayed!

The EPTS Glossary specifies events as points in time as “instantaneous events”. From the EPTS perspective, the 1929 Stock Market Crash was a complex event. At the time it was a “crashing state” for the Wall Street markets - within a period of instability, local rises interspersed with sharp falls. Top-to-bottom, the period covered Sept 1929 to July 1932, and an overall 89% decline in the Dow.

So perhaps History should be formalised, as a science, using event terminology?

I don’t normally have much to say on BPEL (as a language for orchestrated processes). A BPEL engine can be used to execute business processes and actions post-”complex event detection”, but at the end of the day its just a particular - albeit common and standards-based - technology for executing process orchestrations [*1].

On the other hand, state management of entities is particularly interesting for Complex Event Processing. In a nutshell, the state of some entity will often determine some event pattern detection, as well as the relevance of certain business decisions, operations / processes, and actions. CEP tools handle state, and some (like TIBCO BusinessEvents) actually allow developers to model state explicitly - usually for entity lifecycle management, including complex event pattern lifecycles…

It was therefore somewhat fascinating to find a new IBM initiative called BPEL4Data and an associated Business Entity Definition Language (BEDL) comprising of entities and state models (and indeed, almost MDM-like data management operations) [*2].

One trick I think the IBM team have missed is in tying themselves to (another reinvention of) BPEL. State models involve states and event-driven state transitions: to me this means that states are part of the behavior of entities, an active not a passive attribute. And conditional state transitions mean rules rather than processes. Ergo its no accident that TIBCO BusinessEvents state models are defined in an environment that combines them with events and declarative rules.

Of course BPEL - and orchestrated BPM - have their place and use cases - indeed TIBCO has many successful BPM customers, some of whom are combining entity models and states (in TIBCO BusinessEvents) to control workflow processes (in TIBCO BPM). There are indeed many patterns to combining event-based state changes with process orchestrations, and IBM’s focus on just one will be interesting to watch.

Notes:

[1] TIBCO’s BPM group of course has much more to say on BPM and BPEL …

[2] TIBCO followers will be bemused by the acronym overloading here:
- IBM BEs (Business Entities) are directly equivalent to TIBCO BE (BusinessEvents) concepts, with UML-based state models applicable to both.
- IBM BEs map via IBM BPEL4Data to BPEL business processes, whereas TIBCO BE concepts and states are directly executed in the TIBCO BE rule engine (with no BPEL intermediate step, if you like), with BPM processes as optional (downstream) activities.

Reading a paper from last year’s Knowledge Capture (K-CAP 2009) academic conference, I came across some references to various “event standards”. All of these were very domain specific, but 2 seemed they might have more generic uses.

One was Events-ML G2 from the International Press Telecommunications Council for registering “events as in conferences, meetings etc” (rather than the sorts of events the CEP world is mainly interested in). The event schema therefore includes properties such as phone and contact details, implicitly recording the observer’s data on the event (as opposed to some observer identifier from which that and other data could be gleaned, presumably). On the other hand they did have a nice test form!).

Event in Event Ontology

There was also an “Event Ontology” defined as part of a Music Ontology (!) project. Things started well when the authors stated:

This ontology is centered around the notion of event, seen here as the way by which cognitive agents classify arbitrary time/space regions, which is essentially the view expressed by Allen and Fergusson [or its HTML version via Google].

The next quote was less impressive though, seemingly going beyond abstraction and on into the realm of philosophy…

[..] events are primarily linguistic or cognitive in nature. That is, the world does not really contain events. Rather, events are the way by which agents classify certain useful and relevant patterns of change.

Reviewing their definition of event we see relationships between event and:

• place and time
• factors and products
• agents (acting on the events)

Presumably from the musician’s point of view, a set of notes (as events) may combine into a musical chord (an event product) - or in other words, agents combine events and context (”factors”) to define complex events (”products”). So not a million miles away from the EPTS’ labors on the EPTS Glossary, newly refreshed in a draft version 2…