How detailed your business process model should be?

Written by Chintan Rajyaguru

Tuesday, 02 October 2007 17:04

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

To monitor the process at runtime and generate several reports
To perform business process analysis and identify services or derive IT architecture
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.

Comments

Add New