ora bpm infrastructure, release 3 - oracle | hardware and

Oracle® Reference ArchitectureBPM 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.

iii

Contents

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

Preface ................................................................................................................................................................. ix

1 Overview

1.1 BPM Infrastructure ..................................................................................................................... 1-11.2 Scope of BPM Perspective.......................................................................................................... 1-1

2 Introduction

2.1 Business Goals for BPM Infrastructure.................................................................................... 2-12.2 BPM and SOA.............................................................................................................................. 2-2

3 Conceptual Architecture and Infrastructure Capabilities

3.1 BPM Infrastructure Capabilities ............................................................................................... 3-23.1.1 Modeling ............................................................................................................................... 3-23.1.2 Simulation............................................................................................................................. 3-33.1.3 Unified Repository .............................................................................................................. 3-33.1.3.1 Process Model and Metadata...................................................................................... 3-33.1.3.2 Business Rules Repository........................................................................................... 3-33.1.3.3 Service Repository ........................................................................................................ 3-33.1.3.4 Business Motivation ..................................................................................................... 3-33.1.3.5 Model Exchange ........................................................................................................... 3-43.1.3.6 Diagram Interchange ................................................................................................... 3-43.1.4 Process Execution ................................................................................................................ 3-43.1.4.1 Business Process .......................................................................................................... 3-43.1.4.2 Human Workflow ....................................................................................................... 3-43.1.4.3 Service Orchestration .................................................................................................. 3-43.1.5 Business Rules ..................................................................................................................... 3-43.1.6 Event Handling ................................................................................................................... 3-53.1.7 Monitoring, Management, and Security .......................................................................... 3-53.1.8 Stakeholder Interaction....................................................................................................... 3-53.1.8.1 Process Analysis and Modeling ................................................................................. 3-63.1.8.2 Monitoring, Analysis, and Control ............................................................................ 3-63.1.8.3 Process Initiators and Participants............................................................................. 3-6

iv

4 Logical Architecture

4.1 Design-time Logical View.......................................................................................................... 4-14.1.1 Business Architecture ......................................................................................................... 4-24.1.2 Business Process Modeler................................................................................................... 4-34.1.3 Business Process Simulator ................................................................................................ 4-34.1.4 Business Policy Manager .................................................................................................... 4-34.1.5 Technical Process Designer ................................................................................................ 4-34.1.6 Service Composer ................................................................................................................ 4-34.1.7 Design-time Repository ...................................................................................................... 4-44.1.8 Diagram Interchange........................................................................................................... 4-44.2 Run-time Logical View............................................................................................................... 4-44.2.1 Process Execution ................................................................................................................ 4-54.2.1.1 Rules Execution Engine ............................................................................................... 4-54.2.1.2 State Manager................................................................................................................ 4-54.2.1.3 Transaction Coordinator ............................................................................................. 4-64.2.1.4 Process Cache ................................................................................................................ 4-64.3 Related Components .................................................................................................................. 4-64.3.1 Continuous Improvement Loop........................................................................................ 4-64.3.2 Application Integration....................................................................................................... 4-74.3.2.1 Work-list ........................................................................................................................ 4-74.3.2.2 Service Discovery ......................................................................................................... 4-7

5 Product Mapping

5.1 Oracle Business Process Analysis Suite ................................................................................... 5-25.2 Oracle Business Process Management Suite ........................................................................... 5-45.3 Oracle SOA Suite......................................................................................................................... 5-55.4 Shared Products and Product Components............................................................................ 5-65.4.1 Metadata Service (MDS) Repository................................................................................. 5-65.4.2 Service Component Architecture (SCA)........................................................................... 5-65.5 Oracle BPM (OBPM) Design-time ............................................................................................ 5-65.5.1 BPM Studio ........................................................................................................................... 5-75.5.2 BPM Composer .................................................................................................................... 5-75.5.3 Oracle BPM (OBPM) Run-time.......................................................................................... 5-85.6 Oracle Business Rules (OBR)..................................................................................................... 5-95.7 Oracle Business Activity Monitoring (BAM) ....................................................................... 5-105.8 WebCenter (WCI)..................................................................................................................... 5-105.9 Integration................................................................................................................................. 5-105.9.1 Oracle Data Integrator...................................................................................................... 5-105.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-17.1.1 Run-time Business Process Engine.................................................................................... 7-2

v

7.1.2 BPM Participants ................................................................................................................. 7-27.1.3 Supporting Services............................................................................................................. 7-27.2 Typical Physical Deployment ................................................................................................... 7-2

8 Summary

vi

List of Figures

3–1 BPM Conceptual Architecture .................................................................................................. 3-24–1 Design-time Logical Architecture............................................................................................. 4-24–2 Run-time Logical Architecture.................................................................................................. 4-54–3 End-to-end Logical Architecture .............................................................................................. 4-65–1 High-level view of the core BPM Suites and related products ............................................ 5-25–2 Core of BPA Suite Components................................................................................................ 5-35–3 BPM Suite Products .................................................................................................................... 5-55–4 BPM Analysis and Design detail .............................................................................................. 5-85–5 BPM Run-time detail .................................................................................................................. 5-96–1 High-level activities in a business process lifecycle............................................................... 6-27–1 Generalized Deployment Model .............................................................................................. 7-17–2 Typical Physical Deployment ................................................................................................... 7-3

vii

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 [email protected].

ix

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.

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

x

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 DocumentThis 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 DocumentsIT 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

xi

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 Oracle’s 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.

ConventionsThe following typeface conventions are used in this document:

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

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.

http://www.oracle.com/goto/itstrategies

1

Overview 1-1

1Overview

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 InfrastructureThe 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 PerspectiveThis 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,

Scope of BPM Perspective

1-2 ORA BPM Infrastructure

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.

2

Introduction 2-1

2Introduction

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 InfrastructureToday'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

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 SOAAlthough 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 Capabilities 3-1

3Conceptual Architecture and InfrastructureCapabilities

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 3–1 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.

BPM Infrastructure Capabilities


Figure 3–1 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 CapabilitiesIn 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 ModelingProcess 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 SimulationSimulation 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 RepositoryThe 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 MetadataThe 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 RepositoryThe 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 RepositoryAnother 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 MotivationUnderstanding 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 ExchangeWhen 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 InterchangeWhen 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 ExecutionProcess 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 SecurityAs 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 InteractionSeen 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 ModelingBusiness 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 ControlThis 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 ParticipantsThese 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

Logical Architecture 4-1

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 ViewThe business process design-time components described in the following sections are shown in the diagram in Figure 4–1 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".

Design-time Logical View


Figure 4–1 Design-time Logical Architecture

The diagram in Figure 4–1 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 4–1 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 OMG’s 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 designer’s 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 ModelerThe business process modeler, shown in the core of the BPM design-time diagram in Figure 4–1, 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 SimulatorThe 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 ManagerAbstraction 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 DesignerThe 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 ComposerThe 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 RepositoryThe 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 InterchangeAlthough 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 ViewThe BPM run-time logical view is shown in Figure 4–2 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 4–2 Run-time Logical Architecture

While the core system run-time components are shown grouped in the main portion of the diagram in Figure 4–2 the core human interfaces are grouped separately in the labeled "process portal".

4.2.1 Process ExecutionThe 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 EngineThe 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 ManagerThe state manager persists the state of long running processes, thereby freeing memory resources of the runtime subsystem.

Related Components


4.2.1.3 Transaction CoordinatorThe transaction Coordinator is responsible for managing both atomic and long-running transactions.

4.2.1.4 Process CacheThe state of a running process may be cached to improve performance of the run-time system.

4.3 Related ComponentsThe 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 4–3 below shows these relationships which are also described in the following sections.

Figure 4–3 End-to-end Logical Architecture

4.3.1 Continuous Improvement LoopThe relationship between the design-time and run-time groups of components is shown by the two arrows between the two major subsystems in Figure 4–3. 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 IntegrationApplication integration is shown primarily in the lower section of the diagram in Figure 4–3, but it also appears in another form in the process portal box at the top of diagram.

4.3.2.1 Work-listThe 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 DiscoveryA 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-1

5Product Mapping

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.

Oracle Business Process Analysis Suite


Figure 5–1 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 SuiteOracle 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

Product Mapping 5-3

■ 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 5–2 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

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

Product Mapping 5-5

Figure 5–3 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 SuiteSOA 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.

Shared Products and Product Components


5.4 Shared Products and Product ComponentsA 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) RepositoryOf 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-timeOracle 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

Product Mapping 5-7

5.5.1 BPM StudioBPM 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 5–4 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 ComposerOracle 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 5–4 below mapping their capabilities to the components of the design-time logical model described in the previous chapter.

Oracle BPM (OBPM) Design-time


Figure 5–4 BPM Analysis and Design detail

5.5.3 Oracle BPM (OBPM) Run-timeOracle 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)

Product Mapping 5-9

Figure 5–5 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.

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 IntegrationThe 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 IntegratorOracle 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 AdaptersThe 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-1

6Process View

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 ProcessThis 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 6–1 below shows the high level activities and the flow of data in the development and execution of a business process.

BPM Lifecycle Process


Figure 6–1 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.


Process View 6-3

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.

7

Deployment View 7-1

7Deployment View

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 ModelEvery BPM can be said to be comprised of run-time business process engine, business process participants, and supporting services. Figure 7–1 below represents these elements in a typical product system configuration. The following sections describe these elements in more detail.

Figure 7–1 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.

Typical Physical Deployment


7.1.1 Run-time Business Process EngineThe 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 ParticipantsBusiness 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 ServicesBPM 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 DeploymentA typical physical deployment for a BPM production system is shown in Figure 7–2 below.


Deployment View 7-3

Figure 7–2 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.

8

Summary 8-1

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.

A

Further Reading A-1

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.

http://www.oracle.com/applications/application-integration-architecture-pre-built-soa.pdf

A-2 ORA BPM Infrastructure