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

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!

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.

I’m really glad that we agree.

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.

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…

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.

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.

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!

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!

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!

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.

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?

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.

Thank you so much for the clarification. I could not have said it any better.

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).

You’re right on. When it comes to business rules, it’s all about the tool.