There are two types of Business Rules, those that issue warnings and those that cause hard stops.
In highly-automated systems such as automobiles, an audible or visual warning is typically issued when a rule is violated (e.g. engine overheating). If the warning is ignored, a state of affairs may be reached where the system causes a shutdown.
A well designed BPM process behaves in much the same way – the process provides behind-the-scenes orchestration and the BPMs environment provides in-line, real-time governance.
Some prefer to use the terms guidelines and guardrails (i.e. center lines on a highway / physical barriers along the sides).
The big question becomes “where do we park business rules?”
If we consider a sequence of linked steps, we know that data flows along template instances. We can, at any step, test data that is being carried forward as well as data being collected at the step.
We can, for example, prevent alpha characters from being input at numeric fields, reject end dates that are earlier than start dates, and carry out range checks on data values (i.e. percent complete must be between 0 and 100).
The obvious place to park rules is at data collection forms at template instance steps.
If you are at a step, recording data, there is a presumption that you are an appropriate/authorized resource to be at the step and that the step is being performed at the right time.
BPM process maps where steps have plan-side routings take care of some of this but do not take in to consideration whether an instance is on the right sub-path (i.e. we engaged processing of an adult healthcare patient only to discover that the patient actually is an adolescent).
Accordingly, whereas process map logic may tell us that a step has become “current” it may be prudent to test via pre-condition rules that it is OK to access the step and initiate processing.
The rule set placement in this case needs to be upstream from the step and this is easily accommodated by a precursor auto-exec step with a routing of “system”.
Users don’t see the step but if the results of processing at the step indicate a problem, a prompt will be issued or a hard stop will occur. If the outcome of the auto-step is a hard stop, processing never gets to the next-in-line step unless/until the problem is fixed or a supervisor inputs an override.
In respect of soft stops, an auto-exec step can be more lenient (e.g. a step asks for a street address for an individual or an organization). Here, whereas the workflow designers’ preference was to pick up a street address at a particular stage of the processing, an address is actually not needed until such time as a form is submitted, a letter is sent, or a worker goes on the road to that address. Downstream rules will apply a hard stop as and when appropriate.
We can see from the above that auto-exec process control template instance steps are no different from ordinary input/output conversion steps so no special constructs are needed – these steps auto-commit instead of requiring manual commits, their routing is “system” instead of some user skill category.
How do we provide governance at ad hoc steps?
Whereas we can declare an ad hoc step to be a process of one step, if the step form consists of a single memo field, there is not much that we can do. We don’t, in the normal course of events, need to be concerned about what is recorded at memo fields, but, you never know, so no harm auto-parsing the data to see if there are any key words /contexts that should be flagged.
Suppose, however, someone wants to ship a prototype.
Global rules say “no shipments unless a product has been through QA” so the generic solution to this and other unwanted behavior is to isolate users from directly streaming records on templates by presenting to the user a menu of services.
The menu can include all workflow templates plus a replication of all steps within each of these workflow templates as ad hoc steps.
“Build-test-ship” expands to “build”, “ship”, “test” (alpha listing) and in respect of “ship” we would reasonably have, behind the scenes, a two-step template, the first of which is an auto-exec step that asks “has this product been tested?” – if the answer is no, the “ship” ad hoc intervention will fail.
We can implement governance at a Case for work that is made up of any mix of structured /unstructured activity without having to jump through hoops.
Simply park your rules at steps or set up links at steps to regional rule sets (avoids any need for 1:1 coupling between any rule set and a process step).
Final refinements are, once at a process step, if the processing calls for engaging or reaching out to an algorithm, extend your rules implementation model by preceding the algorithm with pre-conditions and, just to make sure, insert an auto-exec post-condition step immediately “downstream” from the algorithm.
Do the same as you leave process steps via next-in-line auto-exec “system” steps that include loopbacks in the event of a fail.
Here is an Eiffel code fragment that illustrates “require”, “do” and “ensure”
class ACCOUNT create
… Attributes as before:
balance , minimum_balance , owner , open …
deposit (sum: INTEGER) is
— Deposit sum into the account.
sum >= 0
balance = old balance + sum
withdraw (sum: INTEGER) is
— Withdraw sum from the account.
sum >= 0
sum <= balance – minimum_balance
balance = old balance – sum
may_withdraw … — As before
add … — As before
make (initial: INTEGER) is
— Initialize account with balance initial.
initial >= minimum_balance
balance := initial
balance >= minimum_balance
end — class ACCOUNT
Apologies to Civerex customers who have never seen nor had to worry about computer code. Rest assured, we will not be putting out upgrades to our software suites that require coding, same as we have not, in the past, required customers to worry about building and maintaining database tables\fields.
Most of the heavy lifting for the approach used in Civerex workflow management software suites comes from research done by Dr. Bertrand Meyer, inventor of the Eiffel language. We are indebted to Dr. Meyer and his team for their important contribution in the area of workflow management.
Civerex was the Canadian distributor of IES for a number of years.