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.


The BPM Technology Convergence – I

A number of Businesses today acknowledge the relevance of BPM & SOA and are increasingly looking to derive value from its adoption and application. Why, even the most important CIO on this planet considers SOA. (overseeing $70 billion spend is quite an awesome IT job). Anyways, BPM has clearly seen through the trough of disillusionment, with a number of standards organizations, vendors, system integrators, customers and of course the analysts (Gartners & Forresters) applying focused efforts in their own ways towards pushing BPM/SOA further up the productivity plain.


Well, at least one of the key enablers has been Technology, be it in terms of various technical standards formulations, proven architectural frameworks or vendor product innovations. With this write-up I try to create just one perspective of today’s BPM technology landscape. This actually leads me to investigate (in part II of this article), whether a general convergence of technology is possible within the frame of this perspective, and is that really where we are going to find the best possible solutions to BPM & SOA.


To narrow-down the scope of the BPM technology landscape, I consider three core foundational technology components required to put together any comprehensive BPM or SOA solution:


  • Process Engine  – BPEL/WSDL being the dominant standard.
  • Rules Engine – No real standard here, except JSR94 that defines interfacing APIs
  • Enterprise Service Bus – Variety of standards such as JBI,  SCA-SDO (incompatible unfortunately L)    



The BPM provider community as we know it today is broadly spilt across two (or maybe three) camps:


  • The more dominant** camp, that envisions a BPM ecosystem where Process & Rules are loosely-coupled (service-oriented) components. This camp includes heavy-weights such as IBM, Tibco, Oracle-Weblogic, and Microsoft. Each of them offer a basic Rules Engine along-side their primary component – a BPEL engine. This particular Rules engine typically supports only stateless service-oriented synchronous rule(set) invocations called out from within decision points in BPEL-based process flow. 


  • The Emergent, less dominant** camp lead by Pegasystems that envisions a BPM ecosystem where Process & Rules are unified tightly-coupled “first class citizens”. Pega sites an analogy in Relational databases where its core capabilities of query optimization, integrity constraints & concurrency simply cannot be addressed by separate engines – an engine for integrity constraints, a separate query optimizer and a third engine for concurrency.  Their BPM solutions have evolved from a strong Rules engine foundation that has been extended to treat Process steps as “specialized” rule types and hence the term – Rule-driven processes.      


  • The 3rd camp (now more-or-less morphed into/aligned with one of the 2 camps mentioned above) that believed all Business logic can be modeled purely in a Rules Engine. ILOG probably was one such vendor that was recently snapped up by IBM.


Both these models (loosely-coupled v/s unified Process & rules) have their merits as well as demerits. Before we get into a detailed analysis of these we need to probe a bit deeper into the “Emergent” camp for the benefit of folks who are not so familiar with them. I myself, have burnt hands working only with the “Dominant” camp, so turned out quite interesting trying to explore the other camp.    



…continued in Part – II      



** IBM claims to sell 3 times as much SOA/BPM software as its nearest rival, probably running into few $ billion revenue. PegaSystems’07- 08’ revenue was around $200 million.