The BPM Cathedral vs. Bazaar Model

Comments: 2
Rate this:
Total votes: 0

When looking at BPM there appears to be two distinct worlds Pegasystems Inc. and one that is more standards-driven that includes vendors, such as, IBM, Appian, etc.  BPM using Pegasystems’ PRPC versus BPM proscribed by this latter set of vendors represent two very different philosophies on how to implement BPM systems. However, I would say that the one thing that all vendors appear to agree with is that an enterprise-grade BPMS is a truly disruptive technology, since its tactical mission is usually to:

  • Extend the functionality of existing apps, 
  • Enable disintermediation between applications, 
  • Tightly-integrate processing gaps among disparate applications
  • Provide opportunistic business application behavior that takes advantage of new technologies and techniques in order to deliver superior functionality

These types of solutions require commitment and embracing the fact that you will probably be doing many more projects with the “platform.” If you do not have several BPM projects lined-up in your application portfolio strategy, you have probably made a strategic mistake. BPM applications are complicated; it may take several implementations to achieve true productivity. That is, business output versus the resources requirements of the BPM application. 

The (BPM) Cathedral vs. Bazaar Model 

It is well-known that these two representative constituencies are addressing the same technology space, but from decidedly different approaches. The market could be defined as a “derivative” version of the Cathedral versus the Bazaar model as applied to business process computing.

In the classical version, of the Cathedral model, source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers, for example, the oft cited Microsoft and SAP. The Bazaar model is created more independently and developed in the view of the public. For example, the Java community Process and OASIS, which are standards organizations, that design for and guide software development organizations.

In the BPM version of the Bazaar model, the non-Pega vendors, software delivery is achieved in a significant way through adoption of standards (i.e. BPEL, BPMN, CMMN, and DMN). Some of the vendors in this market provide design solutions for parts of the software lifecycle, other vendors, such as, Appian or IBM include runtime BPM implementation capability. Pegasystems PRPC is a designed and built by developers, based on the expectation of a major version release -- the Cathedral model. They code, find bugs, fix as much as they can and then after a year or so they eventually ship a product. The software architecture (model) is loosely based on BPM standards. This vendor provides software that addresses all features of the lifecycle. That is requirements, design, and implementation, through testing and release management.  

The Path of the Righteous 

Within the software industry, standards are always and immediately viewed as benign; whereas, proprietary is perceived as evil and tyrannical. But that is a mystical and naïve view of the software industry. Organizations that support standards proselytize the virtues of openness and communal delivery and relegate proprietary-type vendors as usurpers, who lock and hold you into their solution. The fact is, for those of us who actually dwell within organizations where the success and failure of a project has consequences, the choice has to do with which solution is robust, scalable, performs well, etc.  For individuals who really want to deliver workable solution, standards vs. proprietary approaches are further down the list of requirements. 

Standard vs. Proprietary BPM

The key standards for BPM are:

  • BPMN 2.0 (Business Process Model Notation) - for fully automated service orchestration and human workflow management processes.
  • CMMN 1.1 (Case Management Model Notation) - case management is for activities that are less structured than BPMN processes.
  • DMN 1.1 (Decision Model Notation) - allows for decision table execution for business rule automation.    
  • BPEL 2.0 (Business Process Execution Language) - is language for specifying actions within business processes relying on Web services. BPMN, which maps directly to BPEL, was developed using a branch of Process Calculus, a method of mapping process to executable language.

BPM probably represents the closest attempt at true model-driven business programming. In other models like UML, there exists traceability of design model to use case and requirements, but none of models contained enough business logic to create real world applications emitted directly from a model. 

Pegasystems strategic direction is to be capable of creating application with no coding just OOTB functionality that is configurable and ultimately driven by business flow models. At the standards level, Pegasystems is achieving this goal, by only adopting a limited set of CMMN, BPMN and DMN notations. This is not to say that Pegasystems vs. other solution is propriety, it is the degree to which the software embraces a standard or perhaps interprets it. At least that is the way I view their approach.

While Pega PRPC can run in a number of modes, such as, a rules engine, process model, case manager. In most implementations, workflow processed in Pega is contained within the scope of a case. Therefore, Pega design logic contains both CMM and BPM (and DM) notation. The OMG stand on this is that BPMN is procedural, while CMMN is declarative and that these two notations should not be merged together.  

The Diagram 1 below depicts a CMMN process, the outer container (i.e. folder) is the case file; all activities in the case are contained within it

Diagram 1 – CMMN Specification


Diagram 2 – Pega Specification

Diagram 2 is a Pega representation of Diagram 1. In Pega, the case does not need to be declared, it is implied by the workflow process. So Pega essentially merges CMMN and BPMN. Indeed, some analysists have indicated that both BPMN and CMMN would benefit by unification and that the separation is purely vendor-driven and counterproductive.

In CMMN (Diagram 1) the octagons, called stages, are fragments of case logic and stages can be nested inside other stages. Pega also has a stage construct and is used to model the workflow at the highest level, such as, case setup, routing, processing, etc. These types of things can be viewed as “fragments” of case logic.

In CMMN the rounded rectangles are tasks, and the icon in the upper left signifies the task type.  In Pega an assignment is analogous to a task, which also has an inner icon that signifies what type of activity. The assignment can also be specified for service level agreements note the clock icon. 

Pega does not support DMN, specifically, but allows for BPM “decisioning” using decision tables and trees, a decision tree is implemented when logic cannot be contained using key value pairs. A decision tree is a graph that uses a branching method to illustrate every possible outcome by constructing association rules with the target variable on the right.

Pega also supports BPEL, but it does not use this standard in the way the BPMN uses this notation.  BPMN maps directly to BPEL it is required for Web service execution specification. Pega has a utility shape which is typically used to specify Web service invocation. While Pega supports BPEL, it is not used to define or orchestrate Web service processing and is probably offered as an ability to execute a preexisting BPEL process.  

Implications 

I am sure members of the OMG would take umbrage with my opinion that BPM standards are more like guidelines, rather than an implementable notation or specification. That said, creating notation that defines business events and processes is valuable for design time IT projects. Projects scoped as BPM are a somewhat unique modeling effort, because you are typically augmenting or reengineering some process that will benefit from this disciplined approach. Additionally, use case modeling, which is popular in most business-oriented projects today, does not have enough detail to really assist designers in modeling work flow, let alone more advanced functionality like routing logic and SLA (Service Level Agreement) as applied to case management. BPM notations have shapes/icons and built-in methodology for those types of business constructs.   

The problem with standards is that they, that is, standards organizations, try to standardize everything and try to leaving nothing left for the creative vendor or programmer. In any type of process there is a transaction handoff, there is a point in the project lifecycle where the design needs to allow programming effort to move the development process forward. The Holy Grail for BPM, as well as, application generation software is true MDA (Model-driven Architecture). This capability for complex application is still a work in progress.

Comments

Frank Teti
,
posted 5 years 47 weeks ago

I think both will exist for a

I think both will exist for a long time. You will never have just standards driven software that has never happened in and segment within the software industry. Conversely, no one would support standard-less software industry.
Ankit Tara
,
posted 7 years 4 weeks ago

Who will win in the long run?

Who will win in the long run?

Join the Discussion

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.