As preparation for returning to regular commentary, I have:

• Updated the free online articles on my Web Services and Service-Oriented Architectures website and added articles related to Cloud Computing. See www.service-architecture.com/articles/.
• Revised my 2003 Savvy Manager’s Guide on Web Services and Service-Oriented Architectures. This is a book to give to your manager and/or your manager’s manager. It will help them better understand Web Services, service-oriented architecture (SOA), and Cloud Computing. The revised edition is thoroughly updated and weaves Cloud Computing into the discussion of Web Services and SOA. It shows how Cloud Computing actually intensifies forces driving the adoption of SOA.  More on the revised edition can be found at www.service-architecture.com. Scroll down towards the bottom of the page.

The Iridium system includes over 66 low-earth-orbit satellites. That low orbit makes it possible to use low-power devices with a small antenna on Earth (satellite phones). Low orbit also means that Iridium satellites orbit the earth in less than 90 minutes. So during a typical telephone conversation, messages must be dynamically rerouted from one satellite to another. The Objectivity/DB ODBMS is used in the Iridium base stations for the message routing as well as network management. The developers described the Iridium switching problem as the equivalent to re-configuring an ATM switch every 4 minutes.

My understanding is that the part of the Iridium system that uses Objectivity/DB had nothing to do with the collision. Nevertheless, as it turns out, a new system is in the works to manage collision avoidance in space that uses Objectivity/DB as well. It is the Space High Accuracy Catalog (SHAC) project that will be deployed by Lockheed and used by the Joint Space Operations Center at the Vandenberg Air Force Base in California. The new system will provide improved collision avoidance and real-time tracking of hundreds of thousands of objects and debris in space. The goal is that decisions about spacecraft placement and collision avoidance can be made in seconds, rather than hours or days.

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.

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.

The inputs from these legacy systems are shown below at the left in the Decomposition Matrix. These inputs could be from existing packaged software, custom legacy systems, legacy databases, or software as a service (SaaS) on the Internet, etc. The exact nature of the legacy sources for the inputs does not change this example.

The outputs shown from the services in the Decomposition Matrix are just some of the possibilities. The outputs needed would vary based the needs of the particular business. Since this is a generic example, I’ve chosen to show enough of the possible outputs to create a useful example.

The initial decomposition is shown below.

The same diagram is shown below after some minor rearranging along with labeling the processes and the data flows.

Note that the label on the data flow from a given process to another process is the same as the label on the external flow for that process. Also note that some top-level processes have multiple outputs. This indicates that the service input parameters will need the ability to specify sorting the XML output and/or selecting which XML tags should be included in the output. Such input parameters are not shown in DFDs, but they will be needed when you design the services. What is shown in this DFD –  and any DFD — is the flow of data, but not the control provided by input parameters.

I hope you found this Decomposition Matrix example useful. Also, I welcome any comments or suggestions that might improve it. Click on “Contact” in the menu bar at the top of the page to send me your comment or suggestion.

1. Sometimes sub-processes are accumulated too aggressively.
2. Sometimes data flow diagrams can cause a Java run-time error when the graphics display.

Both defects are being investigated and will be  repaired.