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.

First, what is a Choreography Model? Spoken in general terms it does model the participants of a message exchange, the messages exchanged (not necessarily the structure of the message), which interactions (message exchanges) are desiged betreen the participants, who is the initiator of an interaction, and which interactions follow on which other interactions.

The benefits of modeling a Choreography are the general benefits of doing a design for anything. It gives transparency. It results in quality, because of clear-cut statements of the boundary conditions, if fosters collaboration by forcing to discuss the message exchange contract. It can be simulated and thereby problems can be found before implementation and the consistency can be checked with other models – especially process models of the participants.

Sending messages at unspecified points in time between participants and hoping, that they will somehow be processed may seem easier in the beginning, but experience shows, that this does not pay back. Error handling is especially difficult in distributed SOA landscapes. Therefore giving the interaction a backbond and skeleton by modeling it in the first place, is key to success.

This model could even be used in the runtime by letting systems validate messages that arrive or are being sent against the model. By this two things happen: (1) The quality of the model is forced to be on the highest level (in contrast to “just a drawing”) and (2) messages sent or received at the wrong time can be identified as contract violations (instead of clumsy debugging of the application coding).

A SOA consists of Process Components, each of which fulfil a certain business functionality, that interact with each other. One possibility is that a Composite Application does call Services of an underlying Business Process Platform – be it synchronously or asynchronously. Another possibility is, that Process Components of an unterlying Business Process Platform communicate with each other by mainly asynchronous web services. Examples for the first were mentioned above while examples for the second could be a Process Component for Supplier Relationship Management including Purchasing and a Process Component for handling the Delivery, that exchange asynconous XML messages with each other. Another example is the message exchange between a seller and a buyer.
The modeling of a choreography can adress both purposes. It does focus on the exchange of the messages alone – i.e. internal details of the process components are not modeled in such a model.
However it can server as a Top-Down Design methodology – if new Process Components will need to be designed, or – it can serve as a contract between two communication participants, that are adapted to the message exchange.