Just as software developers build better
applications through modeling, business analysts improve business
processes by creating models of process flow. In this article we'll
look at how IBM WebSphere Business Modeler helps turn business
processes into models that can be analyzed, simulated, refactored, and
ultimately turned into software applications.
Business Modeling 101
Business process modeling documents
the tasks and workflows of a business process. The first step is to
determine the activities, business items, and resources required to
execute the process. WebSphere Business Modeler requires little
technical skill, so domain knowledge can easily be turned into a
detailed process model.
A process model looks like a flowchart. It describes the sequence of
steps in a business process (whether they are performed by people or
automated systems). Models are visually described as a sequence of
tasks and decisions linked by connectors (see Figure 1).
A model can contain multiple branching paths based on decisions made
during process execution. It also describes the resources available for
use in the model and the cost of using those resources.
WebSphere Business Modeler also provides a variety of analysis
functions that extract targeted information from one or more elements
within the model (static analysis) or from a simulation of the model
To make the most of WebSphere Business Modeler it's important to
understand the most commonly used process model elements. These are
tasks, decisions, and classifiers.
Tasks are the basic building blocks representing
activities in a process model. Each task performs some function.
Visually, a task represents the lowest level of work you can portray in
a process (see Figure 2).
Tasks are atomic actions, in contrast to processes, which may be
decomposed into another flow. Cost and revenue estimates can be
associated with tasks so that dynamic simulation of the process
generates income and expense projections.
A decision routes inputs to one of several
alternative outgoing paths. You can think of a decision as a question
that determines the exact set of activities during the execution of a
process. Questions might include: "What type of order?", "How will the
order be shipped?", and "How will the customer pay?"
There are two types of decisions: simple decisions and multiple-choice decisions (see Figure 3).
A simple decision has one incoming branch with one input and two
outgoing branches with one output each. When the process is running,
the process flow takes one outgoing branch if a certain condition is
true and the other branch if the same condition is false. A
multiple-choice decision has one incoming branch and multiple outgoing
branches. Each outgoing branch has an associated condition (that is, an
expression that evaluates to either true or false). This condition
determines which branch will be selected when the process runs.
Classifiers categorize process elements for analysis purposes.
Pre-defined classifiers are provided or you can define your own. Colors
can be associated with elements that have specific classifier values,
enabling you to see these values at a glance (see Figure 4).
You can perform static analysis to see the association between
classifier values and model elements in the process. After running a
simulation, you can perform dynamic analysis to find the total cost or
duration of elements with a specific classifier value.
Every process model needs a corresponding
data model. Data models include the business items, which are the
documents, work products, or commodities that are used in the process.
Examples of business items are manufacturing orders, mother boards,
power supplies, and memory chips (in a PC assembly process), itinerary
and customer information records (in a trip reservation process), and
passengers (in a transportation process).
Business items are used within a process to model the objects that
are acted on by the tasks and decisions. In addition, you can model a
specific instance of a business item. For example, if you have defined
a business item called Cash Register, you can model individual cash
registers (such as Cash Register #7) as business item instances.
To model the flow of data from task to task, you associate business
items or business item instances with connections between elements in
the process model (see Figure 5).
A resource model is required to accurately model business processes.
Resource models represent the people, equipment, or material used to
perform a project or a task. Resources are not the same as business
items. The objects that undergo changes and are passed from one process
step to the next should be modeled as business items, whereas the
things that are performing the work or are required prerequisites, such
as machines, fuel, vehicles, or skilled personnel, should be modeled as
Each resource is a particular occurrence or example of a resource
definition. A resource definition is a set of similar characteristics
shared by resources of the same type. If you have modeled a resource
definition called Computer, then some examples of resources might be
"Main server," "Web server," and "Test machine 1."
Roles, timetables, and costs add additional characteristics to
resources. For example, an Employee resource could have the role of
Customer Service Representative, Supervisor, or Manager. The Employee
resource may only be available on a certain timetable (say, Monday to
Friday), and each unit of the Employee's time costs $11.50 per hour (see Figure 6).
Now that you've setup a model, its time to delve into WebSphere
Business Modeler's analysis capabilities. The tool provides a variety
of analysis functions relating to models in their static state. These
analysis functions are in addition to dynamic analysis functions, which
return information based on the results of running a process
There are simply too many static analysis tools to describe in this
space. Some examples are: analyzing activities unable to start (due to
unavailable resources, empty input criteria, or inputs that lack
connections); analyzing activity resource and role leveling (shows the
allocated and available roles and resources for each activity in a
process); analyzing activity cost and duration (shows the cost and
duration of cost of each activity in a process); and analyzing
qualified resources for a role (shows the resources that are qualified
to perform a role defined in the model).
Simulate the Future
A process simulation is a simulation
of a real world business process. The business process may be modeled
on an existing business process ("as-is") or one that is being planned
for the future ("to-be"). Simulation allows you to assess the
performance of the process, generate statistics about its execution,
and pinpoint potential areas of improvement and optimization.
Simulation enables organizations to observe how a process will
perform in response to variations of inputs to the process, just as in
a real-life work environment. Simulation also provides the ability to
vary process input volume over time by adjusting resources and current
When you run a simulation, you can watch an animated view of the process in operation (see Figure 7).
The animation shows the movement of tokens from the inputs of the
process and between activities in the process. A token represents a
unit of work that is received by a process and transferred between
different activities in the process flow.
Dynamic analysis lets you extract targeted information based on the
results of your process simulations. WebSphere Business Modeler
supports four primary types of dynamic analyses:
- Aggregated - Determines information about activities and resources used in all process instances generated during a simulation.
- Process instance - Performs a summary analysis to show
process results for activities within a particular instance of a
process that is created during a simulation run.
- Process cases analysis - Shows statistics produced by all process cases in a simulation.
- Process comparison - Compares the weighted average analysis
results for two simulated processes that use the same input parameters.
Each type of dynamic analysis offers numerous reports that can be generated at the click of a button.
When you're satisfied with the business process model, it is often
turned into a software application. Implementation starts by exporting
the process definition to a Web Services Business Process Execution
Language (WS-BPEL) file, and then specifying key performance indicators
that should be used to monitor the process once it is in production.
The WS-BPEL file can then be turned into a UML model using Rational
Software Architect. Developers can then generate Java components
directly from the UML, which integration developers can integrate with
new and existing applications using WebSphere Integration Developer.
After deployment managers and business analysts can use WebSphere
Business Monitor to track the performance of business processes. So
there you have it. WebSphere Business Modeler is the crucial first step
in business process automation. It lets you build detailed models of
complex business processes with ease. These models can be optimized
through analysis and simulation, and eventually turned into software
applications by making use of the WebSphere family of business