Events and semantics

I spent the last few weeks attending a number of conferences. That gave me an excellent opportunity to talk to customers, discuss with prospects, get an updated view on the industry and the competition.

I also got the opportunity to attend a number of interesting presentations. In particular, at Business Rules Forum (http://www.brforum.com), I attended a peer discussion hosted by Paul Haley (http://haleyai.com/wordpress/). Paul is a well known luminary in the Artificial Intelligence world, and a vocal promoter of a renewal of the knowledge management software landscape.

Paul and I got into a little bit of a debate around how badly the BRMS world – and to a certain extend the so-called CEP world – are faring at dealing with the true complexities of dealing with business knowledge at large. I think our disagreement comes mostly because of the fact that we are looking at different levels in what the software stacks provide. BRMS vendors provide multiple expression layers – Paul focuses on the lowest level one which is misleading because they provide model-driven layers significantly above the low level syntax based ones which enable safe, guided, business compliant and friendly expression of business logic. That’s the key to their success, and it’s only when those layers were introduced that the non-existent BRMS market started growing into its current state. Coming from an AI vendor myself, and having been at the core of that transformation, that’s one thing I am sure about.

Towards the end of the discussion, we got into the importance of event semantics / ontology of events. Great, I absolutely agree.
But what I do not agree with are simplifications that end up leading to slogans such as “a process is an event” or “a decision is an event”. That just creates semantic confusion, and muddies the waters for everybody. And it’s important, because few are those who can spend all day thinking at the level of Paul who knows very well what he means by those slogans, and can easily delve into what they really cover – almost everybody else will be confused. As confused as those who mistake an implementation (OOP-based) with a concept (“an event is an object”).

We need to be careful.

I tend to be more dogmatic about the usage of the terms. Here is what I would say:

- The core notion is that of state of the business. Take that literally. At any point in time, the business that is supported through the implementation at hand is in a given state, and that state has an explicit and implicit representation.The state needs to be fully accessible – we should be able to query against it, to archive it, etc…

- Any change to the state of the business along any dimension represents a transition, which corresponds to a business event.I resist extending the notion of a business event to anything else than a transition of state of the business. In this view, events are dual to states. I can reconstruct the state of the business at any point in time if I know the original state and the complete sequence of events up to that point in time. Conversely, I can re-generate all business events if I know the state of the business at every point in time from the original state to the current state.From this perspective, events have a context in which they occur (the state of business at occurrence time, occurrence time and “location”, time and “location” referential, source, etc…). But what they do not have is duration. This is not illogical – if you consider that your business is moving from state S1 to state S2 and that that takes a given duration, the only reason why the duration is there is because you can observe the state of the business between S1 and S2, which basically means you can decompose your transition in a series of stepwise transitions that you cannot decompose more.This approach has been taken successfully in many real time systems, including some distributed real time systems in which the notion of event is central.

- In this view then, the overall decomposition of a modern enterprise application is much simplified with respect to the happy mess we seem to have today, with overlaps everywhere.
o The business application has an explicit / implicit business state which is always accessible. Typical data management, profile management, state management components play a key role here.
o Changes in state are monitored, sensed, correlated and transformed into business events.This is where event correlators, pattern matchers, etc… play a key role.
o Business events trigger the evaluation of what to do with the event through the execution of business decisions. That is where decision management – essentially built around the BRM (business rules management) capabilities of today – plays the key role.Note that these decisions do not change the state of the business – they read it, they take into account the event (meaning they know what the state was before, what the event is for, what the resulting state is), and they provide the instructions on what to do next.
o The business decisions are executed through business processes. These processes are those who change the state of the business, triggering further events and feeding the same cascading series of steps.This is where BPM (business process management) plays.And to Paul’s point, the execution of a business process, to the extent that it does change the state of the business, manifests itself as business events. But it’s not a one to one mapping, and, definitely, a process is not an event.

This corresponds to http://www.edmblog.com/weblog/2008/11/an-attempt-at-demystifying-cep-bpm-and-brms.html as well as http://architectguy.blogspot.com/2008/11/more-on-cep.html.
This is a simple model. It has the merit that it does not confuse notions.

Paul addressed many other points during that brief session – many of which I agree with and some that I think warrant further discussion. I will cover them in later posts.