-
1. Re: Modelling notation - a Business Analyst perspective
tom.baeyens Dec 8, 2006 11:34 AM (in response to bazoo)we prefer the jBPM approach as well :-)
And I agree completely with your analysis. The only thing which is also to be considered by us as a software vendor is adoption. Meaning that when we go out to compete against other solutions, often the decision makers are not always the ones to which you can explain all this. If then, you have to compete with other engines that have the BPMN 'checkmark', it may become hard.
Our current strategy is to work out our own notation for jPDL in our own eclipse plugin designer. We'll keep a close eye on what the BPMN and other editors do in eclipse land mainly in terms adoption. If BPMN would get mainstream adoption, we might have to switch or support both.
Another option that we want to keep open is the usage of layered BPMN. Meaning that you could define a subset of BPMN wich corresponds pretty much with what we have now in our jPDL editor. Then the tool could be limited to this subset. Then the subset could be enlarged by adding a next set of BPMN constructs... until you have the full BPMN constructs set. That might be another approach to get the best of both worlds.
The swimlane remark is certainly right on. Currently, we have been reluctant because our process language alowes multiple tasks in one task node. Then all of these tasks might potentially be assigned to different swimlanes. But we should at least go for swimlane support and just fix that problem. Either by limiting task-nodes in a swimlane to max 1 task. Or by just taking the first task into account for the swimlane representation. -
2. Re: Modelling notation - a Business Analyst perspective
bazoo Dec 11, 2006 6:43 AM (in response to bazoo)I think the layering approach could work well. Indeed, it would really enable the models as a means of communication. If a model can be simple enough for the business to sign off, but descriptive enough to fill in the technical details the app or developer needs then we are talking about an ideal scenario.
This would also allow project teams to pick and choose the approach they take on a project-by-project basis. Sometimes a quick and dirty model might be the way to go, where a concept needs to be quickly proved or disproved. On the other hand, on bigger projects it might be more appropriate to spend more time on the model, and ensure that communication between analysis and development teams is crystal clear.
One caveat: I have seen situations where the delivery of a solution takes a back seat and modelling becomes an end in itself. Perhaps this is something that should be thought about as part of BPM project methodology rather than the notation, but it would be great if the notation could limit such extravagance. -
3. Re: Modelling notation - a Business Analyst perspective
tom.baeyens Dec 11, 2006 7:04 AM (in response to bazoo)One caveat: I have seen situations where the delivery of a solution takes a back seat and modelling becomes an end in itself. Perhaps this is something that should be thought about as part of BPM project methodology rather than the notation, but it would be great if the notation could limit such extravagance.
exactly. that is the key issue which still needs to be addressed. good to see that others think in the same direction as us :-)
maybe the GUI tools should have a level indicator that enables/disables these levels...