In his blog posting on BPM 2.0 Ismael Ghalimi gives a number of characteristics of a 2.0 BPMS. While there is much here with which I agree, he also said:
Rule Engine Included
Up until now, BPM solutions would fall into two camps: you either had a glorified rule engine presented as a generic BPM solution, or you had a generic BPM solution that failed to support the execution of complex business rules natively. As a result, most customers who deployed a BPM solution of the later kind had to look for a rule engine from a third-party vendor, even though they did not really need a full-fledged rule engine to being with. BPM 2.0 makes the rule engine a requirement, so that it can be leveraged by the BPM vendor itself in places where it makes sense, such as decision branching, message routing, late-stage service binding, or contextual user interfaces.
Here I can't tell if I agree with Ismael or not. He could mean that it is no longer OK for the BPM vendors to have nothing in the way of a rules engine - they must either build something comparable or, more likely, OEM something from one of the business rules leaders. If this is what he means then I agree - hence our recent OEM arrangement with webMethods, for example.
However, what if he means that a BPM 2.0 product would obviate the need for a rules engine outside the BPM product? Well then I have to disagree with them - I do not consider automation of business decision-making (the core value proposition of a BRMS) to be just part of BPM, event BPM 2.0. Why is this?
Well at a pretty basic level I think BPMS and BRMS are fundamentally different:
- BPMS is about "How should it be carried out?"
- Standardize processes
- Facilitate collaboration and compliance
- Workflow Definition and Management
- Process Automation
- Activity Monitoring and Exception Alerts
- Process Reports
- Integration Broker
- BRMS is about "What should be done?"
- Standardize operational decisions
- Facilitate decision automation and maintenance
- Centralized Business Rules Repository
- Straight Through Processing
- Decision Broker
So how do these two different, but related, technologies work? Well I can think of three scenarios where both are relevant:
- A business process reaches a point where it requires a complex automated business decision to be reached before continuing such as origination, underwriting, fraud detection, precise marketing.
To do this it calls upon a rule service to examine the applicable data and recommend appropriate actions - recommend products/services to offer, decide who needs to be notified of current status, determine what additional data must be collected. The decision data is used by the BPM process to continue its flow
- A rule service reaches a point where additional data is needed in the decision process, requiring human intervention.
It initiates a BPM process to bring the right users into the flow and step them through the required tasks. When the BPM process finishes, it re-initiates the rule service with a saved state and new data
- The result of a rule or decision process calls for a complex business process to be started
It calls the appropriate BPM process as the rule action, often while continuing execution of the rest of the decision.
So hopefully I've made it clear why you need both technologies, even when your 2.0 BPMS includes a decent rules engine of its own to improve the management of the process.