(prompted by this item on PCM)
This is a selective summary.
BPEL is not great for BPM modelling
BPEL's association with BPM is problematic from the viewpoint of the BPM modellers (i.e. based on good marketing). The only association is that a BPEL process can be shown as a diagram and that the language has support for wait states.
The BA is supposed to be non-technical, so the chance that the activities in the model correspond to available WS is small. BPEL is block structured, and this is too limited for modelling purposes. Analysts need the freedom to draw boxes and arrows, which always leads to graph structures and arbitrary cycles. A BPEL process doesn't have a notion of transitions. So usually, it's not possible to keep the analyst's analysis diagram in tact when translating into a BPEL executable process. This is exactly why the mapping BPMN to BPEL is hard and has so many limitations.
Another problem is the limited data manipulation capabilities. Extracting pieces of content from an XML document is most of what you need in service orchestration. But for BPM, often a lot of data processing needs to be done in between steps of the process.
If you consider using BPEL for BPM, ou should ask yourself is whether you want your core business process data in the ESB. The domain data that the BPEL engine needs to maintain is usually stored in relational databases. The information in your core business processes must be easily linked to the domain information in the relational databases. This information should be included in the domain model in a database. Not inside the BPEL engine. BPEL doesn't prevent that kind of information to be stored in the domain model database, but it makes it harder. You might have to implement a special web service to get the customer reference stored in the domain model. So BPEL seems to make it easy to get your domain model information partitioned.
BPEL is a good technology for scripting new services as a function of other services. But that it doesn't deliver on its promises for BPM, for which it is currently known. That doesn't mean that BPEL is bad - if you use it as an integration technology to build coarse-grained services out of smaller grained services.
BPMN for BPM modelling
As an analysis language to help with the documentation of a business process BPMN is a very good option. A BPMN diagram improves communication between analyst and developer, but the developer still remains responsible for all the technical details that are a part of the executable process.
A BA creates a description of the business process including a diagram. Then the translation needs to occur to the executable process language. The impact of that translation will depend on the analyst's technical skills and the capabilities of the executable process language. In any case, the goal is to have a minimal impact on the diagram so that the BA recognizes and understands the diagram of the executable process. Note that the diagram is only the tip of the iceberg, because a lot of technical details might be included in the executable process that are of no interest to the analyst. After the translation, the executable process is software, and therefore the non-technical BA is only allowed to see it in read-only mode.
The great advantage that BPM brings here is that analyst and developers are given a common language. The BPMN diagram helps to speed up the communication between BAs and developer. This indeed creates the 'agility' that is credited to BPM. But the illusion that BAs can just edit diagrams and press the 'Publish to production' button is optimistic and unrealistic
Portability at the modelling level is at least as important as portability on the implementation (executable processes) level i.e. portability of process logic from one platform to another is important but so is portability of people allowing us to move our skills from one process design tool to another. BPEL may be able to help with the first goal, but it's not appropriate for the second. When BPMN becomes widely supported it will make people's process design skills portable.
If process modelling is bound to executable processes, the graphical representation of the process should not contain too much information. Trying to express too much detail in the graphical diagram requires everyone to the details and means that there is less chance they will match with the executable language.
Process languages (executable and non executable) differ too significantly to unify them in graphical process designer based on BPMN. For each process language, a BPMN subset can be defined that matches well with that language. The designer tool should support the specific structures of the language and the appropriate finer details directly.
Round tripping
The mapping approach of BPMN has lead to the mistake of round tripping. The idea of round tripping is the continuous switching between the BPMN analysis model and the executable process. The BA works in a modelling language like BPMN, using the graphical notation and the BPMN properties and the developer works in an executable language like BPEL. The problem with this approach is that in practice, it turns out to be way too hard to maintain 2 sets of properties.
BPMN and BPEL mapping
BPMN is graph based, where as BPEL has a composite structure without transitions that corresponds to a tree. Secondly, the concurrency models differ substantially.
Process component models
The idea is that activities in a process graph are linked to a component that implements the runtime behaviour of that activity in a general purpose programming language. Each activity type in a process language corresponds to one implementation component. With this approach a common base layer is extracted from the BPM and workflow technologies.
Because they can support multiple process languages, process component models reduce the importance of the individual process languages. Instead, they let developers select the most appropriate executable process language for each process. This improves the separation of concerns between analysts and developers over a situation where a BPM engine only supports one process language.
In this perspective, we can identify 4 levels of detail, which perfectly fits with a smooth transition from analysis model to executable process model: 1. Process graph structurel; 2. Activity type selection (corresponds to the runtime implementation); 3. Configuration of the runtime implementation; 4. Plan B: Custom coding of an activity
Conclusion
BPEL is an executable process language, which is good for integration purposes, but it's not suited for supporting Business Process Management cause of its tight coupling with technical service invocations. BPMN serves the analysts in drawing analysis diagrams, but it's not executable.
We need to start by making a better distinction between analysis process models and executable process models. Once we abandon the idea that non-technical BAs can draw production-ready software in diagrams, we can come to a much more realistic and practical approach to business process management.
When linking an analysis process model with an executable process implementation, the clue is not to include too many of the sophisticated details of the analysis process notation in the diagram. By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the BA and the developers, based on one single diagram.
Different environments and different functional requirements require different executable process languages. The current idea that one process language would be able to cover all forms of BPM, workflow and orchestration is just too ambitious. And if such an effort would succeed, the resulting process language would be way too complex for practical usage.
New technologies create a component model so that activity types can be build on top of a common foundation.
This is a selective summary.
BPEL is not great for BPM modelling
BPEL's association with BPM is problematic from the viewpoint of the BPM modellers (i.e. based on good marketing). The only association is that a BPEL process can be shown as a diagram and that the language has support for wait states.
The BA is supposed to be non-technical, so the chance that the activities in the model correspond to available WS is small. BPEL is block structured, and this is too limited for modelling purposes. Analysts need the freedom to draw boxes and arrows, which always leads to graph structures and arbitrary cycles. A BPEL process doesn't have a notion of transitions. So usually, it's not possible to keep the analyst's analysis diagram in tact when translating into a BPEL executable process. This is exactly why the mapping BPMN to BPEL is hard and has so many limitations.
Another problem is the limited data manipulation capabilities. Extracting pieces of content from an XML document is most of what you need in service orchestration. But for BPM, often a lot of data processing needs to be done in between steps of the process.
If you consider using BPEL for BPM, ou should ask yourself is whether you want your core business process data in the ESB. The domain data that the BPEL engine needs to maintain is usually stored in relational databases. The information in your core business processes must be easily linked to the domain information in the relational databases. This information should be included in the domain model in a database. Not inside the BPEL engine. BPEL doesn't prevent that kind of information to be stored in the domain model database, but it makes it harder. You might have to implement a special web service to get the customer reference stored in the domain model. So BPEL seems to make it easy to get your domain model information partitioned.
BPEL is a good technology for scripting new services as a function of other services. But that it doesn't deliver on its promises for BPM, for which it is currently known. That doesn't mean that BPEL is bad - if you use it as an integration technology to build coarse-grained services out of smaller grained services.
BPMN for BPM modelling
As an analysis language to help with the documentation of a business process BPMN is a very good option. A BPMN diagram improves communication between analyst and developer, but the developer still remains responsible for all the technical details that are a part of the executable process.
A BA creates a description of the business process including a diagram. Then the translation needs to occur to the executable process language. The impact of that translation will depend on the analyst's technical skills and the capabilities of the executable process language. In any case, the goal is to have a minimal impact on the diagram so that the BA recognizes and understands the diagram of the executable process. Note that the diagram is only the tip of the iceberg, because a lot of technical details might be included in the executable process that are of no interest to the analyst. After the translation, the executable process is software, and therefore the non-technical BA is only allowed to see it in read-only mode.
The great advantage that BPM brings here is that analyst and developers are given a common language. The BPMN diagram helps to speed up the communication between BAs and developer. This indeed creates the 'agility' that is credited to BPM. But the illusion that BAs can just edit diagrams and press the 'Publish to production' button is optimistic and unrealistic
Portability at the modelling level is at least as important as portability on the implementation (executable processes) level i.e. portability of process logic from one platform to another is important but so is portability of people allowing us to move our skills from one process design tool to another. BPEL may be able to help with the first goal, but it's not appropriate for the second. When BPMN becomes widely supported it will make people's process design skills portable.
If process modelling is bound to executable processes, the graphical representation of the process should not contain too much information. Trying to express too much detail in the graphical diagram requires everyone to the details and means that there is less chance they will match with the executable language.
Process languages (executable and non executable) differ too significantly to unify them in graphical process designer based on BPMN. For each process language, a BPMN subset can be defined that matches well with that language. The designer tool should support the specific structures of the language and the appropriate finer details directly.
Round tripping
The mapping approach of BPMN has lead to the mistake of round tripping. The idea of round tripping is the continuous switching between the BPMN analysis model and the executable process. The BA works in a modelling language like BPMN, using the graphical notation and the BPMN properties and the developer works in an executable language like BPEL. The problem with this approach is that in practice, it turns out to be way too hard to maintain 2 sets of properties.
BPMN and BPEL mapping
BPMN is graph based, where as BPEL has a composite structure without transitions that corresponds to a tree. Secondly, the concurrency models differ substantially.
Process component models
The idea is that activities in a process graph are linked to a component that implements the runtime behaviour of that activity in a general purpose programming language. Each activity type in a process language corresponds to one implementation component. With this approach a common base layer is extracted from the BPM and workflow technologies.
Because they can support multiple process languages, process component models reduce the importance of the individual process languages. Instead, they let developers select the most appropriate executable process language for each process. This improves the separation of concerns between analysts and developers over a situation where a BPM engine only supports one process language.
In this perspective, we can identify 4 levels of detail, which perfectly fits with a smooth transition from analysis model to executable process model: 1. Process graph structurel; 2. Activity type selection (corresponds to the runtime implementation); 3. Configuration of the runtime implementation; 4. Plan B: Custom coding of an activity
Conclusion
BPEL is an executable process language, which is good for integration purposes, but it's not suited for supporting Business Process Management cause of its tight coupling with technical service invocations. BPMN serves the analysts in drawing analysis diagrams, but it's not executable.
We need to start by making a better distinction between analysis process models and executable process models. Once we abandon the idea that non-technical BAs can draw production-ready software in diagrams, we can come to a much more realistic and practical approach to business process management.
When linking an analysis process model with an executable process implementation, the clue is not to include too many of the sophisticated details of the analysis process notation in the diagram. By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the BA and the developers, based on one single diagram.
Different environments and different functional requirements require different executable process languages. The current idea that one process language would be able to cover all forms of BPM, workflow and orchestration is just too ambitious. And if such an effort would succeed, the resulting process language would be way too complex for practical usage.
New technologies create a component model so that activity types can be build on top of a common foundation.
