Oracle BPM Life-cycle and Modeling best practices

2
3

4
5
6

Introduction ......................................................................................................................... 2
1.1
Overview....................................................................................................................................................
1.2
Oracle BPM Solution .................................................................................................................................
1.2.1 Oracle Business Process Analysis Suite ................................................................... 3
1.2.2 Oracle SOA Suite....................................................................................................... 4
Typical process life cycle.................................................................................................... 6
Modeling Levels and Model Types................................................................................... 14
3.1
Modeling beyond processes the ARIS House concept ..........................................................................
3.2
Modeling Levels.........................................................................................................................................
3.2.1 Level 0 Process Catalog....................................................................................... 15
3.2.2 Level 1 Process Map ............................................................................................ 16
3.2.3 Level 2 Detailed Process Flow ............................................................................. 18
3.2.4 Level 3 Task Level Processes .............................................................................. 19
3.2.5 Level 4 UI flow, composition of business services ............................................... 19
Modeling Roles & Organization ........................................................................................ 21
Modeling Business Services............................................................................................. 22
Modeling detailed process flow ........................................................................................ 24
6.1
Simple Flow ...............................................................................................................................................
6.2
Conditional Branching ...............................................................................................................................
6.2.1 Mutually exclusive conditional branching................................................................. 25
6.2.2 Mutually Inclusive Conditional Gateway .................................................................. 26
6.2.3 Parallel Paths........................................................................................................... 26
6.3
Conditional Merging...................................................................................................................................
6.3.1 Merging mutually exclusive paths............................................................................ 27
6.3.2 Merging mutually inclusive paths............................................................................. 27
6.3.3 Parallel joins............................................................................................................. 28
6.4
Process Hierarchy .....................................................................................................................................
6.5
Loops .........................................................................................................................................................
6.6
Request-response scenarios.....................................................................................................................
6.7
Modeling Exception Scenarios ..................................................................................................................
6.8
Handling Business transactions and compensations................................................................................
Other Modeling best practices.......................................................................................... 33
7.1.1 Filters ....................................................................................................................... 33
7.1.2 Access Control......................................................................................................... 33
7.1.3 Clean up your database........................................................................................... 33

1 Introduction
1.1 Overview
The purpose of this paper is to provide guidelines and best practices around the creation of
business process models using the Oracle Business Process Analysis Suite (Oracle BPA Suite).
These models automatically get realized as close to complete implementation models that can
then be deployed on top of the Process Execution component of Oracle Business Process
Management solution. The modeling of process artifacts and the role of the BPA Suite in the
Oracle BPM life cycle is the focus of this paper. A case study has been provided in the end to
highlight the different modeling patterns. This is intended to be a living document and will
continuously be updated as the Oracle BPM solution evolves. The audience of this paper are
business analysts and business process modelers.
A business process is a set of coordinated tasks and activities, involving both human and
system interactions, that will lead to accomplishing a set of specific organizational goals. A
business process produces outputs and consumes inputs and is constrained by business policies
and business rules. A business process is defined by the following charectestics:

Accomplishes a set of goals

Creates some value for customers internal and external
Consumes some input data and produces some output data. Data can be structured or
unstructured.
Uses resources could be system (services, applications) or human
Produces value to the customer in the form of products or services

Business process management (BPM) is the modeling, execution, automation and

management of business processes. In the past, the primary BPM business drivers have been
process automation, integration and visibility to increase productivity and reduce operational
costs. Increasingly, competitive advantage and hence innovation of a business depends on the
ability to excel in key business processes. Next Generation BPM is all about business innovation
that will help a business compete effectively in the global marketplace.
Business Process Modeling is the creation and analysis of business process models and
related artifacts. It is the first step in the process life cycle. The Business Process Model is a
graphical representation of a business process. It describes the step-by-step sequence of tasks
that have to be performed from initiation to completion. The purpose of a well-defined process
map is to graphically illustrate the essence of the business process. By simply looking at it, you
should be able to determine the purpose and overall flow of the process. Process Models are
useful for communicating business requirements to IT and for analyzing future improvements
before they are translated to implementation.
Businesses of today are expected to be agile and flexible to respond to changing market
conditions. IT is no longer perceived as a support system and there is a strong focus now on IT to
show business value. IT is expected to be flexible and respond quickly to constantly changing
business requirements. This requires that the process model not be just a business requirements
specification meant for one-time hand off from business to IT but rather a continuous view of the
implementation. Changes to business process model must immediately be reflected in the
implementation and any changes in implementation that affect the business flow must be
reflected back in the business process model. Traditionally tools such as Visio, Powerpoint,

spread sheets and other forms of documentation were used to document and communicate
business process models and business requirements to IT. These tools are at best static
representations of business requirements and hence are not suited for rapid prototyping .
Miscommunication between business and IT people can lead to projects that might seem
successful from an IT-delivery viewpoint, but are considered business failures as they fail to show
business value. Oracle has addressed this issue by innovatively integrating the Oracle BPA Suite
the modeling tool with Oracle SOA Suite - the execution and monitoring environment. The
modeling and the IT IDE are integrated through a shared meta model and this unique valuegenerating approach enables both business and IT to work parallely and yet be in sync with each
other.
Automatic translation of business requirements in to BPEL processes: Once
business decides that a process model is ready for sharing, IT can access and edit it
from within their environment. Rich process definitions get generated from the model
promoting rapid and meaningful process automation and reducing the strategy to
implementation gap by translating the business requirements directly in to almost ready
to deploy BPEL process definitions.
Alignment of business model and IT process: The executable process is always in
lock step with the business process model. Business users can create and change
business models in the Oracle Business Process Analysis Suite while IT users can view
and modify these processes in parallel using the Process Designer component of the
Oracle SOA Suite.
Empowerment of both Business and IT: Business level changes can automatically be
merged with any changes done by the developers to ensure that the implemented
process is inline with the expectations of the business users. Further, IT can make
changes to the business flow that then become visible in the business tool and these
changes can be selectively incorporated to produce new versions of the business
process model.

1.2 Oracle BPM Solution

Oracle BPM consists of the following products:

1.2.1 Oracle Business Process Analysis Suite

The Oracle Business Process Analysis Suite (Oracle BPA Suite for short) is a sophisticated tool
for modeling and analysis of business process models. It consists of the following components:

Oracle Business Process Architect is the modeling and simulation component. . It

provides a rich and intuitive graphical modeling environment tailored to business users
for defining process maps and detailed process flows consisting of both human,
automated and rule steps that spans across organizational boundaries. In addition to
business process modeling, it supports data modeling (rich support for UML models),
organizational modeling, IT system landscapes, impact analysis and rich report
generation. It can be used to analyze as-is and future processes by running simulations
based on different scenarios. Simulations can be used to perform throughput analysis,
activity based costing and average cycle time analysis. It is a diagnostic tool for
uncovering critical paths, resource bottlenecks (both human as well as systems) and
structural problems with the process. Through simulation, you can quickly determine the
performance of the process under certain hypothetical conditions.

The Architect is a versatile tool and can be used by business users of varying skill sets.
The tool provides a pre-defined set of perspectives also known as filters and easily allows
creating new perspectives as well.

Oracle Business Process Publisher is used for publishing Business Process Models to
a process portal and offers role-based and secure access to process content. This
fosters collaboration among the various team members and promotes sharing and review
of process models on an enterprise wide scale.

Oracle Business Process Repository and Oracle Business Process Repository

Server Oracle Business Process Repository is used for storing process metadata. The
Oracle Business Process Repository Server is used for providing concurrent access to
the Business Repository. It promotes collaborative development of process models,
featuring role based access, versioning, check-in/check-out, and load balancing.

Benefits
Oracle BPA Suite provides the following benefits:

Understand and document existing processes.

Promotes reuse of best practices and ensures that there is consistency in process
initiatives across the enterprise.
The process diagram is more than a static drawing. The process diagram is dynamic and
can be changed in response to changing business conditions.
Perform impact analysis upon changes to existing processes and resources.
Determine resource bottlenecks and optimize business processes via simulation.
Promotes rapid development by meaningful and automatic translation of business
process models in to executable BPEL model.
Collaborate with different business stakeholders via the process portal
Eliminate business-IT gap through seamless round-trip integration with the execution
environment. Process model in BPA Suite becomes the communication tool between
business and IT.
Empower both business and IT users : The tool is verstaile enough to cater to the varying
skill sets of the different types of business users and can be configured to present
different perspectives to different users.

1.2.2 Oracle SOA Suite

Oracle SOA Suite is the execution and monitoring platform for the Oracle BPM solution.
Oracle BPEL Process Designer (Implement & deploy) is used for developing and
deploying executable BPEL based processes. It integrates with the Oracle Business
Process Repository and uses the business process models developed in Oracle
Business Process Architect as a starting point to generate rich BPEL artifacts. It is used
to develop services and orchestrate services into composite applications and business
processes. The tool can be used to test the BPEL processes and deploy the same on the
execution platform the Oracle BPEL Process Manager.

Oracle BPEL Process Manager (Execute) Oracle BPEL Process Manager is the
Process Execution engine for the Oracle BPM solution. It provides a comprehensive,
standards-based and easy to use solution for creating, deploying and managing
composite business processes with content, automated and human workflow steps all in
a Service Oriented architecture.Its native support for standards such as BPEL, XML,
XSLT, XPATH, JMS, JCA and Web Services makes this an ideal solution for creating
integrated business processes that are truly portable across platforms. The Oracle BPEL
Process Manager supports the following:

Human interactions:
The Oracle Process execution component has comprehensive support for human
participation in end-to-end processes. The human workflow features include a rich rolebased customizable work-list application, out of the box workflow patterns for
sophisticated routing and assignment, extensive support notifications and escalations
policies, and easy to use declarative modeling. The Task services created are reusable
across multiple business processes as well. The Work-list application can generate
various reports to monitor and optimize work execution. Reports may include work items
needing attention, current work loads and distributions, cycle times, and productivity.
Reports include data based on the user profile: supervisor reports include data for their
staff, etc. In addition to routing modeled in the process diagram, Oracle BPM supports
routing patterns suited for human to human workflows. Such support includes the ability
of participants to invite other participants, request information from other participants,
delegate or reassign tasks to other participants. These capabilities available at run time
may be restricted in the process model, if appropriate

Content interactions:
Oracle BPM enables both structured and unstructured interactions between human
participants. Participants may add comments and attachments to a Task that are then
available to all other participants. Documents in Content Management system may also
be used for structured communication. Oracle BPM also brings in discussion forums and
other unstructured communication such as chat, voip, etc.
System interactions:
The Oracle Process execution component has comprehensive support for system
integration in end-to-end processes. It provides a plug-and-play, standard-based
infrastructure for exposing systems as services and orchestrating these services into
easy-to-change process flows. It can be used to deliver both composite applications (web
service orchestration, J2EE process flows) and data integration applications via 300+
connectivity solutions and integrates with Partners via B2B connectors.

Oracle Business Activity Monitoring (Monitor) to monitor services and disparate

events and provide real-time visibility into the state of the enterprise, business processes,
people, and systems. The BAM component gives business executives the ability to
monitor service level agreements (SLAs) across various services and business
processes in the enterprise, to correlate key performance indicators (KPIs) down to the
actual business process themselves and most importantly change the business
processes much more quickly and efficiently to get more efficient or to take corrective
action if the business environment changes. Business users can quickly create highly
effective dashboards and reports showing critical business measures and KPIs that
update in real time with capability to drill into detailed information all with a few clicks.
The user can also model alert conditions and rules that can be used to alert as the
conditions occur.

Oracle Business Rules, a rule design tool and inference engine to capture business
policies. The Business Rules component of the Oracle BPM Platform is a highperformance inference based Rules Engine and enables business rules to be explicitly
specified and managed by business users in a declarative fashion (that is statements vs.
procedural logic). The Rules Engine is based on industry standard Rete algorithm
(http://en.wikipedia.org/wiki/Rete_algorithm).

2 Typical process life cycle

The BPM lifecycle consists of 3 distinct phases:
Business Process Analysis: Capture, model, simulate and analyze business process models to
reduce risk and maximize efficiency.
Business Process Execution : Implement, deploy and test business process
Business Process Monitoring: Manage processes, monitor business metrics, analyze
performance and handle alerts and exceptions.
Finally, for continuous buisness process improvement, the business metrics collected in the
monitoring phase has to be fed back in to the Business analysis phase for further refinements to
the process models.

Oracle BPM includes best-in-breed tools for both business and IT, with unparalleled
depth in both areas. The Oracle BPA Suite is the modeling tool targeted at business users and
Oracle SOA Suite is the execution and monitoring platform targeted at IT developers.
Traditionally, such attempts to bring together best-in-breed tools for analysts and IT have been
plagued by broken round-tripping between modeling and implementation. The process model is
not just a business requirements specification meant for one-time hand off from business to IT.
The process models change vividly along with the frequently changing business requirements
and the business process model must be a continuous view of the implementation. Changes to
business process model must immediately be reflected in the implementation and any changes in
implementation that affect the business flow must be reflected back in the business process
model. Oracle has defined a shared meta-model between the analyst tooling and developer
tooling named Process Blueprint for synchronization of business and IT models throughout the
business process life-cycle . This unique approach enables both business and IT to work off a
shared process definition.

BPM is a journey that starts with baby steps. It demands maturity within the company to
handle process evaluation and evolution while keeping up with the demands of the day-to-day.

1. Identify strategic business goals

Identify high-level objectives and goals such as vision, mission statement, business direction for
the organization. Process goals and metrics will be derived from these high-level objectives down
the road.
2. Identify the business process for the BPM pilot project
Identify the 5-10 key business processes that are critical to the overall success of the
organiation. You can even create a thin model to capture the core processes in your organization.
From here you can narrow down your focus to a specific process. Start with a simple process that
has a well-defined business problem and is relatively straight-forward (mostly human steps
involving hand-offs, simple approvals and exception handling, require integration to systems
which have well-defined business services). The goal of the pilot project must be aligned with the
strategic goal of the enterprise. The success of the pilot project must be able to justify the
enterprise wide BPM initiative and the time spent on a pilot project should not be more than 3-6
months. It is imperative to do tight scoping of the pilot project and document the business case
before commencing on the project. Pick the project that has a low level of maturity and whose
reach is confined to few departments. Processes than span multi-departments, multi-geographic
locations and have multiple touch points are more prone to scope creep, are difficult to complete
within 3-6 months and have increased project risks and delays. At the same time, ensure that the
BPM pilot project brings out clear benefits and produces measurable impacts. Once the first few
BPM projects have completed with measurable success and have received executive blessing,
the foot print of BPM can slowly be increased to span the entire enterprise.

3. Identify stakeholders for the BPM project

The stakeholders for the BPM project will usually comprise of departmental subject experts,
the line of business owner, the business users who are the day to day users of the business
process and associated IT developers. It is key to establish a process owner to manage the
processes in the critical areas of improvement, boundary management, metrics, collaboration and
advocacy. The process owner coordinates the functions and activities at all levels of the process
and has the authority and ability to makes changes to the process. He or she is both responsible
and accountable for its outcome. It is critical that the organization appoint or hire a BPM process
architect who understands both business requirements and technical solutions. A BPM project
might require organizational changes to reduce handoffs in the process.

4. Modeling the as-is process

Once a process is identified, it needs to be documented accurately.This is an important
step and often determines the success of the implementation. The business process touches
various systems, people and content across multiple organizations and might involve external
entities such as customers, partners and suppliers. Furthermore, business processes are not flat
and are hierarchical in nature and there are layers of processes in an organization.
Business Analyst designs business process models by collaborating with the different
stakeholders such as business users and line of business owner to capture different aspects of a
process.

Once processes are broken into activities, each activity needs to be taken up in detail,
defining the 'role' that will execute the action, the 'input data(s)' and output data(s) associated
with the activity, whether the data will be manually entered or electronically picked up. The
following aspects are captured at the detailed process level:

Simple graphical tool such as Visio provides a static representation of a business process
and does not promote reuse. The Business Architect component of the Oracle BPA Suite
provides a graphical tool for capturing business processes. The Business Architect provides
a shared understanding of business processes, encourages a common and well understood
process vocabulary and promotes reuse and validation of process artifacts. In addition, the
Architect can be used in the analysis and simulation of business processes to identify
potential problems before the implementation of the models. The Business Architect can be
used to capture the following aspects of a business process
Process flow: sequence of activities from start to end along with their interdependencies
and inter-relationships.
Activity description : Define the various steps in the process, human (data manually
entered) versus system (data electronically picked up)
Forms : Business user interfaces and page flows.
Data flow: inputs and outputs for each of the activity mapped as part of activity flow.
Business rules: business policies and conditions governing the flow of business process
Participants: A person, a group of persons, or a system who participate in the activities
Message flow: messages sent to and received from other processes
Simulation : parameters such as processing time, cost and resource allocation for the
various activities
Business Exceptions and Alternative tasks: Business Exceptions are created when
processes break and if not addressed, exceptions will reduce operational profitability and
can become obstacles to organizations realizing their vision of fast, efficient error-free
processes. Hence it is key to model the alternative tasks that get triggered when
business exceptions occur in the process.
As you drill down in to the different layers of the business process, you develop a much
deeper understanding of the operation of the end to end business process . At the same time, IT
gains a more sophisticated understanding of the business processes they are supporting.In
addition, business managers develop a better understanding of how technologies can support
their needs,and this in turn increases their abilities to suggest targeted changes that better
supports their needs.
Note : The Oracle BPA Suite includes a business repository for storing the process content.
Multiple users can access and work concurrently on the process content and simultaneous
access of several users to the same model is provided via implicit check-in and checkout
capabilities.

7. Simulation and Analysis of As-is process

Modeling is followed by simulation and analysis of the models in order to optimize the
business process for reduced risk and increased flexibility. Simulation and Analysis is usually
done by a sophisiticated business analyst to produce innovative and optimal business process
models. With Simulation, you can measure current performance for as-is models by using
historical or real-time operational data for cost and time. You can also analyze what-if scenarios.
The time parameters can be either constant or expressed as a statistical distribution. In addition
to cost and time parameters for each activity, the simulation allows specifying probability for the
different process paths as well as rate at which the instances are expected. The simulation
component can also be used to perform role-based simulation and determine the utilization rate
for the role across a set of business processes. Animated and graphical simulation assist the
business user to determine the following:

average cycle time average time calculated across a set of instances

throughout analysis number of instances processed in a given time
activity based costing total money spent in producing and maintaining a
product/service
critical path path that takes the longest time
weak point task at which the instances gets queued up due to resource contention.
Resource utilization

5. Publish & Review Process Models

The business process models meant for review can be published to a secure design-time
portal. The design-time portal provides role-based access to process content (including
simulation results) to the business community distributed across different geographic locations.
The diffferent business stake holders can review and provide feedback on the process content
and the business analyst incorporates these feedbacks back in the process model.

6. Sharing business models with IT

The business process models are abstract and have to be implemented before they can
be realized.In the Oracle BPM lifecycle, the business process models are not just meant for
documentation purposes, but also is the starting point for implementation. Once business decides
that a specific version of the process model is ready for implementation, a corresponding Process
Blueprint is generated inside the Architect and saved in the Business Process Repository. The IT
developer can access these Blueprints by connecting to the Business Repository within the IT
tool and uses it as a starting point to create executable BPEL model. The IT developer is
presented with two views inside the Oracle BPEL Process Designer: the Blueprint view
showcasing the BPMN based business process and the BPEL view showcasing the executable
BPEL model. BPEL artifacts get automatically generated from the Blueprint promoting rapid and
meaningful process automation and reducing the strategy to implementation gap by translating
the business requirements directly in to almost ready to deploy BPEL process definitions. The IT
developer can then complete and deploy the BPEL model on top of the Oracle BPEL Process
Execution engine.

7. Continuous process development

The sharing of Business Process Model with the IT developer is not a one time hand-off
but rather iterative in nature. Business can continuously refine and enrich the process models
while at the same time preserving business-IT alignment via the shared metadata Process
Blueprint. The executable process is always in lock step with the business process model
throughout the process life cycle. The IT developer gets real-time alerts upon creation of new
versions of the Process Blueprint and can view and modify these processes in parallel using the
BPEL Process Designer component of the Oracle SOA Suite. Business level changes can
automatically be merged with any changes done by the developers to ensure that the
implemented process is inline with the expectations of the business users. Meaningful
implementation work done by the IT is preserved during the merge process promoting rapid
development and prototyping. In addition, IT developer can make changes to the buisness flow
inside the Blueprint view and these in turn gets reflected in the Business Architect tool when the
executable BPEL model is saved to the Business Repository. Business user can review these
changes and incorporate them in to the business process model to produce a newer version.
8. Deploy and test
The IT developer deploys and test the executable processes on top of the Oracle BPEL
Process Manager. The Oracle SOA platform enables automated testing of executable processes
(derived from the process models) by simulating services, providing code coverage analysis and
supporting assert activities.
9. Monitor and Manage
The deployed and running processes can be managed using Oracle Application Server
Control and monitored using Oracle BAM. Oracle BAM provides real-time visibility and captures
business metrics in real-time from business processes, systems and other sources to gain
visibility and analyze performance. This gives business executives the ability to constantly
measure actual performance, monitor service level agreements (SLAs) across various services

and business processes in the enterprise. The tool allows correlation of the key performance
indicators (KPIs) with the option of drilling down to the actual business process themselves if
desired. Business managers can understand process bottlenecks and process delays very
effectively using dashboards and can take corrective action if the business environment changes.

10. Continuous process improvements

Finally, for continuous business process improvement, the real-time business metrics can
be pumped back into the model for further optimization leading to continuous business process
optimization. This enables business managers to appropriately oversee and most importantly
change the business processes much more quickly and efficiently to drive business success. The
Oracle BPM drives innovation by simulation of business processes and models before
implementation to determine success. Real-time process metrics collected from BAM can be fed
in to the simulation component to provide feedback loop from business process execution and
monitoring environment to the design time simulation environment for improving and optimizing
processes on a continual basis.

11. Establish BPM center of excellence

To support the BPM initiative at the enterprise level, the organization must align its business
analysts with process owners and it is imperative to establish a BPM center of excellence. This
group is responsible for establishing the BPM methodology and best practices, for settling
arguments, for identifying BPM projects, for education and training of staff. The BPM center of
excellence needs a committed executive sponsor and its often necessary to involve stakeholders
such as CEO, COO or CFO. The BPM center of excellence will have stakeholders from both
business and IT usually visionaries who have bought in to the benefits of BPM and the power of
a process-oriented enterprise.

3 Modeling Levels and Model Types

3.1 Modeling beyond processes the ARIS House concept
This is a simple yet powerful modeling concept that takes a holistic view of process design.
Process artifacts are much more than processes. Processes are linked and have relationships
with organizational units, data, services, applications, IT systems and business purpose such as
objectives, KPIs, risks. In addition the Business Architect can be used to capture process artifacts
such as risks and controls, objectives, products and services. All of this information is maintained
ina single enterprise repository that enables performing impact analysis if there are any changes
to any process artifact. The ARIS House shown in the below figure captures this concept. At the
center of the ARIS House are processes and the pillars as well as the roof of the house represent
different views. The roof represents the organization view basically the people, roles,
organization units that are responsible/act on the human steps in the process. The left pillar
represent the data both structured and unstructured that are produced and consumed by the
processes. The right pillar represents the business services, application systems and IT systems
that the automated steps of the process interfaces with. The base represents the
products/services produced by the process. All process artifacts are maintained in a common
repository, so you can see the enterprise impact of changing any single element.

The Oracle BPA Suite offers different types of models to capture the different process
artifacts and their relationships. There are about 200+ models and each model type comes with
its pre-defined symbols, diagram types and relationships that have business connotation. This
might seem daunting but the tool can be greatly dumbed down using Filters. Filters allow the
users to select the model types, the objects within those model types as well as the possible
relationships between those modeling objects. The tool comes with pre-defined Filters and the
Oracle BPA Filter is the recommended filter for the Oracle BPM lifecycle. It is also the default
filter.

3.2 Modeling Levels

There are different levels in a process hierarchy depending on the type of information
specified at each level. The hierarchy provides a sensible and manageable structure.

3.2.1 Level 0 Process Catalog

A Process catalog model captures the list of processes that make up the enterprise. The
Value Added Chain model type can be used to represent the Process Catalog. Examples of
processes are order to cash, procure to pay and fulfillment. The following figure shows a Process
Catalog generated from a VACD.

3.2.2 Level 1 Process Map

The Process Map consists of key process steps for a specific business process linked
roughly in the order in which they will be executed. It is a high-level process flow and is not a
detailed process flow. It represents the value chain of functionally independent activities and
should show high-level cross-business unit activities. You can use either the VACD model type or
the Event Process Chain (EPC) model type for representing the Process Map. At this level, you
can also represent details such as organization that carry out these functions and the data and
products that these functions produce and consume. You can also associate business artifacts
such as risk and controls, and objectives at this level.
The Process Catalog and Process Map are conceptual levels and not mandatory. They
however help in drilling down to detailed process flows as well as to capture business artifacts
such as risk and controls, objectives and products and services. The below figure shows a
Process Map generated from a VACD.

Guideline: Consolidate functionally related activities in to a single activity. The below figure
illustrates this.

You can specify goals and objectives and associate them with the processes using the
Objective diagram model type. Objective diagram is a model type that is used to represent the
objectives in a hierarchical fashion. Following figure shows an Objective diagram model for the
Global Company Quote to cash process.

You can also capture risks and controls associated with a process using a Business
controls diagram model type. The following figure shows an example of risk and control model
with swinlanes representating different perspectives.

3.2.3 Level 2 Detailed Process Flow

The detailed business process flows are decomposition of individual activities in the level-1
process. The process steps are linked in the order in which they will proceed. BPMN is
recommended for capturing detailed process flows. Following figure shows a detailed
process flow expressed in BPMN.

Guideline: Keep the level of abstraction high in the main process. For example, the Order
Fulfillment process could have been modeled as:

But it is better represented as:

3.2.4 Level 3 Task Level Processes

Some of the process steps in the main process can decompose in to sub-processes. When a
parent process calls a sub-process, a new incident of a sub-process is invoked in response. Data
from the parent process is passed to the subprocess that uses it for routing and decision-making.
When the sub-process is complete, data from the sub-process is returned to the parent process.
Sub-processes can be created for one of the many following reasons:

One process may need to invoke another process owned by a different organization.
A business process may simply be too big and hence it may be necessary to chunk or
break up a complex process into manageable sub-processes.
Process logic that is common across processes can be incorporated in to a sub-process
to promote reuse.

The sub-processes need to be linked together such that the output of the one becomes the input
of the other. Using a combination of top-down and bottom-up approaches, map out the entire end
to end process in detail. Steps in the main process drill down in to many levels of child processes
(sub-processes). Hence you could have multiple levels of process hierarchy.

3.2.5 Level 4 UI flow, composition of business services

There could also be a level 4 that captures page flows, screen design and models that capture
granular service orchestration flows.

The below figure shows the Modeling Pyramid and the model types recommended for the
different levels.

The conceptual levels do not get realized as implementation flows and they lead to more detailed
flows. The detailed process flows gets realized as implementation processes.

4 Modeling Roles & Organization

Roles & organizational models enable to define process participants (task performers) and
owners for the human steps of a process. Simple approach to defining process participants would
be to create a Person Type object to represent the different roles.

You can also create an organizational chart using the Organizational Chart model type.
You can design very rough overview models or detailed models depending on what you intend to
derive from this exercise. The Organizational chart model type allows you to capture positions,
persons, person type (role), group, organizational units as well as relationships among yhese
objects. The following figure shows a detailed Organizational chart.

5 Modeling Business Services

Business processes consists of both automated and human steps. The automated steps
involve some kind of system integration and Business Services capture the requirements
and specifications for interfacing with the system. Business Services bridge the semantic
gap between business requirements and the architecture of IT solutions that are intended
to meet them. This is especially true in the case of SOA deployments where Services are
orchestrated to form composite applications.
The Application System Type (AST) object is used to represent the Business Service object.
The AST can be referenced while defining the Service of an Automated Activity during the
modeing of the process flow. The below figure shows the browsing of services while
configuring the Get Customer Information Automated Activity. The business
processes are also represented as Services as seen in the figure below.

The Business Architect also supports Service Discovery. You can browse for Service
definitions (WSDLs) and associate them with the Application System Type object.

You can create a Services folder under the Main folder to hold Business Service objects.
Right-click on the folder and select SOA/Import Service Decription option. The Service
descrtiption wizard allows you to define the Service requirements and to browse for the
WSDL.

6 Modeling detailed process flow

BPMN is recommended for modeling detailed process flows.

6.1 Simple Flow

Lets take a simple process flow and describe it in BPMN. The Quote to cash process consists of
2 sub-processes : (a) Process Quote followed by (b) Process Order. In the Process Quote
process, the Sales Quote document is generated by the Sales Rep which then gets approved by
the Sales Executive. The Quote is then sent to the customer for his acceptance. In the Process
Order process, the Order is generated from the Quote, the customer credit information is verified
and the Order is fulfilled. Lets describe the main process first and then the sub-processes. The
symbol represents the sub-process calling step.

Process Quote Flow

1. The Sales Quote document is generated by the Sales Rep after receiving a Quote
request message from Customer. This is a human step.
2. The Sales Manager approves the deal structure and the price of the Sales Quote. This is
a human step as well.
3. Once the Quote has been approved, the Sales Rep forwards the Quote to the customer .
Following figure shows Quote process with just 3 steps. The swimlanes represent the
various process participants in the process. Choose the Single Approver workflow pattern for
Create Quote and Approve Quote steps as the task will be executed by just a single process
participant.

Process Order Flow

1. The Order request from the Quote process triggers the Process Order flow.

2. An Order is created and inserted into the Order Processing System. The status of the
Order is set to Pending. The Input is the Quote and the output is the Order. This is
an automated step.
3. The complete Customer record is retrieved by invoking the Customer service. Input is the
customer name and output is the Customer record.
4. Credit check is then performed by invoking the Credit Rating Service. Input is the
Customer record. Output contains the Credit Rating information.
5. The Order is further manually approved by the Supervisor.
6. If the order is approved, it is sent to Order Fulfillment. If the order is not approved, the
order is canceled and a notification is sent to the customer regarding order cancellation.

The conditional gateway

is used for performing exclusive conditional
branching. Double-click the output connections of the Gateway to specify the conditional
expression. The Process Order process is captured in the following figure:

6.2 Conditional Branching

6.2.1 Mutually exclusive conditional branching
One and only one of the paths can be taken depending on the condition being satisfied. The
Default path is taken if none of the conditions are satisfied on the other paths. Double-click on the
connection object to specify the conditional expression.

6.2.2 Mutually Inclusive Conditional Gateway

One or more paths can be taken depending on the condition being satisfied.

6.2.3 Parallel Paths

Parallel Paths with and without AND Gateway. Both imply the same. All the output paths are
taken.

6.3 Conditional Merging

6.3.1 Merging mutually exclusive paths
Both figures are valid ways of merging mutually exclusive paths.

(a) Using the XOR Data Gateway

to merge mutually exclusive paths.

(b) Merging mutually exclusive paths without the XOR Data Gateway. You can also have 3 End
events completing the 3 paths.

6.3.2 Merging mutually inclusive paths

The OR Gateway

must be used for mutually inclusive gateway merge.

6.3.3 Parallel joins

The AND Gateway

must be used for parallel joins.

6.4 Process Hierarchy

Processes can be linked together by choosing the Assignment option upon right-click of a calling
out sub-process step. The Assignment option brings up the Assignment wizard and allows you to
choose the sub-process that needs to be called. This figure shows the Process Quote and
Process Order steps calling out to sub-processes.

6.5 Loops
Lets build on the BPMN process defined in section 5.1 and introduce loops as well as conditional
branching. The Process Quote process defined in section 5.1 does not take in to
consideration that the Approve Quote step has 2 possible outcomes. The Quote can be
approved or rejected by the Sales Executive. If the Quote is rejected, the Sales Rep has to redo
the Quote. If it is approved, the Quote needs to be sent to the Customer for his approval. So,
there are 2 possible paths that can be taken after the Approve Quote step.

The below figure shows some of the loop patterns.

6.6 Request-response scenarios

The scenario in 5.2 does not take in to account the Customer response to the Quote. The
Customer can either accept or reject the Quote. The above process can be further refined
to include the Customer interaction. The Quote is cancelled if the Customer rejects the
Quote and a notification is sent to indicate that the Quote is cancelled. On the other hand,
if the customer accepts the Quote, a notification is sent to the customer regarding the
processing of the Order. The below figure shows the section of the process that has been
modified to include the request-response scenario.

In BPMN, a process is represented by a Pool. There can be multiple processes or Pools

within a business process diagram and BPMN uses messages also referred to as message
flows to show interaction or communication between processes. In our example, the two
processes would be Process Quote and Customer. Use Event Gateway
to receive 2 or more possible events from another process. The end to
end process looks like the following figure.

6.7 Modeling Exception Scenarios

So far we have looked at modeling happy paths and have not addressed Business Exceptions.
Business Exceptions provide visibility in to the alternative paths that need to taken if the happy
path results in an error. It is key to model business exceptions especially if you intend to perform
simulation of your business process models as some business exceptions result in a significant
degradation in performance. In our example scenario, in the Process Quote sub-process, the
Cancel Quote path should throw an error that needs to be caught in the main process, the Quote
to cash process and the Quote to cash process should terminate and not proceed further to
Process Order sub-process. Place an Error End Event Cancel Quote
and connect it to the Reject Quote - path. The Accept Quote - path has a normal End event.
The error event thrown by the Process Quote sub-process now needs to be caught in the
Quote to cash main process. The section of the sub-process that throws the error event to the
main process is captured in the below figure.

The below figure shows the error being caught in the main process.

You can also model exceptions thrown at the activity level and the associated exception flow
path. The following figure shows business exceptions at the activity level in the Process
Order process. The Create Order Automated activity throws a timeout exception if there
is no response within 20 minutes and a bad data error if the input to the Create Order
activity does not contain the required fields. The exception path consists of Enter Order
Manually Human activity where the Order is entered manually by the Fulfillment Clerk.
Similarly, the Get Customer Information Automated activity can throw an exception when
the Customer is not present in the Customer system. The exception path consists of a human
step to create a new Customer record.

6.8 Handling Business transactions and compensations

Business transactions can be compensated as though a roll back has occurred through a
compensation event. Only 1 activity or sub-process can be attached to Compensation event.
Sequence flows cannot flow out of Compensation activities. The compensation event gets
triggered only if the activity that it is attached to completes. The following figure shows the
compensation activity Debit account attached to Compensation event (catch block) of the same
name. This is invoked if the Debit account compensation event (throw block) is invoked which in
turn will be thrown if the Item not available happens.

7 Other Modeling best practices

7.1.1 Filters
Business Architect also features a wizard that allows users to customize frameworks and
methodologies to meet the specific framework and methodology needs of their organization by
creating filters or templates. Filters are not only used to dumb down information but also to restrict
access to information. You can use Filters to restrict or expand access to the model, object,
attribute and connection types provided by ARIS. The Oracle BPA Filter is recommended for the
Oracle BPM lifecycle for management of business processes.

7.1.2 Access Control

The Business Architect allows you to define user, user groups and associate them with Filters
and access privileges. The granularity of access privileges is at the Folder/Group level so you
cannot group models that might be associated with different set of access control privileges in the
same Folder.

7.1.3 Clean up your database

Reorganise your database often so that the Business Repository can get rid of unused
process artifacts. This helps to speed up the Business Repository and help you to design more
efficiently.