News

Is process modelling easier with S-BPM than with BPMN? Given the very small number of symbols in S-BPM compared to the over 140 symbols in BPMN, the answer seems obvious. On the other hand, there are observations that many process modellers still seem to feel more at ease with the global control-flow perspective of BPMN (with a reduced set of symbols). Why is that?

To understand this issue I suggest considering a second dimension: the degree to which the knowledge about a process is distributed. When all the knowledge needed to model a process is available to 1 person, the global, "end-to-end" process view of BPMN may be more intuitive than the modular perspective of S-BPM where separate process parts are encapsulated in different subjects. However, when the process knowledge is distributed across several people (I'd say more than 2 or 3 process participants), the global view of BPMN quickly becomes very difficult to construct and maintain; to a point where it is no longer manageable. Modelling with S-BPM is more scalable in this respect, with additional knowledge sources leading only to a linear increase in difficulty. ("Difficulty" may be measured in several ways, for example as the subjective perception of individual process participants, as the time needed for process modelling, or as the correctness of the resulting process models.)

This hypothesis is based on two considerations:

  1. The more participants in the process, the more communication relationships you have to include in the model. BPMN, with its focus on control flow (rather than data flow), is very limited in this respect. Simple instances of communication can appear very complex in BPMN, sometimes requiring the use of "advanced" BPMN constructs (such as the signal event for intra-pool communication). S-BPM, in contrast, provides unique symbols for sending and receiving messages and even has a dedicated diagram for modelling communication relationships.
  2. The more distributed the process knowledge, the less the individual participant knows about the other participants. This is a problem for BPMN modelling, as one swimlane needs to understand the detailed process in the other swimlane in order to know which activity it needs to interact with (e.g. by sending a message to that activity). In S-BPM, a subject only needs to know the type of message and the name of the subject it interacts with; the internal behaviour of the other subject doesn't need to be known. This separation of concerns enables concurrent modelling by separate process participants, as they can focus on modelling their own behaviour without needing to care about the internal behaviour of the others.

Current training examples and exercises in (BPMN) process modelling typically provide complete textual descriptions of a process. So all the relevant process knowledge is located in one place, and the distribution of knowledge is zero. Most research in the "process of process modelling" is based on the same "zero-distribution" assumption. To fully understand the benefits of S-BPM in terms of ease of modelling, more attention needs to be given to situations when process knowledge is distributed.

What are your thoughts on the "distributed knowledge" hypothesis?

Email me when people comment –

You need to be a member of Institute of Innovative Process Management (I2PM) to add comments!

Join Institute of Innovative Process Management (I2PM)

Comments

  • Let me start with this quote of yours:
    “…modellers still seem to feel more at ease with the global control-flow perspective of BPMN.”
    Two things about this statement:
    1- Yes; BPMN is developed by people that represent traditional BPM stream but it is not the BPMN that has this global control-flow perspective, it is the people!
    2- Yes; I agree that people like to see (or I’ll go further ‘need to see’) a global control-flow perspective of a process to have a clear understanding of the overall scenario and more importantly where they stand against it.

    Let me start from the second point (about a need to view a global flow of the process): This is exactly why I proposed to merge individual role models (through message exchanges) at different abstraction levels in my previous works. But there is something important in this scheme. We should still be able to keep maintaining the individual role models but not the merged one (simply because individual models are more maintainable). And for this to happen, the merging process should be automated as much as possible (preferably fully).

    For the first point - the main point (notation vs. approach):
    My personal opinion is that it is not much about the notation but it is in the use of the notation, i.e. the method of process modelling.

    I think we should position ourselves carefully when discussing or promoting the idea of S-BPM (or stakeholder-driven BPM, or even -the rather old terminology that I came up with in the old days- ‘decentralised / role-based process modelling’).
    I personally believe that it won’t be right to stand against the BPMN just because it is the ‘product’ of the traditional BPM stream.
    And I would argue that this creates some resistance (and even contempt) in the main stream BPM community against S-BPM, which - I believe- we should avoid.
    The immediate reaction from these people is that it is possible also with BPMN. And guess what, I agree.
    So, on the contrary, if we want to promote the S-BPM as a viable alternative approach in BPM, then showing that it can even be possible with BPMN would help better.

    Besides, I find it quite unfortunate to see that the term S-BPM is usually used interchangeably to represent both the paradigm/approach and its notations.
    Following the S-BPM approach in process modelling, I have used three different notations throughout all these years: eEPCs, S-BPM notation, and the BPMN (all can be traced back in my papers).
    I must say all worked almost equally well. But I think BPMN gained some advantages recently because of generous tool support and obvious popularity among practitioners.
    People tend to stick with what they know best and it makes them happy to see that they can use the same tool of theirs (BPMN) for hammering the nail just in another way.

    To sum up (this rather overly long response :), in your chart above, instead of the notation I would rather put the modelling style/method, i.e. S-BPM vs. Traditional (Procedural/imperative) control-flow oriented modelling.
    Then we can start discussing if it would really represent the reality :)
    • > This is exactly why I proposed to merge individual role models (through message exchanges) at different abstraction levels [...]

      I am curios: Are you referring to an abstraction which omits information from the individual subject models? Not that this is a bad thing - the information is still available in the subject models. I am just unsure what information to omit in order to produce an understandable (small) but still sufficiently comprehensive model

      > So, on the contrary, if we want to promote the S-BPM as a viable alternative approach in BPM, then showing that it can even be possible with BPMN would help better.

      This seems plausible.

      > Besides, I find it quite unfortunate to see that the term S-BPM is usually used interchangeably to represent both the paradigm/approach and its notations.

      Yes, maybe the term "subject-orientation" might be used to refer to the paradigm (although not necessarily the most catchy one) while S-BPM denotes the tuple (paradigm, notation).
      • A late reply (for the question about the abstraction), but anyway ...
        Thanks for the reply first of all.
        I am afraid, in order to answer that I have to give some background info about some concept in the Plural method.
        Let me try doing it in brief.
        A process model is composed of several subject models (each called an 'operation'), but unlike the traditional S-BPM :) a subject can have several operations (and as a result, several subject-operation models) associated with a single process.

        The notion of 'operation' is analogous to the concept of subject operation in SO programming (or to the more well known concept of object-operation/method in OO).
        An operation is a set of related activities that initiates when the subject receives a set of certain inputs (from other subjects or its environment), and ends when a certain set of outputs is produced and delivered to other subjects or to the environment.
        For instance, "approve document" can be an operation, where our subject receives a document, checks certain properties, then send the approved document, or rejection with comments to another subject. An operation typically starts when he/she receives the token and ends when he releases to someone else. In the extreme case, an operation incorporates a single activity (task).

        The use of operation can not only help to achieve some level of modularisation (and abstraction) in the process model, but also allow for other concepts to be applied, such as reusability and inheritance. [these are a bit advanced concepts to be applied in process modelling but still ... For example: subjects can now reuse their operations in different processes. Or a more concrete example: our "approve document' operation can be specified as an abstract operation, which can be concretised as 'approve design document', 'approve delivery document', etc. in different processes.].

        As for the abstraction, now the entire process can be reconstructed (at least) at 2 levels:
        1- At the activity level (fully fledged): All activities, message exchanges, ... in all operations of a single process. You see the entire detail and message exchanges between the subjects (each subject has its own swimlane).

        2- At the operation level: where all subject-operations in a model are integrated (again through message exchanges) but the details of the activities etc. are hidden. There are as many swimlanes as the participating subjects, and you see all the operations of subjects and the message exchanges between them.
        So, coming back to your question :) yes, in a way " ..an abstraction which omits information from the individual subject models".

        I guess I'd better stop here before this post gets even longer :)
        More info is certainly available in the papers. Although a bit old by now, this one might give a brief idea: https://docs.google.com/file/d/0B0i4ZY_RKOZ0N3MzaVV1bEV3OTA

        Best regards,
        Oktay
        • Interesting. This means that there is potentially a class hierarchy of subjects and messages are exchanged between subject classes / types instead of subjects.

          This probably is designed for more advanced modelers. After all, he/she must very carefully determine to which abstraction level of a subject (i.e., which subject class) a message is being sent to.

          However, this appears to allow creating abstractions on multiple levels as subject interaction diagrams might choose at which subject classes abstraction level the subject interaction is being visualized. Obviously this also implies that diagrams typically only show extracts of the behavior / subject interaction. Consequently, this would mean following the UML route where diagrams are imperfect and limited representations of a large single "invisible" model.
  • Hi Udo,

    Maybe we should distinguish between (a) "Is BPMN capable of modeling distributed processes in a way that is similar to S-BPM?" and (b) "Is BPMN encouraging this?".

    IMHO, with the concept of message flows and pools, a subject-oriented way of modeling business process is very well possible with BPMN (even though the semantics are less sharp than in S-BPM). The problem with BPMN is more that is not really encouraging a subject-oriented perspective. In general, BPMN is careful not to strongly encourage any convention. Although this is a deliberate decision, it is unfortunate because this leaves too many choices and redundant ways doing the same thing.

    Maybe with conventions inspired from the S-BPM way of doing things, BPMN might actually be a very useful way of representing distributed knowledge.

    Best regards,

    Matthias

    (Disclaimer: I am active both in the S-BPM and in the BPMN community).
    • Hi Matthias,

      Thanks for your comment. I agree that BPMN can be used for modelling in a more "subject-oriented" way (e.g. by using "black box" pools as in @Oktay Turetken's work), and that it includes a lot of ambiguities. However, I think that there is a strong tendency of BPMN to afford the view of an omnicient observer - someone who has all the knowledge of all the details of a process. This is what most BPMN textbook examples suggest, and what I assume that most BPMN-trained process analysts apply by default. It is only when process models become very large (and the control-flow logic too complicated) that modellers resort to some kind of S-BPM techniques and hide some parts of the process using black-box pools - at least that's my own practical experience in BPMN modelling before I was introduced to S-BPM.
      So perhaps the BPMN curve in my figure should have a "practical" (S-BPM flavoured) variant, where it becomes flat after reaching a certain degree of difficulty?

      Best Regards,
      Udo
      • Hi Udo,

        Yes, I like the notion of having two BPMN flavors in the figure (Flow-Oriented and Subject-Oriented).

        Best Regards,

        Matthias
This reply was deleted.

You want to publish news here?

Read more…