Another Invalid Criticism of BPMN 2.0

Active Endpoints CTO Michael Rowley on another invalid criticism of BPMN 2.0

John Everhard, technical director at Pegasystems has joined the chorus of voices claiming that “BPMN is too hard for business.”

He said:

“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.”

While I agree that the full BPMN 2.0 symbol set is not well suited to business users, this is not really the argument made by Everhard.  The main point seems to be the same one that Jim Sinur made last summer (and which I talked about in my CTO Tuesday episode #54).

What Everhard and Sinur are complaining about is that there isn’t a different symbol that reflects the type of work that is being done, for example resolving a case in a case management system or paying an invoice in an accounts payable system.  They don’t like the choice of icon at the top left of a service task. Service tasks are used to represent most kinds of work done automatically (i.e. services), and there is just one symbol that looks like this:

The problem with this criticism is that it doesn’t account for the extensibility built into BPMN 2.0.  The standard says that you can create your own icons if you want. The actual text is section 10.2.3, under “Task Types” subsection, and it says…

“The list of Task types may be extended along with any corresponding indicators”.

So go ahead. Feel free to create your own icons for the different kinds of tasks you have!

Does that remove the value of using the standard? Of course not. The icon sits that sits in the top left of a rounded rectangle, just represents a standard task. Tasks have important semantics that are irrespective of their type and which differentiate them from gateways, events, artifacts and other modeling constructs. So why not just stick with the standard, but extend it with icons that match your different task types?

However, I feel that the real argument with BPMN isn’t about the pictorial representation, but how well suited is the full icon set to business users. In my opinion, the only way for BPMN to be effective for a business user is to reduce the complexity and use a very small subset of BPMN (even smaller than the “core”).

Take a look at Socrates. This is a product that is designed for use by business users that uses a tiny fraction of the BPMN standard and ALSO uses custom icons for different types of tasks. The combination results in an environment that is natural to business users, but produces diagrams that are easy to understand and very pleasant to read.