BPMN 2.0 – A Step Sideways!

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 artifact 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 (despite earlier claims) 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 modeller 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 accordingly 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 Excellence 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 adaptable 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. To  enable BPMN to play a role in a dynamic adaptive process environment it has to be directly executable and editable at runtime.

11 Comments on “BPMN 2.0 – A Step Sideways!

  1. Thank you – enjoyed the article. What method and supporting tool would you use to model business processes if not flowcharts and and BPMN?

    Like

  2. Thanks for the comment. I propose to model the business entities, including content, roles, rules and goals and let people work collaboratively in that well defined space. Thats what we use in our Papyrus Platform. It is graphical modeling, but we do not create rigid flows. A state/event/rule/role process can also be very strictly controlled, but only a small percentage of processes and process elements has to be that rigidly controlled. It is more important that the goals are part of the process instead of the flow, because then I do not need BAM and BI for monitoring.

    The key benefit is a reduction in upfront analysis time and cost. Substantial better reusability, more flexibility and adaptability and because humans enjoy to work with more freedom they can also service the customer better while under full transparency and quality control.

    PS: The post is an excerpt from an upcoming book.

    Like

  3. Max – I would suggest that you look at Role Activity Diagrams … you will I think find them quite interesting. The best references being Martyn Oulds book “Business Process Management – A Rigorous Approach”

    Like

  4. Derek, thanks. We use aspects of RAD in our visualizations, but we find them also to be fairly complicated for a business user. It is another view that one can take and it can be helpful in some situations.

    We seem to be going into the direction that the user/designer can choose from a number of visualization the one the fits the current process the best. That also seems to make sense, that there is not a single form of process view in a complex adaptive environment. It would be too restrictive.

    Like

  5. I agree with many of the good points you make here. There are deep problems with any attempt to reduce a business process to a diagram.

    Round trip of course is provided by XPDL, but that does not solve the fundamental problems.

    I would like to discuss the possibility that a “language based” approach may offer a solution. It is my observation that what we search for is mainly a way to discuss business processes, not so much to program them. An enactment system can certainly help to inform people of progress, but progress is described in terms of an agreed upon sense of state. That state is a fiction, but one that we all buy into in order to coordinate our actions. Thus, when I say I am finished writing a book, that does not mean that all acts of writing stops, but rather that I commit to being much more careful about how I change things.

    My approach has not been so much to model the “reality” but instead to model the “shared fiction” which is described by words that themselves have fluid meanings. If I re-read that sentence it strikes me as bogus :-) , but in fact such a model is very useful in allowing people to coordinate their actions, and allowing businesses to accomplish goals. In otherwords: flowcharts are not a failure if used in an appropriate way.

    OK, there is no way to cover this here in a comment. I really like your points about “complicated” and “complex”. I really think you have latched on to something important. Success or failure depends upon how you use these models, and I believe a LOT of people want to use the model in a way that simply will not work.

    Like

  6. Keith, thanks. Yes, if flowcharts are visualizations for understanding but not restrictions in operation, then they are fine. That is exactly the way we allow them. They are also ok on a high enough level.

    Let me elaborate that not the meaning of the description ought to be fluid, but the process must be flexible except a few game rules and goal values. Roles must be allowed to adapt the process at any time as long as those rules and goals are met. One fairly simple process can then provide the framework for an unlimited number of variations.

    What has to be modeled firmly are business entities and content, exactly those two elements that flowcharts do not provide for. Maybe BPMN 2.0 will eventually.

    Flowcharts models are virtually always used as means of control and not user enablement and that’s what is wrong with them.

    Like

  7. Max, Very interested in your thinking around this BPM topic. Wondering why I haven’t found this blog before!

    I have come to the same conclusion; that BPMN is not effective at modelling the real word, well … not without looking at the real world as it really is.

    BPMN can be utilised to express the “methods” in real world business entities, or the “plans” within goal directed business agents. Role Activity Diagrams can also be applied, for that matter.

    Business Entities & Goal Directed Agents are higher order modelling constructs that convey real world meaning with grammatical rigour, while BPMN just represents the basic words and syntax of a process “language”.

    These two organising principles for modelling & design do require representation of process case state and interaction with an event model. While BPMN 2.0 has (way too) many event types, it plays lip service to data state or data state changes. Back to UML for state modelling.

    I’ve been using these techniques in modelling for some years with sound results but while we can represent and execute a BPMS that looks like the real world, the design artefacts start to look more like the entrails of an event driven, multi-tasking operating system rather than a back office procedures manual.

    So while I think you/we are on the right track with a NON-flowchart centric approach, the challenge quickly becomes how to develop a common (visual) process language that can be agreed by all, from the boardroom to the call centre floor.

    Like

  8. Pingback: SOA and BPM Agility: The Perfect Trap! « Welcome to the Real (IT) World!

  9. Hi Max,

    I’m not sure I entirely agree with the comment “[BPMN 2.0] remains firmly footed in the flow charting domain.” I don’t think it really knows in which domain it sits, it seems to straddle several without actually providing a complete solution in any. I guess that’s a result of the competitive nature of all the vendors involved in it’s creation. I know there are ‘sub-sets’ of the notation that can potentially be used for business facing processes but on that side I have to agree with you.

    “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.” You’ve got to question whether the amount of work required to capture these blueprints is justified by the value? I’ve been trying to explain this to clients for years but I clearly don’t have the experience and depth of knowledge you have on this subject. (Although I think some of your explanations might frighten a few people away! :))

    I do believe there is some value in flow charting, but at an appropriate level, at a sufficiently high level that it makes sense to the actors but doesn’t constrain their ability to adapt to different scenarios. That level will change depending on the nature of the work, for example, the level of decomposition will probably be lower for a contact centre worker than for a field engineer.

    The approach I take is output focused flow charting. We capture activities but these are fairly high level, we focus on the output of each activity. A level of knowledge, skill and experience is assumed and this is what dictates the level of decomposition, hence why it might be lower for a contact centre worker that may be fresh out of school and not posses the same level of experience as the field engineer. Even the sequence the activities are placed on the chart is not ‘that’ important as it is the collective effect of the combined outputs that ensures the process is completed correctly.

    This gives the actors more freedom to complete activities or processes as they see fit based on their knowledge, skill and experience. What we also try to do is place within the activities various tools and additional information the actor may need to reach the outcome. This could be links to systems or guidance/policy to help make sense of unexpected situations.

    This seems to be similar to the approach you describe in a subsequent comment? I’d be interested to know if/how you try to relate those to executable code? My view is that BPMN is redundant as it doesn’t meet the needs of executable code and is too rigid for the business therefore it’s an unnecessary step. But do you guys automate this in any way or do you still require a technical expert to create workflow based on your graphical modelling? Or something else?

    Craig

    Like

    • Craig, thanks for reading and commenting. You provided some valuable feedback and valid points. Yes, it is better people are frightened away than to approach BPM from a silly cost cutting perspective. It is actually much more than that.

      We agree on the high-level of flowcharts and my point is that at this level we don’t talk about flows, but about a value stream with process goals! What you call output are those goals and outcomes in terms of perceived value. Output is still to manufacturing oriented as a term (for me at least).

      ‘Executable code’ s only necessary for the backend-silo-data-access orchestration but not for human to human services. Yes, we need both and therefore some flows wrapped in subgoals as fragments of the larger process goal works well. IT only provides the data model backend linked by SOA (or other) so that business performers can create processes with data and content and guided by goals and rules can be created without IT involvement. Succesfully achieved goals (and all their real world executables) can be turned into templates for future use (means it is adaptive by reusing knowlegde).

      Thanks again, Max

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: