TIBCO has a long way to go in making its business optimization offerings less technical, but for those that can tolerate less alignment between IT and the business than may be ideal, TIBCO is leading the way in integrating technical agility with business visibility.

It will be tough for Oracle or IBM or SAP to close the gap with what TIBCO has.  Don’t be surprised if rule-based event-driven business processing drives the acquisition of TIBCO by one of these over the next two years.  The growth rate certainly justifies it!  And it won’t stop.

After the talk I spoke with Jan Verbeek and Gartjan Grijzen of Be Informed and reviewed their software, which is excellent.  They have been quite successful with various government agencies in applying  the event-centric methodology to produce goal-driven processing.  Their approach is elegant and effective.  It clearly demonstrates the merits of an event-centric approach and the power that emerges from understanding event-dependencies.  Also, it is very semantic, ontological, and logic-programming oriented in its approach (e.g., they use OWL and a backward-chaining inference engine).

They do not have the top-down knowledge management approach that I advocate nor do they provide the logical verification of governing policies and compliance (i.e., using theorem provers) that I mention in the talk (see Guido Governatori’s 2010 publications and Travis Breaux’s research at CMU, for example) but theirs is the best commercially deployed work in separating business process description from procedural implementation that comes to mind. (Note that Ed Barkmeyer of NIST reports some use of SBVR descriptions of manufacturing processes with theorem provers.  Some in automotive and aerospace industries have been interested in this approach for quality purposes, too.)

BeInformed is now expanding into the United States with the assistance of Mills Davis and others.  Their software is definitely worth consideration and, in my opinion, is more elegant and effective than the generic BPMN approach.

Excellent presentations on complex event processing by Paul Vincent of TIBCO and Mauricio Salatano who showed simple, effective integration of events and rules using Drools.  Mauricio’s was a good demo and Paul’s slides are worth perusing once they go on-line.  (Some comments from Carlos about Paul’s, Mauricio’s,  and my presentations are here, here and here, FYI.)

Christian St. Marie and Hugues Citeau each of Ilog (IBM) on improving RIF support in JRules and the worthy ONTORULE project, respectively.  Both presentations confirm the gulf between production rules and sufficient logical expressiveness to support natural language or natural logic knowledge management, but IBM is clearly aware of  and trying to address the challenges raised in my presentation.

…we need to take a different view of BPM technology and try to see how it can be used to make knowledge-based business more ‘operationally responsive’… …the potential for creating real business value by bringing together the two disciplines of event processing and BPM is substantial…

As Paul notes, this follows Progress’ acquisition of Savvion (i.e., CEP vendor buying BPM vendor). 

I am glad to see other leaders pursuing the vision of knowledge-based enterprise.  As I discussed, IBM is getting there (but SAP seems out of the picture).  Will Oracle take the lead?

Here is the slide that triggered the controversy:

The point of this slide was to show how the current “state of the art” in business rules forces users away from managing knowledge and into coding with “if-then” structure.  Carlos argued in favor of situating knowledge in what he characterized as “the higher level business process”.  I maintain that software should be able to figure out where knowledge is relevant and put it there in the proper manner.  That is, the various “if-then” statements that can be derived from a more natural and expressive logical statement should be derived by machine.  Otherwise, the sales pitch that BRMS are accessible and usable by non-technical people is not only wrong, but potentially misleading.  That is, I think that knowledge is higher-level than flow-charts, although Carlos sees things in the other order.  Neither one of us denies the other, but I am comfortable that the higher ambition is to empower non-programmers with knowledge management that drives automation rather than to provide automation that limits the codification of knowledge to technical personnel. 

Carlos presented 4 bullet points in his post.  I think these were triggered by the following slide:

The last of these bullets relates to comments above and the first few to the perception that BPM is more important than CEP.  Overal, these are addressing the ignorance of most decision making applications of rules with regard to the current event or state of a business process in which the are embedded.  It is clear that Carlos and I are in agreement that this is an important architectural aspect of succeeding with the three technologies.

I agree with Carlos’ first two bullets concerning the need for events and state of processes to be accessible to logical and policy-based knowledge.  His third bullet, however, exposes one of the deep challenges facing convergence of business rules, processes, and events.  In this bullet Carlos implies that rules are for decision management only.  He misses that knowledge, which is higher level than rules, may define or govern the process itself.   I would like to emphasize here, however, that we agree on the need for a representation of events, state, and processes to be shared across the event, process, rule technology stack. 

Unfortunately, Carlos reiterates the Fair Isaac mantra that events are not core to process or the stack, citing colleague Carole-Ann Matignon, but are peripheral to rules for decisions in the hands of knowledge workers and BPM “tools” in whoever’s hands.

This is a problem with the BRMS and BPM industries as a whole and one that I hope Progress, if not TIBCO, drive home commercially this year.  Carlos says, in line with his other thinking, that “a process is not an event”.   This is consistent because if processes are events then Fair Isaac’s position would be inconsistent and untenable. 

As he wrapped up, Carlos said “and, definitely, processes are not events”, presumably in response to this slide:

Here is my take on the title of Carlos’ post:  Events and semantics.

An event is something that happens.  The big bang was an event.  The civil war was an event.  The swearing in of President Obama was an event.  The beginning of this day was an event.  Does anyone disagree at this point?

OK, if you didn’t disagree… Is the occurrence of a war is an event?  Is the swearing in of a president an event?  Is the beginning of the occurrence of something an event?  The answer is yes, of course!

Is war a process?  Is swearing in a process?  Yes.  Is the beginning of an occurrence a process?  Well, it depends if you are referring to the instant of time at which something begins or the process by which it begins.  If you are referring to an instant of time, as in the start of something (rather than its starting), then you are referring to an event but not a process.  That is, processes take some time.

In fact, processes are events that take time.  If it helps, you can always throw the word “occurrence” in front of “process” to distinguish the instances of processes from their types, as in the distinctions between abstractions and realities, concepts or classes or sets and instances or members.

But the fact remains, processes are events.

We’ve written several times about the artificial distinction between CEP and BPM, their inevitable convergence, and the immature integration of business rules with business process management and event processing that inhibits knowledge-driven governance and decisioning.

We predict that IBM will soon abandon its hair-splitting between business event processing and complex event processing and make a deeper move in the CEP space than its partnerships with Coral8/Aleri and Streambase (we don’t see IBM’s acquisition of AptSoft as addressing the need).  It will also be interesting to see how closely IBM integrates Ilog with its BPM middleware and the Lombardi applications.  Unfortunately, Progress is unlikely to pressure IBM or advance the knowledge-driven enterprise to the extent that a move by Oracle, SAP, or TIBCO could.  And, although they each have some position with regard to rules, conversations with Oracle, SAP and TIBCO continue to indicate incremental approaches without any bold vision for knowledge-driven enterprises where IBM owns the vision and thought leadership.

To date, IBM and SAP have similar messaging of their primary rule-based tools with respect to their middleware platforms.  That is, Ilog is positioned with respect to WebSphere as YASU is positioned with respect to NetWeaver.  Of course, Ilog is the stronger product.  IBM also has better marketing, both in WebSphere versus NetWeaver and Ilog versus SAP’s now non-descript rules engine.  To put it another way, SAP almost ignores policy and decision management.

It is worth noting that SAP uses a second-generation decision-oriented scripting language called “Business Rules Framework” within many of its applications.  SAP is working on relating this pervasively applied, internally developed, procedural tool with its acquired rules engine.  I don’t see much to indicate that SAP will take an effective position versus IBM or Oracle in middleware decisioning, however.  Still, they seem aware of the need to formulate their strategy.  Perhaps we’ll see something in 2010.

Oracle clearly lags IBM in middleware decisioning and suffers from a convergence challenge among its Haley, Ruleburst, and JESS rules engines that are used in its CRM, public sector, and middleware offerings.  However, Oracle is well ahead of SAP in its decisioning capabilities, both within its applications and in its next generation of Fusion and Fusion-based applications.

But IBM, Oracle and SAP seem out of the CEP picture.  So now we have Progress promising the most robust platform for events, processes and rules.  Unfortunately, Progress/Savvion will not be as accessible as IBM or Oracle offerings.  That is, IBM and Oracle, by way of their acquisitions of Ilog and Haley, are much better suited for policy and decision management.

We have written previously that robust business process management must address event processing and that event-driven business processes tend to have many fairly simple processes that are triggered and orchestrated by events and rules.  Tools that ineffectively require users to map policies and rules into flow charts (including almost all CEP and BPM platforms) fail to raise business management from the procedural to the knowledge-driven enterprise.

The CEP vendors, including Progress, TIBCO, Coral8/Aleri, and Streambase, need to consider the analyst-accessible, linguistically-oriented approaches of IBM and Oracle in order to cross the same chasm that business rules vendors crossed last decade.  The same remains true for BPM vendors, although it is nice to see that Progress has selected one that takes rule integration seriously.  IBM is clearly on the move and Oracle is best positioned to respond, but they lack events capabilities, both in their platform/stack and in their knowledge management capabilities.

Of the CEP vendors, TIBCO is best positioned because it has rules and BPM capabilities now.  It will be interesting to see if Coral8/Aleri or Streambase make any moves towards accessibility and business process management in 2010.  IBM is clearly dictating this is the game this decade.

1. Reasoning at a point within a [business] process
2. Reasoning about events that occur over time.
3. Reasoning about a [business] process (as in deciding what comes next)
4. Reasoning about and across different states (as in planning)

Enterprise decision management (EDM) addresses the first.  Complex event processing (CEP) is concerned with the second.  In theory, EDM could address the third but it does not in practice.  This third item includes  the issue of governing and defining workflow or event-driven business processes rather than point decisions within such business processes. 

Business applications of rules have not advanced to include the fourth item.  That is to say, business has yet to significantly leverage reasoning or problem solving techniques that are common in artificial intelligence.  For example, artificially intelligent question and answer systems, which are being developed for  the semantic web,  can do more than retrieve data – they perform inference.  Commercial database and business intelligence queries are typically much less intelligent, which presents a number of opportunities that I don’t want to go into here but would happy to discuss with interested parties.  The point here is that business does not use reasoning much at all, let alone to search across the potential ramifications of alternative decisions or courses of action before making or taking one.  Think of playing chess or a soccer-playing robot planning how to advance the ball on goal.  Why shouldn’t business strategies or tactical business decisions benefit from a little simulated look-ahead along with a lot of inference and evaluation?

Even though I have recently become more interested in the fourth of these areas, I expect the audience at the business rules forum to be most interested in the first two points above.  There will also be some who have enough experience with complex business processes, which are common in larger enterprises.  These folks will be interested in the third item.  Only the most advanced applications, such as in biochemical process planning, will be interested in the fourth.  I don’t expect many of them to attend!

The notion of enterprise decision management (EDM) is focused on point decision making within a business process.  For enterprises that are concerned with governing business processes, a model of the process itself must be available to the business rules that govern its operation.  I’ve written elsewhere about the need for an ontology of events and processes in order to effectively integrate business process management (BPM) with business rules.  Here, and in the workshop, I intend to get a little more specific about the requirements, what is lacking in current standards and offerings, and what we’re trying to do about it.

As I’ve written previously, the distinction between business process management (BPM) and CEP is not well principled but arises from somewhat arbitrary, historically distinct emphases on technology and market segmentation.  Any modern business process system must handle events and discussing events processing without considering processes is a limiting perspective.

Most people would intuitively agree that events trigger business processes.  For example, a business receiving a payment or a letter from a customer or vendor is an event that triggers the process of crediting and depositing that payment or considering and responding to that letter  Hopefully, we are moving beyond academic arguments about the distinction.  (I am ignoring here the algorithmic applications of streaming event processing as in trading in the capital markets.)

So, in current BPM, which should include CEP capabilities, we want decision management that is less ignorant about where it is in a business process and that is aware of events that trigger processing.  That is, we want policies that talk about the state of a business process and the occurrence of events.  The surprising thing is that current business rules management systems (BRMS) and related standards are of no help.  Tools from the leading business rule management system (BRMS) vendors, including Oracle and IBM / Ilog, have no intrinsic understanding of processes, events, or time.  And, outside their integrated BRMS, tools from BPM vendors don’t let us “talk” about anything.  They help us structure flows and code, but they rely on integrated BRMS to manage rules.  The rules include the policies, in which the business “talks”.  The BRMS is where English sentences (or something that increasing looks like English) are managed as the enterprise repository of policy. 

Note that there is nothing special about English.  It’s just easier to read than “natural language”.  Another limitation of current policy management systems is their lack of language independence, which requires automatic translation, which is much simpler if the sentences are unambiguously interpreted with logical rigor, but I digress from the point of this missive…

Some examples will help here.  Suppose we check the credit of an applicant at various points within the collection of processes that constitute how our enterprise conducts business.  We might have policies that are concerned with how we consider or act based on credit information in originating a loan (or policy) versus in renewing  or re-pricing one.  In effect, our policies want to talk not just about evaluating credit or pricing risk, but to do so in the context of a larger business process.  To be more specific, business policies that sound like, “if evaluating credit in the course of pricing a renewal…” or “if evaluating credit while considering a new policy…” are quite natural.  These statements define or govern the business process.  They also talk about where the decision is being made within a business process.  

• BRMS need to understand the context of the business process in order to make context-sensitive decisions.
• BPM needs to tell the BRMS what it is going on from the top-down for the BRMS to understand the context of a decision.

So, we need the BRMS to be told things like:

• I am considering a new applicant.
• I am considering the renewal of a contract.

In these statements, the pronoun “I” is the overall enterprise system contemplating its own actions.  If you find that awkward, just substitute “while”  to obtain what you might “say” in a business policy.  Ideally, the language your policy management system would not be overly stilted but would understand any of:

• while considering…
• during consideration of …
• if considering…
• if an … is being considered for…

and so on.  Otherwise, users will find authoring such statements cumbersome.  Reading and understanding English, even if it is a bit stilted, is easy for people.  We’re built to communicate, after all.

Now consider what you would want to say if you were writing policies that involved events.  In this case, the event has already occurred, such as “we received a letter from a customer…”.  You do not want to say, “if I am receiving a letter from a customer…” (which could only be true for an instant that passes quickly unless it was stated as “… I will be receiving…”).  But if we can only refer to events in past tense, how do we talk about a current event that needs to be handled versus another event that we have already handled?

Many business to consumer (B2C) applications, such as pharmacy benefits have this problem, for example.  To a pharmacy benefit manager (PBM), like Medco or Express Scripts, the swiping of an insurance card at a retail pharmacy is an event to be processed.  Any individual beneficiary has a history of such requests.  We can try to model the current one as a request and the prior ones as transactions, but this becomes awkward for less formal or technical people who want to talk about how many requests someone has submitted over a period of time, for example.  The truth is that there is a history of requests per beneficiary and technical limitations should not obscure this fact.  We should be able to distinguish the current request from prior requests, as in the following:

• a request that has not been processed is current or pending
• if processing a request…
• if a request for … is being considered…

Note that “request” is a deverbal noun, which is to say that the root form is the verb (in this case “to request”).  A request is a reference to an act of requesting that may be in any tense.  The sentences above reflect this in the use of an additional verb that carries the tense.  Of course, this is all completely natural since every sentence has a verb.

The most dangerous expression might be:

• if … requests …

and yet this is the form that almost all BRMS would handle today!  This is dangerous because it is too ambiguous about when the request occurred.  It would be better to say:

• when … requests …

provided that the system understands that, unlike “if”, “when” involves time, but even “when” is less than ideal since an event has always occurred in the past by the time it is processed.  On the other hand, we might define when a request occurs as in:

• a request occurs from the time it is received until it receives a final response.

This assumes that “when” combined with a verb in present perfect tense means during the period of time in which the process referenced by the verb continues.  And this is an important point:

• An event can be an occurrence of a process.
• An event may have a duration.
• “When” may refer to an interval of time.

Events are not necessarily processes, but may refer to instantaneous points in time, such as in the following:

• When a request is received…
• When the processing of a request begins…

but these uses of “when” refer to a point in time before any action can be taken in response to the event, therefore the sentences should only conclude with statements of implied, necessary, or modal logic and should not include any statement of action. Of course, a competent BPM/CEP/BRMS would understand all this and advise the author of a policy that suggests taking action in the past.

As we proceed through these examples our intuition should be building the understanding of the first three points made above.  Processes and events and reasoning about or over time are completely intertwined in nature and separating them between BPM and CEP and BRMS systems is completely artificial and hopelessly limiting.

So what is the solution?  I suggest it is a knowledge management  system that understands the following:

• 1. Policies that use tense.
• 2. Policies that refer to events using deverbal nouns.
• 3. Policies that refer to occurrences of processes as events.
• 4. Policies that refer to potential action using future tense, possibly by way of modals.
• 5. Policies that refer to occurrences of processes using verbs such as “begin”, “end”, “start”, etc.
• 6. Policies that refer to occurrences of process using words like “during”, “while” and “when”
• 7. Policies that refer to events using prepositions like “by”, “before”, “after”, and “when”

The natural language technology to parse such sentences is widely available using many approaches.  I am happy to discuss that with interested parties.  The second step that needs to be addressed is transforming the logical interpretation of such sentences derived from the natural language system into the underlying execution architecture, which includes a process engine and a rules engine that must be appropriately integrated.  That integration involves the informing of the BRMS about the state of the business process and the actions that may be taken which may be expressed as processes in the BPMS.  I’ve written elsewhere about this in more detail and am also happy to discuss it in more detail with BPM or CEP practitioners, product managers and architects.

Understanding events and occurrences of processes as events adds a great deal of power to policy management.  It allows statements of policy to reference and consider the context of business processes.  It allows statements of policy to reference and consider how to handle events in the context of business processes.  And, if it is done with adequate natural language understanding, it accomplishes this integration of BPM and CEP within a single policy management system.

Although I had hoped to cover the fourth point made first above here, I now prefer to conclude with a brief discussion about reasoning over time.  I will strive to cover reasoning about potential states of a process another day.  It is interesting but rigorous material that requires (in my opinion) architectural support that is lacking from current rules engines, whether production rule or logically based, even if the situational or event calculi are good formalisms.

Reasoning over time is pervasive in CEP.  In the pharmacy benefits management domain, for example, coverage is commonly limited based on the history of transactions.  For example, a policy might limit the amount of refills over a period of time.  This involves aggregation over a number of events, each of which is the result of handling a prior request.

Very few knowledge or policy management systems understand that transactions are processes, occurrences of which can be viewed as events.  For example, is “order” an noun or a verb in your enterprise applications?  Our technology has biased us to thinking about objects, which drives our modeling towards nouns and away from verbs.  Our technology biases us against modeling events and processes well!  And it shows up, insidiously sapping productivity and accessibility.

The lack of ontology of process and event in current BRMS not only precludes the kind of integrated BPM and CEP I am discussing here, it also limits the ability of current BRMS to automate policies that consider what has happened in making decisions in the present.  For example, a statement like:

• if a medicine has a maximum therapeutic dosage over a period that is less than the total dosage of that medicine requested by a member over the same period then…

is beyond the capabilities of current offerings.  Authority understood some grammar about time but did not understand that events, such as a request, occurred in any deep sense.  So it could automate a sentence like:

• if the total dosage of a medicine requested by a member on a date within the last 90 days exceeds the maximum quarterly therapeutic quarterly dosage for the medicine then…

but understanding why it understands one sentence and not the other is too much for many authors to tolerate, let  alone understand.  The essential reason is that we sold the company before extending Authority’s ontology to include events and revising its parser to understand that both verbs and their deverbal nouns referred to events (including occurences of processes).

The bottom line here is that a quantum leap in natural language processing of business rules is needed.  Fortunately, this is not a quantum leap for natural language processing itself.  It is well-established that sentences are parsed into representations of events in which noun phrases play semantic roles, such as the following:

• agent or counteragent
• donor or beneficiary
• patient or “experiencer”
• causer
• instrument
• locative or time
• source or destination

where quite a few prepositions relate to more refined aspects of time and location, such as at, on, during, by, before, after, in and so on.   The critical thing for processes and events is that they occur in time.

Realizing this quantum leap in policy management and knowledge automation is really pretty simple.  Take an approach such as Authority and extend its core, upper ontology with the semantic roles and the concepts of events and processes.  Then extend its relation-centric parsing with even-centric parsing (both are needed).  A few more steps, notably handling metonymy, and the next generation of knowledge management and automation that provides the integrated understanding of time, events, and processes discussed here becomes a reality.

That’s what we’re patiently working towards.  And we’re doing it in as engine-independent a manner as practical so that we can leverage standards like RIF and SBVR.  It’s all about the knowledge.

Finally, we are looking for collaborators who would like to learn more or help, and, perhaps, get involved in leveraging the solution or its underlying technology.

Ask them the question that drives CEP people crazy!

Last fall, at the RuleML conference in Orlando, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.  

1. Apparently, the broader OMG feels the same need for “event semantics” we discussed in Florida.
2. In addition, BPMN users indicate that too many event types complicate process modeling.
3. Finally, Bruce Silver dives a little deeper in two recent posts, one which responds to the authors of the BPMN survey and the other discussing whether BPMN will actually become portable, among other things, including events.

For me, the Great BPMN Debate boils down to two things:

1. Whether BPMN has too many features
2. That BPMN is missing semantics

I like BPMN.  I wound not want to sacrifice much.  But as a customer, I would think interchange is critical.  Regrettably, Mr. Silver points out some problems serializing to XPDL and other issues with vendor coverage.  We are a ways from effective standards for rules or BPM, it appears.  By effective, I mean standards supported by vendors that actually facilitate interchange between vendors.

1. XPDL may not be enough for BPM.
2. Rule vendors at the Business Rules Forum openly agreed that PRR is too low level for effective interchange given all their value-added (which I do not question)
3. RIF will be much better than PRR but it will still not facilitate effective interchange between BRMS vendors
4. SBVR has little traction and no effective implementation (yet)

One problem with all these standards, and even the web ontology language (OWL), is that they lack a common ontology.  That is, they are syntax lacking shared semantics.  Until they share some semantics, integrating or interchanging between them will remain imprecise , unproductive, and overly technical.  Everything but technical rules and models (e.g., vocabulary) will remain locked in.

BPMN is overwhelmed by events

Just reading Mr. Silvers post, you find start and end events, throwing and catching events, intermediate events, exclusive events, timer, message, error and terminate events.  And there are more.  Too many, BPMN users agree, according to the survey cited above.

How many different kinds of events are there (or should there be)?  For now, I’m going with 2.

What is an event?

Ask any complex event processing (CEP) vendor!  It will drive them crazy or you will get a long-winded answer. Or, like me, they might say that it is something that happens or occurs.

At first, most people think of events as occurring at a point in time.  After some discussion, however, most people agree that events are things that we view as occurring instantaneously, even if they take a day, such as last year’s 4^th of July picnic, which we might also call an occasion.  Events, like the lights going on or a starting gun firing, might indeed be effectively instantaneous, in which case we would not call them occasions.

There is more to the difference between occasions and instantaneous events, however.

What occurs or happens?

Is an event an occurrence or something that occurs?  The difference is  similar to the difference between days, such as Friday versus March 14, 2008.  One is what BPMN would call an event type and the other is an event.  Well, not exactly, I doubt BPM folks would be happy thinking of a day as an event.  Perhaps they would prefer that the start or end of each Friday was a type of an event and that the start of this Friday (i.e., today) was a specific instance of the “start of a Friday” event type.

For those who read about understanding time, the difference between event types and events is similar to the difference between specific and recurring times.  The semantics of introducing different types for starting and ending events is troublesome, however.  Especially if how they are different is not specified semantically.

Generally, for all X, I do not like X “types”. When we talk with friends other than colleagues, using the word “type” confuses them.  When talking to non-technical folks, instead of saying “event types”, why not just say “events”?  Come to think about it, why don’t we talk about process types?  (I’m sure someone thinks BPMN needs them!)

When is a process not an event?

Most people would agree that things happen.  Most people would also agree that events happen.  The word “occur” is interchangeable with “happen” here.  Do you agree that processes, like events, also occur or happen?

If specific instances of events are occurrences of “event types”, what is a specific instance of a process?

If celebrating the 4^th of July is a process and last year’s 4^th of July picnic was an event, could an instance of a process be an event?  Or, is every instance of an event type an occurrence of a process?

Yes and No.  Yes, but, for all X, I do not like X “instances”, for the same reason that I do not like X “types”.  In other words, yes, occurrences of processes can be viewed as events.

But no, some events are not processes.  For example, the start of a process can be viewed as an event, as BPMN views it, but the start of a process is not necessarily a process in and of itself.  We could recurse into philosophy on this one, I guess, but at some level, the beginning of an explosion stops being interesting from a process perspective.

Avoiding philosophy as much as possible while remaining semantic:

1. Occurrences of processes “are” (can be viewed as) events.
2. Events occur instantaneously or over an interval of time.
   • That is, events occur at a point in time or they have a duration.
   • In other words, an event is either instantaneous or durative.
3. Durative events are occurrences of processes.
4. Instantaneous events occur at the beginning or end of processes.

Ontologically, a process is disjoint from an instantaneous event but both are events.

Getting this right is important, not only for helping CEP cross the chasm, but also for integrating BPMS with BRMS.  Whether or not they agree with me, OMG and others need to answer the question:

Are processes and event different and, if so, how?

Paul said that rules don’t address the following that are addressed by CEP:

1. BAM (business activity monitoring) and the other BPM (business performance management)
2. Complex-rule processing
3. Customer-centric (portfolio-based) decisions / policies

I am sure Paul was just being flippant, but you may notice that there is a bit of a war going on between CEP, BPM and rules right now. 

Personally, I believe rules vendors need to move aggressively in the CEP direction.  So, essentially, I agree with Paul’s first point.  However, …

The 2nd  seems merely a  reiteration of the C in CEP.   Commercial rule vendors can handle more complex rules in greater numbers than CEP vendors, in general, and I would like to see more about TIBCO’s expressiveness and functionality before agreeing that their capabilities are superior to the likes of Ilog and Fair Isaac and Haley and ….

The 2nd also dicussed databases versus in-memory caches, implying that the automation in CEP is more scalable and reliable without regard to the amount of state retained over time and in the cache.  CEP vendors need databases as much as the next guy.  Nonetheless, there is an underlying truth that business knowledge and logic should be automated without requiring manual decomposition of rules that involve data or events over time into complex BPM graphs and manually coded database access.  Most CEP vendors take the cache approach but there are other approaches that are viable and, in certain circumstances superior.  For example, Oracle’s in-the-database approach is completely antithetical to streaming CEP vendors but is efficacious in some cases.  Rule vendors should pursue hybrids of these approaches. 

Having resisted the implication, I agree with Paul regarding the current state of the market.  TIBCO is leading the way on point #2.  With one caveat,  TIBCO is not as functional as the leading BRMS vendors in terms of agility and usability (e.g., accessibility by non-technical people).  Personally, I think this could allow a leading BRMS vendor, such as Ilog to leapfrog TIBCO more easily than vice-versa.

Paul’s #3 is a hot topic in the insurance industry, which instigated Paul’s post in the first place.  You can find more content on this on James Taylor’s blog, too.  I don’t think customer versus portfolio has that much to do with CEP versus BRMS for enterprise decision management (EDM).  It’s an industry issue, not a technology issue.  There was also a point there about maintaining state between customer transactions, but it is superfluous (and commonly handled by stateless architectures that use databases). 

After reading Paul’s post, I was genuinely excited that he had so succinctly summarized the capabilities of CEP that are lacking from current BRMS offerings.  The problem is the stateful cache versus the stateless decision service is not where the issue.  The issue is supporting logic that involves information (including events) that span time.