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…

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