Business Rules in or out of BPM?

Mark Norton commented on my algorithm post and inspired this follow-up post on the combination of BPM and Business Rules.

The debate on whether one should implement Business Processes or Business Rules has been raging since the late 90′s…  It seems that both sets of players have finally come to terms with its role and how they can collaborate but I still see a few confused heads.

All BPM or All BRMS?

BPM vendors used to advocate that business processes are meant to encode both routing and decisions.  BRMS vendors used to say that a rules service can define all decision logic (i.e. the rules) as well as the sequencing of those packets of rules (i.e. the ruleflow).  In short they agreed that you only had to use one tool but they disagreed on which one.

Debunking the All BRMS story

It does not take much to argue against that perspective…  When the process at hand runs longer than a single hit-and-run transaction, rules services will cause you more trouble than they are worth.  A long-running transaction, by definition, stops and hangs there.  It could be due to an awaited human intervention, an asynchronous call to a remote system like a DMV (Department of Motor Vehicle) or a Credit Bureau, or simply a failing call to a local service that is gracefully handled in your system.  You want this transaction to patiently wait for the answer before you keep processing it.

The problem is that rules services are not well-suited for waiting patiently.  Granted, a software architect can decide to deploy that service as a stateful service — not that many like that design.  A stateless service could possibly be used like a state machine with careful design — which we have done on a few occasions when a BPM implementation was not an option.

Here is an analogy that may help.  Le Tour de France is full of decisions — Who gets the yellow jersey?  Who gets Polka-dots?  How much doping is too much?  That being said, the route is like a process flow.  You could use business rules to decide which destination to head next but you’d be at the mercy of a system crash, or you would have to design your system to archive the progress as you go.

The fact is BRMS are good citizens of the App Server that hosts them but you don’t want to manage the overhead of those long-running transactions all by yourselves.

Debunking the All BPM Story

BPM does a beautiful job orchestrating services and systems.  The long-running transaction is fully taken care of.  The difficulty comes from the maintenance of the decisions embedded into the said process.

When the decisions become somewhat complicated, you see yourself adding a path here and there in your flow.  No big deal.  Until it become unmanageable: too many links, too many nodes.  In the gigantic stack of spaghetti links, you have a hard time visualizing what the process is meant to be about.

The famous traffic light in London is the perfect analogy.  One traffic light is pretty simple, even my 3 year-old got it a while ago: Green you go, Yellow you slow down and Red you stop.  The thing is, as complexity grows, you make get confused when facing the “simple” traffic light concept multiplied by a few dozens.  Same thing happens when your simple nodes and links get multiplied to create a messy mesh like that traffic light in London.

The trick here is to find out where the fine line lies

You need to find the perfect balance of process and decision.  Think about what each part is really about:

• what is about the various systems & people the transaction must hit, the red tape and the milestones to reach
• what is about the decisions that may vary as a result of regulations or competitive strategy changes

Those tend to change at a different pace, they tend to be subject to different constraints, they tend to be owned by different stakeholders.  So when you are on the job, it may not be that difficult to draw the line when you put your head to it.