Process Component Models: The Next Generation in Workflow?

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 cause 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...