John Everhard, Pegasystems
Following CBR’s story last week in which business process management guru and chair of standards group the Workflow Management Coalition, Jon Pyke said that support and take-up of the BPMN 2.0 standard has been "disappointing", John Everhard, technical director at Pegasystems told us that’s partly because, "BPMN is too hard for business."
Business Process Modelling Notation (BPMN) is a graphical representation for specifying business processes in a business process model. It’s meant to provide a simple means of communicating process information to business users, process implementers, customers, and suppliers. It was developed by the Business Process Management Initiative (BPMI), and is now maintained by the Object Management Group since the two organisations merged in 2005.
The beta specification of BPMN 2.0 was approved by OMG’s board in September 2009. It was ratified as a standard by OMG in January this year.
"There are lots of people pontificating about BPMN 2.0 but full support and take up has to be a big disappointment," Jon Pyke told CBR.
Content from our partners
A range of vendors responded to Pyke’s comments in a CBR article yesterday. The OMG has since refuted claims that adoption has been disappointing.
But Pegasystems’ Everhard said: "PegaRules Process Commander includes a BPMN 2.0 process modeling Stencil that covers more than what is considered ‘core’ to BPMN. You can also design your own stencil and associate shapes to PRPC process functions. Nobody has BPMN 100% covered, everyone has customized interpretations of BPMN 2.0."
He said the firm believes its native modeling has many advantages over BPMN 2.0. "BPMN obscures the business intent with technical details best handled in rules or by the platform itself," he said. "The Business driver behind BPMN 2.0 is driven by the large ‘stack’ vendors who are trying to address the issues of disconnection between their process models and their execution platforms."
Everhard added:
"BPMN is too hard for business, as [Gartner BPM lead analyst] Jim Sinur accurately represented it; "BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark. Fortunately a number of BPM vendors are smart enough to support multiple representations, so that both audiences can we happy. I get the idea of standardization for engineers that are disciplined, but not for business folks. If we fully expect BPM to enter the "C suite" and become the business man’s best friend, it had better shape up its image."
Everhard continued: "BPMN has some deficiencies. The UI is represented as a service call. It is not tightly integrated with the model unlike Pega’s screenflows and flow actions. There is no concept of Case Management which forms an increasingly important component of enterprise BPM suites. There is no concept of business rules, other than a small expression language, and linkage to invoke a rule from a separate technology. Finally, there is no concept of situational selection in BPMN that is the driver to agility and reuse across an enterprise."
"The BPMN 2.0 specification has been so tightly coupled to the more technical BPEL-based execution model as to impact its usability by business analysts," Everhard said. "BPMN does not allow business analysts to fully describe the full scope of their objectives and intents."
He concluded:
"Business applications consist of more than just process models, they include user interfaces, data models and must be managed in a hierarchical repository that understands how to apply the appropriate business rules and process elements "situationally" – taking into account dynamically circumstantial information such as customer type, customer value, product, geography, temporal conditions, in fact anything that can be codified and inspected at execution time by the BPM engine. By forcing everything, including business rules, to be modeled as a "process", BPMN has fallen short of describing what happens beyond the "happy path", the rules that govern processes (Unified Policies and Procedures) and the technical implementation details."
Please follow this author on twitter: www.twitter.com/jasonstamper
