Oracle Technology Strategies BPM Infrastructure (Reference Architecture)

Oracle Reference Architecture
BPM Infrastructure
Release 3.0
E17111-03
September 2010
ORA BPM Infrastructure, Release 3.0
E17111-03
Copyright 2010, Oracle and/or its affiliates. All rights reserved.
Primary Author: Mark Wilkins
Contributing Author: Dave Chappelle, Bob Hensle, Stephen Bennett, Anbu Krishnaswamy, Cliff Booth, Jeff
McDaniel, Michael Schrader
Contributor:
Warranty Disclaimer
THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS

PROVIDED ON AN "AS IS" BASIS AND FOR GENERAL INFORMATION PURPOSES ONLY. ORACLE
EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ORACLE MAKES NO WARRANTY THAT
THE INFORMATION IS ERROR-FREE, ACCURATE OR RELIABLE. ORACLE RESERVES THE RIGHT TO
MAKE CHANGES OR UPDATES AT ANY TIME WITHOUT NOTICE.
As individual requirements are dependent upon a number of factors and may vary significantly, you should
perform your own tests and evaluations when making technology infrastructure decisions. This document
is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle
Corporation or its affiliates. If you find any errors, please report them to us in writing.
Third Party Content, Products, and Services Disclaimer
This document may provide information on content, products, and services from third parties. Oracle is not
responsible for and expressly disclaim all warranties of any kind with respect to third-party content,
products, and services. Oracle will not be responsible for any loss, costs, or damages incurred due to your
access to or use of third-party content, products, or services.
Limitation of Liability
IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR
CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE,
INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT,
ARISING FROM YOUR ACCESS TO, OR USE OF, THIS DOCUMENT OR THE INFORMATION.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
Contents
Send Us Your Comments ....................................................................................................................... vii
Preface ................................................................................................................................................................. ix
1 Overview
1.1 BPM Infrastructure ..................................................................................................................... 1-1
1.2 Scope of BPM Perspective.......................................................................................................... 1-1
2 Introduction
2.1 Business Goals for BPM Infrastructure.................................................................................... 2-1
2.2 BPM and SOA.............................................................................................................................. 2-2
3 Conceptual Architecture and Infrastructure Capabilities

3.1 BPM Infrastructure Capabilities ............................................................................................... 3-2
3.1.1 Modeling ............................................................................................................................... 3-2
3.1.2 Simulation ............................................................................................................................. 3-3
3.1.3 Unified Repository .............................................................................................................. 3-3
3.1.3.1 Process Model and Metadata...................................................................................... 3-3
3.1.3.2 Business Rules Repository........................................................................................... 3-3
3.1.3.3 Service Repository ........................................................................................................ 3-3
3.1.3.4 Business Motivation ..................................................................................................... 3-3
3.1.3.5 Model Exchange ........................................................................................................... 3-4
3.1.3.6 Diagram Interchange ................................................................................................... 3-4
3.1.4 Process Execution ................................................................................................................ 3-4
3.1.4.1 Business Process .......................................................................................................... 3-4
3.1.4.2 Human Workflow ....................................................................................................... 3-4
3.1.4.3 Service Orchestration .................................................................................................. 3-4
3.1.5 Business Rules ..................................................................................................................... 3-4
3.1.6 Event Handling ................................................................................................................... 3-5
3.1.7 Monitoring, Management, and Security .......................................................................... 3-5
3.1.8 Stakeholder Interaction....................................................................................................... 3-5
3.1.8.1 Process Analysis and Modeling ................................................................................. 3-6
3.1.8.2 Monitoring, Analysis, and Control ............................................................................ 3-6
3.1.8.3 Process Initiators and Participants............................................................................. 3-6
iii
4 Logical Architecture
4.1 Design-time Logical View.......................................................................................................... 4-1
4.1.1 Business Architecture ......................................................................................................... 4-2
4.1.2 Business Process Modeler................................................................................................... 4-3
4.1.3 Business Process Simulator ................................................................................................ 4-3
4.1.4 Business Policy Manager .................................................................................................... 4-3
4.1.5 Technical Process Designer ................................................................................................ 4-3
4.1.6 Service Composer ................................................................................................................ 4-3
4.1.7 Design-time Repository ...................................................................................................... 4-4
4.1.8 Diagram Interchange........................................................................................................... 4-4
4.2 Run-time Logical View............................................................................................................... 4-4
4.2.1 Process Execution ................................................................................................................ 4-5
4.2.1.1 Rules Execution Engine ............................................................................................... 4-5
4.2.1.2 State Manager................................................................................................................ 4-5
4.2.1.3 Transaction Coordinator ............................................................................................. 4-6
4.2.1.4 Process Cache ................................................................................................................ 4-6
4.3 Related Components .................................................................................................................. 4-6
4.3.1 Continuous Improvement Loop ........................................................................................ 4-6
4.3.2 Application Integration....................................................................................................... 4-7
4.3.2.1 Work-list ........................................................................................................................ 4-7
4.3.2.2 Service Discovery ......................................................................................................... 4-7
5 Product Mapping
5.1 Oracle Business Process Analysis Suite ................................................................................... 5-2
5.2 Oracle Business Process Management Suite ........................................................................... 5-4
5.3 Oracle SOA Suite......................................................................................................................... 5-5
5.4 Shared Products and Product Components............................................................................ 5-6
5.4.1 Metadata Service (MDS) Repository................................................................................. 5-6
5.4.2 Service Component Architecture (SCA)........................................................................... 5-6
5.5 Oracle BPM (OBPM) Design-time ............................................................................................ 5-6
5.5.1 BPM Studio ........................................................................................................................... 5-7
5.5.2 BPM Composer .................................................................................................................... 5-7
5.5.3 Oracle BPM (OBPM) Run-time .......................................................................................... 5-8
5.6 Oracle Business Rules (OBR)..................................................................................................... 5-9
5.7 Oracle Business Activity Monitoring (BAM) ....................................................................... 5-10
5.8 WebCenter (WCI)..................................................................................................................... 5-10
5.9 Integration................................................................................................................................. 5-10
5.9.1 Oracle Data Integrator...................................................................................................... 5-10
5.9.2 Oracle Adapters ................................................................................................................ 5-10
6 Process View
6.1 BPM Lifecycle Process................................................................................................................ 6-1
7 Deployment View
7.1 A Generalized Deployment Model .......................................................................................... 7-1
7.1.1 Run-time Business Process Engine.................................................................................... 7-2
iv
7.1.2 BPM Participants ................................................................................................................. 7-2
7.1.3 Supporting Services............................................................................................................. 7-2
7.2 Typical Physical Deployment ................................................................................................... 7-2
8 Summary
v
List of Figures
31 BPM Conceptual Architecture .................................................................................................. 3-2
41 Design-time Logical Architecture............................................................................................. 4-2
42 Run-time Logical Architecture.................................................................................................. 4-5
43 End-to-end Logical Architecture .............................................................................................. 4-6
51 High-level view of the core BPM Suites and related products ............................................ 5-2
52 Core of BPA Suite Components................................................................................................ 5-3
53 BPM Suite Products .................................................................................................................... 5-5
54 BPM Analysis and Design detail .............................................................................................. 5-8
55 BPM Run-time detail .................................................................................................................. 5-9
61 High-level activities in a business process lifecycle............................................................... 6-2
71 Generalized Deployment Model .............................................................................................. 7-1
72 Typical Physical Deployment ................................................................................................... 7-3
vi
Send Us Your Comments
ORA BPM Infrastructure, Release 3.0

E17111-03
Oracle welcomes your comments and suggestions on the quality and usefulness of this
publication. Your input is an important part of the information used for revision.
Did you find any errors?
Is the information clearly presented?
Do you need more information? If so, where?
Are the examples correct? Do you need more examples?
What features did you like most about this document?
If you find any errors or have any other suggestions for improvement, please indicate
the title and part number of the documentation and the chapter, section, and page
number (if available). You can send comments to us at its_feedback_ww@oracle.com.
vii
viii
Preface
Following the approach of the Oracle Reference Architecture (ORA) the Business
Process Management (BPM) Foundation and Infrastructure documents present the
Oracle reference architecture viewed from the perspective of technologies associated
with business process. While the ORA perspectives are necessarily grounded in
Service Oriented Architecture (SOA) the current combination of BPM with SOA offers
significant advantages to IT in supporting the rapidly changing demands of today's
business communities.
The ORA BPM perspective document set is divided into two major themes. The first
document of the BPM perspective set builds on the ORA SOA Foundation to create the
ORA BPM Foundation. This BPM Foundation document describes the general reference
architecture for BPM, associated standards, and architectural principles to be applied
to Oracle Fusion BPM technology environments.
The second document in the BPM perspective set, the ORA BPM Infrastructure (this
document), extends the foundation architectural principles to build a set of
BPM-specific capabilities and to map them to relevant infrastructure components.
Audience
This document is intended for publication to Oracle customers with an interest in BPM
and is targeted towards architects and business specialists. It provides the
background material as the basis to discuss BPM solutions between Oracle architects
and Oracle customers.
Document Structure
This document is organized in chapters spanning introduction, background,
conceptual architecture, standards and technologies, ORA interlock, and appendices.
Specifically,
Chapter 1 - provides an overview of BPM infrastructure and its relationship to other
technology strategies.
Chapter 2 - introduces the structure of this document and the approach to developing
an architectural description for BPM infrastructure.
Chapter 3 - presents the core conceptual architecture for this BPM perspective.
Chapter 4 - describes the logical view of the BPM perspective identifying the
components required to provide the capabilities described in the previous chapters.
Chapter 5 - is a mapping of Oracle products to the logical architecture.
ix
Chapter 6 - presents the process view for the lifecycle of a BPM process in the BPM
reference architecture.
Chapter 7 - presents a deployment view for the BPM reference architecture.
Chapter 8 - is a summary of the conclusions contained in this document.
Appendix A - provide lists of relevant supplementary reading and references.
How to Use This Document

This document is intended to be read from start to finish. This document is to be
publically available and should be shared with Oracle customers interested in BPM
solutions and architecture. The contents of this document should provide answers to
questions from customers regarding the infrastructure for BPM and product mapping
to BPM capabilities.
Related Documents
IT Strategies from Oracle (ITSO) is a series of documentation and supporting collateral
designed to enable organizations to develop an architecture-centric approach to
enterprise-class IT initiatives. ITSO presents successful technology strategies and
solution designs by defining universally adopted architecture concepts, principles,
guidelines, standards, and patterns.
ITSO is made up of three primary elements:

Oracle Reference Architecture (ORA) defines a detailed and consistent
architecture for developing and integrating solutions based on Oracle
technologies. The reference architecture offers architecture principles and
guidance based on recommendations from technical experts across Oracle. It
covers a broad spectrum of concerns pertaining to technology architecture,
including middleware, database, hardware, processes, and services.
Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption
of horizontal technologies for the enterprise. They explain how to successfully
execute on a strategy by addressing concerns pertaining to architecture,
technology, engineering, strategy, and governance. An organization can use this
material to measure their maturity, develop their strategy, and achieve greater
levels of adoption and success. In addition, each ETS extends the Oracle Reference
x
Architecture by adding the unique capabilities and components provided by that
particular technology. It offers a horizontal technology-based perspective of ORA.
Enterprise Solution Designs (ESD) are industry specific solution perspectives
based on ORA. They define the high level business processes and functions, and
the software capabilities in an underlying technology infrastructure that are
required to build enterprise-wide industry solutions. ESDs also map the relevant
application and technology products against solutions to illustrate how
capabilities in Oracles complete integrated stack can best meet the business,
technical, and quality of service requirements within a particular industry.
ORA BPM Infrastructure, along with ORA BPM Foundation, extend the Oracle
Reference Architecture. They are part of a series of documents that comprise the BPM
Enterprise Technology Strategy, which is included in the IT Strategies from Oracle
collection.
Please consult the ITSO web site for a complete listing of ORA documents as well as
other materials in the ITSO series.
Conventions
The following typeface conventions are used in this document:
Convention Meaning
boldface text Boldface type in text indicates a term defined in the text, the ORA
Master Glossary, or in both locations.
italic text Italics type in text indicates the name of a document or external
reference.
underline text Underline text indicates a hypertext link.
"Service" v. "service" - In order to distinguish the service of Service-Oriented

Architecture from the wide variety of services within the industry, the term SOA
Service (although somewhat redundant) will be used throughout this document to
make an explicitly distinction for services that were created as part of an SOA
initiative; thus distinguishing SOA Services from other types of services such as Web
Services, Java Messaging Service, telephone service, etc.
Architectural terminology - When appearing in this document, the terms view,
viewpoint, stakeholder, concern, are used according to the definitions appearing in the
IEEE 1471 "Recommended Practice for Architectural Description of Software-Intensive
Systems". The term perspective however, does not appear in IEEE 1471 and is defined
instead, within the context of ORA, to refer to a particular viewpoint on to the ORA
core reference architecture (in this case the technological viewpoint of BPM).
xi
xii
1
Overview
1
ORA is a product-agnostic reference architecture based on architecture principles and

best practices. The principles and best practices are widely applicable and can be
implemented using a variety of products and technologies. ORA does not include any
implementation artifacts for the prescribed architecture. ORA addresses the building
of a modern, consistent IT architecture while minimizing the risk of product
incompatibilities and obsolescence.
This document set is essentially a reference architecture and infrastructure positioning
with a brief look at assessment and implementation practices. It does not describe how
to identify sales opportunities or what scenarios are appropriate for BPM treatment
(see BPM, SOA, and Web 2.0 whitepaper for information).
The ORA BPM documents present the ORA architectural concepts from the
perspective of BPM; highlighting the specific details of BPM as an elaboration of the
ORA core concepts. This ORA BPM perspective comprises two documents:
BPM Foundation: primarily a reference architecture for BPM in IT, including
principles, standards, and definition of BPM and its limitations (scope). See the
ORA BPM Foundation document.
BPM Infrastructure (this document): relates the BPM capabilities, as defined by the
reference architecture, to the Oracle infrastructure and identifies the role of
standards.
1.1 BPM Infrastructure

The ORA BPM perspective is incremental to the ORA core, relying on all underlying
descriptions and architectural principles. The underlying ORA core concepts are not
reproduced in this perspecive document except where it is necessary to show
BPM-specific views.
1.2 Scope of BPM Perspective

This document provides an architectural description for BPM infrastructure necessary
to achieve the capabilities and meet the architectural principles described in the ORA
BPM Foundation document.
In addition to describing the BPM infrastructure using conceptual, logical, process,
and deployment architectural models, this document also outlines a product mapping
from the logical model to the supporting Oracle products.
This document focuses on the technical and architectural aspects of BPM. Technology
is only part of the BPM picture however, and considerable attention needs to be given
to business concerns, such as business process re-engineering, process improvement,
Overview 1-1
Scope of BPM Perspective
and the organizational and cultural changes necessary for BPM success. Such
concerns are dealt with in Oracle's BPM Method.
This document does not attempt to offer a methodology for the implementation of a
BPM strategy, although it is expected that it will be used in conjunction with such a
methodology as the foundation for the architectural approach.
1-2 ORA BPM Infrastructure

2
Introduction
2
The purpose of the BPM infrastructure architecture document is to provide a tangible,

technical strategy for delivering the capabilities and meeting the architectural
principles of the conceptual architecture.
For continuity, this document starts with a review of primary business goals for BPM,
and expands on the BPM conceptual architecture (see Chapter 3) initially outlined in
ORA BPM Foundation.
2.1 Business Goals for BPM Infrastructure

Today's "third wave" of BPM aims to "close the business-IT gap" and empower the
business users to create, manage, and refine core business processes, while
maintaining continuity and clear communication with IT. Unlike the early days of
business process analysis as a documentary aid, these business processes must be
executable, manageable, and measurable. Most of all they must enable closed-loop
continuous improvement with lossless information exchange between stakeholders.
To achieve this empowerment the new generation BPM infrastructure must provide
the following to the business user:
A shared model with views for all stakeholders providing a focal point for
communication and cooperation between business and IT.
Ability to model human workflow involving rich interaction with
structured/unstructured content and seamless integration with existing enterprise
application processes.
An analytical mechanism to support continuous improvement and integrate
business/enterprise performance management efforts.
Real-time feedback to support control and measure effectiveness against Key
Performance Indicators (KPI).
Access to enterprise application functionality in a form that is consistently
understood by both business and IT.
End-to-end traceability to associate business process change with underlying
business motivation.
For the IT user the BPM infrastructure must provide the following:
Ability to apply details to the model necessary to make the process executable,
including task-level parameters, message exchange, and external documents/data.
Integration techniques to bring together the elements involved in the process,
including system integration between disparate application functions that make
Introduction 2-1
BPM and SOA
up the process activities, human task and associated application workflow, and
monitoring and analytical systems that support control and refinement.
Manageable security (in both design-time and run-time).
Support for process versioning.
A flexible workflow process to make all the above work together for any given
organization (i.e. the tools must be flexible enough to integrate with existing IT
engineering practices and must not impose their own approach).
2.2 BPM and SOA

Although Service Oriented Architecture (SOA) is described in detail in a separate ETS
its relevance to BPM is so significant that its mention here is inescapable. While many
earlier IT architectural approaches bring potential benefits towards achieving the goals
of BPM (outlined above) the business focused approach of SOA offers many more
advantages.
SOA brings a new discipline to business and IT alignment in the description of SOA
Service contracts; this leads immediately to a consistent and effective approach to the
discovery of reusable enterprise application assets. In addition, SOA's loose coupling
enables IT to perform infrastructure and application optimizations while minimizing
dependencies.

BPM and SOA
Introduction 2-3
BPM and SOA

3
Conceptual Architecture and Infrastructure
3
Capabilities
A conceptual architecture is a representation of the generalized capabilities of a

system. It identifies the aspects of the system that are critical to the operation of
particular business capability. (The word system is used here for its broader
meaning of any cohesive group of related elements, technical and non-technical).
The BPM conceptual architecture highlights the core capabilities of a BPM system,
identifies the major intersecting systems and outlines their relationships. As far as
possible, the BPM system is described in business terms, without the supporting IT
functions and without regard for technical constraints. The conceptual architecture
represents what the business needs from a BPM system.
This conceptual architecture description of BPM is a summary of the conceptual view
found in the ORA BPM Foundation document where it is described in the context of
architectural capabilities. The conceptual architecture view is included here for the
purpose of aligning the capabilities required from the BPM infrastructure.
The conceptual architecture, shown in Figure 31 below, depicts the core features of
the BPM system, its relationships with other general IT infrastructure, and various
participants involved throughout the business process life-cycle.
Conceptual Architecture and Infrastructure Capabilities 3-1

BPM Infrastructure Capabilities
Figure 31 BPM Conceptual Architecture
The core elements of the BPM conceptual architecture were described in the ORA BPM
Foundation document and include modeling, simulation, repository, orchestration
(human and system), and events. Additionally there are a number of relationships
with other technologies including EAI, various aspects of SOA, portals, dashboards,
analytics, and of course, enterprise applications. The following sections describe these
elements of the BPM conceptual architecture in terms of the capabilities required from
the BPM infrastructure.
3.1 BPM Infrastructure Capabilities

In order to achieve an effective deployment and adoption of BPM it is necessary to
identify the capabilities required for alignment with business goals. Infrastructure
capabilities should be realized through the implementation and deployment of the
components of the logical architecture, while others may involve operational,
organizational, and other aspects not directly related to infrastructure.
This section focuses on capabilities that can be attained through the BPM
infrastructure. The superset of BPM capabilities, beyond just those identified as
infrastructure capabilities here, will also be used as a basis for the BPM Maturity Model.
The infrastructure capabilities should support the architectural principles which can
be found in ORA BPM Foundation.
3.1.1 Modeling
Process modeling is a fundament requirement of BPM. The modeling subsystem must
be able to participate in the lifecycle of a businiss process and it must provide views to
support both business and technical users.

The modeling infrastructure must enable round-tripping, not only offering seamless
exchange of models from business to execution, but also incorporating simulation and
run-time data for continuous improvement of the business process.
3.1.2 Simulation
Simulation is a theoretical execution of the modeled business process. Typically the
business specialist sets the parameters for the simulation describing an environment
that mimics a real-world scenario (for example, number of concurrent users, profile of
delay between process steps, etc.). The simulation tool (usually an extension of the
modeling tool) runs the scenario, and the efficiency of the business process can be
predicted within the boundaries of supplied parameters.
3.1.3 Unified Repository

The infrastructure must provide a unified repository to support coordinated modeling
between business and IT models and the generation of the executable representation.
Ideally these representations are merely views of the same physical model for
immediate visibility of changes between stakeholders. Transformation between model
representations is sometimes necessary, e.g. for the sake of separate storage or the
transfer of models between business partners. In this case however, it is important that
transformations are bi-directional and without loss of information or distortion of the
graphical representations. These points are covered by Diagram Interchange and
Model Exchange below.
3.1.3.1 Process Model and Metadata

The primary role of a BPM repository is to store and share the business process model
and underlying structural information about the model, i.e. metadata (e.g. version
number and last changed date).
3.1.3.2 Business Rules Repository

The maintenance and execution of business rules is a key capability, and like core
business process modeling, spans design-time and run-time. Business rules are
implicitly included in the conceptual repository, although most implementations are
likely to provide separate storage. In any case it is necessary that the rules be visible to
both process modelers and stakeholders responsible for rules determination. As with
the process model itself the rules must be executable in the run-time system.
3.1.3.3 Service Repository

Another aspect of the conceptual unified repository is a portfolio of business functions
and data that are available to the modelers for inclusion in the business process model
as tasks and the data they act upon.
3.1.3.4 Business Motivation

Understanding strategic objectives, for example using strategy maps and value chains,
is particularly important when selecting processes for automation. However, such
business motivation artifacts are needed for governance of the business process
lifecycle, including traceability, impact analysis, etc.

3.1.3.5 Model Exchange

When exchanging the business process model between dissimilar systems (as opposed
to the exchange between stakeholders) the model semantics must be maintained and
the exchange should ideally be bi-directional.
3.1.3.6 Diagram Interchange

When the Unified Repository is not one physical entity, Diagram Interchange becomes
necessary to exchange models between stakeholders or partners.
Diagram Interchange is primarily intended to maintain the graphical layout of a
process model during its transfer between tools, while the operational semantics are
handled by Model Exchange.
3.1.4 Process Execution

Process execution refers the control of the flow of a business process, and not to the
actual running of the application/system functions that underlie the tasks and
activities.
As part of the control of the flow of various types of process, process execution also
involves the invocation of business rules (see Section 3.1.5, "Business Rules") to
support decisions in the flow.
In addition, process execution is responsible for the exchange of parameters (data
exchanged between process tasks and activities) and making references to external
information sources.
Three common types of process flow control are outlined in the following sections.
3.1.4.1 Business Process

A Business Process is the highest level of flow control, potentially calling on both
human and system activities.
3.1.4.2 Human Workflow

Human Workflow is responsible for managing the lifecycle of human tasks, including
creation, assignment, expiration, deadlines, and notifications, as well as its
presentation to end users.
3.1.4.3 Service Orchestration

Application or system functions may be called directly as business process tasks, but
often these functions are too fine grained (and may be inadequately described) to be
used directly by a business process. Instead, Service Orchestration aggregates
low-level functions and presents then as sub-processes that may be used more
effectively by the higher-level business process. When the principles of a Service
Oriented Architecture are applied, these Service Orchestrations are described in a way
that is unambiguous by both the business and IT leading to benefits, such as, process
discovery during design, more effective reuse, and lifecycle management. Refer to the
ORA SOA Foundation document for more information about SOA and Service
Orchestration.
3.1.5 Business Rules

Business rules are expressions of business policy that can be used to guide the flow of
a business process.

A BPM system must provide capabilities for business rule design, management, and
execution. Ideally graphical tools should provide insight, for the process designers,
into the run-time evaluation of complex rule combinations.
Business rules are distinct from routing rules which are technical considerations, such
as determining the best SOA Service instance to invoke based on availability. Routing
rules are typically applied by the SOA infrastructure and should not be confused with
business rules.
3.1.6 Event Handling

In BPM an Event is basically a communication between the process and the outside
world. Start and End events are always present in a complete business process
description, identifying the trigger from the outside world that initiates the process
execution, such as receipt of an e-mail, and the circumstances that define the end of the
process and termination of its flow.
Faults and Timers are special types of events: Faults refer to the handling of error
conditions which potentially lead to premature termination of a process, while Timers
enable processes to start on a schedule, or to pause for a predetermined period (as in
the case of reoccurring activities). Various other types of events may be described, but
are categorized here with the general term "events" for brevity.
Events, other than Start and End events, are referred to in BPMN 2.0 as "intermediate
events" because they occur during process execution and may or may not interrupt the
flow of the process.
Events are normally associated with a message, e.g. an order request by e-mail signals
the start of an ordering process while a corresponding order confirmation e-mail is
transmitted upon normal completion of the order. Some exceptions may exist, such as
process cancellation by an administrator.
3.1.7 Monitoring, Management, and Security

As with all architectures, monitoring, management, and security, are important
capabilities. These topics are covered in general by separate ORA documents, but they
are also identified here to ensure that concerns specific to BPM are covered.
One of the most important features of monitoring in the context of BPM is the support
it provides to process optimization. The performance of a process may be monitored
for real-time and/or off-line analysis for comparison against previously determined
performance indicators.
A more typical aspect of monitoring is observing the health of process flows enabling
human administrators (and potentially automated systems) to respond to undesirable
situations such as stalled process flows. This aspect of monitoring overlaps with
management by supporting control of business processes.
The main concern of management is the lifecycle of the business process, in particular,
management of multiple versions of processes, deprecation of processes, and impact
analysis.
3.1.8 Stakeholder Interaction

Seen in the top layer of the diagram the stakeholders fall into three categories roughly
aligned with the lifecycle stages described in the ORA BPM Foundation document:
business modeling, technical modeling, process execution, and monitoring. This
alignment is explained under the associated category headings in the following
sections.

3.1.8.1 Process Analysis and Modeling

Business process analysis and (technical) process design are performed at design-time
by business process analysts and technical specialists. Both use modeling tools that
present representations of the same business process tailored to the needs of business
and technical communities, ultimately leading to the formation of an executable
model.
In addition, simulation of hypothetical process execution scenarios is supported in
design-time, ideally with the ability to incorporate replays of processes captured by
run-time monitoring.
Business rules and performance indicators may also be modeled by the same
stakeholders and their representations maintained, along with process models, in the
(conceptual) unified repository.
3.1.8.2 Monitoring, Analysis, and Control

This category of stakeholder interaction simply represents user tools aspect of the
monitoring and management capabilities described previously (Section 3.1.7,
"Monitoring, Management, and Security"). Here we find administrators with the
ability to start, stop, and otherwise influence run-time processes while monitoring
tools collect and analyze information about them.
The stakeholders in this category are seen spanning design-time and run-time because
much of the information from monitoring servers the dual purpose of supporting
design-time analysis and run-time control.
3.1.8.3 Process Initiators and Participants

These are the main protagonists in the execution of a business process. Here we see
systems and human actors involved in various interactions with the business process,
including starting and interrupting, fulfilling human tasks, and monitoring overall
progress of the business process. Various devices and application types exist here,
including mobile, integrated application functions, worklist portal, etc. Note that the
system equivalent of fulfilling tasks (system activities) appears in the lower portion of
the diagram (IT Infrastructure). System actors, shown at the top portion of the
diagram, are typically starting process flows rather than performing tasks on behalf of
the process.

4
4Logical Architecture
The logical architecture identifies the components of a system needed to achieve the
capabilities described by the conceptual architecture. Unlike the conceptual view of
the architecture, the logical view is concerned with understanding the functions
required from the IT environment.
The components of the logical view commonly manifest as features of products or,
potentially, custom subsystems; although products are not considered until the later
product mapping exercise (see Chapter 5, "Product Mapping"). The physical
constraints of the IT environment, such as capacities of networks and servers, and
non-functional requirements, such as redundancy for high availability, are not
considered in the logical architecture since these are concerns for the deployment
architecture.
The components of the logical architecture are described in the following sections.
4.1 Design-time Logical View

The business process design-time components described in the following sections are
shown in the diagram in Figure 41 below. The BPM run-time and relationships with
supporting components are not shown here, but are described separately in
Section 4.2, "Run-time Logical View" and Section 4.3, "Related Components".
Logical Architecture 4-1

Design-time Logical View
Figure 41 Design-time Logical Architecture
The diagram in Figure 41 above shows the "Business Process Modeler" component
appearing in two categories of the BPM design-time view: Business Architecture and
Business Process Modeling. Business process modeling appears this way because it
commonly starts within the business architecture domain, which is considerably
broader in scope than BPM; hence the partial inclusion of business architecture in the
BPM design-time domain. Most importantly, and the reason for the additional
representation under business architecture, is the integration of the business process
model in the design-time repository (see Section 4.1.7 below). The conceptual "unified
repository" (see Section 3.1.3, "Unified Repository"), of which the design-time
repository is a part, may potentially include other elements of the business
architecture, such as strategic objectives, Key Performacne Indicators (KPIs), Service
Level Agreements (SLAs), etc.
4.1.1 Business Architecture

A formal definition of the term business architecture is provided by the Object
Management Group's Business Architecture Working Group as follows:
"A blueprint of the enterprise that provides a common understanding of the
organization and is used to align strategic objectives and tactical demands.
The term business architecture is used here to encapsulate the business drivers and
artifacts associated with the development and maintenance of the business process
model. These provide the inputs for identification of candidates for process
automation along with traceability throughout the process lifecycle, and play a key
role in the governance of BPM.
The diagram in Figure 41 shows a number of well known examples of business
modeling artifacts, including Business Motivation Model (BMM), Strategy Maps, and
Organization Charts, and may also contain a business-level representation of the
Business Process Model itself. This apparent duplication may be necessary due to
different uses (and stages of ownership) of the model: for example the business
strategy stakeholders could maintain a high-level view of the business process model

Design-time Logical View
(or process map) perhaps aligning with the OMGs level 1 (see Section B.1, "The "three
levels" of business process modeling"). The detailed analytical business process model
(level 2) appears in the core of the BPM design-time view while the technical process
designers view (level 3) is the final stage of refinement before migration to run-time.
Ideally these views of the business process model are merely different representations
of the same physical artifact. If this is not the case, (as is likely with the business
process model in the business architecture domain at least), then an interchange
protocol (see Section 4.1.8, "Diagram Interchange") becomes necessary.
4.1.2 Business Process Modeler

The business process modeler, shown in the core of the BPM design-time diagram in
Figure 41, represents the analytical modeling component of the BPM system. This
component is intended for use by the business specialist (or business analyst). It
presents a view of the process model unencumbered by the technical details of the
underlying applications and data sources.
Unlike the high-level business process view described in Section 4.1.1, "Business
Architecture" this model describes the details of exception paths and event handling.
4.1.3 Business Process Simulator

The process simulator enables the business specialist to describe a hypothetical
environment in which to test the business process model. The simulated execution of
the model generates throughput statistics and helps identify deficiencies in the model.
4.1.4 Business Policy Manager

Abstraction of business rules and policies (distinct from technical routing rules which
can be found elsewhere) is critical to the development of a flexible BPM solution.
Business rules and policies are maintained in a way that enables them to be
incorporated directly in business process models and referenced such that they are
executed by an associated rules engine at run-time.
The design-time policy manager and run-time rules engine are collectively referred to
as the Business Rules Management System (BRMS) and will be can found described as
such in Chapter 5, "Product Mapping".
4.1.5 Technical Process Designer

The technical process design component allows the technical specialists to apply
supporting technical details to the business process model as the final step before
generating the executable model. In this step the designer supplies the process details,
such as aligning input and output parameters between process activities, determining
message formats for data exchange, and identifying data and document sources.
4.1.6 Service Composer

The Service Composer offers an extension to the technical design process in which
"services" (web services, SOA Services, or other forms of encapsulated application
functionality) are "wired together" (composed) to assemble the functional elements of
(composite) business activities. The component might typically use these or other
similar service composition strategies.

Run-time Logical View
4.1.7 Design-time Repository

The design-time repository is a model and model metadata storage component
supporting all the above and providing the core of the business-IT collaboration. The
various representations (views) of the business process model are presented from a
single unified repository or, at least, exchanged between repositories using a
bi-directional, lossless model interchange mechanism. Other aspects of the business
and technical modeling may also be included in (or linked to) this design-time
repository.
The primary business model views presented by the design-time repository are the
business specialist view, the business analyst view, and the technical specialist view
(roughly aligned with the OMG 3-levels of modeling). Business rules may also be
contained within the design-time repository, although an independent rules repository
may exist as long as it is fully accessible by all the stakeholders tools.
The design-time repository should also includes some form of "service portfolio"
giving the process modelers a catalog of available business functions and providing a
consistent definition of service capabilities. The discovery of core business functions is
ideally supported by a (SOA) Service Repository, but other forms of functional catalog
may be used.
4.1.8 Diagram Interchange

Although not shown directly in the design-time diagram, Diagram Interchange (DI) is
distinct from "model exchange" and involves the transfer of business process model
visual details. DI may be used for the transfer of models between user tools that do not
share a common model repository. In such cases the transfer of the graphical elements,
their layout, positioning, etc. for a business process diagram (e.g. between the
"business architect" and the technical process designer) lacks the nuances of the more
technical model, which would otherwise contain parameter descriptions, external
resource references, etc. For this reason DI, unlike the shared model or model
exchange, cannot fully support bidirectional model exchange between business and
technical users.
4.2 Run-time Logical View

The BPM run-time logical view is shown in Figure 42 below. This portion of the
logical model identifies the components needed to fulfill the run-time capabilities of
the BPM conceptual model. The BPM run-time is responsible for the execution of the
business process, its administration, and monitoring. Taking a generated form of the
process model (and supporting elements such as executable rules) as input and
providing (in addition to the results of the processes themselves) data about the
process execution as output for further simulation and analysis back in the
design-time subsystem. Interactions with external systems are described in an
end-to-end logical view in Section 4.3, "Related Components".

Run-time Logical View
Figure 42 Run-time Logical Architecture
While the core system run-time components are shown grouped in the main portion of
the diagram in Figure 42 the core human interfaces are grouped separately in the
labeled "process portal".
4.2.1 Process Execution

The process manager, sometimes called the process controller or process execution
engine, is the core of the BPM run-time. The process manager orchestrates process
activities by monitoring start and end events (including exceptions and other types of
events) and managing the flow of control from one activity to the next. The process
manager also manages the resources associated with the business process (human
interaction, system and application integration), while enforcing business rules, and
auditing each step overseeing process execution, escalation, and exception
management handling.
4.2.1.1 Rules Execution Engine

The rules execution engine component is responsible for evaluating business rules in
the rules repository and providing responses to the process manager upon request.
4.2.1.2 State Manager

The state manager persists the state of long running processes, thereby freeing
memory resources of the runtime subsystem.

Related Components
4.2.1.3 Transaction Coordinator

The transaction Coordinator is responsible for managing both atomic and
long-running transactions.
4.2.1.4 Process Cache

The state of a running process may be cached to improve performance of the run-time
system.
4.3 Related Components

The complete view of the logical architecture shows both the relationships between the
design-time and run-time components as well as supporting components from other
areas of the IT infrastructure. The diagram in Figure 43 below shows these
relationships which are also described in the following sections.
Figure 43 End-to-end Logical Architecture
4.3.1 Continuous Improvement Loop

The relationship between the design-time and run-time groups of components is
shown by the two arrows between the two major subsystems in Figure 43. The first
arrow from design to run-time represents the transfer of the process model into the
executable environment. This transfer of the process model from design to execution
may involve a one-way transformation, particularly if the design and execution
languages are not the same (as in the case of BPMN to BPEL). However, modeling
languages supporting both design and execution semantics may facilitate design and
execution from a common model storage component. Business rules (or policies) are

Related Components
also conveyed from the design environment to the run-time rules engine in same
manner.
The second arrow, returning information from run-time to design-time, represents the
transfer of business process run-time activity information back to the design-time
tools. The information provided in this way enables the business specialists refine the
business process and hence compete the cycle of continuous improvement.
4.3.2 Application Integration

Application integration is shown primarily in the lower section of the diagram in
Figure 43, but it also appears in another form in the process portal box at the top of
diagram.
4.3.2.1 Work-list
The work-list (human task) portal may also be directly integrated with applications to
automate the signaling of task completion to the process manager. Human tasks
commonly involve document processing, since applications typically involve the
systematic creation or accumulation of documents by presenting users with forms to
be entered on-screen. Documents may be provided by an integrated Content
Management System (CMS) or through an integrated application. Documents may
also arrive by other means (e.g. e-mail, FAX), triggering business process events.
4.3.2.2 Service Discovery

A SOA Service Repository identifies business services available to the process
specialists at design-time. During runtime SOA Services may be coordinated by
Enterprise Service Bus (ESB) and/or Service Registry components.
Additional techniques are available, such as Apache Web Service Invocation
Framework (WSIF), which presents a catalog of non-SOA assets for use at
design-time. WSIF provides protocol mediation for bindings, such as J2CA, SOAP,
EJB, and POJOs, presenting their services via WSDL interface. WSIF also manages
transactions across its encapsulated application functions.
Traditional EAI techniques are also available (shown here as adaptors). These
techniques are well established, but typically lack the benefits of SOA, such as the
business-level descriptions of Service Contracts and design-time discovery.

Related Components

5
Product Mapping
5
The broad range of Oracle products directly associated with BPM is categorized by
two product sets ("suites"), namely Business Process Analysis (BPA) Suite and
Business Process Management (BPM) Suite. The two suites primary purposes are,
business process modeling and analysis (BPA Suite) and technical process design and
execution (BPM Suite).
The core Oracle products within the BPM Suites include components for analysis,
simulation, and publication of the business process (BPA Suite). BPM Suite includes
BPM Composer and Studio for process analysis and design; Human Workflow, BPMN
Runtime, and BPEL Process Manager (BPEL-PM) for process execution; Oracle
Business Process Management (BAM) for monitoring and reporting; Oracle Business
Rules (OBR) for business rules management and execution.
Service Oriented Architecture (SOA) often provides a strategic underpinning to BPM
and some overlap already exists between BPM Suite and SOA Suite: in particular the
BPEL-PM from SOA Suite forms part of a common run-time component which offers
the process designer a choice of process execution types. Other SOA products
potentially supporting BPM include Oracle Enterprise Repository (OER), Oracle
Service Bus (OSB), and Oracle Service Repository (OSR).
Other products and components that are commonly involved in BPM include
Webcenter and Weblogic portals for BAM dashboard, process administration, human
workflow, and application integration; Oracle Adapters, Oracle Connectors, and
Oracle Data Integration for various integration technologies.
A high-level view of the core BPM Suites and related products is shown below
mapped to the logical model from the previous chapter.
Product Mapping 5-1

Oracle Business Process Analysis Suite
Figure 51 High-level view of the core BPM Suites and related products
The core BPM Suites and related products shown here are described in more detail in
the following sections.
5.1 Oracle Business Process Analysis Suite

Oracle BPA Suite, based on the ARIS Design Platform, is a set of integrated products
that enables business users to design, model, simulate, and optimize business
processes to achieve maximum operational efficiency. BPA Suite addresses rich
analysis and modeling requirements such as Six Sigma, Lean, documentation-only
modeling, etc.
The Oracle BPA Suite consists of the following components:
Business Process Architect (Architect) for modeling of business process models

Oracle Business Process Analysis Suite
Simulator for simulation of business process models

Business Process Publisher (Publisher) for publishing process models to a secure
web portal to facilitate collaboration among business users
Business Process Repository Server for business users to work collaboratively on
the process models. The models and related business artifacts created using the
Architect are saved in the Business Repository. The Business Repository is a
database and the Architect connects to the Business Repository in local or remote
deployment. In the local deployment, the Architect directly connects to the
Business Repository. In the remote deployment, the Architect connects to the
Business Repository via the Repository Server and provides concurrent access for
collaborative development.
These core components of BPA Suite are shown in the following diagram.
Figure 52 Core of BPA Suite Components
Using BPA, business process design can be linked with business strategy models
supporting both process identification and traceability. Once a business process model
is created in BPA it can be shared with IT specialists to collaborate on implementation,
using BPM Studio (see OBPM below), for the technical integration necessary to
generate an executable process. Completing the BPM lifecycle, information about the
actual execution of the business process (see BAM in OBPM below) can be retrieved by
BPM for analysis and ultimately process improvement.
Oracle BPA supports Enterprise Architecture (EA), process improvement, and change
management initiatives and supports alignment of BPM and SOA initiatives. In
addition, the suite is integrated with Oracle SOA Suite, BPEL Process Manager, and
BAM to provide closed loop BPM capability.
The Oracle Business Process Architect provides a rich graphical modeling
environment tailored to business users for defining process maps and detailed process
flows consisting of human, system, and rule steps that span organizational
boundaries. In addition to business process modeling the Oracle Business Process
Architect supports data modeling (with rich support for UML), organizational
modeling, IT system landscapes, impact analysis, and rich report generation. It can be
used to analyze as-is and future, to-be, processes by running simulations based on
different scenarios. Simulations can be used to perform throughput analysis,
activity-based costing, and average cycle time analysis. The Oracle Business Process
Product Mapping 5-3

Oracle Business Process Management Suite
Architect 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 Oracle Business Architect provides views for different stakeholders with a feature
referred to as "perspectives" (also known as filters), supplying predefined perspectives
out-of-the-box and supporting creation of new ones.
Included with OBPA Suite is Oracle Business Process Publisher which is a tool for
publishing Business Process Models to a process portal providing role-based access to
process content. This fosters collaboration among the various stakeholders and
promotes sharing and review of process models on an enterprise wide scale.
The OBPA Suite includes the Oracle Business Process Repository which is used for
storing process metadata, from which business process models can be linked to other
business models to represent an holistic view of business architecture. Oracle Business
Process Repository Server is used for support of multiple users in the collaborative
development of process models with a shared repository. It also provides a centralized
process management store with role-based access, versioning, check-in/check-out, and
load balancing capabilities. Business Process Models are shared from OBPA repository
with OBPM and BPEL Designers, (described in the following sections) enabling
round-tripping between the business and technical platforms.
5.2 Oracle Business Process Management Suite

Oracle Business Process Management Suite (Oracle BPM Suite) is a set of tools for
creating, administering, executing, and optimizing business processes. The suite
facilitates collaboration between business and IT by sharing process models while
rendering views appropriate to the stakeholder.
Oracle Business Process Management is the underlying toolset for the Application
Integration Architecture (AIA) integration of Oracle's portfolio of applications.
Oracle BPM Suite includes the following product components:
Oracle Business Process Management (OBPM)
Oracle BPEL Process Manager (BPEL-PM)
Oracle Business Activity Monitoring (BAM)
Oracle Business Rules (OBR)
Oracle WebCenter Suite
Oracle JDeveloper
The products comprising BPM Suite are shown in the following diagram.

Oracle SOA Suite
Figure 53 BPM Suite Products
A more detailed description of the products making up BPM Suite can be found in the
following sections.
5.3 Oracle SOA Suite

SOA Suite contains Oracle's products for Service Oriented Architecture. It is an
integrated suite of products that enables rapid design and assembly, deployment, and
management of highly scalable and adaptable business applications.
Oracle SOA Suite supports a services and events architecture built on a modular,
interoperable infrastructure that leverages existing applications and other IT assets. By
shifting development from coding to component assembly it simplifies
implementation, increases development productivity, and shortens deployment time.
Oracle SOA Suite includes the following product components:
BPEL Process Manager (BPEL-PM)
Business Rules (OBR)
Business Activity Monitoring (Oracle BAM)
Complex Event Processing (CEP)
Oracle Service Bus (OSB)
Oracle Business-to-Business Integration (B2B)
Oracle Web Services Manager (OWSM)
Oracle JDeveloper
These individual products are described in the following sections in the context of the
BPM logical components.
Refer to the ORA SOA perspective and ETS document sets for more information about
SOA.
Product Mapping 5-5

Shared Products and Product Components
5.4 Shared Products and Product Components

A number of products and products components are shared between the product
suites, and the example of BPEL-PM has been mentioned already in the BPM Suite
section above. Other common products between BPM and SOA Suites are BAM, and
OBR. The JDeveloper IDE is also common, although not mentioned directly in the
BPM Suite product list as it is a component of the core BPM Studio product: more
importantly however, SOA Suite and BPM Suite provide separate extensions to
JDeveloper (also for the Open Source Eclipse IDE).
5.4.1 Metadata Service (MDS) Repository

Of particular note in the BPM Suite is the Metadata Service Repository (MDS). MDS is
a component of the Oracle SOA Suite that stores information about SOA composite
applications including business event definitions, business rules, transformations,
schemas, interface definitions, and Complex Event Processing (CEP) metadata files.
Oracle BPM also uses the MDS Repository to share projects and project templates
between Oracle BPM Studio and Oracle Business Process Composer (see OBPM
section below for more information).
In addition Oracle BPM uses to the MDS Repository to deploy executable processes to
the BPM runtime. For this reason the MDS appears in both design-time and run-time
representations in the following sections.
5.4.2 Service Component Architecture (SCA)

SCA is a standards-based assembly model for creating composite applications from
distributed components using disparate technologies. A SCA composite is an
assembly of Services, Components, and References wired together and deployed in a
single application. "Services" and "References" are entry and exit binding components
exchanging messages with the outside world while "wiring" is a graphical
representation of message flows between Service and binding components.
The SCA editor within JDeveloper provides a mechanism to compose an assembly of
Service assets (inc. processes, human tasks, rules, and events) with message flows and
data transformations.
SCA is used in BPM to bind the process (as a composite application) to the outside
world by configuring binding components. Specifically, user and rules tasks are
Service components while Service tasks and Receive tasks are binding components
used to provide references to external application functionality. The deployment unit
for a BPM process is a SCA composite.
5.5 Oracle BPM (OBPM) Design-time

Oracle Business Process Management, a member of the Oracle Business Process
Management Suite, is a set of tools for creating, executing, and optimizing business
processes. In addition to the business-IT integration between BPA Suite and BPM
Suite, Oracle BPM provides support for both business and IT with views and reports
tailored to specific stakeholders. This fosters collaboration between business and IT in
designing, automating, and optimizing business processes.
The components of the BPM product are described in the following sections.

Oracle BPM (OBPM) Design-time
5.5.1 BPM Studio

BPM Studio is an IDE extension providing graphical modeling for integrated business
process design, human workflow, business rules, and forms design. It also includes
simulation and creation of Key Performance Indicators (KPI's) for process
instrumentation with sensors to track activities and variables.
BPMN Editor, Task Editor, Rules editor, BPM Forms (using ADF) can be seen in the
design-time modeling diagram in Figure 54 below.
BPM Studio provides both business and technical views of business process models.
The technical view enables the technical integration of external data and document
sources, message routing and transformation, and external systems interactions. The
technical designer can choose to generate BPMN, BPEL, or human workflow models
to be executed by the run-time system.
In addition to the metadata repository (MDS) described earlier, BPM Studio also
exchanges BPMN models with the BPA repository, enabling sharing of views, version
control, and consistent access control via a shared directory.
No coding is required in the preparation of models for execution (including business
rules and forms design for human task presentation). All process development and
configuration is graphical or declarative, and generated executable process models are
in the form of XML.
Service discovery is supported using UDDI and/or WSIL integration.
5.5.2 BPM Composer

Oracle BPM Composer (also referred to as Process Composer) is a web-based
application that provides a non-technical environment for editing processes and
process templates. BPM Composer is a component of the Oracle BPM Suite that also
further encourages collaboration between business users and IT process developers
and designers.
BPM Studio and Composer are shown in the diagram in Figure 54 below mapping
their capabilities to the components of the design-time logical model described in the
previous chapter.
Product Mapping 5-7

Oracle BPM (OBPM) Design-time
Figure 54 BPM Analysis and Design detail
5.5.3 Oracle BPM (OBPM) Run-time

Oracle BPM provides an integrated process execution engine (also referred to as
common run-time) supporting BPEL, BPMN 2.0 and Human workflow based on
WS-HumanTask and BPEL4People.
The BPM run-time supports interaction with running processes with Process
Workspace for process configuration and administration, and Process Portal for
human task management.
These components of the BPM product can be seen the following diagram showing the
mapping to the run-time components of the logical model.

Oracle Business Rules (OBR)
Figure 55 BPM Run-time detail
Process Analytics provides a dashboard for process performance information based on

KPI's defined at design-time and using data collected from sensors embedded in the
run-time system. The information collected by Process Analytics may also be returned
to the design-time simulation tool to refine simulation models and/or passed to Oracle
BAM for broader business performance management.
Activity Guides are used to establish milestones for collections of human tasks in
order to report meaningful status through progress indicators.
Approval Management (AMX) extends human workflow services with complex
approval patterns. It serves as a sophisticated "Assignment Manager" for human
workflow. Some of the key workflow features include policy-based task assignment
and routing, escalation and expiration settings, and email, voice, and Instant
Messaging notification. AMX also integrates with applications using ADF to
incorporate established approval mechanisms into human workflow processes.
5.6 Oracle Business Rules (OBR)

Oracle Business Rules is a rule design tool and inference engine to capture business
policies. The Business Rules component of the Oracle BPM Platform is a
high-performance inference-based Rules Engine that enables business rules to be
explicitly specified and managed by business users in a declarative fashion. The Rules
Engine is based on the industry standard Rete algorithm.
Product Mapping 5-9

Oracle Business Activity Monitoring (BAM)
OBR is part of the Fusion Middleware stack and integrates seamlessly across the entire
Oracle SOA Suite and BPM Suite.
5.7 Oracle Business Activity Monitoring (BAM)

Oracle Business Activity Monitoring gives business executives the ability to monitor
business processes across the enterprise and to correlate KPIs enabling rapid business
process change and corrective actions.
5.8 WebCenter (WCI)

Oracle WebCenter Suite 11g's Business Dictionary along with Oracle Composer
provides powerful role-based facilities that enable business users to seamlessly unify
many corporate information assets with enterprise portals.
In addition to enterprise application and content integration, WebCenter enables
Business Process Integration via the BPM Process Portal. The BPM Process Portal
unifies the following BPM elements:
the end-user's Worklist,
the composite user interfaces for the applications being integrated into Business
Processes,
the Business Process Console,
and Process Intelligence via a pre-packaged Business Process Library.
Oracle WebCenter provides direct integration with Oracle's Enterprise Business
Dictionary and provides pre-packaged integration with Applications, Content and
Rich Media, Business Processes, and Business Intelligence in a role-specific way to
speed user awareness of these critical resources.
5.9 Integration
The SOA Suite product components provide integration for both design-time service
discovery and run-time service consumption and management.
Other Application integration strategies including Oracle Adapters, Oracle
Connectors, Oracle Data Integration.
5.9.1 Oracle Data Integrator

Oracle Data Integrator is a comprehensive data integration platform that covers all
data integration requirements: from high-volume, high-performance batch loads, to
event-driven, trickle-feed integration processes, to SOA-enabled data services.
5.9.2 Oracle Adapters

The Adapters for Oracle Applications provide comprehensive, bi-directional,
multi-modal, synchronous and asynchronous connectivity to the Oracle Applications.
The Oracle Applications Adapter provides the necessary infrastructure to integrate
Oracle Applications with all other enterprise IT assets.
Oracle Adapters for other (legacy) applications provide integration via Tuxedo to
mainframe and other legacy applications.

6
Process View
6
The process model represented here is an elaboration of the BPM lifecycle outlined in
BPM Foundation. This model serves primarily to identify the key roles (including
human and system participants) and some of the artifacts exchanged between them
throughout the lifecycle of a business process.
6.1 BPM Lifecycle Process

This process description is not intended to provide a method creating business process
automation: this level of detail can be found however, in the Oracle Approach to
Business Process Engineering practitioner guide and other related documents.
The diagram in Figure 61 below shows the high level activities and the flow of data in
the development and execution of a business process.
Process View 6-1

BPM Lifecycle Process
Figure 61 High-level activities in a business process lifecycle
The diagram shows three main groups of activities represented by the swim-lanes:
business architecture, business process analysis and design, and the process run-time
system and its process participants.
The business and/or enterprise architecture provide the initial business motivation
(Business Motivation Model, Value Chains, Balanced Scorecard, etc.) and high-level
business process model. These business drivers and model are represented here as the
transfer of business architecture artifacts providing the inputs necessary to initiate the
creation of a new (or change to existing) level 1 business process model (potentially
leading to the development of an executable model). The business motivation and
associated artifacts should be available throughout the lifecycle of the process in order
to inform analysts and designers of the original business purpose and to maintain
traceability and impact analysis when changes are needed.
The business architecture processes are beyond the scope of this document and the
associated swim-lane is therefore outlined with a dotted line. The process is
considered external to the core processes represented here but it is included to show
the source of the inputs to the start of our modeling process.

Model, simulate, publish is the main sequence of activities performed by the business
analyst, however in reality an iterative process of model refinement would most likely
involve further information exchanges with business and technical users. Business
rules and Key Performance Indicators (KPIs) are also determined at this stage and
provide input to the technical design process for integration with the core business
process (this level of detail is not shown in the diagram). The business analyst
produces the level 2 model, dealing with the nuances of events, errors, and exceptions
preparing the model for next steps of technical configuration.
The level 2 process model, output from the analyst, is transferred to the process
repository where it is available to the designer for the final steps of configuration. This
transfer to the repository is indicated by a dotted line as the output from the analyst's
publish activity and (another dotted line) as input to the designer's technical modeling
activity. This transfer of model data follows the flow of control from the analyst to the
designer.
The process designer performs level 3 process modeling to make the process
executable. This is the technical activity of associating tasks (lowest level activities) in
the model underlying application functions and human workflow, configuring
message flows, data mapping, and transformation.
Finally the automated business process is available to the run-time system (via the
process repository). Here a process instance may be started by an internal participant
or by an external event. Human and system actors participate in the process until the
process ends, providing some kind of result.
The process is monitored according to the configured performance indicators and (not
shown here) its data is subjected to process analytics for Business Activity Monitoring
(BAM) and may be aggregated to support future simulations.
Process View 6-3


7
Deployment View
7
The BPM deployment view describes the manifestation of the components of any BPM
system and its necessary relationships with external systems.
7.1 A Generalized Deployment Model

Every BPM can be said to be comprised of run-time business process engine, business
process participants, and supporting services. Figure 71 below represents these
elements in a typical product system configuration. The following sections describe
these elements in more detail.
Figure 71 Generalized Deployment Model
The diagram shows a typical production environment in which the BPM core process
engine is deployed in one middleware cluster while client workspace and applications
interfaces are deployed in another. Also shown is a database for process metadata and
a directory for security and organizational role mapping.
Deployment View 7-1

Typical Physical Deployment
7.1.1 Run-time Business Process Engine

The primary role of the run-time engine is managing the sequencing and flow of
control between tasks defined by the process model. The process engine is not
responsible for executing the underlying tasks themselves, but rather overseeing their
execution and conveying messages between them. The run-time supports
systems/application activities as well as human workflow.
The run-time engine may perform many other BPM specific tasks, such as monitoring
and analysis of process performance, process auditing, etc. A complete list of run-time
capabilities can be found in Section 4.2.1, "Process Execution".
7.1.2 BPM Participants

Business process participants are both the human actors involved in human workflow
activities, and applications that interact with business processes. Human participants
typically interact with the business process through a workflow management portal or
through direct integration with the users applications. System participants trigger
events and interact with the process through various forms of integration and can
include applications, fax machines, e-mail, etc.
Another category of BPM clients includes the BPM process administrator monitoring
the health of the running processes through an administration tool.
7.1.3 Supporting Services

BPM systems also rely on other capabilities commonly found in an IT environment.
These include databases for process definition (metadata) and a directory for users
association with roles.
7.2 Typical Physical Deployment

A typical physical deployment for a BPM production system is shown in Figure 72
below.

Figure 72 Typical Physical Deployment
In this diagram we see all the elements of BPM system and its supporting components
in a typical distribution across servers and server clusters.
Deployment View 7-3


8
8Summary
The current realization of the "third wave" of BPM shows much promise in addressing
the business-IT gap. This is achieved with a common business process model shared
between the business, IT, and the run-time system in a zero-code, closed loop. SOA
has addressed technical integration problems and placed core application services in
the hands of the business analyst. Business Rules Management Systems elevate
business rules and policy from the realm of code. And, the new modeling standard,
BPMN 2.0, has set the stage for tools that seamlessly exchange models between
stakeholders and execution systems.
This is an exciting time for BPM. We have come a long way from the days of having a
fleet of business consultants write a recipe for a re-engineered business process only to
find that it will take years for IT to implement it. We've crossed a number of chasms
along the way: from manual workflow supported by digitized media, to integration
and workflow between siloed applications with EAI, finally to the BPM Suite with
round-tripping between business specialists, systems engineers, and run-time systems
providing feedback.
The BPMS is still evolving and improving, but the core combination of BPM, SOA,
BRMS, and BAM is the universally agreed-upon direction. Given an appropriate
infrastructure with a robust and consistent metadata repository, process and rules
platforms, and suitable monitoring and analytics, the new wave of BPM is set to
change the face of IT and the businesses it supports.
Summary 8-1
A
AFurther Reading
The IT Strategies From Oracle series contains a number of documents that offer
insight and guidance on many aspects of technology. In particular, the following
documents pertaining to ORA may be of interest:
ORA SOA Foundation - This document is suggested pre-reading for those wishing to
get a deeper background to the SOA aspect of this document. It presents important
basic concepts of SOA that are instrumental to building applications for a SOA
environment. It covers topics including the components of a service, service layering,
service types, the service model, composite applications, invocation patterns, and
standards that apply to SOA.
ORA SOA Infrastructure - Infrastructure plays a key role in a successful enterprise
SOA environment. The SOA Infrastructure document describes the role of
infrastructure and the capabilities it provides. It offers an array of views to define
infrastructure for SOA, including logical and physical views, as well as technology
and product mapping.
ORA Integration - Many forms of integration exist today and play a key role in
enterprise computing. The ORA Integration document examines the most popular and
widely used forms of integration, putting them into perspective with current trends
made possible by SOA standards and technologies. It offers guidance on how to
integrate systems in the Oracle Fusion environment, bringing together modern
techniques and legacy assets.
ORA Security - The ORA Security document describes important aspects of security
including identity, role, and entitlement management, authentication, authorization,
and auditing (AAA), and transport, message, and data security.
ORA Monitoring & Management - A common thread running through many
applications, services, and systems is the ability to monitor and manage assets in a
consistent and efficient manner. ORA Monitoring and Management offers a
framework for OA&M to rationalize these capabilities and help optimize the
operational aspects of enterprise computing.
In addition, the following materials and sources of information relevent to ORA
Integration may be useful:
State of the Business Process Management Market - this Oracle whitepaper discusses
the results of an analysis of the current state of BPM in IT.
Further Reading A-1

A-2 ORA BPM Infrastructure

Oracle Technology Strategies BPM Infrastructure (Reference Architecture)

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Oracle Technology Strategies BPM Infrastructure (Reference Architecture)

Hochgeladen von

Copyright:

Verfügbare Formate

Oracle Reference Architecture

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Primary Author: Mark Wilkins

THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS

Third Party Content, Products, and Services Disclaimer

Send Us Your Comments ....................................................................................................................... vii

3 Conceptual Architecture and Infrastructure Capabilities

ORA BPM Infrastructure, Release 3.0

How to Use This Document

ITSO is made up of three primary elements:

"Service" v. "service" - In order to distinguish the service of Service-Oriented

ORA is a product-agnostic reference architecture based on architecture principles and

1.1 BPM Infrastructure

1.2 Scope of BPM Perspective

1-2 ORA BPM Infrastructure

The purpose of the BPM infrastructure architecture document is to provide a tangible,

2.1 Business Goals for BPM Infrastructure

2.2 BPM and SOA

2-2 ORA BPM Infrastructure

2-4 ORA BPM Infrastructure

A conceptual architecture is a representation of the generalized capabilities of a

Conceptual Architecture and Infrastructure Capabilities 3-1

Figure 31 BPM Conceptual Architecture

3.1 BPM Infrastructure Capabilities

3-2 ORA BPM Infrastructure

3.1.3 Unified Repository

3.1.3.1 Process Model and Metadata

3.1.3.2 Business Rules Repository

3.1.3.3 Service Repository

3.1.3.4 Business Motivation

Conceptual Architecture and Infrastructure Capabilities 3-3

3.1.3.5 Model Exchange

3.1.3.6 Diagram Interchange

3.1.4 Process Execution

3.1.4.1 Business Process

3.1.4.2 Human Workflow

3.1.4.3 Service Orchestration

3.1.5 Business Rules

3-4 ORA BPM Infrastructure

3.1.6 Event Handling

3.1.7 Monitoring, Management, and Security

3.1.8 Stakeholder Interaction

Conceptual Architecture and Infrastructure Capabilities 3-5

3.1.8.1 Process Analysis and Modeling

3.1.8.2 Monitoring, Analysis, and Control

3.1.8.3 Process Initiators and Participants

3-6 ORA BPM Infrastructure

4.1 Design-time Logical View

Logical Architecture 4-1

Figure 41 Design-time Logical Architecture

4.1.1 Business Architecture

4-2 ORA BPM Infrastructure

4.1.2 Business Process Modeler

4.1.3 Business Process Simulator

4.1.4 Business Policy Manager

4.1.5 Technical Process Designer

4.1.6 Service Composer

Logical Architecture 4-3

4.1.7 Design-time Repository

4.1.8 Diagram Interchange

4.2 Run-time Logical View

4-4 ORA BPM Infrastructure

Figure 42 Run-time Logical Architecture

4.2.1 Process Execution