Business Process Management (BPM) and Pega

Business Process Management (BPM) is currently a very in-demand area. One of the factors why it's so is that business rules are always changing. If the business system in any company can not support the changes, the consequence is that the company will be much less competitive. Hence, a lot of companies now put tremendous efforts to improve their business processes in order to make them more automated, more flexible and agile.

Currently there are a few major players of BPM product in the market, such as IBM Lombardi + iLog rule engine, Pega PRPC, Oracle BPM Suite and Progress Savvion, as well as Microsoft SharePoint. I had an opportunity to work with Pega PRPC for a few months starting beginning of this year, and I passed a few Pega certificates (man, you need to study their staff for sure!). I would like to share my comments about Pega here.

Pega is very aggressive in marketing and branding its PRPC product. In addition, its marketing efforts target very much business users. Indeed, Pega PRPC product is good for business users in terms of a few perspectives such as standard user interface, delegation of business rules to business users, easy management features (work list, work basket, monitoring and escalating rules, etc), capability of quick demonstrating the prototype.

However, I have seen a few major questions (if not issues) associated with Pega product. First of all, tt is not in consistence with current technical main stream. Pega product is away, in many aspects, from the common technology language and paradigm. In addition, Pega product is rather proprietary. I am listing a few things below.

In addition to (normal) class inheritance (concept of abstract class and implementation of interface), Pega uses another type inheritance based on the name resolution involved in the dash. For example, Transportation-Vehicle-Car is inherited from Transportation-Vehicle. Pega names this type of class Inheritance as Pattern Inheritance. 

Pega product is not BPEL based, although it provides integrations with other data format and protocols (such as FTP, MQ, HTTP(s), SOAP). 

Pega stores all rules and code in a database. The code is generated dynamically and loaded into the application server (such as WebSphere Application Server, WebLogic) or Web Servers (Such as Tomcat). One of issues from this design is that you can not uninstall it straightforwardly. You need to delete database tables and restore them from the last backup. I bet no database administrator wants to do it, and any change of database has to go through formal change request.

Pega rules are stored as BLOB in a few tables. The good thing of using BLOB is easiness and flexibility. For example, if you add more rules, there is no need to change table schema corresponding to the new rules. They are just stuffed into the BLOB. The content in the BLOB is encoded and compacted by Pega proprietary algorithm. On the other side, the BLOB may impact adversely the performance. One remedy recommended by Pega is to create (or "expose" as per Pega) new columns. Then you can apply indexes on the newly created columns. 

Finally, Pega product is not very easy to learn, not only due to the mediocre documentation and lack of end-to-end tutorials, but also there are many hidden “secrets” (if you don’t know them, it takes a lot of time to figure them out as many things are away from mainstream as mentioned above). Let me chanllege you a question. How to create a new application from scratch if NOT going through the Application Profile and Application Accelerator in PRPC? Sounds a very simple question, isn’t it? Yes, it should be a very simple thing to do with other products. However, I bet you don’t know how to do it even you take 2 weeks training provided by Pega. In this respect, I believe there will be rather tough road for Pega  product to be widely accepted by development community.