Complex event processing (CEP) software handles many low-level events to recognize a high-level event that triggers a business process. Since many business processes do not consider low-level data events, BPM may not seem to need event processing. On the other hand, event processing would not be relevant at all if it did not occasionally trigger a business process or decision. In other words, it appears that:
- CEP requires BPM but
- BPM does not require CEP
The first point is market limiting for CEP vendors. Fortunately for CEP vendors, however, most BPM does require event-processing, however complex. In fact, event processing is perhaps the greatest weakness of current BPM systems (BPMS) and business rules management systems (BRMS), as discussed further below. Continue reading “CEP crossing the chasm into BPM by way of BRMS”
We have been teaching a computer to answer questions like, “How much did IBM’s earnings change last quarter?” It takes a fair bit of knowledge, including how to understand English, to answer this question. But teaching it what a “quarter” is brought back memories of debates with some former CMU colleagues about what units are and how to model time. Since quite a few people ask me for help with knowledge engineering and ontological matters, I thought some might be interested in parts of those debates.As you will see, a strong upper ontology of common knowledge is required to understand common business knowledge. Leveraging such an ontology is the only way to deliver business rules for under $50.
Sentences like “do something if more than a number of possibly related things have happened within a timeframe of something else happening” or “do something if nothing happens within a timeframe following something happening” are extremely common in business process management (BPM), complex event processing (CEP), and workflow. With a sense of time, a business rules management system (BRMS) can support BPM, CEP, and workflow applications almost trivially. Without a sense of time, most BRMS force users to perform computations.
For example, without a sense of time and an infrastructure that supports it, the sentence “call a customer if no response is received within 30 days of notifying the customer of a delinquency” has to be transformed into something like “if a notice is mailed on a date and the notice is a delinquency and the date of notification has a day number then compute the date for checking by adding 30 to the day number and check for a response to the delinquency notice on the date for checking”. The checking on a date for a response to a notice must also be implemented as a database (or persistent queue) of events to be polled or triggered by application code. Then a second rule is required to implement the check, as in “if checking whether a response has been received to a notice and the notice was given on a date of notice and the notice was given to a customer and there exists no record of communication with the customer since the date of notice then call the customer”. (Note that this is actually how most BRMS products would implement this. The natural language approach I prefer handles the original sentence.)
The discussion here reflects the general structure and content that a usable ontology for business process management requires. Most users of business rules management tools will find the need to understand and engineer this discussion in their tool of choice. As my Haley Systems customers know, much of this is reflected in Authority’s built-in ontology and English vocabulary, but quite a few of the points discussed here reflect improvements, especially concerning the confusion between units and amounts.
As you will see the discussion takes careful thinking. Some readers may find it onerous. If at any time you have had enough (or if you simply cannot take anymore!), please skip to the end and decide whether to fill in the conclusions by revisiting the body.
Continue reading “Understanding events and processes takes time”
In comments to a recent post concerning the acquisition of Haley Systems by Ruleburst, James Taylor suggested that a “decision-centric” perspective is necessary for business rules to become mainstream. In subsequent correspondence, I questioned whether fixating on decisions would achieve his objectives for enterprise decision management. EDM hopes to integrate business intelligence (e.g., predictive analytics) with point decision making so as to improve decision making over time. This is a natural step beyond the typical point decision making application of business rules, such as in a stateless web service that returns a simple decision, such as a score, price or simple yes/no. But it is a narrow perspective on the broader confusion between business rules and business process that has been holding back the mainstream.
For years, smart people have been searching for a razor to determine what logic they should “code” in process versus as rules (e.g., using a BRMS versus their BPM platform). At first glance, the decision-centric approach seems to have the answer. Simply put a decision node in your business process diagram and let the BPM tool orchestrate the decision implemented as a stateless web service!
Unfortunately, this alluring answer is all too often inadequate or impractical. The business rule vendor has effectively transfered responsibility for managing state (i.e., information collection and provisioning) into the business process diagram and orchestration tools – or code. The result is implementation complexity, limited user communities, cost overruns and failures. That will certainly hold back mainstreaming a bit!
A better answer is coming. Complex event processing anticipates that business processes and decision making can be stateful, as Paul Vincent explains briefly but well here. When CEP is supported by knowledge capture, management and automation tools such as the better BRMSystems provide, the lines between process specification and decision specification will further blur beyond the adequacy of the decision-centric advisory. Expect this to happen in 2008.