3 Replies Latest reply on Dec 11, 2006 7:04 AM by tom.baeyens

    Modelling notation - a Business Analyst perspective

    bazoo

      Hello all,

      I'm a business analyst and I've been playing with JBPM for a month or two now. I understand that there is some controversy within the project about which modelling notation to use, and I wanted to share my perspective.

      To me, the current JBPM notation language is almost perfect. I think that BPMN is far too technical and I much prefer the simple approach of boxes and arrows. The question I ask myself is: "could my business sponsor understand the model enough to be able to sign off on it?". With a BPMN model, the answer is surely no, they couldn't.

      I'm sure BPMN offers much more flexibility and is far more descriptive, but BPMN diagrams are complicated, and hence they put up unnecessary barriers to communication. If the model can't represent the business process in a form the business can relate to, then there is a breakdown in communication on a fundamental level. Anything which starts to resemble a circuit board diagram is simply not going to work for the business, and hence nor will it work for a BA. If the business can't sign off a model as meeting their requirements, then what are we building anyway?

      For me, I much prefer the JBPM approach. Perhaps the only element I would add would be visual swimlaning - part of what my sponsor is signing off is the definition of who does what.

        • 1. Re: Modelling notation - a Business Analyst perspective
          tom.baeyens

          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

            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

               

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