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…

One of the interesting aspects of “complex event processing” is that “processing” typically encompasses MORE than just event pattern detection (in many use cases). For example:

• in algorithmic trading, you can detect a trade opportunity, but must decide whether to act on it immediately or refer to some risk management rules or process
• in airline operations, you can detect a solution to some passenger delay events, but you must decide whether to simply notify the gate manager or initiate some solution process
• in customer management / CRM, you can detect a customer “change in state” event pattern, but must decide whether to respond with an appropriate offer or simply update the customer record
• in smart grid systems, on detecting a potential transformer outage indicator event pattern, you must decide whether and how to reduce load on the system versus prioritising the maintenance team
• etc etc.

Of course, the process of detecting patterns, making decisions, and instigating appropriate reactions is rarely expressible in a simple orchestration or sequence diagram - event processing is continuous and decisions can simply affect the types of patterns we are looking for. This is why CEP tools often use declarative constructs for defining pattern and decision knowledge, and multiple paradigms / event processing element types or languages for event detection and event-based decisions.

Checking through the presentations and workshops for IRMUK’s Business Analysis (and BPM) 2009 conference last month, I thought it would be interesting to see much focus there was on business event modeling.

Probably the star (from the event perspective) was James Archer from the Royal Borough of Kensington and Chelsea (in London, UK) who presented how a using new requirements approach saved a particular BPM project. The interesting aspect here was the inclusion of (and emphasis on) modeling context (in terms of stakeholders and their interaction events) and the individual business events involved. James uses a particular requirements template, although the spec doesn’t seem to particularly emphasize the business events angle at all. Oh well…

Of the other workshops and presentations, there was a preponderance, as one would expect, of the “process view” of event modeling.

Roger Burlton and Paul Harmon’s workshop on “Business Process Architecture” was typical of the “BPM view” but made some concessions to the “business event” perspective. This included a “business event view” to model the scope of business processes, as an alternative to the process relationship view. Business events though meant the start or end of processes, and that’s it. KPIs (which we in the CEP world can usually consider as “complex events”) were treated differently - as measures of activities from rules and processes (vs objectives).

Dee Carri’s “Principles of BPM” workshop only mentioned “event” when explaining BPMN, while Kathy Long’s “Process Modelling and Analysis Lessons Learned” followed the view that business events’ primary role was to start and end processes.

Ron Ross’ workshop on “Business Rules, Analysis and BPM” unfortunately missed events and temporal effects in his introduction to business rules (or indeed events as the driver of rules) - however, events were clearly marked as the main artifact in the “when / time” column in the Zachman Framework that Ron referred to. Ron adapts Zachman to his own Proteus business rule framework which has:

• Row 1 (for sponsors) covers business events as the “scope” for the “when/time” column.
• Row 2 (business model) has these business events mapped to “business milestones” (which I would argue is a specific strategic business event, not a generic business model artifact for any business event - but probably I am missing the point); these are used to define “timings” in business rules.
• Row 3 (”computable model”) maps these business events and milestones to state transition diagrams.

Chris Bradley and Tim Franklin of IPL gave a workshop introducing BPMN (version 1 anyway) and provided a top-down view of notations useful for business processes covering Input Output, Agent, State and Workflow diagrams. Interestingly their “BPMN in a nutshell” was “event occurs, prompts a decision that invokes an activity“… they then covered BPMN event types in some detail:

• start events (circles with a thin single border) such as message, timer, rule (invokes event), link (process sequence event), and multiple (as well as a null / no info event)
• intermediate events (circles with 2 thin borders placed on activity boundaries) which can be the same type as start events, but also covers error and compensation events
• end events (circles with a thick single border) are the same as intermediate events, but add a terminate event and subtract  timer and rule events.
• Editorial note: BPMN 2.0 adds non-interrupting events, as well as exception (event) driven subprocesses…

Alec Sharp presented on “Process Redesign to IT Requirements” and covered business events in his own methodology under Business Services: using event analysis and state transition analysis alongside business rule analysis to list events and services. His “good process” model was the same as in the BPMN workshop: events drive steps-and-decisions drive results. Alec also picked up on the role of events in use cases.

Roger Burlton’s keynote on “BPM Perspectives” was very neutral (for a BPM conference) and mentioned the “event point of view”, as well as identifying messages, messangers and timetables - albeit from the process worker / workflow perspective, although these also apply at the automated event processing level.

Frits Bussemaker’s graphical presentation on “Corporation to Cooperation” didn’t have many words in it, but a key slide was “time is the new currency“…

In summary, it seems the event perspective has still to evolve in business analysis and modeling in the mainstream (as represented by this conference, in any case). But there were some good ideas here.

Draft Reference Architecture

Some folks may have seen earlier updates on the EPTS Reference Architecture work. Well, the latest (Architect role Functional view) draft seems to be getting some approval (so far) among Reference Architecture Working Group members. Some of the terminology may change slightly to conform to (or influence) the EPTS Glossary; other roles and views are still in progress.

EPTS hasn’t set up a public review mechanism yet, so participants’ blogs will have to do: feedback posted here will be posted back to the working group wiki. Once the Working Group is satisfied with this, the Steering Committee and membership of EPTS will vote on it, and then it can be made “official”.

Business Event Processing Elements

One of the interesting and unexpected customer use cases for TIBCO BusinessEvents is “business modeling”. The idea of complex (aggregate) business events, and the related definitions of concepts, state models and rules, provide a powerful representation tool for business modeling that is also very “easily mapped” to the deployment level - as indeed it must be given that TIBCO BusinessEvents is primarily a deployment platform.

Of course, as far as  I know, no-one use TIBCO BusinessEvents just for business event modeling.

Yet.

But the merger of “business modeling repository” and “executable event processor” is  for sure coming closer. The BPM folks have been promoting this for a while now - defining business level models that in some cases are then annoted further with execution details to become managed workflows, or with IT annotations to become automated processes. But of course the “process flow” is but one view of the business world, with other views (such as events, states, rules, decisions) often being just as useful.