Blog

My last posting referenced the criteria for a well-formed business process diagram mentioned in Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. I am going to expand on their criteria to create a more comprehensive definition of a well-formed business process diagram.

To start, here are three criteria from their book:

• Match each split with a join.
• Have a well-defined start and end event.
• Look out for orphan tasks.

I am not going to use the criterion that — although a good rule of thumb — it is really a generality:

Process models should provide aid in process understanding. 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.

To the above three criteria, I am adding the following of my own:

• A given input message/event is received by only one process/task.
• A given output message/event is produced by only one process/task.
• Processing of an input message/event is started in the process/task that receives the input.
• An output message/event is generated at the earliest point possible and not passed to a later process/task.
• Each process/task must have at least one input or one output message/event.
• All input and output messages/events are at an atomic level. No composite messages/events are used.
• Use parallel processes/tasks whenever possible.

Workflow Modeling by Alec Sharp and Patrick McDermott provides a two additional criteria:

• Process/task names should be in verb-noun format. An example is “pay invoice.”
• Assemble processes based on frequency and affinity. High affinity is define as having 1:1 links. This technique clusters steps with 1:1 links and separates those clusters at the point of 1:M or M:1 links.

I welcome any improvements or additions to these criteria. Eventually, I will add the above criteria and any improvements or additions to the Wiki on this site.

By the way, the Decomposition Matrix on this site generates diagrams that meet this criteria. You do, however, need to provide the naming in verb-noun format yourself after the diagram is generated.

I recently received two new books on business process modeling. Both books looked interesting because they had great titles. As it turns out, one book is great and the other not so good.

The not so good book is Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. There are several issues I have with all three topics mentioned in the title this book. First, the treatment of SOA is very surface and completely leaves out both SOAP and  REST. I realize that a book like this one has a lot of ground to cover and cannot go into detail on all topics. Nevertheless, since the authors  mention WSDL, it seems to me that they should have mentioned SOAP and REST as well — and worked both into their BPEL examples. Second, there are errors in the BPMN used throughout the book as documented by Bruce Silver. See Bruce’s review for a description of those errors. Third, the BPMN to BPEL mapping — which is nearly 20 percent of the book — is really just a tutorial on an Oracle tool. Nearly as much space is devoted at the end of the book to orchestration, again demonstrated by an Oracle tool. I have no issue with Oracle. My issue is that the tool tutorial gets in the way of the clearly describing the basic concepts that need to be covered. The reader would have been better served, for example, with a framework on how to evaluate such tools.

The other book is BPMN Modeling and Reference Guide by Stephen A. White and Derek Meirs. This is a very readable book that is, as the title indicates, a reference guide. It is an easy, yet excellent, introduction to BPMN. Nevertheless, as a reference guide, it does not contain anything on methodology.

So, I am interested the criteria for a well-formed business process diagram or a technique for business process decomposition. I have a fair number of books on business process modeling, but they fall short in these two areas. For example,  the first book reviewed does provide some guidelines (or rules as they are called in the book) for a well-formed business process diagram:

• Process models should provide aid in process understanding. 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.
• Match each split with a join.
• Have a well-defined start and end event.
• Look out for orphan tasks.

This relatively surface set of guidelines is not uncommon in the books I have. (Maybe I have just purchased the wrong books.) To take my point a bit further, the first bullet above mentions a hierarchy which references the decomposition of processes into sub-processes and tasks. I have yet to find a book or a Web site that provides useful guidelines on how to decompose processes and a measurable definition of an atomic task or process (one that cannot be further decomposed). So, if you know of any books or Web sites, please post them in a comment or contact me.

The lack of decomposition guidelines was part of my motivation to create this Web site. The other part of my motivation was that I knew of an algebra for design decomposition and could see how it could applied to business processes. Nevertheless, I am open to ways that I might be able to enhance the decomposition provided by the Decomposition Matrix on this site.

I’m now going to modify and expand the Decomposition Matrix to more fully reflect the story in Web Services and Service-Oriented Architectures, The Savvy Manager’s Guide.

First, the input of travel dates and locations is changed to travel dates and customers. In the story, C. R. chooses the dates and customers, not locations. Locations for customers come from the external CRM service used by C. R.’s company. Inputs and outputs for the CRM service are added.

Second, a traveler identification input is added. This identification is used to obtain the traveler’s profile.

Third, requests to customers’ calendaring services for meeting availability are added. These follow the same pattern as airline, car, and hotel services. There is a request for meeting availability that is followed by a meeting reservation request. The meeting availability requests are sent once it is known that there are available flights, hotel rooms, and rental cars. Also, receipt of one or more meeting confirmations in meeting reservation responses is needed before making either a flight reservation or an air/car/hotel reservation. This is because such reservations may have restrictions in order to get the best rate.

Fourth, the output of GPS destinations is added for the rental car service. This appears after all of the reservations since all driving destinations are provided at the same time to the rental car service. Also, this raises the issue of granularity for the first time in this example. Because of the possible volume for a car rental service, that service might ask that GPS destinations be bundled in one service request. It is potentially more efficient to handle one larger request than many smaller requests. So, this example is set up to create single larger requests that provide GPS destinations for the rental car service.

Fifth, a correction is made to the matrix that goes back to Part 1 of this example. In that matrix, the input and output entries for driving directions were incomplete because the driving directions were not provided to the traveler. The revised matrix below has an additional output of traveler’s driving directions (number 16) that occurs concurrently with the “Driving directions response” input and after the inputs for the various reservations responses. The type of modification is likely to occur as you develop a matrix. It is possible to overlook a relationship or to leave out an input or an output. Nevertheless, what often happens is that as you study the matrix and the generated diagram, these errors or omissions come to light. In this case, I noticed the error when I was adding the output for GPS destinations.

Finally, a number of informational outputs are added to update C. R.’s calendar (C. R. is the Traveler in the matrix), C. R.’s spouse’s calendar, and C. R.’s manager’s calendar. Also, the travel plans are saved for possible future reference.

This matrix generates the following diagram. (You can click on this — or any of the other images — for a larger size.)

Starting at the left, further decomposition of the first process, “Obtain travel information,” is shown below. This further decomposition results from adding the inputs and outputs for CRM customer information and the traveler’s profile. (For simplicity, I am not showing the intermediate sub-matrix for each further decomposition shown in this part of the example. Setting up the sub-matrix was described in Part 2.)

The next process, “Check travel availability,” is similar to the process in Part 2 with the same name. Further decomposition of this process is shown below. The difference between this diagram and the one in Part 2 is that the task “Receive travel dates and customers,” in Part 2 was moved to the first process above and renamed “Receive travel information.” Again, this change was necessitated by the addition of the inputs and outputs for CRM customer information and the traveler’s profile.

The further decomposition of the next two processes is a bit confusing. They appear to break up the various aspects of making reservations. The “Reserve flight and/or pkg” process is shown below. The Decomposition Matrix specifies that only flight information is needed before the generation of the “Manager’s trip summary.” This results in this further decomposition.

Therefore, the remaining reservations are in the “Reserve car and hotel” process. That further decomposition is shown below.

This confusing decomposition is an example of why I often describe the use of the Decomposition Matrix as similar to a working with another designer at a whiteboard. You, the designer, might have to make a decision as to what you think is best. For example, you might decide this decomposition is fine because it generates output at the earliest possible point. In this case, when the “Manager’s trip summary” is generated. On the other hand, you might decide you prefer to consolidate the reservation tasks in one process so that it looks like the further decomposition shown below. This merges the “Reserve flight and/or pkg” and “Reserve car and hotel” processes in the first business process diagram in this posting. The remainder of that diagram remains the same.

To force the Decomposition Matrix to generate this diagram, three check marks would need to be added: Input 5 for Outputs 19 and 20, and Input 7 for Output 20.

Previous: Business Process Decomposition, Part 2