2/14/13

Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture - Books24x7

Chapter 4 - BPMNAdvance Constructs Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture by Matjaz B. Juric and Kapil Pant
P ac kt P ublis hing 2008 Citation

R e com m e nd?

Chapter 4: BPMNAdvance Constructs

The chapter will go into the details of using events and other main BPMN elements, and how they fit together to represent a business process. This section will define how the common BPMN patterns are to be used by analysts to represent scenarios typically seen in an organization.

Business Process Modeling General Guidelines

Before we move further, it's really important to understand some of the rules that are helpful while modeling and designing our business processes. In this section, we will look into some main modeling rules from the perspective of modeling a process, and the instructions specified by BPMN and supported by Oracle BPA.

Rule #1: Process Models should Provide Aid in Process Understanding

A good process model should allow the overall process flow to be visible at one glance, either from left to right, or from top to bottom. To achieve that, a modeler can follow these basic rules: Aim for a minimum of four, and a maximum of fifteen tasks in a process Aim for a maximum of three or four levels in a hierarchy

A good model gives you an intuitive and easy to understand overview of how a business process works, as this is the main purpose of a graphic model. A model with a large number of tasks may be correct and unambiguous, but becomes difficult to understand and, therefore, less useful. You can improve this diagrammatically by grouping tasks into a sub process. In other words, by creating a hierarchy of processes, sub-processes, and tasks. Depending on the complexity of the process, several levels of nested sub-processes are allowed. However, in terms of best practices, it's always better to keep the nesting to a maximum of four levels. This also ensures that the number of activities represented in a process is reduced to a maximum of 10 to 15, which can make the process more readable.

Rule #2: Match Each Split with a Join

In the following figure, the process shows a common mistake with parallel tasks, where an AND split is not properly closed by an AND join.

library.xu.edu.ph:2059/assetviewer.aspx?bookid=30143&chunkid=184380050&noteMenuToggle=0&hitSectionMenuToggle=0&leftMenuState=1

1/4

2/14/13

Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture - Books24x7

This mistake can cause a serious problem. Visually, if Take Case File is completed, then users might think that the process is ending, while it might be possible that the patient has still not reached the doctor. Therefore, it is wise to close the path by using an AND-join to provide the process with a clear checkpoint. This will allow us to check whether all parallel tasks have been completed before the process can continue. The following figure is an example of using an AND-join to ensure that the process can move forward with any further activities. only after both the case file and patient arrive.

In addition, it is nice to use gateway symbols while modeling the process as this improves readability and understanding while reading or creating business process diagrams. Another issue, especially with the use of AND Join, is the possibility of a deadlock situation in a process. Consider the following process:

In this example, an employee's bonus is calculated based on sales targets achieved. The inclusive OR gateway ensures that only one option is taken. However, if you notice, the join gateway used is of type AND, and hence will wait for all parallel processes to complete. Now we have a deadlock situation as the process will never take one of the paths. To avoid this situation, use an OR Join instead of the AND join. The basic rule of thumb to avoid deadlocks is to ensure that every path in a process reaches the end state, especially when working with parallel or AND gateways.
library.xu.edu.ph:2059/assetviewer.aspx?bookid=30143&chunkid=184380050&noteMenuToggle=0&hitSectionMenuToggle=0&leftMenuState=1 2/4

2/14/13

Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture - Books24x7

Another technique to avoid possible process deadlock is always to ensure there is at least one outgoing task for every possible condition at the gateway. Consider the following example:

In this case, the conditions for both processes are either greater than, or less than 100. Therefore, in a situation with an expression value of 100, there will be no output path. Hence, it could result in a deadlock. This is a simple example, and in some business scenarios, it may be overlooked by an analyst and can be misinterpreted as we go down the implementation route. To avoid this situation, it would be appropriate to use the Default flow provided in BPMN, or ensure that there is always at least one path out of the gateway.

The notation used for Default flow in BPMN is a sequence flow with a tilde at its origin. In this case, if the candidate scores 100, he or she will be called in for a discussion before being given a certificate. This was just an example, but in normal process flows, care should be taken to provide default flows to prevent deadlocks.

Rule #3: Have a Well-Defined Start and End Event

library.xu.edu.ph:2059/assetviewer.aspx?bookid=30143&chunkid=184380050&noteMenuToggle=0&hitSectionMenuToggle=0&leftMenuState=1 3/4

2/14/13

Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture - Books24x7

Though not mandatory, it's a good idea to start the process using the start event, and end the process using an end event. This keeps the process elegant, and also gives motivation to designers to ensure that all paths are closed, and linked from the start event, or to the end event, either directly or indirectly.

Rule #4: Look Out for Orphan Tasks

Consider the following example:

The activity Provide Billing Details will never be executed, as it does not have an input sequence flow to this task. As this is a simple process, it looks like an obvious mistake, but in a complex process, such a case can sometimes be overlooked. All efforts should be made to link every activity from the start event, and have at least one incoming sequence flow to maintain consistency. The BPMN standard also places a number of conditions on the representation of a process flow. The aim of this is to ensure consistency in diagram display and interpretation. These rules help in ensuring that BPMN maintains a degree of control on how a diagram is created, and at the same time, allows a bit of flexibility for a modeler and modeling tool vendors to work around the notation. Most of the modeling tool vendors are still maturing, and we will see further compliance to the standards and adherence to modeling rules as specified by BPMN.

Use of content on this site is expressly subject to the restrictions set forth in the Membership Agreement. Books24x7 and Referenceware are registered trademarks of Books24x7, Inc. Copyright 1999-2013Books24x7, Inc. - Feedback | Privacy Policy (updated 03/2005)

library.xu.edu.ph:2059/assetviewer.aspx?bookid=30143&chunkid=184380050&noteMenuToggle=0&hitSectionMenuToggle=0&leftMenuState=1

4/4