For those of you who have not gotten your copy yet, we have a special price on the Kindle version right now at $9.90.

There is a special reduced introductory price, so be sure to get your copy before the price goes up.  Also note that the Kindle version will be released around the end of July 2011.  There are few process modeling / BPMN 2.0 books available for Kindle, and this is the one to own.

Description:

An updated guide to business process modeling covering a broad range of necessary topics for understanding the new era of process design. A must-have book for business analysts, IT architects, and anyone interested in driving process improvement with a more efficient means of communication. The concise materials in this book focus on modern process design. Developed from actual practices, these techniques are proven in many of the most advanced processes, in production today. More than BPMN 2.0, the book is about Process modeling 2.0 concepts which stress decision and event modeling.

• Most important topics related to business process modeling.
• Quick guide to OMG’s BPMN 2.0 notation.
• Common patterns based on proven design.
• Decision modeling and business rules patterns.
• Event processing patterns.
• Combined process, decision, and event modeling.
• Characteristics of various process types.
• Process Modeling Framework (PMF) for consistent, structured design
• Process Discovery through effective requirements gathering techniques.
• Considering the organization as part of process design.

A special thanks to Jessica Holbrook for the beautiful cover design, Robert Kern for the easy to read layout, and Dr. Richard Welke for the forward.

In this new book we are  including some new groundbreaking material about merging business rules and complex event processing along with traditional process modeling.   According to most leading industry analysts (Gartner, Forrester, IDC, etc), we are at a point where techniques and technologies are merging.  This level of complexity and sophistication requires an overarching governance methodology to be successful.   For this reason I included 30+ paged dedicated to the Process Modeling Framework (PMF).   Thirty pages is not nearly enough on this topic, but at least it’s enough to get started with understanding layered process structures.  The Microguide book strategy is to give a jump-start on the topic of process modeling but yet provide enough details to use the content in the real-world.

I still have plans to publish the process patterns book and the more detailed PMF book.  But because of my fairly recent career path change, my perspective has greatly changed. And, the industry as a whole has changed since 2008.   We are now in the fourth wave.  Therefore the content I had previously created has to be updated.

Keep your eyes open for the new book.  It should be showing up on Amazon.com by mid June 2011.   And thanks again for everyone’s support on making the search term “BPMN” on Amazon.com list my previous book in the top three.

- Rick Geneva

My guest appearance will include about an hour of lecture. I will be discussing multi-tier process design and the Process Modeling Framework (PMF). Up until this point the students have been mostly working in two dimensions. The PMF adds another dimension of detail which takes into consideration the organization where the process will be performed. Most process diagrams focus on who does what, and are divided into swimlanes. This is fine for simple diagrams, but in the real world it’s not that simple. There are politics involved, different owners of different parts of the diagram, and the need to change some parts independently of others. So my intent for this event at GSU is to inspire business students to look beyond the people who do the work, and start to look for the why it’s done, in the context of the larger organization.

Following the lecture presentation I’m going to do a Q&A session and a demonstration of the Process Modeling Framework in action.

- Rick Geneva

The other trend we are seeing more of in this decade is the use of more events, and less tasks. A task that says that something happened is not a task at all; it’s an event.   To be a task it has to be something that is performed by a person, system, or process.  One could argue that everything is performed somehow, so everything is a task.  So let me ask you this:  Is it a task for the weather when it rains?  Is it a task for the highway that traffic is backed up?   Is it a task for the stock market when the NASDAQ drops by 100 points?    If I can’t put a performer to the task, it can’t be a task.



Events can basically do two things: start activity or interrupt activity.  The weather changed, so what are you going to do about it?  The traffic is bad, so maybe try another route?   The stock market is down, so maybe you should buy stocks (unlike the herds of people who sell every time there is a jitter in the market).

Condition or event?

You could also argue that the bad weather is a condition, not an event, and you might be right. But what caused the weather to be bad?   It was likely an event.  And when the condition exists, is that not an event?  The BPMN specification says that a condition is a category of event.   There are two types of condition events; start and intermediate.   As stated above, an event can either initiate activity, or interrupt activity.  Also in the BPMN 2.0 specification we have the new non-interrupting start and intermediate variations of the condition event.  These shapes still serve the same purpose, but also add context to where they can be used.   For example, an intermediate non-interrupting shape is essentially a means to start an activity or flow that is relevant to the subprocess the event is attached to.

In the world of event processing you have essentially two things; events and conditions.  Conditions describe a combination of one or more events.  For example, it’s raining outside and the traffic is terrible.  This is a condition that possibly the weather caused the terrible traffic.  Although, one could argue that all of the cars are causing the weather to get worse (global warming). But that’s another topic entirely.   The two conditions combined of traffic and weather cause an event of something I was looking for, and the conditions are correlated as an event in time.  Weather can be bad on its own, and so can traffic.  The two are not necessarily connected until a stream of events (which we could also call facts) are correlated. For example, a weather report in combination with an emergency dispatch of a car hydroplaning due to excessive water on the road.   With respect to both of these events occurring within a window of time, a condition is born.

Conditions act as a filter of events.  Billions of trillions of events occur every millisecond.  But obviously we are not interested in all events; only the ones that are relevant to our business process activity.  When I figure out a way to filter the events down to something interesting then I have a “condition event”.  In other words, the billions of events have been aggregated down to just one single event that is important to my process.

BPM: meet CEP.  CEP: meet BPM.

Now that introductions are made, let’s talk about what they are and why they are both BPM and CEP are very important and relevant in this decade.


BPM was not designed to handle billions of events.  The BPMN notation is far too simple to handle the sophistication of monitoring millions of stock ticker streams, or monitoring millions of cars per day travelling on a highway.  The individual events are so insignificant that they go largely unnoticed by the larger business processes that everyone is familiar with.  Up until last decade we’ve simply called this an application and didn’t bother modeling it.  But now that Complex Event Processing (CEP) is coming of age, there is a new approach emerging in process modeling that efficiently handles complex events.
Up until recently I honestly couldn’t figure out how to use the condition event in a real-world process model.  The difference is that lately I’ve been experimenting with complex event processing concepts.  Suddenly I realized that a condition is the result of a complex event, then it was easy to put conditional events everywhere.

The job of the complex event system is filter through millions or even billions of events per second and find something interesting that I might want to act upon.  Once captured, this event causes a so-called complex event.  So is it an event or a condition?  Why not a condition event?    This led to my new nickname for the CEP acronym.  Instead of calling it “complex” I call it “conditional event processing”.  I wonder if this will catch on?   Probably not, but at least this might help you make sense of all this.


When CEP generates an event, BPM decides what to do with it.  There are two basic use cases here; you can send the event to a process participant, or the BPM system can further aggregate the condition into a decision of whether or not to take action.  For example, a condition event is detected, which causes a flow into a rule, which determines that either no action is required, or an activity should be routed to a participant.   However, if either one of these paths are taken too often, this is yet again another condition that could be used.  For example, too many condition events are causing too many people tasks, and the organization is overloaded with activity.  This overload condition can cause a feedback to the CEP system to relax the thresholds in which it triggers its complex events.   This is an environment where BPM and CEP help each other do what they do best.

Even Olympic size pools only have a limited number of lanes.

I know that if I suggest that swimlanes will be a thing of the past I’ll never hear the end of it.  So go ahead and start your comments now because yes, I’m about to go there.  I’m not saying we’ll see our friend the swimlane disappear anytime soon.  But I am saying that swimlanes are becoming less relevant.  In an event based world, we don’t necessarily have a performer of a task until runtime.  I don’t know who is going to do what.  So why would I model my process in a way that assumes a particular person is doing something?


Swimlanes have their place.  I stand by my advice that if you have more than five lanes in a pool you seriously need to stop and think about what you are doing.  Also, if you have more than five pools in a diagram, a problem should leap off the page and smack you in the face.  Organizations are not flat like this, and in practice, more than 5 roles would be unmanageable.  Instead, a hierarchy exists to manage the complexity.  So what I’m suggesting here is to select process participants that are more in line with how the organization works.


If you have too much activity happening in one place (a diagram) it could be best described as chaos.   Chaos is complex, and there are likely to be way too many events to process with BPM, or draw with BPMN.  You cannot possibly draw all of the events and conditions that might occur in a diagram that has more than 5 or 6 participants.  Likewise, for a single participant, if you are subdividing the role into many lanes there are likely way too many events to handle (too much participation for one participant).  So why not try the event approach instead?

Understanding complexity, events, conditions, and process activity

For better understanding, let’s take a look at a complexity analogy.  Imagine a large, crowded room full of people having a formal dinner evening.   The attendees (participants) walk around the room introducing themselves to others, and conversations begin. As the conversations increase, the noise increases, and you can no longer hear a conversation more than a meter or two from where you are standing.  A simple task such as getting to the dinner buffet is interrupted by hundreds of events; people bumping into you and trying to cut line ahead of you.  As a participant in this dinner process, if you happen to notice it’s getting quiet in the room, it might be a good idea to stop shouting at the top of your voice because someone probably has an announcement to make.  Or, if you happen to notice everyone running to the exit, maybe you should go too.  There might be a fire.

The point to this analogy is that most of the dinner evening was not planned.  Instead, it was a series of events triggering micro processes.  The overall objective of socializing, rubbing elbows with the important people in the room, and having a good time was achieved.  Everything else was random occurrence.  But even in the randomness there is order and process. For example, everyone got in line when it was time for the dinner buffet, and the other agenda items occurred according to schedule.

The basics of management theory state that the more people are involved in a meeting or gathering, the less productive the outcome.   The same can be said for processes.  By keeping the number of swimlanes down to just the important participants, you can actually show more relevant detail.  The other participants are involved, but there is no point in showing detail of what they do; it’s out of scope.  In the dinner evening process above, it only makes sense to make a process of the over-all agenda.  There might be hundreds of participants in the ceremony, but only a few are important.

At the same time, it’s important that all of the guests are having a good time.  For example, the host detects a high percentage of people complaining about the food or getting sick.  This might be a problem that could be fixed before the party is a disaster.  But the only way to know about this condition is to mingle with the crowd and ask everyone if they are having a good time.  Too many people not having a good time (individual events) is a condition that can be brought to the attention of the organization (the process context).

Event driven business processes

The same can be said for many processes in the business world today.  There is the general high-level process and all of the subprocesses that support the main objective.  In addition, there should be some sort of feedback mechanism to govern the process flow.  Otherwise, the highest level objectives will likely fail.   For example, if I have a manufacturing business and I don’t watch the market for signs of growth or slowing, how do I know how many units to make?  And when I slow down production, do I simply cut back on my labor force, or will that negatively affect my ability to operate?   These are questions that cannot be solved in the process modeling realm; it’s an event problem.  However, these events, filtered into conditions, are something that can be modeled.  I can set up market indicator monitors that create condition events, which tell me when to speed up or slow down production.  I can also set up a means to collect information on bottlenecks in my production line, and correlate this data with employee morale data from the HR department.   Too few people on staff can cost me just as much as too many (overtime, employee retention and training, product quality issues, etc).

The old approach to process modeling was to go about business  as usual and hope that everything works out.  The new approach with the event-enabled process is to provide a way to enable the process to self-optimize.  This is not to say that everything can be automated.  But the information needs to get back to the people who make the decisions, at the right time, and filtered to what is relevant.  As organizations become larger, the events become more important.  This is because the lines of communication are long, and much information is lost in the chain of command.  We cannot model the entire process in one big picture, but we can model the events and conditions that affect related processes.

-    Rick Geneva

In a previous post I wrote about IBM buying Lombardi, and noted that I expect to see more industry consolidation.  Well, we didn’t have to wait long to find out which merger is next.  They say things  occur in threes, so I wonder which BPM company is next….

The IBM acquisition of Lombardi was interesting because IBM needed to fill the department level workflow product need.  This is where Lombardi is being positioned, according to IBM.

Progress software’s move for Savvion was much more interesting because Progress did not have a BPM system, or history of workflow systems.  Instead, Progress has a wide range of SOA systems and tools, and a strong offering in the CEP (complex event processing) and BTA (business transaction assurance) space.   With these offerings, Progress would more likely be positioned to sell products and services to the IT architecture crowd more so than the business.  Now with a full  stack of BPM, CEP, transaction monitoring, ESB, and data services, Progress is very well positioned to be an aggressive competitor in the BPM market.

I’m very interested in this Progress and Savvion merger because it shows the BPM industry is evolving into more event oriented processes instead of people centric activity.   CEP (complex event processing) refers to the idea that things happen that are not necessarily all part of a process.  For example, I can correlate streaming data from traffic, weather, positions of my delivery vehicles (from GPS), and incoming orders from my order system.  In a BPM world these events would only come together when they are relevant to a given activity.  In an event driven world, these events could potentially affect each other at any time, regardless if there is an active process task or not.  Many of these might not even be part of the BPM system.  When the filtered events are correlated to something interesting, a process action can be signaled. Examples of process action include starting a new process for corrective action.  You could also interrupt, continue, or end a process that is in-flight.

The over-all strategy of CEP + BPM means that there is less integration time for systems. Instead of routing all event activity load through the BPM system, the CEP system handles complex correlations of events, and aggregates them down to things that a BPM system might be interested in.  Also, you can get a broader perspective of multiple process instances simultaneously, especially when activities are in-flight.  For example, a delivery truck is running late.  With BPM only, it’s likely that you would not know this fact until the truck is overdue.  With CEP, I can constantly monitor all trucks via their GPS signal, and report all positions to a dashboard. Furthermore, you can correlate to traffic data in-route, and determine exactly how late the truck will be.  This allows an organization to react to exceptional conditions in real-time.   Keeping in mind, most transport companies (and other industries) do this sort of monitoring anyway, but not automatically.  Without CEP + BPM capability, you would have to perform these correlations manually, which might require a huge workforce.  The key here is that the events are reported in real-time, and the event correlations are more accurate.

Continuing coverage of the BPMN 2.0 specification, this post will focus on the new event types.   Prior to 2.0, BPMN had several problems when it came to escalating events and dealing with events in parallel.  Often I would end up using a pattern with multiple loops inside of loops to accomplish seemingly simple activities. Furthermore, it was difficult to distinguish between human centric and system centric activity for a mixed-mode diagram that includes both.

One goal of BPMN is to bring the SOA camp, the business analysts,  and the process modeling communities closer together.  A side effect of this has been that BPMN is very messaging intensive. For complex interactions, multiple pools are used, which requires lots of messaging lines to keep activity in sync between participants .  This is sometimes a problem for people who come from a flowchart/workflow backround using tools such as Visio, which essentially allows you to create a really bad BPMN diagram due to the lack of diagram validation.  Often I see messaging lines within a pool going between lanes, when what was really intended is to do a simple escalation.  Antoher common problem prior to BPMN 2.0 is showing enough detail without having to show the intricate patterns of looping and dealing with multiple events in parallel.


We are starting to see a shift from multiple pools and lanes to more of a style based on a single pool with no lanes, which means less explicit messaging notation. On the other hand, we are starting to see more capability in BPMN to document highly technical processes for the SOA community.


New Event Types

In this post I will cover the new BPMN escalation event and parallel multiple event.

Escalation event

The escalation event is new in the BPMN 2.0 specification.  The shape looks like the Star Trek symbol.  I’m not sure what you call it, but it somewhat resembles an upward facing arrowhead.  The full pallet of escalation events are available.  However, it’s important to note that both start (interrupting/non-interrupting) and both intermediate types can only be used with subprocesses. Only the throwing shapes can be used within normal sequence flow.   This implies that escalation can only be thrown from within a subprocess that has a catching shape.  The intermediates are used on the subprocess border, whereas the start types are used within the subprocess.  Note that you should review non-interrupting events in my previous post for more details on how non-interrupting events work.

BPMN 2.0 Escalation Events

Prior to the introduction of the escalation event, the only way to effectively accomplish the equivalent behavior was to throw an exception, or use a timer on a subprocess border. Both of these alternate patterns introduce potentially unwanted side effects.   If the exception event is used, there is no non-interrupting catching shape. Therefore the parent scope would always be cancelled, and only exceptional flow would be executed. But in the case of escalation, most often this is not the case.  For example, a participant is working on a problem which requires escalation to a manager. The original participant will continue the work, although the manager is now involved.  This is a collaborative escalation mode which requires a dynamic parallel flow, generated by the non-interrupting escalation event.  This would not be possible with an exception event.  Furthermore, a timer would not be appropriate in this case either because the event is not based on time. Instead, it’s based on a condition generated during the execution of a task, probably by the participant performing the task.

Escalation Event Example (non-interrupting)

The example above shows the non-interrupting start event catching the intermediate throw escalation event.  Again, note that if the start escalation event were interrupting (solid), the step “do more work” would not occur.   The start and intermediate catching events can only be used within or attached to a subprocess border.  To further clarify this behavior, study the following example:

Intermediate Escalation example

In this example the handler is on the subprocess border.  Technically this process will execute identically to the one above, with one easily overlooked difference.  The participant handling the escalation in example 1 can directly collaborate with the other active tasks, because they are both in the same scope.  Example 2 has an event handler that is external to the subprocess, which means that the handler does not have access to the same data and event scope as the other active tasks.  All communication between tasks would have to be handled in some other way.  Also note that external synchronization back into the main flow is required, because two parallel paths were created. Failure to synchronize would have the same consequences as explicitly using a parallel split with no merge. The inclusive merge is used because at design time we won’t know if the escalation path will occur or not.  Got it?  If not, bear with me for a few more posts and I’ll get back to these patterns.  For now I”m only covering the spec.

Parallel Multiple Event (inclusive behavior)

As of BPMN 1.2 the multiple event had only exclusive behavior, meaning that a single qualifying event would trigger the shape.  The inner shape of the event is a pentagon.

Multiple Events: Exclusive Behavior

Adding to this shape, you can see the new non-interrupting variety of both the start and intermediate shapes.   Refer to non-interrupting events in my previous post for details on how non-interrupting events work.


BPMN 2.0 introduces the parallel multiple event, which has inclusive behavior, meaning that all related events are required in order to trigger the shape.   There is no throwing type for this shape, because a parallel throwing multiple event would probably raise more questions than it solves.  Anyway, there are interrupting and non-interrupting varieties of the start and intermediate types.

Parallel Multiple Event shapes

Officially the specification calls this a parallel event, because it must receive all events to trigger the shape.  To help eliminate confusion I’ve also been referring to the behavior as inclusive, meaning that all events are included.  But actually, the parallel behavior is much closer to the truth of the use case.  The term ‘parallel’ is somewhat ambiguous because it might imply that all events must be received at the same time.  In reality, parallelism in BPMN does not mean that activities execute at the same time. Instead it means that multiple activities or events are enabled in parallel, and have the potential to occur at the same time.   Just because a task or event is enabled doesn’t necessarily mean that it will execute.  A parallel multiple event requires that all events in the correlation set to be triggered before the condition is satisfied.  Only then will the entire event trigger be fulfilled.

The epitome of complexity

The usefulness of this shape is debatable.  Most BPM vendors have not added support for many of the BPMN shapes because they just don’t make sense for an executable system.  In fact, about half of the BPMS vendors on the market today are using only a subset of BPMN 1.0 or 1.1.   To some, this might seem like a negative point towards the vendors.  But the reality is that most people have a hard enough time understanding the basic subset of BPMN, let alone something as complex as a “non-interrupting parallel multiple start event”.  For those of you just tuning in, this would mean that I have a generic shape acting as a filter for a bunch of specific events, and if this condition were to occur, launch an exceptional flow, in parallel, to deal with the problem.  Otherwise, keep working as normal.   Now see, that wasn’t so bad, was it?


For this shape to actually be useful in a diagram, you are doing one of two things; being purposefully vague (shorthand notation), or you are implying some sort of CEP (complex event processing) mechanism.   So, as I mentioned earlier, BPMN is getting simultaneously easier to use, and more complex at the same time.  Something as simple as a rope can be quite useful, but people somehow manage to hang themselves with it every day.

- Rick Geneva

Your thoughts?

I’m curious to see what some of you other BPM professionals think about this acquisition, and if anyone has any predictions for more consolidations.  Comments welcome.

BPMN 2.0 adds a lot of new concepts.  Many of these are long overdue to be added to the spec.  Others are a totally new concept.  In this post we are going to take a look at one of the long-overdue fixes to the BPMN specification; the intermediate events on the subprocess border.

In previous versions of BPMN, placing an event on the subprocess border meant that when the event was triggered, the exceptional flow would become active.  Also, this means that normal flow stops.  In the diagram below, subprocess A ceases when the timer event is triggered.  Instead, the “handle timeout” subprocess is active at that point.  In other words, subprocess A has been interrupted.

Intermediate Interrupting Event

There is another use case that BPMN 1.2 did not cover.  What if the timer event isn’t supposed to interrupt subprocess A?   Just to clarify, in the BPMN 2.0 specification, Interrupt means that the parent subprocess will end.  This is similar to a cancel, but cancellation is another concept and another shape entirely.  So it’s called interruption.  There is another use case for non-interrupting events that has long been a challenge prior to 2.0.

Interrupting and Non-Interrupting Events

Introduced in BPMN 2.0 is the concept of non-interrupting events.  They are illustrated with a dashed line instead of a solid line.

Intermediate Events (catching)

The difference is that when the event is triggered, the exceptional flow occurs in parallel to the main flow.  This means that you need to be careful how you use it.  Special attention is needed to how the two paths merge.  I recommend treating it just like any other parallel situation, using a gateway to merge.  But which gateway?  Parallel would be the obvious choice.  But remember that a parallel considers all paths to be active on the merge. This would cause a process deadlock if the event was never triggered.   Instead, the recommended merge shape is the inclusive gateway.

Intermediate Non-Interrupting Event

The gateway is used for flow control.  Without it, a potential exists that someone could misinterpret the diagram. I never recommend using implicit merge behavior because the risk is high that it might be misinterpreted.  This is especially true in this case because a small change such as a dashed line now means that we have a potential parallel situation. Most people new to BPMN won’t know this, and people not yet familiar with BPMN 2.0 might not spot this subtle, but critical difference.

Non-interrupting start event

This is where it gets complicated.  I had to read this part of the specification several times to figure out how a start event could be non-interrupting.  There are some small examples in the specification, but to fully understand what’s happening here we’ll have to talk about scopes of subprocess and many other concepts.  For now I’ll just introduce the idea and if you have any questions, please feel free to comment and I will reply.

First, let’s talk about scope.  When something occurs inside of a subprocess, the details are not available externally.   For example, if I were to assign an activity to you that requires several steps, I would use a subprocess.  Within that subprocess I don’t have access to the details of what you are currently doing, and I don’t have access to any data artifacts being created.   The subprocess is essentially functioning independently.  However, the subprocess has access to any information defined in the higher-level scope, such as a pool, or parent subprocess when subprocesses are nested.

Because of the limitations of subprocess scope, the event handler for a subprocess doesn’t actually have access to the data and activities contained within the subprocess.   Because of this problem, BPMN 2.0 introduces the non-interrupting start event.

Non-Interrupting Start Event

When a subprocess starts, non-interrupting start events inside the subprocess are activated.   When the subprocess completes, the evens are deactivated.  So there is a scope of when they are available to be triggered that is the same as the scope of the subprocess.

Also because of the subprocess scope, there is a change in accessibility of the events and the related exceptional flow.  Any activity or event on the exceptional flow can access anything from the parent scope.  In this case, everything is in the same subprocess scope, so both A and B can access the timeout handler, and likewise, the timeout handler can access both A and B.

This sort of behavior is significant because of the parallel behavior. In the example above, when the timer is triggered, a parallel flow is introduced.  The parallel flow is outside the scope of the original activity, which might cause synchronization issues. So you might to use additional events such as signals to keep things happening in the correct order.

Because the non-interrupting flow is in the same subprocess, a merging gateway is not needed. A subprocess has an implicit merge capability.  But you still have to pay attention to details.  If the timeout handler is not completed until after subprocess B, the entire subprocess will still be held back until timeout handler is completed.  This is the nearly identical behavior to the interrupting pattern shown above with the merging gateway.  The main difference is in the scope and visibility of data.

I asked the question why they didn’t just reuse the intermediate instead of the start.  I think it would have been easier to learn. It seems that many folks at OMG are very strict about using start and end events inside every subprocess.  However, the spec doesn’t explicitly say that intermediates are disallowed.  I suppose that using an intermediate as a start of a flow is just as confusing.   Prior to BPMN 2.0 I used to draw the entire pattern in yet another parent subprocess, and create any data artifacts in the higher-level parent scope so that both normal and exceptional flow would share a common scope.    So I can see where this new feature of BPMN 2.0 will be useful.  However, I recommend using text annotations so that people who read your diagrams are clear on the exact behavior you are trying to achieve.

BPMN getting complicated?

I have already received feedback based on my last few posts that BPMN is getting way too complicated.  In some ways I agree, but we also have to consider every use case and have a clear way of illustrating it.    Up until quite recently I was very hard-core on teaching every BPMN shape.  I’m now taking a different approach to process modeling.  Sometimes you need all of the shapes, and sometimes you don’t.  It also very much depends on who the audience is. For the engineering crowd, use every feature of BPMN to the maximum extent.  For the strictly business people, I suggest looking at the basic subset of BPMN and letting others worry about the complexity.  This is yet more evidence that we need a multi-tier process design.  You cannot shove everything into one process model and expect everyone to read and understand it.

I’m not making any promises of timeline yet, but I have a new book in the works that will help clarify the spec and make recommendations on which shapes to use in which situations.

Comments and questions welcome.

- Rick Geneva

This post is a continuation of the Highlights from BPMN 2.0 series.

At Last!  The long awaited changes to the numerous problems with the event based gateway.   First off, there was only one type of event based gateway in BPMN 1.0 – 1.2, and it is exclusive behavior.  Exclusive event behavior means that only one event can trigger the gateway.  Also, there was only one shape that served a dual role of start and intermediate event, yet the shape did not have any variations as the event shapes do (see Demystifying the Event Based Gateway from my previous post).

First, let’s take another look at the original Event Based Gateway from BPMN 1.0 – 1.2

Event Based Exclusive Gateway

Event Based Gateway (Exclusive, Intermediate)

The inner pentagon shape signifies multiple events.  The double circle signifies intermediate usage. Lastly, the outer diamond shape signifies a gateway.  When you combine these attributes you get a gateway that handles multiple event types.  Also note that the inner pentagon shape signifies that only one of the potentially numerous events are needed to trigger the gateway.   In many use cases of process modeling, this is less than adequate for the job.  In many cases I’ve had to create some very elaborate patterns to work around the shortcomings for this shape.  The previous BPMN 1.2 specification allowed for this shape to be used as a start or intermediate event.  With all this ambiguity you might now understand why I wrote a post called “Demystifying” the Event Based Gateway.  Still, there were many use cases that were just too complicated to understand.  So I’m quite pleased to see that BPMN 2.0 finally fixes these problems.

Event Based Start Gateway

Event Based Start (exclusive)

Adding only a slight variation of the original shape, the Event Based Exclusive Start Gateway (that’s a mouthful of words) uses the start event (single circle) instead of the intermediate (double circle).   It’s used as the start event, with intermediate events to the right.  Hopefully by the time the spec is released they will allow for start events to be connected to the right of this shape.   But either way it works for me.  This saves me at least 10 minutes of explanation every time this topic comes up in one of my training classes.

Event Based Inclusive

Event Based (Inclusive, Start)

Event Based (Inclusive, intermediate)

This is where the BPMN 2.0 spec gets interesting.  There has long been a use case where you need to receive multiple events to trigger a process to start or to continue. Previously the only option was to put the event based gateway in a loop until all events have been received.  But then this caused another problem where the same event could potentially be received more than once, which is often undesirable.  In BPMN 2.0 you the new inclusive multiple event shape is introduced (discussed in more detail in a later post).  The shape is an empty plus (+) shape (white filled).  This type of event signifies that all associated events must be received before the event is triggered.  So when you put this event type inside the diamond, you then have a gateway that is only triggered when all events are received.  Note that there are both start and intermediate variations of this shape.

Next post: Event shapes in BPMN 2.0

Comments and questions much appreciated and encouraged.

- Rick Geneva