I have just taken a further look at the BPMN 2.0 proposal to see if we could use some of its standard graphic modeling concepts for our process visualization in our Papyrus Platform. I was very disappointed. The enhanced and additional definitions create ambiguous models. An ‘Activity’ can still represent any number of different functions and the new event types are lacking in detail on how they interact with the flow. There is still no artefact method, attribute and state modelling and no business rules. The proposed UML-like data modeling seems non-existent. Thus, it will be impossible to use BPMN 2.0 for exchange as-is and it still has to be transcoded to an executable format (i.e. BPEL plus Java) using additional information that is not mapped into BPMN. Thus, no roundtrip and user empowerment! All inbound and outbound content and GUI artefacts will still have to be programmed. Hence, a lot of project management bureaucracy.

Obviously a lot can still change and maybe 2.0 will take a few more years to become a final spec. But I feel that all that is to no avail as it remains firmly footed in the flowcharting domain. But what are we trying to achieve with a process model? Gain an understanding to calculate how the systems will react given a certain situation? Simulate what will happen when certain actions are taken? Control the system so that it becomes more manageable? Achieve transparency of the processes en-route and completed?

A BPMN model has only the acting agents (users) as real world entities whose functions and decisions to perform these functions can’t be modeled unless substantial abstraction is performed. BPMN 2.0, as all flowchart models, is STILL functionally blind to the inner function of the major elements of a business process (content data and context) and therefore to its decision logic. Flowchart modelers see the world (a business) as a ‘complicated’ system that can be decomposed into a sequential causal chain of functions ‘to be executed’ and a limited set of states that causally control the execution. The relevant process knowledge is however hidden in a) functions performed by different agents who influence state changes on business entities and b) patterns of entity states and attributes that cause different agents to perform certain functions, and c) a variety of complex business events that can change entity states at any time. Flowcharts are unable to represent that even if one could extract and analyze all the information from the agents and the entities! As bad as that is, it is not the key problem.

A classical model of physics (i.e. a watch) is complicated, but the economy or a large business that consists of individually acting agents is complex (Anderson, Arrow, Pines – 1988). The flowchart fallacy is to see a business as complicated rather than complex. Holland et. al (1986) proposed a method of real-world modeling in which the world consists of various states S where a transition function F(S) changes a given state at time t into a new state a time t+1.  The caveat is that in a complex system the modeler using a modelling function can neither accurately describe the state space with all its entities nor can the function F – and its causality – performed by the agents be accurately known.

While the Law of Large Numbers allows us to build a statistical representation of real-world situations across a large number of entities and thus there seems to an emergent pattern, this does however not describe a causal law. The LOLN is an observation and cannot be decomposed into why the various agents came to a particular decision. The individual agents have only a certain probability to interact in a certain way and as much as that can be modelled, it does not allow the modeller to deduce a function to act causally correct on all entities in the same manner. The simplified ‘complicated’ model will therefore be quite wrong when people are involved. That explains why the reductionist approach works well for a robotic production plant but not for people.

The reductionist modeling hypothesis suggests the more a decomposition in smaller elements takes place the more accurate the model would be. Anderson proposed in 1972 that reductionist models are misleading for complex systems because they cannot map and predict emerging properties. Thus they cannot be used to construct the system from the decomposed bits and pieces. The model representation in such situations can only happen through destroying and redrawing the blueprint using the new functions or entities. The reductionist ‘complicated’ model cannot adapt to external influences or to changes in its agent functions.  Flowcharting is acccordingly abstraction based, top-down modeling of complicated functions that connects purely hypothetical snapshots in time with statistically inferred rules that are not causal in reality for a complex adaptive system, just as global warming theory.

Hereto I propose (as I have done for the last ten years) that BPMN 2.0 and flowchart models are still a failure for designing business processes, because a large business clearly is a complex adaptive system that consists of individual acting agents with its employees and customers. Trying to simplify a business into a ‘complicated’ system, forces the agents into non-individual actor-robots and makes the system unable to adapt to the customer agents or to other environmental changes, except if one goes back to the blueprint. That is exactly the situation why we have IT Governance and Centers of Execellence bureaucracy who have to redesign the blueprints. As this typically requires long and difficult projects to implement, BPM reduces the agility of a business rather than improve it.  If agents (such as customers would) refuse to be controlled, the model breaks not only down but produces wrong results.

I propose that a bottom-up approach of real-world objects that can map state-changes and identify causal patterns from unimpeded user activity creates a much more realistic and adaptible model of business activity. Rather than to enforce the agents to perform in a certain way, the system simply enforces basic rules of the game and creates substantial transparency and therefore flexibility and adaptability. Process management has to offer complex real world models of people acting as a social group on business entities. Flowcharts are at most usable at a very high level, for example to show the dependencies between process owners and their goals.

As for BPMN 2.0 or any other flowcharting BPM approach, why would you want to reduce your business agility?