Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Posts Tagged ‘trivia’

The Thin Layer Called Process

It’s a paradox but the term “process” remains the most ambiguous in BPMN, as the recent discussion on the BPM.com forum has shown.

  • In our day-to-day life we call “process” almost anything from digestion to the formation of galaxies.
  • Many consultants are comfortable with the process definitions that cover any orderly set of activites aimed at certain result. It makes sense when we focus on business performance but when we get into details it becomes hard to ignore the difference e.g. between processes and projects. One may treat a project as special case of a process indeed but the fact is that we manage projects and processes substantially differently so a definition that makes no difference between processes and projects would be counter-productive. That’s why I like the term “business capability” - it provides an umbrella term for different kinds of business activities yet it doesn’t merge them all into “process” treated too widely.
  • Process definition narrows even more in BPMN context. First, there is a clear difference between a process and subprocess in BPMN: the former is triggered by external event (e.g. a message, timer or free will of process initiator) while the latter is called from overarching process or subprocess. Secondly, the entities more abstract than a single process are beyond BPMN scope completely. There is no element to model process groups in BPMN so one can’t depict things like “value chain”, “supporing processes” or “product promotion”.

Thus, if we look at the process hierarchy through the prism of BPMN, we’d find several levels of process groups at the top, several levels of subprocesses at the bottom and a thin layer of what BPMN calls a process in the middle:

See also:

04/03/17 | Articles | ,     Comments: 2

Limited Usability of BPMN Lanes

Lanes (known as swimlanes in BPMN 1.x) represent process performers in BPMN.

Rules for the lanes:

  1. Lanes are optional.
  2. Lanes may be nested (hierarchical).
  3. Lanes semantics is fully at the discretion of the diagram’s author - it may be a function, role, position…
  4. Embedded subprocesses do not have pools and therefore can’t have lanes.
  5. Lanes are meaningful only to the user tasks - service tasks, script tasks, subprocesses, gateways, events are irrelevant to which lane you put them in.
  6. Even for the user tasks the lane is essentially a comment - actual performer is defined by the model attributes of the given task.

Novice BPMN users love lanes and use them at first excercises with enthusiasm:

Figure 1. BPMN diagram with lanes.

However using lanes won’t allow showing the process “happy path” which arguably is more valuable from ease of perception standpoint:

Figure 2. BPMN diagram with a happy path.

Moreover, when dealing with large processes there is no room for lanes at all.

There is a general rule applicable to any notation including BPMN: the number of activities at any diagram level should not exceed 7-9. Otherwise the scheme becomes too difficult to perceive:

Figure 3. “Flat” diagram with a large number of activities is hard to understand.

Accordingly, if the process comprises a large number of tasks, it should be decomposed into subprocesses:

Figure 4. Subprocesses help creating a simple diagram from a complex process.

But this style of modeling leaves no room for lanes:

  • At the top level there are only subprocesses while lanes apply only to the user tasks (rule 5).
  • Subprocess diagram doesn’t allow pools nor lanes (rule 4).

More precisely, rule 4 applies only to the embedded processes; reusable subprocesses may have lanes. I’ve seen diagrams where reusable subprocesses where used instead of embedded solely to be able to depict lanes. This is definitely bad practice - embedded subprocesses shall be used for the decomposition. Reusable subprocesses introduce additional complexity because unlike embedded they are executed in a separate data context.

If you can’t live without diagramming performers then use BPMN artifact “group”:

Figure 5. BPMN groups shows performers within the embedded subprocess.

06/27/11 | Articles | ,     Comments: 32

Modeling Subprocesses in BPMN

If you’re working with on a complex enough business process then at some point the process diagram will become bloated and unreadable. This means it’s time to make hierarchical decomposition - in simple words, split the process to subprocesses. The old rule of having 5 to 9 activities per level is fully applicable to BPMN.

Let’s consider the contract process with three phases:

  1. Agree essential terms of the contract
  2. Agree the contract text
  3. Authorize the contract

Naive process diagrams like the following aren’t rare:

» read the rest

05/27/11 | Articles | , , ,     Comments: 22

BPMN Orchestration-Collaboration Balance

Definition 1: Orchestration - a diagram depicting a sequence of activities coordinated from a single center of control.

Notes:

  • Synonyms to orchestration are workflow and, in fact, process.
  • Orchestration is modeled by a white-box pool in BPMN; it may also contain optionally black-box pools presenting external entities.
  • The phrase “coordinated from a single center of control” means that even if a process diverges at some point, the branches remain coordinated e.g. they can be synchronized later in a converging fork; the whole process will end when all branches are completed.

Definition 2: Collaboration - a diagram showing interactions between processes.

Notes:

  • In BPMN 1.x interprocess communication was called choreography. In BPMN 2.0 choreography is reserved for a totally new type of diagram - what used to be a choreography in BPMN 1.x is called collaboration now. So it goes.
  • A collaboration diagram contains more than one white-box pool.
  • Some people reduce collaboration to the exchange of messages but generally speaking, processes may communicate via messages, signals and/or data (data store, conditional event).
  • Processes on a collaboration diagram are executed independently except specific sync points where messages and signals are sent/received, data read/written.

The big BPMN advantage is its support of collaboration as well as orchestration. This is also a key criterion for choosing a BPMS. Yet as my BPMN training shows, the right balance between orchestration and collaboration is tricky.

There are two common pitfalls:

  1. At a first approach to BPMN analysts try to do the job with orchestration only. Yet it works only for very simple processes like vacation request. Cross-functional processes that are of greatest interest for the business are multi-threaded by nature and hence can’t be modeled within orchestration.
  2. After getting acquainted with messages and learning that they can only be used between pools, many analysts introduce unnecessary pools into their diagrams. For example they love to use pools and messages where a subprocess would suffice:

Fig.1 Process antipattern: “Messaging instead of subprocess”

The common arguments in favor of this scheme:

  • “This process is performed by another entity.” - Use swimlanes not pools to show a performer.
  • “The process can be called from several points.” - So do reusable subprocesses.
  • “The link between the caller and the calling process becomes visible.” - First of all, expanded subprocesses are transparent, too:

Fig.2 Expanded subprocess

  • Secondly, for a well-structured diagram with properly separated abstraction levels collapsed subprocesses are sufficient: when we look at the process top-level, we must understand its logic without knowing the details of subprocesses. The subprocess contents shaill be presented on a separate page:

Fig.3 Collapsed subprocess

It’s a matter of style rather than correctness - the diagram in Figure 1 is formally correct. Yet I recon it’s an antipattern and inventing a wheel because messages are used to model a behaviour witch is already built-in into subprocess invocation:

  • when a control flow reaches a subprocess a token emerges with a subprocess and the caller goes into a wait state
  • when the subprocess completes the caller continues

In summary, here are my rules for the optimal balance between orchestration and collaboration:

Rule 1. If your attempts to model a process are unsuccessful because some significant aspects are missed repeatedly then stop and think - maybe in fact it’s not a single process but two or more?

Rule 2. Do not overuse collaboration - stay within the orchestration as long as possible. Never introduce collaboration into a diagram just because you’ve recently learned how to do that.

In the following article I’ll share my experience of identifying independent processes during analysis.

05/19/11 | Articles | , ,     Comments: 2

Copyright © 2008-2024 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments