|
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.
| 
