Here is a test for my readers.

Question: What BPMN elements may be used to model interprocess communications (mark all correct options) -

1. sequence flow
2. message flow
3. signal event
4. conditional event
5. association

Answer: click to see the answer

Comments to the answer:

» read the rest

Sorry, this entry is only available in Русский.

Let’s consider a process diagram borrowed (with some simplifications) from the book by Stephen White, Derek Miers, “BPMN Modeling And Reference Guide”, p. 113:

The diagram illustrates a fragment of book creation process. The process splits into two subprocesses executed in parallel: writing text and developing book cover. The point is that book cover development may start only when the concept is ready.

The challenge of implementing this logic is that we can’t use sequence flow because it cannot cross subprocess boundary. (Let’s leave apart the question why we need subporcesses here; let’s just suppose we need them for some reason.) We can’t use message flow either because it’s all within a single pool.

The standard recommendation is to use BPMN signal event:

• when the concept is ready, first subporcess triggers a signal
• second process was awaiting for the signal; after catching the signal it proceeds to “Develop Book Cover” task

It’s so called “Milestone” process pattern. A similar example of BPMN signal usage is given in the book by Bruce Silver, “BPMN Method and Style”, p. 98.

Where is the catch?

Everything is OK as long as we consider a signle book creation. Now let’s suppose several books are processed at once. Recalling that BPMN signal is broadcasted to everyone awaiting it at the given moment, as soon as the concept of first book is ready all designers will receive the signal to start developing the cover. Not exactly what we expected.

In order to make the diagram work we must limit the signal propagation somehow. How it can be done?

1. The first thing that comes into my mind is an attribute that would limit signal broadcasting by the current process instance boundaries. Yet there is no such attribute in the standard. Under BPMN 1.x one may say that it’s implementation issue not covered by the standard. But BPMN 2.0 fully specify the process metamodel. Let’s look at page 281 of OMG document dated June 2010: signal has a single attribute - its name. Therefore, a signal will be transmitted to all process instances.
2. If the signal has only name then let’s use what we have. The diagram above may work if we could change signal name dynamically i.e. during the process execution. If we could name the signal “Process 999 Concept Ready” instead of “Concept Ready” then everything will be fine. But it’s a dirty hack and it’s hard to count on it. BPMS engines allow to change certain things during the execution (e.g. timer settings) but unlikely the name.

Why we should care.

Depending on whether we may use signal events to coordinate flows within a process instance, we should chose one process architecture or another:

• if signals propagation can be limited, one can freely use subprocesses - whenever the need to synchronize them arises, it can be done by a signal
• if signals transmit without limits then the only option is to launch separate processes for each branch because we can synchronize processes by message flows, resulting in a diagram like this:

Conclusions:

1. The BPMN standard lacks an attribute giving an option to limit signal event propagation.
2. As long as there is no way to limit the signal propagation, the “Milestone” process pattern should be implmented by message flows between separate pools.

Very common case: an employee performs the task, his boss checks the work and may return it back for correction. It’s usually modelled like this:

I recommend slightly more sophisticated diagram:

The content of two jobs “Do” and “Redo” may not differ at all, it’s about task names. Now what’s the point:

• Within the first scheme an employee sees a task in his list: “Do It. He does, then presses the button and… after 15 minutes he sees the same task belonging to the same process instance. It’s confusing, especially if he managed to work on some other things during these 15 (or 30, or 130) minutes.
• The second diagram is also better from monitoring perspective: it’s easy to calculate the number of “Redo” executions and the total time spent for them and then focus on bringing them to zero. OK, the number of redo’s can be calculated within the first scheme too - by subtracting the number of process instances from the number of task executions. Yet the total time spent (i.e. unjustified costs) won’t be so easy to calculate within the first scheme.

So that’s the pattern: almost trivial yet (or therefore?) widely applicable.

Sorry, this entry is only available in Русский.

Sorry, this entry is only available in Русский.

A short addendum to previous post “A Case For BPMN Signal Event“.

The pecularity of the signal event noted there - a signal is catched by every instance of a receiver process which is waiting for the event at the moment the signal is thrown - refers to intermediate events.

In case of start event one process initiates a signal and another process starts as a result. But why using a signal here - a message seemingly can do the same?

Firstly, a signal allows to initiate several processes at once.

Secondly, a signal has conceptual advantage:

• Let a given signal thrown by a process A initiate start of a process B.
• Now let’s recall that BPM is a management of business processes that change in time and assume that we decided to make process C handle the signal instead of B.
• When a message is used, the receiver is specified in process A, hence we need to modify A scheme in order to change the handler. And if we do we got a problem with A instances already running.
• When a signal is used, we simply install C and uninstall B. We don’t need to modify A nor to do anything with A instances.

This way signal implements late binding: a handler can be set/reset at time of execution rather than development.

Events are both the most powerful component of BPMN and most difficult to learn. There are many types of events (more and more with each new versions of BPMN) and it’s not clear how, where and when to use each one. As a result not only users but also developers of BPM Suites make mistakes by implementing events not exactly as the standard prescribes.

There are two levels of understanding: 1) formal and 2) meaningful. Knowing the definition is one thing and knowing how the event of given type differs from others and what are the use cases is another.

In this article I will focus on the signal event.

» read the rest

There is confusion in the classification of software used to manage business processes:

• Enterprise Architecture (EA) tools target the following aspects of enterprise architecture:
  1. Business architecture - business goals, organizational structure, functions, processes, roles, etc.
  2. Application Architecture - enterprise systems and interfaces
  3. Data architecture - logical and physical
  4. Technology infrastructure - hardware, software, networks
• Modeling abilities of Business Process Analysis (BPA) tools cover a subset of EA: business architecture. But in addition to modeling BPA may include specialized tools like process simulation or statistical analysis.
• Business Process Management Suite (BPMS) must include business processes modeling, execution (process engine) and monitoring/analysis. Optionally it may include simulation, business rules and much more.
• Some vendors define their product as “BPM Software”. Usually this means that the system doesn’t fit into BPMS category - for example there is no engine - but marketing wants it to be labeled with BPM.

BPMS enthusiasts (including myself) believe in the power of executable business processes, in “what you model is what you run” principle. The process engine is a must for them so they can’t live with EA tools only.

On the other hand, enterprise architects have no idea how to handle business processes apart from the organizational structure, data and applications architecture. While many BPMS allow modeling the organizational structure, roles and external systems, it is fragmented to the level of “project” - that is, a logical business process (there may be several physical processes in the project) and do not cover the entire organization. Therefore BPMS doesn’t fit architect’s needs.

Now what shall we do about it? Maybe it’s a temporary issue and BPMS will eventually grow up to EA or EA will include the BPMS functionality some day?

I’d be glad to be wrong but I won’t expect this. Let’s forget about processes for a moment and look at the data architecture. DBMS is much more mature technology compared to the BPMS yet the divide between EA and DBMS is not going to disappear. Enterprise architecture deal with databases but their internal structure is modeled by specialized tools.

Getting back to the processes: they can be modelled both in EA and BPMS. As for today BPMN may be used in both. Typical business analyst knows EA/BPA tools better so the natural way to go for him is:

1. Draw BPMN diagram within EA
2. Two possible options:
   • If BPMS directly executes BPMN, export-import via XPDL
   • If BPMS supports BPEL, translate BPMN->BPEL

For example, model in ARIS and export to WebMethods. Or model in Casewise and translate to Oracle BPEL.

This workflow is simple, logical, but… not working well. Both options work only if we consider a single pass: draw - handover - execute. Yet BPM is not a one-time process automation excercise but management of ever-changing business processes.

What does it mean in practice? Once the model is loaded into BPMS, the developer edits it to specify certain details required by the execution engine. At the same time the original process model in EA tool doesn’t remain unchanged because analyst improves it continually. (I strictly recommend a series of posts started with “Model Strategy: Preserving vs. Transforming” at Keith Swenson’s blog to anyone interested in the matter.)

Now we must either transfer the details of physical implementation back to EA and find a room in the repository for them (so-called “round-trip” problem) or merge changes made in both models (like branch merging in version control systems). In theory the problem can be solved but as a matter of fact it wasn’t for years. Shall we wait more?

I propose to accept that:

1. EA-BPMS divide exists and will remain for the foreseeable future.
2. There will be no satisfactory automatic artifacts passing between them in the foreseeable future.

So where should we draw this division? There is certain freedom because the tools overlap. It’s better indeed to minimize the volume of information transmitted.

Suggestion: let’s divide at the level of a single process -

• The value chain analysis and inter-process communication (via events and/or data) modeling is done within EA tool
• The internal process logic is modeled within BPMS

This way only the list of processes and their interfaces will be transferred from EA to BPMS. Automatic export-import is not necessary for this task, we may utilize “export-import via the printer”.

Every business analyst should obey the red line: never use EA tools to model business process internals if BPMS is present.

There is better application for BPMN capabilities of EA tools. BPMS mostly focus on modeling the internal logic of the processes (orchestration), it’s poorly suited for interprocess communication modeling (process choreography). But the orchestration alone can only solve the tasks at the “office automation” level; as soon as you target the end-to-end business processes - i.e. the processes of real value - you can’t do much without choreography. (See process anti-pattern “End-to-End Process Orchestration”.)

Interprocess communications can be modeled by EA tools using the so-called “black box BPMN diagram” - modeling technique presenting each process as a blank BPMN pool. Communications through messages is modeled by message flow, communications through the data is modeled by associations.

BPMN diagram of interprocess communication (black box diagram) produced by EA tool may look like this:

For each process of the above diagram a BPMN diagram is created in BPMS. It deals with the internal logic of the process (white box diagram):

An example:

We can draw whatever we wish of course but as soon as we tried to make this diagram executable we’d find out that in the real world the payment doesn’t always arrive. As well as in the case of “one-way activity” antipattern, we communicate with an independent subject having a free will (the buyer) and we can’t assume that it will follow our prescriptions.

We should consider at least three outcomes in this example:

1. payment arrived
2. buyer informed about refusal to pay
3. neither payment nor refusal arrived in due time

There is a special BPMN construct exactly for such a case called “exclusive event gateway”:

The beauty of this construct is that the process executes in parallel after passing the gateway, expecting all three events simultaneously. But as soon as one event happens, the other branches stop executing automatically and immediately.

The big regret is that BPMS vendors tend to consider the event gatway as luxury. I know several systems being declared as supporting BPMN yet not supporting this construct.

This is mistake I’m afraid because alternative messages processing can’t be avoided! The only possible way to solve the task in the absence of the event gateway is parallel gateway. But here we hit the problem of stopping other routes as soon as one of possible events happens. It can only be resolved with ugly diagram constructs and/or program code. Of course the process visibility and standard compiance become lost on the way.

This antipattern is special because it comes not from process analysts but from BPMS developers. On the other hand, it’s BPMS vendors will to eliminate this antipattern - they only need to change their attitude towards the event gateway.

As long as particular BPMS does not support the exclusive event gateway, one cannot effectively utilize the message flow. The software supports orchestration but not choreography. An old good workflow to me, whether it has the BPMN label or not.