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.