This article arguments that the gap between the analysis and the implementation of business processes is far bigger then the marketing of today's workflow tools might suggest. Also it will propose a much more realistic way of dealing with this situation. The current standards and initiatives will be explained with enough depth so that you can see how they relate to the movements and why. In the discussions, I'll identify the strengths and weaknesses of each discussed technology and describe the proper and improper ways of using them. At the end, a new type of workflow technology is introduced called process component model. This type of framework can handle multiple process languages and it can support process languages that better support the transition from analysis process diagrams to executable processes.
BPEL is an executable process language, which is good for integration purposes, but it's not suited for supporting Business Process Management because of its tight coupling with technical service invocations. BPMN serves the analysts in drawing analysis diagrams, but it's not executable. XPDL is a less adopted file format, which might be superseded by BPDM. The gap between analysis languages and executable languages still remains too big to be practical. In order to create a more realistic approach to BPM for widespread adoption, 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 business analysts 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 business analyst 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...
Read the complete article by Tom Baeyens, InfoQ.
