Business process modeling is rarely applied to simplistic processes. Real world business processes often embody complex decision making. Complex decisions imply choices of action. Rule intermediate events, in BPMN, are designed to express these hard ideas with easy to read diagrams.
We presented an introduction to BPMN diagrams in July. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.
The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).
Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.
Business Process Model of a Day Trader
We can use classical flowcharting to describe a process that a day trader (someone who buys and sells stocks during the same day, to attempt to capitalize on short-term market movements) would follow for purchasing a stock that he intends to sell by the end of the day for a quick profit.
The daytrader will inspect a stock, and if a buy signal is received (based on some undefined criteria), he will purchase the stock. If a buy signal is not received, he will continue to inspect the stock until one is received. Once the daytrader has purchased the stock, he enters into another loop of inspecting the stock until one of three conditions occurs. If the stock price drops by 2% or goes up by 5% he will sell the stock. If the daytrader still owns the stock at the end of the trading day he will sell the stock.
We can use a much simpler BPMN diagram to represent the same process. In this diagram we will use two intermediate rule events and an intermediate timer event.
The day trader starts by watching a stock. There is an intermediate rule event attached to the boundary of the “Watch Stock” activity. Unlike the looping construct in the classical flowchart, repeatedly inspecting the stock, the BPMN activity represents a continuous activity of watching the stock. The intermediate rule event is triggered if the buy signal is received. This creates an exception flow that causes the day trader to buy the stock, and then immediately start watching it again.
The intermediate rule event will trigger an exception flow to the same “Sell Stock” task if either the 2% stop loss or the 5% profit price target is reached.
As an aside, we drew the exception flows both going directly into the “Sell Stock” task. We could have drawn an inclusive (OR) gateway showing the flows reconnecting into the same task. This is an optional element, but it should be used consistently within and across diagrams used by the same people.
Intermediate rule events in BPMN can be used to represent complex decision making in a concise diagram. When writing the rules for an event, keep in mind that if the rule evaluates to true, then the event is triggered and the flow diverts from the normal flow (aka sequence flow) to the exception flow coming out of the event.