I can see why it is assumed that the WebSphere Business Modeler (WBModeler) is a tool for the business users. I can also see why it has to be available on windows platform. What bothers me though is that the tool is not available on Linux or any other platform for that matter. Do technical people or anybody using Linux not need the tool? Well, I certainly did and I didn't want to install windows on vmware just so I can use WBModeler. Neither do I have access to a windows machine to remote desktop into it.

I refused to accept the limitation. So, first I tried to launch installation using launchpad.sh script, which failed right away. Next, I tried to understand what launchpad.bat was doing and followed its steps but that didn't work either. Then I thought, "At the end of the day, WBModeler is just eclipse with some plugins. If I can install it as eclipse, may be I can use it on Linux." So, I decided to use IBM installation manager and make WBModeler a repository from where the installation manager could access the files. I set an eclipse repository in the installation manager by pointing it to the diskTag.inf file in the installation image. As soon as I clicked Install, Bingo! The installation manager recognized that WBModeler Advanced version was available for installation. I installed it right away on my openSUSE 11.1.

But the joy didn't last long. I launched the tool and specified the workspace directory but didn't see all the options in the menu. There were blank spaces in the File > New menu. When I found and launched business modeling project, I got errors that suggested various osgi and eclipse classes were not found. I did some debugging but soon realized that the task of running WBModeler on Linux might be more complex than I originally thought. For now, I have accepted the defeat, uninstalled the tool and hoping and praying that some day it will be available on the Linux platform. If someone has done this successfully, please feel free to drop me a line. In the mean time, I don't expect IBM to make the tool work on Linux. It takes customers not developers for something like this to happen.

A business process is lot like a car. You have to own it and maintain it. A well built business process runs the organization well and causes fewer disruptions. A well maintained business process saves money in the long run.

Organizations just starting with BPM often have the misconception (often unknowingly) that it's an area that allows business processes to be automated and that executing BPM activities is the responsibility of systems folks. These organizations often have business analysts that belong to systems department working with the business partners to model the business process flow. This activity is no different than the typical requirements gathering. Like they gather user-system interaction in form of use cases and business rules requirements in form of rules repository, they capture business process flow in form of process description and BPMN model. This process results in yet another artifact owned and maintained by the systems department. These artifacts are used for process automation and then, they get lost in the pile of papers that are looked up only when the system implementing the business process needs to be changed. This works well if the goal is to simply document the process flow. But BPM is not about just identifying the process flow. It is much more than that.

A successful BPM strategy requires the organizations to stop treating BPM as the requirements gathering activity owned by systems. Going back to the car analogy, business processes must be well built, owned and maintained; and this must be done by the business. IT is a stakeholder in the process of building and maintaining the business processes but the business must define it, own it and maintain it.

This is a very important concept to develop and implement a successful BPM strategy. In my future blog entries, I will explore it in much more detail.

In Business Process Modeling Notation (BPMN), an attached intermediate event is modeled as shown below. It means that the event could occur any time while the task is executing. In the example below, a Timer (or Message or Error etc.) intermediate event could go off while activity Task X is going on. If the event occurs, the process would follow its path and execute Task 2, otherwise it would execute Task 1.

But I wouldn't be writing this blog if the life was so simple. While the BPMN specification isn't explicit, it does indicate that such an intermediate event results in an exception flow (see section 10.2.2 of the specification), which interrupts the normal flow. English translation of this means if the timer goes off, Task 2 will execute, Task X will terminate and Task 1 will not execute. Since the exception flow 'merges' back into the normal flow, Task 3 will execute and so on. Below, I have shown two examples with intermediate events. In the first case the behavior described above would be acceptable but in the second case it wouldn't.

In the first diagram (left) if order cancellation Message is received, the Process Order task should terminate, the normal flow should terminate (Ship Order should never execute) and control should be turned over to the exception flow to execute Cancel Order task - just like it's described in the specification.

In the second diagram (right) however, we don't want to terminate the normal flow. If the Underwrite Application task takes too long and hence interrupted by the timer intermediate event, we would like to Notify Manager but we would also like to continue to underwrite the application and eventually record the decision. If you strictly go by the specification, it doesn't support modeling the second scenario. Industry experts have been asking for non-aborting attached intermediate events.

This strict definition of an attached intermediate event turning the normal flow into an exception flow has never been a problem for me because I chose convention over configuration. Here are some of my recommendations about attached intermediate events:

• Most of the business scenarios at my client require non-aborting attached intermediate events. So, I recommend that by default, attached intermediate events be treated as non-aborting event (I will explain the rationale in a minute)

• If we need an aborting attached intermediate event then we put a note in the model

• An attached intermediate event of type error be treated as aborting intermediate event

These recommendations work well for me because they make the models look consistent. While there is a work around in BPMN to model non-aborting intermediate events, it makes the model complex. Using convention over modeling, I keep the models simple. In most cases (at least for me) the implementation language for business models created in BPMN is BPEL, which does NOT terminate the task or normal flow when attached intermediate event occurs. Only in case of an Error event does BPEL terminates the current task and normal flow (hence the convention described in the bullet points above). So, from the implementation perspective this convention makes sense. While only a few tools generate correct BPEL out of BPMN, I have not seen any tool that generates BPEL that would terminate the normal flow in case of an intermediate event. In a nut shell, while there is a discrepancy between BPMN and BPEL specification, it's not been a problem for me so far.

Now, about updating the specification to allow non-aborting intermediate events. The solution is simple (I hope OMG is listening). BPMN specification defines an attribute called Target for an intermediate event. Specifying a sub-process or a task as a target of an intermediate event means the event is attached to that sub-process or task. I recommend that we introduce another attribute called Abort, which would take the value True or False. The specification could force Abort attribute to be specified every time Target attribute is specified OR it could provide a default value of False for Abort attribute . The specification does do something like that today: When Trigger attribute has value of Timer, Timedate or TimeCycle attribute is required.

If you are using a tool that can generate implementation code with a terminating intermediate event, let me know. In the mean time feel free to use convention until the specification is updated.

I have been writing about business processes for some time now. This is because I am working on an SOA initiative that recognizes the business process layer and wants to perform top-down analysis. A colleague recently asked me about all these BPXX acronyms and what they meant. Let me try to explain them with analogy to UML and Java:

BPM

Business Process Management (BPM) is a field of knowledge encompassing tools and techniques to design and analyze business processes.

BPMN

I have discussed Business Process Modeling Notation (BPMN) in more details here. In a nut shell, BPMN is very similar to UML. It's a pictorial representation of a business process just like UML is a pictorial representation of software. BPMN notation defines pictures (notations) to show a process, task, sub-process, events, message flows and more. What shape in BPMN means what is described in BPMN specification. Like UML, BPMN specification is also owned by OMG.

BPEL

BPEL is to BPMN what Java is to UML. In other words, BPEL is an xml based language that defines runtime behavior of the business process. Like Java code has to be written with correct syntax, BPEL must also be written with correct syntax and like Java, BPEL process can be deployed to a runtime server. Like you can generate Java from UML, you can generate BPEL from BPMN. However, not all tools provide this functionality. And similar to UML, BPMN doesn't have to be deployed as BPEL.

WS-BPEL

This is analogous to various specifications around Java technology. Like JSR 154 is a pdf file containing servlet 2.4 specification, WS-BPEL is a pdf file containing BPEL specification. Like a servlet must conform to JSR 154 specification, a BPEL process conforms to WS-BPEL specification.

BPEL4WS

IBM developed this service orchestration standard and later submitted to OASIS. BPEL4WS has been renamed to WS-BPEL.

In an SOA/BPM initiative, I see business processes being modeled primarily for 3 reasons:

1. To monitor the process at runtime and generate several reports
2. To perform business process analysis and identify services or derive IT architecture
3. To deploy the process in a process runtime and invoke services (service orchestration)

In each case, the level of details included in the model and the granularity of the process will be different. More often than not, you would want to do all the three.

I tend to think of business process models at 3 different levels.

High level model

This is the level business actually cares about. Business doesn't necessarily want to see every possible task and every possible flow within the business process. In fact, if you show any non-technical person a BPMN model of a relatively complex process, he/she may get confused. A high level model of a loan approval process might include high level tasks such as: Create Application, Retrieve Credit Report, Review Application, Accept/Reject Application.

Business is usually only interested in getting runtime information at this level. In fact, if the business wants runtime information around every little task, the process server will end up invoking way too many implementations of those tasks resulting in a poor performance.

Analysis level business process model

You model business processes at detail level when:

• Current business processes are not documented
• You want to analyze the current processes and modify them
• You want to derive IT architecture and identify services using the business process model

When working at this level, you typically identify all the tasks and all possible flows in a process. Depending on your project goals, you define additional information for each task including who performs it, how much time does it take, how much does it cost, what resources are used, what data does the task operate on and more. You tie the business information with various elements in the process model. For example, you may trace use cases and/or rules with tasks in the business process. Your SOA architect will rely on this model heavily.

Deployment level business process model

If a business process has been modeled, it doesn't have to be deployed in a BPEL runtime. Modeling business processes typically means that we have recognized that there is a business process layer, the implementation of this layer may be a BPEL process, a workflow process or something entirely different. Also note that BPEL is still new and evolving. Not all scenarios modeled in the process modeled can be implemented readily using BPEL (see BPMN specification section XYZ for more information). This mismatch between model and runtime typically necessitates creating a runtime model. When BPEL is used, the runtime model is the WS-BPEL compliant xml that can be deployed in a process server. Your SOA architect or integration specialist will work on your business process model to create correct WS-BPEL artifacts.

It is important to note that I am not suggesting always creating 3 models (while that may be necessary in some cases). I am merely stressing the point that business process model may have to evolve and contain different level of details for different audience.