The BPM Technology Convergence – II

A Converged or Unified Process & Rules Engine brings forth a few striking capabilities by virtue of it being “Rule driven”. Let us examine the key features.

Dynamic Process Configurabilty  

It is possible for such an engine to allow a process/rule designer to define process and rule objects that behave or evaluate differently based on multiple possible Contexts specified using variables such as locale, customer type, time, version, rating, etc; combining in multiple possible ways. So, along with  the main process and rule definition, one can define specializations of them, applicable only in defined Contexts. At runtime now, the Engine evaluates the incoming context instance and based on the evaluation outcome, assemble the pre-configured  process & rule specializations for execution and execute them.

Traditional (Camp 1) process engine approach tends to build service (or process) configurability by embedding more decision points and branches in the process itself. In other words, configurability tends to get codified in the process flow. Over a period of time this results in bloated and difficult to comprehend and maintain process diagrams.
In contrast, a Rule-driven process engine, could evaluate the rules based on contextual information and dynamically assemble the optimal process(es), decisions, and data sources for that particular case.  System building then, is an exercise in defining the different contexts and responses to them as integrated components (process & rules) that are brought together as needed, rather than developing an individual process that handles all potential situations. 


Consistent Artifact Versioning 

A unified process & rules engine, based on contextual information, could resolve at runtime the correct version of Process as well as Rules to be executed.

This is required to support for e.g. a smooth transition from old to new process & rule definitions where existing in-flight component instances are required to continue through to completion based on old definitions and newly instantiated cases are based on the latest version definitions.
Another simpler example could be to support concurrent operations of the same service for 2 different clients. 

Traditional (Camp 1) process engines provide runtime version resolution support for “Process” definitions only.
A rule-driven process engine being intimately aware of the process-rule combinations for the case, can natively provide consistent artifact versioning capability. 


Integrated Domain Object Model 

Most business applications define a Business logic layer where “application” logic (Domain Driven Design, Eric Evans) and  domain logic resides. The Business logic layer usually tends to take the shape of one of following structures:

1. A Rich Domain model comprising of fine grained objects, interfaces & strategies typically supported by a well-defined O-R mapping layer and encapsulated by a thin service layer comprising of coarse grained interfaces, implementing application logic and exposing business functionality to the world.  

2. An Anaemic Domain model(Martin Fowler) comprising of mostly non-behavioural objects designed as elementary state capturing attributes, typically supported by a DAO layer that implements data access logic, and a thick service layer that implements business (domain + application) logic in addition to exposing business functionality to the world.

3. The third form is a variation of the Anaemic domain model wherein the service layer is kept thin by moving bulk of domain logic into RDBMS dependant stored procedures, following a performance oriented architectural principle – Process Data as close to its Source as possible.

I have witnessed all 3 forms of organizing business logic mentioned above and each has its pros & cons. I will reserve a personal account of this for a later post. So moving on; how does Traditional v/s Unified BPM fare in the context of the structures described above? After-all both process & rules engine help codify a significant portion of the Business logic of a Business application. Processes codify “application” logic –  responsible for orchestrating domain operations, controlling transactions and third-party system interactions; whereas  Rules codify components of domain logic – the kernel of business logic.    

Traditional (Camp 1)  BPM design takes the approach that processes invoke  rule services that govern certain processing steps, as and when required. Such rule invocations will require that the domain model objects (either Rich or Anaemic)  be explicitly passed back & forth between Process & Rules engine as invocation/response parameters. There are a couple of consideratons here, which are actually overheads if process & rules engine are from different vendors, or process & rule artifacts are Not managed from a single development environment:

1. The domain model versions used by both engines need to be explicitly kept in sync.  

2. Business logic (in the case of Anaemic domain model, see structure 2 above) may get distributed  between Process & rule artifacts. To avoid this, policies that enforce localization of business logic to the process engine (preferably) need to be implemented. Practically, this results in only stateless invocations of rule types that are nothing more than decision tables or  if-condition-action statements, again with the “action” part not really responsible for any domain operations. A typical invocation by a Process, will ask the rules engine — Given this context specified by these (anaemic) domain objects (also known as fact instances), help decide the next course of action, by evaluating this specific bunch of if-conditions (operating on the facts) that I have externalized as rules, so that my (process) Code looks clean !  

From the interaction pattern described above it is clear that one does not get to use the full power of the Rules engine such as Inferencing – Backward and Forward chaining, unless we allow significant business logic to also reside in the rules engine, which can quickly lead to a maintenance nightmare.  

A Unified Process & Rules engine does not suffer from the overheads & limitations described above since it provides an integrated environment – both development and runtime, and infact a process artifact is treated as just another special rule type artifact with special features.

Concluding Notes

The BPM industry is taking note of innovations such as the one we have discussed – a Unified process & rules engine platform for deploying BPM solutions. However, whether a widespread adoption of this technology will happen remains to be seen. Two major factors that will be instrumental in this regard are:
1. Backing from Industry heavy-weights such as IBM & Oracle marketing & delivering their own adaptations of this technology.
2. Backing from the developer community at large, primarily driven by adaptations in open source arena – for e.g. JBOSS Drools 5 that employs similar technology. 
The technology however has some compelling merits.  It seems to directly address the heart of real world BPM problems of dynamic process configurability or context driven adaptable/agile process flows and consistent process and rule versioning. In the bargain, one should consider the additional skills required to architect, develop, deploy, maintain and govern a solution based on this technology.