Frank Michael Kraft's Blog

I was recently asked if I like this idea: Handle everything, that is coded in an ERP systems today as Process Patterns and instead design it as process models, that can be adapted to the requirements of the customer. The context of the discussion was if the combination of ERP/BPM/SOA would not have tremendous potential.

I aswered, that I have experience with that and that I agree that there is a tremendous potential with that. That really was an interesting discussion, because I did not hear such analysis before in the discussions in the public marketplace. I think this is the right direction to think.

I had already governed the design of the process of about 200 or more business objects, creating about 2.000 models including roughly about 5.000 web service operations. I didn’t use BPMN for that, because it was not flexible enough for this purpose, neither any of the existing languages. I used an own Domain Specific Language (DSL) for Modeling the behavior of those Business Objects.

My summary of that exercise is, that I agree to the original question. Only by modeling the process of Business Objects which are part of the ERP system, the ERP system’s web services will as a result have the right granularity. What is the right granularity for web services? Reusability. If web services are reusable, then they pay off most. In order for them to be reusable, they need to fulfil certain conditions. A web service operation should only do one thing at a time., i.e. not trigger an endless chain of activities in the system. It should have clearly defined preconditions. The effects and results of the web service operations must be clearly defined in terms, that can also be preconditions to other web service operations. That are the most important criteria in my view.

A system must be designed for this philosophy from the beginning. I strongly believe that adding web services to an existing system falls short of this goal. Even if it has some value, it would not use the full potential.

In general what I miss in the public standards is a language to describe the behavior of web services. Yes, BPMN 2.0 goes into that direction. But BPMN 2.0 still has to prove that it can fulfil the promise in practice. I think to a degree it can. It will turn out later, if it is possible to simplify the language or if it becomes an inspiration for other approaches (e.g. constraint based instead of workflow based).  And using BPMN 2.0 in itself does not guarantee the success. Additional guidance is necessary, certain quality criteria that each model must fulfil.

However, if the behavior of web service operations of an ERP system is defined, and if the granularity of the web service operations are so, that they are reusable, then the potential is very big. Because it means, that it is possible to attach own processes to that ERP service and even to interweave own processes in-between ERP processes. For example to add an approval before the release of an order under certain conditions, to add an own method of calculating benefits for the payroll and the like.

However as a limitation to the original question I would say, that not all of the processes modeled could be customized or changed arbitrarily. There are certain core processes, that the ERP system offers, that can not be changed without the danger of losing the consistency of the process. Therefore it is clearly necessary to describe which part of the process needs to remain stable and which parts of the process can change or are open for additions and interweaving. This of course must be part of the model.

So – it is very useful to have this tool for the top-down design of process interaction now. Inversely it can be used for the validation of an already existing bottom-up modeling. In reality it will be a mixture between the two. It is of central importance to have the enforceability in mind, that is to define a process, that is actually executeable by the participants. For this the model levels serve as basis for validation.

If we go down to the technical modeling, it is now possible to model Conversations, which are groups of Message Flows, Correlations, which are assignments between a message and a process instance, Service Bindings, Data Flow, … Compared to BPMN 1.2 the DataFlow is more than an artifact now (i.e. more than just a pictogram). It has a datastructure and the Activities have DataInput and DataOutput. Also the DataObject can be used as Parameterspecification for reusable Subprocesses. The Events have been enhanced. There are complex Events, Events , that can interrupt an activity or not, it is possible to define Event-Subprocesses that run aside from the Sequence Flow.

Here some critical comments from my side may be allowed. I think the workflow type of modeling is too strong in this. First there are strong sequence flow relationships established, only to be loosened later by many Events. I think it would be better for the future to define the relationships more loosely from the beginning. For example they could be modeled as preconditions depending on the status. That is something for the future.

Personally I found the discussion around the relationship between public and private processes very fascinating. One time it seemed like we had so many problems with it, that we could not do it. And additionally to this there was the climax of the debate with the concurrent submission. We were blamed, that our model was too strict. A very good discussion! But we found a very simple and elegant solution to these problems. The sequence flow is now not so strict than it was before. It has been loosened, and the difficulties disappeared.

Furthermore one important area is to have in mind the asynchronity of messages. That can produce race conditions between messages. However this in my opinion is not mainly a technical problem, but is due to the asynchronous nature of business processes, that I hope to discuss in the Blog as well in the future. Most problems on the message technology side can be avoided on the business process design level – and that is good news.

There are more changes from 1.2 to 2.0, but in my view these were the most important.BPMN has become quite powerful. Sometimes it is not so clear as to how to solve a certain modeling problem. However the success will depend on elaborating best practices and good guidance.

My wishlist for BPMN in the future? Modeling of Interactions with and of Business Objects. Find simpler ways to model special cases. Model a Process specific  Status.

But now is the time that BPMN 2.0 has to be used and proven in practice. After that we can establish our common opinion about the wishlist for the future. It is a language. And the vocabluary is only the beginning of the process to learn to speak that language. Therefore a good coaching process is what I can recommend.