The folks from Knowledge Partners have a post that I found thanks to Sandy Kemsley, whose blog often provides good pointers. This article talks about the decision perspective on business rules. It makes some good points, on which I would like to elaborate albeit at a more semantic or knowledge-level.
Every language has three kinds of statements: questions, statements, and commands. There are also some peripheral types, such as exclamations (Yikes!), but in business processes and decisions only declarative and imperative sentences matter.
From a process- or decision-oriented perspective, decisions are always phrased as imperative sentences. Otherwise, the statements reflected in any business process, whether you are using BPMN or a BRMS, are declarative sentences.
Decisions are imperative sentences because they state an action to be taken. For example, decline a loan or offer a discount. It’s really pretty simple. A decision is an action. Rules that don’t take actions are statements of truth. Such declarative statements of truth are perfect for formal logic, logic programming, and semantic technologies. It’s the action that requires the production rule technology that dominates the market for and applications of rules.
The authors of the aforementioned article use the following diagram to explain the benefits of the decision-oriented approach in simplifying business processes:
The impact is very simple. If you eliminate how you reach decisions from the flow that you diagram in BPMN things get simpler. It’s really as simple as realizing that you have removed all the “if” parts (i.e., the antecedents) of the rule logic from the flow chart.
So who in their right mind would use a business process tool to express any business logic? Continue reading “What could be more strategic than process or decision management?”
In preparing for my workshop at the Business Rules Forum in Las Vegas on November 5th, I have focused on the following needs in reasoning about processes, about events, and about or over time:
- Reasoning at a point within a [business] process
- Reasoning about events that occur over time.
- Reasoning about a [business] process (as in deciding what comes next)
- 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. Continue reading “Time for the next generation of knowledge automation”
Externalizing enterprise decision management using service-oriented architecture orchestrated by business process management makes increases agility and allows continuous performance improvement, but…
How do you implement the rules of EDM in an SOA decision service? Continue reading “Agile decision services without XML details”
Have you heard the one about how to drive BPM people crazy?
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. Continue reading “In the names of CEP and BPM”
TIBCO is the CEP vendor most focused on the market for business rules, as reflected in Paul Vincent’s post here. Although I agree with Paul that rule vendors are not currently offering enough in terms of support for long-running processes, the conclusions that he draws in favor of considering a CEP alternative to a BRMS are not compelling yet.
Paul said that rules don’t address the following that are addressed by CEP:
- BAM (business activity monitoring) and the other BPM (business performance management)
- Complex-rule processing
- 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. Continue reading “Behind the CEP curtain – it’s about time, not the cache”
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”