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.

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.

My answer would be, that the Pi Calculus is a Low Level desription calculus for processes that communicate with each other, messages and message channels. This serves the simulation and analysis. The choreography model and the collaboration model are more like a notation with metamodel covering the processes and the messages, but not the message channels. It is more for modeling than for analysis, although the model can be input to the analysis and the simulation.
Also every BPMN choreography model or collaboration model can be mapped to a Pi Calculus description, but not vice versa. Pi calculus is more general and has no notation. BPMN is guiding the modeling process and therefore easier to understand.

When one want to use the BPMN choreography model or collaboration model as input to a pi calculus conversion or a simulation and analysis, the quality of service contract needs to be specified before.

http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/quality-of-service-contracts/
[ad]

Bibliography

1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).