We've been talking about it for a long time. And we've been working on it for even much longer. And finally, the moment of truth is here. The first alpha release of the Process Virtual Machine can be downloaded. Documentation and Javadocs are also available.
The Process Virtual Machine now also got it's own home page.
This marks an important milestone for the jBPM project. It's the finalization of our approach to support multiple process languages and embeddable BPM.
But don't wait any longer. Go download it and start building your first processes and process activities.
Wednesday, 19 March 2008
Complete Refresh Of The jBPM Website
JBoss jBPM has a renewed website. A serious update was long time overdue. We took the time to put the soul of the project into the website. Multiple subprojects now are very prominent, highlighting the fact that jBPM supports multiple process languages. An overview section helps people to understand workflow, BPM and how we approach it.
This new site is part of a larger effort to focus more on building the community further out. Previously we already announced the new logo. We now have about 20000 downloads per month, but we won't rest until BPM and workflow is a ubiquitous part of software development.
Special thanks goes to Koen for making it happen.
This new site is part of a larger effort to focus more on building the community further out. Previously we already announced the new logo. We now have about 20000 downloads per month, but we won't rest until BPM and workflow is a ubiquitous part of software development.
Special thanks goes to Koen for making it happen.
Friday, 14 March 2008
My Concluding Nuance On BPMN
Before I try to summarize my position, I'll reference all the related blogs in this discussion:
Michael zur Muehlen: How much BPMN do you need?
Bruce Silver: On How Much BPMN Do You Need
Michael zur Muehlen: Who is at fault - the language or the speaker?
Bruce Silver: Michael Elaborates
Me: The Hottest BPMN Process Modelling Debate, BPMN Conformance Sets And Unrealistic Ambitions and The Devil Is In The Technical Details
And overviews from InfoQ and Sandy Kemsley.
After the above and another good discussion at the Dolmen event: Do’s en don’ts van Business Process Management yesterday, I would like to give another shot at summarizing my point of view around BPMN and indicate where I see most misunderstandings around analysis to implementation.
BPMN can be used for analysis. In that sense, the BPMN analysis model is a model or a description of the real world. BPMN can also be used to represent executable process languages. But in that case the BPMN diagram represents a piece of software.
So my point is that, in general, it is impossible for an analysis model to automagically be translated into an implementation model. Even while for both models BPMN can be used, at some point, the purpose of the model changes. I believe that the purpose-change from analysis to implementation can not and should not happen automatically or transparantly.
In some cases, the BPMN model representing the executable process could very well be exactly the same as the original analysis diagram. In fact, the better the executable process language, the closer the implementation diagram will be to the original analysis diagram. William Vampenepe's post already shows that BPMN to BPEL doesn't really succeed in that goal.
BPMN to XPDL would be much closer, but XPDL doesn't really aim to be an executable process language.
Michael zur Muehlen: How much BPMN do you need?
Bruce Silver: On How Much BPMN Do You Need
Michael zur Muehlen: Who is at fault - the language or the speaker?
Bruce Silver: Michael Elaborates
Me: The Hottest BPMN Process Modelling Debate, BPMN Conformance Sets And Unrealistic Ambitions and The Devil Is In The Technical Details
And overviews from InfoQ and Sandy Kemsley.
After the above and another good discussion at the Dolmen event: Do’s en don’ts van Business Process Management yesterday, I would like to give another shot at summarizing my point of view around BPMN and indicate where I see most misunderstandings around analysis to implementation.
BPMN can be used for analysis. In that sense, the BPMN analysis model is a model or a description of the real world. BPMN can also be used to represent executable process languages. But in that case the BPMN diagram represents a piece of software.
So my point is that, in general, it is impossible for an analysis model to automagically be translated into an implementation model. Even while for both models BPMN can be used, at some point, the purpose of the model changes. I believe that the purpose-change from analysis to implementation can not and should not happen automatically or transparantly.
In some cases, the BPMN model representing the executable process could very well be exactly the same as the original analysis diagram. In fact, the better the executable process language, the closer the implementation diagram will be to the original analysis diagram. William Vampenepe's post already shows that BPMN to BPEL doesn't really succeed in that goal.
BPMN to XPDL would be much closer, but XPDL doesn't really aim to be an executable process language.
Thursday, 13 March 2008
BPMN to BPEL: Lipstick On A Pig?
Yesterday I came across William Vambenepe's blog post: BPMN to BPEL: going to battle with one hand tied? It shows that if you translate a simple BPMN model to BPEL, the BPEL process is not really recognizable any more. It seems to reconfirm my initial estimations about that kind of transformation.
I'm happy with the rapid adoption of BPMN in the BPM world. But I was always puzzled by the big focus of the BPMN to BPEL conversion. I have not done the excercise myself of trying to write an algorithm that did such a transformation because the models just don't seem to fit. BPEL is a composite (aka block) structured language. BPMN is graph based. BPMN is focussed on process analysis, while BPEL is about orchestrating web services. And in my experience, the non tech business analysts don't think in terms of web services.
I'm happy with the rapid adoption of BPMN in the BPM world. But I was always puzzled by the big focus of the BPMN to BPEL conversion. I have not done the excercise myself of trying to write an algorithm that did such a transformation because the models just don't seem to fit. BPEL is a composite (aka block) structured language. BPMN is graph based. BPMN is focussed on process analysis, while BPEL is about orchestrating web services. And in my experience, the non tech business analysts don't think in terms of web services.
The Devil Is In The Technical Details
My reply to Bruce's comment got out of hand so I decided to publish it as a separate post.
For the sake of the discussion, let's zoom in on the part where we see different things :-) I understand your point of view as focussed on the modelling side. Then you see some vendors that can take a BPMN model, add details (be it visible in the diagram or just properties) and then this model becomes executable:
First, this implies that at least some visual model constructs that can be used during analysis have a runtime meaning. There are different kind of analysts. Some have a tech background and they know that this process is going to be executed on a computer system. Some don't. Analysing a business process, means trying to understand the business problem and describing that. The analyst might use all the BPMN constructs for that not knowing what that these have a runtime meaning on a computer system. An executable model is software that is to be run on one system. I think that in general, there always needs to be a human translation from the analysis model to the executable model, even if both the analysis model and the executable model can be expressed in BPMN.
With jPDL, we have focussed on modelling freedom, which means that the executable process diagram should look exactly like the analyst diagram. And that was not trivial. Important concepts are listeners (aka actions) so that a developer can associate callbacks on specific points in the process. Another concept is that the runtime behaviour for nodes doesn't have to come from a fixed set of process constructs. Instead, if the analyst has a really weird requirement in a specific node (aka activity), then the developer can code the runtime behaviour for that node in a plain programming language like java and hook it up in the process.
I think that an executable process language needs those kinds of features and a lot more to really keep the same diagram. I think it is often overlooked that analysis and implementation are two different things.
So the simple waterfall model of adding implementation details to an analysis model doesn't cut it for me.
The second part where the pure plays will keep having a problem with the development teams is embeddability. Instead of having a separate monolithic BPMS that has to be connected to applications, I have seen that the developer community likes it much more when the BPMS logic can be embedded into their own applications. And the BPMS database can be a set of tables right next to the application tables. That is what the operators like: Since the BPMS is part of the application, it reduces the number of systems that need to be managed and hence simplifies IT operations.
To support embeddability, BPMS vendors like us need to support all the DB's out there. Next, the application domain model needs to be coupled seamlessly with the process executions. E.g. the Order hibernate entity (or ejb), needs to be linked bidirectionally with the Order process. That is something that we can offer on a API level basis to developers.
I didn't yet see another executable process language then jPDL that can offer that level of convenience to the developers. IMO, it is not possible to get this level of convenience for developers if you start from the analysis model. Somewhere you have to turn requirements into a software design.
Without this translation idea, in all other executable BPMS systems I have seen so far, executable details ripple through in the tools offered to the analyst. And in the niche markets where those vendors are active now, a lot of analysts have some technical background. But if we want to make BPM and workflow a ubiquitous technology that is in the repertoire of every IT team, we have offer it in a way that is easily consumable for IT teams.
One last parting thought, inspired by the vendors that you reference. What do these vendors have different then what Ultimus had 5 years ago ? That was the first vendor I looked at when I started. At that time, they already had a very complete product. How come they (and so many others in that field at that time) were not able to gain any significant market share. Instead it seems like BPM vendors come and go all the time. None of those is able to get beyond a certain treshold of adoption. I think this has to do with the fact that BPMS tools sell easy to CXO's, but it is very hard to make a BPMS that is attractive to developers. IMO, it's the IT team that should select a BPMS, not management.
Thanks Bruce, with this awsome discussion, it certainly got out the best in me :-)
For the sake of the discussion, let's zoom in on the part where we see different things :-) I understand your point of view as focussed on the modelling side. Then you see some vendors that can take a BPMN model, add details (be it visible in the diagram or just properties) and then this model becomes executable:
"I doubt the general feasibility of this approach.
BPMN is just the model, the activity flow in abstract sense. The implementation properties of each activity, event, or gateway are layered on by developers. Not in code, but using the visual tools even those guys like to use. And not stored in BPMN attributes, but in the tool-specific metadata that drives the executable language.
"
First, this implies that at least some visual model constructs that can be used during analysis have a runtime meaning. There are different kind of analysts. Some have a tech background and they know that this process is going to be executed on a computer system. Some don't. Analysing a business process, means trying to understand the business problem and describing that. The analyst might use all the BPMN constructs for that not knowing what that these have a runtime meaning on a computer system. An executable model is software that is to be run on one system. I think that in general, there always needs to be a human translation from the analysis model to the executable model, even if both the analysis model and the executable model can be expressed in BPMN.
With jPDL, we have focussed on modelling freedom, which means that the executable process diagram should look exactly like the analyst diagram. And that was not trivial. Important concepts are listeners (aka actions) so that a developer can associate callbacks on specific points in the process. Another concept is that the runtime behaviour for nodes doesn't have to come from a fixed set of process constructs. Instead, if the analyst has a really weird requirement in a specific node (aka activity), then the developer can code the runtime behaviour for that node in a plain programming language like java and hook it up in the process.
I think that an executable process language needs those kinds of features and a lot more to really keep the same diagram. I think it is often overlooked that analysis and implementation are two different things.
So the simple waterfall model of adding implementation details to an analysis model doesn't cut it for me.
The second part where the pure plays will keep having a problem with the development teams is embeddability. Instead of having a separate monolithic BPMS that has to be connected to applications, I have seen that the developer community likes it much more when the BPMS logic can be embedded into their own applications. And the BPMS database can be a set of tables right next to the application tables. That is what the operators like: Since the BPMS is part of the application, it reduces the number of systems that need to be managed and hence simplifies IT operations.
To support embeddability, BPMS vendors like us need to support all the DB's out there. Next, the application domain model needs to be coupled seamlessly with the process executions. E.g. the Order hibernate entity (or ejb), needs to be linked bidirectionally with the Order process. That is something that we can offer on a API level basis to developers.
I didn't yet see another executable process language then jPDL that can offer that level of convenience to the developers. IMO, it is not possible to get this level of convenience for developers if you start from the analysis model. Somewhere you have to turn requirements into a software design.
Without this translation idea, in all other executable BPMS systems I have seen so far, executable details ripple through in the tools offered to the analyst. And in the niche markets where those vendors are active now, a lot of analysts have some technical background. But if we want to make BPM and workflow a ubiquitous technology that is in the repertoire of every IT team, we have offer it in a way that is easily consumable for IT teams.
One last parting thought, inspired by the vendors that you reference. What do these vendors have different then what Ultimus had 5 years ago ? That was the first vendor I looked at when I started. At that time, they already had a very complete product. How come they (and so many others in that field at that time) were not able to gain any significant market share. Instead it seems like BPM vendors come and go all the time. None of those is able to get beyond a certain treshold of adoption. I think this has to do with the fact that BPMS tools sell easy to CXO's, but it is very hard to make a BPMS that is attractive to developers. IMO, it's the IT team that should select a BPMS, not management.
Thanks Bruce, with this awsome discussion, it certainly got out the best in me :-)
Wednesday, 12 March 2008
BPMN Conformance Sets And Unrealistic Ambitions
In the recent BPMN discussion, Bruce clarifies that he also sees a partitioning in BPMN:
So now, my only disagreement is not with Bruce, but with the picture that the traditional BPMS vendors paint. He describes it like this:
Instead, I think it is much more realistic that the analyst delivers an initial analysis model. This model can be in 'the COMPLETE conformance set' as described by Bruce or it can be boxes and arrows on a napkin. Then this serves as the requirements input for the development team. The executable process language should be a selection of the development team. They can select a language that fits their architecture and the environment of the process best.
The clue is that a good executable process language would allow the developers to build a process that exactly looks like the analysts input. That way, the implementation model is structured in the same way as the analysis model. As a result, analyst and developer can speak the same language.
But crucial is that after the translation of an analysis model into an executable process, the responsibility is transferred to the development team. In subsequent iterations, the communication between analysts and developers can happen around the diagram, but it's the developers that should do the updates to the executable process.
With general purpose executable process languages, it's not possible to let the non technical business analyst modify executable software. The exception is in the specific process languages with a specific target and limited scope. For example a language to specify approvals in a document management system. In those cases, the analysts can build fully executable processes.
The round tripping approach that traditional BPMS vendors put forward tries to automate the translation of requirements into software design. That is, IMO, an unrealistic ambition.
"This is very close to (and much more concrete then) the levels that I envisioned. That puts our opinions indeed much closer as I initially estimated. Especially if you only look at the modelling perspective, then I totally agree with you, Bruce.
The SIMPLE conformance set includes task, collapsed subprocess, gateway (exclusive data-based and parallel), None start and end events, pool, lane, data object, text annotation, sequence flow, and association.
The STANDARD conformance set includes task (task type User, Service, Send, Receive); collapsed and expanded subprocess, looping or multi-instance activity, gateway (inclusive, exclusive data-based, exclusive event-based, parallel), start events (None, message, timer), catching intermediate events in sequence flow (timer, message), throwing intermediate events in sequence flow (message), attached intermediate events (timer, message, error), end events (None, error, message, terminate), pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association. [Looks like we left out message flow… not sure why.]
The COMPLETE conformance set includes the full BPMN 1.1 spec.
"
So now, my only disagreement is not with Bruce, but with the picture that the traditional BPMS vendors paint. He describes it like this:
"IMO, the BPMN model-driven implementation as pursued by most vendors is flawed. They see the executable language as the byte-code behind the BPMN model. Then round tripping is envisioned between the model and the "byte-code". I believe that it is impossible to let the non technical people drive the executable byte code.
And, like Michael, the tool vendors factor into my thinking as well, in particular the BPMS vendors who support BPMN’s model-driven implementation style.
"
Instead, I think it is much more realistic that the analyst delivers an initial analysis model. This model can be in 'the COMPLETE conformance set' as described by Bruce or it can be boxes and arrows on a napkin. Then this serves as the requirements input for the development team. The executable process language should be a selection of the development team. They can select a language that fits their architecture and the environment of the process best.
The clue is that a good executable process language would allow the developers to build a process that exactly looks like the analysts input. That way, the implementation model is structured in the same way as the analysis model. As a result, analyst and developer can speak the same language.
But crucial is that after the translation of an analysis model into an executable process, the responsibility is transferred to the development team. In subsequent iterations, the communication between analysts and developers can happen around the diagram, but it's the developers that should do the updates to the executable process.
With general purpose executable process languages, it's not possible to let the non technical business analyst modify executable software. The exception is in the specific process languages with a specific target and limited scope. For example a language to specify approvals in a document management system. In those cases, the analysts can build fully executable processes.
The round tripping approach that traditional BPMS vendors put forward tries to automate the translation of requirements into software design. That is, IMO, an unrealistic ambition.
Tuesday, 11 March 2008
The Hottest BPMN Process Modelling Debate
Just in case you didn't notice, a very important blog discussion is happening right now around BPMN. Bruce Silver is discussing with Michael Zur Muehlen about how BPMN is used, how it should be used and how it should be improved.
Michael: "How much BPMN do you need?"
Bruce: "On how much BPMN do you need"
Michael: "Who is at fault, the language or the speaker?"
Bruce: "Michael elaborates"
Bruce Silver is a BPM guru consultant. He advocates and teaches BPMN as a rigorous modelling notation. In his view process modellers need a very precise and expressive language so that a lot of details can be precisely documented in the shapes and decorations of a process diagram.
Michael Zur Muehlen is a BPM open academic with a practical touch. His point is that a better layering of the BPMN complexity is needed and that for most organisations, the more basic parts of BPMN are sufficient.
I very much appreciate both gentlemen. BPM minds like that are few and far between. In this case, I tend to agree with Michael. Michaels position reflects what I experience as well in the field. Depending on the culture in an organisation, only in very few occasions, modelling notations are used as mathematical science, in which case a lot of expressiveness is desirable and a lot of exact interpretation of the diagram is needed. In most cases, process diagrams are just drawings of boxes and arrows. We should not forget that multiple reports have indicated that Visio is by far the most used tool to draw business processes. If we assume that a majority doesn't use the BPMN Visio stencils, it means that many organisations now work without these precise modelling notations.
First, I think BPMN would benefit from a better layering. BPMN should introduce e.g. 3 levels. So that in a tool, you can choose whether you want to work in BPMN on level 1 (basics), level 2 (advanced) or level 3 (Bruce :-) ). Michael refers to the constructs already being divided into categories. If that is the case, it is certainly not prominent enough and a categorisation of the constructs is not enough. It should be verified that each level is a self contained language that is complete enough to satisfy a well defined set of modelling purposes.
Second, too formal is not good as it will get into execution semantics. That's why i indicated that maybe a third level will already be too detailed for a modelling notation.
Third BPMN should stick to being a modelling notation. That's what it is being adopted for. The properties can be removed and the mapping approach to concrete executable process languages should be left up to the vendors.
But when these discussions are settled, still the question is left open of how to translate these process analysis models into executable processes that can be executed on a BPMS. We as BPMS vendors tend to see this as the only possible use case of process modelling. But in fact, a bit more modesty is probably appropriate. We should realise that most business process models are not intended to become executable. But anyway, *if* a process analysis model is to be made executable, I think there has to be a translation to an executable process language. And such a translation should make sure that the analyst still recognizes the diagram of the executable process. That guarantees good communication between analyst and developer. After a process has become executable, it is software and it becomes the responsibility of the developer. Therefore, I don't really believe in the analysis to executable process round tripping. Instead, I think that that it is much more practical to have a one-way translation to an executable process and then iterative updates under control of the developer, but with good input from the analyst on the diagram level.
Anyways, all this side tracks to indicate that we at jBPM still have got couple of challenges left to tackle. Because our goal is actually to bring the usage and knowledge of BPM and workflow technology to become ubiquitous amongst IT teams. I know this has been envisioned before, I know this is ambitious, but I still think we're actually close to getting there.
For a long time now, we've been preaching about multiple process languages. Only recently I start to encounter left and right messages like 'multiple forms of workflow' and 'BPEL is not a silver bullet'. That is a done deal. We are finalizing the Process Virtual Machine that actually runs multiple process languages (like jPDL, BPEL and XPDL) natively. The other point is that embeddability is still underestimated. BPM products are still too much silo's that are hard to integrate into day to day application development. That is where we will be ready soon.
I'll be looking forward to the rest of that conversation.
Michael: "How much BPMN do you need?"
Bruce: "On how much BPMN do you need"
Michael: "Who is at fault, the language or the speaker?"
Bruce: "Michael elaborates"
Bruce Silver is a BPM guru consultant. He advocates and teaches BPMN as a rigorous modelling notation. In his view process modellers need a very precise and expressive language so that a lot of details can be precisely documented in the shapes and decorations of a process diagram.
Michael Zur Muehlen is a BPM open academic with a practical touch. His point is that a better layering of the BPMN complexity is needed and that for most organisations, the more basic parts of BPMN are sufficient.
I very much appreciate both gentlemen. BPM minds like that are few and far between. In this case, I tend to agree with Michael. Michaels position reflects what I experience as well in the field. Depending on the culture in an organisation, only in very few occasions, modelling notations are used as mathematical science, in which case a lot of expressiveness is desirable and a lot of exact interpretation of the diagram is needed. In most cases, process diagrams are just drawings of boxes and arrows. We should not forget that multiple reports have indicated that Visio is by far the most used tool to draw business processes. If we assume that a majority doesn't use the BPMN Visio stencils, it means that many organisations now work without these precise modelling notations.
First, I think BPMN would benefit from a better layering. BPMN should introduce e.g. 3 levels. So that in a tool, you can choose whether you want to work in BPMN on level 1 (basics), level 2 (advanced) or level 3 (Bruce :-) ). Michael refers to the constructs already being divided into categories. If that is the case, it is certainly not prominent enough and a categorisation of the constructs is not enough. It should be verified that each level is a self contained language that is complete enough to satisfy a well defined set of modelling purposes.
Second, too formal is not good as it will get into execution semantics. That's why i indicated that maybe a third level will already be too detailed for a modelling notation.
Third BPMN should stick to being a modelling notation. That's what it is being adopted for. The properties can be removed and the mapping approach to concrete executable process languages should be left up to the vendors.
But when these discussions are settled, still the question is left open of how to translate these process analysis models into executable processes that can be executed on a BPMS. We as BPMS vendors tend to see this as the only possible use case of process modelling. But in fact, a bit more modesty is probably appropriate. We should realise that most business process models are not intended to become executable. But anyway, *if* a process analysis model is to be made executable, I think there has to be a translation to an executable process language. And such a translation should make sure that the analyst still recognizes the diagram of the executable process. That guarantees good communication between analyst and developer. After a process has become executable, it is software and it becomes the responsibility of the developer. Therefore, I don't really believe in the analysis to executable process round tripping. Instead, I think that that it is much more practical to have a one-way translation to an executable process and then iterative updates under control of the developer, but with good input from the analyst on the diagram level.
Anyways, all this side tracks to indicate that we at jBPM still have got couple of challenges left to tackle. Because our goal is actually to bring the usage and knowledge of BPM and workflow technology to become ubiquitous amongst IT teams. I know this has been envisioned before, I know this is ambitious, but I still think we're actually close to getting there.
For a long time now, we've been preaching about multiple process languages. Only recently I start to encounter left and right messages like 'multiple forms of workflow' and 'BPEL is not a silver bullet'. That is a done deal. We are finalizing the Process Virtual Machine that actually runs multiple process languages (like jPDL, BPEL and XPDL) natively. The other point is that embeddability is still underestimated. BPM products are still too much silo's that are hard to integrate into day to day application development. That is where we will be ready soon.
I'll be looking forward to the rest of that conversation.
Subscribe to:
Posts (Atom)