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.
Thursday, 13 March 2008
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.
Monday, 25 February 2008
The New jBPM Logo Rocks !
Back in the days I had spent a full two hours with MS Paint to create the first logo for jBPM. When it was done I was so happy with the result.
I remember it was just before JavaPolis 2004. Now that my project even had a logo, I was in full confidence. You know the feeling... Nothing could stop me now. So I went to the conference and immediately I got a lot of valuable feedback. All in the sense of "Hey Tom, you're project is great but your logo sucks bigtime!".
(Please put a curtain over your screen now and read on)
So this time I sticked to coding and left the paint job to the professionals. Even with my artistic skills I can see it's a world of difference. I think our new logo just rocks. But don't let me keep you in tension too long. Tataaaaa ! (you should pull the curtain from your screen now)
A small logo for this blog. But a giant leap for the jBPM project.
Can you see what it is ?
I remember it was just before JavaPolis 2004. Now that my project even had a logo, I was in full confidence. You know the feeling... Nothing could stop me now. So I went to the conference and immediately I got a lot of valuable feedback. All in the sense of "Hey Tom, you're project is great but your logo sucks bigtime!".(Please put a curtain over your screen now and read on)
So this time I sticked to coding and left the paint job to the professionals. Even with my artistic skills I can see it's a world of difference. I think our new logo just rocks. But don't let me keep you in tension too long. Tataaaaa ! (you should pull the curtain from your screen now)
A small logo for this blog. But a giant leap for the jBPM project.Can you see what it is ?
jBPM @ JBUG Benelux
This Friday, I'll talk about the Process Virtual Machine at the next JBUG Benelux meeting. These JBUG events are especially interesting since there is always a great interaction and lots of discussion that spawns from (and during!) the presentations. I'm looking forward to it.
Pete Muir will kick off with a 'SEAM In Action' talk. I saw Pete's presentation two weeks ago at JBossWorld Orlando and it was great. Pete is an excellent speaker and he's got some great handwaiving manouvres. Then I'll be talking about the Process Virtual Machine. And the last but not least, Bart Schuller and Daan Hoogenboezem will bring a testimonial about their experiences using jBPM. It's always great to get such direct feedback. Hopefully there is some positive in there as well :-)
For those of you more interested in the packaging rather then that content, the event will be hosted in Paddy Murphy's, an "vette" Irish pub in Rotterdam. Lunatech does the hosting of the event and we will take care of the Guinness.
I'm sure you don't want to miss this. Hope to see you there !
Pete Muir will kick off with a 'SEAM In Action' talk. I saw Pete's presentation two weeks ago at JBossWorld Orlando and it was great. Pete is an excellent speaker and he's got some great handwaiving manouvres. Then I'll be talking about the Process Virtual Machine. And the last but not least, Bart Schuller and Daan Hoogenboezem will bring a testimonial about their experiences using jBPM. It's always great to get such direct feedback. Hopefully there is some positive in there as well :-)
For those of you more interested in the packaging rather then that content, the event will be hosted in Paddy Murphy's, an "vette" Irish pub in Rotterdam. Lunatech does the hosting of the event and we will take care of the Guinness.
I'm sure you don't want to miss this. Hope to see you there !
Sunday, 24 February 2008
jBPM @ FOSDEM
I'll be speaking about "Workflow in Java" this afternoon from 15:00 till 16:00 in room AW1.120. Due to misunderstandings, this talk didn't make it into the conference guide. So this blog post is an attempt to avoid an empty room :-) Hope to see you there.
Tuesday, 19 February 2008
JBossWorld Recap
JBossWorld was last week in Orlando, FL. Of course, we took the opportunity to meet up in advance with the core JBoss developers. It still surprises me each time how the communication at such meetings can be intense, distributed, apparently anarchistic and yet extremely effective ...often even at 1am at the bar.
My presentation "A Lightweight Approach to Business Processes with JBoss jBPM" was in the very first slot. I always like that very much as jet lag and parties tend to undermine my concentration as the week progresses.
Met up with my good friends at SeeWhy. They might be able to contribute an initial version of the log/event generation in the Process Virtual Machine. The open source collaboration model in practice. Cool.
Same open source spirit for NexusBPM. Matthew Sandoz has already extended jPDL with new node types in the engine and in the graphical designer. Good to see that a long term vision becomes reality. We're happy that Matthew is interested to donate his contributions to the jBPM community and we will be assisting him in the process of doing so.
By coincidence, IDS Scheer's ProcessWorld conference was also taking place at the exact same location at the exact same time. I saw Sandy Kemsley blogging about it and pinged her to have a meeting. We definitely agreed that translating analysis models into executable software artifacts is not as easy as most BPMS vendors make us believe. For many other observations of the BPM market we thought very similar, which is surprising given our different background. Only when it came down to roundtripping between the analysis model and the implementation models of business processes, I seriously doubted if that was achievable, while Sandy had good faith that the big BPM players some day will find a way to make that transparant.
Another interesting meeting was with our new CEO, Jim Whitehurst. Everyone was enthousiast about the fact that he managed to analyse and express exactly where the problems are located in such a short period. Now our expectations him to get them fixed are very high :-)
A last anecdote that I would like to share is my jogging experience around the Marriott World Center. It turned out to be extremely difficult to find a track for jogging. Even the driveway to the hotel was a 4 lane street without cycle or pedestrian facilities. Eventually I saw a golf court behind a small pond and grass. There was a sign before the pond. I assumed it was going to be "Don't walk on the grass" and given my struggles so far, I was completely prepared to ignore it. But the sign didn't say anything like that. Instead it had a much more effective message: "Don't feed the alligators!". It worked for me :-)
My presentation "A Lightweight Approach to Business Processes with JBoss jBPM" was in the very first slot. I always like that very much as jet lag and parties tend to undermine my concentration as the week progresses.
Met up with my good friends at SeeWhy. They might be able to contribute an initial version of the log/event generation in the Process Virtual Machine. The open source collaboration model in practice. Cool.
Same open source spirit for NexusBPM. Matthew Sandoz has already extended jPDL with new node types in the engine and in the graphical designer. Good to see that a long term vision becomes reality. We're happy that Matthew is interested to donate his contributions to the jBPM community and we will be assisting him in the process of doing so.
By coincidence, IDS Scheer's ProcessWorld conference was also taking place at the exact same location at the exact same time. I saw Sandy Kemsley blogging about it and pinged her to have a meeting. We definitely agreed that translating analysis models into executable software artifacts is not as easy as most BPMS vendors make us believe. For many other observations of the BPM market we thought very similar, which is surprising given our different background. Only when it came down to roundtripping between the analysis model and the implementation models of business processes, I seriously doubted if that was achievable, while Sandy had good faith that the big BPM players some day will find a way to make that transparant.
Another interesting meeting was with our new CEO, Jim Whitehurst. Everyone was enthousiast about the fact that he managed to analyse and express exactly where the problems are located in such a short period. Now our expectations him to get them fixed are very high :-)
A last anecdote that I would like to share is my jogging experience around the Marriott World Center. It turned out to be extremely difficult to find a track for jogging. Even the driveway to the hotel was a 4 lane street without cycle or pedestrian facilities. Eventually I saw a golf court behind a small pond and grass. There was a sign before the pond. I assumed it was going to be "Don't walk on the grass" and given my struggles so far, I was completely prepared to ignore it. But the sign didn't say anything like that. Instead it had a much more effective message: "Don't feed the alligators!". It worked for me :-)
Monday, 18 February 2008
SOA Done The Hard Way
You don't see many public cridible reports about results of SOA projects. So that's why Chris Muir 's testimonial is interesting.
The overall message in Chris' post is that there are a lot of practical problems between the dream and reality of SOA development.
It expresses very well how Oracle's Fusion doesn't really address most of the practical issues. In fact, they are very hard (if at all) to address. That's why I'm happy with JBoss' practical developer oriented approach that gives full control to developers. With the tool suite that we're building, we focus not to introduce unnecessary levels of complex indirections.
The overall message in Chris' post is that there are a lot of practical problems between the dream and reality of SOA development.
"Just because the underlying Web Service communications allow you to communicate in a standard fashion, it doesn't mean the systems or organisations you communicate to are following any standards internally."Top of the bill was:
"In addition only 1 of the 3 suppliers actually had test systems we could build our application against. And for the supplier that did have a test system we literally had to phone them to ask them to flush the data each time we did a test. So much for quick agile development."But the post contains much more in depth insight about the practical things that can go wrong in SOA projects. Definitely worth a read.
It expresses very well how Oracle's Fusion doesn't really address most of the practical issues. In fact, they are very hard (if at all) to address. That's why I'm happy with JBoss' practical developer oriented approach that gives full control to developers. With the tool suite that we're building, we focus not to introduce unnecessary levels of complex indirections.
Wednesday, 6 February 2008
What is BPEL really ? And what are process component models ?
I included a very simple description of what BPEL really is in my article "Process Component Models: The Next Generation In Workflow ?", published at InfoQ. Basically the article is about different forms of workflow and Business Process Management (BPM) and it tries to demystify some of the common misconceptions around BPM. And at the end, a new approach to building embeddable runtime engines is introduced: Process component models. With process component models, it's possible to serve the different forms of workflow and BPM by executing multiple process languages natively on top of one core simple state machine library.
Tuesday, 29 January 2008
What Possesses These Open Source Developers ?
Joe Walker desrcibes it in a very realistic way for me:
"
The funny thing about getting heavily involved in an open source project is the roller coaster ride you embark on. There's the buzz from seeing the hits to the web server and reading what people think of your project. There's the gnawing feeling of responsibility when you discover very large websites using your code, and you're worried about bugs you might have created. There's the total flat feeling when a friend tells you they're taking your code out of a project because they prefer an alternative; and there's the burnout when you just can't keep up with the volume of work, and realize that a huge percentage of what you do is not directly development related.My experiences with open source have opened a huge number of doors. I've met people that I wouldn't have met otherwise and had job offers that I wouldn't have dreamed of before. There really is a magic buzz to open source.
"
Right on, Joe!
Friday, 25 January 2008
Process Modelling And Process Execution
Jim Sinur talks about a lesser known aspect in BPM and workflow: the interaction of process modeling with process execution. He walks through 5 use cases of BPM and explains which tools that apply best: modelling tools or a Business Process Management System (BPMS, aka runtime process engine).
The part of it that I think is not enough known is the differentiation between the modelling tools and the process engines. The aim of modelling tools is to let the analyst create a diagram to help with documenting business processes. On the other hand, the aim of the BPMS is to track the progress of process executions and to execute the automated parts of it on a computer system.
BPMSs offer modelling capabilities, but since those models need to be executed later on, there is more to it then just the diagram. The diagram of an executable process will be more restricted then a diagram of an analysis model. Also the diagram of the executable process will be tied to software execution so changes to the diagram lead to changes to software execution.
There are some good tools for process analysis and there are some good BPMSs that support a graphical diagram view onto their executable processes. But making the link between those two worlds is not handled by today's technologies.
BPEL is known as a BPM language. It's an executable process language. And because of its focus on WSDL and executability, it is not suitable to let a non technical business analyst model a business process.
BPMN is mostly known as a graphical notation for business process diagrams. It's a good language for the business analysts, but creating easy and maintainable bindings to executable process languages is not yet demonstrated. Especially the gap between BPMN and BPEL is too big to keep in sync with round tripping.
So this leads to a software development cycle for processes that is completely similar to any other software automation project. Non tech business analysts can create analysis models. From analysis models, implementation models can be distilled. After that translation, the business analyst will only be able to see the implementation models in read only mode. The analyst will still recognise the diagrams, which results in a common language between the business analysts and the development team. That is a big added value that BPMSs can bring.
XPDL and jPDL have already today are most suited for aligning the executable process model with the analysis model. While BPEL is very complementary technology on an ESB, it is still very problematic in making the link between analysis models and executable models.
With jPDL 4 that we are currently conceiving, it will be possible to just add technical details to the analysis model and keep the original diagram as-is for the executable process. That is quite an achievement as the analysis model will not have taken into account persistence, transaction demarcation and concurrency details. Making all of those technical details fit into any Java application architecture is something that we can be proud of. But let's not make this into a jPDL blog.
The main message of this blog was that the link between modelling tools and process execution engines is still not as good as most people assume. Especially not with the two technologies that are mostly known: BPMN and BPEL. While the link between BPMN and BPEL is broken, both technologies can still be very usefull on their own.
The part of it that I think is not enough known is the differentiation between the modelling tools and the process engines. The aim of modelling tools is to let the analyst create a diagram to help with documenting business processes. On the other hand, the aim of the BPMS is to track the progress of process executions and to execute the automated parts of it on a computer system.
BPMSs offer modelling capabilities, but since those models need to be executed later on, there is more to it then just the diagram. The diagram of an executable process will be more restricted then a diagram of an analysis model. Also the diagram of the executable process will be tied to software execution so changes to the diagram lead to changes to software execution.
There are some good tools for process analysis and there are some good BPMSs that support a graphical diagram view onto their executable processes. But making the link between those two worlds is not handled by today's technologies.
BPEL is known as a BPM language. It's an executable process language. And because of its focus on WSDL and executability, it is not suitable to let a non technical business analyst model a business process.
BPMN is mostly known as a graphical notation for business process diagrams. It's a good language for the business analysts, but creating easy and maintainable bindings to executable process languages is not yet demonstrated. Especially the gap between BPMN and BPEL is too big to keep in sync with round tripping.
So this leads to a software development cycle for processes that is completely similar to any other software automation project. Non tech business analysts can create analysis models. From analysis models, implementation models can be distilled. After that translation, the business analyst will only be able to see the implementation models in read only mode. The analyst will still recognise the diagrams, which results in a common language between the business analysts and the development team. That is a big added value that BPMSs can bring.
XPDL and jPDL have already today are most suited for aligning the executable process model with the analysis model. While BPEL is very complementary technology on an ESB, it is still very problematic in making the link between analysis models and executable models.
With jPDL 4 that we are currently conceiving, it will be possible to just add technical details to the analysis model and keep the original diagram as-is for the executable process. That is quite an achievement as the analysis model will not have taken into account persistence, transaction demarcation and concurrency details. Making all of those technical details fit into any Java application architecture is something that we can be proud of. But let's not make this into a jPDL blog.
The main message of this blog was that the link between modelling tools and process execution engines is still not as good as most people assume. Especially not with the two technologies that are mostly known: BPMN and BPEL. While the link between BPMN and BPEL is broken, both technologies can still be very usefull on their own.
Wednesday, 16 January 2008
BPM, A Peel Of SOA And The CIO Filter Syndrome
Jim Sinur kicks an open door and expresses the current general ideas around BPM and SOA in "What is the Nature of the BPM/SOA Codependence?"
I think in many ways the views expressed in that post are too limited and I'll sketch where I would like to see a broader vision. Since the tenor of the post is very representative for todays generally accepted viewpoint, I'll discuss that general viewpoint, even when it goes a bit outside this post of Jim.
In the BPM section, he describes that a human task that doesn't require a lot of thinking can be considered a candidate for automation:
This is what I would call the CIO level filter. The CIO level filter only lets those parts of software development pass that can be understood by business people. BPM and SOA, but also rules fit into that category. Executable business processes and executable rules are in essence pieces of software. These languages try to create a representation that are understandable by non technical people. That is how they should be treated. All too often, non technical people tend to forget about the software nature of executable business processes and executable rule bases and discuss them in the plain english interpretation.
I believe many BPM folks miss insight on general application development to talk about software architectures. In my opinion, applications are developed in silos. Connectivity between application silos is enhanced with the typical SOA, WSDL, WS-* armoury. But BPM is much broader applicable then only on top of services.
There are many forms of process languages. Some of them like BPEL are only targetted at the services level. Others like jPDL are targetted to be used inside application development. So my point is that business processes, in the business sense of the word, translate over many layers of the software architecture, not only the services layer. Some business processes might be implemented on the services level only, in which case BPEL is a good candidate. While other business processes might be implemented as part of a Java application, in which case jPDL is a better option. Other business processes might be easier to implement in plain Java code.
Executable process languages come in different flavours and different habitats. The choice of executable process language should be a technical one. A company can manage their business processes better and more agile by leaving the choice for the process language to the technical team. All too often I see situations where the technology is selected upfront.
On Jim's SOA part, there is another occurence of what I would call the CIO filter syndrome:
So it's not new versus old. It's loosely coupled versus tightly coupled, knowing that inside an application silo, tightly coupling has great advantages. So I think that application development is as relevant as it was before, the only thing that was added recently is a set of standard technologies with which you can easily put a peel of SOA around your applications.
This still leaves the difficult task of the software architect to define what functionality is build in which application and what interfaces will be exposed to the SOA connectivity layer.
In summary, the CIO filter syndrome is that non technical business people try to come to conclusions about software architectures by only looking at the languages and parts of the architecture that they understand. Try to avoid it :-)
I think in many ways the views expressed in that post are too limited and I'll sketch where I would like to see a broader vision. Since the tenor of the post is very representative for todays generally accepted viewpoint, I'll discuss that general viewpoint, even when it goes a bit outside this post of Jim.
In the BPM section, he describes that a human task that doesn't require a lot of thinking can be considered a candidate for automation:
There is another class of work that revolves around human activity where the knowledge level is not as intense and revolves around workflow-like activities. This work has also eluded automation at the level that a service would be needed.The fact that the word 'service' is used bothers me. As if there no other forms of automation then a service. This particular phrase is an example of a broader mistake that I see with business level people talking about software. Their view seems to be limited to BPM and SOA only.
This is what I would call the CIO level filter. The CIO level filter only lets those parts of software development pass that can be understood by business people. BPM and SOA, but also rules fit into that category. Executable business processes and executable rules are in essence pieces of software. These languages try to create a representation that are understandable by non technical people. That is how they should be treated. All too often, non technical people tend to forget about the software nature of executable business processes and executable rule bases and discuss them in the plain english interpretation.
I believe many BPM folks miss insight on general application development to talk about software architectures. In my opinion, applications are developed in silos. Connectivity between application silos is enhanced with the typical SOA, WSDL, WS-* armoury. But BPM is much broader applicable then only on top of services.
There are many forms of process languages. Some of them like BPEL are only targetted at the services level. Others like jPDL are targetted to be used inside application development. So my point is that business processes, in the business sense of the word, translate over many layers of the software architecture, not only the services layer. Some business processes might be implemented on the services level only, in which case BPEL is a good candidate. While other business processes might be implemented as part of a Java application, in which case jPDL is a better option. Other business processes might be easier to implement in plain Java code.
Executable process languages come in different flavours and different habitats. The choice of executable process language should be a technical one. A company can manage their business processes better and more agile by leaving the choice for the process language to the technical team. All too often I see situations where the technology is selected upfront.
On Jim's SOA part, there is another occurence of what I would call the CIO filter syndrome:
The power of the SOA architectural approach is that it enables autonomous subsystems to be assembled into entities (SOA applications / processes ) that can be as cohesive externally as applications built with older architectural approaches (classic components, modularization, or object-oriented paradigm).I agree with the message that an SOA is all about increasing connectivity between loosely coupled components. The interoperability of WS-* infrastructure that is available today helps to simplify and speed up the connectivity problem. But that doesn't take away the applications at the end of the connectivity need to be build and developed. When building applications, tight coupling is a blessing. Without typesafety and refactoring, application development would take considerably longer. Without synchronous method invocations as in Java, applications would run infinitely slower.The benefit of SOAs over these older approaches is increased agility and greater tolerance for change throughout the life cycle of a system, especially compared with a system that assumes tight coupling and homogeneity across the subsystems.
So it's not new versus old. It's loosely coupled versus tightly coupled, knowing that inside an application silo, tightly coupling has great advantages. So I think that application development is as relevant as it was before, the only thing that was added recently is a set of standard technologies with which you can easily put a peel of SOA around your applications.
This still leaves the difficult task of the software architect to define what functionality is build in which application and what interfaces will be exposed to the SOA connectivity layer.
In summary, the CIO filter syndrome is that non technical business people try to come to conclusions about software architectures by only looking at the languages and parts of the architecture that they understand. Try to avoid it :-)
Tuesday, 4 December 2007
BPM Arrives Into Puberty
Bruce Silver is in a real interesting discussion with Marlon Dumas. They are discussing how to synchronize the analysis model of a business process with the executable implementation of a business process.
In my opinion, most BPM Suite products are still in childhood or kindergarten, even when they may have many bells and whistles. The root cause is that most BPM products still pursue the goal of letting non technical business create executable software. The idea is that with a graphical tool, non technical business analists can graphical design a process that is executable on a BPM System. <synical>In general, it's simply not a good idea to put software, produced by a non-technical person into production.</synical> The more realistic goal is that BPM tools try to improve the communication between non technical business analyst and developers and support the development cycle of that type of software.
I have been saying for a long time that analysis and implementation cannot be unified. So it's nice to see that leading industry experts like Bruce and Marlon are coming to the same conclusions. Although they still have different ideas about the implementation parts of the equation, at least, we all seem to be acknowledging the necessary separation between analysis models and executable models of business processes:
I don't think that roundtripping between the analysis model in BPMN and the executable model BPEL is feasible. It would be similar to maintaining a separate UML class diagram for the analysis of a domain model and for the implementation model. That is in practice simply not done. In my opinion, the goal should be that the executable process languages impose the least possible restrictions to make an analysis model executable.
That is the problem of using BPEL for BPM. People have started to realize that BPEL didn't deliver on all its promises. When its used as a service orchestration language to script new services as a function of other services, I didn't hear many complaints yet. But when BPEL was used for Business Process Management, that's when I heard a lot of complaints. It imposes too many restrictions and hence it's hard for an analyst that produced an BPMN analysis model to recognize the process after it has been translated to BPEL. Other languages like jPDL and XPDL are much better suited to make analysis processes executable without touching the graphical view. For one because those languages are graph based. And in the case of jPDL, an extra capability is Actions, which allow developers to add pieces of programming logic to the execution of a process without changing the diagram.
So when we (the BPM industry) would abandon the goal to let the analysts create executable software and acknowledge that, even in BPM, analysis models are different from executable implementations, then it would be a clear sign that we're moving from childhood into puberty :-)
If I recall correctly from this presentation, Neal Ford made a similar comment in general about Domain Specific Languages at his keynote in TSS Barcelona. The idea was that DSL's are there to create languages that make sense to non technical people.
In my opinion, most BPM Suite products are still in childhood or kindergarten, even when they may have many bells and whistles. The root cause is that most BPM products still pursue the goal of letting non technical business create executable software. The idea is that with a graphical tool, non technical business analists can graphical design a process that is executable on a BPM System. <synical>In general, it's simply not a good idea to put software, produced by a non-technical person into production.</synical> The more realistic goal is that BPM tools try to improve the communication between non technical business analyst and developers and support the development cycle of that type of software.
I have been saying for a long time that analysis and implementation cannot be unified. So it's nice to see that leading industry experts like Bruce and Marlon are coming to the same conclusions. Although they still have different ideas about the implementation parts of the equation, at least, we all seem to be acknowledging the necessary separation between analysis models and executable models of business processes:
"No one is talking about removing IT from the BPM lifecycle. In fact I even agree with your 3 roles, although I would describe their function slightly differently. The business analyst creates process models in BPMN. The solution architect (IT) makes model activities and gateways executable by configuring them via point-click dialogs and wizards (no code). The developer creates business services using Java, BPEL or whatever, which can also be bound to model activities to make them executable. The developer may be working in the SOA tool, while the business analyst and solution architect are using the BPMS."The part where I see different is the conversions between the analysis model and the executable developer model. After an analysis model is translated into an executable process, there should be only 1 single executable process. That executable process can still be seen by the non technical people in read only mode. Consider this a projection, where the non technical view hides the the implementation details like transaction demarcations and only shows the graphical part and the business level properties and textual descriptions.
I don't think that roundtripping between the analysis model in BPMN and the executable model BPEL is feasible. It would be similar to maintaining a separate UML class diagram for the analysis of a domain model and for the implementation model. That is in practice simply not done. In my opinion, the goal should be that the executable process languages impose the least possible restrictions to make an analysis model executable.
That is the problem of using BPEL for BPM. People have started to realize that BPEL didn't deliver on all its promises. When its used as a service orchestration language to script new services as a function of other services, I didn't hear many complaints yet. But when BPEL was used for Business Process Management, that's when I heard a lot of complaints. It imposes too many restrictions and hence it's hard for an analyst that produced an BPMN analysis model to recognize the process after it has been translated to BPEL. Other languages like jPDL and XPDL are much better suited to make analysis processes executable without touching the graphical view. For one because those languages are graph based. And in the case of jPDL, an extra capability is Actions, which allow developers to add pieces of programming logic to the execution of a process without changing the diagram.
So when we (the BPM industry) would abandon the goal to let the analysts create executable software and acknowledge that, even in BPM, analysis models are different from executable implementations, then it would be a clear sign that we're moving from childhood into puberty :-)
If I recall correctly from this presentation, Neal Ford made a similar comment in general about Domain Specific Languages at his keynote in TSS Barcelona. The idea was that DSL's are there to create languages that make sense to non technical people.
Monday, 3 December 2007
JavaPolis Sold Out
JavaPolis sold out completely. It's hot cause you can hear about hot Java technologies from the source. The moments I'm looking forward to are a mix of solid traditions and fresh ideas.
The solid tradition is the Belgian beer tap at the JBoss booth. Imagine that! Not only do you get our software for free, but even our beer. I'm still thinking on how we can do something special this year at our booth. Probably Bela Ban's beerathlon, can serve as inspiration. A beerathlon is a race where you have to run 7 kilometers and on the way drink a pint at every pub. Maybe we can do some kind of coding competition. You have to drink a pint before you get the next failing test, which you have to make succesful faster then your competitor. It would be nice if we could include extra beers if you generated too many failing attempts.
As a teaser for the people that were too late with registration, I'll point out my highlights :-)
The fresh idea I'm looking forward to is the unconference. It's a very informal and unprepared way of getting together with your peers to talk about a certain topic. It should be a great way to meet new people and learn different perspectives.
Also, I'm looking forward to the introduction of Parleys.com V2. Parleys is of course nice for those who can't come to the conference itself. But it has a potential to change the way we educate ourselves in this fast paced industry.
Another fresh idea is the Tools in Action track. It really boosts the value of the first two university days. For those that don't know yet, the university days have typically longer talks of 3 hours with a break inbetween. That way it's possible to cover topics a bit deeper then in the typical conference session. But the new Tools track, all kinds of development tools will be showcased on half an hour. Definitely check out RichFaces/Exadel/JSFUnit and Ivy.
SEAM in Action is another talk that I think is going to be great. I saw Peter Hilton give this presentation in Rotterdam last month and he did an excellent job of explaining how to get started with SEAM in very simple terms.
Hope to see you all next week in Antwerp !
The solid tradition is the Belgian beer tap at the JBoss booth. Imagine that! Not only do you get our software for free, but even our beer. I'm still thinking on how we can do something special this year at our booth. Probably Bela Ban's beerathlon, can serve as inspiration. A beerathlon is a race where you have to run 7 kilometers and on the way drink a pint at every pub. Maybe we can do some kind of coding competition. You have to drink a pint before you get the next failing test, which you have to make succesful faster then your competitor. It would be nice if we could include extra beers if you generated too many failing attempts.
As a teaser for the people that were too late with registration, I'll point out my highlights :-)
The fresh idea I'm looking forward to is the unconference. It's a very informal and unprepared way of getting together with your peers to talk about a certain topic. It should be a great way to meet new people and learn different perspectives.
Also, I'm looking forward to the introduction of Parleys.com V2. Parleys is of course nice for those who can't come to the conference itself. But it has a potential to change the way we educate ourselves in this fast paced industry.
Another fresh idea is the Tools in Action track. It really boosts the value of the first two university days. For those that don't know yet, the university days have typically longer talks of 3 hours with a break inbetween. That way it's possible to cover topics a bit deeper then in the typical conference session. But the new Tools track, all kinds of development tools will be showcased on half an hour. Definitely check out RichFaces/Exadel/JSFUnit and Ivy.
SEAM in Action is another talk that I think is going to be great. I saw Peter Hilton give this presentation in Rotterdam last month and he did an excellent job of explaining how to get started with SEAM in very simple terms.
Hope to see you all next week in Antwerp !
Subscribe to:
Posts (Atom)