Article: Process Component Models: The Next Generation In Workflow?
Read Process Component Models: The Next Generation In Workflow?
Going into detail on separating the execution framework from the process framework, Tom explains:
A first observation is that multiple process languages can be implemented on top of the same activity component framework. Each process language is composed of a number of activity types. For each of those activity types, the runtime behaviour can be implemented in a general programming language like e.g. Java or C#. So an executable process language just becomes a set of activity type implementations. The most important part of such an activity component is the code that implements the runtime behaviour of the process constructs. But also the XML serialization, the designer forms to configure the process construct, persistence and many other aspects can potentially be included in a process construct component.The article has already been commented on by several other BPM framework providers including Sun's middleware & standards guru Mark Hapner.
Make a good choice
We choose Logic Base Studio from Transparent Logic (currently part of Altiris) wich is brilliant and effecient solution.
Design diagrams that are 'input-only' are declining in value ...
This makes the design-impl gap even a bigger problem because the cross functional teams tasked with delivering new BPs can't get off the ground. If they can't continuously communicate through iteratively evolving notation of what's being built they are likely going to fail. They have to be able to start with a basic working model that is jointly improved; that all can interrogate and experience as it evolves.
In this mode of development, diagrams with loose to non-existent semantics don't play an important role. On the other hand, diagrams that capture a facet of an evolving prototype are very useful. If the development environment can't spit these out then it just complicates the process of development via iteration.
Re: Design diagrams that are 'input-only' are declining in value ...
In 'Process development process', I agree with you that round tripping between an analysis model and a technical model is basically not solvable. That gap is indeed too big. Therefore, I stated that the translation from an analysis model into a executable (=design) process model is a one-way translation.
But I didn't want to imply that the connection with the analyst is broken at that point. On the contrary, the better the process language (BPEL scores pretty bad at this target), the better the design diagram will match the analysis diagram and then the analysts will still recognize it. Then the diagram serves as the common language between analysts and developers. But since the executable process artifact is now software, it should not be updated by the analyst in e.g. a graphical designer tool at that stage. The input should be collected by the developers in meetings and they should apply the changes to the executable process.
In my presentation for JBossWorld next week in Orlando, I have put a picture to illustrate that reasoning.
While this is the only way that the pure play BPM vendors approach the problem, this is not the only one way of making valid use of BPM technology. By far, most BPM is done by documenting the business processes (with Visio, IDS Scheer's ARIS or a BPMN modelling tool) and then *never* make the processes executable on a BPMS. It's only a small fraction of BPM use cases that try to make the bridge between analysis and design models.
On the other hand, there is the technical approach. Where developers model the processes. In that case there is no analysis model. Only design process models.
Re: Design diagrams that are 'input-only' are declining in value ...
Process Component Model
Miguel Valdes Faura
BTW, I would like to highlight that The Process Virtual Machine technology is the result of collaboration between Jboss and Bull and so you must consider Bull workflow and BPM open source products as a major player in this domain next years. Indeed we are on the road of providing a new version of our open source solutions based on this technology: Bonita (The XPDL open source project) and Orchestra (The BPEL open source solution).
That said, I will also take the chance to disagree with some of the Tom’s arguments pointed out in the article. I have posted a dedicated item on this subject at BPM Corner community .
The BPEL open source project: orchestra.objectweb.org
The XPDL open source project: bonita.objectweb.org
Good one Tom...
- interacting with the domain model in an efficient manner (crafting lean payload exchanges).
- building service interfaces that deliver more value than being simple decorators to data back-ends.
- allocating time to translate their Process expressions to Process composites.
There just isn't enough discipline and time spent on those aspects. And the result is a multitude of implementations that give BPM/Workflow/Orchestration approaches a bad name.
A reasonable resolution at this point would be to stop pretending like the 'round-trip process engineering' technologies are delivering on their promises and focus on honing three technology areas to make it closer to reality:
1. Process Expression. Let's not get hung up on mapping models to BPEL. It's an impedance mismatch we'll just have to deal with. There are plenty of process expression suites that Business Analysts like to use. Let them work with what they are comfortable with.
2. Process Composition. There is opportunity here to allow a 'Technical Analyst' to begin the process of 'distilling' these expressions into re-usable blocks that properly delineate responsibility between processes, services, domain data & humans. A DSL for expressing process compositions is sorely missed (we have a rudimentary version of our own). Let's focus on expression first. Exchange later.
3. Process Implementation. Once you know the actual scope of the process vs. what the business analyst thought it would do - you can go ahead and define it in BPEL or use a simpler language abstraction like SimPEL (work in progress) for it.
I like to call the resulting solution for the customer an 'Intelligent Composite'. It works. We have happy customers to prove it :).
"Business Acceleration through Process Automation."
What does Route Planning has to do with Business Process Management?
Freddie van Rijswijk
I liked your artice a lot and agree with the fact that BPEL (and the tools for it) is not suited for BPM. I would go even one step further and challenge the fact that a real business process is far more complex and event-driven and influenced by users and context that it's to my opinion NOT possible at all to model all possible variations to execute it. I guess we need an other mechanism (pattern matching, adaptive self learning systems, event driven) to be able to provide the business with goal driven automated processes.
I have wrote a short blog-item on it in analogy with a route planner.
Formalized DSL definition
Johan den Haan
I totally agree with the idea of a component activity framework. I think the idea behind can be used in general for defining domain specific languages.
I've worked it out with some scientific foundation in my blogpost: Combining general purpose and domain specific languages for Model-Driven Engineering
Common misperception about BPEL's block-structured nature
"A BPEL process doesn't have a notion of transitions."
Within a <flow> environment you can use <link>s to define the ordering of activities in BPEL. You can have links without transition condition or links with a transition condition which correspond to a BPMN sequence flow or conditional sequence flow respectively. So, in general, BPEL allows you to "to draw boxes and arrows" (arbitrary cycles are not supported).
You are a victim of the commom misperception that BPEL is block-structured. Of course BPEL provides for complex activities like <sequence> and <if>, which allow you defining a block-based process, but BPEL supports also graph-based modelling.
I know it's convenient to learn by reading other peoples articles/papers, but sometimes you guys should really consider taking a look to the specs...
I skipped the rest of your article I but was interested in your conclusion:
"BPEL is an executable process language, which [...] is not suited for supporting Business Process Management"
Then you say:
"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."
Well, why not taking the intersection of BPMN and BPEL, which is BPMN plus DPE (Dead Path Elemination) minus arbitrary cycles, or simply BPEL (maybe minus WSDL)? :-)
Business Process Analysis Language
in this good article will change,
- it can be refined to be natively executable,
BPEL is build in
- it has a defined metamodel and own exchange format,
XPDL is no more needed.
- it fills the gap between business and IT using a
single model and common language, but of course business
only needs a subset