Why a BPMS needs a Business Rules Engine
Monday, June 5th 2006 | Ismael Ghalimi
This is the thirteenth edition of our weekly BPM 2.0 post. Today, I will try to explain why a BPMS should include a Business Rules Engine. Unless your business processes are extremely complex, you might never need the power of a full-fledged business rules engine, but this does not mean that your BPMS should not include one by default. There are many reasons for this.
First, there is no standard way of integrating with a business rules engine, and if there ever was one, there would be no standard way of describing a business rule like there is for business processes using BPMN serialized into BPEL code. Vendors of business rules engines have tried to build such a standard for years, but they never could agree with each other, and I strongly doubt that they ever will. As a result, if a BPMS does not include a business rules engine by default, it has no way of providing a standard interface that would allow customers to plug their engine of choice.
Second, the only way to really take advantage of a business rules engine within the context of a BPMS is to align the lifecycle of business rules with the lifecycle of business processes. For example, a business rule will have to be expressed against the data model of objects or services that are orchestrated by business processes. When the process changes, the data model of its related objects and services will change as well, which will impact business rules using them. If the two lifecycles are not aligned, you can forget about One Click Deploy.
Third, the BPMS should take advantage of the capabilities offered by the business rules engine not just for business rules, but also late-stage biding rules to select which implementation of an abstract service should be used, how a user interface should be tailored to specific end-users, and when to escalate an alert to an IT manager when some system-level exceptions are generated.
If your BPMS of choice does not include a business rules engine by default, you will still be able to invoke business rules through some kind of service interface or API, but you will lose the benefits outlined above. Interestingly enough, this is one of the pieces that are missing in the Intalio|BPMS, and we are aggressively working to fix this. Our two main options or Corticon and Drools. The first is nice but not free. The second is Open Source but does not have an Eclipse-compatible tool yet (at least not a full-featured one). Shall we go with the second option, we will develop a tool through our Demand Driven Development program. If you have any interest in this, feel free to drop me a line.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael,
Drools, while it seems popular for the JBoss crowd, has little to do with the business rules approach. It is good for building expert systems and other complex capabilities; however when business managers need to make changes in policies or strategies, they will need to call upon skilled developers. A one click deploy is difficult with Drools. However, there is a spreadsheet tool for excel. The core of the business rules approach is a rule authoring tool for business area managers and persons with slight technical skills.
This is what we are doing with our OpenLexicon project. We have been successful with training business personnel to rapidly complete complex business-rule scenarios with this project.
Not sure I agree that lifecycle of business rules must sync up with lifecycles of business processes. In fact, one of the benefits of business rules is that they are independent of process boundaries and lifecycles, so they can change without versioning the process. I agree that they are dependent on a data model that, for this to work, should also be independent of processes and generally longer-lived than process versions.
I can kind of see what Ismael is getting at. However, I would put the problem statement as: how to do a clean cut-over of changing processes and changing rule structures/parameters in a production environment?
Given that a process can be very long running, taking up to days to complete, how do you ensure a clean cut-over without versioning of rules and processes? Given that there are no standards in terms of process/rule interaction, without an embedded rule engine, a BPMS will not be able to facilitate a real-world deployment cut-over. The arguement is that until there’s a standard interface between rule engines and BPMS, embedding a rules engine would dramatically improved the value of a BPMS. If a modeler chooses not to update the rule parameters or criteria, so be it. But in a real work deployment, a BPMS should provide the ability for versioning and synchronization of a given process against a given business rule.
Tom,
You’re right on. When it comes to business rules, it’s all about the tool.
Bruce,
When writing about the alignment of lifecycles for rules and processes, I did not mean that the lifecycle of business rules should be the same as the lifecycle of their related processes. In fact, they could be orthogonal, and intersect only when the interfacing data model changes. In that respect, your terminology is better than mine: the lifecycles of business rules and business processes must be synchronized with each other (when they intersect).
Karl,
Thank you so much for the clarification. I could not have said it any better.
Ismael,
I cannot agree with you on the synchronizing thing. Like Bruce I think the whole point of having separate, but linked, BPMS and BRMS tools is to allow for the separate update cycles. I can think of any number of customers who have deployed new rules many times but still run exactly the same process. While I can think of examples where synchronized changes are needed, I think asynchronous changes are more common. I wrote about this for the BPM Institute in the context of compliance, but I think this is generally true.
James,
You are absolutely correct! It is critical that one can update a rule without having to update a process. And I hate myself for not having made that clearer in my post. That being said, I maintain my original point, which is that when the data schema of the interface between a process and a rule changes, the process or the rule has to be changed accordingly. This is what I would refer to as a “synchronization point”, which is the point where the lifecycle of a process intersects with the lifecycle of a rule, the two being separate and independent from each other. Does it make more sense?
Yup — sounds right.
Of course I would recommend a different BRMS, but then I’m biased and, to be fair, focused on how you build a decisioning infrastructure not just add rules capabilities to a BPMS.
Ismael,
You said:
“Today, the BPM moniker is used to describe anything from legacy workflow products to business rule engines, flowchart diagramming tools, Java code generators, or even business process reengineering consultancy services. This confusion, perpetuated by software vendors and industry analysts alike, serves two main purposes: it allows any vendor who can show boxes and arrows in its product to keep selling its gear, while letting any analyst who can compile a list of the aforementioned vendors to sell its luminary services to herds of utterly confused end users.”
I am slowly but surely raising above the herd. A long and tortuous road it is, though!
Keep enlightning us!
Ismael,
A newbie question on BPM. Take for example the order-to-delivery-to-cash process. By necessity, it spans two enterprises — the seller and the buyer — so if one would want to automate and optimize this process with a BPMS/BRE application, wouldn’t both organizations have to participate? Would that make adoption of the application much more difficult?
Just curios on what your experience is. Thanks!
Ismael,
I began writing a series of posts to bridge the gap between supply chain knowledge in the industries I know and emerging IT technology such as BPM. I am trying to develop the case for the process centric view of the enterprise, explore state-of-the-art in basic supply chain processes, and make the link to technolgies such as BPMS, BRE and so on. When you get a chance could check my posts and give me some feedback? Thanks!
I’d like to broaden the discussion by making the claim that a rules engine is essential for the next generation of BPM. What do I mean by this assertion? Let me give an example:
If you look at a complex set of processes such as handling an insurance claim, you end up with many permutations of paths through the various actions and subprocesses. Whilst settling many instances of insurance claims events can occur (such as a garage being investigated for fraud, or a doctor appearing to sign off an unusually large number of sick notes). This would entail finding all instances of processes in progress, stopping them, re-examining them, and restarting. Add in all the other potential events (garages going out of business with half-repaired cars, driver insurance record changing, etc.), and the possibilities are literally mind boggling!
If the process were split into a series of fragments with a supervisory “meta-process” orchestrating them, we may manage. If the meta-process itself were rules-driven, responding to internal process data and external events, then the choice of which fragments to run (or re-run) next could be managed easily. In essence the meta process boils down to:
1. Save state
2. Examine environment
3. Check rules engine to determine next fragment to run
4. Run fragment
One fragment would also contain a “Stop” instruction.
In the ideal world there would also be a “meta-meta-process”, which again could be rules-driven and would examine all the processes running to determine pairs where one fragment needs a service whilst another is in a receptive state and could offer it; I’ve written about this, coining the term “opportunistic rendezvous” to describe how it could work.
I agree with the concerns expressed regarding change control for process [instances] and rules, but these could be overcome — I don’t want to extrapolate or recurse too far and have meta-meta-meta processes, but the principles are expressible in process terms.
BPM definitely needs business rules, but I agree with James (and others) that the BRE/BRMS should not be buried within the BPMS. In the real world of heterogeneous systems that I see in my clients’ IT shops, they would want to plug in the same rules to their BPMS, their CRM and possibly custom applications that they wrote in-house. Having the BRMS as a separate entity that provides a single version of a business rule on command to any application that calls it is far more valuable then having it embedded, and isolated, within a BPMS.
Ismael,
I couldn’t agree more. That’s why a BRE (Business Rules Engine) ships as a core part of Microsoft BizTalk Server (since 2004), and also why the recently-announced Windows Workflow Foundation includes a rules engine.
Rules are a critical feature of BPMS’s, because, among other things, they allow business users to interact with processes in intuitive and sandboxed way. Lots more I could say on the topic — I published an article on it in BPM.com last year.
Ismael,
Have you ever thought of having a glossary page where all these acronyms (BPM, BPMS, BPMN, BPEL, BRE, etc.) are defined for business users that are not up to speed yet with IT technologists?
Just wondering…
Ryan,
On your question regarding the order-to-cash scenario you described, you could either use some B2B protocol in between the buyer’s and seller’s processes, and each process could run on different systems, or you could have the channel master (buyer or seller) expose its process through some kind of partner portal. In this case, the end-to-end process is being automated by a single party. Usually, the later is an order of magnitude simpler to implement than the former.
Regarding your blog, I will send feedback as soon as possible.
Regarding the glossary, I think it’s a great idea. I’ll work on it.
Barry,
I’m really glad that we agree.
Sandy,
I think I disagree. It seems to me that we’re confusing Business Rules Engine (BRE) and Business Rules Management System (BRMS). I believe that the first should be part of a BPMS, while the second would be externalized and integrated with multiple BREs. Much like all processes are not running within the BPMS. Instead, the BPMS is used as a master system of process that can orchestrate processes running on different systems such as existing workflow engines or packaged applications.
Ismael,
This one really got me thinking…
I agree with you on the synchronizing thing, and would suggest that it is an issue that extends beyond just rules and process. The synchronization of schemas, rules, processes, etc, impacts a variety of components of a complete system, not just rules management and process management, but also the application’s user interface (UI), underlying data persistence (your application DB), and integration with business applications (e.g. ERP). I have an experience where this whole system synchronization issue almost blew up in a large insurance system implementation.
Though I also agree with James that independent components can be updated out of step, the information systems guys must make sure that they understand the dependencies between components, and under what circumstances a synchronized update is required.
Keep up the good work — the discussion is great!
[…] This is true for business rules — as was discussed at length in comments to this past article, but it is also true for binding rules invoked to bind abstract process and service interfaces to their matching implementations, as well as user interface parameters used for internationalization, localization and personalization purposes. In order to support real-time changes to be applied to business processes, it should be possible to change such parameters and variables at runtime, without having to redeploy the processes themselves. […]
Now that you called out the problem space, are you also going to lead the charge in terms of getting standards that fix it?
James,
That’s a tough one. I’ve been in the standard development game before — I created BPMI.org back in 2000, and it’s a very tough one. One needs a lot of resources to make it work. That being said, I would not totally close the door yet. Keep an eye on us…
Best regards -Ismael
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment