JV
Hi All,
I have a collapsed subprocess taking part in a collaboration. When I show the detailed view of the subprocess I want to show which actual internal activities send and receive the collaboration messages (refer to attached doc for an example I found on the web). But Aris won't allow me to attach a collaboration diagram to a subprocess, only a process diagram which does not have the option of a pool.
Is this a new BPMN 2 rule or an Aris limitation? I have looked at the BPMN2 spec and it would appear to be valid (refer to point 9.2 figure 9.5 page 116 of OMG BPMN 2 Beta 09-08-14).
Regards
@Johannes: You are right - the call activity/SP is a reusable process that shouldn't be used here IMHO.
However, your assumption that you should be able to use a collaboration assigned to a SP object is wrong when I read the spec. When you look at chapter 10.2.5 of the final spec (dated 11-01-03) you can read:
"A Sub-Process is a graphical object within a Process, but it also can be “opened up” to show a lower-level Process."
That means that a SP only exists as part of a process -that happens within a pool/lane that represent one process (see the explanation close to figure 9.5 in the spec and below)- and therefore only hides detailed steps that exist within this process.
The implementation in ARIS is therefore correct IMHO and supports you in consistent modeling when only allowing an assigned BPMN Process model. This restricts the improper usage of different pools in the assigned model and you can show the interaction in the process by using catching/throwing events, which you would reuse as occurrence copy when modeling the black box pools/processes in other models.
-Roland
Hi Roland,
I agree with the sub-process definition. I also agree that the activities of the expanded view of the sub process cannot be shown in another pool as the collapsed sub-process is already within a pool. So by default the activities of the sub-process also belong in that pool. That is why I'm happy not to show the activities of the sub-process in a pool (I would show them in lanes if different roles execute the activities for example) and the tool can enforce that to prevent the incorrct use of pools, i.e. you can't have a hierarchy of pools as you can have with lanes.
It is just that I want to show which activities in the expanded view of the sub-process initiates or consumes the communication that the sub-process has with the external environment. I feel it gives a better clarification of the process.
I took two photos of how Bruce Silver explains this in his book BPMN Method and Style (page 43 and 44) - I hope he does not get mad at me :) which I attach (not sure how you attach to a comment)
I did not say so at the begining because I think this is a worthwhile discussion (I think we all want to get better at modelling and in our use of BPMN) but yesterday I found a way in Aris of getting round this problem. I am currently in a bottom up phase and have created parent collaboration diagrams for my detailed child collaboration diagrams and have linked them successfully. I'm not telling how for now because I want to first see if it is considered a "legal" method of BPMN modelling :)
Regard
Jannie
I have tried to understand the various discussions in this community on message flow interactions from sub-processes. I think a fundamental misunderstanding of sub-processes is causing this issue, apart from the refusal on the part of ARIS to support this (all tools I am familiar with do support this btw). This misunderstanding also leads (in my opinion) to a skewed reading of the spec.
Indeed, a sub-process is contained in the same pool as the top-level process it is ultimately in. No-one is (or at least, should be) suggesting otherwise. We can expand all sub-levels into the top-level without changing the semantics of the model. (External white-box or black-box) pools in a sub-level should refer to those pools being defined on the top level. Lanes with the same name on any level should be the same lane (labels in BPMN have semantics).
But! Modelling is not just about capturing the correct semantics. It is also very much about an approach, a method, to design those semantics. For that a flat process is just not scalable. We sub-divide a process into sub-processes to manage the design of potentially huge, complex models, as per Bruce Silver's 5-step approach. Restricting the use of message flow elements (Tasks and Events, but also optional message flow connections to any activity boundary) exclusively to the top level process does not only sound wrong, in fact it feels like a dysfunctional behaviour of ARIS trying to sell itself as a feature.
I said "we can expand all sub-levels into the top-level without changing the semantics of the model". That is not correct for some sub-processes: sub-processes with boundary events such as timers, and loops, parallel, MI. I cannot think of how to model those in a flattened process. So it is not possible to make a phone call when working through a stack of invoices?
Your photos didn't come through, but I guess they show some of the (few) things where I disagree with Bruce (collaborations on a lower level *brrrr* :-)
What people try to do is to show everything in one notation and -especially with BPMN- some try to "bend" the notation to their needs. When you look at the scope of the notation/spec, you will read that its only purpose it to match a process diagram with an execution engine/BPMS (for more info see here). But a BPMS is not meant to create a process hierarchy and sees processes as "flat" with a well defined start and end event(s) that allow the execution of one instance of that process - therefore the name "subprocess" is misleading in BPMN. When you look at the behavior of a SP it is more a hide/show (collapse/expand) functionality to unclutter a diagram - the process steps are on the same level than the non-SP steps when you expand it.
Therefore I like to use VACDs in my projects for the higher levels (say 1-3) of the process hierarchy and -if wanted- BPMN only on level 4 of the hierarchy. If I cannot avoid to use SPs in the level 4 processes, I add a "level 4+" model level attribute to the assigned BPMN Process diagrams (one of a few custom model attribute that we add to all our projects here in North America by default when doing the Method & Conventions work). This indicates that from a method perspective it is L4 but shows that for organization purposes the BPMN Processes will be stored in a group below - similar to Function Allocation Diagrams which should be in their own group as well.
Using VACDs and FADs also solves the problems of not being able to use the "correct" objects types in BPMN (e.g. lanes vs. org units or roles).
Hi Roland,
I am in total agreement with you in that sub processes must be used to produce uncluttered diagrams with "hide and show" functionality and should not be used to create a hierarchy of processes. We need to hide the detail as our minds can only take in so much at a time.
You are correct it is one process. The process is executed at the detail level. It is one process not many processes in a hierarchy. What activities are executed is determined by events and gates not by a hierarchy of processes.
Yes "sub process" is sort of misleading, sub sounds as if it is an activity that is below the other activities, of lesser importance, and process sounds as if it is another process that is executed independent of the current process. A better term might have been "process group", a grouping of processes that aims to accomplish one specific result in the process. But then I'm no language expert :)
But my interest is exactly in this “hide and show” functionality as you named it to produce an uncluttered diagram. My aim is to give the viewer contexts with an overview of the process and then take the viewer into the detail of specific functions with an expanded more detailed view (and if required into more levels). Too much detail at first glance reduces the effectiveness of the model as a requirements communication tool. It is just too much for people to get their minds round it.
You must also take into account that you are looking at this from an Aris perspective. Aris has many diagrams that can be linked together. Aris is a rich and powerful modelling tool.
On the other hand I'm looking at this from a pure BPMN perspective. It just so happens that my current assignment uses Aris as their preferred tool but tomorrow I may work for a customer that does not use Aris but who still wants their processes modelled using BPMN. So if you do not have value chains and FADs how do you model the levels of detail using BPMN only. This is where I think Bruce Silver's method makes sense. Rightly or wrongly for personal marketability I rather prefer to be seen as a BA with BPMN skills than a BA with experience in using Aris.
This of course brings me back to my original question, is it a new BPMN 2 rule or an Aris limitation. It would appear to be an Aris limitation but to call it a limitation in Aris is not completely correct because in the greater scheme of things Aris has many other ways of accomplishing the views which reflect the required levels of detail.
Regards
Jannie.
I understand your arguments. However - to answer your question- I think it is not a new, but "a" BPMN rule and not a tool limitation. The implementation just follows the specification.
If I read the spec correctly I can see a hierarchy in the object/model usage and within that the Conversation is the 30,000 ft view, the Collaboration is the 1,000 ft view showing the interaction in pools and with messages, and the Process shows the 100 ft details. By "testing" the outcome of a SP with a gateway after the SP (if it has multiple outcomes) you can show the interaction and are not forced to double the pools and information in multiple models (and being forced to keep the info in sync).
You can see this in the spec for example when you are forced to start a SP with a none event and are not allowed to use a message start event.
In general you should define what kind of information you want to see on which level and then stick with it. Your users -the people who will read the models, not your colleagues or you who create them- will thank you that they have security in what they can expect and not being forced to relearn what they see in each model.
In regards to the tool - I think ARIS is the best tool you can use because it is so powerful (and I would say this even if my paycheck wouldn't come from SAG ;-), and it allows you to chose the proper model for the right purpose. Each of them has their specialties -e.g. how to model data "correctly"- and I think that you should use the right model for the right purpose and be a "more complete" BA in the long run...
Hi, I'm fairly new to BPMN modeling (being a former employee of IDS Scheer, I seem to have one foot firmly planted in the EPC world), but it seems to me, regarding a sub-process object on a Level 4 model (and agreeing that the SP is actually the same level of detail), one could just as easily model a SP as a black box pool and still maintain the integrity of the process "story" being told via the models. IMHO the existence of both the black box pool and the SP is simply to keep the main L4 process limited to an agreed-to number of steps so it is easily understood by the end users.
Is there anything that says this logic shouldn't/couldn't be adopted? Thanks!
Best regards,
Bob
Robert, it depends on the control flow in the process. If you model a black box pool you are saying that the control will be handed over to another participant (actually you send and receive a message) and that that other process will work independently on its schedule, while the other process waits for the reply.
In case of a "regular SP" this is typically not what you want, so a SP in a normal BPMN process is a better way to show/hide steps if you do not hand over control.
For non executable processes, this might be a feasible solution, though.
