I want to share some thoughts about it.

First Prof. Börger looks at some of weaknesses of the BPMN 2.0 Standard.

He sais:

The crucial criterion is how well the practitioner is supported when walking through the different levels of detail (refinement levels).

The standard does not support process structure at the risk of producing incomprehensible spaghetti diagrams.

The standard document fails to provide a seamless systematic mechanism for refinement from conceptual to executable models, which is necessary to guarantee the reliability of the implementation.

I discussed the same topic some days ago. I agree that the standard does not prescribe a solution to the problem, but as I said keeping some basic rules the solution is easy. It is always a question of discretion how much should be prescribed by a standard and how much should be described in a guideline or methodology or best practice how to use a standard effectively. There are always many ways to do it wrong, but as long as it is easily possible to do it right, it should not be such of a headache. As I said I will discuss the way to do it right in the seminar BPMNexpress. In general also I teach it also in the mentoring.

He also sais:

Furthermore a statistical evaluation (of BPMN 1.1) shows that `the average BPMN model uses less than 20% of the available vocabulary’ and that, out of the more than 50 graphical elements in BPMN, `Only five elements (normal flow, task, end event, start event, and pool) were used in more than 50% of the models we analyzed.’

Yes, and this is why it is possible to learn what you really need to know about BPMN in half a day. Of course full mastery is only reached within a longer process of modeling, mentoring and quality assurance. But this is normal with any modeling method.

The he talks about difficult modeling concepts in BPMN 2.0:

The lifecycle concept is an example of an underspecified feature, particularly in relation to the equally underspecified interruption mechanisms like exceptions or cancellation or compensation for transactions.

I have the same opinion. I tried to convince the BPMN 2.0 standardization team that these concepts are too difficult and problematic. Now I recommend to my clients not to use them. However for all of these problems, there is an easier way to solve them.

A general notion of state is missing and, as a consequence, the specification of relevant data dependent conditions is only poorly supported.

In fact BPMN 2.0 has a notion of state for data objects. This already helps a lot! I do recommend to my clients the use of state for data objects and it makes many modeling problems much simpler.

And yes, the state model is not very elaborated – but it can be extended.

Communication and process interaction are poorly supported for concurrent execution, e.g. of independent (not embedded) subprocesses or of processes belonging to different parts of one organization or to different cooperating organizations.

An analogous problem results from the poor interweaving of different BPMN diagram types, in particular that no consistency criteria are imposed for them, for example collaboration vs choreography vs process diagrams.

I do not agree at all. This is one major part of what is new in BPMN 2.0 compared to BPMN 1.x. I will teach this in BPMNdelta.

Later Prof. Börger looks at difficulties with WPI Workflow Patterns

The workflow patterns, as presented by the WPI, come without pragmatic or rational foundation. In fact there is no statistical underpinning showing how frequently which patterns appear in real-life business processes.

My opinion is that some of these are of practical relevance and others are not. I am preparing a publication on the topic, but it is not finished. Also most of these patterns that are relevant in practice can be reduced back to very simple principles of modeling.

Prof. Börger has the same opinion as he sais:

In fact most patterns are not of fundamental character but are easily definable from a small set of more basic and rather simple patterns.

In the last section Prof. Börger discusses YAWL and coloured petri nets. Some of his statements:

In this section, we show that the purported semantic foundation of YAWL using coloured Petri nets is not `suitable’ for the practice of BPM.

… deal with patterns that Petri nets have difficulty expressing, in particular patterns dealing with cancellation, synchronization of active branches only, and multiple concurrently executing instances of the same task.’

… languages which `lack the concepts to be able to deal with the broad range of requirements one may encounter when trying to precisely capture business scenarios’ directly applies to Petri nets, work flow nets, reset nets and other extensions proposed for modeling business processes.

I already discussed some days ago, why I would not build a new standard for Adaptive Case Management based on BPMN and I argued it is because of the “token logic” – actually what is meant is the petri net logic of BPMN. So we – Prof. Börger and me – have the same opinion on this if we refer to advanced scenarios. These are some of the topics that I will discuss in BPMfuture.

As I said BPMN is good for some problems, but it is difficult with more flexibility as it is needed for Adaptive Case Management and in general for the work of knowledge workers. Instead of building more and more complex formal constructs to address all of these special cases it is easier to not use petri net at all for Adaptive Case Management.

However I am more optimistic than Prof. Börger when we refer to cancellation scenarios and BPMN. Yes – he is right it is very difficult with petri net – but BPMN also has other features of modeling. It is possible in BPMN to use data objects and state – and therefore it becomes easier to model cancellation scenarios. I do teach this in BPMNexpress.

Finally he proposes to use a concept of introducing Product Lines to BPM. I have to study this more, before I say something about it.

At the BPMN 2011 Practitioner’s Day in Potsdam we had the opportunity to try out tangible BPM modeling or t.BPM. It is a research project of the Hasso-Plattner-Institute. Instead of modeling in half-dark rooms with flickering monitors we went outside into the sun. There we had tables prepared and plastic shapes for BPMN available. The team grouped around the table and we placed the shapes on the table to model. Pens were available to label the shapes and connect them.

I really liked this very much. It was fun. And I think it was quite productive. The focus of all team members was on the model and we were fast in achieving a result. It was good to discuss during modeling. I also liked, that by this all were focused on the model itself, not the tool. Often when modeling we lose time to fiddle with the tool, the routing of lines etcetera. I think I might use it in future BPMN classroom trainings. I expect that it is possible for the participants to focus on the model and the BPMN method; to have a shared collaboration experience. So in my eyes it is ideal for BPMN classroom trainings.

That’s when I thought, what if Business Process Modeling could be made more real by means of virtual reality. In know – Second Life is not the place, where one would meet too many Business Process Modelers. But – there are businesses to be fair. Even though the hype is gone, it’ still there and – a place where I could try the idea of more tangible Business Process Modeling in a virtual reality.

Viola.

What, if a group of avatars would meet and collaboratively move around and build the process? Discuss about it, while they watch each other? They could simulate the process and adapt it, if necessary.

Ok – maybe the process is more like the 3D version of a paper or screen type of pattern. So why not try one or the other pattern? Like walk though the process?

Maybe completely new patterns of representing models emerge over time. Maybe it is also an idea to sit at a table and use activities like lego bricks.

Maybe even if 3D is exploited in a better way, sub processes can be displayed together with the main process. Or the whole process is like a big house with many rooms.

Interestingly enough in the last BPM 09 conference in Ulm there was a scientific discussion about tangible process modeling. There was a research project where Activities were made tangible by means of plastic bricks and people moved them around on the table. In the real world I mean. They mentioned the next challenge was to digitalize the result in a more effective way. Well – maybe virtual reality modeling is the solution to this problem. In some future.

So – that’s my fun project.

http://www.bpmn-selftest.org/

I made it to rank 14 of 394. However I wonder who the 13 were, that were better . So give it a try, maybe you can beat me. The test is anonymous however.

Nevertheless I want to share what I thought when I saw the models. They were quite complicated. I think if models are as complicated in a real project as those in the test, then something went terribly wrong in the first place. I agree, that it is fine for a research project to use artifical complicated models, to find out more about human model comprehension. And I am very interested in the research result. But models must be much simpler than those.

Simpler models could be reached by limiting the scope of one model – i.e. splitting it up in different parts, using submodels for example. As far as I remember human comprehension can assess 7 items at once, not more. So in essence I think a model should not contain more than about 7 important steps.

Also it can mean to model only the most important cases and model the special cases in a different model.

And it can mean to question, if BPMN is the right model language for the purpose chosen. I know that BPMN is popular and becomes even more, because it is a standard. But in my eyes the question remains, if the task flow oriented modeling it does is really the best way to do it. In my eyes it should be evaluated as a result of this research project, if goal driven and constraint based modeling would not result in much easier models.

This is my BPMN 2.0 Overview Map.

It shows a Choreography model in the middle, Orchestration with public Processes and private Processes, that belong to the public Processes.

Systems integration is the realization of the underlying business processes. This sounds so simple. But in reality there is often a misalignment between the business process design and the systems design. It is the wrong way to just implement business processes, that are as they are today or that are designed without discretion of the principles of loose coupling.

Often system designers need knowledge about how business processes work, but on the other hand business process designers need knowledge about how system integration works. As long as both sides are willing to learn and willing to share the knowledge, it is possible to come up with common principles of modeling, that avoid the most common mistakes, that lead to project cost overrun or failure.  I say it clearly what I mean: using BPMN 2.0 choreography modeling language in itself is no gurantee for success. But: It is a VERY useful tool for the communication between the business and system experts, which is a necessary condition of success.

So in other words, it is necessary, that the process design follows the principles of loose coupling of business processes. That is no design task, that can be solved by system designers alone, if the business process is modeled in a tightly coupled way. In other words: If the business process is designed in the right way – in the loosely coupled way – then the system design is without a hitch. If the business process is designed in the wrong way – there is no way to save the project on the system design level.

So are business experts forced to design business processes different, just to make the job of system designers easier? No. If it is designed that way, it is a better business process. It would work even better even if there was no system, but just paper and phone. It is more tolerant to errors. It gives the individual more freedom to decide. It makes it easier to reach the goal. Yes, it requires a little bit more brain power than just modeling the sunny day case. But in the end it pays off abundantly.

And in my eyes this is good news. It is NOT the system programming that dominates the design and dictates the constraints. It can be the business process needs again, that prescribe the way to go. And that is why BPMN 2.0 is so helpful, because it starts with the business process model.

If you are german speaking, you might like this short video explaning the new possibilities of BPMN 2.0.

Neue Möglichkeiten mit BPMN 2.0 from AdaPro GmbH on Vimeo.

Compatibility of the services is not so obvious in the first place. The question to be answered is, if for all possible sent messages the other participant (or service) is ready to process it, and if both can complete their control flow in all cases. For example if one participants sends an order cancellation, but the other participant cannot process it, because the order is already delivered, and it has no control flow to deal with the late cancellation, then the services are not compatible.

Typically this can be checked by comparing all possible states of all participants and all messages. However this brute force method consumes much memory and computing time. Probably this is one reason, why it is not yet offered in so many or even a modeling product at all – which I do not exactly know. The proposed method in (An efficient necessary condition for compatibility, 2009) is to use a method known from petri nets: to convert them into matrices (state equation) and use the matrices to determine the compatibility in a much more efficient way. This is definitely interesting to consider.

The paper states, that this can be used for service discovery and mediator construction. In my personal opinion these use cases are very advanced research use cases, which are not yet so relevant in the practical industry application. Even the mediator construction I have severe doubts, if this is a way that will lead to somewhere at all. But I might be convinced later.

But very relevant is to support the design process of services which need to interact. If there were a repository, that would contain such compatibility determination method – that would be a great step forward. Furthermore it would provide the industry use cases that are needed for further research on the matter.

References

An efficient necessary condition for compatibility. Oanea, Olivia und Wolf, Karsten. 2009. [Hrsg.] Oliver Kopp und Niels Lohmann. Stuttgart : Universität Stuttgart, Fakultät Informatik, Elektrotechnik und Informationstechnik, 2009. Services und ihre Komposition, Erster zentraleuropäischer Workshop, ZEUS 2009. Bd. CEUR Workshop Proceedings Vol. 438, S. 81-87. http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-438/paper13.pdf.

In my personal opinion the use of preconditions is a good thing in general. However in my opinion the splitting up of the whole behavior into different scenarios has also disadvantages. For example that it is not so clear, if one scenario is changed, which side effects this has on other scenarios. Also one transition for example can occur in different scenarios. Thereby probably many scenarios need to be changed, if the behavior of one transition needs to be changed. Also a problem is, that it is not so clear how to model differen alternative behaviors. If the union set of all scenarios describes the behavior of the service, it is all one. So for example if there is one big service, but the behavior can be different – for example in one case with confirmation, in another without confirmation – this is not possible to be modeled. It is just a “confirmation” scenario in the set, but it is not modeled, that is sometimes must be used, sometimes not.

Good is that in the end of the paper it is proposed to integrate the scenarios into one view. This I agree upon. My personal opinion is, that I would rather start with the integrated view. Because all the mentioned disadvantages are not there in this case.

But I admit, that the use case proposed in the paper may still be valid in a consulting experince, where the client already has described the behavior of his services in the form of scenarios. Then, the method proposed is a good way to unify them into the desired integrated view. This may also be supported by tools, which gives an additional value add.

Also notbody should be distracted by the notion of the modeling language. This is just the underlying logic. The same method can as well be transferred to industrial languages, as is proposed in the paper and as I believe. For example I see no reason why this should not be useable in a BPMN 2.0 orchestration model environment.

So the paper proposes, that for the purposes of service validation, (automatic) service construction, service composition and service replacement there is not yet a represenations, that allows for a closed theory – i.e. a structured solution in all cases. Actually it is an opening paper that will be later completed by describing “operating guidelines”, which are intended to fulfil this purpose.

My personal opinion is, that is it a good endeavor. Such work is needed to complete the foundation for modeling tools, that allow for more comfortable modeling consistency checks and functionality.
I especially see much benefits in consistency checking. I also have one or two patents in this area. Important in my view in consistency is a clear definition of the goal of the check and a good method to explain consistency errors to the tool user. Consistency checking is in most cases useful. One needs a little bit of patience, to make a service definition fit to another, because there is always this one unwanted execution that needs to be eliminated. But it is worth the effort, because it is better to eliminate these errors in modeling time than in runtime.

Service construction is in my personal opinion difficult. In my view there are always abiguities in such an endeavor. So I prefer “human” design plus consistency check.
Service composition promises some benefit – especially if there is a skeleton composed, which can be further edited by the human designer. Also here it is important to formulate clear goals of the service composition and to have a complete – i.e. without gaps – description of the underlying services. Especially if there is a Business Process Platform that offers services, that need to be composed, and that is model driven, this is very promising. There are also other projects working on this. I may come back to this some other time.
Service Replacement is certainly an interesting application. If a service is changed, then it is certainly worthwhile to know potentially which consuming services might be affected and which not. This may be the outcome of this part of the research.

So good work – keep it going!

• structured,
• unstructured and
• semi-structured

processes, that I like. It is interesting, that in the definition of process the emphasis on the post is less on the sequence of activities, but more on the business goal to reach. That was, what I proposed earlier. And it makes sense. In the end it is more important, what the result of a process is, than what has been done or should be done in which order to try to (!) achieve it. I said “try to” because sometimes just doing a thing can not guarantee that the desired result is achieved. That’s why I say that the result is more important than the doing of an activity or task itself.
Of course it is inevitable that when a business process is implemented in an business process platform, that it is structured. Otherwise it is impossible to implement the business functionality that transforms the business objects that are part of the business process from one state to another. That is said modulo that there may be some generic functionality like a process engine for workflow or generally for execution of modeled process parts of course.
BPMN supports some Ad-Hoc modeling cababilities. There are Ad-Hoc tasks where the sequence is not defined or where it is not defined if none, one or all of them are executed. However one would expect, that any task that can be executed is modeled – at least if it is not, it can not be system supported. Also it is a difference, if the Ad-Hoc cababilities are on the process type level, or on the instance level, meaning that a concrete process instance can be adapted to a new, unexpected flow, sequence or even new Ad-Hoc Tasks.
However the more the tasks become Ad-Hoc the more they become an empty shell. What do I mean by this?
Create an Ad-Hoc task “Calculate stock losses based on financial crisis”. Of course if this is done the first time, there is no busines logic implementation for this. Even if there is a SOA service offering the solution, there needs to be some implementation of calling the service, which means gathering and providing the needed parameters and using the result in other processes.
So – as soon as a process is implemented in a business process platform it has at least some constraints.
Which is ok – because it has been formalized, because it’s execution is more repetitive.
On the other hand especially in times of crisis the importance of Ad-Hoc processes grows to account for the need to compensate unforeseen difficulties in the daily “business as usual”.
The important thing is, that the structured, the unstructured and the semi-structured processes can be integrated as seamless as possible. This is only possible, if there is a common notion of result of a process or of an activity in the process. Furthermore it is an interesting question – especially in semi-structured processes – how much constraints are desribed.

• None Constraints: Unstructured.
• Some Constraints: Semi-Structured.
• All Constraints: Structured.