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 use cases for TIBCO CIM (TIBCO’s MDM product), which is incidentally part of the same TIBCO Business Optimization product stack as TIBCO’s CEP product BusinessEvents, is managing some of the artifacts used in event processing in some applications. Now this may seem strange: why should event definitions, event patterns, or decision rules be considered “master data”? On reflection, though, it might seem strange to even ask that question, as if one is treating things like event patterns and business rules as input data to an application, then these are surely as “master” (as in “business critical”) as it gets.

Lets see what MDM brings to the table: from TIBCO’s MDM page we see:

• MDM ensures that master data (assets, people, locations) is accurate and consistent across multiple transactional systems.
  • Well, you certainly want event processing definitions, patterns and decision rules to be accurate and consistent. These may require more specific verification and validation over simpler data sets, but such tests are themselves part of the “process”…
• It enforces the necessary processes, policies, and procedures so that clean data stays clean.
  • So even if we have more complex verification and validation processes, these can be included in MDM.
• It allows organizations to manage the complex hierarchies and relationships within their data such as the relationships between two products, a customer and a vendor, general ledger hierarchies, and so on.
  • And also relationships between multiple versions of events, patterns and decisions and each other, presumably. At a more complex level part of the management means hierarchies of processes and their inter-relationships…
• Through effective MDM, organizations can eliminate errors, become efficient in their business activities, and accelerate critical processes such as new product introductions, service provisioning, cross-sell/up-sell, and customer service.
  • If the business activity is updating / maintaining their event processing applications, then maintaining consistency and associated artifacts across services makes sense too.
• Additionally, MDM builds a data services foundation that supports IT initiatives such as SOA and BPM.
  • And, er, CEP.

And of course if I am treating / storing event processing models as master data / in MDM, then I can also treat / store other changable, critical (BPM) process models as master data / in MDM, too. The MDM system becomes an IT repository as well as a business repository.

Food for thought, anyway!

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.

My thanks to Robin Cover at standards body OASIS for pointing out to me the OASIS Symptoms Autonomic Framework initiative. From the OASIS TC page, SAF is meant to:

“… integrate information and processes across the organization … by defining, enhancing, and maintaining a standard XML-based framework that will enable the collection, detection, isolation, and remediation/optimization of the operational or business characteristics of complex systems with applicability to both IT and non-IT domains including operational and service management, governance, and security.”

If that paragraph proves difficult to digest, the overview goes on to say more succinctly:

“SAF is intended to provide a common language for exchange of event-driven data in a distributed-computing, multi-vendor environment.”

In other words this is either a DSL or XSD  for “control events”, of the type handled by TIBCO’s CEP-based ActiveMatrix Service Performance Manager (i.e. the autonomic services’ performance policy engine) and its cloud (TIBCO Silver) oriented derivative. So it should certainly be targeting complex event processing of these control events.

The SAF Charter explains the SAF goals further as:

“Ensure that the specifications can be applied to various sources of event data, enabling a methodology to perform pattern matching, diagnostics, and analysis in order to achieve a timely and accurate resolution of a wide range of IT and non-IT situations.”

Sounds possibly a little wide-ranging, but we assume the 3 (as of Oct09) member organizations know where they are going with this.

The charter goes on to describe the medical-based terminology used in SAF, including  “symptom” as a current state, “syndrome” as a collection of symptoms, “protocols” used to generate “prescriptions” which in turn are (data) used to confirm, remediate or optimize a syndrome. Syndrome confirmation is (naturally enough!) via a “diagnosis” effected through  “validating Symptoms”. One wonders what ailments the authors had when coming up with this healthcare-analogous vocabulary!

The architecture roles mentioned also stay in the “doctors and nurses” theme: we have a Syndrome and Protocol Catalogs, a Symptom Store, a Diagnostician, a Practitioner (to administer Prescriptions), and a Case Manager (general manager). Probably someone could do a reasonable mapping of these to the EPTS Glossary and Architecture work…

Looking at the White Paper from the SAF docs collection we see a much closer correlation to the CEP world with use cases of “Denial Of Service attacks” (a.k.a security), “identity theft” (i.e. fraud), energy industry “data analysis”, and manufacturing “process optimization”.

Overall this looks an interesting effort - interesting in that the authors have found a compelling reason to develop the SAF standard, rather than the content itself - but one would expect that persuading end-user organizations to comply with a SAF approach to automating diagnostics and remedies will be a tall order. If the standard does prove compelling, then Complex Event Processing tools like TIBCO BusinessEvents should have no problem in reading SAF payloads, applying SAF roles and implementing SAF-type implementations. So one to keep an eye on, then…

Ron Ross’ latest edition of his guidebook, Business Rule Concepts, expands further on the relationship between enforcable business rules and the events that cause their evaluation.

Ron uses the example of a business rule that might apply in a workflow: “a customer must be assigned to an agent if the customer has placed an order”.

This rule needs to be evaluated on the event: “Customer places order”.
But equally it applies when: “Agent leaves” (or becomes unavailable).
And also to: “Customer order is cancelled”
… although usually this sort of exception would probably be covered by a business rule too.

Ron’s term for these “events derived from business rules” are “flash points”, citing “a business rule generally produces 2 or more flash points when it needs to be evaluated”. This is useful for mapping (or modelling) from business rules to the relevant events one needs to be concerned with.

Probably more importantly, this also shows a short cut for researchers looking to automate the transformations from such business rules to IT systems. Simply (a) identify the affecting events (sorry, “flash points”) and (b) use these events to drive an evaluation of the rule concerned. The latter of course is ideally suited to some highly scalable event-based rules engine …

Ron’s book can be found on his web site or Amazon.